From nobody Mon May 1 00:38:47 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630781293D6; Mon, 1 May 2017 00:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, 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 fyr3J4tuoZBL; Mon, 1 May 2017 00:38:42 -0700 (PDT) Received: from mx01.telecomitalia.it (mx01.telecomitalia.it [217.169.121.10]) (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 63C0D129B63; Mon, 1 May 2017 00:36:03 -0700 (PDT) X-AuditID: d9a9790a-bc3ff7000000439d-9d-5906e55f30ff Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx01.telecomitalia.it () with SMTP id DE.7F.17309.F55E6095; Mon, 1 May 2017 09:36:00 +0200 (CEST) From: Fioccola Giuseppe To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@ietf.org" CC: "draft-bryant-mpls-rfc6374-sfl@ietf.org" Thread-Topic: R: IPR poll on draft-bryant-mpls-rfc6374-sfl Thread-Index: AQHSvwbYCEwbUKb/E0u0OLm/OkrHyqHY8mLQgAAJsoCAACNF4IAF+vUd Date: Mon, 1 May 2017 07:35:58 +0000 Message-ID: <1493624158511.94291@telecomitalia.it> References: <8b495d71-1291-cd59-9faa-fff371c9535f@pi.nu> <2d27868ab59943cc964a1c715b58521e@TELMBXB02RM001.telecomitalia.local> <82bbc067-3526-8999-ad84-80654cccea55@pi.nu>, <8a36b471f3c24e848a3cc05278d16003@TELMBXB02RM001.telecomitalia.local> In-Reply-To: <8a36b471f3c24e848a3cc05278d16003@TELMBXB02RM001.telecomitalia.local> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.233] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsXCxfdHWjfhKVukQeMsbYuGyTYW/+bOYbZY d/kUm8WtpStZHVg8liz5yeQxa3obWwBTFJdNSmpOZllqkb5dAlfGgYlrGQseqlVMbFjB2sD4 Tr6LkZNDQsBE4vqp6WxdjFwcQgJTmSR6P21nBUmwCdhIHHx1AijBwSEikC+x6W4kSJhZIFzi 0rq9YCXCApYSv888YAGxRQSsJNYtucAGYbtJfL3QCxZnEVCRaPi3ihHE5hUwkjjyrJ8ZYtdX RomO0weZQBKcAkESnz53M4PYjAKyEhN2L2KEWCYu8WL6CXaIQwUkluw5zwxhi0q8fPyPFcI2 kNi6dB8LhK0o8ai5mw3ClpFYeGQyK8QcPYkbU6ewQdjaEssWvmaGOEhQ4uTMJywTGMVmIVk3 C0nLLCQts5C0LGBkWcUomlthYKhXkpqTmpyfm1mSmJOZqJdZsokRGFE3V1Zy7WB8vcr5EKMA B6MSD6/NfbZIIdbEsuLK3EOMEhzMSiK8228ChXhTEiurUovy44tKc1KLDzFKc7AoifMWsDBF CgmkJ5akZqemFqQWwWSZODilGhiVJs095NVS8NBMNKamPTHX/Io8v3jBSYaiDRofsx7WiAsy rr50hmX7G4bzj0o3/TYVU10/iTvYyqJEZSfXkx3/v+dlad/drbnHq/j0pW0nXi3/2MT5/unq M6tv3FyXV9ejzK6tlLxadeMdo2U2Gxg9+p1Pqn7n/D2B54UM32lR3S1ma++03FukxFKckWio xVxUnAgAq4QuVqQCAAA= Archived-At: Subject: Re: [mpls] R: IPR poll on draft-bryant-mpls-rfc6374-sfl X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 07:38:46 -0000 Hi Loa,=0A= I'm not aware of other IPR related to the draft besides that has already be= en disclosed.=0A= =0A= Best Regards,=0A= =0A= Giuseppe=0A= ________________________________________=0A= Da: Fioccola Giuseppe =0A= Inviato: gioved=EC 27 aprile 2017 14:13=0A= A: Loa Andersson; mpls@ietf.org; mpls-chairs@ietf.org=0A= Cc: draft-bryant-mpls-rfc6374-sfl@ietf.org; ippm@ietf.org; ippm-chairs@ietf= .org=0A= Oggetto: R: R: IPR poll on draft-bryant-mpls-rfc6374-sfl=0A= =0A= Ok Loa,=0A= Many Thanks for your clarification.=0A= I will inform TI IPR department so they can update the disclosure on draft-= bryant-mpls-rfc6374-sfl.=0A= =0A= Best Regards,=0A= =0A= Giuseppe=0A= =0A= -----Messaggio originale-----=0A= Da: Loa Andersson [mailto:loa@pi.nu]=0A= Inviato: gioved=EC 27 aprile 2017 14:00=0A= A: Fioccola Giuseppe; mpls@ietf.org; mpls-chairs@ietf.org=0A= Cc: draft-bryant-mpls-rfc6374-sfl@ietf.org; ippm@ietf.org; ippm-chairs@ietf= .org=0A= Oggetto: Re: R: IPR poll on draft-bryant-mpls-rfc6374-sfl=0A= =0A= Giuseppe,=0A= =0A= I can't give advice on validity of one IPR or another. If you have knowledg= e about IPRs that you think are relevant for one IETF document or another y= ou have to disclose. The fact that it has been disclosed against another do= cument is not relevant, a disclosure is necessary for each document you thi= nk it applies to.=0A= =0A= /Loa=0A= =0A= On 2017-04-27 18:26, Fioccola Giuseppe wrote:=0A= > Hi All,=0A= > I'm one of the co-authors of this draft.=0A= >=0A= > The IPR disclosure, already linked to this document, is the fundamental o= ne.=0A= > There are other IPRs belonging to the same topic: the alternate marking t= echnology (owned by Telecom Italia).=0A= >=0A= > These are already declared on draft-ietf-ippm-alt-mark, that is a referen= ce for draft-bryant-mpls-rfc6374-sfl.=0A= > Our draft mentions draft-ietf-ippm-alt-mark in some points and explains h= ow to use the alternate marking technology, so all the IPRs should be inher= ited in addition to the IPR already declared.=0A= >=0A= > Do you think we should declare also the other IPRs on our draft or are th= ese already inherited from draft-ietf-ippm-alt-mark?=0A= >=0A= > Thanks,=0A= >=0A= > Giuseppe=0A= >=0A= >=0A= > -----Messaggio originale-----=0A= > Da: Loa Andersson [mailto:loa@pi.nu]=0A= > Inviato: gioved=EC 27 aprile 2017 05:32=0A= > A: mpls@ietf.org=0A= > Cc: mpls-chairs@ietf.org; draft-bryant-mpls-rfc6374-sfl@ietf.org=0A= > Oggetto: IPR poll on draft-bryant-mpls-rfc6374-sfl=0A= >=0A= > Working Group,=0A= >=0A= > The author of draft-bryant-mpls-rfc6374-sfl has told us that the document= is ready to be considered for working adoption.=0A= >=0A= > The document been through MPLS-RT review. We will do an IPR poll parallel= to the start of the adoption poll.=0A= >=0A= > This mail starts the IPR poll.=0A= >=0A= > Are you aware of any IPR that applies to draft-bryant-mpls-rfc6374-sfl?= =0A= >=0A= > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs 3979, 4879, 3669 and 5378 for more details).=0A= >=0A= > There is one IPR disclosure filed directly against this document.=0A= >=0A= > If you are listed as a document author or contributor please respond to t= his email regardless of whether or not you are aware of any relevant IPR. *= The response needs to be sent to the MPLS wg mailing list.* The document wi= ll not advance to the next stage until a response has been received from ea= ch author and contributor.=0A= >=0A= > If you are on the MPLS WG email list but are not listed as an author or c= ontributor, then please explicitly respond only if you are aware of any IPR= that has not yet been disclosed in conformance with IETF rules.=0A= >=0A= >=0A= > /Loa=0A= > mpls wg co-chair=0A= >=0A= =0A= --=0A= =0A= =0A= Loa Andersson email: loa@mail01.huawei.com=0A= Senior MPLS Expert loa@pi.nu=0A= Huawei Technologies (consultant) phone: +46 739 81 21 64=0A= =0A= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.=0A= =0A= This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks.=0A= =0A= Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario.=0A= From nobody Mon May 1 17:23:37 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D770128D3E; Mon, 1 May 2017 17:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 K7WTvnZXBYu7; Mon, 1 May 2017 17:23:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F39AE12EB48; Mon, 1 May 2017 17:20:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMB92148; Tue, 02 May 2017 00:20:51 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 2 May 2017 01:20:50 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.200]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 2 May 2017 08:20:45 +0800 From: Lizhenbin To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@ietf.org" CC: "draft-bryant-mpls-rfc6374-sfl@ietf.org" Thread-Topic: R: IPR poll on draft-bryant-mpls-rfc6374-sfl Thread-Index: AQHSvwbcts0xjY2HnE67nrm26bupAaHYfVwAgAAaI4CAAAO7AIAF+8EAgAGeKeA= Date: Tue, 2 May 2017 00:20:45 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8DEFDD8E@NKGEML515-MBS.china.huawei.com> References: <8b495d71-1291-cd59-9faa-fff371c9535f@pi.nu> <2d27868ab59943cc964a1c715b58521e@TELMBXB02RM001.telecomitalia.local> <82bbc067-3526-8999-ad84-80654cccea55@pi.nu>, <8a36b471f3c24e848a3cc05278d16003@TELMBXB02RM001.telecomitalia.local> <1493624158511.94291@telecomitalia.it> In-Reply-To: <1493624158511.94291@telecomitalia.it> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.77] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5907D0E4.0045, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.200, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2445dc3514f0505b2c92b323fb462411 Archived-At: Subject: [mpls] =?gb2312?b?tPC4tDogUjogSVBSIHBvbGwgb24gZHJhZnQtYnJ5YW50?= =?gb2312?b?LW1wbHMtcmZjNjM3NC1zZmw=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 00:23:36 -0000 SGkgTG9hLA0KSSdtIG5vdCBhd2FyZSBvZiBvdGhlciBJUFIgcmVsYXRlZCB0byB0aGUgZHJhZnQg YmVzaWRlcyB0aGF0IGhhcyBhbHJlYWR5IGJlZW4gZGlzY2xvc2VkLg0KDQpCZXN0IFJlZ2FyZHMs DQpaaGVuYmluKFJvYmluKQ0KDQoNCg0KPg0KPiAtLS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0t LQ0KPiBEYTogTG9hIEFuZGVyc3NvbiBbbWFpbHRvOmxvYUBwaS5udV0NCj4gSW52aWF0bzogZ2lv dmVkqKwgMjcgYXByaWxlIDIwMTcgMDU6MzINCj4gQTogbXBsc0BpZXRmLm9yZw0KPiBDYzogbXBs cy1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWJyeWFudC1tcGxzLXJmYzYzNzQtc2ZsQGlldGYub3Jn DQo+IE9nZ2V0dG86IElQUiBwb2xsIG9uIGRyYWZ0LWJyeWFudC1tcGxzLXJmYzYzNzQtc2ZsDQo+ DQo+IFdvcmtpbmcgR3JvdXAsDQo+DQo+IFRoZSBhdXRob3Igb2YgZHJhZnQtYnJ5YW50LW1wbHMt cmZjNjM3NC1zZmwgaGFzIHRvbGQgdXMgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUg Y29uc2lkZXJlZCBmb3Igd29ya2luZyBhZG9wdGlvbi4NCj4NCj4gVGhlIGRvY3VtZW50IGJlZW4g dGhyb3VnaCBNUExTLVJUIHJldmlldy4gV2Ugd2lsbCBkbyBhbiBJUFIgcG9sbCBwYXJhbGxlbCB0 byB0aGUgc3RhcnQgb2YgdGhlIGFkb3B0aW9uIHBvbGwuDQo+DQo+IFRoaXMgbWFpbCBzdGFydHMg dGhlIElQUiBwb2xsLg0KPg0KPiBBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVz IHRvIGRyYWZ0LWJyeWFudC1tcGxzLXJmYzYzNzQtc2ZsPw0KPg0KPiBJZiBzbywgaGFzIHRoaXMg SVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2Vl IFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCj4NCj4g VGhlcmUgaXMgb25lIElQUiBkaXNjbG9zdXJlIGZpbGVkIGRpcmVjdGx5IGFnYWluc3QgdGhpcyBk b2N1bWVudC4NCj4NCj4gSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3Ig Y29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdo ZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gKlRoZSByZXNw b25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBNUExTIHdnIG1haWxpbmcgbGlzdC4qIFRoZSBk b2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9u c2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuDQo+ DQo+IElmIHlvdSBhcmUgb24gdGhlIE1QTFMgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0 ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJl c3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBi ZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQo+DQo+DQo+IC9M b2ENCj4gbXBscyB3ZyBjby1jaGFpcg0KPg0KDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAg ICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQpTZW5pb3IgTVBM UyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KSHVhd2VpIFRlY2hu b2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQoNClF1ZXN0 byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFt ZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNp YXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5m b3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmlj ZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVn YXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJv dnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQg YW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1p bmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0 aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5k ZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQpSaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24g c3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIKioIG5lY2Vzc2FyaW8uDQo= From nobody Tue May 2 06:13:36 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E722E128796; Tue, 2 May 2017 06:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61bq9TWk240n; Tue, 2 May 2017 06:13:33 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 2F26C12EB76; Tue, 2 May 2017 06:08:58 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id w64so112260992wma.0; Tue, 02 May 2017 06:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:cc:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=IeLKncJJ8BTiclyARLFuneLfXojoAVSf9CvSnJyyAYs=; b=FQ2hD0yCKtnegzxwnKBYSc9NtK1Tr4QdZGm0i1fieXMhdJ7Ux/fbXkVQ4KTPrwCZ3r ZjVXsm3Z43XIdAhX8XGiHmoJnQeG2W/ShQ+mfH/RMqIqWFzy2dpf0ZjXT865rhlFNmTh 06s1HTkVXl4yInVEqkr0XiJT6ZNNbXlerlu5Ah9l83SqB38YG1Hx8tTRmXPBMTj0Fvlk JSIT5SavtXohckeyw1E1KN81utSezbydO3x2g6ZDEOjd+JIQuv4+m9+v/c3nZ7fm5sa/ 7C6KN5gEB35HKXgfdq3OdWmjiKgyVzd9/UKfoQbokG+yT0POaTEk6e+XlkXnseipIkCB mRqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:cc:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=IeLKncJJ8BTiclyARLFuneLfXojoAVSf9CvSnJyyAYs=; b=DYGsfrfTSGcR0TBwleO2pMB9pBdIR5onTl2WjRZHw0lgaRzZwSbt8HE9hXT2zyKe+7 vfR0HcBpEiY+o5nWVmxwUWsOeJ5FPW+xNT8e9RMDI6ULwh/qNxbRvRA2M0u39HlUyR3W B5S7aAbJ0mmbJWg4+EDR/fSRGHAz1hAtA+DrwOGDu7NJzjpW/HlcqfzxDrU3UQxncZD9 ws562g7FOUUqTMGjrjWFP06046etBAMAhJSGOcbaS4hCn7W/xIOK2v30gtdJR1PIiB8Q ZN8v6WllRwcc01uLf11brNVVd2O5kBjwp2VqKwKN662pBhmwIBEUEO1fxsngF5Or1+ye SuJQ== X-Gm-Message-State: AN3rC/7OuGj8nvgpJYtPmwSns5UshSbjUTvsEuj56xjQMeNuH0jy5MDh kMZhvDEFb0EItgJu+to= X-Received: by 10.28.32.193 with SMTP id g184mr2250410wmg.56.1493730536365; Tue, 02 May 2017 06:08:56 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id p187sm1090643wmd.24.2017.05.02.06.08.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 06:08:55 -0700 (PDT) To: "mpls-chairs@ietf.org" , "mpls@ietf.org" From: Stewart Bryant Cc: "" Message-ID: <1452d116-c861-ebda-4989-39a93bfdbe8b@gmail.com> Date: Tue, 2 May 2017 14:08:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] draft-ietf-spring-ipv6-use-cases - almost completed WGLC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 13:13:35 -0000 draft-ietf-spring-ipv6-use-cases has almost finished IETF LC (two days left) https://datatracker.ietf.org/doc/draft-ietf-spring-ipv6-use-cases/ There are a number of statements about the development of MPLS over IPv6 that are used to justify the argument of the authors that MPLS cannot run over an IPv6 only network. It seems to me that these statements ought to be checked for correctness by the MPLS WG. Stewart From nobody Wed May 3 08:18:10 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8663129479; Wed, 3 May 2017 08:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFhbL30s70av; Wed, 3 May 2017 08:18:08 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B98E129489; Wed, 3 May 2017 08:16:05 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id o68so4753747pfj.2; Wed, 03 May 2017 08:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-transfer-encoding:content-disposition; bh=k3ZJIPcOgqzeHyqL5rUulzHkTeZQpn1rXIhyXD9LfeI=; b=Bhc6lUZD16L+6yBHf2wnJeKnuO/+9rKHtVZ15TVIvTA3FQsNWXla267EkDD2TKFABj PMutzqU13YszHB+8kjspFmcWnI1zV/6+wGjvH77YE1ulDWpYdlP+UYU2gejLoTInp7u4 Tl5ZjX1EDoXuKmjS+56BFyNvR50VyPfA51jrEEkfEdd0+1KSiuA/31Ry3qy0821xEdCv W+9f43/fta0aNvKfZ7KKrP2/uH1QJPcHJGIKWEPu+ZRvQq/awau8KojNAHHaTwH8IEwY vgjy8fc9Y2QKDeiY24FIqhlyezJG6kprZEB+xmNhVxAdhQYUWZzMsUQCBFRoYLepp5Ru 7ETg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-transfer-encoding :content-disposition; bh=k3ZJIPcOgqzeHyqL5rUulzHkTeZQpn1rXIhyXD9LfeI=; b=DQZWIz3VfAbdD9hswWsArtqnac3Hup99LDmTglHLeWaP7eSiuUHkhLYXT3vM86fl8i icwB9uoLQRmiKtKhgApug5KWYhO6clxp6F5wJviTyxxM1dJFUHZUfuJepQvxT0QPFqSM hTT+hvj1f9vnUC2m3fX4aaufDFUUIrLmqxhqasAz33zQdUI09lOJ51phWYDUpM4aZAvl LvcRuFzkUjq0kIjJzWTcjn8BGFAHWGVqedfLPv6JYVS+S1E8NH8WjKoHcXIa5HBOwmr6 1unGPgscxacePs5v7GI8eAGS8Yg35C/r4Y19O458efZAH0t415pT9FV43OGcpKSQBIKv EtSA== X-Gm-Message-State: AN3rC/5xiv1nWSf2JYlkDGUEwmFE4+JbiY8ZNcUAVOEhsGoLoxgK7IBo e97NmEler7pwNievYYk= X-Received: by 10.98.25.78 with SMTP id 75mr5498693pfz.84.1493824565104; Wed, 03 May 2017 08:16:05 -0700 (PDT) Received: from LLIOK4RX6E0B076 ([103.251.128.66]) by smtp.gmail.com with ESMTPSA id r90sm5890050pfl.120.2017.05.03.08.16.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 08:16:03 -0700 (PDT) Date: Wed, 3 May 2017 23:16:02 +0800 From: "lizho.jin" To: Stewart Bryant Cc: Loa Andersson , draft-bryant-mpls-rfc6374-sfl , huubatwork , "Andrew G. Malis" , Vishwas Manral , mpls-chairs , mpls Message-ID: <299CBBE1-0CFD-424D-BFB5-B602EAFC4469@gmail.com> In-Reply-To: <4fe2d0af-480c-f9ae-d3a2-38fcd1c70772@gmail.com> References: <3492a077-bc52-dd35-aed7-17fc6c749a8b@pi.nu> <20653DE4-B6BE-4915-AB22-0574891CD225@gmail.com> <4fe2d0af-480c-f9ae-d3a2-38fcd1c70772@gmail.com> X-Mailer: PC MailMaster/3.3.1.1013 (Windows 7) MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: Re: [mpls] MPLS-RT review of draft-bryant-mpls-rfc6374-sfl X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 15:18:10 -0000
Stewart, I am OK with the changes, thanks.


Regards
Lizhong

On 04/= 26/2017 02:30=EF=BC=8CStewart Bryant<stewart.bryant=40gmail.com> wrote=EF=BC=9A=



On 23/03/2017 15:14, lizho.jin wro= te:
Hi,
I review this draft, and also the two related S=46L draft. Overall, this document is useful and technically sound. And I have some non-blocking comments listed below. Regarding the adoption, I suggest to consider adopting = ;draft-bryant-mpls-sfl-framework-03 first, then this draft which is highly relied on the concept of S=46L.

I have read draft-bryant-mpls-sfl-framework, did a minor edit and uploaded it. draft-bryant-mpls-sfl-framework-04 is ready for a WG adoption call.


Section 3
   The data service packets of the flow being instrumented are grouped
   into batches, and all the packets within a = batch are marked with the
   S=46L =5BI-D.ietf-mpls-flow-ident=5D
=5BLizhong=5D more suitable to refer =5Bdraft-bryant-mpls-sfl-framework=5D, not =5BI-D.ietf-mpls-flow-ident=5D

=5BI-D.ietf-mpls-flow-ident=5D describes the requirements in a soluti= on agnostic way. I think the reference is correct.

We then describe the problems and that takes us to the framework draft and hence to the solution.

So I think it's all OK.


Section 4
   Such a packet may not need to be carried = over an S=46L since the delay
   over a particular LSP should be a functio= n of the TC bits.
=5BLizhong=5D not understand here, adding S=46L does n= ot change the LSE and TC, why not possible to carry over S=46L=3F

This is considering the case where we are using S=46L to do packet loss, and want to do a single measurement of delay. We should be able to do this just by sending an R=46C6374 packet over the LSP. However there is a corner case where R=46C3270 (label based) prioritization is being used. I think there is another issue with ECMP. I will reword the section to make it clear.

The section now says:

R=46C6374 describes how to measure the packet delay by measuring the<= br> transit time of an R=46C6374 packet over an LSP.  Such a packet = may not
need to be carried over an S=46L since the delay over a particular LS= P
should be a function of the TC bits.

However where S=46Ls are being used to monitor packet loss or where label inferred scheduling is used =7B=7BR=46C3270=7D=7D then
the S=46L would be REQUIRED to ensure that the R=46C6374 packet
which was being used as a proxy for a data service packet experienced
a representative delay. The format of an
R=46C6374 packet carried over the LSP using an S=46L is shown in =7B=7BR=46C6374S=46L=7D=7D.

The packet loss case is petty firm, we need to think about the R=46C3270 case, but
can do that post adoption.

 
Section 7
7.  Multiple Packet Delay Characteristics
=
=5BLizhong=5D = is it assumed here that all packets belong to one flow will go through the same path=3F Some network equipment may not be the case. E.g., case in R=46C7424.

Normally we try quite hard to make sure the packets of a flow go over a single path, so that is a good assumption. If we are load balancing across a number of paths then The method still works, but the delays will be multi-modal. Some of the methods will show this better than others.


Section 7.1
   There will be a number of Interval/Numb= er pairs depending on the
   number of buckets being specified by th= e Querier.  If an R=46C6374
   message is being used to configure the = buckets, the Responder MUST
   respond with 0 packets in each bucket u= ntil it has been configured
   for a full measurement period (i.e. it = was configured at the time of
   the last response message).  Out o= f band configuration is permitted
   by this mode of operation.
=5BLizhong=5D need detail process of Query and Reponse. E.g= ., does the query need =22Number pkts in Bucket=22 field, and= if not, please specify.

I have updated the text as follows:

There will be a number of Interval/Number pairs depending on the
number of buckets being specified by the Querier. If an R=46C6374
= message is being used to configure the buckets, (i.e. the responder
is creating or modifying the buckets according to the intervals = in
the Query message), then the Responder
MUST respond with 0 packets in each bucket until it has been
configured for a full measurement period. This indicates that it was configured
at the time of the last response message, and thus the response
is valid for the whole interval. As per the =7B=7BR=46C6374=7D=7D con= vention
the Number of pkts in Bucket fields are included in the Query message and set
to zero.

Out of band configuration is permitted by this mode of operation.
=
Hopefully this sufficiently  clarifies the operation of the protocol.

7.3.1.  R=46C6374 Multi-Packet Delay Measuremen= t Message =46ormat
=5BLizhong=5D this is only for Classic Standard Deviation, right=3F why it is not section 7.2.1=3F


=46ixed

7.4
   This R=46C6374 message is carried over = an LSP in the way described in
   =5BR=46C6374=5D and over an LSP with an= S=46L as described in Section 9
=5BLizhong=5D = what's the format of query message, will it include =22Time of =46irst Packet=22, =22Time of =46irst Packet=22, a= nd other fields=3F

I have added:

As is the convention with R=46C6374, the Query message contains placeholders
for the Response message. The placeholders are sent as zero.



13.1.  Allocation of PW Associated Channel Type=
   A= s per the IANA considerations in =5BR=46C5586=5D, IANA is requested = to
   allocate the following Channel Type in = the =22PW Associated Channel
   Type=22 registry:

   Value  Description     &= nbsp;              TLV =46ollows  Reference
   -----  ---------------------------= --  -----------  ---------
   TBD    Description MPLS Multi= -Packet  No           This
          Delay Measurement=
=5BLizhong=5D there is other two message type need t= o be defined here. E.g., Bucket Jitter Measurement Message =46ormat, Average Delay Measurement Message =46ormat

Thanks for catching that I have added it

New version will uploaded when I have responded to all the review comments.

Thanks for the review

Stewart


Regards
Lizhong

On 03/9/2017 11:09=EF=BC=8C= Loa Ande= rsson<loa=40pi.nu> wrote=EF=BC=9A
Huub, Andy, Vishwas and Lizhong,

You have been selected as MPLS-RT = ;reviewers for 
draft-bryant-mpls-rfc6374-sfl-03.

Note to authors: You have been CC'd on=  this email so that you can know
that this review is going on. However, = ;please do not review your own
document.

Reviews should comment on whether the docum= ent is coherent, is it
useful (ie, is it likely to be actuall= y useful in operational networks), 
nd is the document technically sound=3F=

We are interested in knowing whether the&nb= sp;document is ready to be
considered for WG adoption (ie, it doesn't&= nbsp;have to be perfect at this
point, but should be a good start). Pl= ease remember that it often is
easier to progress the document when it&nbs= p;has become a working group
document. All comments in the MPLS-RT revie= w needs to be addressed,
but please think carefully about whether a&= nbsp;comment is gating the
adoption or could just as easily be ad= dressed after the adoption.

Reviews should be sent to the document = ;authors, WG co-chairs and WG
secretary, and CC'd to the MPLS WG ema= il list. If necessary, comments
may be sent privately to only the=  WG chairs.

If you have technical comments you should&n= bsp;try to be explicit about what
needs to be resolved before adopting it&nbs= p;as a working group document, and
what can wait until the document is a&= nbsp;working group document and the
working group has the revision control= .

Are you able to review this draft by&n= bsp;March 23, 2017=3F Please respond
whether you are available to do the re= view in a timely fashion.


Thanks, Loa
(as MPLS WG co-chair)
-- 


Loa Andersson         &= nbsp;           &n= bsp;  email: loa=40mail01.huawei.com
Senior MPLS Expert      = ;            =         loa=40pi.nu
Huawei Technologies (consultant)   &nb= sp; phone: +46 739 81 21 64
<=21--=F0=9F=98=80-->

<=21--=F0=9F=98=80-->
From nobody Wed May 3 11:25:16 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA52129A99; Wed, 3 May 2017 11:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgsNl2nNMKz2; Wed, 3 May 2017 11:25:11 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0123.outbound.protection.outlook.com [104.47.38.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10694129B19; Wed, 3 May 2017 11:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XXWT07Ujb5SmCeZlzejM2LfDp0ldfuboDxD0pdiybkk=; b=WpEbxVLS1hWNtm2AhGlJR3EraWecpfeybVxYUmPOBX5pAsBzu8BVH5a0mV6YAo8GdQuahmwCe4qoUSPauAH0A43pPX03RCXd43AtmTI3Y5TKxT3De+tn87tZYn4XKjUogZAv33HAOxTPVyb1G4akOVT/DFtZeHPJL5csOWka7Z0= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.35.213] (66.129.241.14) by BY2PR05MB2184.namprd05.prod.outlook.com (10.166.112.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Wed, 3 May 2017 18:23:07 +0000 To: Jonathan Hardwick , "draft-ietf-mpls-rfc3107bis@ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" References: CC: "rtg-dir@ietf.org" From: Eric C Rosen Message-ID: <9913c8e1-50fe-34c1-a8d5-2d5efefafc5e@juniper.net> Date: Wed, 3 May 2017 14:23:03 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B904B5417489A850A8D161CD" X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BN6PR1301CA0021.namprd13.prod.outlook.com (10.174.84.162) To BY2PR05MB2184.namprd05.prod.outlook.com (10.166.112.12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7a60a971-f7d5-4636-ea42-08d4925172f0 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BY2PR05MB2184; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 3:fq0dx/bnVtlnzVUATiiGIUCkA43jXrXmQAib/C1+r5nDI/DdKTsUQiaEvLLu31wS+rJk5uiZjzjblnF4Eg24Qmnr6GV/PnjmoppBGM0AzedTjmG2CIpxSFgyNQTenNC/a6kb7P9GcuKve7IWBsDjaP+WhXk4zDnjNs7BVOn5fLXsZe7ueMVH8cX3c8JnQb25Gj+wASBy40pDzwdFViD3TR2ztDM+6sGmOq5Ng6GrJZtLC2JgiuO1j/bhLWE+ZtKfTnMhd25+P+6rCVEAWnldnmuA3zvzUob+gyema1f45OuPmEw6THda1H4oD95gIzbuhPk+kDHTSdV6i180MJtzNL0ESSoxZ9iQSIj6t+ygNAM=; 25:OJg7arre2Okrla7YCrl7yAHPVZXV9MUBisxwm2NxiSrMYRVgZQKAqGMsnsZw7cW6pjo+0laNXSV4G7dLgkO9EPAgoa8e9cBcKDcCS/l24HHn24dGRgxjecG8HI1y0oRx1hmPhuQW4eYYrSFOvn3aicn0b9FdQwUkLSwl+waGLL9YxKx0U0Nive/1NP0gPHvz/wQmib0ZlgkLOCAFvTj/epN0ITXsCckvAJpkSA9WvsZJCVn6P5H5g9AzBjmE8l07KI/6X2ihQcj4CmbNoZqcVeC5VEoqpjLj0QRK0jntH0qvGXLBlPHOFqJZ2C8RWw2u3FJmc4Lds1j+NRg2D4boddo5EbBnXza6DiK2cT0xEKOe+7+p2XcwoH4dclZMRGgAbQCV2DD45jYoQd8IQsJXdRGI+ffGHPLVItcnBZ5v61jE5WDIsEA2r3pTKlHImoMmD83foc/QDC3X7rz0iZBw+sMR9+aQkHrIjC1xk734I9E= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 31:3c73c+V0g7UON6/yCApXBHIeKLjOxt219feva56q8XQj6YzRyi7vr8RikyvfnBx5+z1l/f8Se+f7FCsgrJvQnomqxXRQSTrDPOYQVacON+d+nIc68BCiOpCzJB0Ns+LbdVA03hYcwJMJh7rAXQ99qDEwL9T9fh9tSH0Nig4MmjzJAaKEGxHcxxYHB/qrL+tyd2nmmerBfRYvAdSGrX1UT+575Ba+e1eqIy/Xx+QPEFs=; 20:6WtVyx8A6tqaMdU6PBSkWpGO58j1eeq9ptuZ42MfQfS+WwmpWoNJiXC+tn/AYV9jifVEkjZffcoT7JYGRZIpadNInwxEnofh8LApxwvUy8WeCk1gwUN2cI7oWe9oP+ebv+p80DyLg/C/GEYEZhkziQqwSflj78NiiOIdN6Gz6NTRLyGHVXbM8LQqx7ppJyo+L+Rrslx92M2DBybKMjoZVQpJuWnuzG90ZX6DwwgnW8EvR7tKBobDPAfm3tjsWNBoIqpPm3k0lEX3RqoJ1Fhd3utWr6Z4DnpYe746tRFeBio+uLSz81RgoWXG8jK+W2Fzcn83piKeP8+YbFKsmBmKP58do+8vZaQZAfY+w35g4vAyZy1QrY5CafN+Wg1bDpfsX8jxXLLog/cZwsSpsS6wmg4/xppzUVtJbbZrbdPod4Zr5O1qzOC1215Z768KQTeBDoWA6ZkYycEAvQzKNHMmKnPIxiKMQMNqZqkrFfAjAXZ4n7y15cZQGbKBA6Vu7VRT/vNULnDsH1uJjPqTRc19WzmuIH/OETLO6Tde0AT026VryACdg+qffS6DN4zrypetMh6ay0xQ++3oEsMDhU4JYEgUbcV1E3ssVOWJ38nN8I0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(189930954265078)(35073007944872); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(6072148); SRVR:BY2PR05MB2184; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB2184; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 4:/7a2jOKGOHOv63cGXGKL6DkYtpk09Q9tq/IR9iuCV7+ojra7QN24hOxctgqXxFUNMgskAjh0Wui4ZlSNjy6AAP8wXM8b3Gj1Ozs1BEwdhNDRCqb5+GxAR0H4CY5WgurwV0475kUMRMxD0ipyfbgGRv5M4y/u9zMhjQvuIEeeF90Dj842VKjv+N7/HkHsK/X2UwGkx+GCyg/weyTR6lPijKrbebYmpE++nR+H703IerDwIAC/8cU2nHUs1wMMtlGvgqUwyJLXXoHcwPV89ZI5qsrPJ6DFFf+IZKfyFOFSSp/MmxqyFhAR7NJjF5YFX+bMU1bZFVIWwCrcYBd6YEZLXWTRm93j/R4RZhBXrs8/QoyBHNKOPQWHiIB+S9167NQRH9axFoTSkcljdtUU/J7J6ugp0xo1DLcPE8XVCy+EBFt/8DouD6o4XVHmLmvgMXxQGnWucvEYUgNAONJ/FuY7NnPTdZqFxE/l3il9+vaA2YBduTGcopnPeMBhvYnuGCJ7XMa+EdfxmxFMmWevsLs4f6RNfUb0VQ1fBHnqWsNM2eyN5ispzo1c7PEb2xNbriHxVujm6YN6VDaVww5w+FxyzCOjTuWZLhBSDQ/XCbEp+x3BtJzoUZBT8NUWssLh7Y3KxSIifdFCrx41/1kQqhux/FXMuNh7F6hxGtmi3wu8aycJy/PNbA1NZeWLVfDgiKtkxlCIUPV6/ha6rt5JNcNnfQH8zACR9qDJm5+kyW3XO0DMqYOE/Ropj6zYSSQcJp9hsiqT/j5hpXyi9nAYGQ2payovJOSfIG5C0uLKQeDTMY36xGWLSlxQSETlg8ROMB5Xo1c2G42CX4e8d6p2gjyag6loGdAu6lsqDpTrwwWP7pA2qHf96cFlCmiO0li+Q7k6 X-Forefront-PRVS: 029651C7A1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39860400002)(39450400003)(39840400002)(39400400002)(39410400002)(39850400002)(24454002)(377454003)(76176999)(7736002)(2906002)(512874002)(54356999)(50986999)(229853002)(6666003)(2950100002)(81166006)(8676002)(31686004)(36756003)(42186005)(83506001)(5660300001)(90366009)(31696002)(4326008)(6246003)(33646002)(189998001)(77096006)(2201001)(6486002)(86362001)(230783001)(84326002)(4001350100001)(478600001)(6116002)(3846002)(54896002)(790700001)(2501003)(3260700006)(38730400002)(64126003)(53546009)(53936002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2184; H:[172.29.35.213]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB2184; 23:nERmTBuTJnDlMMFMGZFDOhkICKUyIlIpzToliNS80?= =?us-ascii?Q?EDGvGo3YIZdEU9tSPgdLR9rlqopXoDnCvSt5/pVlmVr9F7jyJd3SSR9P6YXK?= =?us-ascii?Q?iW34CeElpr9em5q/UeiYDW0JzKBP4oqE/sIUsegvUssMvD+L25UK40gL7x4A?= =?us-ascii?Q?7Rmt5e6l9Lo1EXX74hRFcKGyeVrCE/uQp7YyffhyqJr288cyLo5DyeroPA2y?= =?us-ascii?Q?jNaoH9Z/M9U2WKwXQ7N0BquBLxds8mNIPsUMX03rsBHpH36nNOyLpLzWkDqg?= =?us-ascii?Q?Zzjp/qYVpVKDBEzSSQewv3vsXSWUqaf0/YfcXBia3y7x7CkeIHxGy4mkWMM5?= =?us-ascii?Q?Ffk1RYdaz3bb4c7BFwQc5QKPu4sZ0VxANkRMWEiIvrAzBUlkV5eRLy8XBS9n?= =?us-ascii?Q?hXiKyw69OH6OEFT6bUmMGbaBcv/UdV1L8HpJoCHAxhAGci94ySnZ4hypnglz?= =?us-ascii?Q?+QeFbhXXNQ0N6UVH+9Ng8YI+DyOZPkGMygaxOLnE4vZ92avNUvuy4mC5W3LD?= =?us-ascii?Q?nXaJnRvoaMz+alxzsf7jSDieliHdyYb3sIF3hjSb1/HdvDI6X2l4D03vnM45?= =?us-ascii?Q?Cxz85acY/p6bxmRkjND0pIaYuAdMxUiPXLq87T3BPYdlJ1E3+Q/G3UMts7MF?= =?us-ascii?Q?+kF6bxeqtS6R8GIg/IJC+wtDtqXgi+QoBf6mfsNcn3wyZ/yqkS2LPNGtr8A9?= =?us-ascii?Q?DxLkNnUVT/xcUU+IKGbZnBMp7Xrvtk6lWLaf/XppVFXqaHfqABAUtQbWEkKe?= =?us-ascii?Q?W3Rsrp2yg6/wP2CeYzw1yE1MwMLPXzGNPEsPzd5gU6qVl40REOJ73gygCfOo?= =?us-ascii?Q?9o7QMqWKttEX0Ala0cdcBGSV1nRrIZ4AZ+cLf0aqfbddaoDmWrX1w3HcfJni?= =?us-ascii?Q?pqIHGmMsEWYDXYgic9CSTUvPhwyJGL2HE4RJczql7d3SEOFp3yMAM3eBXTXV?= =?us-ascii?Q?+PAbcXg64R7bN/4A5co+FHRdzM/xXbz/N1mKf3T2xiw2LilmyWK/9pcQpVTG?= =?us-ascii?Q?Dtp4VBaznHSzxE0/T3SH9bO1T1f3yoOyMqVagjJ8GeLZnzSVTloC0MuMYUdx?= =?us-ascii?Q?59GCyzEDx+pAZezRzieMCSEcgrao6sM2BQ/WZa1PSi4wDQOTwS+ob38ziGOx?= =?us-ascii?Q?oAldVKMD0v2w+qZQCOgGFRuQPpTu4Hf1TbGBivCo3cQWoh9WTPnUswwSohnK?= =?us-ascii?Q?EiKMXIfsWmXWaAYw++EokZCQoVhZrvjQQmbZ8bipI9UBXYv1/07WJJxoNkGY?= =?us-ascii?Q?Hr5zWIoy+As1IBfrQEtc2h85CPhi3QFSVso3Kc55pObHvG582MNblv6a2poo?= =?us-ascii?B?dz09?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 6:/JA2bKGsTINw7yvBXPvQK2fBDQNSnGwcTxUJ2vVxWaUmeUq/WaVIrzaFPgg7q9tcyeGzpWxNeeFooUoceYfUBmVqiVx3zJAC4NvcVr3hlN99Nw+kwscZAEAJ6wK3ezRLbfbiQmXonQGsC9SFE+pIwWaN4ejUonTq6s4wPva+Otu6TP0g9D+3QyqHd1ADuAjVxlRjJ6HljLmSdbLp8j6OZrQrsnOkcPMxe98moolBE7rAwThNuZ//OB5VmJu6bLv8+jPEoHVdQVRaDA+0km9tpLJsFGGl+tI4MMMGV+y0gkx+fPV+85gEa+oQ7ylpqnddqvB72nXzxrLuNEwrK3SKll0nYK7w3/yc/srScQjzR4GQajg7VXSmy8FoqbaDxPl0cHczIIo9UP38P+3I2oZhXJlw1nC0D71IAY5VOSWrxn3b+3NfCkY9ifLjixTnMGxlmxW7O5yAg8SOOZuUgJkm77nYa2qIDcIIchUGXC6AmNVjIkAvjAmKijzI9KeDtC+NRvUbjfo8XhGSOUEndnKAbSK9XDz2d7x5nNJpNvFZPR4=; 5:GTydr7fEuLR1PA9xmkH/3DwX3Ze4q5ho/xTDBNdso+EEb+lqTOZHS55o67Etfo82mQKXMbX0lqctY5Ahp99vuoakxf2kk0qroV7+S03lBcKYys+jzUilWvW5gMrk8AmRdnGU+cpiRO1OyGK9gjnkDA==; 24:GrRHKc64CQxerTjR6pgTfZayaYXrDHwolQXAqnDwJkUYoSKevk0pSfqIttFMi6Z7nw8C/+9CRzcbJZCaddG8pO0I0X9xiZfFnT8qA0LxoPQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2184; 7:vPo5+KtZO2PWDVDugwWkpYSct84i/hGlm5Zo90MnkwwBBkTF9AOqVLnEnQNV9oHdo80EAmn+Ka5d8a+I1in3aTYEyVfcWZOZsuaBlUVHxCvnUrGLWscXXOk45CX5QGjz70/JJoiNkZ5Uhw8hFvAwtmC4Xtxv8ADHSoJjreZ/2cKqYLUqIfuNnng3zo6I38Xq7TYPBDbdx9SIbO85+UsuPZRdBl7NJRjb40y5/XPwx2HTh8sHpoOotY/gnO1qyL7fpAaJZsvLY9nWHUgAYkIU6lsP3/WRgaSqHRJAKqZnhBxZD0e1irbd5b5vohF4CUqPDdqKzKboyS+hEoIVgkU/5g== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 May 2017 18:23:07.4167 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2184 Archived-At: Subject: Re: [mpls] Routing directorate review of draft-ietf-mpls-rfc3107-bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:25:14 -0000 --------------B904B5417489A850A8D161CD Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Thanks for your review! On 4/27/2017 9:03 AM, Jonathan Hardwick wrote: > > I also spotted a few nits that should be fixed at some point before > publication. > I have fixed the nits. > Comments and Questions > > 1) In section 2.1 it says: > > “ If the Multiple Labels Capability for a given AFI/SAFI had been > > exchanged on the failed session, but is not exchanged on the > > restarted session, then any prefixes advertised in that AFI/SAFI with > > multiple labels MUST be explicitly withdrawn.” > > If I have understood this correctly, it requires a speaker to withdraw > NLRI that it sent on the previous session but that it has not sent on > the restarted session (because the negotiated session capabilities > changed). > > (a) Why does it need to do that – isn’t the NLRI implicitly withdrawn > when the EOR marker is sent? > The theory here is that the label stack in the stale routes is known to be invalid, so you really don't want your peer to hold on to them until EOR is received. > (b) This seems to contradict section 2.4 which says “Note that > label/prefix bindings that were not advertised on the given session > cannot be withdrawn by this method.” > I added the following text to section 2.4 right after the quoted sentence: (However, if the bindings were advertised on a previous session with the same peer, and the current session is the result of a "graceful restart" ([RFC4724]) of the previous session, then this withdrawal method may be used.) > > 2) In section 2.1 it says: > > “A BGP speaker SHOULD NOT send an UPDATE that binds more labels to a > given prefix than its peer is capable of receiving” – why isn’t that > MUST NOT? > Section 2.1 also requires the receiving speaker to apply "treat-as-withdraw" to such updates, which does imply that the sending speaker must not send them. So I've changed "SHOULD NOT" to "MUST NOT". > 3) In section 2.4 it says: > > “To do so, it may send a BGP UPDATE message with an MP_UNREACH_NLRI > attribute.” > > Should that be “it MUST send”? > I think the non-normative (non-RFC2119) language is fine here. > 4) In section 5: although some implementations treat SAFI 1 and SAFI 4 > routes as comparable, I believe that they should always be treated as > independent, in the following sense: > > Suppose a speaker S1 sends a SAFI 1 route and then a SAFI 4 route to > the same prefix P. The SAFI 4 route MUST NOT be treated by the > receiving speaker as an implicit withdraw of the SAFI 1 route. If S1 > subsequently sends an explicit withdraw of the SAFI 4 route, this MUST > NOT implicitly withdraw the SAFI 1 route, and vice versa. > > Am I correct? I have seen implementations that violate this so I > think it is worth spelling out somewhere in this section. > From Section 1: This document also addresses the issue of the how UPDATEs that bind labels to a given prefix interact with UPDATEs that advertise paths to that prefix but do not bind labels to it. However, for backwards compatibility, it declares most of these interactions to be matters of local policy. Different deployed implementations have different behavior, and I think it is better to advance the document as is rather than derail it with the inevitable food fight that would occur if we wanted to try to get the IETF to say which implementation is better than which other implementation. The deployed implementations have been around for many years, and people seem to have adapted to the differences. > 5) In section 7 it says: > > “ If a BGP implementation, not conformant with the current document, > > encodes multiple labels in the NLRI but has not sent and received the > > "Multiple Labels" Capability, a BGP implementation that does conform > > with the current document will likely reset the BGP session.” > > Wouldn’t that prevent incremental deployment of this RFC into a > network that is initially composed of such implementations? Because > it seems to require that both ends of each BGP session must be > upgraded simultaneously, or else the BGP sessions will all reset. > This issue was discussed at great length when the draft was first submitted. The vast majority of deployments do not check the S bit. That is, the de facto standard is to assume that a received update has only one label. If any existing deployment were transmitting updates with multiple labels encoded into the NLRI, it would already be causing BGP session resets. (Even iff this were a real problem, it wouldn't require both ends of a session to be upgraded simultaneously. It would just require one end to have a knob allowing it to accept both old and new behavior from its peer, and a knob telling it whether to use old or new behavior when sending to its peer. But since the defacto standard doesn't use multiple labels, I don't think we have to worry much about this.) --------------B904B5417489A850A8D161CD Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Thanks for your review!


On 4/27/2017 9:03 AM, Jonathan Hardwick wrote:

I also spotted a few nits that should be fixed at some point before publication.


I have fixed the nits.

 

Comments and Questions

 

1) In section 2.1 it says:

“   If the Multiple Labels Capability for a given AFI/SAFI had been

   exchanged on the failed session, but is not exchanged on the

   restarted session, then any prefixes advertised in that AFI/SAFI with

   multiple labels MUST be explicitly withdrawn.”

 

If I have understood this correctly, it requires a speaker to withdraw NLRI that it sent on the previous session but that it has not sent on the restarted session (because the negotiated session capabilities changed).

(a) Why does it need to do that – isn’t the NLRI implicitly withdrawn when the EOR marker is sent?


The theory here is that the label stack in the stale routes is known to be invalid, so you really don't want your peer to hold on to them until EOR is received.

(b) This seems to contradict section 2.4 which says “Note that label/prefix bindings that were not advertised on the given session cannot be withdrawn by this method.”


I added the following text to section 2.4 right after the quoted sentence:
 (However, if the bindings were advertised on a previous session with the same peer, and the current session is the result of a "graceful restart" ([RFC4724]) of the previous session, then this withdrawal method may be used.)


2) In section 2.1 it says:

“A BGP speaker SHOULD NOT send an UPDATE that binds more labels to a given prefix than its peer is capable of receiving” – why isn’t that MUST NOT?


Section 2.1 also requires the receiving speaker to apply "treat-as-withdraw" to such updates, which does imply that the sending speaker must not send them.  So I've changed "SHOULD NOT" to "MUST NOT". 

 

3) In section 2.4 it says:

“To do so, it may send a BGP UPDATE message with an MP_UNREACH_NLRI attribute.”

Should that be “it MUST send”?


I think the non-normative (non-RFC2119) language is fine here. 

 

 

4) In section 5: although some implementations treat SAFI 1 and SAFI 4 routes as comparable, I believe that they should always be treated as independent, in the following sense:

Suppose a speaker S1 sends a SAFI 1 route and then a SAFI 4 route to the same prefix P.  The SAFI 4 route MUST NOT be treated by the receiving speaker as an implicit withdraw of the SAFI 1 route.  If S1 subsequently sends an explicit withdraw of the SAFI 4 route, this MUST NOT implicitly withdraw the SAFI 1 route, and vice versa.

Am I correct?  I have seen implementations that violate this so I think it is worth spelling out somewhere in this section.


From Section 1:
This document also addresses the issue of the how UPDATEs that bind labels to a given prefix interact with UPDATEs that advertise paths to that prefix but do not bind labels to it.  However, for backwards compatibility, it declares most of these interactions to be matters of local policy.
Different deployed implementations have different behavior, and I think it is better to advance the document as is rather than derail it with the inevitable food fight that would occur if we wanted to try to get the IETF to say which implementation is better than which other implementation.  The deployed implementations have been around for many years, and people seem to have adapted to the differences.

 

 

5) In section 7 it says:

“ If a BGP implementation, not conformant with the current document,

encodes multiple labels in the NLRI but has not sent and received the

"Multiple Labels" Capability, a BGP implementation that does conform

with the current document will likely reset the BGP session.”

 

Wouldn’t that prevent incremental deployment of this RFC into a network that is initially composed of such implementations?  Because it seems to require that both ends of each BGP session must be upgraded simultaneously, or else the BGP sessions will all reset.

 


This issue was discussed at great length when the draft was first submitted.  The vast majority of deployments do not check the S bit.  That is, the de facto standard is to assume that a received update has only one label.   If any existing deployment were transmitting updates with multiple labels encoded into the NLRI, it would already be causing BGP session resets.

(Even iff this were a real problem, it wouldn't require both ends of a session to be upgraded simultaneously.  It would just require one end to have a knob allowing it to accept both old and new behavior from its peer, and a knob telling it whether to use old or new behavior when sending to its peer.  But since the defacto standard doesn't use multiple labels, I don't think we have to worry much about this.)

--------------B904B5417489A850A8D161CD-- From nobody Thu May 4 06:19:26 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92341127B52 for ; Thu, 4 May 2017 06:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo6lgTs1luRd for ; Thu, 4 May 2017 06:19:22 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 21C34127180 for ; Thu, 4 May 2017 06:19:22 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id w64so18324346wma.0 for ; Thu, 04 May 2017 06:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=TUdn8KsmrgF7/y7GTlT6j8+xXAgH7XHJsHqjfl7msgM=; b=akfAOG/DqN/T9EfcRwzkGYg88mveY+yrBlwyV6GOVHu5k7rJIHxkgNBfx948rnY2u7 j3RHSQstSv6BVk3MAWkXpHwo7szuNf9Hojqp7+SmjcYt2LrvT+RN9QAg8loNDmXfSn2m PbLuAvlJJ6VYgSumDc3xQtV8lYFY9aSRc2xswiU+xFAw3prG5liU0Dq4RpV9vWHEBtqP ZshhRzI+tnH6oTtdcvtxHY9vrycX6tlf4bBrDIl9IrmaWWkqwjETubJCj/61Pvb56DWz Czf4PMyNU1dyNrf3Pbat5adlMoiKw37ODlQsTwBtty8SnOu8dFN3A7ZyKSoPgFVyq5FR TqIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=TUdn8KsmrgF7/y7GTlT6j8+xXAgH7XHJsHqjfl7msgM=; b=pYVcgqpJOszluJd36/IIst1bdecXP0s9E7PIAQhqGFCvr3MFYclp4woQgNoXsW7cnE TxZ5w8r3+ONIobpowNq2wMvqj+XlI0Y9NhrBCLpGkKV+kYMFxCwgFHeND0d+Ds2I3laz xtxRDoTQGQo/kpM0ei5N1NSvJkEnaypKICW328yjC+n6l5K7y9dXDfl8WklvKYdeJ8Va OlNiUgEwe6BE6ZVyjtwtSisQ+ZAwyvNXng7XeNSr9oqM2GEpsDFLtsXSyQk/TPB1FLuH sgHeCgDcWiBg4A5ZspsENAXMsogr5YxuO5aBWxQgk+UeTa+2KwK6aZo3AJjhhdzekUnG 3XKA== X-Gm-Message-State: AODbwcA4pcMrX1dyFzjLUwA7UsKsUE740o+HA7qYLGybTdrAW3orn40O dMF9TtvQQAlsCdZhftA= X-Received: by 10.28.234.84 with SMTP id i81mr1731331wmh.138.1493903959991; Thu, 04 May 2017 06:19:19 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id k18sm1588974wre.9.2017.05.04.06.19.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 May 2017 06:19:19 -0700 (PDT) To: Curtis Villamizar , mpls@ietf.org References: <20170428192655.C5C301293EE@ietfa.amsl.com> From: Stewart Bryant Message-ID: <93e688f5-0072-0853-337b-df9364b56f68@gmail.com> Date: Thu, 4 May 2017 14:19:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170428192655.C5C301293EE@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 13:19:25 -0000 On 28/04/2017 20:26, Curtis Villamizar wrote: > Loa, > > The document is coherent and possibly useful. The question of IPR > should be resolved before accepting this as a WG document. I will leave the IPR issue to the chairs. > > Briefly: > > 1. The document proposes a change to forwarding. Whenever a change > in forwarding is considered, there should be a very substantial > benefit and interoperability with older hardware should be > considered in the document. The important thing is that the change to forwarding is confined solely to the PEs that are using this function. There is no change to any of the P routers needed. Furthermore, in the application that triggered this work, pro-active packet loss measurement, the action required is to count the number of packets received on a label, and that is something that a lot of chips already do. In such a case the change is a technical change to the forwarding behaviour specifying an action that is already deployed. In other cases, where a net-processor is deployed, it is a case of vectoring from the LFIB to a different routine. Given that the additional functionality is needed by the PEs such a change is not unreasonable. > > 2. The document leaves open the question of dealing with ECMP in > section 4. The first option in section 4 is not viable. I do not understand why this is not viable, other than perhaps due to stack size limits. The EL solution requires support for EL along the LSP which may not be available. Indeed I am not sure how widely available it is. Thus I see option 1 as a method to be deployed in the absence of EL support. We can discuss whether this is listed first or second. > The > document should drop this and expand on the second "worthy of > consideration" solution, explaining how it will work in the same > level of detail as provided in 3.1, 3.2, and 3.3. Sure, that can be added. Adding it is fairly simple, although I do not see why that cannot wait until after adoption, since it is the duty of the editor to reflect the consensus of the WG. > > 3. In the VPN example a perceived advantage of MP2P LSP is lost. > With MP2P LSP, the number of application labels needed is the > number of VPN IDs. The number of labels needed becomes number > of VPN IDs times the number in ingress. If Section 3.3 is > supposed to address this, then this is not clear and therefore > could benefit by referring back to the example and stating that > the SFL could indicate source only and the application label > indicate VPN ID only. Sure we can text to address the scaling concern, and expand the processing text. Note that whether scaling is a concern or not will depend on how many VPNs need SFL actions, and on the chosen ECMP approach. > > More detail: > > Forwarding of labeled packets currently involves some special > processing of labels 0-15 and some form of lookup in a table or TCAM > or other structure with the lookup resolving to a set of operations. > At mimimum these operation are SWAP and forward to an egress > optionally after considering ECMP (EL or rest of stack), POP and look > at next label (or assume IP payload if no next label). Forwarding > hardware currently need not support a POP and look for IP payload. > That operation is only required of the IPv4 Explicit NULL Label and > IPv6 Explicit NULL Label. I do not see what in the text causes you to raise this point. An SL has the same semantics as the label it replaces plus a side-effect. If the original label implied IP, so will the SL. As I said earlier, if the side-effect is other than increment a counter (which is common anyway) then the side effect is new functionality which needs implementing anyway. > Second, both Explicit NULL labels in > RFC3032 are required to be at the bottom of stack in RFC3032 with this > restriction removed in RFC4182 for proper operation of the pipe model > when not using an ordinary label POP at egress. > > The changes to forwarding are: > > 1. Processing of an ordinary label (label not in the 0-15 range) > must be able to POP and look at the IPv4 or IPv6 payload to > conform to section 3.2 of this draft. Currently this processing > can be fixed to label values 0 and 2 respectively. > > 2. Processing of an ordinary label taking on the function of an > explicit NULL and processing of an explicit NULL label must be > capable of handling ELI and EL below the SFL or Explicit NULL > and then take the same action as would be taken for Explicit > NULL after the ELI and EL POP. This would be needed to support > pipe model as described in RFC4182 and not change the > penultimate LSR to SWAP a lable for SFL or Explicit NULL and > remove ELI and EL from underneath. > > I'm assuming that SFL would not map to special labels other than > Explicit NULL but such a statement should be made explicit. Although > if applied to RFC 6374 then SFL might also map to GAL. I had been assuming that if you wanted a GAL you would put it in there. I wonder if the EN equivalence is confusing and we should look at other equivalences. There are a number of alternative equivalence models we can look at that have the same properties: If you assume that the LSP label has already been popped (due to PHP) it the SFL could be considered as equivalent to a non-popped LSP label. Alternatively I suppose you could model the SFL as a VRF label with the lookup performed in the base topology. > If SFL can map > to other special labels, then those others from the set of 0-15 > including mapping to ESPL should be mentioned. We will put text in on the subject. > Each time a new > special label is defined there are complaints about changing > forwarding. If now any ordinary label can map to a specific set of > special labels, or worse to any special label, then this is a > substantial change in the definition of MPLS forwarding. That is not where I think this should go either. I think that it needs to behave exactly as MPLS normally behaves except for the agreed side effect in PEs configured to have the required behaviour. > > btw- In practice the IPv6 Explicit NULL is rarely if ever used but > instead POP of an ordinary label at BOS, label zero (IPv4 Explicit > NULL) at BOS, or lack of a label stack after PHP looks for the IP > version in the payload. Does any RFC say to do this (combine the > meaning of IPv4 Explicit NULL and IPv6 Explicit NULL and look at IP > version in the payload) or is this just common practice for almost 20 > years that escaped getting documented? I am not sure this impacts this draft. > > The second issue relates to ECMP. Section 4.1 item 1 suggests that > "The operator can elect to always run with the SFL in place". If the > value of SFL is different for data traffic and PM traffic, then the PM > would not take the same path. This would put each "flow" in a > multipoint to point LSP (ie: LDP) on a separate path which for ECMP is > not an issue. I would expect that the instrumentation packet go with the same SFL it is collecting results for. > > If the only purpose of the SFL was maintain separately counters for > specific multipoint to point LSP ingress then lack of SFL for other > ingress has no effect. In this case the "solution" described in > Section 4.1 item 1 is a NOOP. > > If the purpose is to also provide separate PM for specific (or all) > multipoint to point LSP ingress or provide separate counters for PM > for a point to point LSP, then the "solution" described in Section 4.1 > item 1 fails. > > Section 4.1 item 1 therefore needs to be removed. I don't think so. If you instrument one flow on a long term basis and leave the SFL in place the behaviour is always the same. How does that fail? > > The implications of Section 4.1 item 2 need to be better explored. > The section as-is constitutes a "punt" on the problem of ECMP with SFL > used for PM. A diagram of each case in Section 3 with ELI and EL can > be added in Section 4 or the optional placement of ELI and EL. The > behaviour when ELI and EL are present can then be described in Section > 4 with penultimate LSR behaviour in addition to egress LSR behaviour > described for both PHP and non-PHP case. That text can be expanded in a future version. > Nits: > > In "Abstract" the phrase "on the on the" should be "on the". Ack > > In Section 2 "defined to be a label" is awkward. s/to be/as/ > > An alternate: > > An alternate to the proposal here would be to make something like what > is in Section 3.3 the only case, but where a ESPL range is used. This > would add egress processing without stepping on ECMP since SPL and > ESPL are excluded from ECMP according to RFC 7274. An interesting idea, but I am not sure how widely EL is supported, and it has the disadvantage that it needs new dataplane changes to process the EL, whereas the advantage of the proposal in the text is that for the common VPN and PW case the existing h/w works out of the box in a lot of cases. > An ESPL with a few > top bits always set and less than 20 bits of range could be considered > (for example XL + 1111xxxxxxxxxxxxxxxx for 16 bits of range and 1/16 > of the ESPL space in RFC 7274). This range would be defined such that > it is application specific, is added at ingress, completely ingnored > along the way and provides the some egress specific functionality. Not only is that new functionality in the core (ignoring a label following and EL) but it then remains unclear how ECMP then works. On the other hand we could (which is what I thought you meant) assign a meaning to the EL value agreed between PEs and have the load balancing use the EL value and have the SL behaviour be based on the SL value. However this is a forwarding change and an ECMP path change, and can only be applied once whereas the proposed design could have multiple SFLs in the stack, say to monitor an LSP and a PW. > Most implementations that support RFC 6790 are likely to also support > the prohibition on using ESPL for ECMP since the documents were in the > MPLS WG at about the same time, though publication of the latter > lagged about a year. This alternative also solves any scalability > problem associated with combining source and application label > functionality into one label. It does add two labels to the stack > depth but newer hardware should no longer be constrained to very > shallow stack depth. This alternate also might be an even more > attractive option if IPR becomes an issue with the current proposal. I have no idea how to respond to this given the IETF rules that prohibit discussion of IPR terms. > > Summary: > > well written document. not a great design. multiple problems as > defined. possible IPR issue. I agree with the first :) I disagree with the second :( Working through problems is part of the WG phase of development, and as far as I can see the alternative you propose has problems. What I do know is that the underlying problem we seek to solve is important and as far as I can tell this is the best proposal on the table. You keep saying IPR issues, but it is a deficiency of the IETF rules of conduct that we cannot have a detailed discussion. The chairs and or ADs need to provide guidance on how to respond to this. - Stewart > > consider alternative. any alternative but I provided one. feel free > to use the idea. :-) > > Curtis > > > In message <5774d63c-6980-103e-0b3f-a277db822462@pi.nu> > Loa Andersson writes: >> Huub, Andy, Curtis and Kamran, >> >> You have been selected as MPLS-RT reviewers for >> draft-bryant-mpls-sfl-framework-04 >> . >> > [ ...] > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu May 4 06:23:13 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0625B12762F; Thu, 4 May 2017 06:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 5oS-HbvASZZ7; Thu, 4 May 2017 06:23:10 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 64903126C0F; Thu, 4 May 2017 06:23:10 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id z52so7791502wrc.2; Thu, 04 May 2017 06:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=WUeuHACSSJGTssF/Oc8Gz4f78KJjRAXRoFon2ECXH9Y=; b=FQ2rX71f2dJ2ajkSb/WlSbr/YN86DgmlijdxyDw5svWF/XRLMBBcYINKyxM7xWuOZQ ZPqCZX+CUIPsNIk0yzjIxi+iOX9y4NwzAFPeshE9ZjCgWGp+Svx/Iz6DI9ugCKmzpvw9 +AD8to3mrzjgocHt6kWr9sV1RYMdZ4EOmeRGXRIH5fo4Dw3D0jFuPLWOBFP5p7Ud4NdO zz5pZe8aoiSx+RZCG2LYeNErPCcfYGp4e0NOzqO/W1sSztusD/ebaSq+T7TP6Yw/xZPH 4vvrLQkDEE08L0gdE9pns0pqyKOhNVbR2Kg3X7C+Vpu2VDewRlnKU6UNDyPlfOjH46G5 kK8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=WUeuHACSSJGTssF/Oc8Gz4f78KJjRAXRoFon2ECXH9Y=; b=ddwmlGWwhiKzAuPv8f0NEhs3GpKd9MrGleFoBACyLuIN9MmW8RYmLfpsS+iy5VcNuH rcBhsU8DKgN0V/JlXZH2ozoyDsv7MNS6zSy7684sSORNP7r6ys23n/Z3g/8Phs3J7bTh JLETZ+eTEIhd4sfjkXMtJxNp473O5cu6VnF5sTdM1f82+vE6CwumDFuWusd94s1NsbIc JfEevv8qqUd3jZsPMJuZjOGA7Nzr9RtUD3msPJwo1WVObn/ZWhLrwWv4Xi0vy/TZTjFf P46PlTJjBrODIEF7ao8RMRsQGee+etugiK4bm6mGgdAajq+Uf+E1mMYKTHp45G63hdYL ai6A== X-Gm-Message-State: AN3rC/7uU+YZwy+7I1eXkU/KnNOMw96y0rgd7NZIQzCJqUyVEcfslxUn s9YJj9tQ2sdV4RIPOsI= X-Received: by 10.223.142.35 with SMTP id n32mr33113897wrb.131.1493904188719; Thu, 04 May 2017 06:23:08 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id w136sm1310313wmd.0.2017.05.04.06.23.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 May 2017 06:23:08 -0700 (PDT) To: "Andrew G. Malis" , "mpls@ietf.org" , draft-bryant-mpls-sfl-framework@ietf.org References: Cc: mpls-chairs From: Stewart Bryant Message-ID: <959ec149-92e0-c58e-2ca4-45e172ee0d8d@gmail.com> Date: Thu, 4 May 2017 14:22:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 13:23:12 -0000 On 27/04/2017 15:13, Andrew G. Malis wrote: > Authors and WG, > > I have been selected as a pre-adoption MPLS Review Team reviewer for > draft-bryant-mpls-sfl-framework. > > While not really necessary for WG adoption, I note that idnits runs clean. > > The draft is short and straightforward. My only comment on the content > is that it may be useful to note that in some router implementations, > the use of a synonymous label may, depending on triggered action, > force a packet from an internal fast path to an internal slow path. Yes, but you would know that was the case and might refuse the SL setup request. > In such cases, it may be useful to limit the use of a synonymous label > to a fraction of those on a particular LSP or PW. However, as noted in > section 4, this may lead to ECMP interactions unless an Entropy Label > is also used. It may also lead to out-of-order packets on a PW. In the PW (or VPN) case the text in section 4 addresses the problem. > > Regardless of this comment, I feel that this draft is ready for WG > adoption, and does not need to be updated prior to adoption. > Thank you. Stewart > Cheers, > Andy > From nobody Thu May 4 10:37:41 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4B7129B66; Thu, 4 May 2017 10:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4IJkG1dvHFn; Thu, 4 May 2017 10:37:36 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0118.outbound.protection.outlook.com [104.47.34.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 866CE129B2E; Thu, 4 May 2017 10:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rD3Injx8f7qmDia8xsf0R6dSjaKKl9xEYk8cgfNDJTk=; b=QuC1ztuaFolXIST+gpINVeC9tSV1Gnul2KZmiGjteTY9bxnbh+zjD8Fk64HYeFdrQzJGIwMf1/a6m9vNq5dzBYB4uZcVY1cNmMr7+iZiJyr73eVj+IqICEtUhB1MZ5z964CP9vhWCBYgDmiNsapt75lXW/o2/9x9rUKMfAnYzqw= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1912.namprd02.prod.outlook.com (10.163.75.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Thu, 4 May 2017 17:37:34 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.1075.010; Thu, 4 May 2017 17:37:34 +0000 From: Jonathan Hardwick To: Eric C Rosen , "draft-ietf-mpls-rfc3107bis@ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" CC: "rtg-dir@ietf.org" Thread-Topic: Routing directorate review of draft-ietf-mpls-rfc3107-bis Thread-Index: AdK/UgoPnMchP/X0SOKBF6US5Kr0PwE6EMqAAC5SQVA= Date: Thu, 4 May 2017 17:37:34 +0000 Message-ID: References: <9913c8e1-50fe-34c1-a8d5-2d5efefafc5e@juniper.net> In-Reply-To: <9913c8e1-50fe-34c1-a8d5-2d5efefafc5e@juniper.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none; juniper.net; dmarc=none action=none header.from=metaswitch.com; x-originating-ip: [86.175.167.173] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1912; 7:nTxF7YELHQXk3O3PWOLT36Y9IfxTa1mFpgwWSpcohue2eH2jIo4xS5+u5qW60nr88pf4yKcAsAzF92/yCtrPsL3qOABRVABbkicMR6opwdCa7/XwoWSW/I2EEWStK+TI2Bdmaxpsf+1M/HjbzLDgm5Tj9DgU5kv+nG881eNpId+3P32KP4826iD/iytMWsxKmFRhubo2IZFFwrFEv8Axz2Ujk9xscgTz/Zd+QzzeBBCHmJ95OtLAmmwoU/GnXfGo26zZKRhV54bn6CnbX9EejKQR8BFIB1D9yzh8Us2f/gpdfZpDYgejdNbSUpM6ETxe30wFAfY2oIAL8OHxXSW/LA== x-ms-office365-filtering-correlation-id: a880813f-5e01-4382-9445-08d493143fe6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BY2PR0201MB1912; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(35073007944872)(138986009662008)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148); SRVR:BY2PR0201MB1912; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1912; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39400400002)(39410400002)(39450400003)(24454002)(51444003)(377454003)(51914003)(2906002)(478600001)(189998001)(7696004)(76176999)(50986999)(54356999)(229853002)(3280700002)(2950100002)(3660700001)(230783001)(74316002)(5660300001)(2900100001)(6436002)(77096006)(6506006)(122556002)(33656002)(81166006)(8676002)(66066001)(8936002)(9686003)(54896002)(6306002)(55016002)(8666007)(99286003)(38730400002)(7736002)(53936002)(25786009)(53546009)(86362001)(2201001)(2501003)(3846002)(790700001)(102836003)(6116002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1912; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB19109734BAE5CFFB0E7DD70C84EA0BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 17:37:34.3124 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1912 Archived-At: Subject: Re: [mpls] Routing directorate review of draft-ietf-mpls-rfc3107-bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 17:37:40 -0000 --_000_BY2PR0201MB19109734BAE5CFFB0E7DD70C84EA0BY2PR0201MB1910_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJpYw0KDQpUaGFua3MgZm9yIHRoZSByZXBsaWVzIOKAkyBwbGVhc2Ugc2VlIFtKb25dIGlu bGluZS4NCg0KQ2hlZXJzDQpKb24NCg0KRnJvbTogRXJpYyBDIFJvc2VuIFttYWlsdG86ZXJvc2Vu QGp1bmlwZXIubmV0XQ0KU2VudDogMDMgTWF5IDIwMTcgMTk6MjMNClRvOiBKb25hdGhhbiBIYXJk d2ljayA8Sm9uYXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5jb20+OyBkcmFmdC1pZXRmLW1wbHMt cmZjMzEwN2Jpc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcN CkNjOiBydGctZGlyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogUm91dGluZyBkaXJlY3RvcmF0ZSBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1tcGxzLXJmYzMxMDctYmlzDQoNCg0KVGhhbmtzIGZvciB5b3Vy IHJldmlldyENCg0KT24gNC8yNy8yMDE3IDk6MDMgQU0sIEpvbmF0aGFuIEhhcmR3aWNrIHdyb3Rl Og0KSSBhbHNvIHNwb3R0ZWQgYSBmZXcgbml0cyB0aGF0IHNob3VsZCBiZSBmaXhlZCBhdCBzb21l IHBvaW50IGJlZm9yZSBwdWJsaWNhdGlvbi4NCg0KSSBoYXZlIGZpeGVkIHRoZSBuaXRzLg0KDQoN Cg0KQ29tbWVudHMgYW5kIFF1ZXN0aW9ucw0KDQoxKSBJbiBzZWN0aW9uIDIuMSBpdCBzYXlzOg0K 4oCcICAgSWYgdGhlIE11bHRpcGxlIExhYmVscyBDYXBhYmlsaXR5IGZvciBhIGdpdmVuIEFGSS9T QUZJIGhhZCBiZWVuDQogICBleGNoYW5nZWQgb24gdGhlIGZhaWxlZCBzZXNzaW9uLCBidXQgaXMg bm90IGV4Y2hhbmdlZCBvbiB0aGUNCiAgIHJlc3RhcnRlZCBzZXNzaW9uLCB0aGVuIGFueSBwcmVm aXhlcyBhZHZlcnRpc2VkIGluIHRoYXQgQUZJL1NBRkkgd2l0aA0KICAgbXVsdGlwbGUgbGFiZWxz IE1VU1QgYmUgZXhwbGljaXRseSB3aXRoZHJhd24u4oCdDQoNCklmIEkgaGF2ZSB1bmRlcnN0b29k IHRoaXMgY29ycmVjdGx5LCBpdCByZXF1aXJlcyBhIHNwZWFrZXIgdG8gd2l0aGRyYXcgTkxSSSB0 aGF0IGl0IHNlbnQgb24gdGhlIHByZXZpb3VzIHNlc3Npb24gYnV0IHRoYXQgaXQgaGFzIG5vdCBz ZW50IG9uIHRoZSByZXN0YXJ0ZWQgc2Vzc2lvbiAoYmVjYXVzZSB0aGUgbmVnb3RpYXRlZCBzZXNz aW9uIGNhcGFiaWxpdGllcyBjaGFuZ2VkKS4NCihhKSBXaHkgZG9lcyBpdCBuZWVkIHRvIGRvIHRo YXQg4oCTIGlzbuKAmXQgdGhlIE5MUkkgaW1wbGljaXRseSB3aXRoZHJhd24gd2hlbiB0aGUgRU9S IG1hcmtlciBpcyBzZW50Pw0KDQpUaGUgdGhlb3J5IGhlcmUgaXMgdGhhdCB0aGUgbGFiZWwgc3Rh Y2sgaW4gdGhlIHN0YWxlIHJvdXRlcyBpcyBrbm93biB0byBiZSBpbnZhbGlkLCBzbyB5b3UgcmVh bGx5IGRvbid0IHdhbnQgeW91ciBwZWVyIHRvIGhvbGQgb24gdG8gdGhlbSB1bnRpbCBFT1IgaXMg cmVjZWl2ZWQuDQoNCltKb25dIE9LLCB0aGF04oCZcyBmaW5lLg0KDQooYikgVGhpcyBzZWVtcyB0 byBjb250cmFkaWN0IHNlY3Rpb24gMi40IHdoaWNoIHNheXMg4oCcTm90ZSB0aGF0IGxhYmVsL3By ZWZpeCBiaW5kaW5ncyB0aGF0IHdlcmUgbm90IGFkdmVydGlzZWQgb24gdGhlIGdpdmVuIHNlc3Np b24gY2Fubm90IGJlIHdpdGhkcmF3biBieSB0aGlzIG1ldGhvZC7igJ0NCg0KSSBhZGRlZCB0aGUg Zm9sbG93aW5nIHRleHQgdG8gc2VjdGlvbiAyLjQgcmlnaHQgYWZ0ZXIgdGhlIHF1b3RlZCBzZW50 ZW5jZToNCiAoSG93ZXZlciwgaWYgdGhlIGJpbmRpbmdzIHdlcmUgYWR2ZXJ0aXNlZCBvbiBhIHBy ZXZpb3VzIHNlc3Npb24gd2l0aCB0aGUgc2FtZSBwZWVyLCBhbmQgdGhlIGN1cnJlbnQgc2Vzc2lv biBpcyB0aGUgcmVzdWx0IG9mIGEgImdyYWNlZnVsIHJlc3RhcnQiIChbUkZDNDcyNF0pIG9mIHRo ZSBwcmV2aW91cyBzZXNzaW9uLCB0aGVuIHRoaXMgd2l0aGRyYXdhbCBtZXRob2QgbWF5IGJlIHVz ZWQuKQ0KDQoNCjIpIEluIHNlY3Rpb24gMi4xIGl0IHNheXM6DQrigJxBIEJHUCBzcGVha2VyIFNI T1VMRCBOT1Qgc2VuZCBhbiBVUERBVEUgdGhhdCBiaW5kcyBtb3JlIGxhYmVscyB0byBhIGdpdmVu IHByZWZpeCB0aGFuIGl0cyBwZWVyIGlzIGNhcGFibGUgb2YgcmVjZWl2aW5n4oCdIOKAkyB3aHkg aXNu4oCZdCB0aGF0IE1VU1QgTk9UPw0KDQpTZWN0aW9uIDIuMSBhbHNvIHJlcXVpcmVzIHRoZSBy ZWNlaXZpbmcgc3BlYWtlciB0byBhcHBseSAidHJlYXQtYXMtd2l0aGRyYXciIHRvIHN1Y2ggdXBk YXRlcywgd2hpY2ggZG9lcyBpbXBseSB0aGF0IHRoZSBzZW5kaW5nIHNwZWFrZXIgbXVzdCBub3Qg c2VuZCB0aGVtLiAgU28gSSd2ZSBjaGFuZ2VkICJTSE9VTEQgTk9UIiB0byAiTVVTVCBOT1QiLg0K DQpbSm9uXSBUaGFua3MuICBOb3RlIHRoYXQgdGhlIHNhbWUgY2hhbmdlIGFsc28gYXBwbGllcyBp biBzZWN0aW9uIDMuMi4xDQoNCiAgIOKAnFNpbWlsYXJseSwgYSBnaXZlbiByb3V0ZSBTSE9VTEQg Tk9UIGJlDQogICBwcm9wYWdhdGVkIHRvIGEgZ2l2ZW4gcGVlciBpZiB0aGUgcm91dGUncyBOTFJJ IGhhcyBtb3JlIGxhYmVscyB0aGFuDQogICB0aGUgcGVlciBoYXMgYW5ub3VuY2Vk4oCdDQoNCuKA pmFuZCBhbHNvIGluIHNlY3Rpb24gMy4yLjINCg0K4oCcQSBCR1Agc3BlYWtlciBNVVNUIE5PVCBz ZW5kIG11bHRpcGxlDQoNCiAgIGxhYmVscyB0byBhIHBlZXIgd2l0aCB3aGljaCBpdCBoYXMgbm90 IGV4Y2hhbmdlZCB0aGUgIk11bHRpcGxlDQoNCiAgIExhYmVscyIgQ2FwYWJpbGl0eSwgYW5kIFNI T1VMRCBOT1Qgc2VuZCBtb3JlIGxhYmVscyB0byBhIGdpdmVuIHBlZXINCg0KICAgdGhhbiB0aGUg cGVlciBoYXMgYW5ub3VuY2Vk4oCdDQoNCg0KMykgSW4gc2VjdGlvbiAyLjQgaXQgc2F5czoNCuKA nFRvIGRvIHNvLCBpdCBtYXkgc2VuZCBhIEJHUCBVUERBVEUgbWVzc2FnZSB3aXRoIGFuIE1QX1VO UkVBQ0hfTkxSSSBhdHRyaWJ1dGUu4oCdDQpTaG91bGQgdGhhdCBiZSDigJxpdCBNVVNUIHNlbmTi gJ0/DQoNCkkgdGhpbmsgdGhlIG5vbi1ub3JtYXRpdmUgKG5vbi1SRkMyMTE5KSBsYW5ndWFnZSBp cyBmaW5lIGhlcmUuDQoNCltKb25dIEl0IGp1c3QgamFycmVkIHdpdGggbWUgYSBsaXR0bGUuICBJ 4oCZbSBub3QgZ29pbmcgdG8gZGlnIGluIG9uIHRoaXMgcG9pbnQsIGJ1dCBsZXQgbWUgZXhwbGFp biB3aGVyZSBJIHdhcyBjb21pbmcgZnJvbS4gIFdoZW4geW91IHNheSDigJxpdCBtYXkgc2VuZOKA nSB0aGUgd29yZCDigJxtYXnigJ0gbWFrZXMgaXQgc291bmQgbGlrZSBpdCBpcyBub3Qgb2JsaWdl ZCB0byBkbyBpdCB0aGlzIHdheS4gIEkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhbnkgb3RoZXIg d2F5IHRvIHdpdGhkcmF3IHRoZSByb3V0ZSAoc2hvcnQgb2YgY2xvc2luZyB0aGUgc2Vzc2lvbikg c28gSSB0aGluayB0aGF0IHdoYXQgeW91IGFyZSBkZXNjcmliaW5nIGlzIHRoZSBvYmxpZ2F0b3J5 IHdheSB0byB3aXRoZHJhdyB0aGUgcm91dGUuICBGb3IgdGhhdCByZWFzb24gSeKAmWQgcHJlZmVy IGVpdGhlciDigJxpdCBzZW5kc+KAnSBvciDigJxpdCBNVVNUIHNlbmTigJ0uDQoNCg0KNCkgSW4g c2VjdGlvbiA1OiBhbHRob3VnaCBzb21lIGltcGxlbWVudGF0aW9ucyB0cmVhdCBTQUZJIDEgYW5k IFNBRkkgNCByb3V0ZXMgYXMgY29tcGFyYWJsZSwgSSBiZWxpZXZlIHRoYXQgdGhleSBzaG91bGQg YWx3YXlzIGJlIHRyZWF0ZWQgYXMgaW5kZXBlbmRlbnQsIGluIHRoZSBmb2xsb3dpbmcgc2Vuc2U6 DQpTdXBwb3NlIGEgc3BlYWtlciBTMSBzZW5kcyBhIFNBRkkgMSByb3V0ZSBhbmQgdGhlbiBhIFNB RkkgNCByb3V0ZSB0byB0aGUgc2FtZSBwcmVmaXggUC4gIFRoZSBTQUZJIDQgcm91dGUgTVVTVCBO T1QgYmUgdHJlYXRlZCBieSB0aGUgcmVjZWl2aW5nIHNwZWFrZXIgYXMgYW4gaW1wbGljaXQgd2l0 aGRyYXcgb2YgdGhlIFNBRkkgMSByb3V0ZS4gIElmIFMxIHN1YnNlcXVlbnRseSBzZW5kcyBhbiBl eHBsaWNpdCB3aXRoZHJhdyBvZiB0aGUgU0FGSSA0IHJvdXRlLCB0aGlzIE1VU1QgTk9UIGltcGxp Y2l0bHkgd2l0aGRyYXcgdGhlIFNBRkkgMSByb3V0ZSwgYW5kIHZpY2UgdmVyc2EuDQpBbSBJIGNv cnJlY3Q/ICBJIGhhdmUgc2VlbiBpbXBsZW1lbnRhdGlvbnMgdGhhdCB2aW9sYXRlIHRoaXMgc28g SSB0aGluayBpdCBpcyB3b3J0aCBzcGVsbGluZyBvdXQgc29tZXdoZXJlIGluIHRoaXMgc2VjdGlv bi4NCg0KRnJvbSBTZWN0aW9uIDE6DQpUaGlzIGRvY3VtZW50IGFsc28gYWRkcmVzc2VzIHRoZSBp c3N1ZSBvZiB0aGUgaG93IFVQREFURXMgdGhhdCBiaW5kIGxhYmVscyB0byBhIGdpdmVuIHByZWZp eCBpbnRlcmFjdCB3aXRoIFVQREFURXMgdGhhdCBhZHZlcnRpc2UgcGF0aHMgdG8gdGhhdCBwcmVm aXggYnV0IGRvIG5vdCBiaW5kIGxhYmVscyB0byBpdC4gIEhvd2V2ZXIsIGZvciBiYWNrd2FyZHMg Y29tcGF0aWJpbGl0eSwgaXQgZGVjbGFyZXMgbW9zdCBvZiB0aGVzZSBpbnRlcmFjdGlvbnMgdG8g YmUgbWF0dGVycyBvZiBsb2NhbCBwb2xpY3kuDQpEaWZmZXJlbnQgZGVwbG95ZWQgaW1wbGVtZW50 YXRpb25zIGhhdmUgZGlmZmVyZW50IGJlaGF2aW9yLCBhbmQgSSB0aGluayBpdCBpcyBiZXR0ZXIg dG8gYWR2YW5jZSB0aGUgZG9jdW1lbnQgYXMgaXMgcmF0aGVyIHRoYW4gZGVyYWlsIGl0IHdpdGgg dGhlIGluZXZpdGFibGUgZm9vZCBmaWdodCB0aGF0IHdvdWxkIG9jY3VyIGlmIHdlIHdhbnRlZCB0 byB0cnkgdG8gZ2V0IHRoZSBJRVRGIHRvIHNheSB3aGljaCBpbXBsZW1lbnRhdGlvbiBpcyBiZXR0 ZXIgdGhhbiB3aGljaCBvdGhlciBpbXBsZW1lbnRhdGlvbi4gIFRoZSBkZXBsb3llZCBpbXBsZW1l bnRhdGlvbnMgaGF2ZSBiZWVuIGFyb3VuZCBmb3IgbWFueSB5ZWFycywgYW5kIHBlb3BsZSBzZWVt IHRvIGhhdmUgYWRhcHRlZCB0byB0aGUgZGlmZmVyZW5jZXMuDQoNCltKb25dIEkgYWdyZWUgdGhh dCB0aGlzIGRvY3VtZW50IGNhbuKAmXQgcmV0cm9zcGVjdGl2ZWx5IGRlcHJlY2F0ZSBleGlzdGlu Zywgd2lkZWx5IGRlcGxveWVkIGJlaGF2aW91cnMuICBJbiBzZWN0aW9uIDUgeW91IHNheQ0KDQoN CuKAnE90aGVyIGltcGxlbWVudGF0aW9ucyBtYXkgdHJlYXQgdGhlIFNBRkktMSBhbmQgU0FGSS00 IHJvdXRlcyBmb3IgYSBnaXZlbiBwcmVmaXggYXMgY29tcGFyYWJsZeKAnQ0KDQoNCg0KSW1hZ2lu ZSB0aGF0IHRoZSBTQUZJIDEgYW5kIFNBRkkgNCByb3V0ZXMgd2VyZSByZWNlaXZlZCBmcm9tIHRo ZSBzYW1lIHBlZXIgb24gdGhlIHNhbWUgc2Vzc2lvbi4gIFdoYXQgZG8geW91IG1lYW4gYnkg4oCc Y29tcGFyYWJsZeKAnSBpbiB0aGlzIGNvbnRleHQ/ICBJdCBoYXMgYmVlbiBpbnRlcnByZXRlZCBp biBpbmNvbXBhdGlibGUgd2F5cyBieSBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zLg0KDQotICAg ICAgICBFaXRoZXI6IHRoZSByb3V0ZXMgYXJlIGluZGVwZW5kZW50IGluIHRoZSBBZGotUklCLUlu IGJ1dCBjb21wYXJhYmxlIGluIHRoZSBMT0MtUklCIChhIHNpbmdsZSBiZXN0IG9uZSBpcyBzZWxl Y3RlZCwgdGhlIG90aGVyIGlzIHJldGFpbmVkIGluIG1lbW9yeSkNCg0KLSAgICAgICAgT3I6IFRo ZSByb3V0ZXMgYXJlIGNvbXBhcmFibGUgaW4gdGhlIEFkai1SSUItSW4gaS5lLiBvbmUgaW1wbGlj aXRseSB3aXRoZHJhd3MgdGhlIG90aGVyLg0KDQoNCg0KQm90aCBvZiB0aGVzZSBiZWhhdmlvdXJz IGFyZSBpbXBsZW1lbnRlZCBhbmQgZGVwbG95ZWQuICBUaGUgaXNzdWUgaXMgdGhhdCB0aGV5IGRv IG5vdCBpbnRlcm9wZXJhdGUgaWYgU0FGSSAxIGFuZCBTQUZJIDQgYXJlIGVuYWJsZWQgb24gdGhl IHNhbWUgc2Vzc2lvbi4gIEZvciBpbnN0YW5jZSwgaWYgYW4gaW1wbGVtZW50YXRpb24gb2YgdGhl IGZpcnN0IHR5cGUgd2l0aGRyYXdzIGl0cyBTQUZJIDQgcm91dGUgdGhlbiBhbiBpbXBsZW1lbnRh dGlvbiBvZiB0aGUgc2Vjb25kIHR5cGUgaXMgbGVmdCB3aXRoIG5vIFNBRkkgMSByb3V0ZSB3aXRo IHdoaWNoIHRvIGZvcndhcmQgdHJhZmZpYy4gIFlvdSBkZXNjcmliZSB0aGlzIGFzIGEgbWF0dGVy IG9mIHBvbGljeSwgd2hpY2ggSSBjYW4gbGl2ZSB3aXRoLCBidXQgd2l0aG91dCBmdXJ0aGVyIGRp c2N1c3Npb24gaXQgZ2l2ZXMgbm8gY2x1ZSB0byB0aGUgbGFjayBvZiBpbnRlcm9wZXJhYmlsaXR5 Lg0KDQoNCg0KSSB1bmRlcnN0YW5kIHRoYXQgaXQgaXMgdG9vIGxhdGUgdG8gc2F5IHRoYXQgb25l IG9mIHRoZXNlIGlzIHdyb25nIGFuZCBvbmUgaXMgcmlnaHQsIGJ1dCB0aGUgbGFjayBvZiBpbnRl cm9wZXJhYmlsaXR5IGlzIGFuIGltcG9ydGFudCBkZXBsb3ltZW50IGNvbnNpZGVyYXRpb24gYW5k IEkgZG9u4oCZdCB0aGluayB0aGlzIGRvY3VtZW50IHNob3VsZCBiZSBzaWxlbnQgb24gaXQuICBJ TU8gdGhpcyBpcyBhbiBpbXBvcnRhbnQgZGV0YWlsIGZvciBpbXBsZW1lbnRlcnMsIHdobyBuZWVk IHRvIGJlIGF3YXJlIHRoYXQgYm90aCBpbnRlcnByZXRhdGlvbnMgb2Yg4oCcY29tcGFyYWJsZeKA nSBleGlzdC4gIE5ldyBpbXBsZW1lbnRhdGlvbnMgbWF5IHdpc2ggdG8gaGF2ZSBhIOKAnGNvbXBh dGliaWxpdHkgc2V0dGluZ+KAnSB0aGF0IGVtdWxhdGVzIG9uZSBvciB0aGUgb3RoZXIgYmVoYXZp b3VyIG9uIGEgcGFydGljdWxhciBzZXNzaW9uLCBzbyB0aGF0IHRoZXkgY2FuIGludGVyb3BlcmF0 ZS4NCg0KDQoNCk15IHN1Z2dlc3Rpb246IGNhbiB3ZSBleHBhbmQgc2VjdGlvbiA1IHNsaWdodGx5 IHRvIGNsYXJpZnkgdGhhdCB0aGVyZSBhcmUgdHdvIHdheXMgaW4gd2hpY2ggaW1wbGVtZW50YXRp b25zIGNhbiBjb25zaWRlciBTQUZJIDEgYW5kIFNBRkkgNCByb3V0ZXMgY29tcGFyYWJsZSBvbiBh IGdpdmVuIHNlc3Npb24sIGFzIGFib3ZlLCBhbmQgdGhhdCB0aGUgcmVzdWx0aW5nIGludGVyb3Bl cmFiaWxpdHkgaXNzdWUgY2FuIGJlIGF2b2lkZWQgZWl0aGVyIGJ5IGVtdWxhdGluZyB0aGUgYXBw cm9wcmlhdGUgYmVoYXZpb3VyIG9uIHRoYXQgc2Vzc2lvbiBvciBieSBub3QgcnVubmluZyBTQUZJ IDEgYW5kIFNBRkkgNCBvbiB0aGUgc2FtZSBzZXNzaW9uPw0KDQo1KSBJbiBzZWN0aW9uIDcgaXQg c2F5czoNCuKAnCBJZiBhIEJHUCBpbXBsZW1lbnRhdGlvbiwgbm90IGNvbmZvcm1hbnQgd2l0aCB0 aGUgY3VycmVudCBkb2N1bWVudCwNCmVuY29kZXMgbXVsdGlwbGUgbGFiZWxzIGluIHRoZSBOTFJJ IGJ1dCBoYXMgbm90IHNlbnQgYW5kIHJlY2VpdmVkIHRoZQ0KIk11bHRpcGxlIExhYmVscyIgQ2Fw YWJpbGl0eSwgYSBCR1AgaW1wbGVtZW50YXRpb24gdGhhdCBkb2VzIGNvbmZvcm0NCndpdGggdGhl IGN1cnJlbnQgZG9jdW1lbnQgd2lsbCBsaWtlbHkgcmVzZXQgdGhlIEJHUCBzZXNzaW9uLuKAnQ0K DQpXb3VsZG7igJl0IHRoYXQgcHJldmVudCBpbmNyZW1lbnRhbCBkZXBsb3ltZW50IG9mIHRoaXMg UkZDIGludG8gYSBuZXR3b3JrIHRoYXQgaXMgaW5pdGlhbGx5IGNvbXBvc2VkIG9mIHN1Y2ggaW1w bGVtZW50YXRpb25zPyAgQmVjYXVzZSBpdCBzZWVtcyB0byByZXF1aXJlIHRoYXQgYm90aCBlbmRz IG9mIGVhY2ggQkdQIHNlc3Npb24gbXVzdCBiZSB1cGdyYWRlZCBzaW11bHRhbmVvdXNseSwgb3Ig ZWxzZSB0aGUgQkdQIHNlc3Npb25zIHdpbGwgYWxsIHJlc2V0Lg0KDQoNClRoaXMgaXNzdWUgd2Fz IGRpc2N1c3NlZCBhdCBncmVhdCBsZW5ndGggd2hlbiB0aGUgZHJhZnQgd2FzIGZpcnN0IHN1Ym1p dHRlZC4gIFRoZSB2YXN0IG1ham9yaXR5IG9mIGRlcGxveW1lbnRzIGRvIG5vdCBjaGVjayB0aGUg UyBiaXQuICBUaGF0IGlzLCB0aGUgZGUgZmFjdG8gc3RhbmRhcmQgaXMgdG8gYXNzdW1lIHRoYXQg YSByZWNlaXZlZCB1cGRhdGUgaGFzIG9ubHkgb25lIGxhYmVsLiAgIElmIGFueSBleGlzdGluZyBk ZXBsb3ltZW50IHdlcmUgdHJhbnNtaXR0aW5nIHVwZGF0ZXMgd2l0aCBtdWx0aXBsZSBsYWJlbHMg ZW5jb2RlZCBpbnRvIHRoZSBOTFJJLCBpdCB3b3VsZCBhbHJlYWR5IGJlIGNhdXNpbmcgQkdQIHNl c3Npb24gcmVzZXRzLg0KW0pvbl0gT0suDQoNCihFdmVuIGlmZiB0aGlzIHdlcmUgYSByZWFsIHBy b2JsZW0sIGl0IHdvdWxkbid0IHJlcXVpcmUgYm90aCBlbmRzIG9mIGEgc2Vzc2lvbiB0byBiZSB1 cGdyYWRlZCBzaW11bHRhbmVvdXNseS4gIEl0IHdvdWxkIGp1c3QgcmVxdWlyZSBvbmUgZW5kIHRv IGhhdmUgYSBrbm9iIGFsbG93aW5nIGl0IHRvIGFjY2VwdCBib3RoIG9sZCBhbmQgbmV3IGJlaGF2 aW9yIGZyb20gaXRzIHBlZXIsIGFuZCBhIGtub2IgdGVsbGluZyBpdCB3aGV0aGVyIHRvIHVzZSBv bGQgb3IgbmV3IGJlaGF2aW9yIHdoZW4gc2VuZGluZyB0byBpdHMgcGVlci4gIEJ1dCBzaW5jZSB0 aGUgZGVmYWN0byBzdGFuZGFyZCBkb2Vzbid0IHVzZSBtdWx0aXBsZSBsYWJlbHMsIEkgZG9uJ3Qg dGhpbmsgd2UgaGF2ZSB0byB3b3JyeSBtdWNoIGFib3V0IHRoaXMuKQ0K --_000_BY2PR0201MB19109734BAE5CFFB0E7DD70C84EA0BY2PR0201MB1910_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwg bGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVM7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CWNvbG9yOndpbmRvd3RleHQ7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVM7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4 dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE3Mjk3MjEyNjc7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjUyMzI5MDAxMiAtNjMzNjk2MjE0IDEz NDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUz IDEzNDgwNzU1NSAxMzQ4MDc1NTc7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEi IHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgRXJpYzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgcmVwbGllcyDigJMgcGxl YXNlIHNlZSBbSm9uXSBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5DaGVlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Sm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t R0IiPiBFcmljIEMgUm9zZW4gW21haWx0bzplcm9zZW5AanVuaXBlci5uZXRdDQo8YnI+DQo8Yj5T ZW50OjwvYj4gMDMgTWF5IDIwMTcgMTk6MjM8YnI+DQo8Yj5Ubzo8L2I+IEpvbmF0aGFuIEhhcmR3 aWNrICZsdDtKb25hdGhhbi5IYXJkd2lja0BtZXRhc3dpdGNoLmNvbSZndDs7IGRyYWZ0LWlldGYt bXBscy1yZmMzMTA3YmlzQGlldGYub3JnOyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgbXBsc0BpZXRm Lm9yZzxicj4NCjxiPkNjOjwvYj4gcnRnLWRpckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogUm91dGluZyBkaXJlY3RvcmF0ZSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1tcGxzLXJmYzMx MDctYmlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+VGhhbmtzIGZvciB5b3VyIHJldmll dyE8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNC8yNy8yMDE3IDk6 MDMgQU0sIEpvbmF0aGFuIEhhcmR3aWNrIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyBzcG90dGVkIGEgZmV3IG5pdHMgdGhhdCBzaG91 bGQgYmUgZml4ZWQgYXQgc29tZSBwb2ludCBiZWZvcmUgcHVibGljYXRpb24uPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxicj4NCkkgaGF2ZSBmaXhlZCB0aGUgbml0 cy48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29t bWVudHMgYW5kIFF1ZXN0aW9uczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xKSBJbiBzZWN0aW9u IDIuMSBpdCBzYXlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcJm5i c3A7Jm5ic3A7IElmIHRoZSBNdWx0aXBsZSBMYWJlbHMgQ2FwYWJpbGl0eSBmb3IgYSBnaXZlbiBB RkkvU0FGSSBoYWQgYmVlbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7Jm5ic3A7IGV4Y2hhbmdlZCBvbiB0aGUgZmFpbGVkIHNlc3Npb24sIGJ1dCBpcyBub3QgZXhj aGFuZ2VkIG9uIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A7IHJlc3RhcnRlZCBzZXNzaW9uLCB0aGVuIGFueSBwcmVmaXhlcyBhZHZlcnRpc2VkIGlu IHRoYXQgQUZJL1NBRkkgd2l0aDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7Jm5ic3A7IG11bHRpcGxlIGxhYmVscyBNVVNUIGJlIGV4cGxpY2l0bHkgd2l0aGRyYXdu LuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBJIGhhdmUgdW5kZXJzdG9vZCB0aGlzIGNv cnJlY3RseSwgaXQgcmVxdWlyZXMgYSBzcGVha2VyIHRvIHdpdGhkcmF3IE5MUkkgdGhhdCBpdCBz ZW50IG9uIHRoZSBwcmV2aW91cyBzZXNzaW9uIGJ1dCB0aGF0IGl0IGhhcyBub3Qgc2VudCBvbiB0 aGUgcmVzdGFydGVkIHNlc3Npb24gKGJlY2F1c2UgdGhlIG5lZ290aWF0ZWQgc2Vzc2lvbiBjYXBh YmlsaXRpZXMgY2hhbmdlZCkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4o YSkgV2h5IGRvZXMgaXQgbmVlZCB0byBkbyB0aGF0IOKAkyBpc27igJl0IHRoZSBOTFJJIGltcGxp Y2l0bHkgd2l0aGRyYXduIHdoZW4gdGhlIEVPUiBtYXJrZXIgaXMgc2VudD88bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp Zjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+PGJyPg0KVGhlIHRoZW9yeSBoZXJlIGlzIHRo YXQgdGhlIGxhYmVsIHN0YWNrIGluIHRoZSBzdGFsZSByb3V0ZXMgaXMga25vd24gdG8gYmUgaW52 YWxpZCwgc28geW91IHJlYWxseSBkb24ndCB3YW50IHlvdXIgcGVlciB0byBob2xkIG9uIHRvIHRo ZW0gdW50aWwgRU9SIGlzIHJlY2VpdmVkLjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPltKb25dIE9LLCB0aGF04oCZcyBmaW5l Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxi cj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4oYikgVGhpcyBzZWVtcyB0byBjb250cmFkaWN0IHNlY3Rpb24gMi40IHdoaWNoIHNheXMg 4oCcTm90ZSB0aGF0IGxhYmVsL3ByZWZpeCBiaW5kaW5ncyB0aGF0IHdlcmUgbm90IGFkdmVydGlz ZWQgb24gdGhlIGdpdmVuIHNlc3Npb24gY2Fubm90IGJlIHdpdGhkcmF3biBieSB0aGlzIG1ldGhv ZC7igJ08bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+PGJyPg0KSSBh ZGRlZCB0aGUgZm9sbG93aW5nIHRleHQgdG8gc2VjdGlvbiAyLjQgcmlnaHQgYWZ0ZXIgdGhlIHF1 b3RlZCBzZW50ZW5jZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+Jm5ic3A7 KEhvd2V2ZXIsIGlmIHRoZSBiaW5kaW5ncyB3ZXJlIGFkdmVydGlzZWQgb24gYSBwcmV2aW91cyBz ZXNzaW9uIHdpdGggdGhlIHNhbWUgcGVlciwgYW5kIHRoZSBjdXJyZW50IHNlc3Npb24gaXMgdGhl IHJlc3VsdCBvZiBhICZxdW90O2dyYWNlZnVsIHJlc3RhcnQmcXVvdDsNCiAoW1JGQzQ3MjRdKSBv ZiB0aGUgcHJldmlvdXMgc2Vzc2lvbiwgdGhlbiB0aGlzIHdpdGhkcmF3YWwgbWV0aG9kIG1heSBi ZSB1c2VkLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+MikgSW4gc2VjdGlvbiAyLjEgaXQgc2F5czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPuKAnEEgQkdQIHNwZWFrZXIgU0hPVUxEIE5PVCBzZW5kIGFuIFVQREFURSB0 aGF0IGJpbmRzIG1vcmUgbGFiZWxzIHRvIGEgZ2l2ZW4gcHJlZml4IHRoYW4gaXRzIHBlZXIgaXMg Y2FwYWJsZSBvZiByZWNlaXZpbmfigJ0g4oCTIHdoeSBpc27igJl0IHRoYXQgTVVTVCBOT1Q/PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PGJy PlNlY3Rpb24gMi4xIGFsc28gcmVxdWlyZXMgdGhlIHJlY2VpdmluZyBzcGVha2VyIHRvIGFwcGx5 ICZxdW90O3RyZWF0LWFzLXdpdGhkcmF3JnF1b3Q7IHRvIHN1Y2ggdXBkYXRlcywgd2hpY2ggZG9l cyBpbXBseSB0aGF0IHRoZSBzZW5kaW5nIHNwZWFrZXIgbXVzdCBub3Qgc2VuZCB0aGVtLiZuYnNw OyBTbyBJJ3ZlIGNoYW5nZWQgJnF1b3Q7U0hPVUxEIE5PVCZxdW90OyB0byAmcXVvdDtNVVNUIE5P VCZxdW90Oy4mbmJzcDsgPGJyPjxicj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W0pvbl0g VGhhbmtzLiZuYnNwOyBOb3RlIHRoYXQgdGhlIHNhbWUgY2hhbmdlIGFsc28gYXBwbGllcyBpbiBz ZWN0aW9uIDMuMi4xPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IOKAnDwvc3Bhbj5TaW1pbGFy bHksIGEgZ2l2ZW4gcm91dGUgU0hPVUxEIE5PVCBiZTxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLUdCIj4mbmJzcDsmbmJzcDsgcHJvcGFnYXRlZCB0byBhIGdpdmVuIHBlZXIgaWYgdGhl IHJvdXRlJ3MgTkxSSSBoYXMgbW9yZSBsYWJlbHMgdGhhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tR0IiPiZuYnNwOyZuYnNwOyB0aGUgcGVlciBoYXMgYW5ub3VuY2VkPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLUdCIj7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPuKApmFuZCBhbHNv IGluIHNlY3Rpb24gMy4yLjI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+4oCcPC9zcGFuPkEgQkdQIHNwZWFrZXIgTVVTVCBOT1Qgc2VuZCBtdWx0aXBsZTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBsYWJlbHMgdG8gYSBwZWVyIHdpdGggd2hpY2gg aXQgaGFzIG5vdCBleGNoYW5nZWQgdGhlICZxdW90O011bHRpcGxlPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IExhYmVscyZxdW90OyBDYXBhYmlsaXR5LCBhbmQgU0hPVUxEIE5P VCBzZW5kIG1vcmUgbGFiZWxzIHRvIGEgZ2l2ZW4gcGVlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyB0aGFuIHRoZSBwZWVyIGhhcyBhbm5vdW5jZWQ8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKA nTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zKSBJbiBzZWN0aW9uIDIuNCBpdCBzYXlzOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcVG8gZG8gc28sIGl0IG1heSBz ZW5kIGEgQkdQIFVQREFURSBtZXNzYWdlIHdpdGggYW4gTVBfVU5SRUFDSF9OTFJJIGF0dHJpYnV0 ZS7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNob3VsZCB0aGF0IGJl IOKAnGl0IE1VU1Qgc2VuZOKAnT88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1HQiI+PGJyPg0KSSB0aGluayB0aGUgbm9uLW5vcm1hdGl2ZSAobm9uLVJGQzIxMTkpIGxhbmd1 YWdlIGlzIGZpbmUgaGVyZS4mbmJzcDsgPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5bSm9uXSBJdCBq dXN0IGphcnJlZCB3aXRoIG1lIGEgbGl0dGxlLiZuYnNwOyBJ4oCZbSBub3QgZ29pbmcgdG8gZGln IGluIG9uIHRoaXMgcG9pbnQsIGJ1dCBsZXQgbWUgZXhwbGFpbiB3aGVyZSBJIHdhcyBjb21pbmcg ZnJvbS4mbmJzcDsgV2hlbiB5b3Ugc2F5IOKAnGl0IG1heQ0KIHNlbmTigJ0gdGhlIHdvcmQg4oCc bWF54oCdIG1ha2VzIGl0IHNvdW5kIGxpa2UgaXQgaXMgbm90IG9ibGlnZWQgdG8gZG8gaXQgdGhp cyB3YXkuJm5ic3A7IEkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhbnkgb3RoZXIgd2F5IHRvIHdp dGhkcmF3IHRoZSByb3V0ZSAoc2hvcnQgb2YgY2xvc2luZyB0aGUgc2Vzc2lvbikgc28gSSB0aGlu ayB0aGF0IHdoYXQgeW91IGFyZSBkZXNjcmliaW5nIGlzIHRoZSBvYmxpZ2F0b3J5IHdheSB0byB3 aXRoZHJhdyB0aGUgcm91dGUuJm5ic3A7IEZvcg0KIHRoYXQgcmVhc29uIEnigJlkIHByZWZlciBl aXRoZXIg4oCcaXQgc2VuZHPigJ0gb3Ig4oCcaXQgTVVTVCBzZW5k4oCdLjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjQpIEluIHNlY3Rpb24gNTogYWx0aG91Z2ggc29tZSBpbXBsZW1lbnRhdGlvbnMgdHJlYXQg U0FGSSAxIGFuZCBTQUZJIDQgcm91dGVzIGFzIGNvbXBhcmFibGUsIEkgYmVsaWV2ZSB0aGF0IHRo ZXkgc2hvdWxkIGFsd2F5cyBiZSB0cmVhdGVkIGFzIGluZGVwZW5kZW50LCBpbiB0aGUgZm9sbG93 aW5nIHNlbnNlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VwcG9zZSBh IHNwZWFrZXIgUzEgc2VuZHMgYSBTQUZJIDEgcm91dGUgYW5kIHRoZW4gYSBTQUZJIDQgcm91dGUg dG8gdGhlIHNhbWUgcHJlZml4IFAuJm5ic3A7IFRoZSBTQUZJIDQgcm91dGUgTVVTVCBOT1QgYmUg dHJlYXRlZCBieSB0aGUgcmVjZWl2aW5nIHNwZWFrZXIgYXMgYW4gaW1wbGljaXQgd2l0aGRyYXcg b2YgdGhlIFNBRkkgMSByb3V0ZS4mbmJzcDsgSWYgUzEgc3Vic2VxdWVudGx5IHNlbmRzIGFuIGV4 cGxpY2l0IHdpdGhkcmF3DQogb2YgdGhlIFNBRkkgNCByb3V0ZSwgdGhpcyBNVVNUIE5PVCBpbXBs aWNpdGx5IHdpdGhkcmF3IHRoZSBTQUZJIDEgcm91dGUsIGFuZCB2aWNlIHZlcnNhLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW0gSSBjb3JyZWN0PyZuYnNwOyBJIGhhdmUg c2VlbiBpbXBsZW1lbnRhdGlvbnMgdGhhdCB2aW9sYXRlIHRoaXMgc28gSSB0aGluayBpdCBpcyB3 b3J0aCBzcGVsbGluZyBvdXQgc29tZXdoZXJlIGluIHRoaXMgc2VjdGlvbi48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp Zjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+PGJyPg0KRnJvbSBTZWN0aW9uIDE6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPlRoaXMgZG9jdW1lbnQgYWxzbyBhZGRyZXNz ZXMgdGhlIGlzc3VlIG9mIHRoZSBob3cgVVBEQVRFcyB0aGF0IGJpbmQgbGFiZWxzIHRvIGEgZ2l2 ZW4gcHJlZml4IGludGVyYWN0IHdpdGggVVBEQVRFcyB0aGF0IGFkdmVydGlzZSBwYXRocyB0byB0 aGF0DQogcHJlZml4IGJ1dCBkbyBub3QgYmluZCBsYWJlbHMgdG8gaXQuJm5ic3A7IEhvd2V2ZXIs IGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSwgaXQgZGVjbGFyZXMgbW9zdCBvZiB0aGVzZSBp bnRlcmFjdGlvbnMgdG8gYmUgbWF0dGVycyBvZiBsb2NhbCBwb2xpY3kuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5EaWZmZXJlbnQgZGVwbG95ZWQgaW1w bGVtZW50YXRpb25zIGhhdmUgZGlmZmVyZW50IGJlaGF2aW9yLCBhbmQgSSB0aGluayBpdCBpcyBi ZXR0ZXIgdG8gYWR2YW5jZSB0aGUgZG9jdW1lbnQgYXMgaXMgcmF0aGVyIHRoYW4gZGVyYWlsIGl0 IHdpdGgNCiB0aGUgaW5ldml0YWJsZSBmb29kIGZpZ2h0IHRoYXQgd291bGQgb2NjdXIgaWYgd2Ug d2FudGVkIHRvIHRyeSB0byBnZXQgdGhlIElFVEYgdG8gc2F5IHdoaWNoIGltcGxlbWVudGF0aW9u IGlzIGJldHRlciB0aGFuIHdoaWNoIG90aGVyIGltcGxlbWVudGF0aW9uLiZuYnNwOyBUaGUgZGVw bG95ZWQgaW1wbGVtZW50YXRpb25zIGhhdmUgYmVlbiBhcm91bmQgZm9yIG1hbnkgeWVhcnMsIGFu ZCBwZW9wbGUgc2VlbSB0byBoYXZlIGFkYXB0ZWQgdG8gdGhlIGRpZmZlcmVuY2VzLjxicj4NCjxi cj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1HQiI+W0pvbl0gSSBhZ3JlZSB0aGF0IHRoaXMgZG9jdW1lbnQgY2Fu4oCZdCBy ZXRyb3NwZWN0aXZlbHkgZGVwcmVjYXRlIGV4aXN0aW5nLCB3aWRlbHkgZGVwbG95ZWQgYmVoYXZp b3Vycy4mbmJzcDsgSW4gc2VjdGlvbiA1IHlvdSBzYXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RCI+4oCcPC9zcGFuPk90aGVyIGltcGxl bWVudGF0aW9ucyBtYXkgdHJlYXQgdGhlIFNBRkktMSBhbmQgU0FGSS00IHJvdXRlcyBmb3IgYSBn aXZlbiBwcmVmaXggYXMgY29tcGFyYWJsZTxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMUY0OTdE Ij7igJ0gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkltYWdpbmUgdGhhdCB0aGUgU0FGSSAxIGFuZCBTQUZJIDQg cm91dGVzIHdlcmUgcmVjZWl2ZWQgZnJvbSB0aGUgc2FtZSBwZWVyIG9uIHRoZSBzYW1lIHNlc3Np b24uJm5ic3A7IFdoYXQgZG8geW91IG1lYW4gYnkg4oCcY29tcGFyYWJsZeKAnSBpbiB0aGlzIGNv bnRleHQ/Jm5ic3A7IEl0IGhhcyBiZWVuIGludGVycHJldGVkIGluIGluY29tcGF0aWJsZSB3YXlz IGJ5IGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkVpdGhlcjogdGhlIHJvdXRlcyBhcmUgaW5k ZXBlbmRlbnQgaW4gdGhlIEFkai1SSUItSW4gYnV0IGNvbXBhcmFibGUgaW4gdGhlIExPQy1SSUIg KGEgc2luZ2xlIGJlc3Qgb25lIGlzIHNlbGVjdGVkLCB0aGUgb3RoZXIgaXMgcmV0YWluZWQgaW4g bWVtb3J5KTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5PcjogVGhlIHJvdXRlcyBhcmUgY29tcGFyYWJsZSBpbiB0aGUgQWRqLVJJQi1JbiBp LmUuIG9uZSBpbXBsaWNpdGx5IHdpdGhkcmF3cyB0aGUgb3RoZXIuPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJv dGggb2YgdGhlc2UgYmVoYXZpb3VycyBhcmUgaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkLiZuYnNw OyBUaGUgaXNzdWUgaXMgdGhhdCB0aGV5IGRvIG5vdCBpbnRlcm9wZXJhdGUgaWYgU0FGSSAxIGFu ZCBTQUZJIDQgYXJlIGVuYWJsZWQgb24gdGhlIHNhbWUgc2Vzc2lvbi4mbmJzcDsgRm9yIGluc3Rh bmNlLCBpZiBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgZmlyc3QgdHlwZSB3aXRoZHJhd3MgaXRz IFNBRkkgNCByb3V0ZSB0aGVuIGFuIGltcGxlbWVudGF0aW9uIG9mIHRoZSBzZWNvbmQgdHlwZSBp cyBsZWZ0IHdpdGggbm8gU0FGSSAxIHJvdXRlIHdpdGggd2hpY2ggdG8gZm9yd2FyZCB0cmFmZmlj LiZuYnNwOyBZb3UgZGVzY3JpYmUgdGhpcyBhcyBhIG1hdHRlciBvZiBwb2xpY3ksIHdoaWNoIEkg Y2FuIGxpdmUgd2l0aCwgYnV0IHdpdGhvdXQgZnVydGhlciBkaXNjdXNzaW9uIGl0IGdpdmVzIG5v IGNsdWUgdG8gdGhlIGxhY2sgb2YgaW50ZXJvcGVyYWJpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB1 bmRlcnN0YW5kIHRoYXQgaXQgaXMgdG9vIGxhdGUgdG8gc2F5IHRoYXQgb25lIG9mIHRoZXNlIGlz IHdyb25nIGFuZCBvbmUgaXMgcmlnaHQsIGJ1dCB0aGUgbGFjayBvZiBpbnRlcm9wZXJhYmlsaXR5 IGlzIGFuIGltcG9ydGFudCBkZXBsb3ltZW50IGNvbnNpZGVyYXRpb24gYW5kIEkgZG9u4oCZdCB0 aGluayB0aGlzIGRvY3VtZW50IHNob3VsZCBiZSBzaWxlbnQgb24gaXQuJm5ic3A7IElNTyB0aGlz IGlzIGFuIGltcG9ydGFudCBkZXRhaWwgZm9yIGltcGxlbWVudGVycywgd2hvIG5lZWQgdG8gYmUg YXdhcmUgdGhhdCBib3RoIGludGVycHJldGF0aW9ucyBvZiDigJxjb21wYXJhYmxl4oCdIGV4aXN0 LiZuYnNwOyBOZXcgaW1wbGVtZW50YXRpb25zIG1heSB3aXNoIHRvIGhhdmUgYSDigJxjb21wYXRp YmlsaXR5IHNldHRpbmfigJ0gdGhhdCBlbXVsYXRlcyBvbmUgb3IgdGhlIG90aGVyIGJlaGF2aW91 ciBvbiBhIHBhcnRpY3VsYXIgc2Vzc2lvbiwgc28gdGhhdCB0aGV5IGNhbiBpbnRlcm9wZXJhdGUu PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPk15IHN1Z2dlc3Rpb246IGNhbiB3ZSBleHBhbmQgc2VjdGlvbiA1IHNs aWdodGx5IHRvIGNsYXJpZnkgdGhhdCB0aGVyZSBhcmUgdHdvIHdheXMgaW4gd2hpY2ggaW1wbGVt ZW50YXRpb25zIGNhbiBjb25zaWRlciBTQUZJIDEgYW5kIFNBRkkgNCByb3V0ZXMgY29tcGFyYWJs ZSBvbiBhIGdpdmVuIHNlc3Npb24sIGFzIGFib3ZlLCBhbmQgdGhhdCB0aGUgcmVzdWx0aW5nIGlu dGVyb3BlcmFiaWxpdHkgaXNzdWUgY2FuIGJlIGF2b2lkZWQgZWl0aGVyIGJ5IGVtdWxhdGluZyB0 aGUgYXBwcm9wcmlhdGUgYmVoYXZpb3VyIG9uIHRoYXQgc2Vzc2lvbiBvciBieSBub3QgcnVubmlu ZyBTQUZJIDEgYW5kIFNBRkkgNCBvbiB0aGUgc2FtZSBzZXNzaW9uPzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjUpIEluIHNlY3Rpb24gNyBpdCBzYXlzOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLUdCIj7igJwgSWYgYSBCR1AgaW1wbGVtZW50YXRpb24sIG5vdCBjb25mb3JtYW50IHdpdGgg dGhlIGN1cnJlbnQgZG9jdW1lbnQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5lbmNvZGVz IG11bHRpcGxlIGxhYmVscyBpbiB0aGUgTkxSSSBidXQgaGFzIG5vdCBzZW50IGFuZCByZWNlaXZl ZCB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPiZxdW90O011bHRpcGxlIExhYmVscyZx dW90OyBDYXBhYmlsaXR5LCBhIEJHUCBpbXBsZW1lbnRhdGlvbiB0aGF0IGRvZXMgY29uZm9ybTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+d2l0aCB0aGUgY3VycmVudCBkb2N1bWVudCB3aWxs IGxpa2VseSByZXNldCB0aGUgQkdQIHNlc3Npb24u4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Xb3VsZG7igJl0IHRoYXQgcHJldmVudCBpbmNyZW1lbnRhbCBkZXBsb3ltZW50IG9m IHRoaXMgUkZDIGludG8gYSBuZXR3b3JrIHRoYXQgaXMgaW5pdGlhbGx5IGNvbXBvc2VkIG9mIHN1 Y2ggaW1wbGVtZW50YXRpb25zPyZuYnNwOyBCZWNhdXNlIGl0IHNlZW1zIHRvIHJlcXVpcmUgdGhh dCBib3RoIGVuZHMgb2YgZWFjaCBCR1Agc2Vzc2lvbiBtdXN0IGJlIHVwZ3JhZGVkIHNpbXVsdGFu ZW91c2x5LCBvciBlbHNlIHRoZSBCR1ANCiBzZXNzaW9ucyB3aWxsIGFsbCByZXNldC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxicj4N ClRoaXMgaXNzdWUgd2FzIGRpc2N1c3NlZCBhdCBncmVhdCBsZW5ndGggd2hlbiB0aGUgZHJhZnQg d2FzIGZpcnN0IHN1Ym1pdHRlZC4mbmJzcDsgVGhlIHZhc3QgbWFqb3JpdHkgb2YgZGVwbG95bWVu dHMgZG8gbm90IGNoZWNrIHRoZSBTIGJpdC4mbmJzcDsgVGhhdCBpcywgdGhlIGRlIGZhY3RvIHN0 YW5kYXJkIGlzIHRvIGFzc3VtZSB0aGF0IGEgcmVjZWl2ZWQgdXBkYXRlIGhhcyBvbmx5IG9uZSBs YWJlbC4gJm5ic3A7IElmIGFueSBleGlzdGluZyBkZXBsb3ltZW50IHdlcmUNCiB0cmFuc21pdHRp bmcgdXBkYXRlcyB3aXRoIG11bHRpcGxlIGxhYmVscyBlbmNvZGVkIGludG8gdGhlIE5MUkksIGl0 IHdvdWxkIGFscmVhZHkgYmUgY2F1c2luZyBCR1Agc2Vzc2lvbiByZXNldHMuPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLUdCIj5bSm9uXSBPSy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLUdCIj48YnI+DQo8YnI+DQooRXZlbiBpZmYgdGhpcyB3ZXJlIGEgcmVh bCBwcm9ibGVtLCBpdCB3b3VsZG4ndCByZXF1aXJlIGJvdGggZW5kcyBvZiBhIHNlc3Npb24gdG8g YmUgdXBncmFkZWQgc2ltdWx0YW5lb3VzbHkuJm5ic3A7IEl0IHdvdWxkIGp1c3QgcmVxdWlyZSBv bmUgZW5kIHRvIGhhdmUgYSBrbm9iIGFsbG93aW5nIGl0IHRvIGFjY2VwdCBib3RoIG9sZCBhbmQg bmV3IGJlaGF2aW9yIGZyb20gaXRzIHBlZXIsIGFuZCBhIGtub2IgdGVsbGluZyBpdCB3aGV0aGVy IHRvIHVzZSBvbGQNCiBvciBuZXcgYmVoYXZpb3Igd2hlbiBzZW5kaW5nIHRvIGl0cyBwZWVyLiZu YnNwOyBCdXQgc2luY2UgdGhlIGRlZmFjdG8gc3RhbmRhcmQgZG9lc24ndCB1c2UgbXVsdGlwbGUg bGFiZWxzLCBJIGRvbid0IHRoaW5rIHdlIGhhdmUgdG8gd29ycnkgbXVjaCBhYm91dCB0aGlzLik8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR0201MB19109734BAE5CFFB0E7DD70C84EA0BY2PR0201MB1910_-- From nobody Fri May 5 00:01:54 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC5D1201F2; Fri, 5 May 2017 00:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VD4gZBiFldNY; Fri, 5 May 2017 00:01:50 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D001512943D; Fri, 5 May 2017 00:01:49 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id F119418013D1; Fri, 5 May 2017 09:01:46 +0200 (CEST) To: Stewart Bryant , "mpls-chairs@ietf.org" , "mpls@ietf.org" References: <1452d116-c861-ebda-4989-39a93bfdbe8b@gmail.com> Cc: "" , "spring-chairs@ietf.org" From: Loa Andersson Message-ID: <393098d4-6a64-6c38-699b-3060b0ee27c5@pi.nu> Date: Fri, 5 May 2017 09:01:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1452d116-c861-ebda-4989-39a93bfdbe8b@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] draft-ietf-spring-ipv6-use-cases - almost completed WGLC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 07:01:52 -0000 Stewart, Tnx for the heads-up, I had missed this :(, and have still not read the draft. Alvaro, Is it possible to give the MPLS wg time to review this? As far as I can see this was never brought to the attntion of the MPLS wg. /Loa On 2017-05-02 15:08, Stewart Bryant wrote: > draft-ietf-spring-ipv6-use-cases has almost finished IETF LC (two days > left) > > https://datatracker.ietf.org/doc/draft-ietf-spring-ipv6-use-cases/ > > There are a number of statements about the development of MPLS over IPv6 > that are used to justify the argument of the authors that MPLS cannot > run over an IPv6 only network. It seems to me that these statements > ought to be checked for correctness by the MPLS WG. > > Stewart > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri May 5 04:18:07 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352CC1201FA; Fri, 5 May 2017 04:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsdiJloqXaS9; Fri, 5 May 2017 04:18:04 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606AB127444; Fri, 5 May 2017 04:18:04 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id y10so703915wmh.0; Fri, 05 May 2017 04:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:references:to:cc:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=hEpRJEfsmGDPctVpykKifezW/wRW1qIvin4byXZgp64=; b=YJafsSLa/rXcIctTcUOx8QpLsAjJ1k/mhiutn3WIvt97l+G87/Ohrjk3TQrlh+Ipsi Prs3VoHKwC0HzWaZB/zVBOc2S9B3TJyzZ8uN0G2KstybYoF4ZXWct3z5YsxhJnCpo4SS JiL1lJ0BJ5EEiYWlIKFFr308GJbo0s8UJ4nvYlfVBjcluI0FEMpt4c5CmCdiimjMFequ 9aTiFlnKLA68BpLKo0xoFg3R+ktmVACrq7+vJLFK5gv2cmIPGniywNeWj40+xIliQyGm HAcESqWVqYeF7d+hZJcV9DYTNz1AKXCJr4SSZu0rR4A5+nNyaioTICNgPrX8Nsphbibp wVCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=hEpRJEfsmGDPctVpykKifezW/wRW1qIvin4byXZgp64=; b=LCyzCplahKtV5zlRmCUtT23itB2NbTbTeEaMz57nriGG3R6jBRDKHpT2El2VCYQFRb poc3YRqqEIDxln/aA4+XOjj5PQ4pX54GHoNaDWRpoG6nQgmB7HooqismMTGyLvabIOO0 bYEFRV6w1QlJRgAutusY+PHTxivP0gYx2smlsXDFrBmMIuvc2xpTeMBHytBph0J00x4G yreufygEUEl9Yv8ZMmFcnipIuJASHE82dC5xSX4TzVShj2ZRMtSGroZDahr7cjqm7BXi mk0u1V247WgoQSmzKxVfcyKijDockuYvuCPSIdnz4rz/1bIaD+Z3Ez37EMCzGzpGS1WI kY6w== X-Gm-Message-State: AN3rC/54nJnC7l9TfQF/qmufOMXvOMg6LBpeLbLHE6c7e5+mydp5ZFoz PMq5v0KV9qbGY1Xl X-Received: by 10.80.170.220 with SMTP id r28mr1339335edc.72.1493983082732; Fri, 05 May 2017 04:18:02 -0700 (PDT) Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id m53sm1364071edc.29.2017.05.05.04.18.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 04:18:00 -0700 (PDT) Reply-To: huubatwork@gmail.com References: To: "mpls@ietf.org" , draft-bryant-mpls-sfl-framework@ietf.org Cc: mpls-chairs From: Huub van Helvoort Message-ID: Date: Fri, 5 May 2017 13:17:59 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 11:18:06 -0000 Hello authors and WG, I am an MPLS-RT reviewer assigned to review draft-bryant-mpls-sfl-framework. The document is short and coherent, it may be useful. The only comment I have is regarding the text in the first paragraph of section 4. I had to read it several times before I understood what it means. this can be fixed prior to adaption as WG document. Best regards, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From nobody Fri May 5 05:52:43 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C7D127866; Fri, 5 May 2017 05:52:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149398875418.6885.2278821254350194395@ietfa.amsl.com> Date: Fri, 05 May 2017 05:52:34 -0700 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-spring-entropy-label-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 12:52:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Entropy label for SPRING tunnels Authors : Sriganesh Kini Kireeti Kompella Siva Sivabalan Stephane Litkowski Rob Shakir Jeff Tantsura Filename : draft-ietf-mpls-spring-entropy-label-06.txt Pages : 23 Date : 2017-05-05 Abstract: Source routed tunnels with label stacking is a technique that can be leveraged to steer a packet through a controlled set of segments. This can be applied to the Multi Protocol Label Switching (MPLS) data plane. Entropy label (EL) is a technique used in MPLS to improve load-balancing. This document examines and describes how ELs are to be applied to source routed tunnels with label stacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-entropy-label/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-06 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-spring-entropy-label-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-spring-entropy-label-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 Fri May 5 06:40:16 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F10129412; Fri, 5 May 2017 06:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doHNA55t1Nrb; Fri, 5 May 2017 06:40:13 -0700 (PDT) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 7D4E01293D9; Fri, 5 May 2017 06:40:13 -0700 (PDT) Received: by mail-qk0-x242.google.com with SMTP id o85so864485qkh.0; Fri, 05 May 2017 06:40:13 -0700 (PDT) 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=jgMeWgYFCbXAR2ptqTTHffLBEPgLCX4Nh62bU2X9BnM=; b=eZrY/Fso5u1hU/KCW26Rz8eGQzl/02zYT1MlNPA3z7juxJVEVM20tGDqDeplBbSUzf QGvxQQBNqykvjIye49LZ+/ua0pZeIYemf4cwmm+ZT7r763hr6XJMUpIUrmQf7JWeN5Oe Cpae9VyGm0HOlRSNeOsaVzw5XB5zpTn2mUFpjaYoYmGlmFIixZNLK6iyW7H03n6aI5bL sTMRo6E8AspZalkqhXaymHiou+zpi/9kn8kFIsOc7yTHFOpsQ+agNX/oC+19EifuqSoB 8ZwwB8og+9jBMBCd+LFxg23161BjfnM+kBereC8OF69rSw/aRpMIK1q1ibqBrw4BTEy2 9F0g== 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=jgMeWgYFCbXAR2ptqTTHffLBEPgLCX4Nh62bU2X9BnM=; b=rH0KQlza4WXyh4h+EqxzJ5vvERAnANr8E7fVPVo9O7YfLJ5MnZIC494zakwkC5Cfv2 ugb3Sd+WK8C8HVCnz0PkPTNwdJWjzX5KwSqSOypqQMbK5LRz7K8ON8fuKDyHJFc+uwAg BvVxg3h59xX7lNNPBNf1nRjeh9nbz+V210cN7/OVMwlTug3DqNmFZFf8uJqlzdjTQHdD /Q122MBaAooMBs/qW1HCHCGrwKZCVCuB5N2JmoyOTHw2p7O4I9hhDg0bD4D+yOU7W80w WQOUTJIGJvS3rHzZK7/aa5pRJYDvKR+Z+tUCBpCwnSWjF20TL5XUA4ia5TyiEuc22225 bS0A== X-Gm-Message-State: AN3rC/4sNhoL9nvAonTrlpzqpzjDz4e85v1/TNa9UBcDTyobH+WspuWi hssHJN0rDrqUA/vIKqw= X-Received: by 10.55.31.38 with SMTP id f38mr12410137qkf.267.1493991612672; Fri, 05 May 2017 06:40:12 -0700 (PDT) Received: from [10.0.1.8] (c-98-229-24-65.hsd1.ma.comcast.net. [98.229.24.65]) by smtp.gmail.com with ESMTPSA id q40sm4318991qtq.21.2017.05.05.06.40.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 06:40:12 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-6AD05A0D-45E2-4AAC-BBB7-FA1DEB1E1B5D Mime-Version: 1.0 (1.0) From: George Swallow X-Mailer: iPhone Mail (14E304) In-Reply-To: Date: Fri, 5 May 2017 09:40:11 -0400 Cc: "mpls@ietf.org" , "mpls-chairs@ietf.org" , draft-bryant-mpls-rfc6374-sfl@ietf.org, Greg Mirsky Content-Transfer-Encoding: 7bit Message-Id: <3596E602-376D-4E67-A6E8-5965D3449D7E@gmail.com> References: <8b495d71-1291-cd59-9faa-fff371c9535f@pi.nu> To: Loa Andersson Archived-At: Subject: Re: [mpls] IPR poll on draft-bryant-mpls-rfc6374-sfl X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 13:40:15 -0000 --Apple-Mail-6AD05A0D-45E2-4AAC-BBB7-FA1DEB1E1B5D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I know of no further IPR beyond that which has been disclosed against this d= ocument.=20 George > On Apr 27, 2017, at 7:24 AM, Greg Mirsky wrote: >=20 > Hi Loa, > I'm not aware of any IPR related to this draft other that already been dis= closed. >=20 > Regards, > Greg >=20 >> On Wed, Apr 26, 2017 at 8:31 PM, Loa Andersson wrote: >> Working Group, >>=20 >> The author of draft-bryant-mpls-rfc6374-sfl has told us that >> the document is ready to be considered for working adoption. >>=20 >> The document been through MPLS-RT review. We will do an IPR poll >> parallel to the start of the adoption poll. >>=20 >> This mail starts the IPR poll. >>=20 >> Are you aware of any IPR that applies to draft-bryant-mpls-rfc6374-sfl? >>=20 >> If so, has this IPR been disclosed in compliance with IETF IPR rules >> (see RFCs 3979, 4879, 3669 and 5378 for more details). >>=20 >> There is one IPR disclosure filed directly against this document. >>=20 >> If you are listed as a document author or contributor please respond to >> this email regardless of whether or not you are aware of any relevant >> IPR. *The response needs to be sent to the MPLS wg mailing list.* The >> document will not advance to the next stage until a response has been >> received from each author and contributor. >>=20 >> If you are on the MPLS WG email list but are not listed as an author or >> contributor, then please explicitly respond only if you are aware of any >> IPR that has not yet been disclosed in conformance with IETF rules. >>=20 >>=20 >> /Loa >> mpls wg co-chair >> --=20 >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 --Apple-Mail-6AD05A0D-45E2-4AAC-BBB7-FA1DEB1E1B5D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I know of no further IPR beyond that which has been disclosed against this document. 

George

On Apr 27, 2017, at 7:24 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Loa,
I'm not aware of any IPR related to this draft other that already been disclosed.

Regards,
Greg

On Wed, Apr 26, 2017 at 8:31 PM, Loa Andersson <loa@pi.nu> wrote:
Working Group,

The author of draft-bryant-mpls-rfc6374-sfl has told us that
the document is ready to be considered for working adoption.

The document been through MPLS-RT review. We will do an IPR poll
parallel to the start of the adoption poll.

This mail starts the IPR poll.

Are you aware of any IPR that applies to draft-bryant-mpls-rfc6374-sfl?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

There is one IPR disclosure filed directly against this document.

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the MPLS wg mailing list.* The
document will not advance to the next stage until a response has been
received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any
IPR that has not yet been disclosed in conformance with IETF rules.


/Loa
mpls wg co-chair
--


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

--Apple-Mail-6AD05A0D-45E2-4AAC-BBB7-FA1DEB1E1B5D-- From nobody Fri May 5 08:32:37 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABA2129557; Fri, 5 May 2017 08:32:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk CC: mpls@ietf.org, db3546@att.com, mpls-chairs@ietf.org, draft-ietf-mpls-tp-aps-updates@ietf.org, Loa Andersson , loa@pi.nu Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149399833617.8524.3174242289503521535.idtracker@ietfa.amsl.com> Date: Fri, 05 May 2017 08:32:16 -0700 Archived-At: Subject: [mpls] Last Call: (Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 15:32:16 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-05-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document contains updates to MPLS Transport Profile (MPLS-TP) linear protection in Automatic Protection Switching (APS) mode defined in RFC 7271. The updates provide rules related to the initialization of the Protection State Coordination (PSC) Control Logic, in which the state machine resides, when operating in APS mode, and clarify some operation related to state transition table lookup. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-aps-updates/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-aps-updates/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri May 5 10:06:04 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAD7127863; Fri, 5 May 2017 10:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRrOGDx9TyFl; Fri, 5 May 2017 10:06:01 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1DC51294C8; Fri, 5 May 2017 10:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1766; q=dns/txt; s=iport; t=1494003959; x=1495213559; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=I5hgm+seTrLjQFL8/iFjadh3IfeJP5bV44s31nYgS0U=; b=GL9RNVJOcP9cwIseWzyhcsTTCZUXvK3gC2D3q4gnVciIBG4jYe/so9RV Kdytrp4y4VFGcPKu+tcftnZpDzNwDHbIlBLBhW8FNhsNIWPVOfDIrDVWz h4cTT7PEVkP894rvXhDzei2pww/4oZf/ual1Y9esRYQGReEZ5nM6F83NU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CNAQBwsAxZ/5FdJa1bGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyorgW4Hg2GKGJFWlXCCD4YkAhqELz8YAQIBAQEBAQEBayiFFgEEASM?= =?us-ascii?q?RRQULAgEIGgImAgICMBUQAgQBDQUfiXkIsTyCJopoAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHYELhVSBXiuCcIRjgwYugjEBBJZhhw4BkxYLgXmFOYorlDYBHziBCm8?= =?us-ascii?q?VWAGGX3aHaIENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,293,1491264000"; d="scan'208";a="419405468" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 May 2017 17:05:59 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v45H5wJE007942 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 May 2017 17:05:59 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 5 May 2017 12:05:58 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Fri, 5 May 2017 12:05:58 -0500 From: "Alvaro Retana (aretana)" To: Loa Andersson , Stewart Bryant , "mpls-chairs@ietf.org" , "mpls@ietf.org" CC: "" , "spring-chairs@ietf.org" Thread-Topic: [mpls] draft-ietf-spring-ipv6-use-cases - almost completed WGLC Thread-Index: AQHSxW17bKDzWOmEkEaSkH1DswbWnKHmCaMA Date: Fri, 5 May 2017 17:05:58 +0000 Message-ID: References: <1452d116-c861-ebda-4989-39a93bfdbe8b@gmail.com> <393098d4-6a64-6c38-699b-3060b0ee27c5@pi.nu> In-Reply-To: <393098d4-6a64-6c38-699b-3060b0ee27c5@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.230.208] Content-Type: text/plain; charset="utf-8" Content-ID: <7115CDBCC903314381465D67BF227E0C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] draft-ietf-spring-ipv6-use-cases - almost completed WGLC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 17:06:03 -0000 T24gNS81LzE3LCAzOjAxIEFNLCAiTG9hIEFuZGVyc3NvbiIgPGxvYUBwaS5udT4gd3JvdGU6DQoN CkxvYToNCg0KSGkhDQoNCj4gSXMgaXQgcG9zc2libGUgdG8gZ2l2ZSB0aGUgTVBMUyB3ZyB0aW1l IHRvIHJldmlldyB0aGlzPyBBcyBmYXIgYXMgSSBjYW4NCj4gc2VlIHRoaXMgd2FzIG5ldmVyIGJy b3VnaHQgdG8gdGhlIGF0dG50aW9uIG9mIHRoZSBNUExTIHdnLg0KDQpUaGlzIGRyYWZ0IGlzIG5v dCBhYm91dCBNUExTLCBpdCBpcyBhYm91dCBkb2N1bWVudGluZyBJUHY2IHVzZSBjYXNlcy4gIE1v cmUgZXhwbGljaXRseSwgaXQgaXMgYWJvdXQgdGhlIGNhc2Ugd2hlcmUgb3BlcmF0b3JzIGRvbuKA mXQgd2FudCB0byB1c2UgdGhlIE1QTFMgY29udHJvbCBwbGFuZSB3aXRoIHNlZ21lbnQgcm91dGlu Zy4NCg0KU3Rld2FydCAoaW4gaGlzIEdlbkFydCByZXZpZXcpIGNvcnJlY3RseSBwb2ludGVkIGF0 IHRoZSBmYWN0IHRoYXQgdGhlIGRvY3VtZW50IHVzZWQgdGhlIHBlcmNlaXZlZCBsYWNrIG9mIGFi aWxpdHkgdG8gcnVuIE1QTFMgb24gYW4gSVB2Ni1vbmx5IG5ldHdvcmsgYXMgcGFydCBvZiB0aGUg anVzdGlmaWNhdGlvbiBmb3IgSVB2Ni1iYXNlZCBzZWdtZW50IHJvdXRpbmcuICBJIHRoaW5rIHRo YXQgdGhlIGNvcnJlY3Qgd2F5IHRvIGFkZHJlc3MgdGhhdCBpcyB0byB0YWtlIHRoZSBmb2N1cyBh d2F5IGZyb20gTVBMUyDigJMgdGhlcmXigJlzIG5vIG5lZWQgdG8gZXZlbiBtZW50aW9uIGl0IGlu IHVzZSBjYXNlcyB0aGF0IHdvbuKAmXQgdXNlIGl0Lg0KDQpUaGUgYXV0aG9ycyBoYXZlIGFncmVl ZCB0byByZWZvY3VzIHRoZSBkb2N1bWVudCB0aGF0IHdheS4NCg0KSW4gc3VtbWFyeSwgSSBkb27i gJl0IHRoaW5rIGl0IGlzIG5lY2Vzc2FyeSBmb3IgdGhlIG1wbHMgV0cgdG8gY29uc2lkZXIgdGhp cyBkb2N1bWVudC4gIEV2ZW4gdGhvdWdoIHdlIGFscmVhZHkgZmluaXNoZWQgSUVURiBMQywgaXQg d2lsbCBzdGlsbCB0YWtlIG1lIHNldmVyYWwgd2Vla3MgYmVmb3JlIHRoZSBJRVNHIGNvbnNpZGVy cyBhcHByb3ZhbCAoYmVjYXVzZSBJ4oCZbSBmb3J3YXJkaW5nIHRoaXMgZG9jdW1lbnQgaW4gYSBj bHVzdGVyIHdpdGggb3RoZXIgcmVsYXRlZCBvbmVzKSwgc28geW91IGNhbiBzdGlsbCBzZW5kIGNv bW1lbnRzIGFib3V0IGl0LiAgSG93ZXZlciwgcGxlYXNlIHdhaXQgZm9yIHRoZSBhdXRob3JzIHRv IHJlZm9jdXMgdGhlIHRleHQgYW5kIGF0IGxlYXN0IHBvc3QgLTExIGJlZm9yZSBsb29raW5nIGF0 IGl0Lg0KDQpUaGFua3MhDQoNCkFsdmFyby4NCg0KDQoNCg== From nobody Mon May 8 02:00:13 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C12312945B for ; Sat, 6 May 2017 08:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=orleans.occnc.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 fvTb7z8PpILv for ; Sat, 6 May 2017 08:15:19 -0700 (PDT) Received: from mta3.somerville.occnc.com (mta3-em1.somerville.occnc.com [IPv6:2001:4830:c400:203::171]) (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 E494B129454 for ; Sat, 6 May 2017 08:15:18 -0700 (PDT) Received: from harbor1.v6only.occnc.com (harbor1-em2.v6only.occnc.com [IPv6:2001:470:88e6:2::230]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: curtis@occnc.com) by mta3-em1.somerville.occnc.com (Postfix) with ESMTPSA id 07CDD12FDB; Sat, 6 May 2017 11:15:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=orleans.occnc.com; s=curtis-orleans; t=1494083717; bh=mUI7nE+S1BIKlCsF6FPkLdbssq3PlouyVfO1Sr5DqbM=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=QgAdapFX9++Np5RqEZZW/O2ZlbzoCopn541hUmdxMzd9G/4sKT6BjGcMinuKkNJRf 80ooOc3iKytlM9k0QewR68KO10JO6z9IM+1AjR/dtnPFbBYnybwHP/ltkrdSJGtlHJ kMPt5unyK3+2TJOD70M7ltCMizeXfPDpLx4YYMmA= To: Stewart Bryant cc: Curtis Villamizar , mpls@ietf.org Reply-To: Curtis Villamizar From: Curtis Villamizar In-reply-to: Your message of "Thu, 04 May 2017 14:19:07 +0100." <93e688f5-0072-0853-337b-df9364b56f68@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11993.1494083705.1@harbor1-em2.v6only.occnc.com> Date: Sat, 06 May 2017 11:15:08 -0400 Message-Id: <20170506151518.E494B129454@ietfa.amsl.com> Archived-At: X-Mailman-Approved-At: Mon, 08 May 2017 02:00:11 -0700 Subject: Re: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 15:15:22 -0000 In message <93e688f5-0072-0853-337b-df9364b56f68@gmail.com> Stewart Bryant writes: > > On 28/04/2017 20:26, Curtis Villamizar wrote: > > Loa, > > > > The document is coherent and possibly useful. The question of IPR > > should be resolved before accepting this as a WG document. > I will leave the IPR issue to the chairs. > > > > > Briefly: > > > > 1. The document proposes a change to forwarding. Whenever a change > > in forwarding is considered, there should be a very substantial > > benefit and interoperability with older hardware should be > > considered in the document. > The important thing is that the change to forwarding is confined solely > to the > PEs that are using this function. There is no change to any of the P > routers needed. Forwarding at intermediate routers which do ECMP is affected. If you add a label to LM/DM measurement traffic but not the traffic intended to be measured, then the measurement traffic is likely to take a different path. If you add a label to both the measurement traffic and the non-measurement traffic, and the label value is different, then the path are likely to be different. If the label value is always the same, then the label is a NOOP. For the purpose of discussing LM/DM traffic path, ECMP should be interpreted as all forms of ECMP, including at L2 such as Ethernet LAG or equivalent behaviour over other high capacity links. > Furthermore, in the application that triggered this work, pro-active packet > loss measurement, the action required is to count the number of packets > received on a label, and that is something that a lot of chips already > do. In such > a case the change is a technical change to the forwarding behaviour > specifying > an action that is already deployed. The LM measurement needs to be made on the same path. > In other cases, where a net-processor is deployed, it is a case of > vectoring from > the LFIB to a different routine. Given that the additional > functionality is needed > by the PEs such a change is not unreasonable. What you are trying to accomplish is getting a classification label into the label stack. To support ECMP, that label cannot affect ECMP if the classification label is not intended to affect the traffic path. > > 2. The document leaves open the question of dealing with ECMP in > > section 4. The first option in section 4 is not viable. > I do not understand why this is not viable, other than perhaps due to > stack size limits. > The EL solution requires support for EL along the LSP which may not be > available. > Indeed I am not sure how widely available it is. Thus I see option 1 as > a method to be > deployed in the absence of EL support. > > We can discuss whether this is listed first or second. At this point EL support may be at some nodes in the path but not others, or at all nodes, or at none. Adding a label to identify flows (such as ingress on a PTMP LSP or measurement traffic on LM/DM traffic) can only not affect ECMP in the case where EL is supported on the entire path. > > The > > document should drop this and expand on the second "worthy of > > consideration" solution, explaining how it will work in the same > > level of detail as provided in 3.1, 3.2, and 3.3. > > Sure, that can be added. Adding it is fairly simple, although I do not > see why > that cannot wait until after adoption, since it is the duty of the editor to > reflect the consensus of the WG. Before adoption you need to insure that a viable solution exists and also that a reasonably efficient solution is proposed so I would like to see you complete that exercise. Ultimately the WG decides. > > 3. In the VPN example a perceived advantage of MP2P LSP is lost. > > With MP2P LSP, the number of application labels needed is the > > number of VPN IDs. The number of labels needed becomes number > > of VPN IDs times the number in ingress. If Section 3.3 is > > supposed to address this, then this is not clear and therefore > > could benefit by referring back to the example and stating that > > the SFL could indicate source only and the application label > > indicate VPN ID only. > Sure we can text to address the scaling concern, and expand the > processing text. > Note that whether scaling is a concern or not will depend on how many VPNs > need SFL actions, and on the chosen ECMP approach. What I was getting at above is a reason to decouple the label providing the action with the label identifying the flow. > > More detail: > > > > Forwarding of labeled packets currently involves some special > > processing of labels 0-15 and some form of lookup in a table or TCAM > > or other structure with the lookup resolving to a set of operations. > > At mimimum these operation are SWAP and forward to an egress > > optionally after considering ECMP (EL or rest of stack), POP and look > > at next label (or assume IP payload if no next label). Forwarding > > hardware currently need not support a POP and look for IP payload. > > That operation is only required of the IPv4 Explicit NULL Label and > > IPv6 Explicit NULL Label. > > I do not see what in the text causes you to raise this point. An SL has > the same > semantics as the label it replaces plus a side-effect. If the original > label implied > IP, so will the SL. As I said earlier, if the side-effect is other than > increment a > counter (which is common anyway) then the side effect is new functionality > which needs implementing anyway. Some routers didn't do POP and look at payload on ordinary labels, or did so at lower PPS rate. They could make that special operation (at all or at full speed) only for Explicit NULL. Otherwise a label lookup was required, followed by an IP lookup. That is why PHP came about. Some routers assumed PHP was always available and could not do any form of POP and look further except on Explicit NULL. Since MPLS/TP prohibited PHP, maybe those routers are all gone. You asked why I brought it up. > > Second, both Explicit NULL labels in > > RFC3032 are required to be at the bottom of stack in RFC3032 with this > > restriction removed in RFC4182 for proper operation of the pipe model > > when not using an ordinary label POP at egress. > > > > The changes to forwarding are: > > > > 1. Processing of an ordinary label (label not in the 0-15 range) > > must be able to POP and look at the IPv4 or IPv6 payload to > > conform to section 3.2 of this draft. Currently this processing > > can be fixed to label values 0 and 2 respectively. > > > > 2. Processing of an ordinary label taking on the function of an > > explicit NULL and processing of an explicit NULL label must be > > capable of handling ELI and EL below the SFL or Explicit NULL > > and then take the same action as would be taken for Explicit > > NULL after the ELI and EL POP. This would be needed to support > > pipe model as described in RFC4182 and not change the > > penultimate LSR to SWAP a lable for SFL or Explicit NULL and > > remove ELI and EL from underneath. > > > > I'm assuming that SFL would not map to special labels other than > > Explicit NULL but such a statement should be made explicit. Although > > if applied to RFC 6374 then SFL might also map to GAL. > I had been assuming that if you wanted a GAL you would put it in there. > I wonder if the EN equivalence is confusing and we should look at other > equivalences. > > There are a number of alternative equivalence models we can look at that > have the same properties: > > If you assume that the LSP label has already been popped (due to PHP) it > the SFL could be considered as equivalent to a non-popped LSP label. > Alternatively I suppose you could model the SFL as a VRF label with > the lookup performed in the base topology. I think the problem is that the EN equivalence is problematic, not that the EN equivalence is confusing. It is true though that the EN is processed at the egress and that the egress can not agree to perform the SFL function if it is in any way problematic, for example problematic in forcing slow path as Andy pointed out. > > If SFL can map > > to other special labels, then those others from the set of 0-15 > > including mapping to ESPL should be mentioned. > > We will put text in on the subject. Thanks. > > Each time a new > > special label is defined there are complaints about changing > > forwarding. If now any ordinary label can map to a specific set of > > special labels, or worse to any special label, then this is a > > substantial change in the definition of MPLS forwarding. > That is not where I think this should go either. I think that it needs to > behave exactly as MPLS normally behaves except for the agreed side > effect in PEs configured to have the required behaviour. I think what you are ignoring in the "exactly as MPLS normally behaves" is consideration of ECMP along the path for measurement traffic. > > btw- In practice the IPv6 Explicit NULL is rarely if ever used but > > instead POP of an ordinary label at BOS, label zero (IPv4 Explicit > > NULL) at BOS, or lack of a label stack after PHP looks for the IP > > version in the payload. Does any RFC say to do this (combine the > > meaning of IPv4 Explicit NULL and IPv6 Explicit NULL and look at IP > > version in the payload) or is this just common practice for almost 20 > > years that escaped getting documented? > > I am not sure this impacts this draft. It was just a comment on whether anyone actually uses IPv6 Explicit NULL, which could also bring up the question of whether anyone uses any Explicit NULL rather than Implicit NULL (where payload is exposed at egress and therefore the IP version nibble is checked. > > The second issue relates to ECMP. Section 4.1 item 1 suggests that > > "The operator can elect to always run with the SFL in place". If the > > value of SFL is different for data traffic and PM traffic, then the PM > > would not take the same path. This would put each "flow" in a > > multipoint to point LSP (ie: LDP) on a separate path which for ECMP is > > not an issue. > I would expect that the instrumentation packet go with the same SFL it is > collecting results for. Are we talking about direct measurement LM or counting PM packets? If the former, then yes they have the same SFL. Back when MPLS was having the TP PM discussions, the notion of sending PM test traffic slow pathing simply to support those counters was popular because most hardware could not capture the exact LSP count at the moment a PM measurement packet arrived, only some time after the packet arrived since the measurement packet itself was slow pathed, or semi-slow pathed in some chip microcoded engine added for OAM. As I understood it then, very little hardware (if any) at the time could support a slow path with LSP counter snapshot, that would be needed to support the sort of highly accurate LM that direct measurement would provide. So are talking about applicability to LM (rfc6374) direct measurement only? If so, please say so. For inferred measurement I don't see how using the LSP counters helps. RFC 6374 section 3 describes LM using inferred measurement (stop sending, wait, then send query). If this is the case and you are LSP counters then you have an ECMP problem without EL. > > If the only purpose of the SFL was maintain separately counters for > > specific multipoint to point LSP ingress then lack of SFL for other > > ingress has no effect. In this case the "solution" described in > > Section 4.1 item 1 is a NOOP. > > > > If the purpose is to also provide separate PM for specific (or all) > > multipoint to point LSP ingress or provide separate counters for PM > > for a point to point LSP, then the "solution" described in Section 4.1 > > item 1 fails. > > > > Section 4.1 item 1 therefore needs to be removed. > > I don't think so. > > If you instrument one flow on a long term basis and leave the SFL in place > the behaviour is always the same. How does that fail? We are back to the question of whether PM traffic has a different SLF value than the traffic it is measuring. And then we are back to the PM slow path counter snapshot time lag issue. If chip vendors took note and fixed this such that LM direct measurement now works (accurate counter when sending and accurate counter read on reception), that would be great news but for me it would be news. Also I don't know of any hardware capable of direct measurement of DM or any advantage to having LSP counters available for DM. The one case that I can see an small advantage in inferred LM measurement is where the LM test packets carried a unique SFL and could therefore be counted and tossed rather than slow pathed. This would require a different SFL value that the flow being measured. If that case is being considered, then Section 4.1 would not work. > > The implications of Section 4.1 item 2 need to be better explored. > > The section as-is constitutes a "punt" on the problem of ECMP with SFL > > used for PM. A diagram of each case in Section 3 with ELI and EL can > > be added in Section 4 or the optional placement of ELI and EL. The > > behaviour when ELI and EL are present can then be described in Section > > 4 with penultimate LSR behaviour in addition to egress LSR behaviour > > described for both PHP and non-PHP case. > That text can be expanded in a future version. Thanks. > > Nits: > > > > In "Abstract" the phrase "on the on the" should be "on the". > Ack > > > > In Section 2 "defined to be a label" is awkward. > s/to be/as/ > > > > > An alternate: > > > > An alternate to the proposal here would be to make something like what > > is in Section 3.3 the only case, but where a ESPL range is used. This > > would add egress processing without stepping on ECMP since SPL and > > ESPL are excluded from ECMP according to RFC 7274. > > An interesting idea, but I am not sure how widely EL is supported, and > it has the > disadvantage that it needs new dataplane changes to process the EL, whereas > the advantage of the proposal in the text is that for the common VPN and PW > case the existing h/w works out of the box in a lot of cases. Everyone I talked to making a new chip in 2010 timeframe was aware of EL and addressing it, though I only talked to a subset and only those considering new product on the higher end. Any multiple 100G interface chip today is of that generation, though I can't be sure roadmaps turned to real product. Anyone using an high multiple of 10G chip would probably use a newer chip due to space and power and is likely to have EL. Its lower end products that may very well be using older chips just because they cost less and space and power is less of an issue in that product space. For rfc6790, bets are off for chips designed before about 2010 and I suspect lower end chips will lag. If there is no EL support then nothing is Section 4 will work. > > An ESPL with a few > > top bits always set and less than 20 bits of range could be considered > > (for example XL + 1111xxxxxxxxxxxxxxxx for 16 bits of range and 1/16 > > of the ESPL space in RFC 7274). This range would be defined such that > > it is application specific, is added at ingress, completely ingnored > > along the way and provides the some egress specific functionality. > > Not only is that new functionality in the core (ignoring a label > following and EL) > but it then remains unclear how ECMP then works. If a mid LSP LSR doesn't support EL, then it will do ECMP on all labels. Your entire Section 4 fails to get measurement and real traffic on the same path (except direct measurement). At the mid LSP LSR this proposal misbehaves in the same way. In both cases only the egress LSR is affected. In this case, no SFL functionality is needed (and no increase in number of ordinary labels that need to be acted on). The XL and next label have to be removed to expose the payload and then a counter is based on the low 16 bits of the label following XL. The forwarding action (PW or VPN or whatever) and the counting action are decoupled. > On the other hand we could (which is what I thought you meant) assign a > meaning > to the EL value agreed between PEs and have the load balancing use the > EL value > and have the SL behaviour be based on the SL value. However this is a > forwarding > change and an ECMP path change, and can only be applied once whereas the > proposed design could have multiple SFLs in the stack, say to monitor > an LSP and a PW. No ECMP change is needed. RFC 7274 already prohibits using SPL, XL, or ESPL label for ECMP. There is no change at all to ingress except push more labels, none at all for mid LSR including PHP LSR, and only change at egress. > > Most implementations that support RFC 6790 are likely to also support > > the prohibition on using ESPL for ECMP since the documents were in the > > MPLS WG at about the same time, though publication of the latter > > lagged about a year. This alternative also solves any scalability > > problem associated with combining source and application label > > functionality into one label. It does add two labels to the stack > > depth but newer hardware should no longer be constrained to very > > shallow stack depth. This alternate also might be an even more > > attractive option if IPR becomes an issue with the current proposal. > > I have no idea how to respond to this given the IETF rules that prohibit > discussion > of IPR terms. The WG choice may be no IPR vs IPR with currently unknown IPR terms given lack of an IPR statement. > > Summary: > > > > well written document. not a great design. multiple problems as > > defined. possible IPR issue. > I agree with the first :) > > I disagree with the second :( Its really just the thorny ECMP questions. ECMP is not to be ignored IMHO since we have to consider non-TP. > Working through problems is part of the WG phase of development, and as > far as > I can see the alternative you propose has problems. What I do know is > that the > underlying problem we seek to solve is important and as far as I can > tell this is > the best proposal on the table. I remain unconvinced. Using SFL: no ECMP - works. no way to support mid LSR counting inferred measurement LM or DM: with ECMP and less that 100% EL support - doesn't work. with EL - works direct measurement LM or DM: works but apparently nothing today supports direct measurement. Using a new ESPL range: egress changes to count on new ESPL before POP optional mid LSR change to count on new ESPL would be nice but not needed (enable per LSP). inferred measurement LM or DM: with ECMP and less that 100% EL support - doesn't work. with EL - works direct measurement LM or DM: works but apparently nothing today supports direct measurement. So it looks like a wash except that there is no way for an ingress and egress to create a label stack that doesn't yield bad measurements if ECMP is present in the path but not known to the ingress or egress and there is a way to support mid LSR counting down the stack a ways. > You keep saying IPR issues, but it is a deficiency of the IETF rules of > conduct that > we cannot have a detailed discussion. The chairs and or ADs need to provide > guidance on how to respond to this. It is perfectly valid to bring up the existance of IPR in a review. AFAIK All you and I can say is "IPR exists and there are four IPR disclosures so far" so WG should read them and wait on completion of the IPR poll for any additional disclosure. > - Stewart Curtis > > consider alternative. any alternative but I provided one. feel free > > to use the idea. :-) > > > > Curtis > > > > > > In message <5774d63c-6980-103e-0b3f-a277db822462@pi.nu> > > Loa Andersson writes: > >> Huub, Andy, Curtis and Kamran, > >> > >> You have been selected as MPLS-RT reviewers for > >> draft-bryant-mpls-sfl-framework-04 > >> . > >> > > [ ...] From nobody Mon May 8 07:52:32 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47591294AC; Mon, 8 May 2017 07:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbbQ_bm09cla; Mon, 8 May 2017 07:52:23 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 DBD911294A8; Mon, 8 May 2017 07:52:22 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id 142so67898389wma.1; Mon, 08 May 2017 07:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=Ay60VtUR7zaLwOWvj0eXpDf0tGMhjA67It2v4F2mtSs=; b=iz8q/PLUbcHViHGWJihVB86pSNHUjWaAm7DU7YMAcktY1jOhnOoW61TV/qWRdJaeKf b+ttod7e9icpiEQ5SqT7qnBrGgzTx/cq09WSH8psY9MgOrm32zK0VJi1NI/T6R6PTv5w 1XbffJrzi9A4EVNHtMrZYTd6MOiTPPgDRgl2VkLWyuN+3A+kBZ/ZgGBcegye1X+2YQ0F ZclYyGab2N9FJqeamnTdbjc1gniLPhB0r3spfr7C3uCImk8drZRWZknPfCLjtfPAYY12 gTmAu27DtWQDDkrcx1ZZD318yY/vqg4STd9jG8e35lcfLLUWsgM9laMth55KYQTdJ2hn mHQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Ay60VtUR7zaLwOWvj0eXpDf0tGMhjA67It2v4F2mtSs=; b=iWUg6tdwuyj2HXcNqALPwPN3dNdpc3/uHARgRmiPzCvhp2VgBtNJQAYlbC5+YXN2rT 5TS5+xCHYbL+tGvy/Yaf4LeD40cTevqRn49NJPSMi4oTimplW6SkQyTH21TXbnhNWf0m 99ZCQTD+1UTYpRo0HJPbnwhoiiiiibN842Yi9mxetRhRj+S59Q4tkU60T/J4zj3d91LV BahG/E/9jJYvywD30n00xqvNvgkHw4IMPusGxsIM7Z/QJ/M9bC0kKbrt20h63qXoFgtF 4iJd5B6WqiX0JH/DdUJyDXNxBWYOe4sa8LQ6OWR5PS37Fxn/5ERrRdREH71pypMenDv+ XrYw== X-Gm-Message-State: AODbwcCG44eBdBVdHGQQtmqYQL21ZawSTt41dsaowkl0BGcBle7ah+kx Ytst+C/JeYQxGAWfr+sltg== X-Received: by 10.28.84.67 with SMTP id p3mr3996922wmi.40.1494255141193; Mon, 08 May 2017 07:52:21 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id 188sm11543970wmf.29.2017.05.08.07.52.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 May 2017 07:52:20 -0700 (PDT) To: bier@ietf.org, "mpls@ietf.org" , "mpls-chairs@ietf.org" References: From: Stewart Bryant Message-ID: Date: Mon, 8 May 2017 15:52:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C3D5D4A3330F8C2AEC6822E7" Archived-At: Subject: Re: [mpls] [Bier] WGLC: draft-ietf-bier-mpls-encapsulation-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 14:52:25 -0000 This is a multi-part message in MIME format. --------------C3D5D4A3330F8C2AEC6822E7 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Please could you clarify whether this document is being reviewed by the MPLS WG as part of this process? Please can you explain how the entropy system works in MPLS? Are you expecting the P router to look into the BIER header, or are you expecting BIER capable nodes to construct an entropy structure in the outer label stack. If the latter, you have two methods available to you the EL system, and the FAT PW system. The former is becoming the method of choice where available, but you have the option of using the later which will work in any network. I find the title a little strange since the union of MPLS and non-MPLS is all networks and thus you ought to cut the title after "Replication". Best regards Stewart On 05/05/2017 23:58, Greg Shepherd wrote: > At WG meeting, IETF97 in Chicago, we decided to move forward to > WGLC for some of our docs. We learned that even once published the > IESG has a process to change the track of the RFC if the WG makes the > case to move the work from Informational to Standards track. The > feedback from operators is that RFC status was more important than > track, and we won't be able to meet our charter requirements to change > track without deployment experience and operator support. > > This email starts a two week timer for feedback on the draft: > https://datatracker.ietf.org/doc/draft-ietf-bier-mpls-encapsulation/ > > Please read and respond do this thread. EOWGLC - 20/5/17 > > Thank you, > Chairs > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier --------------C3D5D4A3330F8C2AEC6822E7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Please could you clarify whether this document is being reviewed by the MPLS WG as part of this process?

Please can you explain how the entropy system works in MPLS?

Are you expecting the P router to look into the BIER header, or are you expecting BIER capable nodes to construct an entropy structure in the outer label stack.

If the latter, you have two methods available to you the EL system, and the FAT PW system. The former is becoming the method of choice where available, but you have the option of using the later which will work in any network.

I find the title a little strange since the union of MPLS and non-MPLS is all networks and thus you ought to cut the title after "Replication".

Best regards

Stewart


On 05/05/2017 23:58, Greg Shepherd wrote:
At WG meeting, IETF97 in Chicago, we decided to move forward toWGLCfor some of our docs. We learned that even once published the IESG has a process to change the track of the RFC if the WG makes the case to move the work from Informational to Standards track. The feedback from operators is that RFC status was more important than track, and we won't be able to meet our charter requirements to change track without deployment experience and operator support.

This email starts a two week timer for feedback on the draft:

Please read and respond do this thread. EOWGLC - 20/5/17

Thank you,
Chairs


_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier

--------------C3D5D4A3330F8C2AEC6822E7-- From nobody Mon May 8 08:29:59 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782C41294B3; Mon, 8 May 2017 08:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzk6SxK3QxWV; Mon, 8 May 2017 08:29:49 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0111.outbound.protection.outlook.com [104.47.41.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4AD5126BF6; Mon, 8 May 2017 08:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cBNxR8HiAetKjGJydHPY4nz/V+oRfRU+zPxLdJ1bo0g=; b=i30EEC3awwwc39lISuoZb4ML/UDlxfWHPE2WEblVsxhfgvsokHAu4YolzTlVdpU4WVXRtoDrBsNswXdfK5I3mr+HFpGoHyyQm3rs98jrLjOXmm938una5Skz0+7wyQfLcf/GnirvykIVJmojw3DNz3EA5hcdkcwkPscXQ4bkoXI= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.37.32] (66.129.241.10) by SN1PR05MB2192.namprd05.prod.outlook.com (10.169.124.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Mon, 8 May 2017 15:29:46 +0000 To: Stewart Bryant , , "mpls@ietf.org" , "mpls-chairs@ietf.org" References: From: Eric C Rosen Message-ID: <24a3794c-f195-a885-2049-cb1f56cfe9d0@juniper.net> Date: Mon, 8 May 2017 11:29:43 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BN6PR05CA0016.namprd05.prod.outlook.com (10.174.92.157) To SN1PR05MB2192.namprd05.prod.outlook.com (10.169.124.140) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 97cb4476-bf02-453a-6d5f-08d496270f42 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:SN1PR05MB2192; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2192; 3:fUkSCxevad/nH2pL7xQnpw6T+Jl5dVkhvN7JjJTPPdQ7Rc0FwfCEbBNhXut4aDzWunPYLJktKI7FsuJux4CYJvMjXMixkBs1AQhb+y7AVGR8UgcjGEsxwvBzGg6LOalA8xv7+xrFa4CQWo54T728BJyyHrsluvu2YazI2c9OS3WZOh2Ud0CPULLSmntDgbfEU220+01jgJmIOI5JYB1DsVFOOAQ3vC9cfB9ButCAkoc5efRCgVfAfSM+bb/u7de28lDVGRJVmoKAK+oy8vtVxAK9DYMe7FBvPZfXTJacPjXMj18E9j00m+6OsbwRWiyvN6GjKTBf+CXO6awPyRbEgPXyCqXJ9ZRaLJymFi0BEog=; 25:BR56R+K6LLM4+XCeHTj9owcqc+KtLXlrjRwSoP082y+m9IBW7TVAY4c6sHl59XPe1SLy9MskeoiIoS99VXVJT48g2C20PoglMlycee69kOW8mjhjAIguAhSCWJ412drtING2Tu5K60A8GCJB323FcksITR0C/vjoIt8oyJQStwXEbWAw05Mp8EArKsdrm9QMzyt7nefmJ/XjvwnRUrInAE35VuJPpPisOoZhDaDdYvcjcgOr8O80RqICmr8HmkREiuqt7n13GnUcsPcKK8NsNr38R18ixmlXlk/3358/fKbYhUE18RAFguRO7WybrYp9Ioh0loG8uK/Xkn3jag/Y6lFcRCMZCVf1Vo+X3Ru96zekr/TBBFEO9auh0XIKquoizJlY6fdvi9NJGeaBWBOfZc52WylGo7ZK8BR7GG/XeILKyhkzxnE3+/KW4G3ZdhJ4qhXx6osNlv4NyAOkx9NtXr3VepXj2ZMDfajTS+rywvo= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2192; 31:q5kiXNd+njHRZjmqoI1uvOpGb+tef7NPf3Lpar1ukpjTrc3IySiIXAJiTJFump4dYUjdNR3UGy6i7n9ql/b5ZLAQoPUn81NgX3HMFlxl/gsnfxmUWBQI0jELGBhpXFK5m4ZZI/1H1M3u80sK7pvingl9wF3s+W5nhuYKyHHIuw8EP71tJryRx0A1ILakuF1QA8nry8bJTqrqOe4LEuoOQrM6EkuuYCEcWc9mehD0k4nNbPWSFAIuLyfw6F0Yif07; 20:Mpim+pCWdL2rMk1BnlqwZ9hUt4FQ5TtIpS7u+xFJDQ0aZ1sj2x+hmg99+TXVLGyqWWq+ALWlkO71B7BF7F75eVrpPD/q75POClgfBexof/zuIZR6SNt8S8CMUTWaYe02eAibfGS8f7L0rq3Kj4mLjcvO3thjZOoKTjT6BQ9+5dHsjlm2e3JMu5icInbtOvvSAViMRpCEyoAqFNZlY9bWDUi0EArjDiXfPZhky0b+fXw+k/+/qmP+mep4xAMRZ7ITFyedGHpgeWnTWEvaYflKfRCKyIc9oqbRoUCZ9YXqY6QkX9gudZhI6XJCUA6t/FcRIpDuQX18RleV5Kpg/sCh8ZOLJSq3o1RM98IOGIhWMZSBgTOFcHQLYX8mxn5jCdYhqD+eVf84Uo51aSes2f1V6IIj+OVSZfrKNh9+xz49UZryZ5fUrPAn4in9mqMwzEhhQyA+pwMB/gyxQymhMP4ImdPLLSqUf65R8FMGmwEfZK+9Jev+/W+B1BpSzr8UAIM+fGNW6TUcZHIkebN470XPvUQbMw0d8cMBKwI3eQdZIJxmH4bS8btjFjIq2IBerH2VFh0A7VAkbASMYI8LxIuZ3EiSy9r53Ajpo6Mmc8ca7L4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(20161123560025)(6072148); SRVR:SN1PR05MB2192; BCL:0; PCL:0; RULEID:; SRVR:SN1PR05MB2192; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2192; 4:pBiO6ejcxZsrUfkigThuQ1oZ14cOUKoLKL2a+gV48mgWPagCG8MMz0pUvxE5hHjZevgMLZZSi9N3QM2CwXxr7Ck/LNcuewopE/eYldbnVZznzQw8wSxO3ptWiDtVEi81n7VIP0ujMuGMOwbbubquHEkz5GqYEXaNyQ9fLsgnQ2I5mEV77QiNQVrkBPEhNaFZ21BqYg/75G/YfRdpIKqqU7i6rEceMnzEz4Cc11dc7GjFC4RL0ZhD7bRvpSwKcgHgdIkaRWXXbUh9YPHaQrmQvZtOtLxO9TUcR21B9jFtUvMFrdnSM2ggt6wG8BthNW23ZxYaTl1ULKxMn31IBXUxlIHVhcxDgXxcyJLbspAv64dbPqK4wkPvtASR9YB/zs7YmoDLwkIbXbgQU1LNVzFGLVZ46ZHtIy5vTPg4DJBfOWmLFhbSBJKukaZO1fZ0tzX5ByUzHEf9bdNRSMk3+2dNjDkFfwlEnhsz4DjvG6pXuFqLaBSMHPtz0tLkistHvNTDG5UHyo+SFGKKFB2aaRKbntqDk4+cM5BnzHcF7Eo0zmLAPm2UHCSM56Tdk9TBLy2WkxJMgmmp8C4E/qABUz9mjydjQCpUCO9y6BZ4Shh6k8sAf7ennt60InTWv0pUC4fKhgxBqJhFGkiDyVDgKX0TLxdiSzwfBWk49ifCm23IMr9JGSZEPa10AfXrL7fP+EwJ1vRhXe4Sk42qhlQUxFZzVyjaY7PBFN8gBEEFPx2izJaryb01FtVyQxNqiv/TkhjbzYHqOm4nihuU8N3ArzH3Xa5cxQ0ylv5Iy8KNkedOGE48Fzw7/A26hVvMDqFw2PDY X-Forefront-PRVS: 0301360BF5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39840400002)(39850400002)(39860400002)(39410400002)(39450400003)(377454003)(24454002)(478600001)(7736002)(33646002)(36756003)(305945005)(5660300001)(2201001)(47776003)(2501003)(25786009)(53546009)(3260700006)(23746002)(38730400002)(83506001)(230783001)(2906002)(53936002)(2950100002)(86362001)(90366009)(6486002)(6666003)(77096006)(3846002)(65956001)(6116002)(42186005)(31686004)(81166006)(4001350100001)(50466002)(230700001)(31696002)(229853002)(8676002)(50986999)(64126003)(189998001)(54356999)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2192; H:[172.29.37.32]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; SN1PR05MB2192; 23:cBqagIaT2LOFRQneRTLD8pl+tQAqQ6hAtFwUo?= =?Windows-1252?Q?IXU45u0OOdQotuYdsXcgBcH8eJ6DKmNduoi+5iGJLxmIbvtqcQdTsYRv?= =?Windows-1252?Q?Z/hsHlIobhrHLqo9ascAf+8r4tmyb+7ZzRHKvo/OdFzU4lEwR/MIJqIQ?= =?Windows-1252?Q?urp1J1SUJjPd+eNpRrNOGI27ezbTA5/KJ3HWcywR+RcThAUmE6aAYiDj?= =?Windows-1252?Q?drVIoaOH2dScrqP9Y4JI4Nl2/VIb49+ZHcB5OhUbounRn4aq5padSsne?= =?Windows-1252?Q?YKW9aaIL7YYF4nIphm50AQL56EBlVT1lvSi+wuGsn4grypTeIAsZCRlr?= =?Windows-1252?Q?c+yNQIbfT5GLJcuiggmvdlfe5buD/HD+R0LSPjbcpTpYCWlKcZOYFK38?= =?Windows-1252?Q?SgUr2YuzXOObTBD3ISChEcnkes/RddX0d7C9KCZQmYr9+AsVrThizs8i?= =?Windows-1252?Q?jnXz8/10TRfxRkwk+8PD8RaEVCxRfMPChbmq0IkcAs/1lpjNjKCP+HnG?= =?Windows-1252?Q?gPkmNE6lVa+8sY/TH+Zk6juMGBTUqLc8aBoqmYtH1b2mWGRhKtjChSGO?= =?Windows-1252?Q?uEdP7I1A83n+TqGyvLqG+T7i1XVb3JQpOhtdidGNqP2/UOdUi6YCEXkk?= =?Windows-1252?Q?1P0hliHt9NwZK/dJZQ9PS9YDstuRe0kBD11JUnTcKCCrbzJl4X2xejfg?= =?Windows-1252?Q?o12cmYKJ93ChFouCO/qkiwDxXhV+pDC8d1drPUcV0Y5Oi7jsY6ELZdsf?= =?Windows-1252?Q?XOVCszUMgjAGuywX50DnQQvIDzvgNv5PNqBdbY3bhUH6htihaKViPdef?= =?Windows-1252?Q?l7T4cvvWHlnTEhWpoPbhwwMuftoVUpZsyC5HxZZ6RWY7FkqCbTfhAC/2?= =?Windows-1252?Q?f2iJxWwKD7Jr2xwHyWFNN4O21Jko2jmfKwilVPlKua+FtnAUYX2qwgBl?= =?Windows-1252?Q?xl1hGW1XC40TQNtlhkBEAJBx0WjuET5cMLaZsYhlLU8oU4nS9OvlAzRY?= =?Windows-1252?Q?cbrmFzTBdt277ctoKrEYCf+pdD5HdzBSojNPgs4L2GtJ3RQl5g6bXF7h?= =?Windows-1252?Q?PwmXZDnd72WZ1dV5g82392Iw8GR9todAdAu7vHBogxYfyBPl7pZmexbr?= =?Windows-1252?Q?g6tKv0quEuvkL2IJpDzxBfR8m9C2dtJfXiLlgU0ZX7fEkDogddS6f515?= =?Windows-1252?Q?T9rk/+Eb2zNVFGHGVNd0MKnVIGafzUSPea0PgSWmI2/U/qiUObM7Wd8x?= =?Windows-1252?Q?VjS1ICK7h4WWH9Qjw5BZe374inw5n2hJZo7HJ9THm+wW1jfv+nkq3Ki5?= =?Windows-1252?Q?jMjiBp+ufHjO/J4Es/p0SuasyIt/1aTlsjyqMiBAmy8qnn2BFW9oc6rt?= =?Windows-1252?Q?/8NKl57ew/B?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2192; 6:iKASzSimJs1mXds26c8vEO47YSBKY5IYok2UYDmyNvGolRoc2QC4/iSid5JS+RwlvJg59HtQ35uS0jtcokJvg9SFIDwDLiAkPf/FI7uRU2/OwIaVSdcOCXhBrtVerAUiwNqzm0w9rfDxzsBEuUdKvJHEOARp9OZqeJ3NFmajN4z7ODrjhET7J6SLE9HMLORNTWZjkF0yKQzPSmCIGkOpViVW69rzcftONQJ+GKErjWYrlW4mX34ypFKwC8RoEqw/hKXlxgKXTdxMSUUIvxDepofyn/UJjmyiPW/9cwVm8CZJzi1nO1g9BK6MEcJHI4tZjUuNEJnXF+/tX1DmLRQL/Bdjft8lsB8ZX+6OKh4VS8BWCcLlzFDt7N3k5ZxMvCV0/mEpXqPFl0KDayI1fjeX0rborvybMBHjtHh24J8GLq2xLaiya1jcX0Q7VLqa/CBTdTj3hFbvnc8vaEcTw9Nx5kKhwpB6EPT6CFwI5KCOduI1jFz7UochSWKMCRvDbK6O6ueHiCO8g+08GWpBSzcFOLBAGdAC085BdCo1pt304iA=; 5:pJFWp8vpBOaaSlAfI822Aiovr0h+hZS0ffi4A88nC+6KugSJXCLufDXFSU7tAQqZHbwxAh6XRy3YzhO2bK9VkzhgPfn7GFOvEx/c7hqHMakPjrxUFFruWv0ebi7+XPFOWkUwqMjqwLjpw2zU1/PlXA==; 24:tAdqITRdRwx1rqtBjW/GcvM4gVdr1cS/+Zmm8Eo9wuJCIfvFZZyrvHxiJbADK+Hwtn9DX3dGHp6hhsBGFRVcd8BDzS9KziqYYl7wKJrxF/8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2192; 7:xeUQ+78HTsBsFJUuYwHWRntAig4GMAV+d8EF9XzAUnVN9kPTkVJ9i7Gce3koxj+KE9f5wQXmDSyYfg++M+y67iJ15fPNNplgRzmHx3FJgzcVDvKqVMOKq1nHiPgg/H0W7c0V2LRfuPucVzOgqRQX8vAI7iMibwnj/QVBcorlgnCeroBzDOHU+DikJ4R+XSTzHccx3eWtbsMCXoIPyxiXh1HDfwmBxsiAsRxf0tur/O1EF6+4OQyQl1UaRrTMOBbAEG3CeWkIiCE1gJ7Dx6njkT9e1ao9mh9L0fWzWJduQeuwB/FoPWKFkkLxFqmoOvXiZbtoSe5o38BJhLY9KLkswQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2017 15:29:46.3266 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2192 Archived-At: Subject: Re: [mpls] [Bier] WGLC: draft-ietf-bier-mpls-encapsulation-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 15:29:50 -0000 Hi Stewart, Thanks for your review! On 5/8/2017 10:52 AM, Stewart Bryant wrote: > > Please could you clarify whether this document is being reviewed by > the MPLS WG as part of this process? > I'll let the WG chairs answer that ;-) > Please can you explain how the entropy system works in MPLS? > > Are you expecting the P router to look into the BIER header, or are > you expecting BIER capable nodes to construct an entropy structure in > the outer label stack. > A router that is BIER-capable uses the entropy value from the BIER header as part of its BIER forwarding process. This is discussed in the BIER architecture document. If a packet is being tunneled from one BIER-capable router to another, and the tunnel passes through a sequence of intermediate routers, then the tunnel encapsulation probably has some entropy mechanism of its own. It would make sense to ensure that if two BIER packets have the same entropy value in their respective BIER headers, then they have the same entropy in the tunnel encapsulation. However, the tunnel encapsulation is not the BIER encapsulation. and how the tunnel encapsulation header is formed is outside the scope of this document. The BIER entropy field does happen to be 20 bits long, so if the tunnel encapsulation is MPLS, the BIER entropy could be copied into the EL. > If the latter, you have two methods available to you the EL system, > and the FAT PW system. The former is becoming the method of choice > where available, but you have the option of using the later which will > work in any network. > This seems like a general issue about MPLS tunnels, not a BIER-specific issue. > I find the title a little strange since the union of MPLS and non-MPLS > is all networks and thus you ought to cut the title after "Replication". > > Originally the draft only discussed MPLS networks. When a non-MPLS encaps was added, the title was augmented with "and non-MPLS networks". I don't really see a problem with it, as it emphasizes that two encapsulation mechanisms are provided. Eric From nobody Mon May 8 08:45:20 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F313F127275; Mon, 8 May 2017 08:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8G9RnHNjw6t7; Mon, 8 May 2017 08:45:11 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::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 7B07E126B6E; Mon, 8 May 2017 08:45:11 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id d127so7964693wmf.1; Mon, 08 May 2017 08:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Un6iqHovBvLakupZTZiCPj8FX0dn+Ky57R1EdJjSv3Q=; b=AMGqA4a7GjASe6O8Acrm5ODnNwtsNJvqtZvvSzr8BbUnVUB/Zetg+VMhMpzcSFVkNq ImTJjV6uPFOgtEZjpKnwM8UPu96QYsVEcoF3RWct/0sf5QA3CRWZaH6iPrzaQZ0Juyh9 yP0QE5n6QlH6QHkJpYHvIFjwwMUPny92SyxAhJc0bn25GMMJvZQwfpHd6Y3zFBl78fZ5 XXNbNdenXLbO2QnZ/mz7BoLbmzdqVfgev0LBtjm0eI4b8wRvcQxNyGdTqOhrZTCVI9Kh F2VtvQSRYVJAaGWvu47K9ACqGGXPvfZ1EmzW6NSko0myMoyFZVd38LbTv3kguow0jawB /yvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Un6iqHovBvLakupZTZiCPj8FX0dn+Ky57R1EdJjSv3Q=; b=f452GAxdNRBJYL7l7GC/4eFjxPf9Cy8q/ZRcyAOviPFODSK89IEzDOzv92cGD9SvX1 8oquQZluM3BazEcS17yM0cE9vtbow/L+JkTw9jAZ53Y0Zx+6JNJa+wy9QkGRY1GkAoBj 9R2yG8C0BaGZIGzTrnRRc1HWZUfVO3d0glPx1k4jbZisnC2i4SFczK6NAbJ0jKY2Z8TL IFeL+Rv3COUZy/HnOm80Fqw+l8GU0T4eETDooql9foakLyZ6Ulk0uQGjwiPbMkeqeQ98 kxReZWdjaNDJTHWfvGQ+fPiIDcbikIvkpVn3UdwX401Mz1OvlQI+RSViCTcoIWoOXX9+ Ntfg== X-Gm-Message-State: AODbwcC+Oh4G5VodlITIpppb0qCYsIsGKt+XeJrW3vPkpE40g6WDk9WI HXcqNMrjiR3RaA== X-Received: by 10.28.203.143 with SMTP id b137mr2740945wmg.115.1494258310028; Mon, 08 May 2017 08:45:10 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id y60sm18378705wrb.39.2017.05.08.08.45.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 May 2017 08:45:09 -0700 (PDT) To: Eric C Rosen , bier@ietf.org, "mpls@ietf.org" , "mpls-chairs@ietf.org" References: <24a3794c-f195-a885-2049-cb1f56cfe9d0@juniper.net> From: Stewart Bryant Message-ID: Date: Mon, 8 May 2017 16:44:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <24a3794c-f195-a885-2049-cb1f56cfe9d0@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] [Bier] WGLC: draft-ietf-bier-mpls-encapsulation-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 15:45:13 -0000 On 08/05/2017 16:29, Eric C Rosen wrote: Hi Eric, > However, the tunnel encapsulation is not the BIER encapsulation. and > how the tunnel encapsulation header is formed is outside the scope of > this document. That seems odd. The document seems to be about how you operate BIER in an MPLS network, and so I would have expected tunnelling over MPLS to be in scope. - Stewart From nobody Mon May 8 09:12:30 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CE01294E6; Mon, 8 May 2017 09:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_lcEl6lzu_Q; Mon, 8 May 2017 09:12:20 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 7BBE9126C0F; Mon, 8 May 2017 09:12:19 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id b84so60349295wmh.0; Mon, 08 May 2017 09:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lfVVbylDNYlbAd3To5wJKF4engt4ltWsUrWpKOpERGY=; b=I7aDi1PcNkkV3SbzZFILWu4+QuxJDzP0mlcnzsQdfuKDiNTqLUenSAsffc9M8E5+Qq 7Rb3vdUtTXxg8zb27hTNutZ7X/CY5cIwTHBaRknsmQ2HWIVcZ2xi/i5JamMBLbpz3CXd 2gVQ3SlQ2S1t3gqgtLAN5a7B6B3comJwlyB7rn9C163KYj6RLY8vtOqgacU+bqdLNb2k kvy5Cko0uJ1yQ0YBahL6/Uy7PHzVkyjj6sB4sLUEA+XCTU/z4atX1dGVPJJdZMZD5wo+ 49yvPeEcoosnxBezcOOYMY7Ee8Dw99EtnCd3W2S7IPntDWjHZ7P5aB57YZrmbDdPsfzN /pKQ== 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=lfVVbylDNYlbAd3To5wJKF4engt4ltWsUrWpKOpERGY=; b=aIuNoiOdbu3bBoN9UVa+L4Zu0JdETqDnq2XVA0OWj8oil0Y2x1ieJewMeXglz5ZkfZ L0V4Eo3sl19+lim/aQ8pdnDUyqY2Q4G5jXX5Hb/R6cCYxr9yoMw7Sxven+4juxH+pM/y bmjGc/nMHszEIAMTdXg86OnhOoX6I/55Ze6ONteNCQqEFsWETPUgDI0vdGg7Xmqcokjc wq6/FJxk4ilnLBkx3d1BdYypAJsD5kz4a5fnZjEz6pl6DJJEGpIc9+1cdSNzPafvobBB ckyOj5tT2xygWu/vsl77sPUl2EabLSh6sTxNKq78AT1yRyQjDzLllwIRBoMnyOtEGy2Q zsZA== X-Gm-Message-State: AN3rC/6tOtlF/rkLwp7DWms99Y3pYrQI5JLK3jbQ5N7ufbm+/tYvlWGC 4kjstjjRuj/MmvshEBzpmHkG0NujoQ== X-Received: by 10.80.212.211 with SMTP id e19mr19749368edj.164.1494259938014; Mon, 08 May 2017 09:12:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.159.37 with HTTP; Mon, 8 May 2017 09:11:37 -0700 (PDT) In-Reply-To: <24a3794c-f195-a885-2049-cb1f56cfe9d0@juniper.net> References: <24a3794c-f195-a885-2049-cb1f56cfe9d0@juniper.net> From: Tony Przygienda Date: Mon, 8 May 2017 09:11:37 -0700 Message-ID: To: Eric C Rosen Cc: Stewart Bryant , "bier@ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1af9f8cebc4f054f05808e Archived-At: Subject: Re: [mpls] [Bier] WGLC: draft-ietf-bier-mpls-encapsulation-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 16:12:22 -0000 --94eb2c1af9f8cebc4f054f05808e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My initial reaction was same as Eric's. You either have outer stack =3D tunnel in which case what's inside is irrelevant (well, we know about deep inspection hacks but that doesn't apply here) or the label/tag is BIER. if the label is BIER it's processed by definition by a BFR that uses BIER entropy ... I have no opinion whether e.g. BIER entropy should be copied onto outer stack in case BIER is tunneled in MPLS and I consider it an implementation choice really since I don't see a need for the architecture to mandate this ... --- tony On Mon, May 8, 2017 at 8:29 AM, Eric C Rosen wrote: > Hi Stewart, > > Thanks for your review! > > On 5/8/2017 10:52 AM, Stewart Bryant wrote: > >> >> Please could you clarify whether this document is being reviewed by the >> MPLS WG as part of this process? >> >> > I'll let the WG chairs answer that ;-) > > Please can you explain how the entropy system works in MPLS? >> >> Are you expecting the P router to look into the BIER header, or are you >> expecting BIER capable nodes to construct an entropy structure in the ou= ter >> label stack. >> >> > A router that is BIER-capable uses the entropy value from the BIER header > as part of its BIER forwarding process. This is discussed in the BIER > architecture document. > > If a packet is being tunneled from one BIER-capable router to another, an= d > the tunnel passes through a sequence of intermediate routers, then the > tunnel encapsulation probably has some entropy mechanism of its own. It > would make sense to ensure that if two BIER packets have the same entropy > value in their respective BIER headers, then they have the same entropy i= n > the tunnel encapsulation. However, the tunnel encapsulation is not the > BIER encapsulation. and how the tunnel encapsulation header is formed is > outside the scope of this document. > > The BIER entropy field does happen to be 20 bits long, so if the tunnel > encapsulation is MPLS, the BIER entropy could be copied into the EL. > > If the latter, you have two methods available to you the EL system, and >> the FAT PW system. The former is becoming the method of choice where >> available, but you have the option of using the later which will work in >> any network. >> >> > This seems like a general issue about MPLS tunnels, not a BIER-specific > issue. > > I find the title a little strange since the union of MPLS and non-MPLS is >> all networks and thus you ought to cut the title after "Replication". >> >> >> > Originally the draft only discussed MPLS networks. When a non-MPLS encap= s > was added, the title was augmented with "and non-MPLS networks". I don't > really see a problem with it, as it emphasizes that two encapsulation > mechanisms are provided. > > Eric > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > --=20 *We=E2=80=99ve heard that a million monkeys at a million keyboards could pr= oduce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* =E2=80=94Robert Wilensky --94eb2c1af9f8cebc4f054f05808e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My initial reaction was same as Eric's. You either hav= e outer stack =3D tunnel in which case what's inside is irrelevant (wel= l, we know about deep inspection hacks but that doesn't apply here) or = the label/tag is BIER. if the label is BIER it's processed by definitio= n by a BFR that uses BIER entropy ...=C2=A0

I have no op= inion whether e.g. BIER entropy should be copied onto outer stack in case B= IER is tunneled in MPLS and I consider it an implementation choice really s= ince I don't see a need for the architecture to mandate this ...=C2=A0<= /div>

--- tony=C2=A0

On Mon, May 8, 2017 at 8:29 AM, Eric C Ro= sen <erosen@juniper.net> wrote:
Hi Stewart,

Thanks for your review!

On 5/8/2017 10:52 AM, Stewart Bryant wrote:

Please could you clarify whether this document is being reviewed by the MPL= S WG as part of this process?


 I'll let the WG chairs answer that ;-)

Please can you explain how the entropy system works in MPLS?

Are you expecting the P router to look into the BIER header, or are you exp= ecting BIER capable nodes to construct an entropy structure in the outer la= bel stack.


 A router that is BIER-capable uses the entropy value from the BIER header a= s part of its BIER forwarding process.=C2=A0 This is discussed in the BIER = architecture document.

If a packet is being tunneled from one BIER-capable router to another, and = the tunnel passes through a sequence of intermediate routers, then the tunn= el encapsulation probably has some entropy mechanism of its own.=C2=A0 It w= ould make sense to ensure that if two BIER packets have the same entropy va= lue in their respective BIER headers, then they have the same entropy in th= e tunnel encapsulation.=C2=A0 However, the tunnel encapsulation is not the = BIER encapsulation. and how the tunnel encapsulation header is formed is ou= tside the scope of this document.

The BIER entropy field does happen to be 20 bits long, so if the tunnel enc= apsulation is MPLS, the BIER entropy could be copied into the EL.

If the latter, you have two methods available to you the EL system, and the= FAT PW system. The former is becoming the method of choice where available= , but you have the option of using the later which will work in any network= .


 This seems like a general issue about MPLS tunnels, not a BIER-specific iss= ue.

I find the title a little strange since the union of MPLS and non-MPLS is a= ll networks and thus you ought to cut the title after "Replication&quo= t;.



 Originally the draft only discussed MPLS networks.=C2=A0 When a non-MPLS en= caps was added, the title was augmented with "and non-MPLS networks&qu= ot;.=C2=A0 I don't really see a problem with it, as it emphasizes that = two encapsulation mechanisms are provided.

Eric


_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier



--
=
We=E2=80=99ve heard that a million monkeys at a million ke= yboards could produce the complete works of Shakespeare; now, thanks to the= Internet, we know that is not true.
=E2=80=94Robert Wilensky
--94eb2c1af9f8cebc4f054f05808e-- From nobody Mon May 8 19:42:30 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134A1128D16; Mon, 8 May 2017 19:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju2GqDbPYp1t; Mon, 8 May 2017 19:42:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0F0D128BB6; Mon, 8 May 2017 19:42:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMN25260; Tue, 09 May 2017 02:42:17 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 9 May 2017 03:42:16 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.200]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 9 May 2017 10:42:11 +0800 From: Xuxiaohu To: Eric C Rosen , Stewart Bryant , "bier@ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: [Bier] WGLC: draft-ietf-bier-mpls-encapsulation-06 Thread-Index: AQHSyBBH3GIfSKukREmdtlqFe0rBBKHrSRvg Date: Tue, 9 May 2017 02:42:11 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB9C4CF@NKGEML515-MBS.china.huawei.com> References: <24a3794c-f195-a885-2049-cb1f56cfe9d0@juniper.net> In-Reply-To: <24a3794c-f195-a885-2049-cb1f56cfe9d0@juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59112C89.011F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.200, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7fe02638cd012b777989e3c040d2906d Archived-At: Subject: [mpls] =?gb2312?b?tPC4tDogW0JpZXJdIFdHTEM6IGRyYWZ0LWlldGYtYmll?= =?gb2312?b?ci1tcGxzLWVuY2Fwc3VsYXRpb24tMDY=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 02:42:22 -0000 PiBPcmlnaW5hbGx5IHRoZSBkcmFmdCBvbmx5IGRpc2N1c3NlZCBNUExTIG5ldHdvcmtzLiAgV2hl biBhIG5vbi1NUExTIGVuY2Fwcw0KPiB3YXMgYWRkZWQsIHRoZSB0aXRsZSB3YXMgYXVnbWVudGVk IHdpdGggImFuZCBub24tTVBMUyBuZXR3b3JrcyIuDQo+IEkgZG9uJ3QgcmVhbGx5IHNlZSBhIHBy b2JsZW0gd2l0aCBpdCwgYXMgaXQgZW1waGFzaXplcyB0aGF0IHR3byBlbmNhcHN1bGF0aW9uDQo+ IG1lY2hhbmlzbXMgYXJlIHByb3ZpZGVkLg0KDQpIaSBhbGwsDQoNCkkgcmVhbGx5IGRvbid0IHRo aW5rIGl0J3Mgd29ydGh3aGlsZSB0byBoYXZlIHR3byBpbmRpcmVjdGlvbiBhcHByb2FjaGVzIHdp dGggbGl0dGxlIHNpZ25pZmljYW50IGRpZmZlcmVuY2VzLiBJTUhPLCB0aGUgb25seSBkaWZmZXJl bmNlIGJldHdlZW4gdGhlIHR3byBhcHByb2FjaGVzIGlzIHdoZXRoZXIgdGhlIGZpcnN0IDIwLWJp dCAoaS5lLiwgdGhlIGluZGlyZWN0aW9uIGtleSkgaXMgZGVlZGVkIGFzIGFuIE1QTFMgbGFiZWwg b3Igbm90LiBJcyB0aGF0IHNvIGltcG9ydGFudCBpbiBuYXR1cmU/DQoNCkJlc3QgcmVnYXJkcywN ClhpYW9odQ0KDQo+IEVyaWMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IEJJRVIgbWFpbGluZyBsaXN0DQo+IEJJRVJAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iaWVyDQo= From nobody Mon May 8 20:33:14 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39301293F9; Mon, 8 May 2017 20:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUt8-0Ec83B6; Mon, 8 May 2017 20:33:09 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 9EAFD126C2F; Mon, 8 May 2017 20:33:09 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id l18so73367945oig.2; Mon, 08 May 2017 20:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=OA+/AoIVq22yNANfyGt50aie02oIvPaFlKvYBAbRgS0=; b=kb1KueaYL4Z/IlDaylIujRHjx+GuT78nw+EX/tvq/DWRdw00pkkpj46sGCspl8IWty V90IpOEP7pesrxkz6I1gz7cj0mobtKk0Dl+/NkUK2PQ6Cpvsi5hz4I2/g0OPmFU+Y6gG shF/Rpx9eWd9VoWDBkalqTE7o1waywbGwCejunF5fESq9kZ+GYAKAXr/pnvNYpG2FknS OWU16NEtf/W5Sy3IpUT2mzTA2U42zGwelgrILAKcnnCSLCi3X3v5lqkbpP0m2JF85Lu+ j42ktCpTYOcpOV1KWaO5dPD3LpCgGdNhbCEONmdTShHaqV4FqMwWWhLP36woSwozKEJV W/6g== 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; bh=OA+/AoIVq22yNANfyGt50aie02oIvPaFlKvYBAbRgS0=; b=lA5nJ8MRAieQ4CR6Ff6WyCm0UeRrAQCz1lcjuC1fOL4fxENlsp1Z4r1LmQZGD+kJB1 x36rrnoi9DQ7AuiYm+MhADp2BHjXJjDBhyFVOhsIu+5kKVYkn4AyIGxWqGYEzr3UEqLc bbL9f93n0jdsMhwDjiwSK22u6hdYd4YEr+y+pkD12NpvWinqW1ubPcsYMq8OxRSanbeS WQ0ah3U0W4bIN69R19+D+ARaIL5OyS5s1Lof4EFYHKweiH2gsTlxKeUMMQLSLAvSSqcd l61yWj2LdAOoFOcCJUFuEaVGz41ECd+hjStYuhGjXplWVc9Ggkftst9nFefTK/SrfzkX 83Tg== X-Gm-Message-State: AN3rC/6pkz1qAhl8tdIMkvTlbAgAlaaXKyrfyWhy6EghStQ6rhOPoJQK q8n33mZx0wx+tCmS3BlZBxvhaNdhR15o X-Received: by 10.202.60.11 with SMTP id j11mr24252108oia.161.1494300788849; Mon, 08 May 2017 20:33:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.246 with HTTP; Mon, 8 May 2017 20:33:08 -0700 (PDT) In-Reply-To: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Mon, 8 May 2017 20:33:08 -0700 Message-ID: To: spring@ietf.org, "rtg-bfd@ietf.org" , "mpls@ietf.org" Content-Type: multipart/alternative; boundary=001a113ccb38b506f3054f0f0318 Archived-At: Subject: [mpls] Fwd: New Version Notification for draft-mirsky-spring-bfd-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 03:33:11 -0000 --001a113ccb38b506f3054f0f0318 Content-Type: text/plain; charset=UTF-8 Dear All, perhaps this new draft may is of interest to you. Your comments, suggestions are most welcome and greatly appreciated. Regards, Greg ---------- Forwarded message ---------- From: Date: Mon, May 8, 2017 at 8:29 PM Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt To: Gregory Mirsky A new version of I-D, draft-mirsky-spring-bfd-00.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-spring-bfd Revision: 00 Title: Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane Document date: 2017-05-08 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-mirsky-spring-bfd -00.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/ Htmlized: https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-spring-b fd-00 Abstract: Segment Routing architecture leverages the paradigm of source routing. It can be realized in the Multiprotocol Label Switching (MPLS) network without any change to the data plane. A segment is encoded as an MPLS label and an ordered list of segments is encoded as a stack of labels. Bidirectional Forwarding Detection (BFD) is expected to monitor any kind of paths between systems. This document defines how to use Label Switched Path Ping to bootstrap and control path in reverse direction of a BFD session on the Segment Routing network over MPLS dataplane. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a113ccb38b506f3054f0f0318 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,
perhaps this new draft may is of interest to= you.
Your comments, suggestions are most welcome and greatly app= reciated.

Regards,
Greg

---------- Forwarded message ----------
From: <= b class=3D"gmail_sendername"> <internet-drafts@ietf.org>=
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notifi= cation for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <gregimirsky@gmail.com>



A new version of I-D, draft-mirsky-spring-bfd-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-spring-bfd
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bidirectional Forwarding Detection= (BFD) in Segment Routing Networks Using MPLS Dataplane
Document date:=C2=A0 2017-05-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-spring-= bfd-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-mirsky-spring-bfd-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-mirsky-spring-bfd-00<= /a>


Abstract:
=C2=A0 =C2=A0Segment Routing architecture leverages the paradigm of source<= br> =C2=A0 =C2=A0routing.=C2=A0 It can be realized in the Multiprotocol Label S= witching
=C2=A0 =C2=A0(MPLS) network without any change to the data plane.=C2=A0 A s= egment is
=C2=A0 =C2=A0encoded as an MPLS label and an ordered list of segments is en= coded
=C2=A0 =C2=A0as a stack of labels.=C2=A0 Bidirectional Forwarding Detection= (BFD) is
=C2=A0 =C2=A0expected to monitor any kind of paths between systems.=C2=A0 T= his document
=C2=A0 =C2=A0defines how to use Label Switched Path Ping to bootstrap and c= ontrol
=C2=A0 =C2=A0path in reverse direction of a BFD session on the Segment Rout= ing
=C2=A0 =C2=A0network over MPLS dataplane.




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

The IETF Secretariat


--001a113ccb38b506f3054f0f0318-- From nobody Tue May 9 07:42:53 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E78129494; Tue, 9 May 2017 07:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NopsClY4Cww9; Tue, 9 May 2017 07:42:50 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0133.outbound.protection.outlook.com [104.47.38.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 B952412947D; Tue, 9 May 2017 07:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=swEPvChxA8VgmqhR5KEecV2hCOQ4tRe115WUZ4Ti1P4=; b=hPC9hvxyagPq1r101eQ58RgdOahin6fJLAwXR0vK1XupKdR30cNaMP/y1sQkGFHMIMa1Yp2FC89PVAVPQKiYJQOfilw4IXgr4fYISr+OqHsNhkPoXyZYiSOfD/ZxgazdO9a9bL3J2F5AtTJU5Ox1NmLgjOI/jn08zup9o16R2PE= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.37.32] (66.129.241.10) by BL2PR05MB2177.namprd05.prod.outlook.com (10.167.98.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Tue, 9 May 2017 14:42:46 +0000 From: Eric C Rosen To: Stewart Bryant , , "mpls@ietf.org" , "mpls-chairs@ietf.org" References: <24a3794c-f195-a885-2049-cb1f56cfe9d0@juniper.net> Message-ID: Date: Tue, 9 May 2017 10:42:43 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BN6PR1301CA0032.namprd13.prod.outlook.com (10.174.84.173) To BL2PR05MB2177.namprd05.prod.outlook.com (10.167.98.137) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6862f079-3c94-4e62-f07d-08d496e9a908 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BL2PR05MB2177; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2177; 3:yq+3UEXovyxuFhEEkdEDUPd2Gj5DTjwcLOVahVOa3LKfLKplLOz6tBEwR7A7L4ql/k9coIrBAVvcs1s66XD4m8YbNiz/SpUR8fcGNsSUlVfK7pPAkm21zVl0RLre8bqXOe1zgsDUGyC8BYK+HNEkWVSTQvWsKXzhj7ICgOcYPm05R2TjFlFgxhVHDoLwU9QyqaeNqQ1CatWZLv1G5m8DCWElJoVJUTbUYpOYrcBZO1mvY5rXHT3DPe9eKzybIkLAVbkgPwjVaxndXm0/+vFAEnRKpeCku9TgWYJf7aExM6APQSdQzu3wdowPNke6UrxZO1dRedh4QUiEi/TdqzY11tNYip3Yc5NOKED5VJsMSfc=; 25:RiEZOGbsKx5C1XFWdMGbMN2AHYunwgFWBYvG4lFHoglQSlhJnDgwbXkPJTfcn1dWxTQeAL3byLls1NgohT5EZx2AgdvO3Pv7dp3OnTXNqszDkhng/6AiDf2LN/Ca/ZrcfFXMd/TKNOZTMvT0cS3dTtAg5Y+kLJulV4dFFSU+MzJTVCNA6ES546qoRRST0gAv+r+f42Myk7LNQG9oXKNiRnwq2AQxc9GGC+et5mx/4YoIGA6zdhtDqTXj+/mbq3NgQex8owRv+hWbVGkFxVAeYArZwJy4dXaSVSuQ1Ee03fehPACCLqaFnQbERvzUjdC4kbDV1+kjqcNeGeBnlWUEZ1mQmovZ+Q0bvxXMA1rFFRQQXnKbev0CeDZVhEt3+wW6OfwnK1q6780JFrotIyU3VFOszAw+dtUJxtrbckCIPHDhM/FPTh7cptGFtT/9IlMb913r5jV9Q1JtxZNEJfpwq20v53VnzgA6V+SqnT2djA4= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2177; 31:+7wIvIxTNH9GfY4/fhnnLQRiBqM/HFfXK0vo5iM7pQIesOY/FjsJF4YsAhGdK1a5LZVBSNGUaVlKIJavPsH8RBgi6dMMHaNQduAoQLF7DyxbrR9TwL7vzzPUEBoi2QUHyLyqv3/qS4k+a0l30iV1xPYuLEcnCPws6QbgeBRlqp4rChuXslYvXWi1RyyNQ5YVTgwNlIv+b/HGdh55a8qo3cPo9WiPUXmgbTMpnV6yRDLij4mwy3iQBCZXH29ly7S+; 20:HEgaCPdif0OVugEqqxVS0zNMtT2Y3CE3Et5IxS23r/8MFOObbbnXpzu8zqoyK16x0CfKEysrV88DYxlBi8cFCfhT4DuOyqBj2NUHdk58KTmyuaLp0eky96PJn6U6tXRD47pbahqzYQLu0M7gj6ZQTML4yD35LiUd8e+KrpbMwNvOTlbg0H3B9pNb6ETT7RdiJ7OwN3eHZk64ypawMND0MZb46Q/BaUWA/2lRvE6m5jUBKx55/ihsqsj0Pt167+nKxME/2EuxccDiXD1mWgIV6YYbCo0QVnBAqQUIv8/48vVeaWRHt9W0ymGq4bX+c9s+KUrO3dH0Un0FXIZiuxNh5wkaXivXgtctB58ax+qyZyfmdWrKiZkYSyw/SdElSiAEDihCBPACexeQhYK4JwRbnlpCBBYAey0fBS54kFsCxuvWN4PhqJWEOjUfR8sOC3u3eDZHje0era82xTGoJ4U1s/a6WAiSmDcAY1c83NyP4z0k7nN8HdgPZr7eInosve627CNq5dZ+XOkuAMC1+IQHorNiPeCkQzrPpmeBoG11632GaSgYmlE7a2HarbDzJOapAUaPvxjhLCrfyHx/S1UIe21nuAbTrqimEoj8GSSVkYE= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:BL2PR05MB2177; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB2177; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2177; 4:GFgBmt5D8mITQBYQru2apmvd/YONMCf0uFRd4WyGk1jQEoIuMnYrAlkurtdhR4MSoB7Nts0V8UkqDPV4WHTJSTp6uKlGHIiUIHqvpdUPTFdVBs+m+uGw3zxYsof7H1fy+VvcXzPHe5OUKBXudSErjVvnvcr28RgQsKYXj3datG7H0x4+r8wbAWwybw/YL1vU83bZpvGJZV3FPw4I8bS2+03WskhYoLvmaWsXeO18RJtxlIOsxTi+NOHWylFB2mrwjDE2Q64R167byQgQKcEttjFfaX0HCDX5jhcghbg1eZJ8OauwPFOF4o74TXO7QaSf4n9DiWsN4dKbgxVd1ztawlIMBB51BgQaSTC7+t4qH1RBZJ2jOE6pZmGDRpyXA8cSkS51m0dibfc53GAyuYoKteTqGv7r6is621vHLD8GL927R0z/Ps3ThDnLEUOylwjmpT4EmgK5SSU50iFtKrql2SMn58AJw+pNrqUsNfmAWuyjtJ5H+uOR7kSIeJ4CFi5gN7FMMQvGxjG6esKP3r9iOKrBxy6DhvBoPJiRvpkZ6hp4A/mL94t4HpyZcO0M0iBa7s/lMT6tgI5Ju69upnlr556pz3qbqBQYFOg9YFK4ZhfXySCG+cB3sNiTbmP3ZAbtX8840Bd6e2svJzAPc8TWP+cg2B2vo5m8XYaLBWT4JwVgHgXvIIUd1ZMOo+l1tcTfkYZ3TDdLFJVtzZRub+G+96fz6wLvtPMI7H8FndJf5hllQSiwGHX8uT0lmKdaJCoPWmx+oMLl0rdb/Aa08HMmK9bMZ1duNbzW/rxlUtQy2d9CXV6r7VArBwzUTpTDJlZt X-Forefront-PRVS: 0302D4F392 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(39840400002)(39860400002)(39850400002)(39450400003)(39400400002)(39410400002)(377454003)(24454002)(2950100002)(64126003)(86362001)(31696002)(42186005)(31686004)(6486002)(53936002)(6116002)(305945005)(6666003)(66066001)(2906002)(47776003)(33646002)(3846002)(230783001)(2201001)(230700001)(36756003)(5660300001)(65826007)(8676002)(53546009)(229853002)(83506001)(76176999)(3260700006)(25786009)(50986999)(6246003)(189998001)(50466002)(54356999)(81166006)(23746002)(77096006)(4001350100001)(38730400002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB2177; H:[172.29.37.32]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BL2PR05MB2177; 23:okUT0Mb0C8q7JOwWplB2TtcKP8yQD4zGq9JQD?= =?Windows-1252?Q?6AG46cYVsZIssoZPxao+PnSIHpvpbj6d7R5CbbrtWLaO/7zIrACmAeii?= =?Windows-1252?Q?2QWOvBh1eG6dIfFwlzsGFqTgDl+THf6zifwnofIrPdv9k+5WvRYBWa1d?= =?Windows-1252?Q?af2IyKpsfcnSaEW6mEB6ffxT9ydnQYBaFTJfpih61HVURGsDpcuTURde?= =?Windows-1252?Q?JtPEnZowVWFTL7g7w2HfBkibVFOTlGmljSbjFJ13sJ7MCWJ9MMLNyBnJ?= =?Windows-1252?Q?l6EPpX9D3CLzxZ2+JPTevqJ8KrV3cqt4ol6oL0kh/DAA8Wx61uGa3rFx?= =?Windows-1252?Q?5lVboudT7ISve7IM28naCRL2gPw9RqJWVRCvanLtTaqVi2RixcjKjtIQ?= =?Windows-1252?Q?FmjToz2gLXxG/a3xXktgB1iQH3ub0X4TN1yyHrHrVSOla7Ci+gD5T2NZ?= =?Windows-1252?Q?x6Fz45e2VBRCPyLqkqgBhgrobeXk1TKsxXTVwpJ45wnLa2WUVqzdBNAD?= =?Windows-1252?Q?XfuysZove4kz0m6rRP3hlU0fTi+/YB+/dpQZoEGUQyHVgTpnVWIRNcEd?= =?Windows-1252?Q?ZoRRm6rjZBCyhtmUH78KRnUbPOhdKWTzp2vn7D0VLydq6xMZQBgf7BKt?= =?Windows-1252?Q?2QpLLfnPSdjMAYmhj8xiv1FVxVc/AqAIAZTsupNLWl5R5R+TWy6Ypk7Y?= =?Windows-1252?Q?On+148ozwyQIC654+oJRrXsp+XrCkNqBfzFYwfk8mDkld471N+AFE+jq?= =?Windows-1252?Q?o+FmgU78WUUkgqPs+zaaL40ID/EW4ixZuB6anrKh3yfxvXwaR2y+mxwS?= =?Windows-1252?Q?3J3s3ZJvcfjfIE//WiTi3RlWJJ83MX3Ri29y3iZMjZJ4m2lj/agEIcvV?= =?Windows-1252?Q?Tie9AgRaNSbOlBjHegz/7HTCrZ5cwwoUrcnSgicSDReBOXt6/e74acfb?= =?Windows-1252?Q?pA2Kx/iWBG/0cDhLj3sHiqt1uejUOQ/qnIRR7R+q0ALL3zL1l+OZOdM6?= =?Windows-1252?Q?ze9pRz4vOYa9uzLSQ8nMHcQpXX4oUvqe04pP5zhWDhE5kfBUUSukgS+7?= =?Windows-1252?Q?8wwxHOX2gBp4rLJUElZR498UkOlOCSqsZqzObA1DVWxtHWchyH9imoIv?= =?Windows-1252?Q?bO6DQq5fM/VOYfgb3IJ13D2tjiM+iMsgCvf+XQDFqHzOf2gWov1/5qH0?= =?Windows-1252?Q?vcGBSIS3CS1WPvWD3YAruaMQURnkJ4lSGyM+4MbNqLPSNXl4+wq7F+x8?= =?Windows-1252?Q?BEDSBmTFDPjWPdIUbxaHsDWjFJwVR2YjY2hqFWhBeZ3OdZms46XZvDE6?= =?Windows-1252?Q?iW1tyySUF958y7lsa5UNcPtKn8VC47d+wMmGWdFvbasTyLOJHp19IkIh?= =?Windows-1252?Q?PcPRcbqcZ8j?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2177; 6:ln88aoVpktK+rjg0X24EvMKfgld65XzibeCKMZPME9RE8yzCjnsGjP9MUk1S7/qYKtBgvqw1sIMycby7Idp4M+U8kGh5Tks/fzGeg8L5gXa+G7Mor+fN1SyN6RJjT8XbJDWukISPYOcOEW0NJ8ltutYcE68+m1eC5QlrtaDy+winV/1cvnzbcozgE3aC4/QuFKb4mRUQ8a8SJlWJn2IymhVZvb/7i3ZF+FLkMtiw+lcF5w3xMDDD1DeFfiqP9biQPQx5gbkU30W4IyM/WRfI0mJBGgw22QwPOaO6O0Z05rM0Rqh73lOf61N5Tf5xD2iOULMss8Olle8+B+RTDLEZ+W8jpjIv4O+hrz2aa2qUzl05/Le99JOr/u0V/tUbwg7qfKeaJQodZkU53Hf36Tdv5NbvHkrTspB19w3YQ0k4kQ8l0fiO0/2g886bC2UVsE0ibcMHA3bOSiQ8jffH3vgEBmoufBeQChS3FpggmMtDu0UHAV2pr+jFdwM2clgZZ9xqrkAz8q68//24rrY5MTH56Rl2DbWOPWntwvoH2JhQNm8=; 5:tIiO/ED/nXLOU4Mve4WwA4I1Z6cETfzJBU9zzje1KsW9Oy0VUa7Hm5GK9fRhf8d8Wlf6r6MpoLMDM9Hrr0l8ulHS+YjENxo1e2NALYgMmMkYowoYZOoU68dUcoWRe9OIM4MOGVCVm3KE72/QIRI+NQ==; 24:FiRJyvJPLadS5doJDs9eNSQYj9QCBQ9pK7nZsTWOkzeRoKeR7hCKST93xPPH/yy8sn/CWx147v2qlVKVUlaxARrgYigCyAeRm8iyp1dMFqY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2177; 7:ZU8ceTzF4Rzg3SIWNlyFg0UjUke+6+0PWbK7N+ArQQX7w0/CUGsMUTkbs/hcvZMWEvhTm5DO8KPj87LP+Ui/97yI7qfPa5/xJFP4gAY0Zo00HjoFCpqXZ3k6DGq9gjwSoo2NG/Z0WnW1wangZisCvfsVMEm9zH9jlnzdSCaVhelw/PpStoEptzB6TpHKW4iAmDX4Z2PPtzKxBFkTrCjh85a8wctXC+S0bHwhyGJiANPw/aoHVZKnzfPJOIq/bNpt2y4USO53dwD3QH3u/eTeV0W1pDQwBm6FPZisO2PHVXNq22vVZttFNXbxZQVzIMhpEbCDxLMMLtIbR/YhwsuSrQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2017 14:42:46.7979 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2177 Archived-At: Subject: Re: [mpls] [Bier] WGLC: draft-ietf-bier-mpls-encapsulation-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 14:42:51 -0000 On 5/8/2017 11:44 AM, Stewart Bryant wrote: > The document seems to be about how you operate BIER in an MPLS network, Please avoid the word "operate". We don't want to give the Operations&Maintenance ADs any opportunity to insist that the document is not complete without a "how to" guide for operators ;-) > and so I would have expected tunnelling over MPLS to be in scope. The topic of the draft is how to form a BIER encapsulation that can be used in an MPLS network, and how to form a BIER encapsulation that can be used in a non-MPLS network. Admitedly, there is some discussion (sections 2.1.3 and 2.2.3) of further encapsulating the BIER packets in tunnels, but not a comprehensive survey of all the issues that might arise when tunneling. Suppose P1 and P2 are packets, and E(Px) is the result of encapsulating Px in order to send it through a particular tunnel. I think it is true in general that if P1 and P2 have the same entropy, then it is desirable for E(P1) and E(P2) to also have the same entropy. This isn't mentioned because it isn't specific to either BIER or to MPLS, it's a general principle of tunneling. But I could add something like the above sentences to sections 2.1.3 and 2.2.3, as well as to section 6.9 of the architecture draft. Note that that text deliberately avoids RFC2119 language. I don't want to get into any detail about how to set the entropy in the tunnel encapsulation headers; that's clearly out of scope. There is no need for a discussion of when it is and is not appropriate to use the entropy label, how one knows whether the entropy label will be understood properly, how one knows whether the entropy label will make the stack too long, whether the FAT PW mechanism is appropriate, whether hardware can always preserve the entropy properly when putting on a tunnel encapsulation header, what the best entropy mechanism is for MPLSoUDP encapsulations, etc., etc., etc. Someone could write an entire draft on the entropy issues that arise when tunneling, but I don't think this needs to be dealt with in the BIER docs. (BTW, I'm sure you've noticed that the entropy field in the BIER header is 20 bits long, and hence could be copied into an entropy label. Perhaps it's worth mentioning tht explicitly, as long as RFC2119 language is not used.) From nobody Tue May 9 08:03:51 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1738E1294A6; Tue, 9 May 2017 08:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZELjfEYG0Tx; Tue, 9 May 2017 08:03:41 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0102.outbound.protection.outlook.com [104.47.38.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C781242F5; Tue, 9 May 2017 08:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=akpGBUN9cZgmN4fZjIFccYvEH5URIHnDYlxJKOnAQX0=; b=FlAmCOWwXHowN1+rj4u9GsUu7OHJdciXorGc3Xb3PPXlB03KaIKEczT2CE01KXGVhwlIdBb5+w1/E8253wsJ9vlVN4VaFWNPVfPXhdf09tM8oEK9VjQB3UlsCphQAn9z7mCp1HT1wIKE6O5udHNYoIqT5UTGwcB4wGG/QKCqYYM= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.37.32] (66.129.241.10) by BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Tue, 9 May 2017 15:03:39 +0000 To: Jonathan Hardwick , "draft-ietf-mpls-rfc3107bis@ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" References: <9913c8e1-50fe-34c1-a8d5-2d5efefafc5e@juniper.net> CC: "rtg-dir@ietf.org" From: Eric C Rosen Message-ID: Date: Tue, 9 May 2017 11:03:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BN6PR11CA0025.namprd11.prod.outlook.com (10.173.25.11) To BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 10f2962a-95de-4bd8-72a6-08d496ec938e X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 3:ASXXrHhrXJJk3bsxgdz1AuxxuopnQUQhrrxkNUb7FsWYLXNcAnB7sf9jV/QeZvYoFE3eCO6pxppgSgmTXHdx6nUfidCgdPcZBzRB68WvrBVTnTX/8XxWuOSfsGbJoYO2/hnQc+HuPUvk6lCxVGdUVISJy+Q/bmi8VEnaBw3aENJgLbErak7F+gLvPljEXnvIoxo5QQItWRggScnEjkejT1qrD/2rnbU2y0fT6oAey1+pQ6tOHDwQLSgt4/tkaQnsw+lIqVUUmlkE4lyyvuHkQB4pkUWLD+nL2UsKRW04/Hwx9KHRG0lend7zxBQrHeYQlxWrqngKH/tsvjZ3eed+CY2surtQhJp8yoLMhpktaEA=; 25:Fzqmr3lohL1BNkeQIRRayQMWAEkI6E1sC3GLXpnrlt6DQiZuQQUke38F4chb2QVZzmZwVnJQeSWG1P/LIEp2+9LZKtQQOsm03ICNURczbJxeboXzI+zT3XqfZ27TDTmeUKNahgb1wyHZfEW/v50U0RFIzJ02Pm9Bz1Yb3W2D/88jWSDcVM/ITUboD+8Nle3K0L8a+HKpIv2DTYX+YLAOfec8ImksOinhzSUUSizTsPwcQEghxUfWoo53Br5hwpwTVDE30r0rDpRwSp+tqeXa7+cMVRCVhL9NF744FPW22xHT5DgLp3TUO7k/t0AGK1pcR/Lkygd7imp/RSmJtwugUcPQjJgniYw2oj2EY37pnC544zHY0LHqlUWbiJkDaYcFQoG5XR8GZZVq3JyW2hzUki9uKncF97IDrz7J+0DZJ9PYSfF+LwcCxTb5t2Pqwf/CgBC815JdvKZ6Cul1rBEMwfQaeVMP36WzVmFYX8LtLWU= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 31:tqkWf14BVNO9D09rhgPo88Tj5fb0I4BLtcsTN/Pgx+4ANUwwwWT/MSbubq+SZIpe18MGgLotFTood2OAaAHAsKTI95Ihl3IGqrgKvsDktDpQRK9vGRtmgS4uUoVggXXzmcNFeUo8Vb761CMXFyhkZOnx6s/8LKQdfvGPc3BKseW+PVuj3XGKZNflMLoPC+ynPkIRDH2Gj5eAiOgppqcjKN7HccgkNioRHYDRY27TbtxSlqeUORPBPQuB6w0HJkjH; 20:XrxzBPDZMCaYl+0cynr1OycNXfIYK6thYd+THT7P9Sknw0tvQrU5iEFDmgQIgQ2W0BAWb3i7Dz2qXVcovovfFXK/70cTbkzi/kXSDXUYQKqa3yusDaByds8wqjD0AvseLOV4njz4f8mYG2CpX09Qa8+j/EEtLyGm4nCHGftpwV7jFzh7W8OmU5rZ2xCZD5NyIf9qOiJbp/SSUqXZAgQ6gz8KLKayAHXHCkzG2/FIWVHPFoVnscDdwrbqu/+fv1pocjNzNWQsDxbN6k9kCz7ymZZy3Z4OT5Fro7CO/g1UI4j/Vqn0b704SxZRIBVVAHokY8oyNVoNHj2WECKZevOSncbukOjRjtVLO3VNtMxUUpmw0ELj0RJqpqPsgo4Pw6t66YyAANkj+00kVtvz6TFiGZnfye7K429dRpGu2/NSzbWX+AuRaAVHixenU73o5WxDLpyACtbwIkpr5yCy2tcfxqYND1d6OBeyOY3LN6f8jefoP8tmWkkWRMb9Ky7kTufi7+2pmAb3FDCPK1SX2C/b+GPewUq7BJO5GvFvdtkRPumE7qVX+rGLxK8Gja38SPrbl7ndaJ2GFw4RF+Fd89l9TdYK7yqJrwPYfJUjv175tXs= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148); SRVR:BL2PR05MB2180; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 4:wOire4EUK4B1jPrhhdzjDhHUw5r/kN7jCIhUaJS7wMHsS6ZJ2yGbtMaqJBntRvgyzfjqQfbAC50EJVu+SXwpSfMDMbBCl2RreGiswb3emzTsqbaCxvq++9i66zCSBPYtJ/uoB8OUy9xU52iNGeJLg/o8FMCof4En/nsapoMt3GXakwm1ZOX8QWamfrJR9U9lAwdcvgXPrhg6uIqdA1f2yosJ2H3gLRxSW5TvLhMOA+17eYr8Y7BIc1ecfJD2rFkJEM1ydNhBRgIwO6BBMJXtDYo0jhGnCzC1MuGHXmPrc/ork/WA2vGG9abLK+0wK3qTNG6gaHO9EBJM95C3yHoxc3c8ptEjylhGGoK4V393oGpFxbQZwFVaYR4i/jPAUS/LIa+ZV7YkS1NHvtMSZq7hs6K5hFpval3R9XMSuzC9knmHjU9qrvVZqIabJy9zzf1EZC530eolZkNMTDGNjLTwQTYuQPgAedZZwEHa9Bhb5EC9BM2xeENy2LBD/t1ftrogg2lsHIGznT8LzzQR060aHN+tiA00mbPAKV9tYMelNPAU9/AMknq2woPg+LfhiMfci4sRBtYfJXGZ4yEXf+hxN5bZkGdK8tG9O9ifG+GL4fDKtYZsUN3fthap6cltYXGKrBeDQZdHmP2QEqPvxw8UoNlVsUqIfMuEu3XZP6buZSP9IkhZ8oIlnUmIBbzjPy8c+X8qogG02WbLgFJzkQz98KipXfbPXqTTTA2F4B6XZdZU85nkEYHR0xqbnOG3RiTmtdYL3Uy6q7TFAs70uwpJbwk9oOrsWLqBbx34Jy/giTUVKGimGg5pOLl5kMmbQKXC X-Forefront-PRVS: 0302D4F392 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(39450400003)(39400400002)(39850400002)(39860400002)(39840400002)(39410400002)(77096006)(31686004)(6246003)(230783001)(5660300001)(4326008)(86362001)(229853002)(2950100002)(4001350100001)(50986999)(54356999)(53936002)(6666003)(2201001)(230700001)(31696002)(76176999)(3260700006)(50466002)(23676002)(25786009)(65826007)(3846002)(83506001)(478600001)(66066001)(2906002)(6116002)(38730400002)(42186005)(6486002)(47776003)(305945005)(189998001)(36756003)(8676002)(33646002)(64126003)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB2180; H:[172.29.37.32]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTDJQUjA1TUIyMTgwOzIzOkw2ZUhob3dBRk0vMUVzZmdQak5CWGtLNVRM?= =?utf-8?B?Qnp4cWQ5NEhGODFOYlkzdGFwVldQbk1oekluWGJ1WW1xWkVEZStiYWtsVGVG?= =?utf-8?B?bzR2ajREUjRBZSt3VU1RaXFoclVyOHIxbktDcEFCN2pTb2tZN0xtbFZsMXl3?= =?utf-8?B?bS9BNEJBdEhGNUwvb1dpTWJhdzEyUGpxMUFERUJwTWwwNC9pZWNMR2JOTjZS?= =?utf-8?B?NFdEVi9malJmR1lzeE5pN2RSSFRFMkNIRzNURS9qMzBseTZTK0pJRm81UkNW?= =?utf-8?B?QWpDVHFWYTRtNnV1YkhlZ012aVZ3UDFqN0FQN2Y4S1F6WXo5R0I0NFErUENs?= =?utf-8?B?c0VGMUVrMi94T0ptMno5N0gvTUI2dU9CVlFhYzhjQlgvblFIVjlVTTBQRERL?= =?utf-8?B?S3E5NjVyMFF6UjFmVGFUazErWWlFOGhRSjUvWEs2Y3I2ZDBvbWFKc3FBVDYr?= =?utf-8?B?MHFJdmhoRml4SEwrQmdsNWZEWUh1N2dnTVRPRUtQMUdnZlk0Wmc3UUdhWVRS?= =?utf-8?B?SjFaSUtvUlFTMkk5SElBUFh5WldOc2Z0bXBpUTJXaXNscDFRS1RxNnBwVmln?= =?utf-8?B?MlRiTWROazZZdW1yWTBPK0lKRTFYcjRVYlloU1JWa3o1NkEySUpzWjNyMVdv?= =?utf-8?B?N1k5Rm80ZHlpcmdXVjJzaXZJemJjVFhRMzZ3TlhKTzlMeVRtSVBwR1FmVHVV?= =?utf-8?B?WE9nUUNmMUZFY1FpLzFoSm1TNzJWRFdJOEdvV0dpM0phS2VxV2ZQMXgrQ0ZP?= =?utf-8?B?SzRrNUFwZUphQmNaZnVXWFlHazRXQjdncVc5Z0pOdnJMc09hVHJtNlZJTSsz?= =?utf-8?B?RFY5UTkvWXBQMjhHMk9pclRGc3M5OHZWYlFZb3k3QW9zZURxdnFhajMzL3hN?= =?utf-8?B?Vk9IWjFraVd0Ry9XVkkyQTNaRUlyTUV1S2pzV2pVc0hFdVNsR2hNOUQ2U1lZ?= =?utf-8?B?Q1hwL1RMNHBTdkNjTGxaQ1RUN1doeCsyRnhIei9WbENsVG8zQ2R0alRZU09l?= =?utf-8?B?SjdNN1VHNFpNa2dDWldzOG04MUdIcTdrWmN3QVNsNkM1TldhaWUyQjJmM05K?= =?utf-8?B?T1BwZEFGOXR1NFZlNFd1YXhnTnpaQS9VRTFEYUNZRThUYlNZVkFTbSswNm1s?= =?utf-8?B?QVVGbmZEaEpGeVo5ckt5S2ZabEpqZGdMTG4ycnZKTTMrbXRsTE5ETncyN2w0?= =?utf-8?B?TlVxcXJ4VzNWT25nc1crQUZMLzh6aDBLQWM4eVg4VDVpRzlSTkVVUWgzYTJm?= =?utf-8?B?OGgxVzhnaHFFVGp6Z1dtdmczcEtoMEp2a0FELzBaWTM0NGZRUlVCdWdQU0FO?= =?utf-8?B?RE1MTHJ2MDlaQ0NRdkszOUY3Y2lkdnBzT1pUR1cvaWpOWVZrZ09HK3BibHhz?= =?utf-8?B?Ny9VMGtTbEZrZTNxVm5KNkNrMjJJc1cvS1V4cjdHTytLd1FGZmVlOTdIMHRw?= =?utf-8?B?L0N5czV5ZFFFQkpDdFIzdFZmL2JBWFZUWkdkUWRTUXBiU2VhSStpY1dseStj?= =?utf-8?B?NFR3dGpjbW5qOXk4cmZTM0ZoaFM1RGhpaFRLZGNCaXFlYmJqdjM2VDJOemh3?= =?utf-8?B?TlJtaGpLRTFyMWFySWtuS3VFd3RVMVNmUHpJZGRJSTE0U2FuTHFuZS94KzJX?= =?utf-8?Q?1tDsClF43a3MAQzI3zge?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 6:WIHqpxCEXINBOUcn0c9TMZa1SgkjQ6ywFMaLfzrcKDsiwzvr1Y9ex/kBMv8Y/Q05iWvoZy1WJ0x8rTN2+77KBCVbx4bLuMGY5iGp7QWco3xevOeALlqI8REAFF4cEeY8VbB5SIOW1uWP26IN0FiBspzeqmRCI2+2vZxyyh26g3NqXPXsj5wDyu4PtRctVmMspKpobN4ulGAOC9jBmo+SYOcGNhpnkokbwK4yXEbT+8UyJ6lVNTpf0nojinZEQX84aUps9TG4KV8n8GMXiKsJKxyNYOgc+mpgnvmsdEnxF4JFGVrNSlepWjtFwXRY1i6cwnksRySn6XF7V9LRVr30ydelvr853cdVqEx8FSnNzoQS2iXQRQXZ826khnuhLjWmblA1nac2XKQtPBie3F4UV2hk35bvsuU6J7meUcWZk9McoZcy9vLEcmOMTkR5qXi+SsA0B9AXoZ82EzSPaToM/LxBDmy1qvkQZzvEbx/uLUXokNQWcpWRAiDvH/PBDlTawRdOCSTftZ/U8N19dKKxdbHUPOPfv91k0bCkVokfDFw=; 5:QSO6rrusRPZ908/CHlOVDg/yHdg6R5LEgoowG392D1TD9GYBJlCrW1Wy3r+BUnYXIR5ttQpFlpLFWSu98Boe0tJ0hZvz4nrJ0wWijDbtHbkuWiZ0K6vXBb3DWZHVfIjemO20NJ6uO0MuxM6LvwFM/Q==; 24:QfIzyKrJnfcMfWECctBAcHnQlOQFu4NTgOhNZUwUO6bWSVvPAnUMJVbCZs3vThW7qVycuY5Km3krPZnlbrffECwv9wlyoT4sqYwmKWMrYT0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 7:dnLb2gJkwRHcuQpWPANs0Ijxvn5/qlaUsJbvD9pfUBZZ4j5CSyyWfglSaOoltO5Esby2H8270MbkREyOcgQblL+eRVZZRSbv9Df+52p17H13Z0MVFI8WCTCms8sRIJkQeoSyNTOaGOst6GxsBi5K8uyyjBWv8/bjB+GiAzXsWxaBTZ+vriGQ47H38U+n3f3tV6HlqjdyRB0GXH2thwpsmhhJn7D7LW1iD8Nnybclg6HggG6LzZdyfRfM0fOe6Ltsyj4dJjukP7pyi2D7mVe6PqsJjHGKkJXC7CqqKpI8mkWLtBoScpJ7mgiy5NUZF0Lm1vj2V8eeimsscTVSCR0UOw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2017 15:03:39.1631 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2180 Archived-At: Subject: Re: [mpls] Routing directorate review of draft-ietf-mpls-rfc3107-bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 15:03:43 -0000 Hi Jon, I've made some modifications to section 5 in response to your comments. While I don't want to get into a lot of details about the implementation differences, I do think it is fair to ask that section 5 point out more clearly that there can be interoperability problems, and that it might not be possible to achieve a desired set of local policies with some implementations or some combinations of implementation. See below for the proposed new contents of Section 5. Eric ---------------------- 5. Relationship Between SAFI-4 and SAFI-1 Routes It is possible that a BGP speaker will receive both a SAFI-1 route for prefix P and a SAFI-4 route for prefix P. Different implementations treat this situation in different ways. For example, some implementations may regard SAFI-1 routes and SAFI-4 routes as completely independent, and may treat them in a "ships in the night" fashion. In this case, bestpath selection for the two SAFIs is independent, and there will be a best SAFI-1 route to P as well as a best SAFI-4 route to P. Which packets get forwarded according to the routes of which SAFI is then a matter of local policy. Other implementations may treat the SAFI-1 and SAFI-4 routes for a given prefix as comparable, such that the best route to prefix P is either a SAFI-1 route or a SAFI-4 route, but not both. In such implementations, if load-balancing is done among a set of equal cost routes, some of the equal cost routes may be SAFI-1 routes and some may be SAFI-4 routes. Whether this is allowed is again a matter of local policy. Some implementations may allow a single BGP session to carry UPDATES of both SAFI-1 and SAFI-4; other implementations may disallow this. Some implementations that allow both SAFIs on the same session may treat the receipt of a SAFI-1 route for prefix P on a given session as an implicit withdrawal of a previous SAFI-4 route for prefix P on that session, and vice versa. Other implementations may have different behavior. A BGP speaker may receive a SAFI-4 route over a given BGP session, but may have other BGP sessions for which SAFI-4 is not enabled. In this case, the BGP speaker MAY convert the SAFI-4 route to a SAFI-1 route and then propagate the result over the session on which SAFI-4 is not enabled. Whether this is done is a matter of local policy. These differences in the behavior of different implementations may result in unexpected behavior or lack of interoperability. In some cases, it may be difficult or impossible to achieve the desired policies with certain implementations or combinations of implementations. From nobody Tue May 9 08:51:50 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8557212E049; Tue, 9 May 2017 08:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSyUAheispVh; Tue, 9 May 2017 08:51:40 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A42C12E057; Tue, 9 May 2017 08:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11404; q=dns/txt; s=iport; t=1494345100; x=1495554700; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=b9PUXgYXDwJtNTK18p1PTl3sMYCbt09BDD9/rWOEAoo=; b=UVapUp/FRWzXKwKWzCk8GGmG9nKyQYBk0tmTD1cq+rI3kOu8ym4hkvhf gZM3/22lD0HvwQv2a11gO1913TpvuqdBVxWQZpkMttFhic4+lSv8xL3mh c8k0T3q9wNYw/pZGW6+QPy0pGW8EziDiNYa/v59YIoj1UVsbCphHRNTMn I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AAD35BFZ/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHg2KKGJFWiCOIF4U4gg8hAQqFeAIahFI/GAECAQEBAQE?= =?us-ascii?q?BAWsohRUBAQEBAwEBIUsJAhACAQgRAQIBAigDAgICHwYLFAMGCAIEDgWKCQMVD?= =?us-ascii?q?rJWgiaHLg2DOAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GX4FeK4JwglSBcgEBOxY?= =?us-ascii?q?IgkwugjEFiUSGXo0oOwGHG4cqhFOCBFWEZoosiyqEdyiDdgEPEDiBCnAVHCoSA?= =?us-ascii?q?YQoORyBY3YBhkWBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,315,1491264000"; d="scan'208,217";a="422173887" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 May 2017 15:51:39 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v49FpdtO013839 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 May 2017 15:51:39 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 9 May 2017 11:51:38 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Tue, 9 May 2017 11:51:38 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: "spring@ietf.org" , "rtg-bfd@ietf.org" , "mpls@ietf.org" Thread-Topic: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt Thread-Index: AQHSyNwkwOl2lp11iEyR0ciJiuUUKQ== Date: Tue, 9 May 2017 15:51:38 +0000 Message-ID: <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.52] Content-Type: multipart/alternative; boundary="_000_1C12E1626B5C4EF2A3CB3621C72BCFE9ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 15:51:42 -0000 --_000_1C12E1626B5C4EF2A3CB3621C72BCFE9ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBHcmVnLA0KDQpDdXJzb3JpbHkgc2Nhbm5pbmcgdGhyb3VnaCB0aGlzLCBpdCBzZWVtcyB0 aGF0IG1vc3QgY29uY2VybnMgcmFpc2VkIGFuZCBjb21tZW50cyBtYWRlIGFib3V0IHRoZSBTUiBz ZWN0aW9ucyBvZiBkcmFmdC1pZXRmLW1wbHMtYmZkLWRpcmVjdGVkLTBOICh3aXRoIE4gPCA1KSBh cHBseSB0byB5b3VyIG5ldyBkcmFmdC4NCg0KVGhpcyBpcyBvbmUgb2YgdGhvc2U6IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50L21zZzE1ODYwLmh0bWwg 4oCUIHRoZSBsaXN0IGFyY2hpdmUgc2hvd3MgYSBmZXcgbW9yZS4gVGhlIGNvcHkvcGFzdGUgZGlk IG5vdCBhZGRyZXNzIHRoZSBjb21tZW50cy4NCg0KQmVzdCwNCg0K4oCUIENhcmxvcy4NCg0KT24g TWF5IDgsIDIwMTcsIGF0IDExOjMzIFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwu Y29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90ZToNCg0KRGVhciBBbGwsDQpw ZXJoYXBzIHRoaXMgbmV3IGRyYWZ0IG1heSBpcyBvZiBpbnRlcmVzdCB0byB5b3UuDQpZb3VyIGNv bW1lbnRzLCBzdWdnZXN0aW9ucyBhcmUgbW9zdCB3ZWxjb21lIGFuZCBncmVhdGx5IGFwcHJlY2lh dGVkLg0KDQpSZWdhcmRzLA0KR3JlZw0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0t LS0tLS0tLS0NCkZyb206IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZz4+DQpEYXRlOiBNb24sIE1heSA4LCAyMDE3IGF0IDg6MjkgUE0NClN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWlyc2t5LXNwcmluZy1i ZmQtMDAudHh0DQpUbzogR3JlZ29yeSBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWls dG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgR3JlZyBNaXJza3kgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4N Cg0KTmFtZTogICAgICAgICAgIGRyYWZ0LW1pcnNreS1zcHJpbmctYmZkDQpSZXZpc2lvbjogICAg ICAgMDANClRpdGxlOiAgICAgICAgICBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9u IChCRkQpIGluIFNlZ21lbnQgUm91dGluZyBOZXR3b3JrcyBVc2luZyBNUExTIERhdGFwbGFuZQ0K RG9jdW1lbnQgZGF0ZTogIDIwMTctMDUtMDgNCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICA3DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwLnR4dA0K U3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1p cnNreS1zcHJpbmctYmZkLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAN Cg0KDQpBYnN0cmFjdDoNCiAgIFNlZ21lbnQgUm91dGluZyBhcmNoaXRlY3R1cmUgbGV2ZXJhZ2Vz IHRoZSBwYXJhZGlnbSBvZiBzb3VyY2UNCiAgIHJvdXRpbmcuICBJdCBjYW4gYmUgcmVhbGl6ZWQg aW4gdGhlIE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nDQogICAoTVBMUykgbmV0d29yayB3 aXRob3V0IGFueSBjaGFuZ2UgdG8gdGhlIGRhdGEgcGxhbmUuICBBIHNlZ21lbnQgaXMNCiAgIGVu Y29kZWQgYXMgYW4gTVBMUyBsYWJlbCBhbmQgYW4gb3JkZXJlZCBsaXN0IG9mIHNlZ21lbnRzIGlz IGVuY29kZWQNCiAgIGFzIGEgc3RhY2sgb2YgbGFiZWxzLiAgQmlkaXJlY3Rpb25hbCBGb3J3YXJk aW5nIERldGVjdGlvbiAoQkZEKSBpcw0KICAgZXhwZWN0ZWQgdG8gbW9uaXRvciBhbnkga2luZCBv ZiBwYXRocyBiZXR3ZWVuIHN5c3RlbXMuICBUaGlzIGRvY3VtZW50DQogICBkZWZpbmVzIGhvdyB0 byB1c2UgTGFiZWwgU3dpdGNoZWQgUGF0aCBQaW5nIHRvIGJvb3RzdHJhcCBhbmQgY29udHJvbA0K ICAgcGF0aCBpbiByZXZlcnNlIGRpcmVjdGlvbiBvZiBhIEJGRCBzZXNzaW9uIG9uIHRoZSBTZWdt ZW50IFJvdXRpbmcNCiAgIG5ldHdvcmsgb3ZlciBNUExTIGRhdGFwbGFuZS4NCg0KDQoNCg0KUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvPi4NCg0K VGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRv Om1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMNCg0K --_000_1C12E1626B5C4EF2A3CB3621C72BCFE9ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <342CA9F64BCFEF44826344A6A2AF8B9D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRGVhciBHcmVnLA0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q3Vyc29yaWx5IHNjYW5u aW5nIHRocm91Z2ggdGhpcywgaXQgc2VlbXMgdGhhdCBtb3N0IGNvbmNlcm5zIHJhaXNlZCBhbmQg Y29tbWVudHMgbWFkZSBhYm91dCB0aGUgU1Igc2VjdGlvbnMgb2YmbmJzcDtkcmFmdC1pZXRmLW1w bHMtYmZkLWRpcmVjdGVkLTBOICh3aXRoIE4gJmx0OyA1KSBhcHBseSB0byB5b3VyIG5ldyBkcmFm dC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlRoaXMgaXMgb25lIG9mIHRob3NlOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50L21zZzE1ODYwLmh0bWwiIGNsYXNzPSIi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50L21zZzE1 ODYwLmh0bWw8L2E+IOKAlCB0aGUgbGlzdCBhcmNoaXZlIHNob3dzIGEgZmV3IG1vcmUuIFRoZSBj b3B5L3Bhc3RlIGRpZCBub3QgYWRkcmVzcw0KIHRoZSBjb21tZW50cy48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJlc3QsPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJQgQ2Fy bG9zLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE1heSA4LCAyMDE3LCBh dCAxMTozMyBQTSwgR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBn bWFpbC5jb20iIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwv ZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5EZWFyIEFsbCwNCjxkaXYgY2xhc3M9IiI+cGVy aGFwcyB0aGlzIG5ldyBkcmFmdCBtYXkgaXMgb2YgaW50ZXJlc3QgdG8geW91LjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5Zb3VyIGNvbW1lbnRzLCBzdWdnZXN0aW9ucyBhcmUgbW9zdCB3ZWxjb21lIGFu ZCBncmVhdGx5IGFwcHJlY2lhdGVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UmVnYXJkcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+R3Jl ZzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+LS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyIGNsYXNzPSIi Pg0KRnJvbTogPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPjwvYj48c3BhbiBkaXI9Imx0ciIg Y2xhc3M9IiI+Jmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIiBjbGFzcz0iIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0Ozwv c3Bhbj48YnIgY2xhc3M9IiI+DQpEYXRlOiBNb24sIE1heSA4LCAyMDE3IGF0IDg6MjkgUE08YnIg Y2xhc3M9IiI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1p cnNreS1zcHJpbmctYmZkLTAwLnR4dDxiciBjbGFzcz0iIj4NClRvOiBHcmVnb3J5IE1pcnNreSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwLnR4dDxiciBjbGFzcz0iIj4NCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR3JlZyBNaXJza3kgYW5kIHBvc3RlZCB0byB0 aGU8YnIgY2xhc3M9IiI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KTmFtZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0 LW1pcnNreS1zcHJpbmctYmZkPGJyIGNsYXNzPSIiPg0KUmV2aXNpb246Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7MDA8YnIgY2xhc3M9IiI+DQpUaXRsZTombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaW4g U2VnbWVudCBSb3V0aW5nIE5ldHdvcmtzIFVzaW5nIE1QTFMgRGF0YXBsYW5lPGJyIGNsYXNzPSIi Pg0KRG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxNy0wNS0wODxiciBjbGFzcz0iIj4NCkdyb3VwOiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJy IGNsYXNzPSIiPg0KUGFnZXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA3PGJy IGNsYXNzPSIiPg0KVVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1taXJz a3ktc3ByaW5nLWJmZC0wMC50eHQiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNs YXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtPHdiciBjbGFzcz0iIj5kcmFm dHMvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQ8d2JyIGNsYXNzPSIiPi0wMC50eHQ8L2E+PGJyIGNs YXNzPSIiPg0KU3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXJza3ktc3ByaW5nLWJm ZC8iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvPHdiciBjbGFzcz0iIj5kb2MvZHJhZnQtbWlyc2t5LXNwcmluZy1i ZmQvPC9hPjxiciBjbGFzcz0iIj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1taXJza3ktc3ByaW5n LWJmZC0wMCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2Q8d2JyIGNsYXNzPSIiPnJhZnQtbWlyc2t5LXNwcmluZy1i ZmQtMDA8L2E+PGJyIGNsYXNzPSIiPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1t aXJza3ktc3ByaW5nLWJmZC0wMCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xh c3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy88d2JyIGNsYXNzPSIiPmRvYy9odG1s L2RyYWZ0LW1pcnNreS1zcHJpbmctYjx3YnIgY2xhc3M9IiI+ZmQtMDA8L2E+PGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQWJzdHJhY3Q6PGJyIGNsYXNzPSIiPg0K Jm5ic3A7ICZuYnNwO1NlZ21lbnQgUm91dGluZyBhcmNoaXRlY3R1cmUgbGV2ZXJhZ2VzIHRoZSBw YXJhZGlnbSBvZiBzb3VyY2U8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7cm91dGluZy4mbmJz cDsgSXQgY2FuIGJlIHJlYWxpemVkIGluIHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGlu ZzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsoTVBMUykgbmV0d29yayB3aXRob3V0IGFueSBj aGFuZ2UgdG8gdGhlIGRhdGEgcGxhbmUuJm5ic3A7IEEgc2VnbWVudCBpczxiciBjbGFzcz0iIj4N CiZuYnNwOyAmbmJzcDtlbmNvZGVkIGFzIGFuIE1QTFMgbGFiZWwgYW5kIGFuIG9yZGVyZWQgbGlz dCBvZiBzZWdtZW50cyBpcyBlbmNvZGVkPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2FzIGEg c3RhY2sgb2YgbGFiZWxzLiZuYnNwOyBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9u IChCRkQpIGlzPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2V4cGVjdGVkIHRvIG1vbml0b3Ig YW55IGtpbmQgb2YgcGF0aHMgYmV0d2VlbiBzeXN0ZW1zLiZuYnNwOyBUaGlzIGRvY3VtZW50PGJy IGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2RlZmluZXMgaG93IHRvIHVzZSBMYWJlbCBTd2l0Y2hl ZCBQYXRoIFBpbmcgdG8gYm9vdHN0cmFwIGFuZCBjb250cm9sPGJyIGNsYXNzPSIiPg0KJm5ic3A7 ICZuYnNwO3BhdGggaW4gcmV2ZXJzZSBkaXJlY3Rpb24gb2YgYSBCRkQgc2Vzc2lvbiBvbiB0aGUg U2VnbWVudCBSb3V0aW5nPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO25ldHdvcmsgb3ZlciBN UExTIGRhdGFwbGFuZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyIGNs YXNzPSIiPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvIiByZWw9Im5vcmVmZXJyZXIiIHRh cmdldD0iX2JsYW5rIiBjbGFzcz0iIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KbXBs cyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9y ZyIgY2xhc3M9IiI+bXBsc0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIGNsYXNzPSIiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvYT48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_1C12E1626B5C4EF2A3CB3621C72BCFE9ciscocom_-- From nobody Tue May 9 09:00:48 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF8412E76A; Tue, 9 May 2017 09:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryj0stNX5sp0; Tue, 9 May 2017 09:00:28 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 B2C1C12EA42; Tue, 9 May 2017 09:00:23 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id h4so4948772oib.3; Tue, 09 May 2017 09:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LNIPH7txEl3b07ZBRj/kYGT05RcZ1GhC7ydfir+4nVM=; b=E3olA8MDKx2thgOriN2m/fQmanvc5pT1zVW048efx1nWkInSzbaKAZh3/s/HNTL3SS PZ9pLwm7jI6PmZGWIVYexndeiVeFNSuhtDC7s/qqKfQtgzhONijuOheeE+eMkWzLyVWp 6m+UiSAm6NGF+gNfKlsemt/8UA0iqozmorfr7DiYLDctbnyFwtkRZWLRG9socbqni9VE PD9GPYC1xodkWFIaVoyAU7/2Lco+qN/1uL7M289fJgwdXHMBenAQQTtceMLWWmlauEU7 5B3xsLWH7YiICDmvxWERH9ZFw8tVIsDjRfAX8vZrpiKLRn4YvPlsfh8sR3Dv21tD1Nl2 I6rQ== 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=LNIPH7txEl3b07ZBRj/kYGT05RcZ1GhC7ydfir+4nVM=; b=APktbC/fdoRA0PFX13uXt2cBe0l5eGD1I2RYAnlHCRFzDmQDdcW7ccDnT9U4MFnhCy uMTLVxGlw27vhpJK7Yq+DV74tEsMIbTy3+nkHgAUMnkib3l2GmsUbOz4O7HnejuVyAI1 VKVS6Us5+/I05QEBfgDOihxaZX3IwfDp5zB/1qL+PqpkYjmGPwk6qKlSN0+F78D7U5NH yHGEB8vAUTpzyY9EeS6x0LSbL/M4ucZftpXuBuuZMxqLTdC5e7U5Gvg0t2BE7WHlOuwK WBu8dJZor0cf7CRNcpUceqcZ9Npu1Wez1E+PbBfcyYIH9IP7ik73zxTz7gmv3kL8CCNK CsCQ== X-Gm-Message-State: AODbwcBL+3Bql3UWgqb4ocseE/GulkAaGDbdhSDg+tqJrTvtXxNT1F5o OsZkUspBzUbZjL42J2psP4NUSkw7YndM X-Received: by 10.202.206.139 with SMTP id e133mr293393oig.168.1494345623081; Tue, 09 May 2017 09:00:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.246 with HTTP; Tue, 9 May 2017 09:00:22 -0700 (PDT) In-Reply-To: <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> From: Greg Mirsky Date: Tue, 9 May 2017 09:00:22 -0700 Message-ID: To: "Carlos Pignataro (cpignata)" Cc: "spring@ietf.org" , "rtg-bfd@ietf.org" , "mpls@ietf.org" Content-Type: multipart/alternative; boundary=001a113d3ccc0918cc054f1974f7 Archived-At: Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 16:00:31 -0000 --001a113d3ccc0918cc054f1974f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Carlos, I've decided to re-start the discussion and am interested to hear technical comments to the proposed solution. Regards, Greg On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Dear Greg, > > Cursorily scanning through this, it seems that most concerns raised and > comments made about the SR sections of draft-ietf-mpls-bfd-directed-0N > (with N < 5) apply to your new draft. > > This is one of those: https://www.ietf.org/mail-archive/web/mpls/current/ > msg15860.html =E2=80=94 the list archive shows a few more. The copy/paste= did not > address the comments. > > Best, > > =E2=80=94 Carlos. > > On May 8, 2017, at 11:33 PM, Greg Mirsky wrote: > > Dear All, > perhaps this new draft may is of interest to you. > Your comments, suggestions are most welcome and greatly appreciated. > > Regards, > Greg > > ---------- Forwarded message ---------- > From: > Date: Mon, May 8, 2017 at 8:29 PM > Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt > To: Gregory Mirsky > > > > A new version of I-D, draft-mirsky-spring-bfd-00.txt > has been successfully submitted by Greg Mirsky and posted to the > IETF repository. > > Name: draft-mirsky-spring-bfd > Revision: 00 > Title: Bidirectional Forwarding Detection (BFD) in Segment > Routing Networks Using MPLS Dataplane > Document date: 2017-05-08 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet- > drafts/draft-mirsky-spring-bfd-00.txt > Status: https://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/ > Htmlized: https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-mirsky-spring-bfd-00 > > > Abstract: > Segment Routing architecture leverages the paradigm of source > routing. It can be realized in the Multiprotocol Label Switching > (MPLS) network without any change to the data plane. A segment is > encoded as an MPLS label and an ordered list of segments is encoded > as a stack of labels. Bidirectional Forwarding Detection (BFD) is > expected to monitor any kind of paths between systems. This document > defines how to use Label Switched Path Ping to bootstrap and control > path in reverse direction of a BFD session on the Segment Routing > network over MPLS dataplane. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > --001a113d3ccc0918cc054f1974f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Carlos,
I've decided to re-start the discussi= on and am interested to hear technical comments to the proposed solution.= =C2=A0

Regards,
Greg

On Tue, May 9, 2017 at 8:= 51 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wro= te:
Dear Greg,

Cursorily scanning through this, it seems that most concerns raised an= d comments made about the SR sections of=C2=A0draft-ietf-mpls-bfd-dire= cted-0N (with N < 5) apply to your new draft.

This is one of those:=C2=A0https://www.ietf.org/mail-archive/web/mpls/current/msg15860.html =E2=80=94 the list = archive shows a few more. The copy/paste did not address the comments.

Best,

=E2=80=94 Carlos.

On May 8, 2017, at 11:33 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear All,
perhaps this new draft may is of interest to you.
Your comments, suggestions are most welcome and greatly appreciated.

Regards,
Greg

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <gregimirsky@gmail.com>



A new version of I-D, draft-mirsky-spring-bfd-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-spring-bfd
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bidirectional Forwarding Detection= (BFD) in Segment Routing Networks Using MPLS Dataplane
Document date:=C2=A0 2017-05-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-spring-bfd-00.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-mirsky-spring-bfd-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-mirsky-spring-bfd-00<= /a>


Abstract:
=C2=A0 =C2=A0Segment Routing architecture leverages the paradigm of source<= br> =C2=A0 =C2=A0routing.=C2=A0 It can be realized in the Multiprotocol Label S= witching
=C2=A0 =C2=A0(MPLS) network without any change to the data plane.=C2=A0 A s= egment is
=C2=A0 =C2=A0encoded as an MPLS label and an ordered list of segments is en= coded
=C2=A0 =C2=A0as a stack of labels.=C2=A0 Bidirectional Forwarding Detection= (BFD) is
=C2=A0 =C2=A0expected to monitor any kind of paths between systems.=C2=A0 T= his document
=C2=A0 =C2=A0defines how to use Label Switched Path Ping to bootstrap and c= ontrol
=C2=A0 =C2=A0path in reverse direction of a BFD session on the Segment Rout= ing
=C2=A0 =C2=A0network over MPLS dataplane.




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

The IETF Secretariat


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls


--001a113d3ccc0918cc054f1974f7-- From nobody Tue May 9 09:07:38 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FCC1294AC; Tue, 9 May 2017 09:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFdLccWn6s2N; Tue, 9 May 2017 09:07:25 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E92212420B; Tue, 9 May 2017 09:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15804; q=dns/txt; s=iport; t=1494346045; x=1495555645; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=z4kC/A4y1mfoT95b1XbYLX+H3rYIWFJpJ288HrXZ1QM=; b=gblv3Wg+qL95b0gVGi6OEQ2k2q6WmNFQyK9rW5+z3OXx23MYo4KWKg4I ZZorJmebo6pIqqqUFHMFA5ZFvjmxzfeK/igdCIgmNyJGPX4MYo9bb9V4b nBQgYXGyH3GG+Ks5pm5AzR0ep1x4RevNHS+WSUmarwAxZ1KAsq4Ua2Dx3 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AACA6BFZ/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHg2KKGJFWiCOIF4U4gg8hAQqFeAIahFI/GAECAQEBAQE?= =?us-ascii?q?BAWsohRUBAQEBAwEBIUsJAhACAQgRAQIBAigDAgICHwYLFAMGCAIEDgUbiW4DF?= =?us-ascii?q?Q6yVoImhy4NgzgBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhl+BXiuCcIJUTYElAQE?= =?us-ascii?q?7FgiCTC6CMQWJRIZehkuGXTsBhxuHKoRTggRVhGaKLIsqhHcog3YBDxA4gQpwF?= =?us-ascii?q?RwqEgGEKDkcgWN2AYZFgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,315,1491264000"; d="scan'208,217";a="232756573" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 May 2017 16:07:23 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v49G7NWB019458 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 May 2017 16:07:23 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 9 May 2017 12:07:22 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Tue, 9 May 2017 12:07:22 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: "spring@ietf.org" , "rtg-bfd@ietf.org" , "mpls@ietf.org" Thread-Topic: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt Thread-Index: AQHSyNwl4f82jzKO5Eq8Ccd1kzJOwKHsbA8AgAAB9QA= Date: Tue, 9 May 2017 16:07:22 +0000 Message-ID: References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.52] Content-Type: multipart/alternative; boundary="_000_F3C093E0FE4E41C0B9EB0CA1CB52DBE7ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 16:07:27 -0000 --_000_F3C093E0FE4E41C0B9EB0CA1CB52DBE7ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IEdyZWchDQoNClNpbmNlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1taXJza3ktc3ByaW5nLWJmZC0wMCBzZWVtcyBxdWl0ZSBzaW1pbGFyIHRvIHRoZSB0ZXh0IHJl bW92ZWQgYXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1t cGxzLWJmZC1kaXJlY3RlZC0wNS50eHQsIHRoZW4gdGhlIGNvbXBsZXRlIHNldCBvZiBvdXRzdGFu ZGluZyB0ZWNobmljYWwgY29tbWVudHMgdGhhdCB0cmlnZ2VyZWQgdGhlIHJlbW92YWwgb2YgdGhh dCB0ZXh0IGZyb20gZHJhZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3RlZC0wNS50eHQgbWlnaHQgcGVl ayB5b3VyIGludGVyZXN0IDotKQ0KDQpPbmUgdGhhdCBJIHJlY2FsbCBpczogd2h5IHVzZSBsYWJl bCB2YWx1ZXMgd2hlbiBldmVyeSBvdGhlciByZXR1cm4tcGF0aCBzdWItVExWIGZvciBCRkQgYW5k IGZvciBMU1AtUGluZywgaW5jbHVkaW5nIGRyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZWQsIHVz ZXMgVEZTcz8NCg0KQmVzdCwNCg0K4oCUIENhcmxvcy4NCg0KT24gTWF5IDksIDIwMTcsIGF0IDEy OjAwIFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1p cnNreUBnbWFpbC5jb20+PiB3cm90ZToNCg0KRGVhciBDYXJsb3MsDQpJJ3ZlIGRlY2lkZWQgdG8g cmUtc3RhcnQgdGhlIGRpc2N1c3Npb24gYW5kIGFtIGludGVyZXN0ZWQgdG8gaGVhciB0ZWNobmlj YWwgY29tbWVudHMgdG8gdGhlIHByb3Bvc2VkIHNvbHV0aW9uLg0KDQpSZWdhcmRzLA0KR3JlZw0K DQpPbiBUdWUsIE1heSA5LCAyMDE3IGF0IDg6NTEgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWdu YXRhKSA8Y3BpZ25hdGFAY2lzY28uY29tPG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+PiB3cm90 ZToNCkRlYXIgR3JlZywNCg0KQ3Vyc29yaWx5IHNjYW5uaW5nIHRocm91Z2ggdGhpcywgaXQgc2Vl bXMgdGhhdCBtb3N0IGNvbmNlcm5zIHJhaXNlZCBhbmQgY29tbWVudHMgbWFkZSBhYm91dCB0aGUg U1Igc2VjdGlvbnMgb2YgZHJhZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3RlZC0wTiAod2l0aCBOIDwg NSkgYXBwbHkgdG8geW91ciBuZXcgZHJhZnQuDQoNClRoaXMgaXMgb25lIG9mIHRob3NlOiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cxNTg2MC5o dG1sIOKAlCB0aGUgbGlzdCBhcmNoaXZlIHNob3dzIGEgZmV3IG1vcmUuIFRoZSBjb3B5L3Bhc3Rl IGRpZCBub3QgYWRkcmVzcyB0aGUgY29tbWVudHMuDQoNCkJlc3QsDQoNCuKAlCBDYXJsb3MuDQoN Ck9uIE1heSA4LCAyMDE3LCBhdCAxMTozMyBQTSwgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdt YWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4gd3JvdGU6DQoNCkRlYXIgQWxs LA0KcGVyaGFwcyB0aGlzIG5ldyBkcmFmdCBtYXkgaXMgb2YgaW50ZXJlc3QgdG8geW91Lg0KWW91 ciBjb21tZW50cywgc3VnZ2VzdGlvbnMgYXJlIG1vc3Qgd2VsY29tZSBhbmQgZ3JlYXRseSBhcHBy ZWNpYXRlZC4NCg0KUmVnYXJkcywNCkdyZWcNCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2Fn ZSAtLS0tLS0tLS0tDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogTW9uLCBNYXkgOCwgMjAxNyBhdCA4OjI5IFBN DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1pcnNreS1zcHJp bmctYmZkLTAwLnR4dA0KVG86IEdyZWdvcnkgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb208 bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRv cnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1taXJza3ktc3ByaW5nLWJmZA0KUmV2aXNpb246 ICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVj dGlvbiAoQkZEKSBpbiBTZWdtZW50IFJvdXRpbmcgTmV0d29ya3MgVXNpbmcgTVBMUyBEYXRhcGxh bmUNCkRvY3VtZW50IGRhdGU6ICAyMDE3LTA1LTA4DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgNw0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMC50 eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1taXJza3ktc3ByaW5nLWJmZC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDANCkh0bWxpemVkOiAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW1pcnNreS1zcHJpbmctYmZk LTAwDQoNCg0KQWJzdHJhY3Q6DQogICBTZWdtZW50IFJvdXRpbmcgYXJjaGl0ZWN0dXJlIGxldmVy YWdlcyB0aGUgcGFyYWRpZ20gb2Ygc291cmNlDQogICByb3V0aW5nLiAgSXQgY2FuIGJlIHJlYWxp emVkIGluIHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZw0KICAgKE1QTFMpIG5ldHdv cmsgd2l0aG91dCBhbnkgY2hhbmdlIHRvIHRoZSBkYXRhIHBsYW5lLiAgQSBzZWdtZW50IGlzDQog ICBlbmNvZGVkIGFzIGFuIE1QTFMgbGFiZWwgYW5kIGFuIG9yZGVyZWQgbGlzdCBvZiBzZWdtZW50 cyBpcyBlbmNvZGVkDQogICBhcyBhIHN0YWNrIG9mIGxhYmVscy4gIEJpZGlyZWN0aW9uYWwgRm9y d2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMNCiAgIGV4cGVjdGVkIHRvIG1vbml0b3IgYW55IGtp bmQgb2YgcGF0aHMgYmV0d2VlbiBzeXN0ZW1zLiAgVGhpcyBkb2N1bWVudA0KICAgZGVmaW5lcyBo b3cgdG8gdXNlIExhYmVsIFN3aXRjaGVkIFBhdGggUGluZyB0byBib290c3RyYXAgYW5kIGNvbnRy b2wNCiAgIHBhdGggaW4gcmV2ZXJzZSBkaXJlY3Rpb24gb2YgYSBCRkQgc2Vzc2lvbiBvbiB0aGUg U2VnbWVudCBSb3V0aW5nDQogICBuZXR3b3JrIG92ZXIgTVBMUyBkYXRhcGxhbmUuDQoNCg0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnLz4u DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1h aWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzDQoNCg0KDQo= --_000_F3C093E0FE4E41C0B9EB0CA1CB52DBE7ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9F15CA7F15AE9241B8FCFE110D7EACC6@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhhbmsgeW91IEdyZWchDQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5TaW5jZSA8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQt MDAiIGNsYXNzPSIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1pcnNreS1z cHJpbmctYmZkLTAwPC9hPiBzZWVtcyBxdWl0ZSBzaW1pbGFyIHRvIHRoZSB0ZXh0IHJlbW92ZWQg YXQNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtbXBscy1iZmQtZGlyZWN0ZWQtMDUudHh0IiBjbGFzcz0iIj4NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZWQtMDUudHh0PC9h PiwgdGhlbiB0aGUgY29tcGxldGUgc2V0IG9mIG91dHN0YW5kaW5nIHRlY2huaWNhbCBjb21tZW50 cyB0aGF0IHRyaWdnZXJlZCB0aGUgcmVtb3ZhbCBvZiB0aGF0IHRleHQgZnJvbSBkcmFmdC1pZXRm LW1wbHMtYmZkLWRpcmVjdGVkLTA1LnR4dCBtaWdodCBwZWVrIHlvdXIgaW50ZXJlc3QgOi0pPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5P bmUgdGhhdCBJIHJlY2FsbCBpczogd2h5IHVzZSBsYWJlbCB2YWx1ZXMgd2hlbiBldmVyeSBvdGhl ciByZXR1cm4tcGF0aCBzdWItVExWIGZvciBCRkQgYW5kIGZvciBMU1AtUGluZywgaW5jbHVkaW5n IGRyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZWQsIHVzZXMgVEZTcz8mbmJzcDs8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJlc3QsPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7i gJQgQ2FybG9zLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE1heSA5LCAy MDE3LCBhdCAxMjowMCBQTSwgR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1p cnNreUBnbWFpbC5jb20iIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7IHdy b3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5EZWFyIENhcmxvcywNCjxkaXYgY2xh c3M9IiI+SSd2ZSBkZWNpZGVkIHRvIHJlLXN0YXJ0IHRoZSBkaXNjdXNzaW9uIGFuZCBhbSBpbnRl cmVzdGVkIHRvIGhlYXIgdGVjaG5pY2FsIGNvbW1lbnRzIHRvIHRoZSBwcm9wb3NlZCBzb2x1dGlv bi4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPlJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkdyZWc8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj5PbiBUdWUsIE1heSA5LCAyMDE3IGF0IDg6NTEgQU0sIENhcmxvcyBQaWduYXRh cm8gKGNwaWduYXRhKQ0KPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPiZsdDs8YSBocmVmPSJtYWls dG86Y3BpZ25hdGFAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+Y3BpZ25hdGFA Y2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFw OmJyZWFrLXdvcmQiIGNsYXNzPSIiPkRlYXIgR3JlZywNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkN1cnNvcmlseSBzY2FubmluZyB0aHJvdWdoIHRo aXMsIGl0IHNlZW1zIHRoYXQgbW9zdCBjb25jZXJucyByYWlzZWQgYW5kIGNvbW1lbnRzIG1hZGUg YWJvdXQgdGhlIFNSIHNlY3Rpb25zIG9mJm5ic3A7ZHJhZnQtaWV0Zi1tcGxzLWJmZC08d2JyIGNs YXNzPSIiPmRpcmVjdGVkLTBOICh3aXRoIE4gJmx0OyA1KSBhcHBseSB0byB5b3VyIG5ldyBkcmFm dC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlRoaXMgaXMgb25lIG9mIHRob3NlOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50L21zZzE1ODYwLmh0bWwiIHRhcmdldD0i X2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy88d2JyIGNsYXNzPSIiPm1haWwt YXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50Lzx3YnIgY2xhc3M9IiI+bXNnMTU4NjAuaHRtbDwvYT4g 4oCUIHRoZSBsaXN0IGFyY2hpdmUgc2hvd3MNCiBhIGZldyBtb3JlLiBUaGUgY29weS9wYXN0ZSBk aWQgbm90IGFkZHJlc3MgdGhlIGNvbW1lbnRzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QmVzdCw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlCBDYXJsb3MuPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJoNSI+DQo8 ZGl2IGNsYXNzPSIiPk9uIE1heSA4LCAyMDE3LCBhdCAxMTozMyBQTSwgR3JlZyBNaXJza3kgJmx0 OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBj bGFzcz0iIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBj bGFzcz0ibV80MTg3ODE3MTU1MzM0NjA3ODE3QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSJoNSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5EZWFyIEFsbCwNCjxkaXYgY2xhc3M9IiI+ cGVyaGFwcyB0aGlzIG5ldyBkcmFmdCBtYXkgaXMgb2YgaW50ZXJlc3QgdG8geW91LjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5Zb3VyIGNvbW1lbnRzLCBzdWdnZXN0aW9ucyBhcmUgbW9zdCB3ZWxjb21l IGFuZCBncmVhdGx5IGFwcHJlY2lhdGVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UmVnYXJkcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ R3JlZzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+LS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyIGNsYXNz PSIiPg0KRnJvbTogPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPjwvYj48c3BhbiBkaXI9Imx0 ciIgY2xhc3M9IiI+Jmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0 Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQpEYXRlOiBNb24sIE1heSA4LCAyMDE3IGF0IDg6MjkgUE08 YnIgY2xhc3M9IiI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LW1pcnNreS1zcHJpbmctYmZkLTAwLnR4dDxiciBjbGFzcz0iIj4NClRvOiBHcmVnb3J5IE1pcnNr eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwLnR4dDxiciBjbGFzcz0iIj4NCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR3JlZyBNaXJza3kgYW5kIHBvc3RlZCB0 byB0aGU8YnIgY2xhc3M9IiI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KTmFtZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Ry YWZ0LW1pcnNreS1zcHJpbmctYmZkPGJyIGNsYXNzPSIiPg0KUmV2aXNpb246Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7MDA8YnIgY2xhc3M9IiI+DQpUaXRsZTombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkg aW4gU2VnbWVudCBSb3V0aW5nIE5ldHdvcmtzIFVzaW5nIE1QTFMgRGF0YXBsYW5lPGJyIGNsYXNz PSIiPg0KRG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxNy0wNS0wODxiciBjbGFzcz0iIj4NCkdyb3Vw OiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9u PGJyIGNsYXNzPSIiPg0KUGFnZXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA3 PGJyIGNsYXNzPSIiPg0KVVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1t aXJza3ktc3ByaW5nLWJmZC0wMC50eHQiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtPHdiciBjbGFzcz0iIj5k cmFmdHMvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQ8d2JyIGNsYXNzPSIiPi0wMC50eHQ8L2E+PGJy IGNsYXNzPSIiPg0KU3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXJza3ktc3ByaW5n LWJmZC8iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvPHdiciBjbGFzcz0iIj5kb2MvZHJhZnQtbWlyc2t5LXNwcmlu Zy1iZmQvPC9hPjxiciBjbGFzcz0iIj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1taXJza3ktc3By aW5nLWJmZC0wMCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Q8d2JyIGNsYXNzPSIiPnJhZnQtbWlyc2t5LXNwcmlu Zy1iZmQtMDA8L2E+PGJyIGNsYXNzPSIiPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1taXJza3ktc3ByaW5nLWJmZC0wMCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy88d2JyIGNsYXNzPSIiPmRvYy9o dG1sL2RyYWZ0LW1pcnNreS1zcHJpbmctYjx3YnIgY2xhc3M9IiI+ZmQtMDA8L2E+PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQWJzdHJhY3Q6PGJyIGNsYXNzPSIi Pg0KJm5ic3A7ICZuYnNwO1NlZ21lbnQgUm91dGluZyBhcmNoaXRlY3R1cmUgbGV2ZXJhZ2VzIHRo ZSBwYXJhZGlnbSBvZiBzb3VyY2U8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7cm91dGluZy4m bmJzcDsgSXQgY2FuIGJlIHJlYWxpemVkIGluIHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRj aGluZzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsoTVBMUykgbmV0d29yayB3aXRob3V0IGFu eSBjaGFuZ2UgdG8gdGhlIGRhdGEgcGxhbmUuJm5ic3A7IEEgc2VnbWVudCBpczxiciBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDtlbmNvZGVkIGFzIGFuIE1QTFMgbGFiZWwgYW5kIGFuIG9yZGVyZWQg bGlzdCBvZiBzZWdtZW50cyBpcyBlbmNvZGVkPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2Fz IGEgc3RhY2sgb2YgbGFiZWxzLiZuYnNwOyBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0 aW9uIChCRkQpIGlzPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2V4cGVjdGVkIHRvIG1vbml0 b3IgYW55IGtpbmQgb2YgcGF0aHMgYmV0d2VlbiBzeXN0ZW1zLiZuYnNwOyBUaGlzIGRvY3VtZW50 PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2RlZmluZXMgaG93IHRvIHVzZSBMYWJlbCBTd2l0 Y2hlZCBQYXRoIFBpbmcgdG8gYm9vdHN0cmFwIGFuZCBjb250cm9sPGJyIGNsYXNzPSIiPg0KJm5i c3A7ICZuYnNwO3BhdGggaW4gcmV2ZXJzZSBkaXJlY3Rpb24gb2YgYSBCRkQgc2Vzc2lvbiBvbiB0 aGUgU2VnbWVudCBSb3V0aW5nPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO25ldHdvcmsgb3Zl ciBNUExTIGRhdGFwbGFuZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJy IGNsYXNzPSIiPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvIiByZWw9Im5vcmVmZXJyZXIi IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX188d2JyIGNsYXNzPSIiPl9f X19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9 IiI+DQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz PSIiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyIGNsYXNzPSIiPmxpc3RpbmZvL21wbHM8 L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F3C093E0FE4E41C0B9EB0CA1CB52DBE7ciscocom_-- From nobody Tue May 9 12:44:06 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C1A1295A0; Tue, 9 May 2017 12:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye9bWEJv03xO; Tue, 9 May 2017 12:43:55 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 9C79D129477; Tue, 9 May 2017 12:43:55 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id l18so12511189oig.2; Tue, 09 May 2017 12:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HfyriXuk6qw3zG8RgGrsFjfIh4fDS3nL7fTX9iZc1Sw=; b=X+Syb4gHHVzNyfs4UZWIX7jx0oajICpwjq80hQHnIAsQcaEtLIy7p1L8bffnv3OqTO xfgwIGIS6rBtNRVlw/+vcVfmYNWPuaYqzgy6nnsoGjEcYunPhVkZCIDx8CEblpGuaN4G IZd4n4k0h8EMhKG9DBBjfgG7s2E/PgHHjicWvvib6suUrJ2w7t+/OnyhAs62OSniFjzv MriMpqdu2f/WHRT2cizbEWyUrqabiv5kbheTWmSCYeuwqRxb5c7eTHMJMh9YoGlKIJ8B A2VxKn3TtIlb00pvJA6ZLuXAzItODp45/CBMSMjLRyYU+w/LVNLXwnPprlRMFrNHx2Pc KDsg== 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=HfyriXuk6qw3zG8RgGrsFjfIh4fDS3nL7fTX9iZc1Sw=; b=lotx8monuhdUj0vmICRQjW0r3Lufrzc3da1K5+i+2rE0soohl1PEVerHZ4iIOk9Aol wkRSCQ0QoUf64ZrS9rn+ilp+hxjPE28MPKQq3yajtzXi/OF+ehnpmzuBefsGFcZYCwxZ Act+pfPGKBhXQQkEUHI5BvYSL9FPqpS1lq4PaLrUwPZkOiLaRoSVzrprMDCRaXucoaV4 BPa/djTlVhhwrMwXh4NbQZU85FZxnOC1k8E7cKqkxE7kmtv4gTQmnBBNkNH/K+DzmsIE gkexet8nrGieAfNQyr6treX9NQnFE8jmSwPSq9fYqKp78GMBDj504D+rqZ6GQOOnYK95 /Flw== X-Gm-Message-State: AODbwcAhctKVefbI4VxF/050WzLeAdX/1Sa9F3JqT2lM2oYnor4OlNT0 y93gxtF9NmAhGgzTDgyeKqjiI9f98g== X-Received: by 10.202.198.208 with SMTP id w199mr708191oif.115.1494359034868; Tue, 09 May 2017 12:43:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.246 with HTTP; Tue, 9 May 2017 12:43:54 -0700 (PDT) In-Reply-To: References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> From: Greg Mirsky Date: Tue, 9 May 2017 12:43:54 -0700 Message-ID: To: "Carlos Pignataro (cpignata)" Cc: "spring@ietf.org" , "rtg-bfd@ietf.org" , "mpls@ietf.org" Content-Type: multipart/alternative; boundary=001a1134fbb470c137054f1c9329 Archived-At: Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 19:43:58 -0000 --001a1134fbb470c137054f1c9329 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, I probably would characterize anything that starts with Why not as a technical comment but rather as a question. According to draft-ietf-spring-segment-routing-mpls, "In the MPLS dataplane= ,the SR header is instantiated through a label stack". At the same time, one of advantages of SR is that "per-flow state only [maintained] at the ingress node to the SR domain". Thus, for the case of monitoring unidirectional SR tunnels, I consider that there's no need to create any additional state on the egress node. Of course, if there were bidirectional SR tunnels, then control of the reverse direction of the BFD session would not require use of the Return Path sub-TLV. As for LSP-Ping, I just propose that the Segment Routing MPLS Tunnel sub-TLV MAY be used Reply Path TLV defined in RFC 7110. I viewed the proposal as invitation to technical discussion. Regards, Greg On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Thank you Greg! > > Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems quite > similar to the text removed at https://tools.ietf.org/ > rfcdiff?url2=3Ddraft-ietf-mpls-bfd-directed-05.txt, then the complete set > of outstanding technical comments that triggered the removal of that text > from draft-ietf-mpls-bfd-directed-05.txt might peek your interest :-) > > One that I recall is: why use label values when every other return-path > sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directed, > uses TFSs? > > Best, > > =E2=80=94 Carlos. > > On May 9, 2017, at 12:00 PM, Greg Mirsky wrote: > > Dear Carlos, > I've decided to re-start the discussion and am interested to hear > technical comments to the proposed solution. > > Regards, > Greg > > On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Dear Greg, >> >> Cursorily scanning through this, it seems that most concerns raised and >> comments made about the SR sections of draft-ietf-mpls-bfd-directed-0N >> (with N < 5) apply to your new draft. >> >> This is one of those: https://www.ietf.org/ma >> il-archive/web/mpls/current/msg15860.html =E2=80=94 the list archive sho= ws a few >> more. The copy/paste did not address the comments. >> >> Best, >> >> =E2=80=94 Carlos. >> >> On May 8, 2017, at 11:33 PM, Greg Mirsky wrote: >> >> Dear All, >> perhaps this new draft may is of interest to you. >> Your comments, suggestions are most welcome and greatly appreciated. >> >> Regards, >> Greg >> >> ---------- Forwarded message ---------- >> From: >> Date: Mon, May 8, 2017 at 8:29 PM >> Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt >> To: Gregory Mirsky >> >> >> >> A new version of I-D, draft-mirsky-spring-bfd-00.txt >> has been successfully submitted by Greg Mirsky and posted to the >> IETF repository. >> >> Name: draft-mirsky-spring-bfd >> Revision: 00 >> Title: Bidirectional Forwarding Detection (BFD) in Segment >> Routing Networks Using MPLS Dataplane >> Document date: 2017-05-08 >> Group: Individual Submission >> Pages: 7 >> URL: https://www.ietf.org/internet- >> drafts/draft-mirsky-spring-bfd-00.txt >> Status: https://datatracker.ietf.org/doc/draft-mirsky-spring-bfd= / >> Htmlized: https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 >> Htmlized: https://datatracker.ietf.org/ >> doc/html/draft-mirsky-spring-bfd-00 >> >> >> Abstract: >> Segment Routing architecture leverages the paradigm of source >> routing. It can be realized in the Multiprotocol Label Switching >> (MPLS) network without any change to the data plane. A segment is >> encoded as an MPLS label and an ordered list of segments is encoded >> as a stack of labels. Bidirectional Forwarding Detection (BFD) is >> expected to monitor any kind of paths between systems. This document >> defines how to use Label Switched Path Ping to bootstrap and control >> path in reverse direction of a BFD session on the Segment Routing >> network over MPLS dataplane. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> > > --001a1134fbb470c137054f1c9329 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos,
I probably would characterize anything that= starts with Why not as a technical comment but rather as a question.
=
According to=C2=A0draft-ietf-spring= -segment-routing-mpls, "In the MPLS=C2=A0dataplane,the SR header is insta= ntiated through a label stack".
At the same time, one of advantages of SR is that &qu= ot;per-flow state only [maintained] at the ingress node to th= e SR=C2=A0domain".
Thus, for the case of monitoring unid= irectional SR tunnels, I consider that there's no need to create any ad= ditional state on the egress node.
Of course, if there were bidirectional S= R tunnels, then control of the reverse direction of the BFD session would n= ot require use of the Return Path sub-TLV.
As for LSP-Ping, I just propose = that the Segment Routing MPLS Tunnel sub-TLV MAY be used Reply Path TLV def= ined in RFC 7110. I viewed the proposal as invitation to technical discussi= on.

Regards,
Greg
=
On Tue, May 9, 2017 at 9:07 AM, Carlos Pigna= taro (cpignata) <cpignata@cisco.com> wrote:
Thank you Greg!

Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems quite= similar to the text removed at https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-bfd-directe= d-05.txt, then the complete set of outstanding technical comments that = triggered the removal of that text from draft-ietf-mpls-bfd-directed-0= 5.txt might peek your interest :-)

One that I recall is: why use label values when every other return-pat= h sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directed,= uses TFSs?=C2=A0

Best,

=E2=80=94 Carlos.

On May 9, 2017, at 12:00 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear Carlos,
I've decided to re-start the discussion and am interested to hear = technical comments to the proposed solution.=C2=A0

Regards,
Greg

On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro= (cpignata) <cpignata@cisco.com> wrote:
Dear Greg,

Cursorily scanning through this, it seems that most concerns raised an= d comments made about the SR sections of=C2=A0draft-ietf-mpls-bfd-directed-0N (with N < 5) apply to your new draft.

This is one of those:=C2=A0https://www.ietf.org/ma= il-archive/web/mpls/current/msg15860.html =E2=80=94 the list = archive shows a few more. The copy/paste did not address the comments.

Best,

=E2=80=94 Carlos.

On May 8, 2017, at 11:33 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear All,
perhaps this new draft may is of interest to you.
Your comments, suggestions are most welcome and greatly appreciated.

Regards,
Greg

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <gregimirsky@gmail.com>



A new version of I-D, draft-mirsky-spring-bfd-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-spring-bfd
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bidirectional Forwarding Detection= (BFD) in Segment Routing Networks Using MPLS Dataplane
Document date:=C2=A0 2017-05-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-spring-bfd-00.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-mirsky-spring-bfd-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-mirsky-spring-bfd-00<= /a>


Abstract:
=C2=A0 =C2=A0Segment Routing architecture leverages the paradigm of source<= br> =C2=A0 =C2=A0routing.=C2=A0 It can be realized in the Multiprotocol Label S= witching
=C2=A0 =C2=A0(MPLS) network without any change to the data plane.=C2=A0 A s= egment is
=C2=A0 =C2=A0encoded as an MPLS label and an ordered list of segments is en= coded
=C2=A0 =C2=A0as a stack of labels.=C2=A0 Bidirectional Forwarding Detection= (BFD) is
=C2=A0 =C2=A0expected to monitor any kind of paths between systems.=C2=A0 T= his document
=C2=A0 =C2=A0defines how to use Label Switched Path Ping to bootstrap and c= ontrol
=C2=A0 =C2=A0path in reverse direction of a BFD session on the Segment Rout= ing
=C2=A0 =C2=A0network over MPLS dataplane.




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

The IETF Secretariat


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls




--001a1134fbb470c137054f1c9329-- From nobody Tue May 9 18:44:43 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2688112EBA6; Tue, 9 May 2017 18:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 tpnmw3R0b9hS; Tue, 9 May 2017 18:44:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65DC112EB98; Tue, 9 May 2017 18:44:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGH37943; Wed, 10 May 2017 01:44:37 +0000 (GMT) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 10 May 2017 02:44:36 +0100 Received: from DGGEML508-MBX.china.huawei.com ([169.254.3.84]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0301.000; Wed, 10 May 2017 09:44:28 +0800 From: Mach Chen To: Lizhenbin , Loa Andersson , "mpls@ietf.org" , "mpls-chairs@ietf.org" CC: "draft-bryant-mpls-rfc6374-sfl@ietf.org" Thread-Topic: R: IPR poll on draft-bryant-mpls-rfc6374-sfl Thread-Index: AQHSvwbczYvetV6PbE2sGAJMrk4OoKHYfVwAgAAaI4CAAAO7AIAF+8EAgAEYvICABd3VYA== Date: Wed, 10 May 2017 01:44:27 +0000 Message-ID: References: <8b495d71-1291-cd59-9faa-fff371c9535f@pi.nu> <2d27868ab59943cc964a1c715b58521e@TELMBXB02RM001.telecomitalia.local> <82bbc067-3526-8999-ad84-80654cccea55@pi.nu>, <8a36b471f3c24e848a3cc05278d16003@TELMBXB02RM001.telecomitalia.local> <1493624158511.94291@telecomitalia.it> <5A5B4DE12C0DAC44AF501CD9A2B01A8D8DEFDD8E@NKGEML515-MBS.china.huawei.com> In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8DEFDD8E@NKGEML515-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59127086.0002, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.84, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ccdab2c1228f5e105517271214225aeb Archived-At: Subject: Re: [mpls] R: IPR poll on draft-bryant-mpls-rfc6374-sfl X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 01:44:42 -0000 SGkgTG9hLA0KDQpJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgKG90aGVyIHRoYW4gdGhlIG9uZSBk aXNjbG9zZWQpIHJlbGF0ZWQgdG8gdGhpcyBkb2N1bWVudC4NCg0KQmVzdCByZWdhcmRzLA0KTWFj aA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1wbHMgW21haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMaXpoZW5iaW4NCj4gU2VudDogVHVl c2RheSwgTWF5IDAyLCAyMDE3IDg6MjEgQU0NCj4gVG86IExvYSBBbmRlcnNzb24gPGxvYUBwaS5u dT47IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQGlldGYub3JnDQo+IENjOiBkcmFmdC1icnlh bnQtbXBscy1yZmM2Mzc0LXNmbEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbbXBsc10gtPC4tDogUjog SVBSIHBvbGwgb24gZHJhZnQtYnJ5YW50LW1wbHMtcmZjNjM3NC1zZmwNCj4gDQo+IEhpIExvYSwN Cj4gSSdtIG5vdCBhd2FyZSBvZiBvdGhlciBJUFIgcmVsYXRlZCB0byB0aGUgZHJhZnQgYmVzaWRl cyB0aGF0IGhhcyBhbHJlYWR5IGJlZW4NCj4gZGlzY2xvc2VkLg0KPiANCj4gQmVzdCBSZWdhcmRz LA0KPiBaaGVuYmluKFJvYmluKQ0KPiANCj4gDQo+IA0KPiA+DQo+ID4gLS0tLS1NZXNzYWdnaW8g b3JpZ2luYWxlLS0tLS0NCj4gPiBEYTogTG9hIEFuZGVyc3NvbiBbbWFpbHRvOmxvYUBwaS5udV0N Cj4gPiBJbnZpYXRvOiBnaW92ZWSorCAyNyBhcHJpbGUgMjAxNyAwNTozMg0KPiA+IEE6IG1wbHNA aWV0Zi5vcmcNCj4gPiBDYzogbXBscy1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWJyeWFudC1tcGxz LXJmYzYzNzQtc2ZsQGlldGYub3JnDQo+ID4gT2dnZXR0bzogSVBSIHBvbGwgb24gZHJhZnQtYnJ5 YW50LW1wbHMtcmZjNjM3NC1zZmwNCj4gPg0KPiA+IFdvcmtpbmcgR3JvdXAsDQo+ID4NCj4gPiBU aGUgYXV0aG9yIG9mIGRyYWZ0LWJyeWFudC1tcGxzLXJmYzYzNzQtc2ZsIGhhcyB0b2xkIHVzIHRo YXQgdGhlIGRvY3VtZW50DQo+IGlzIHJlYWR5IHRvIGJlIGNvbnNpZGVyZWQgZm9yIHdvcmtpbmcg YWRvcHRpb24uDQo+ID4NCj4gPiBUaGUgZG9jdW1lbnQgYmVlbiB0aHJvdWdoIE1QTFMtUlQgcmV2 aWV3LiBXZSB3aWxsIGRvIGFuIElQUiBwb2xsDQo+IHBhcmFsbGVsIHRvIHRoZSBzdGFydCBvZiB0 aGUgYWRvcHRpb24gcG9sbC4NCj4gPg0KPiA+IFRoaXMgbWFpbCBzdGFydHMgdGhlIElQUiBwb2xs Lg0KPiA+DQo+ID4gQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFm dC1icnlhbnQtbXBscy1yZmM2Mzc0LXNmbD8NCj4gPg0KPiA+IElmIHNvLCBoYXMgdGhpcyBJUFIg YmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZD cw0KPiAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KPiA+DQo+ ID4gVGhlcmUgaXMgb25lIElQUiBkaXNjbG9zdXJlIGZpbGVkIGRpcmVjdGx5IGFnYWluc3QgdGhp cyBkb2N1bWVudC4NCj4gPg0KPiA+IElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0 aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMNCj4gZW1haWwgcmVnYXJk bGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIu ICpUaGUNCj4gcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0aGUgTVBMUyB3ZyBtYWlsaW5n IGxpc3QuKiBUaGUgZG9jdW1lbnQgd2lsbA0KPiBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFn ZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaA0KPiBhdXRob3Ig YW5kIGNvbnRyaWJ1dG9yLg0KPiA+DQo+ID4gSWYgeW91IGFyZSBvbiB0aGUgTVBMUyBXRyBlbWFp bCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3INCj4gY29udHJpYnV0b3Is IHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2Yg YW55IElQUg0KPiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNl IHdpdGggSUVURiBydWxlcy4NCj4gPg0KPiA+DQo+ID4gL0xvYQ0KPiA+IG1wbHMgd2cgY28tY2hh aXINCj4gPg0KPiANCj4gLS0NCj4gDQo+IA0KPiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAg ICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPiBTZW5pb3IgTVBMUyBFeHBl cnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KPiBIdWF3ZWkgVGVjaG5vbG9n aWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCj4gDQo+IFF1ZXN0 byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFt ZW50ZSBhbGxlDQo+IHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVh bHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGENCj4gY29ub3NjZW56YSBkaSBxdWVz dGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhDQo+IGFi YmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2Vt ZW50ZSBwcmVnYXRpIGRpDQo+IGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRl bnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YQ0KPiBkaXN0cnV6aW9uZSwgR3JhemllLg0KPiAN Cj4gVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1h eSBjb250YWluIHByaXZpbGVnZWQNCj4gaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRy ZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywNCj4gcHJpbnRpbmcgb3IgdXNl IGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZA0KPiByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0 YWNobWVudHMgYW5kIGFkdmlzZSB0aGUNCj4gc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5r cy4NCj4gDQo+IFJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBz ZSBub24gqKggbmVjZXNzYXJpby4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From nobody Wed May 10 04:00:54 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D35129B01; Wed, 10 May 2017 04:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ucKbuPIsmftp; Wed, 10 May 2017 04:00:50 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30138.outbound.protection.outlook.com [40.107.3.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73582129B00; Wed, 10 May 2017 04:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UXH7yIQTu7TGRowV6edY7IVbqGSWVbvKmdiAqHKtPNo=; b=SwIpoD3pVLcakyM3CB6WzUMgC7xAcVOZ4pDvoywaHx3FNfVjyQQj6KwwZQh53TCqnw62rCwBmz2W8m7rVpojvPS+5pD7TnklgSZ8cxT4760xNMvaBCZ9Il1Y4rZsf1VKgPm6+PBuuqnX/BZtracBo5JUsPqO02leofGY7ufFTNw= Received: from DB4PR07MB314.eurprd07.prod.outlook.com (10.141.234.15) by DB4PR07MB316.eurprd07.prod.outlook.com (10.141.234.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Wed, 10 May 2017 11:00:48 +0000 Received: from DB4PR07MB314.eurprd07.prod.outlook.com ([fe80::d934:270e:e6a2:4f43]) by DB4PR07MB314.eurprd07.prod.outlook.com ([fe80::d934:270e:e6a2:4f43%16]) with mapi id 15.01.1084.014; Wed, 10 May 2017 11:00:48 +0000 From: "Bocci, Matthew (Nokia - GB)" To: "mpls@ietf.org" , "draft-bryant-mpls-sfl-framework@ietf.org" CC: "mpls-chairs@ietf.org" Thread-Topic: MPLS-RT review of draft-bryant-mpls-sfl-framework-04 Thread-Index: AQHSyXyubno0L7diUE+waDh2NhVRQw== Date: Wed, 10 May 2017 11:00:48 +0000 Message-ID: <74FA86D7-E0FB-4E5D-A5D3-64324CB2A656@nokia.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [81.131.107.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB316; 7:zKzstGKlaS+IICRq7wz0/72BPej11MfE87xiyw/y3C4TYswht7VdqfEvLwQaj3sm/ZdK9IABPiBwzfnroNFEKjfZ/zRI2PRmfGTbHqQGaKBxLZ8DxfIJ1Gulr3JuHv0KX6VGmMKLAOGovxiuRot/NO8L+aqLFEHdWh8BBG3iZkbgLqRKiULNz04Y1lAmOEoiivsOKzf63SE1zf3wureNlVKQVraFvkFFS5cEBE4Ww+X8iLJCyITuGkAE/NiiEeBOyhcbj+bH09bIkA/n64YNWjUShK7URQPpKvyYsUI/rJt18ffhCNQfL2h8+6TtkqPjI8He0zIh1LEz7QCj8i08OA== x-ms-office365-filtering-correlation-id: 2f35e7fa-9d8d-452d-abbb-08d49793d0b6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB4PR07MB316; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:DB4PR07MB316; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB316; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39840400002)(39410400002)(39860400002)(39850400002)(66066001)(450100002)(54356999)(53936002)(2906002)(189998001)(83506001)(4326008)(5660300001)(38730400002)(33656002)(83716003)(7736002)(4001350100001)(230783001)(5250100002)(2501003)(82746002)(54896002)(50986999)(81166006)(6506006)(6436002)(6116002)(86362001)(25786009)(2900100001)(8936002)(8676002)(102836003)(6512007)(3846002)(3660700001)(99286003)(36756003)(478600001)(6486002)(6306002)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR07MB316; H:DB4PR07MB314.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_74FA86D7E0FB4E5DA5D364324CB2A656nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2017 11:00:48.3071 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB316 Archived-At: Subject: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-framework-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 11:00:53 -0000 --_000_74FA86D7E0FB4E5DA5D364324CB2A656nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gYXV0aG9ycyBhbmQgV0csDQoNCkkgYW0gYW4gTVBMUy1SVCByZXZpZXdlciBhc3NpZ25l ZCB0byByZXZpZXcgZHJhZnQtYnJ5YW50LW1wbHMtc2ZsLWZyYW1ld29yay0wNC4NCg0KSSBoYXZl IHJldmlld2VkIHRoZSBkcmFmdCBhbmQgZm91bmQgdGhhdCBpdCBpcyB3ZWxsIHdyaXR0ZW4gYW5k IGNvaGVyZW50LCBhbmQgaXMgYSBwb3RlbnRpYWxseSB1c2VmdWwgc29sdXRpb24uDQoNCkhvd2V2 ZXIsIEkgaGF2ZSBhIGNvbmNlcm4gd2l0aCB0aGUgZm9sbG93aW5nIHRleHQgaW4gc2VjdGlvbiA0 IGRlc2NyaWJpbmcgRUNNUCBhbmQgRUwvRUxJOg0KDQrigJwgIDIuICBUaGUgb3BlcmF0b3IgY2Fu IGVsZWN0IHRvIHVzZSBbUkZDNjc5MF0gRW50cm9weSBMYWJlbHMgd2hpY2gsIGluDQogICAgICAg YSBuZXR3b3JrIHRoYXQgZnVsbHkgc3VwcG9ydHMgdGhpcyB0eXBlIG9mIEVDTVAsIHJlc3VsdHMg aW4gdGhlDQogICAgICAgRUNNUCBkZWNpc2lvbiBiZWluZyBpbmRlcGVuZGVudCBvZiB0aGUgdmFs dWUgb2YgdGhlIG90aGVyIGxhYmVscw0KICAgICAgIGluIHRoZSBsYWJlbCBzdGFjay7igJ0NCg0K SSBkb27igJl0IHRoaW5rIHlvdSBjYW4gYXNzdW1lIHRoYXQgaW50ZXJtZWRpYXRlIExTUiBpbXBs ZW1lbnRhdGlvbnMgb25seSB1c2UgdGhlIEVMIHdoZW4gc3ByYXlpbmcgcGFja2V0cy4gQWx0aG91 Z2ggUkZDNjc5MCBkb2VzIG1lbnRpb24gdGhpcyBhcyBvbmUgb3B0aW9uLCBJIGJlbGlldmUgdGhl IG1vcmUgY29tbW9uIGNhc2UgaXMgdG8gdGFrZSBpbnRvIGFjY291bnQgb3RoZXIgbGFiZWxzIGlu IHRoZSBzdGFjayBpbmNsdWRpbmcgdGhlIEVMLiBUaGUgRUwgaXMgZWZmZWN0aXZlbHkgc2F5aW5n IOKAnGFsbCBvdGhlciB0aGluZ3MgYmVpbmcgZXF1YWwsIGhlcmUgaXMgc29tZSBhZGRpdGlvbmFs IGluZm9ybWF0aW9uIHRvIGRpc3Rpbmd1aXNoIGZsb3dz4oCdLiBJdCBpcyBpbiBhZGRpdGlvbiB0 bywgYnV0IG5vdCBhbiBhbHRlcm5hdGl2ZSB0byB0aGUgcmVzdCBvZiB0aGUgbGFiZWwgc3RhY2su IElmIHRoZSBTRkwgdmFsdWUgZm9yIHBhY2tldHMgb24gYSBnaXZlbiBmbG93IGRpZmZlcnMsIGJ1 dCB0aGUgRUwgaXMgdGhlIHNhbWUsIHRoZW4gdGhlIExTUiB3b3VsZCBzdGlsbCBzcHJheSB0aGUg cGFja2V0cyBiZWNhdXNlIHRoZSBsYWJlbCBzdGFjayB3b3VsZCBiZSBkaWZmZXJlbnQuDQoNCkkg ZG9u4oCZdCB0aGluayB0aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8gbWFuZGF0ZSB0aGF0IExTUnMg b25seSBjb25zaWRlciB0aGUgRUwgYW5kIGlnbm9yZSBhbGwgb3RoZXIgbGFiZWxzIGluIHRoZSBz dGFjayBnaXZlbiB0aGUgaW1wYWN0IG9uIHRoZSBkZXBsb3llZCBiYXNlIGZvciBqdXN0IGEgZmV3 IGVuZC10by1lbmQgYXBwbGljYXRpb25zLg0KDQpJIGRvbuKAmXQgdGhpbmsgdGhpcyBkcmFmdCBz aG91bGQgYmUgYm90aCBkZWZpbmluZyBTRkxzIGFuZCB0cnlpbmcgdG8gc29sdmUgdGhlIGdlbmVy YWwgRUNNUCBwcm9ibGVtIGZvciBhcHBsaWNhdGlvbnMgb2YgU0ZMcy4gSW5zdGVhZCwgaXQgc2hv dWxkIGZvY3VzIG9uIHRoZSBTRkwgaXRzZWxmLiBNeSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIGNo YW5nZSBzZWN0aW9uIDQgdG8gc2F5IHRoYXQgRUNNUCBjb25zaWRlcmF0aW9ucyBzaG91bGQgYWRk cmVzc2VkIGJ5IGFuIGFwcGxpY2F0aW9uIG9mIFNGTCBpZiBFQ01QIGlzIGEgY29uY2VybiBmb3Ig dGhhdCBhcHBsaWNhdGlvbi4NCg0KDQpCZXN0IHJlZ2FyZHMNCg0KTWF0dGhldw0K --_000_74FA86D7E0FB4E5DA5D364324CB2A656nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglt c28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRl YWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo1OTUuMHB0IDg0Mi4wcHQ7DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1HQiIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5I ZWxsbyBhdXRob3JzIGFuZCBXRyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkkgYW0gYW4gTVBMUy1SVCByZXZpZXdlciBhc3NpZ25lZCB0byByZXZpZXcgZHJhZnQt YnJ5YW50LW1wbHMtc2ZsLWZyYW1ld29yay0wNC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkkgaGF2ZSByZXZpZXdlZCB0aGUgZHJhZnQgYW5kIGZvdW5kIHRoYXQg aXQgaXMgd2VsbCB3cml0dGVuIGFuZCBjb2hlcmVudCwgYW5kIGlzIGEgcG90ZW50aWFsbHkgdXNl ZnVsIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ SG93ZXZlciwgSSBoYXZlIGEgY29uY2VybiB3aXRoIHRoZSBmb2xsb3dpbmcgdGV4dCBpbiBzZWN0 aW9uIDQgZGVzY3JpYmluZyBFQ01QIGFuZCBFTC9FTEk6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij7igJwmbmJzcDsgMi4mbmJzcDsgVGhlIG9wZXJhdG9yIGNhbiBl bGVjdCB0byB1c2UgW1JGQzY3OTBdIEVudHJvcHkgTGFiZWxzIHdoaWNoLCBpbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYSBuZXR3b3JrIHRo YXQgZnVsbHkgc3VwcG9ydHMgdGhpcyB0eXBlIG9mIEVDTVAsIHJlc3VsdHMgaW4gdGhlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFQ01QIGRl Y2lzaW9uIGJlaW5nIGluZGVwZW5kZW50IG9mIHRoZSB2YWx1ZSBvZiB0aGUgb3RoZXIgbGFiZWxz PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBp biB0aGUgbGFiZWwgc3RhY2su4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5JIGRvbuKAmXQgdGhpbmsgeW91IGNhbiBhc3N1bWUgdGhhdCBpbnRlcm1lZGlhdGUg TFNSIGltcGxlbWVudGF0aW9ucyBvbmx5IHVzZSB0aGUgRUwgd2hlbiBzcHJheWluZyBwYWNrZXRz LiBBbHRob3VnaCBSRkM2NzkwIGRvZXMgbWVudGlvbiB0aGlzIGFzIG9uZSBvcHRpb24sIEkgYmVs aWV2ZSB0aGUgbW9yZSBjb21tb24gY2FzZSBpcyB0byB0YWtlIGludG8gYWNjb3VudA0KIG90aGVy IGxhYmVscyBpbiB0aGUgc3RhY2sgaW5jbHVkaW5nIHRoZSBFTC4gVGhlIEVMIGlzIGVmZmVjdGl2 ZWx5IHNheWluZyDigJxhbGwgb3RoZXIgdGhpbmdzIGJlaW5nIGVxdWFsLCBoZXJlIGlzIHNvbWUg YWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0byBkaXN0aW5ndWlzaCBmbG93c+KAnS4gSXQgaXMgaW4g YWRkaXRpb24gdG8sIGJ1dCBub3QgYW4gYWx0ZXJuYXRpdmUgdG8gdGhlIHJlc3Qgb2YgdGhlIGxh YmVsIHN0YWNrLiBJZiB0aGUgU0ZMIHZhbHVlDQogZm9yIHBhY2tldHMgb24gYSBnaXZlbiBmbG93 IGRpZmZlcnMsIGJ1dCB0aGUgRUwgaXMgdGhlIHNhbWUsIHRoZW4gdGhlIExTUiB3b3VsZCBzdGls bCBzcHJheSB0aGUgcGFja2V0cyBiZWNhdXNlIHRoZSBsYWJlbCBzdGFjayB3b3VsZCBiZSBkaWZm ZXJlbnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgZG9u 4oCZdCB0aGluayB0aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8gbWFuZGF0ZSB0aGF0IExTUnMgb25s eSBjb25zaWRlciB0aGUgRUwgYW5kIGlnbm9yZSBhbGwgb3RoZXIgbGFiZWxzIGluIHRoZSBzdGFj ayBnaXZlbiB0aGUgaW1wYWN0IG9uIHRoZSBkZXBsb3llZCBiYXNlIGZvciBqdXN0IGEgZmV3IGVu ZC10by1lbmQgYXBwbGljYXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+SSBkb27igJl0IHRoaW5rIHRoaXMgZHJhZnQgc2hvdWxkIGJlIGJvdGggZGVmaW5p bmcgU0ZMcyBhbmQgdHJ5aW5nIHRvIHNvbHZlIHRoZSBnZW5lcmFsIEVDTVAgcHJvYmxlbSBmb3Ig YXBwbGljYXRpb25zIG9mIFNGTHMuIEluc3RlYWQsIGl0IHNob3VsZCBmb2N1cyBvbiB0aGUgU0ZM IGl0c2VsZi4gTXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBjaGFuZ2Ugc2VjdGlvbg0KIDQgdG8g c2F5IHRoYXQgRUNNUCBjb25zaWRlcmF0aW9ucyBzaG91bGQgYWRkcmVzc2VkIGJ5IGFuIGFwcGxp Y2F0aW9uIG9mIFNGTCBpZiBFQ01QIGlzIGEgY29uY2VybiBmb3IgdGhhdCBhcHBsaWNhdGlvbi4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+TWF0dGhldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_74FA86D7E0FB4E5DA5D364324CB2A656nokiacom_-- From nobody Wed May 10 12:25:26 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37E412EA74; Wed, 10 May 2017 12:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 E2Z4OsZlgIrf; Wed, 10 May 2017 12:25:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF1512EA6A; Wed, 10 May 2017 12:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23734; q=dns/txt; s=iport; t=1494444305; x=1495653905; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3D8DG/LRuhURy/OPI+AudnyFtFyljp+M1x7zxnWErYI=; b=FQXwhcAII5q1wD1SGe51vDoBEeiUogbmvoWCKehc4oB8qMfgm9+JDkuW 7z9zno/Gazp5ZVVD54i6l+TwmG54Ion+1g9soP9R1SyTd1bldKlHi/LDS sBN232QN9LNi8/6quNGDNT3sIUrfhvDXkA1p4C1+PN1Uf7nfRNlqYuaZD 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BUAQC4aBNZ/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMB4NiihiRNyGII4gXhTiCDyEBCoV4AhqEZj8YAQIBAQE?= =?us-ascii?q?BAQEBayiFFQEBAQEDAQEhSwkCEAIBCBEBAgECKAMCAgIfBgsUAwYIAgQOBRuJb?= =?us-ascii?q?gMVDrJVgiaHMA2DOAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GX4FeKwuCZYJUTYE?= =?us-ascii?q?lAQE7FgiCUC+CMQWJRIZehk2GYDsBhxuHLIRTggRVhGaKLIsthHcog3YBDxA4g?= =?us-ascii?q?QpwFRwqEgGEKjkcgWN2AYZqgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,320,1491264000"; d="scan'208,217";a="243726006" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 May 2017 19:24:53 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v4AJOrxW014129 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 May 2017 19:24:53 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 10 May 2017 15:24:52 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 10 May 2017 15:24:52 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: "spring@ietf.org" , "rtg-bfd@ietf.org" , "mpls@ietf.org" Thread-Topic: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt Thread-Index: AQHSyNwl4f82jzKO5Eq8Ccd1kzJOwKHsbA8AgAAB9QCAADyAAIABjQKA Date: Wed, 10 May 2017 19:24:52 +0000 Message-ID: <9D886964-6C21-427C-8733-7731D5A996D3@cisco.com> References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.52] Content-Type: multipart/alternative; boundary="_000_9D8869646C21427C87337731D5A996D3ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 19:25:09 -0000 --_000_9D8869646C21427C87337731D5A996D3ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywNCg0KSW4gdGhlIE1QTFMgZGF0YSBwbGFuZSwgRkVDcyBhcmUgYWxzbyBpbnN0YW50aWF0 ZWQgdGhyb3VnaCBhIGxhYmVsIHN0YWNrLiBCdXQgUkZDIDcxMTAgZG9lcyBub3QgdXNlIG51bWVy aWMgbGFiZWwgdmFsdWVzLCBpdCB1c2VzIFRGU3MuIFRoYXQgZG9lcyBub3QgY3JlYXRlIGFueSBh ZGRpdGlvbmFsIHN0YXRlLiBFLmcuLDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9tcGxzL2N1cnJlbnQvbXNnMTYwOTEuaHRtbA0KDQpUaGFua3MsDQoNCuKAlCBDYXJsb3Mu DQoNCg0KDQpPbiBNYXkgOSwgMjAxNywgYXQgMzo0MyBQTSwgR3JlZyBNaXJza3kgPGdyZWdpbWly c2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhp IENhcmxvcywNCkkgcHJvYmFibHkgd291bGQgY2hhcmFjdGVyaXplIGFueXRoaW5nIHRoYXQgc3Rh cnRzIHdpdGggV2h5IG5vdCBhcyBhIHRlY2huaWNhbCBjb21tZW50IGJ1dCByYXRoZXIgYXMgYSBx dWVzdGlvbi4NCkFjY29yZGluZyB0byBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmct bXBscywgIkluIHRoZSBNUExTIGRhdGFwbGFuZSx0aGUgU1IgaGVhZGVyIGlzIGluc3RhbnRpYXRl ZCB0aHJvdWdoIGEgbGFiZWwgc3RhY2siLg0KQXQgdGhlIHNhbWUgdGltZSwgb25lIG9mIGFkdmFu dGFnZXMgb2YgU1IgaXMgdGhhdCAicGVyLWZsb3cgc3RhdGUgb25seSBbbWFpbnRhaW5lZF0gYXQg dGhlIGluZ3Jlc3Mgbm9kZSB0byB0aGUgU1IgZG9tYWluIi4NClRodXMsIGZvciB0aGUgY2FzZSBv ZiBtb25pdG9yaW5nIHVuaWRpcmVjdGlvbmFsIFNSIHR1bm5lbHMsIEkgY29uc2lkZXIgdGhhdCB0 aGVyZSdzIG5vIG5lZWQgdG8gY3JlYXRlIGFueSBhZGRpdGlvbmFsIHN0YXRlIG9uIHRoZSBlZ3Jl c3Mgbm9kZS4NCk9mIGNvdXJzZSwgaWYgdGhlcmUgd2VyZSBiaWRpcmVjdGlvbmFsIFNSIHR1bm5l bHMsIHRoZW4gY29udHJvbCBvZiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24gb2YgdGhlIEJGRCBzZXNz aW9uIHdvdWxkIG5vdCByZXF1aXJlIHVzZSBvZiB0aGUgUmV0dXJuIFBhdGggc3ViLVRMVi4NCkFz IGZvciBMU1AtUGluZywgSSBqdXN0IHByb3Bvc2UgdGhhdCB0aGUgU2VnbWVudCBSb3V0aW5nIE1Q TFMgVHVubmVsIHN1Yi1UTFYgTUFZIGJlIHVzZWQgUmVwbHkgUGF0aCBUTFYgZGVmaW5lZCBpbiBS RkMgNzExMC4gSSB2aWV3ZWQgdGhlIHByb3Bvc2FsIGFzIGludml0YXRpb24gdG8gdGVjaG5pY2Fs IGRpc2N1c3Npb24uDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFR1ZSwgTWF5IDksIDIwMTcgYXQg OTowNyBBTSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIDxjcGlnbmF0YUBjaXNjby5jb208 bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+IHdyb3RlOg0KVGhhbmsgeW91IEdyZWchDQoNClNp bmNlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC0w MCBzZWVtcyBxdWl0ZSBzaW1pbGFyIHRvIHRoZSB0ZXh0IHJlbW92ZWQgYXQgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3RlZC0wNS50 eHQsIHRoZW4gdGhlIGNvbXBsZXRlIHNldCBvZiBvdXRzdGFuZGluZyB0ZWNobmljYWwgY29tbWVu dHMgdGhhdCB0cmlnZ2VyZWQgdGhlIHJlbW92YWwgb2YgdGhhdCB0ZXh0IGZyb20gZHJhZnQtaWV0 Zi1tcGxzLWJmZC1kaXJlY3RlZC0wNS50eHQgbWlnaHQgcGVlayB5b3VyIGludGVyZXN0IDotKQ0K DQpPbmUgdGhhdCBJIHJlY2FsbCBpczogd2h5IHVzZSBsYWJlbCB2YWx1ZXMgd2hlbiBldmVyeSBv dGhlciByZXR1cm4tcGF0aCBzdWItVExWIGZvciBCRkQgYW5kIGZvciBMU1AtUGluZywgaW5jbHVk aW5nIGRyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZWQsIHVzZXMgVEZTcz8NCg0KQmVzdCwNCg0K 4oCUIENhcmxvcy4NCg0KT24gTWF5IDksIDIwMTcsIGF0IDEyOjAwIFBNLCBHcmVnIE1pcnNreSA8 Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90 ZToNCg0KRGVhciBDYXJsb3MsDQpJJ3ZlIGRlY2lkZWQgdG8gcmUtc3RhcnQgdGhlIGRpc2N1c3Np b24gYW5kIGFtIGludGVyZXN0ZWQgdG8gaGVhciB0ZWNobmljYWwgY29tbWVudHMgdG8gdGhlIHBy b3Bvc2VkIHNvbHV0aW9uLg0KDQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBUdWUsIE1heSA5LCAyMDE3 IGF0IDg6NTEgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lzY28u Y29tPG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+PiB3cm90ZToNCkRlYXIgR3JlZywNCg0KQ3Vy c29yaWx5IHNjYW5uaW5nIHRocm91Z2ggdGhpcywgaXQgc2VlbXMgdGhhdCBtb3N0IGNvbmNlcm5z IHJhaXNlZCBhbmQgY29tbWVudHMgbWFkZSBhYm91dCB0aGUgU1Igc2VjdGlvbnMgb2YgZHJhZnQt aWV0Zi1tcGxzLWJmZC1kaXJlY3RlZC0wTiAod2l0aCBOIDwgNSkgYXBwbHkgdG8geW91ciBuZXcg ZHJhZnQuDQoNClRoaXMgaXMgb25lIG9mIHRob3NlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cxNTg2MC5odG1sIOKAlCB0aGUgbGlzdCBhcmNo aXZlIHNob3dzIGEgZmV3IG1vcmUuIFRoZSBjb3B5L3Bhc3RlIGRpZCBub3QgYWRkcmVzcyB0aGUg Y29tbWVudHMuDQoNCkJlc3QsDQoNCuKAlCBDYXJsb3MuDQoNCk9uIE1heSA4LCAyMDE3LCBhdCAx MTozMyBQTSwgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2lt aXJza3lAZ21haWwuY29tPj4gd3JvdGU6DQoNCkRlYXIgQWxsLA0KcGVyaGFwcyB0aGlzIG5ldyBk cmFmdCBtYXkgaXMgb2YgaW50ZXJlc3QgdG8geW91Lg0KWW91ciBjb21tZW50cywgc3VnZ2VzdGlv bnMgYXJlIG1vc3Qgd2VsY29tZSBhbmQgZ3JlYXRseSBhcHByZWNpYXRlZC4NCg0KUmVnYXJkcywN CkdyZWcNCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiA8 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+ Pg0KRGF0ZTogTW9uLCBNYXkgOCwgMjAxNyBhdCA4OjI5IFBNDQpTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwLnR4dA0KVG86IEdy ZWdvcnkgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdt YWlsLmNvbT4+DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWlyc2t5LXNwcmlu Zy1iZmQtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEdyZWcgTWly c2t5IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAg ICBkcmFmdC1taXJza3ktc3ByaW5nLWJmZA0KUmV2aXNpb246ICAgICAgIDAwDQpUaXRsZTogICAg ICAgICAgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBpbiBTZWdtZW50 IFJvdXRpbmcgTmV0d29ya3MgVXNpbmcgTVBMUyBEYXRhcGxhbmUNCkRvY3VtZW50IGRhdGU6ICAy MDE3LTA1LTA4DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczog ICAgICAgICAgNw0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMC50eHQNClN0YXR1czogICAgICAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC8N Ckh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWlyc2t5 LXNwcmluZy1iZmQtMDANCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwDQoNCg0KQWJzdHJhY3Q6DQog ICBTZWdtZW50IFJvdXRpbmcgYXJjaGl0ZWN0dXJlIGxldmVyYWdlcyB0aGUgcGFyYWRpZ20gb2Yg c291cmNlDQogICByb3V0aW5nLiAgSXQgY2FuIGJlIHJlYWxpemVkIGluIHRoZSBNdWx0aXByb3Rv Y29sIExhYmVsIFN3aXRjaGluZw0KICAgKE1QTFMpIG5ldHdvcmsgd2l0aG91dCBhbnkgY2hhbmdl IHRvIHRoZSBkYXRhIHBsYW5lLiAgQSBzZWdtZW50IGlzDQogICBlbmNvZGVkIGFzIGFuIE1QTFMg bGFiZWwgYW5kIGFuIG9yZGVyZWQgbGlzdCBvZiBzZWdtZW50cyBpcyBlbmNvZGVkDQogICBhcyBh IHN0YWNrIG9mIGxhYmVscy4gIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJG RCkgaXMNCiAgIGV4cGVjdGVkIHRvIG1vbml0b3IgYW55IGtpbmQgb2YgcGF0aHMgYmV0d2VlbiBz eXN0ZW1zLiAgVGhpcyBkb2N1bWVudA0KICAgZGVmaW5lcyBob3cgdG8gdXNlIExhYmVsIFN3aXRj aGVkIFBhdGggUGluZyB0byBib290c3RyYXAgYW5kIGNvbnRyb2wNCiAgIHBhdGggaW4gcmV2ZXJz ZSBkaXJlY3Rpb24gb2YgYSBCRkQgc2Vzc2lvbiBvbiB0aGUgU2VnbWVudCBSb3V0aW5nDQogICBu ZXR3b3JrIG92ZXIgTVBMUyBkYXRhcGxhbmUuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24N CnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnLz4uDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0KDQoNCg0K --_000_9D8869646C21427C87337731D5A996D3ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <92AE4598DFBA884C87A8535A0FE5500B@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KR3JlZywNCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkluIHRoZSBNUExTIGRhdGEgcGxh bmUsIEZFQ3MgYXJlIGFsc28gaW5zdGFudGlhdGVkIHRocm91Z2ggYSBsYWJlbCBzdGFjay4gQnV0 IFJGQyA3MTEwIGRvZXMgbm90IHVzZSBudW1lcmljIGxhYmVsIHZhbHVlcywgaXQgdXNlcyBURlNz LiBUaGF0IGRvZXMgbm90IGNyZWF0ZSBhbnkgYWRkaXRpb25hbCBzdGF0ZS4gRS5nLiw6Jm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJl bnQvbXNnMTYwOTEuaHRtbCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9tcGxzL2N1cnJlbnQvbXNnMTYwOTEuaHRtbDwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyw8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlCBDYXJs b3MuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5P biBNYXkgOSwgMjAxNywgYXQgMzo0MyBQTSwgR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0 bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5IaSBDYXJsb3MsDQo8 ZGl2IGNsYXNzPSIiPkkgcHJvYmFibHkgd291bGQgY2hhcmFjdGVyaXplIGFueXRoaW5nIHRoYXQg c3RhcnRzIHdpdGggV2h5IG5vdCBhcyBhIHRlY2huaWNhbCBjb21tZW50IGJ1dCByYXRoZXIgYXMg YSBxdWVzdGlvbi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QWNjb3JkaW5nIHRvJm5ic3A7PGZvbnQg ZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9 ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1MywgMjQ1KTsiIGNsYXNzPSIiPmQ8L3NwYW4+ PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1MywgMjQ1KTsiIGNsYXNz PSIiPnJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMsICZxdW90Ozwvc3Bhbj48 c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyIgY2xhc3M9 IiI+SW4NCiB0aGUgTVBMUyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogcmdiKDI1NSwgMjUzLCAyNDUpOyIgY2xhc3M9IiI+ZGF0YXBsYW5lLDwvc3Bhbj48c3BhbiBz dHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyIgY2xhc3M9IiI+dGhl IFNSIGhlYWRlciBpcyBpbnN0YW50aWF0ZWQgdGhyb3VnaCBhIGxhYmVsIHN0YWNrJnF1b3Q7Ljwv c3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9ImFyaWFsLCBoZWx2 ZXRpY2EsIHNhbnMtc2VyaWYiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9y OiByZ2IoMjU1LCAyNTMsIDI0NSk7IiBjbGFzcz0iIj5BdCB0aGUgc2FtZSB0aW1lLCBvbmUgb2Yg YWR2YW50YWdlcyBvZiBTUiBpcyB0aGF0ICZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iYmFja2dy b3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyBmb250LXNpemU6IDE0cHg7IiBjbGFzcz0i Ij5wZXItZmxvdw0KIHN0YXRlIG9ubHkgW21haW50YWluZWRdIGF0IHRoZSBpbmdyZXNzIG5vZGUg dG8gdGhlIFNSJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2Io MjU1LCAyNTMsIDI0NSk7IGZvbnQtc2l6ZTogMTRweDsiIGNsYXNzPSIiPmRvbWFpbiZxdW90Oy48 L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJhcmlhbCwgaGVs dmV0aWNhLCBzYW5zLXNlcmlmIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogcmdiKDI1NSwgMjUzLCAyNDUpOyBmb250LXNpemU6IDE0cHg7IiBjbGFzcz0iIj5UaHVzLCBm b3IgdGhlIGNhc2Ugb2YgbW9uaXRvcmluZyB1bmlkaXJlY3Rpb25hbCBTUiB0dW5uZWxzLCBJIGNv bnNpZGVyIHRoYXQgdGhlcmUncyBubyBuZWVkIHRvIGNyZWF0ZSBhbnkgYWRkaXRpb25hbA0KIHN0 YXRlIG9uIHRoZSBlZ3Jlc3Mgbm9kZS48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyBmb250LXNpemU6 IDE0cHg7IiBjbGFzcz0iIj5PZiBjb3Vyc2UsIGlmIHRoZXJlIHdlcmUgYmlkaXJlY3Rpb25hbCBT UiB0dW5uZWxzLCB0aGVuIGNvbnRyb2wgb2YgdGhlIHJldmVyc2UgZGlyZWN0aW9uIG9mIHRoZSBC RkQgc2Vzc2lvbiB3b3VsZA0KIG5vdCByZXF1aXJlIHVzZSBvZiB0aGUgUmV0dXJuIFBhdGggc3Vi LVRMVi48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJhcmlh bCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyBmb250LXNpemU6IDE0cHg7IiBjbGFzcz0iIj5B cyBmb3IgTFNQLVBpbmcsIEkganVzdCBwcm9wb3NlIHRoYXQgdGhlIFNlZ21lbnQgUm91dGluZyBN UExTIFR1bm5lbCBzdWItVExWIE1BWSBiZSB1c2VkIFJlcGx5IFBhdGggVExWIGRlZmluZWQgaW4N CiBSRkMgNzExMC4gSSB2aWV3ZWQgdGhlIHByb3Bvc2FsIGFzIGludml0YXRpb24gdG8gdGVjaG5p Y2FsIGRpc2N1c3Npb24uPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg ZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9 ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1MywgMjQ1KTsgZm9udC1zaXplOiAxNHB4OyIg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiIgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1MywgMjQ1KTsgZm9udC1zaXpl OiAxNHB4OyIgY2xhc3M9IiI+UmVnYXJkcyw8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBjbGFzcz0iIj48 c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyBmb250LXNp emU6IDE0cHg7IiBjbGFzcz0iIj5HcmVnPC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj5PbiBUdWUsIE1heSA5LCAyMDE3IGF0IDk6MDcgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNw aWduYXRhKQ0KPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPiZsdDs8YSBocmVmPSJtYWlsdG86Y3Bp Z25hdGFAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+Y3BpZ25hdGFAY2lzY28u Y29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNz PSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAj Y2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFr LXdvcmQiIGNsYXNzPSIiPlRoYW5rIHlvdSBHcmVnIQ0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U2luY2UgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvPHdiciBjbGFzcz0iIj5kcmFm dC1taXJza3ktc3ByaW5nLWJmZC0wMDwvYT4gc2VlbXMgcXVpdGUgc2ltaWxhciB0byB0aGUgdGV4 dCByZW1vdmVkIGF0DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLW1wbHMtYmZkLWRpcmVjdGVkLTA1LnR4dCIgdGFyZ2V0PSJfYmxhbmsiIGNs YXNzPSIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy88d2JyIGNsYXNzPSIiPnJmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLW1wbHMtPHdiciBjbGFzcz0iIj5iZmQtZGlyZWN0ZWQtMDUudHh0PC9hPiwg dGhlbiB0aGUgY29tcGxldGUgc2V0IG9mIG91dHN0YW5kaW5nIHRlY2huaWNhbCBjb21tZW50cyB0 aGF0IHRyaWdnZXJlZCB0aGUgcmVtb3ZhbCBvZiB0aGF0IHRleHQgZnJvbSBkcmFmdC1pZXRmLW1w bHMtYmZkLWRpcmVjdGVkLTx3YnIgY2xhc3M9IiI+MDUudHh0IG1pZ2h0DQogcGVlayB5b3VyIGlu dGVyZXN0IDotKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+T25lIHRoYXQgSSByZWNhbGwgaXM6IHdoeSB1c2UgbGFiZWwgdmFsdWVzIHdo ZW4gZXZlcnkgb3RoZXIgcmV0dXJuLXBhdGggc3ViLVRMViBmb3IgQkZEIGFuZCBmb3IgTFNQLVBp bmcsIGluY2x1ZGluZyBkcmFmdC1pZXRmLW1wbHMtYmZkLWRpcmVjdGVkLCB1c2VzIFRGU3M/Jm5i c3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5CZXN0LDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+4oCUIENhcmxvcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSJoNSI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gTWF5IDksIDIw MTcsIGF0IDEyOjAwIFBNLCBHcmVnIE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWly c2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJtXy00MjgwMjc0MTcwMDM4OTk4 OTAyQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9 Imx0ciIgY2xhc3M9IiI+RGVhciBDYXJsb3MsDQo8ZGl2IGNsYXNzPSIiPkkndmUgZGVjaWRlZCB0 byByZS1zdGFydCB0aGUgZGlzY3Vzc2lvbiBhbmQgYW0gaW50ZXJlc3RlZCB0byBoZWFyIHRlY2hu aWNhbCBjb21tZW50cyB0byB0aGUgcHJvcG9zZWQgc29sdXRpb24uJm5ic3A7PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5SZWdhcmRzLDwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5HcmVnPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWls X2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlLCBN YXkgOSwgMjAxNyBhdCA4OjUxIEFNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNCjxzcGFu IGRpcj0ibHRyIiBjbGFzcz0iIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmNwaWduYXRhQGNpc2NvLmNv bSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmNwaWduYXRhQGNpc2NvLmNvbTwvYT4mZ3Q7PC9z cGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRk aW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIiBjbGFzcz0i Ij5EZWFyIEdyZWcsDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5DdXJzb3JpbHkgc2Nhbm5pbmcgdGhyb3VnaCB0aGlzLCBpdCBzZWVtcyB0aGF0IG1v c3QgY29uY2VybnMgcmFpc2VkIGFuZCBjb21tZW50cyBtYWRlIGFib3V0IHRoZSBTUiBzZWN0aW9u cyBvZiZuYnNwO2RyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZTx3YnIgY2xhc3M9IiI+ZC0wTiAo d2l0aCBOICZsdDsgNSkgYXBwbHkgdG8geW91ciBuZXcgZHJhZnQuPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGlzIGlzIG9uZSBvZiB0 aG9zZTombmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L21wbHMvY3VycmVudC9tc2cxNTg2MC5odG1sIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWE8d2JyIGNsYXNzPSIiPmlsLWFyY2hpdmUvd2ViL21wbHMvY3Vy cmVudC9tczx3YnIgY2xhc3M9IiI+ZzE1ODYwLmh0bWw8L2E+IOKAlCB0aGUgbGlzdCBhcmNoaXZl IHNob3dzDQogYSBmZXcgbW9yZS4gVGhlIGNvcHkvcGFzdGUgZGlkIG5vdCBhZGRyZXNzIHRoZSBj b21tZW50cy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkJlc3QsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj7igJQgQ2FybG9zLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0ibV8tNDI4MDI3NDE3MDAzODk5ODkwMmg1Ij4N CjxkaXYgY2xhc3M9IiI+T24gTWF5IDgsIDIwMTcsIGF0IDExOjMzIFBNLCBHcmVnIE1pcnNreSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJy IGNsYXNzPSJtXy00MjgwMjc0MTcwMDM4OTk4OTAybV80MTg3ODE3MTU1MzM0NjA3ODE3QXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJtXy00MjgwMjc0MTcwMDM4OTk4OTAyaDUiPg0KPGRp diBkaXI9Imx0ciIgY2xhc3M9IiI+RGVhciBBbGwsDQo8ZGl2IGNsYXNzPSIiPnBlcmhhcHMgdGhp cyBuZXcgZHJhZnQgbWF5IGlzIG9mIGludGVyZXN0IHRvIHlvdS48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+WW91ciBjb21tZW50cywgc3VnZ2VzdGlvbnMgYXJlIG1vc3Qgd2VsY29tZSBhbmQgZ3JlYXRs eSBhcHByZWNpYXRlZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPlJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkdyZWc8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPi0t LS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCkZyb206 IDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj48L2I+PHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIi PiZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8L3NwYW4+PGJy IGNsYXNzPSIiPg0KRGF0ZTogTW9uLCBNYXkgOCwgMjAxNyBhdCA4OjI5IFBNPGJyIGNsYXNzPSIi Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1taXJza3ktc3By aW5nLWJmZC0wMC50eHQ8YnIgY2xhc3M9IiI+DQpUbzogR3JlZ29yeSBNaXJza3kgJmx0OzxhIGhy ZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMC50eHQ8YnIgY2xhc3M9IiI+DQpoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhlPGJyIGNs YXNzPSIiPg0KSUVURiByZXBvc2l0b3J5LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5h bWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1taXJza3kt c3ByaW5nLWJmZDxiciBjbGFzcz0iIj4NClJldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzAwPGJyIGNsYXNzPSIiPg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIGluIFNlZ21lbnQg Um91dGluZyBOZXR3b3JrcyBVc2luZyBNUExTIERhdGFwbGFuZTxiciBjbGFzcz0iIj4NCkRvY3Vt ZW50IGRhdGU6Jm5ic3A7IDIwMTctMDUtMDg8YnIgY2xhc3M9IiI+DQpHcm91cDombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxiciBjbGFzcz0i Ij4NClBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgNzxiciBjbGFzcz0i Ij4NClVSTDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWlyc2t5LXNwcmlu Zy1iZmQtMDAudHh0IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LTx3YnIgY2xhc3M9IiI+ZHJhZnRzL2RyYWZ0 LW1pcnNreS1zcHJpbmctYmZkPHdiciBjbGFzcz0iIj4tMDAudHh0PC9hPjxiciBjbGFzcz0iIj4N ClN0YXR1czombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQvIiByZWw9 Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnLzx3YnIgY2xhc3M9IiI+ZG9jL2RyYWZ0LW1pcnNreS1zcHJpbmctYmZkLzwvYT48 YnIgY2xhc3M9IiI+DQpIdG1saXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAi IHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kPHdiciBjbGFzcz0iIj5yYWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwPC9h PjxiciBjbGFzcz0iIj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbWlyc2t5LXNw cmluZy1iZmQtMDAiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvPHdiciBjbGFzcz0iIj5kb2MvaHRtbC9kcmFmdC1t aXJza3ktc3ByaW5nLWI8d2JyIGNsYXNzPSIiPmZkLTAwPC9hPjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFic3RyYWN0OjxiciBjbGFzcz0iIj4NCiZuYnNwOyAm bmJzcDtTZWdtZW50IFJvdXRpbmcgYXJjaGl0ZWN0dXJlIGxldmVyYWdlcyB0aGUgcGFyYWRpZ20g b2Ygc291cmNlPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3JvdXRpbmcuJm5ic3A7IEl0IGNh biBiZSByZWFsaXplZCBpbiB0aGUgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmc8YnIgY2xh c3M9IiI+DQombmJzcDsgJm5ic3A7KE1QTFMpIG5ldHdvcmsgd2l0aG91dCBhbnkgY2hhbmdlIHRv IHRoZSBkYXRhIHBsYW5lLiZuYnNwOyBBIHNlZ21lbnQgaXM8YnIgY2xhc3M9IiI+DQombmJzcDsg Jm5ic3A7ZW5jb2RlZCBhcyBhbiBNUExTIGxhYmVsIGFuZCBhbiBvcmRlcmVkIGxpc3Qgb2Ygc2Vn bWVudHMgaXMgZW5jb2RlZDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDthcyBhIHN0YWNrIG9m IGxhYmVscy4mbmJzcDsgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBp czxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtleHBlY3RlZCB0byBtb25pdG9yIGFueSBraW5k IG9mIHBhdGhzIGJldHdlZW4gc3lzdGVtcy4mbmJzcDsgVGhpcyBkb2N1bWVudDxiciBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDtkZWZpbmVzIGhvdyB0byB1c2UgTGFiZWwgU3dpdGNoZWQgUGF0aCBQ aW5nIHRvIGJvb3RzdHJhcCBhbmQgY29udHJvbDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtw YXRoIGluIHJldmVyc2UgZGlyZWN0aW9uIG9mIGEgQkZEIHNlc3Npb24gb24gdGhlIFNlZ21lbnQg Um91dGluZzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtuZXR3b3JrIG92ZXIgTVBMUyBkYXRh cGxhbmUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxiciBjbGFzcz0iIj4N CnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnLyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdiciBjbGFzcz0iIj5fX19fX19fX19fX19f X19fXzxiciBjbGFzcz0iIj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJl Zj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5tcGxzQGll dGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbDx3YnIgY2xhc3M9IiI+aXN0aW5mby9tcGxzPC9hPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9D8869646C21427C87337731D5A996D3ciscocom_-- From nobody Wed May 10 12:40:22 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C03212EAA9; Wed, 10 May 2017 12:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXqbqfTtI3zp; Wed, 10 May 2017 12:40:01 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75846128AB0; Wed, 10 May 2017 12:40:01 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id p24so8470949ioi.0; Wed, 10 May 2017 12:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qKK7klzpm+jnKD+cec9LqksoIPnUCyWGgItAqrfhbsk=; b=ZRhjgC/gZjqYCe9XeHX2R4WlFbWOV0tH72jP8Vl2siuki5IJEUFEXFBgXsa8GjdSQz Rgpt6w+NbL3T5+CAEHbdEhWD6Afpij2fUKPY1ucU0qhmiGivE/byCQNTzGJGE6QzVGyb 3CUMg04ViAzw1bGoOp5a/WwgntZlXPhVUwwI0A67q/tbyJdsUEjw6Wl/M2g72sfzonto GVfE7/8KRPn8Wvv3sbTyCBbF6uPpE2h2KtYRaR1o8jfZJomnJq2YBnn264fKd6lqzoz4 oPg3uR0KUoHGYi7SrJMGZX9qTBNvFTOMHRO+8OT9IU9iZ9X5LXvSqo78JaX1FuLsU8ai y1gQ== 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=qKK7klzpm+jnKD+cec9LqksoIPnUCyWGgItAqrfhbsk=; b=r2javusmoOBpkIoS8Y2tFKemotHipk4hseNjC0YKqO9a4oP6+xUPDFfjPdzcRmh0w8 j491VJ+HDfbCALJPxzAsbOdmWm2hLIcXOvl/Cxc3CXlHEbRS+3agg3M1fVr0bCYTQJDS 1bV2Hh77Q2SJThvflm1DfRq4+0avOhoXCmmox4IlzAXbhDzNEZQZG+pTs8yv6IK2mwYa JK+sr63PuPlVkNkiLjgc7gFKxcicOZFL14X5kHMK6fokdCU0b+qaCkz9BuH72K/cNwuo z/JdmN2Utoua8VKWJvzb1yy5JXsI56gQU9mPHX2UBNb/szHQ2JN1YTTGE5QuXGUvaMoE Gmjw== X-Gm-Message-State: AODbwcCJCJ/OM/ashqL16ZThZGtbgsuPqpkVyEsUmBjXLzOiZcAtj4Yl WHFmiN6ymCtMxpus9i5mOCB6OuzDyQ== X-Received: by 10.107.205.132 with SMTP id d126mr5071044iog.155.1494445200753; Wed, 10 May 2017 12:40:00 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Wed, 10 May 2017 12:40:00 -0700 (PDT) In-Reply-To: <9D886964-6C21-427C-8733-7731D5A996D3@cisco.com> References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> <9D886964-6C21-427C-8733-7731D5A996D3@cisco.com> From: Robert Raszuk Date: Wed, 10 May 2017 21:40:00 +0200 X-Google-Sender-Auth: x_PauMqsKG4nRRs352gzM0YQgdI Message-ID: To: "Carlos Pignataro (cpignata)" Cc: Greg Mirsky , "mpls@ietf.org" , "spring@ietf.org" , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c18871853f0c7054f30a3b7 Archived-At: Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 19:40:04 -0000 --94eb2c18871853f0c7054f30a3b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, Sorry what is "TFS" ? RFC 7110 does not even use such abbreviation neither do draft-ietf-mpls-bfd-directed :) Google also seems to be pretty clueless about it. Just curious as you keep using this term in each email :) Thx, R. On Wed, May 10, 2017 at 9:24 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Greg, > > In the MPLS data plane, FECs are also instantiated through a label stack. > But RFC 7110 does not use numeric label values, it uses TFSs. That does n= ot > create any additional state. E.g.,: https://www.ietf.org/ > mail-archive/web/mpls/current/msg16091.html > > Thanks, > > =E2=80=94 Carlos. > > > > On May 9, 2017, at 3:43 PM, Greg Mirsky wrote: > > Hi Carlos, > I probably would characterize anything that starts with Why not as a > technical comment but rather as a question. > According to draft-ietf-spring-segment-routing-mpls, "In the MPLS > dataplane,the SR header is instantiated through a label stack". > At the same time, one of advantages of SR is that "per-flow state only > [maintained] at the ingress node to the SR domain". > Thus, for the case of monitoring unidirectional SR tunnels, I consider > that there's no need to create any additional state on the egress node. > Of course, if there were bidirectional SR tunnels, then control of the > reverse direction of the BFD session would not require use of the Return > Path sub-TLV. > As for LSP-Ping, I just propose that the Segment Routing MPLS Tunnel > sub-TLV MAY be used Reply Path TLV defined in RFC 7110. I viewed the > proposal as invitation to technical discussion. > > Regards, > Greg > > On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Thank you Greg! >> >> Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems quite >> similar to the text removed at https://tools.ietf.org/rfcdiff >> ?url2=3Ddraft-ietf-mpls-bfd-directed-05.txt, then the complete set of >> outstanding technical comments that triggered the removal of that text f= rom >> draft-ietf-mpls-bfd-directed-05.txt might peek your interest :-) >> >> One that I recall is: why use label values when every other return-path >> sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directed= , >> uses TFSs? >> >> Best, >> >> =E2=80=94 Carlos. >> >> On May 9, 2017, at 12:00 PM, Greg Mirsky wrote: >> >> Dear Carlos, >> I've decided to re-start the discussion and am interested to hear >> technical comments to the proposed solution. >> >> Regards, >> Greg >> >> On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro (cpignata) < >> cpignata@cisco.com> wrote: >> >>> Dear Greg, >>> >>> Cursorily scanning through this, it seems that most concerns raised and >>> comments made about the SR sections of draft-ietf-mpls-bfd-directed-0N >>> (with N < 5) apply to your new draft. >>> >>> This is one of those: https://www.ietf.org/ma >>> il-archive/web/mpls/current/msg15860.html =E2=80=94 the list archive sh= ows a >>> few more. The copy/paste did not address the comments. >>> >>> Best, >>> >>> =E2=80=94 Carlos. >>> >>> On May 8, 2017, at 11:33 PM, Greg Mirsky wrote: >>> >>> Dear All, >>> perhaps this new draft may is of interest to you. >>> Your comments, suggestions are most welcome and greatly appreciated. >>> >>> Regards, >>> Greg >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: Mon, May 8, 2017 at 8:29 PM >>> Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt >>> To: Gregory Mirsky >>> >>> >>> >>> A new version of I-D, draft-mirsky-spring-bfd-00.txt >>> has been successfully submitted by Greg Mirsky and posted to the >>> IETF repository. >>> >>> Name: draft-mirsky-spring-bfd >>> Revision: 00 >>> Title: Bidirectional Forwarding Detection (BFD) in Segment >>> Routing Networks Using MPLS Dataplane >>> Document date: 2017-05-08 >>> Group: Individual Submission >>> Pages: 7 >>> URL: https://www.ietf.org/internet- >>> drafts/draft-mirsky-spring-bfd-00.txt >>> Status: https://datatracker.ietf.org/ >>> doc/draft-mirsky-spring-bfd/ >>> Htmlized: https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 >>> Htmlized: https://datatracker.ietf.org/ >>> doc/html/draft-mirsky-spring-bfd-00 >>> >>> >>> Abstract: >>> Segment Routing architecture leverages the paradigm of source >>> routing. It can be realized in the Multiprotocol Label Switching >>> (MPLS) network without any change to the data plane. A segment is >>> encoded as an MPLS label and an ordered list of segments is encoded >>> as a stack of labels. Bidirectional Forwarding Detection (BFD) is >>> expected to monitor any kind of paths between systems. This documen= t >>> defines how to use Label Switched Path Ping to bootstrap and control >>> path in reverse direction of a BFD session on the Segment Routing >>> network over MPLS dataplane. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> >>> >> >> > > --94eb2c18871853f0c7054f30a3b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos,

=
Sorry what is "TFS" ?=C2=A0

RFC 7110 does not even use such ab= breviation neither do=C2=A0draft-ietf-mpls-bfd-directed=C2=A0:) Google also seems to= be pretty clueless about it.=C2=A0

Just curious as you keep using this term in each email :)=C2= =A0

Thx,
R.

On Wed, May 1= 0, 2017 at 9:24 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com&g= t; wrote:
Greg,

In the MPLS data plane, FECs are also instantiated through a label sta= ck. But RFC 7110 does not use numeric label values, it uses TFSs. That does= not create any additional state. E.g.,:=C2=A0https://w= ww.ietf.org/mail-archive/web/mpls/current/msg16091.html

Thanks,

=E2=80=94 Carlos.



On May 9, 2017, at 3:43 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Carlos,
I probably would characterize anything that starts with Why not as a t= echnical comment but rather as a question.
According to=C2=A0draft-ietf-spring-segment-routing-mpls, "= In the MPLS=C2=A0dat= aplane,the SR head= er is instantiated through a label stack".
At the same time, one of advantages of SR is that &= quot;per-flow state only [maintained] at the ingress node to the SR=C2=A0domain".
Thus, for the case of monitoring uni= directional SR tunnels, I consider that there's no need to create any a= dditional state on the egress node.
Of course, if there were bidirection= al SR tunnels, then control of the reverse direction of the BFD session wou= ld not require use of the Return Path sub-TLV.
As for LSP-Ping, I just propose that= the Segment Routing MPLS Tunnel sub-TLV MAY be used Reply Path TLV defined= in RFC 7110. I viewed the proposal as invitation to technical discussion.

Regards,
Greg

On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro= (cpignata) <cpignata@cisco.com> wrote:
Thank you Greg!

Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems quite= similar to the text removed at https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-bfd-directe= d-05.txt, then the complete set of outstanding technical comments that = triggered the removal of that text from draft-ietf-mpls-bfd-directed-0= 5.txt might peek your interest :-)

One that I recall is: why use label values when every other return-pat= h sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directed,= uses TFSs?=C2=A0

Best,

=E2=80=94 Carlos.

On May 9, 2017, at 12:00 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear Carlos,
I've decided to re-start the discussion and am interested to hear = technical comments to the proposed solution.=C2=A0

Regards,
Greg

On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro= (cpignata) <cpignata@cisco.com> wrote:
Dear Greg,

Cursorily scanning through this, it seems that most concerns raised an= d comments made about the SR sections of=C2=A0draft-ietf-mpls-bfd-directed-0N (with N < 5) apply to your new draft.

This is one of those:=C2=A0https://www.ietf.org/ma= il-archive/web/mpls/current/msg15860.html =E2=80=94 the list = archive shows a few more. The copy/paste did not address the comments.

Best,

=E2=80=94 Carlos.

On May 8, 2017, at 11:33 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear All,
perhaps this new draft may is of interest to you.
Your comments, suggestions are most welcome and greatly appreciated.

Regards,
Greg

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <gregimirsky@gmail.com>



A new version of I-D, draft-mirsky-spring-bfd-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-spring-bfd
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bidirectional Forwarding Detection= (BFD) in Segment Routing Networks Using MPLS Dataplane
Document date:=C2=A0 2017-05-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-spring-bfd-00.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-mirsky-spring-bfd-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-mirsky-spring-bfd-00<= /a>


Abstract:
=C2=A0 =C2=A0Segment Routing architecture leverages the paradigm of source<= br> =C2=A0 =C2=A0routing.=C2=A0 It can be realized in the Multiprotocol Label S= witching
=C2=A0 =C2=A0(MPLS) network without any change to the data plane.=C2=A0 A s= egment is
=C2=A0 =C2=A0encoded as an MPLS label and an ordered list of segments is en= coded
=C2=A0 =C2=A0as a stack of labels.=C2=A0 Bidirectional Forwarding Detection= (BFD) is
=C2=A0 =C2=A0expected to monitor any kind of paths between systems.=C2=A0 T= his document
=C2=A0 =C2=A0defines how to use Label Switched Path Ping to bootstrap and c= ontrol
=C2=A0 =C2=A0path in reverse direction of a BFD session on the Segment Rout= ing
=C2=A0 =C2=A0network over MPLS dataplane.




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

The IETF Secretariat


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls






--94eb2c18871853f0c7054f30a3b7-- From nobody Wed May 10 12:42:12 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B2E12EAA9; Wed, 10 May 2017 12:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lllpogR1dOFy; Wed, 10 May 2017 12:42:01 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 090C6128AB0; Wed, 10 May 2017 12:42:01 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id e65so8022369ita.1; Wed, 10 May 2017 12:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=TEdy2bHd6L1ahTmEy06UhWRMlZCCotYRPJMjLgjKEJo=; b=UaenTSAALvQUyF3UJBal2YaGaapBUJlfECkV3jsw3nc1hfq9P4a2ZxKl5SfXr2gXON kDHnT5V0xiRVuGDKUoiQUG9kE0t+QUk4tlJYfZSAkzzLq6C+DoS7s8L0bXNsnzAEZash abWmB7JLGEemrnvVG6w76A3JYpfSXshfklYlIzhVtOke0kFlHo238YdKB7sZef0KLWIy S1QoxeEhrgNAQZAx2d0sTOE/dKSz1YDGDNpaMBpzcwGQ5JBqAq7zcfB6I2ONnXwFk0aC 1yFY1E9N3SCQFHsSJA6fOem/qVwGSFoAQfCdxCIVKjqnFA4w+CnNWQANd/fwzgpdgsMH OWpQ== 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=TEdy2bHd6L1ahTmEy06UhWRMlZCCotYRPJMjLgjKEJo=; b=QUVu4Cgim5lNObwoiU30/bHXMPN+XcUAMgzskXLKK9qBg+a24uPGOnSGt6pcnzX5yS hJnKzE/MMV79RYKCgzb6XkZU4H2gTSA6wXwQtxlH69eLVGAbEQv2BTWDzrIWHiLev7qN jW5ngOQ/fs/SAyasL3u4L6ZvjoASOtGK+UfQ/2Fp83lXYuJJ69EF8Pgr0rgbzjq0rT7H uPnNmAT3xtyfvI5orVeAKhidPndvL4PtkDcSd0OI7yXYFph5uMTIfKNYw7ZIs7/wYXob RM2hSelp8IdebQ6pkIQMYO58kA1ZKpk1R7My3lEaUmxQ6CI7pjyb6q2sFhRa18Oa6Xze c9OQ== X-Gm-Message-State: AODbwcC6eNm4zADE5aFBEDPSPHWEKdt3ufQL22adOWOoOt7txkwuIrzl gZKM/TWJb7kfEBkVdN2To0Kw5AHAX0Oot8w= X-Received: by 10.36.125.197 with SMTP id b188mr7099939itc.59.1494445320238; Wed, 10 May 2017 12:42:00 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.62.24 with HTTP; Wed, 10 May 2017 12:41:59 -0700 (PDT) In-Reply-To: References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> <9D886964-6C21-427C-8733-7731D5A996D3@cisco.com> From: Robert Raszuk Date: Wed, 10 May 2017 21:41:59 +0200 X-Google-Sender-Auth: rgwSCYFZFs41rD-zSR4UiCp2kpA Message-ID: To: "Carlos Pignataro (cpignata)" Cc: Greg Mirsky , "mpls@ietf.org" , "spring@ietf.org" , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=001a114043b0731de7054f30aa83 Archived-At: Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 19:42:03 -0000 --001a114043b0731de7054f30aa83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Never mind .. I guess you made it up from "Target FEC Stack" :) On Wed, May 10, 2017 at 9:40 PM, Robert Raszuk wrote: > Hi Carlos, > > Sorry what is "TFS" ? > > RFC 7110 does not even use such abbreviation neither do > draft-ietf-mpls-bfd-directed :) Google also seems to be pretty clueless > about it. > > Just curious as you keep using this term in each email :) > > Thx, > R. > > On Wed, May 10, 2017 at 9:24 PM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Greg, >> >> In the MPLS data plane, FECs are also instantiated through a label stack= . >> But RFC 7110 does not use numeric label values, it uses TFSs. That does = not >> create any additional state. E.g.,: https://www.ietf.org/ma >> il-archive/web/mpls/current/msg16091.html >> >> Thanks, >> >> =E2=80=94 Carlos. >> >> >> >> On May 9, 2017, at 3:43 PM, Greg Mirsky wrote: >> >> Hi Carlos, >> I probably would characterize anything that starts with Why not as a >> technical comment but rather as a question. >> According to draft-ietf-spring-segment-routing-mpls, "In the MPLS >> dataplane,the SR header is instantiated through a label stack". >> At the same time, one of advantages of SR is that "per-flow state only >> [maintained] at the ingress node to the SR domain". >> Thus, for the case of monitoring unidirectional SR tunnels, I consider >> that there's no need to create any additional state on the egress node. >> Of course, if there were bidirectional SR tunnels, then control of the >> reverse direction of the BFD session would not require use of the Return >> Path sub-TLV. >> As for LSP-Ping, I just propose that the Segment Routing MPLS Tunnel >> sub-TLV MAY be used Reply Path TLV defined in RFC 7110. I viewed the >> proposal as invitation to technical discussion. >> >> Regards, >> Greg >> >> On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro (cpignata) < >> cpignata@cisco.com> wrote: >> >>> Thank you Greg! >>> >>> Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems >>> quite similar to the text removed at https://tools.ietf.org/rfcdiff >>> ?url2=3Ddraft-ietf-mpls-bfd-directed-05.txt, then the complete set of >>> outstanding technical comments that triggered the removal of that text = from >>> draft-ietf-mpls-bfd-directed-05.txt might peek your interest :-) >>> >>> One that I recall is: why use label values when every other return-path >>> sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directe= d, >>> uses TFSs? >>> >>> Best, >>> >>> =E2=80=94 Carlos. >>> >>> On May 9, 2017, at 12:00 PM, Greg Mirsky wrote: >>> >>> Dear Carlos, >>> I've decided to re-start the discussion and am interested to hear >>> technical comments to the proposed solution. >>> >>> Regards, >>> Greg >>> >>> On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro (cpignata) < >>> cpignata@cisco.com> wrote: >>> >>>> Dear Greg, >>>> >>>> Cursorily scanning through this, it seems that most concerns raised an= d >>>> comments made about the SR sections of draft-ietf-mpls-bfd-directed-0N >>>> (with N < 5) apply to your new draft. >>>> >>>> This is one of those: https://www.ietf.org/ma >>>> il-archive/web/mpls/current/msg15860.html =E2=80=94 the list archive s= hows a >>>> few more. The copy/paste did not address the comments. >>>> >>>> Best, >>>> >>>> =E2=80=94 Carlos. >>>> >>>> On May 8, 2017, at 11:33 PM, Greg Mirsky wrote= : >>>> >>>> Dear All, >>>> perhaps this new draft may is of interest to you. >>>> Your comments, suggestions are most welcome and greatly appreciated. >>>> >>>> Regards, >>>> Greg >>>> >>>> ---------- Forwarded message ---------- >>>> From: >>>> Date: Mon, May 8, 2017 at 8:29 PM >>>> Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt >>>> To: Gregory Mirsky >>>> >>>> >>>> >>>> A new version of I-D, draft-mirsky-spring-bfd-00.txt >>>> has been successfully submitted by Greg Mirsky and posted to the >>>> IETF repository. >>>> >>>> Name: draft-mirsky-spring-bfd >>>> Revision: 00 >>>> Title: Bidirectional Forwarding Detection (BFD) in Segment >>>> Routing Networks Using MPLS Dataplane >>>> Document date: 2017-05-08 >>>> Group: Individual Submission >>>> Pages: 7 >>>> URL: https://www.ietf.org/internet- >>>> drafts/draft-mirsky-spring-bfd-00.txt >>>> Status: https://datatracker.ietf.org/ >>>> doc/draft-mirsky-spring-bfd/ >>>> Htmlized: https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 >>>> Htmlized: https://datatracker.ietf.org/ >>>> doc/html/draft-mirsky-spring-bfd-00 >>>> >>>> >>>> Abstract: >>>> Segment Routing architecture leverages the paradigm of source >>>> routing. It can be realized in the Multiprotocol Label Switching >>>> (MPLS) network without any change to the data plane. A segment is >>>> encoded as an MPLS label and an ordered list of segments is encoded >>>> as a stack of labels. Bidirectional Forwarding Detection (BFD) is >>>> expected to monitor any kind of paths between systems. This docume= nt >>>> defines how to use Label Switched Path Ping to bootstrap and contro= l >>>> path in reverse direction of a BFD session on the Segment Routing >>>> network over MPLS dataplane. >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>>> >>>> >>> >>> >> >> > --001a114043b0731de7054f30aa83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Never mind= .. I guess you made it up from "Target FEC Stack"= :)



On Wed, May 10, 2017 at 9:40 PM, Robert Ras= zuk <robert@raszuk.net> wrote:
Hi Carlos,

Sorry what is "TFS" ?=C2=A0

RFC 7110 does not even use su= ch abbreviation neither do=C2=A0draft-ietf-mpls-bfd-directed=C2=A0:) Google als= o seems to be pretty clueless about it.=C2=A0

<= /div>
Just curious as you keep using this term in each em= ail :)=C2=A0

Thx,
R= .

On Wed, May 10, 2017 at 9:24 PM, Carlos= Pignataro (cpignata) <cpignata@cisco.com> wrote:
Greg,

In the MPLS data plane, FECs are also instantiated through a label sta= ck. But RFC 7110 does not use numeric label values, it uses TFSs. That does= not create any additional state. E.g.,:=C2=A0https://w= ww.ietf.org/mail-archive/web/mpls/current/msg16091.html

Thanks,

=E2=80=94 Carlos.



On May 9, 2017, at 3:43 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Carlos,
I probably would characterize anything that starts with Why not as a t= echnical comment but rather as a question.
According to=C2=A0draft-ietf-spring-segment-routing-mpls, "= In the MPLS=C2=A0dat= aplane,the SR head= er is instantiated through a label stack".
At the same time, one of advantages of SR is that &= quot;per-flow state only [maintained] at the ingress node to the SR=C2=A0domain".
Thus, for the case of monitoring uni= directional SR tunnels, I consider that there's no need to create any a= dditional state on the egress node.
Of course, if there were bidirection= al SR tunnels, then control of the reverse direction of the BFD session wou= ld not require use of the Return Path sub-TLV.
As for LSP-Ping, I just propose that= the Segment Routing MPLS Tunnel sub-TLV MAY be used Reply Path TLV defined= in RFC 7110. I viewed the proposal as invitation to technical discussion.

Regards,
Greg

On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro= (cpignata) <cpignata@cisco.com> wrote:
Thank you Greg!

Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems quite= similar to the text removed at https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-bfd-directe= d-05.txt, then the complete set of outstanding technical comments that = triggered the removal of that text from draft-ietf-mpls-bfd-directed-0= 5.txt might peek your interest :-)

One that I recall is: why use label values when every other return-pat= h sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directed,= uses TFSs?=C2=A0

Best,

=E2=80=94 Carlos.

On May 9, 2017, at 12:00 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear Carlos,
I've decided to re-start the discussion and am interested to hear = technical comments to the proposed solution.=C2=A0

Regards,
Greg

On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro= (cpignata) <cpignata@cisco.com> wrote:
Dear Greg,

Cursorily scanning through this, it seems that most concerns raised an= d comments made about the SR sections of=C2=A0draft-ietf-mpls-bfd-directed-0N (with N < 5) apply to your new draft.

This is one of those:=C2=A0https://www.ietf.org/ma= il-archive/web/mpls/current/msg15860.html =E2=80=94 the list = archive shows a few more. The copy/paste did not address the comments.

Best,

=E2=80=94 Carlos.

On May 8, 2017, at 11:33 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear All,
perhaps this new draft may is of interest to you.
Your comments, suggestions are most welcome and greatly appreciated.

Regards,
Greg

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <gregimirsky@gmail.com>



A new version of I-D, draft-mirsky-spring-bfd-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-spring-bfd
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bidirectional Forwarding Detection= (BFD) in Segment Routing Networks Using MPLS Dataplane
Document date:=C2=A0 2017-05-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-spring-bfd-00.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-mirsky-spring-bfd-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-mirsky-spring-bfd-00<= /a>


Abstract:
=C2=A0 =C2=A0Segment Routing architecture leverages the paradigm of source<= br> =C2=A0 =C2=A0routing.=C2=A0 It can be realized in the Multiprotocol Label S= witching
=C2=A0 =C2=A0(MPLS) network without any change to the data plane.=C2=A0 A s= egment is
=C2=A0 =C2=A0encoded as an MPLS label and an ordered list of segments is en= coded
=C2=A0 =C2=A0as a stack of labels.=C2=A0 Bidirectional Forwarding Detection= (BFD) is
=C2=A0 =C2=A0expected to monitor any kind of paths between systems.=C2=A0 T= his document
=C2=A0 =C2=A0defines how to use Label Switched Path Ping to bootstrap and c= ontrol
=C2=A0 =C2=A0path in reverse direction of a BFD session on the Segment Rout= ing
=C2=A0 =C2=A0network over MPLS dataplane.




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

The IETF Secretariat


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls







--001a114043b0731de7054f30aa83-- From nobody Wed May 10 13:02:15 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B76129B2F; Wed, 10 May 2017 13:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 pErYYZ-QPBSJ; Wed, 10 May 2017 13:01:55 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC611250B8; Wed, 10 May 2017 13:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30672; q=dns/txt; s=iport; t=1494446514; x=1495656114; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4SC3vMbhU7xgrg/Gn955pEEGM4uUGPqg8hnNhQ8338E=; b=NEY6v53HdUJ4Ss3+gBpaVV5bh4yS5+VN0u8t3lBIEl7oDlfCzCIW5MPF T5QlStHyfrGA/WDPb/S1hyuyI1d1cBb+tlu553+1KPYPCaCtYKCTURunz igRxvWIihSPJWwyjvG8NA0Xdk9uxK+LzKzpNMxD01wX1mQ4w76va4iEVE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAQDxcBNZ/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMB4NiihiRNyFyhzGNT4IPIQEKhXgCGoRoPxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUVAQEBAQMBASFLCQIQAgEIEQECAQIhBwMCAgIfBgsUAwYIAgQOBRuJb?= =?us-ascii?q?gMVDrJCgiaHLg2DOAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GX4FeKwuCMTSCVE2?= =?us-ascii?q?BExECATsWCIJQL4IxBYlEhl6GTYZgOwGHG4cshFOCBFWEZoosiy2EdyiDdgEPE?= =?us-ascii?q?DhMMwtwFRwqEgGEKjkcgWN2AYgLgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.38,320,1491264000"; d="scan'208,217";a="243738630" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2017 20:01:53 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v4AK1qK4015515 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 May 2017 20:01:53 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 10 May 2017 16:01:51 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 10 May 2017 16:01:52 -0400 From: "Carlos Pignataro (cpignata)" To: Robert Raszuk CC: "spring@ietf.org" , "rtg-bfd@ietf.org" , "mpls@ietf.org" Thread-Topic: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt Thread-Index: AQHSyNwl4f82jzKO5Eq8Ccd1kzJOwKHsbA8AgAAB9QCAADyAAIABjQKAgAAEOwCAAACOgIAABY2A Date: Wed, 10 May 2017 20:01:52 +0000 Message-ID: References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> <9D886964-6C21-427C-8733-7731D5A996D3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.52] Content-Type: multipart/alternative; boundary="_000_F1E0BFDF70724B2696BC4F47FE8FEDCBciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 20:01:57 -0000 --_000_F1E0BFDF70724B2696BC4F47FE8FEDCBciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGFyZSByaWdodCDigJQgc29ycnkgYWJvdXQgdGhhdCEg4oCcVEZT4oCdIGlzIG5vdCB1c2Vk IGluIGFueSBvZiB0aG9zZSBSRkNzIG9yIGRyYWZ0cywgYWx0aG91Z2ggaXQgaXMgdXNlZCBvbiBl bWFpbCBkaXNjdXNzaW9ucyBhYm91dCBMU1AgUGluZy4NCg0KSW5kZWVkLCBURlMgZm9yIOKAnFRh cmdldCBGRUMgU3RhY2vigJ0gZnJvbSBTZWN0aW9uIDMuMiBvZiBSRkMgODAyOS4NCg0KVGhhbmtz LA0KDQrigJQgQ2FybG9zLg0KDQpPbiBNYXkgMTAsIDIwMTcsIGF0IDM6NDEgUE0sIFJvYmVydCBS YXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+IHdyb3Rl Og0KDQoNCk5ldmVyIG1pbmQgLi4gSSBndWVzcyB5b3UgbWFkZSBpdCB1cCBmcm9tICJUYXJnZXQg RkVDIFN0YWNrIiA6KQ0KDQoNCg0KT24gV2VkLCBNYXkgMTAsIDIwMTcgYXQgOTo0MCBQTSwgUm9i ZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4g d3JvdGU6DQpIaSBDYXJsb3MsDQoNClNvcnJ5IHdoYXQgaXMgIlRGUyIgPw0KDQpSRkMgNzExMCBk b2VzIG5vdCBldmVuIHVzZSBzdWNoIGFiYnJldmlhdGlvbiBuZWl0aGVyIGRvIGRyYWZ0LWlldGYt bXBscy1iZmQtZGlyZWN0ZWQgOikgR29vZ2xlIGFsc28gc2VlbXMgdG8gYmUgcHJldHR5IGNsdWVs ZXNzIGFib3V0IGl0Lg0KDQpKdXN0IGN1cmlvdXMgYXMgeW91IGtlZXAgdXNpbmcgdGhpcyB0ZXJt IGluIGVhY2ggZW1haWwgOikNCg0KVGh4LA0KUi4NCg0KT24gV2VkLCBNYXkgMTAsIDIwMTcgYXQg OToyNCBQTSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIDxjcGlnbmF0YUBjaXNjby5jb208 bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+IHdyb3RlOg0KR3JlZywNCg0KSW4gdGhlIE1QTFMg ZGF0YSBwbGFuZSwgRkVDcyBhcmUgYWxzbyBpbnN0YW50aWF0ZWQgdGhyb3VnaCBhIGxhYmVsIHN0 YWNrLiBCdXQgUkZDIDcxMTAgZG9lcyBub3QgdXNlIG51bWVyaWMgbGFiZWwgdmFsdWVzLCBpdCB1 c2VzIFRGU3MuIFRoYXQgZG9lcyBub3QgY3JlYXRlIGFueSBhZGRpdGlvbmFsIHN0YXRlLiBFLmcu LDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJlbnQvbXNn MTYwOTEuaHRtbA0KDQpUaGFua3MsDQoNCuKAlCBDYXJsb3MuDQoNCg0KDQpPbiBNYXkgOSwgMjAx NywgYXQgMzo0MyBQTSwgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86 Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhpIENhcmxvcywNCkkgcHJvYmFibHkg d291bGQgY2hhcmFjdGVyaXplIGFueXRoaW5nIHRoYXQgc3RhcnRzIHdpdGggV2h5IG5vdCBhcyBh IHRlY2huaWNhbCBjb21tZW50IGJ1dCByYXRoZXIgYXMgYSBxdWVzdGlvbi4NCkFjY29yZGluZyB0 byBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscywgIkluIHRoZSBNUExTIGRh dGFwbGFuZSx0aGUgU1IgaGVhZGVyIGlzIGluc3RhbnRpYXRlZCB0aHJvdWdoIGEgbGFiZWwgc3Rh Y2siLg0KQXQgdGhlIHNhbWUgdGltZSwgb25lIG9mIGFkdmFudGFnZXMgb2YgU1IgaXMgdGhhdCAi cGVyLWZsb3cgc3RhdGUgb25seSBbbWFpbnRhaW5lZF0gYXQgdGhlIGluZ3Jlc3Mgbm9kZSB0byB0 aGUgU1IgZG9tYWluIi4NClRodXMsIGZvciB0aGUgY2FzZSBvZiBtb25pdG9yaW5nIHVuaWRpcmVj dGlvbmFsIFNSIHR1bm5lbHMsIEkgY29uc2lkZXIgdGhhdCB0aGVyZSdzIG5vIG5lZWQgdG8gY3Jl YXRlIGFueSBhZGRpdGlvbmFsIHN0YXRlIG9uIHRoZSBlZ3Jlc3Mgbm9kZS4NCk9mIGNvdXJzZSwg aWYgdGhlcmUgd2VyZSBiaWRpcmVjdGlvbmFsIFNSIHR1bm5lbHMsIHRoZW4gY29udHJvbCBvZiB0 aGUgcmV2ZXJzZSBkaXJlY3Rpb24gb2YgdGhlIEJGRCBzZXNzaW9uIHdvdWxkIG5vdCByZXF1aXJl IHVzZSBvZiB0aGUgUmV0dXJuIFBhdGggc3ViLVRMVi4NCkFzIGZvciBMU1AtUGluZywgSSBqdXN0 IHByb3Bvc2UgdGhhdCB0aGUgU2VnbWVudCBSb3V0aW5nIE1QTFMgVHVubmVsIHN1Yi1UTFYgTUFZ IGJlIHVzZWQgUmVwbHkgUGF0aCBUTFYgZGVmaW5lZCBpbiBSRkMgNzExMC4gSSB2aWV3ZWQgdGhl IHByb3Bvc2FsIGFzIGludml0YXRpb24gdG8gdGVjaG5pY2FsIGRpc2N1c3Npb24uDQoNClJlZ2Fy ZHMsDQpHcmVnDQoNCk9uIFR1ZSwgTWF5IDksIDIwMTcgYXQgOTowNyBBTSwgQ2FybG9zIFBpZ25h dGFybyAoY3BpZ25hdGEpIDxjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2Nv LmNvbT4+IHdyb3RlOg0KVGhhbmsgeW91IEdyZWchDQoNClNpbmNlIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMCBzZWVtcyBxdWl0ZSBzaW1pbGFy IHRvIHRoZSB0ZXh0IHJlbW92ZWQgYXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3RlZC0wNS50eHQsIHRoZW4gdGhlIGNvbXBsZXRl IHNldCBvZiBvdXRzdGFuZGluZyB0ZWNobmljYWwgY29tbWVudHMgdGhhdCB0cmlnZ2VyZWQgdGhl IHJlbW92YWwgb2YgdGhhdCB0ZXh0IGZyb20gZHJhZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3RlZC0w NS50eHQgbWlnaHQgcGVlayB5b3VyIGludGVyZXN0IDotKQ0KDQpPbmUgdGhhdCBJIHJlY2FsbCBp czogd2h5IHVzZSBsYWJlbCB2YWx1ZXMgd2hlbiBldmVyeSBvdGhlciByZXR1cm4tcGF0aCBzdWIt VExWIGZvciBCRkQgYW5kIGZvciBMU1AtUGluZywgaW5jbHVkaW5nIGRyYWZ0LWlldGYtbXBscy1i ZmQtZGlyZWN0ZWQsIHVzZXMgVEZTcz8NCg0KQmVzdCwNCg0K4oCUIENhcmxvcy4NCg0KT24gTWF5 IDksIDIwMTcsIGF0IDEyOjAwIFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29t PG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90ZToNCg0KRGVhciBDYXJsb3MsDQpJ J3ZlIGRlY2lkZWQgdG8gcmUtc3RhcnQgdGhlIGRpc2N1c3Npb24gYW5kIGFtIGludGVyZXN0ZWQg dG8gaGVhciB0ZWNobmljYWwgY29tbWVudHMgdG8gdGhlIHByb3Bvc2VkIHNvbHV0aW9uLg0KDQpS ZWdhcmRzLA0KR3JlZw0KDQpPbiBUdWUsIE1heSA5LCAyMDE3IGF0IDg6NTEgQU0sIENhcmxvcyBQ aWduYXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lzY28uY29tPG1haWx0bzpjcGlnbmF0YUBj aXNjby5jb20+PiB3cm90ZToNCkRlYXIgR3JlZywNCg0KQ3Vyc29yaWx5IHNjYW5uaW5nIHRocm91 Z2ggdGhpcywgaXQgc2VlbXMgdGhhdCBtb3N0IGNvbmNlcm5zIHJhaXNlZCBhbmQgY29tbWVudHMg bWFkZSBhYm91dCB0aGUgU1Igc2VjdGlvbnMgb2YgZHJhZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3Rl ZC0wTiAod2l0aCBOIDwgNSkgYXBwbHkgdG8geW91ciBuZXcgZHJhZnQuDQoNClRoaXMgaXMgb25l IG9mIHRob3NlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21wbHMvY3Vy cmVudC9tc2cxNTg2MC5odG1sIOKAlCB0aGUgbGlzdCBhcmNoaXZlIHNob3dzIGEgZmV3IG1vcmUu IFRoZSBjb3B5L3Bhc3RlIGRpZCBub3QgYWRkcmVzcyB0aGUgY29tbWVudHMuDQoNCkJlc3QsDQoN CuKAlCBDYXJsb3MuDQoNCk9uIE1heSA4LCAyMDE3LCBhdCAxMTozMyBQTSwgR3JlZyBNaXJza3kg PGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4gd3Jv dGU6DQoNCkRlYXIgQWxsLA0KcGVyaGFwcyB0aGlzIG5ldyBkcmFmdCBtYXkgaXMgb2YgaW50ZXJl c3QgdG8geW91Lg0KWW91ciBjb21tZW50cywgc3VnZ2VzdGlvbnMgYXJlIG1vc3Qgd2VsY29tZSBh bmQgZ3JlYXRseSBhcHByZWNpYXRlZC4NCg0KUmVnYXJkcywNCkdyZWcNCg0KLS0tLS0tLS0tLSBG b3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogTW9uLCBNYXkgOCwg MjAxNyBhdCA4OjI5IFBNDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwLnR4dA0KVG86IEdyZWdvcnkgTWlyc2t5IDxncmVnaW1p cnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+DQoNCg0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAudHh0DQpoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhl DQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1taXJza3ktc3ByaW5n LWJmZA0KUmV2aXNpb246ICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgQmlkaXJlY3Rpb25hbCBG b3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBpbiBTZWdtZW50IFJvdXRpbmcgTmV0d29ya3MgVXNp bmcgTVBMUyBEYXRhcGxhbmUNCkRvY3VtZW50IGRhdGU6ICAyMDE3LTA1LTA4DQpHcm91cDogICAg ICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgNw0KVVJMOiAgICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1taXJza3kt c3ByaW5nLWJmZC0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC8NCkh0bWxpemVkOiAgICAgICBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDANCkh0bWxp emVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW1p cnNreS1zcHJpbmctYmZkLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBTZWdtZW50IFJvdXRpbmcgYXJj aGl0ZWN0dXJlIGxldmVyYWdlcyB0aGUgcGFyYWRpZ20gb2Ygc291cmNlDQogICByb3V0aW5nLiAg SXQgY2FuIGJlIHJlYWxpemVkIGluIHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZw0K ICAgKE1QTFMpIG5ldHdvcmsgd2l0aG91dCBhbnkgY2hhbmdlIHRvIHRoZSBkYXRhIHBsYW5lLiAg QSBzZWdtZW50IGlzDQogICBlbmNvZGVkIGFzIGFuIE1QTFMgbGFiZWwgYW5kIGFuIG9yZGVyZWQg bGlzdCBvZiBzZWdtZW50cyBpcyBlbmNvZGVkDQogICBhcyBhIHN0YWNrIG9mIGxhYmVscy4gIEJp ZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMNCiAgIGV4cGVjdGVkIHRv IG1vbml0b3IgYW55IGtpbmQgb2YgcGF0aHMgYmV0d2VlbiBzeXN0ZW1zLiAgVGhpcyBkb2N1bWVu dA0KICAgZGVmaW5lcyBob3cgdG8gdXNlIExhYmVsIFN3aXRjaGVkIFBhdGggUGluZyB0byBib290 c3RyYXAgYW5kIGNvbnRyb2wNCiAgIHBhdGggaW4gcmV2ZXJzZSBkaXJlY3Rpb24gb2YgYSBCRkQg c2Vzc2lvbiBvbiB0aGUgU2VnbWVudCBSb3V0aW5nDQogICBuZXR3b3JrIG92ZXIgTVBMUyBkYXRh cGxhbmUuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rv b2xzLmlldGYub3JnLz4uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQpt cGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0KDQoNCg0KDQoNCg0K --_000_F1E0BFDF70724B2696BC4F47FE8FEDCBciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <86A7300BB8B04C4D8ABEE15686C0C1E4@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KWW91IGFyZSByaWdodCDigJQgc29y cnkgYWJvdXQgdGhhdCEg4oCcVEZT4oCdIGlzIG5vdCB1c2VkIGluIGFueSBvZiB0aG9zZSBSRkNz IG9yIGRyYWZ0cywgYWx0aG91Z2ggaXQgaXMgdXNlZCBvbiBlbWFpbCBkaXNjdXNzaW9ucyBhYm91 dCBMU1AgUGluZy4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5J bmRlZWQsIFRGUyBmb3Ig4oCcVGFyZ2V0IEZFQyBTdGFja+KAnSBmcm9tIFNlY3Rpb24gMy4yIG9m IFJGQyZuYnNwOzgwMjkuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5UaGFua3MsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJQgQ2FybG9zLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPk9uIE1heSAxMCwgMjAxNywgYXQgMzo0MSBQTSwgUm9iZXJ0IFJhc3p1ayAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiBjbGFzcz0iIj5yb2JlcnRAcmFzenVr Lm5ldDwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1u ZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Es c2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCk5ldmVyIG1pbmQgLi4gSSBndWVzcyB5b3Ug bWFkZSBpdCB1cCBmcm9tICZxdW90OzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ3RpbWVzIG5l dyByb21hbic7IGZvbnQtc2l6ZTogMTJweDsiIGNsYXNzPSIiPlRhcmdldCBGRUMgU3RhY2smcXVv dDsgOik8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogJ3RpbWVzIG5ldyByb21hbic7IGZvbnQtc2l6ZTogMTJw eDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9Imdt YWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJp Zjtmb250LXNpemU6c21hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAndGltZXMgbmV3 IHJvbWFuJzsgZm9udC1zaXplOiAxMnB4OyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFu PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFdlZCwgTWF5IDEwLCAyMDE3IGF0IDk6NDAgUE0s IFJvYmVydCBSYXN6dWsgPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1h aWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnJvYmVydEBy YXN6dWsubmV0PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWws aGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCkhpIENhcmxvcyw8L2Rpdj4N CjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVs dmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NClNvcnJ5IHdoYXQgaXMgJnF1b3Q7 VEZTJnF1b3Q7ID8mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxl PSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwi Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxs Ij4NClJGQyA3MTEwIGRvZXMgbm90IGV2ZW4gdXNlIHN1Y2ggYWJicmV2aWF0aW9uIG5laXRoZXIg ZG8mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjFlbTtmb250LWZhbWlseTphcmlhbCxzYW5z LXNlcmlmIiBjbGFzcz0iIj5kcmFmdC1pZXRmLW1wbHMtYmZkLTx3YnIgY2xhc3M9IiI+ZGlyZWN0 ZWQ8L3NwYW4+Jm5ic3A7OikgR29vZ2xlIGFsc28gc2VlbXMgdG8gYmUgcHJldHR5IGNsdWVsZXNz IGFib3V0IGl0LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+ DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxl PSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwi Pg0KSnVzdCBjdXJpb3VzIGFzIHlvdSBrZWVwIHVzaW5nIHRoaXMgdGVybSBpbiBlYWNoIGVtYWls IDopJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1m YW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQt ZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpUaHgs PGJyIGNsYXNzPSIiPg0KUi48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iSE9FblpiIj4NCjxk aXYgY2xhc3M9Img1Ij4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBNYXkgMTAsIDIwMTcgYXQgOToyNCBQTSwg Q2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo8c3BhbiBkaXI9Imx0ciIgY2xhc3M9IiI+Jmx0 OzxhIGhyZWY9Im1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFz cz0iIj5jcGlnbmF0YUBjaXNjby5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCIgY2xhc3M9IiI+R3JlZywNCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkluIHRoZSBNUExTIGRhdGEgcGxh bmUsIEZFQ3MgYXJlIGFsc28gaW5zdGFudGlhdGVkIHRocm91Z2ggYSBsYWJlbCBzdGFjay4gQnV0 IFJGQyA3MTEwIGRvZXMgbm90IHVzZSBudW1lcmljIGxhYmVsIHZhbHVlcywgaXQgdXNlcyBURlNz LiBUaGF0IGRvZXMgbm90IGNyZWF0ZSBhbnkgYWRkaXRpb25hbCBzdGF0ZS4gRS5nLiw6Jm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJl bnQvbXNnMTYwOTEuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21hPHdiciBjbGFzcz0iIj5pbC1hcmNoaXZlL3dlYi9tcGxzL2N1cnJlbnQvbXM8d2Jy IGNsYXNzPSIiPmcxNjA5MS5odG1sPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+4oCUIENhcmxvcy48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJtXzU0MzE0NTgxMjE5Mjg2ODEzMDJoNSI+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXkg OSwgMjAxNywgYXQgMzo0MyBQTSwgR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVn aW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5ncmVnaW1pcnNreUBn bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0ibV81NDMxNDU4MTIxOTI4 NjgxMzAybV8tMjM4ODg0ODEzOTcwODEyMjI3OEFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPkhpIENhcmxvcywNCjxkaXYg Y2xhc3M9IiI+SSBwcm9iYWJseSB3b3VsZCBjaGFyYWN0ZXJpemUgYW55dGhpbmcgdGhhdCBzdGFy dHMgd2l0aCBXaHkgbm90IGFzIGEgdGVjaG5pY2FsIGNvbW1lbnQgYnV0IHJhdGhlciBhcyBhIHF1 ZXN0aW9uLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BY2NvcmRpbmcgdG8mbmJzcDs8Zm9udCBmYWNl PSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iYmFj a2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1MywyNDUpIiBjbGFzcz0iIj5kPC9zcGFuPjxzcGFuIHN0 eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjUzLDI0NSkiIGNsYXNzPSIiPnJhZnQtaWV0 Zi1zcHJpbmctc2VnbWVudC1yPHdiciBjbGFzcz0iIj5vdXRpbmctbXBscywgJnF1b3Q7PC9zcGFu PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjUzLDI0NSkiIGNsYXNzPSIi PkluDQogdGhlIE1QTFMmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6 cmdiKDI1NSwyNTMsMjQ1KSIgY2xhc3M9IiI+ZGF0YXBsYW5lLDwvc3Bhbj48c3BhbiBzdHlsZT0i YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1MywyNDUpIiBjbGFzcz0iIj50aGUgU1IgaGVhZGVy IGlzIGluc3RhbnRpYXRlZCB0aHJvdWdoIGEgbGFiZWwgc3RhY2smcXVvdDsuPC9zcGFuPjwvZm9u dD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fu cy1zZXJpZiIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwy NTMsMjQ1KSIgY2xhc3M9IiI+QXQgdGhlIHNhbWUgdGltZSwgb25lIG9mIGFkdmFudGFnZXMgb2Yg U1IgaXMgdGhhdCAmcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdi KDI1NSwyNTMsMjQ1KTtmb250LXNpemU6MTRweCIgY2xhc3M9IiI+cGVyLWZsb3cNCiBzdGF0ZSBv bmx5IFttYWludGFpbmVkXSBhdCB0aGUgaW5ncmVzcyBub2RlIHRvIHRoZSBTUiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1MywyNDUpO2ZvbnQtc2l6 ZToxNHB4IiBjbGFzcz0iIj5kb21haW4mcXVvdDsuPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiIgY2xhc3M9 IiI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTMsMjQ1KTtmb250LXNp emU6MTRweCIgY2xhc3M9IiI+VGh1cywgZm9yIHRoZSBjYXNlIG9mIG1vbml0b3JpbmcgdW5pZGly ZWN0aW9uYWwgU1IgdHVubmVscywgSSBjb25zaWRlciB0aGF0IHRoZXJlJ3Mgbm8gbmVlZCB0byBj cmVhdGUgYW55IGFkZGl0aW9uYWwgc3RhdGUNCiBvbiB0aGUgZWdyZXNzIG5vZGUuPC9zcGFuPjwv Zm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwg c2Fucy1zZXJpZiIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiKDI1 NSwyNTMsMjQ1KTtmb250LXNpemU6MTRweCIgY2xhc3M9IiI+T2YgY291cnNlLCBpZiB0aGVyZSB3 ZXJlIGJpZGlyZWN0aW9uYWwgU1IgdHVubmVscywgdGhlbiBjb250cm9sIG9mIHRoZSByZXZlcnNl IGRpcmVjdGlvbiBvZiB0aGUgQkZEIHNlc3Npb24gd291bGQgbm90IHJlcXVpcmUNCiB1c2Ugb2Yg dGhlIFJldHVybiBQYXRoIHN1Yi1UTFYuPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiIgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTMsMjQ1KTtmb250LXNpemU6MTRw eCIgY2xhc3M9IiI+QXMgZm9yIExTUC1QaW5nLCBJIGp1c3QgcHJvcG9zZSB0aGF0IHRoZSBTZWdt ZW50IFJvdXRpbmcgTVBMUyBUdW5uZWwgc3ViLVRMViBNQVkgYmUgdXNlZCBSZXBseSBQYXRoIFRM ViBkZWZpbmVkIGluIFJGQyA3MTEwLg0KIEkgdmlld2VkIHRoZSBwcm9wb3NhbCBhcyBpbnZpdGF0 aW9uIHRvIHRlY2huaWNhbCBkaXNjdXNzaW9uLjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjUzLDI0NSk7Zm9udC1zaXpl OjE0cHgiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjUzLDI0NSk7Zm9udC1z aXplOjE0cHgiIGNsYXNzPSIiPlJlZ2FyZHMsPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiIgY2xhc3M9IiI+ PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTMsMjQ1KTtmb250LXNpemU6 MTRweCIgY2xhc3M9IiI+R3JlZzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+ T24gVHVlLCBNYXkgOSwgMjAxNyBhdCA5OjA3IEFNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0 YSkNCjxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmNwaWduYXRh QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmNwaWduYXRhQGNpc2NvLmNvbTwv YT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk IiBjbGFzcz0iIj5UaGFuayB5b3UgR3JlZyENCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNpbmNlIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz PSIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyPHdiciBjbGFzcz0iIj5hZnQtbWly c2t5LXNwcmluZy1iZmQtMDA8L2E+IHNlZW1zIHF1aXRlIHNpbWlsYXIgdG8gdGhlIHRleHQgcmVt b3ZlZCBhdA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3RlZC0wNS50eHQiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZjx3YnIgY2xhc3M9IiI+P3VybDI9ZHJh ZnQtaWV0Zi1tcGxzLWJmZC1kaXJlPHdiciBjbGFzcz0iIj5jdGVkLTA1LnR4dDwvYT4sIHRoZW4g dGhlIGNvbXBsZXRlIHNldCBvZiBvdXRzdGFuZGluZyB0ZWNobmljYWwgY29tbWVudHMgdGhhdCB0 cmlnZ2VyZWQgdGhlIHJlbW92YWwgb2YgdGhhdCB0ZXh0IGZyb20gZHJhZnQtaWV0Zi1tcGxzLWJm ZC1kaXJlY3RlZC0wPHdiciBjbGFzcz0iIj41LnR4dCBtaWdodA0KIHBlZWsgeW91ciBpbnRlcmVz dCA6LSk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPk9uZSB0aGF0IEkgcmVjYWxsIGlzOiB3aHkgdXNlIGxhYmVsIHZhbHVlcyB3aGVuIGV2 ZXJ5IG90aGVyIHJldHVybi1wYXRoIHN1Yi1UTFYgZm9yIEJGRCBhbmQgZm9yIExTUC1QaW5nLCBp bmNsdWRpbmcgZHJhZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3RlZCwgdXNlcyBURlNzPyZuYnNwOzwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ QmVzdCw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPuKAlCBDYXJsb3MuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0ibV81 NDMxNDU4MTIxOTI4NjgxMzAybV8tMjM4ODg0ODEzOTcwODEyMjI3OGg1Ij4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXkgOSwgMjAxNywgYXQgMTI6MDAgUE0sIEdy ZWcgTWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayIgY2xhc3M9IiI+Z3JlZ2ltaXJza3lAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6 PC9kaXY+DQo8YnIgY2xhc3M9Im1fNTQzMTQ1ODEyMTkyODY4MTMwMm1fLTIzODg4NDgxMzk3MDgx MjIyNzhtXy00MjgwMjc0MTcwMDM4OTk4OTAyQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+RGVhciBDYXJsb3MsDQo8ZGl2 IGNsYXNzPSIiPkkndmUgZGVjaWRlZCB0byByZS1zdGFydCB0aGUgZGlzY3Vzc2lvbiBhbmQgYW0g aW50ZXJlc3RlZCB0byBoZWFyIHRlY2huaWNhbCBjb21tZW50cyB0byB0aGUgcHJvcG9zZWQgc29s dXRpb24uJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5SZWdhcmRzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5HcmVnPC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9xdW90ZSI+T24gVHVlLCBNYXkgOSwgMjAxNyBhdCA4OjUxIEFNLCBDYXJsb3MgUGln bmF0YXJvIChjcGlnbmF0YSkNCjxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4mbHQ7PGEgaHJlZj0i bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmNwaWdu YXRhQGNpc2NvLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQt d3JhcDpicmVhay13b3JkIiBjbGFzcz0iIj5EZWFyIEdyZWcsDQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DdXJzb3JpbHkgc2Nhbm5pbmcgdGhyb3Vn aCB0aGlzLCBpdCBzZWVtcyB0aGF0IG1vc3QgY29uY2VybnMgcmFpc2VkIGFuZCBjb21tZW50cyBt YWRlIGFib3V0IHRoZSBTUiBzZWN0aW9ucyBvZiZuYnNwO2RyYWZ0LWlldGYtbXBscy1iZmQtZGly ZWN0ZTx3YnIgY2xhc3M9IiI+ZC0wTiAod2l0aCBOICZsdDsgNSkgYXBwbHkgdG8geW91ciBuZXcg ZHJhZnQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5UaGlzIGlzIG9uZSBvZiB0aG9zZTombmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cxNTg2MC5odG1sIiB0YXJn ZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWE8d2JyIGNsYXNzPSIi PmlsLWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tczx3YnIgY2xhc3M9IiI+ZzE1ODYwLmh0bWw8 L2E+IOKAlCB0aGUgbGlzdCBhcmNoaXZlIHNob3dzDQogYSBmZXcgbW9yZS4gVGhlIGNvcHkvcGFz dGUgZGlkIG5vdCBhZGRyZXNzIHRoZSBjb21tZW50cy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJlc3QsPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJQgQ2FybG9zLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0ibV81 NDMxNDU4MTIxOTI4NjgxMzAybV8tMjM4ODg0ODEzOTcwODEyMjI3OG1fLTQyODAyNzQxNzAwMzg5 OTg5MDJoNSI+DQo8ZGl2IGNsYXNzPSIiPk9uIE1heSA4LCAyMDE3LCBhdCAxMTozMyBQTSwgR3Jl ZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIiBjbGFzcz0iIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 L2Rpdj4NCjxiciBjbGFzcz0ibV81NDMxNDU4MTIxOTI4NjgxMzAybV8tMjM4ODg0ODEzOTcwODEy MjI3OG1fLTQyODAyNzQxNzAwMzg5OTg5MDJtXzQxODc4MTcxNTUzMzQ2MDc4MTdBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9Im1fNTQzMTQ1ODEyMTkyODY4MTMwMm1fLTIzODg4NDgxMzk3 MDgxMjIyNzhtXy00MjgwMjc0MTcwMDM4OTk4OTAyaDUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9 IiI+RGVhciBBbGwsDQo8ZGl2IGNsYXNzPSIiPnBlcmhhcHMgdGhpcyBuZXcgZHJhZnQgbWF5IGlz IG9mIGludGVyZXN0IHRvIHlvdS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+WW91ciBjb21tZW50cywg c3VnZ2VzdGlvbnMgYXJlIG1vc3Qgd2VsY29tZSBhbmQgZ3JlYXRseSBhcHByZWNpYXRlZC48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJl Z2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkdyZWc8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPi0tLS0tLS0tLS0gRm9yd2FyZGVk IG1lc3NhZ2UgLS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCkZyb206IDxiIGNsYXNzPSJnbWFpbF9z ZW5kZXJuYW1lIj48L2I+PHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPiZsdDs8YSBocmVmPSJtYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KRGF0ZTog TW9uLCBNYXkgOCwgMjAxNyBhdCA4OjI5IFBNPGJyIGNsYXNzPSIiPg0KU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMC50eHQ8YnIg Y2xhc3M9IiI+DQpUbzogR3JlZ29yeSBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1p cnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5ncmVnaW1pcnNreUBnbWFp bC5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1taXJza3ktc3ByaW5n LWJmZC0wMC50eHQ8YnIgY2xhc3M9IiI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhlPGJyIGNsYXNzPSIiPg0KSUVURiByZXBv c2l0b3J5LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5hbWU6Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1taXJza3ktc3ByaW5nLWJmZDxiciBjbGFz cz0iIj4NClJldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAwPGJyIGNsYXNzPSIi Pg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBCaWRpcmVjdGlvbmFs IEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIGluIFNlZ21lbnQgUm91dGluZyBOZXR3b3JrcyBV c2luZyBNUExTIERhdGFwbGFuZTxiciBjbGFzcz0iIj4NCkRvY3VtZW50IGRhdGU6Jm5ic3A7IDIw MTctMDUtMDg8YnIgY2xhc3M9IiI+DQpHcm91cDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxiciBjbGFzcz0iIj4NClBhZ2VzOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgNzxiciBjbGFzcz0iIj4NClVSTDombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAudHh0IiByZWw9 Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LTx3YnIgY2xhc3M9IiI+ZHJhZnRzL2RyYWZ0LW1pcnNreS1zcHJpbmctYmZk PHdiciBjbGFzcz0iIj4tMDAudHh0PC9hPjxiciBjbGFzcz0iIj4NClN0YXR1czombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQvIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdl dD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnLzx3YnIgY2xh c3M9IiI+ZG9jL2RyYWZ0LW1pcnNreS1zcHJpbmctYmZkLzwvYT48YnIgY2xhc3M9IiI+DQpIdG1s aXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAiIHJlbD0ibm9yZWZlcnJlciIg dGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kPHdi ciBjbGFzcz0iIj5yYWZ0LW1pcnNreS1zcHJpbmctYmZkLTAwPC9hPjxiciBjbGFzcz0iIj4NCkh0 bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAiIHJlbD0i bm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvPHdiciBjbGFzcz0iIj5kb2MvaHRtbC9kcmFmdC1taXJza3ktc3ByaW5nLWI8d2Jy IGNsYXNzPSIiPmZkLTAwPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCkFic3RyYWN0OjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtTZWdtZW50IFJvdXRp bmcgYXJjaGl0ZWN0dXJlIGxldmVyYWdlcyB0aGUgcGFyYWRpZ20gb2Ygc291cmNlPGJyIGNsYXNz PSIiPg0KJm5ic3A7ICZuYnNwO3JvdXRpbmcuJm5ic3A7IEl0IGNhbiBiZSByZWFsaXplZCBpbiB0 aGUgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmc8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5i c3A7KE1QTFMpIG5ldHdvcmsgd2l0aG91dCBhbnkgY2hhbmdlIHRvIHRoZSBkYXRhIHBsYW5lLiZu YnNwOyBBIHNlZ21lbnQgaXM8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ZW5jb2RlZCBhcyBh biBNUExTIGxhYmVsIGFuZCBhbiBvcmRlcmVkIGxpc3Qgb2Ygc2VnbWVudHMgaXMgZW5jb2RlZDxi ciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDthcyBhIHN0YWNrIG9mIGxhYmVscy4mbmJzcDsgQmlk aXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBpczxiciBjbGFzcz0iIj4NCiZu YnNwOyAmbmJzcDtleHBlY3RlZCB0byBtb25pdG9yIGFueSBraW5kIG9mIHBhdGhzIGJldHdlZW4g c3lzdGVtcy4mbmJzcDsgVGhpcyBkb2N1bWVudDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtk ZWZpbmVzIGhvdyB0byB1c2UgTGFiZWwgU3dpdGNoZWQgUGF0aCBQaW5nIHRvIGJvb3RzdHJhcCBh bmQgY29udHJvbDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtwYXRoIGluIHJldmVyc2UgZGly ZWN0aW9uIG9mIGEgQkZEIHNlc3Npb24gb24gdGhlIFNlZ21lbnQgUm91dGluZzxiciBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDtuZXR3b3JrIG92ZXIgTVBMUyBkYXRhcGxhbmUuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxiciBjbGFzcz0iIj4NCnVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnLyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQp0 b29scy5pZXRmLm9yZzwvYT4uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIElFVEYg U2VjcmV0YXJpYXQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPHdiciBjbGFzcz0iIj5fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4N Cm1wbHMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5tcGxzQGlldGYub3JnPC9hPjxiciBjbGFz cz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bDx3YnIgY2xhc3M9IiI+aXN0aW5mby9tcGxzPC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F1E0BFDF70724B2696BC4F47FE8FEDCBciscocom_-- From nobody Wed May 10 14:23:59 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5228B12969E; Wed, 10 May 2017 14:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yllkkmvxjcs6; Wed, 10 May 2017 14:23:49 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 3CD80128616; Wed, 10 May 2017 14:23:49 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id h4so9668819oib.3; Wed, 10 May 2017 14:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XmLmZFClzQl4W5En6nXjPzagHeKL0YyYwY/lRSR2smM=; b=DXpuEcSS0evaG1oIdEzzT2DsqoPkzukQuW5Kj2g+ClitogZZ0WL/SmuxofSC01g12B e9hbDaxqDiqTaTp6yrP3HstY7K5cYoJUTHSvwf1A4o3PiblnNNTIZubbgKrOTkLaJiQh Kd8fxs4FZ33K0S/3GRvqjubuFjzH4i7yHEcOnrnnlqCStaDK4PbqEBRDYpluQah/DLt+ L8WNXiIAKZdXAEXkCCRO/LDjHwYIBzW+EgasQwvkbKWe7vaViuO/fikUcaL7dT3zwvJC R3JaOnfPp0x6yl3rqWbHDBT+9OSqd+ZYGeg4RKK0Nz4L2UO2XY1iUoVMKarRMXmL+QKK JvNg== 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=XmLmZFClzQl4W5En6nXjPzagHeKL0YyYwY/lRSR2smM=; b=iXB5HrCN9cYIjGA915j0Ck1U5QPyCWRTmV2zsnTLTrQ7JYopFVmg0/RjMdiIpM3ujV iLwAInu8CMgn69cmfRh7OKaAvRqWzeDLs0c9teHBAgfzATXLaUTwOtN0QbtGo76LC1cN 4qeA08/MUOFjAgj97oyqzQs8guXeA9s2k7LGOnUAwzkUiaWkJ3PP/EAowfNIG//4cLea zp6Q+hyJ8UkTKfZ3hlGWc8jh+a1DYAu41Oba6XTVG3r0ggB8n2/gh4Zg/5iD80Z6J7kb KDalOM7hmOLNzNKAsSHRpVpq95+iZMECy5YxSmODg7K3WlUTZFZEI6H1oAH8qN5ZEefB c7wg== X-Gm-Message-State: AODbwcAYWur589ELpMPazCuIdW44fONZ7qszcvOAUK9e/VUZx9wRhrOK wLxdvLEqOm9rwkygwx66GY5rx/WmEw== X-Received: by 10.157.47.70 with SMTP id h64mr3909430otb.23.1494451428547; Wed, 10 May 2017 14:23:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.246 with HTTP; Wed, 10 May 2017 14:23:48 -0700 (PDT) In-Reply-To: References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> <9D886964-6C21-427C-8733-7731D5A996D3@cisco.com> From: Greg Mirsky Date: Wed, 10 May 2017 14:23:48 -0700 Message-ID: To: "Carlos Pignataro (cpignata)" Cc: Robert Raszuk , "mpls@ietf.org" , "spring@ietf.org" , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c04713888651a054f32160f Archived-At: Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 21:23:51 -0000 --94eb2c04713888651a054f32160f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, RFC 7110 defined sub-TLVs by extensively re-using TFS sub-TLVs. Even more, they've referenced explanations of fields to the TFS-defining RFCs. I guess only Flags field was introduced in RFC 7110 with Primary and Secondary bit flag fields being defined. As, I've said in the discussion on BFD directed, this is proposal, it make sense to me as the head-end has all the information already. I always welcome technical comments and appreciate well-argumented discussion. What would be the reason not to use the proposed approach but do it TFS-like style? Regards, Greg On Wed, May 10, 2017 at 1:01 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > You are right =E2=80=94 sorry about that! =E2=80=9CTFS=E2=80=9D is not us= ed in any of those RFCs > or drafts, although it is used on email discussions about LSP Ping. > > Indeed, TFS for =E2=80=9CTarget FEC Stack=E2=80=9D from Section 3.2 of RF= C 8029. > > Thanks, > > =E2=80=94 Carlos. > > On May 10, 2017, at 3:41 PM, Robert Raszuk wrote: > > > Never mind .. I guess you made it up from "Target FEC Stack" :) > > > > On Wed, May 10, 2017 at 9:40 PM, Robert Raszuk wrote: > >> Hi Carlos, >> >> Sorry what is "TFS" ? >> >> RFC 7110 does not even use such abbreviation neither do >> draft-ietf-mpls-bfd-directed :) Google also seems to be pretty clueless >> about it. >> >> Just curious as you keep using this term in each email :) >> >> Thx, >> R. >> >> On Wed, May 10, 2017 at 9:24 PM, Carlos Pignataro (cpignata) < >> cpignata@cisco.com> wrote: >> >>> Greg, >>> >>> In the MPLS data plane, FECs are also instantiated through a label >>> stack. But RFC 7110 does not use numeric label values, it uses TFSs. Th= at >>> does not create any additional state. E.g.,: https://www.ietf.org/ma >>> il-archive/web/mpls/current/msg16091.html >>> >>> Thanks, >>> >>> =E2=80=94 Carlos. >>> >>> >>> >>> On May 9, 2017, at 3:43 PM, Greg Mirsky wrote: >>> >>> Hi Carlos, >>> I probably would characterize anything that starts with Why not as a >>> technical comment but rather as a question. >>> According to draft-ietf-spring-segment-routing-mpls, "In the MPLS >>> dataplane,the SR header is instantiated through a label stack". >>> At the same time, one of advantages of SR is that "per-flow state only >>> [maintained] at the ingress node to the SR domain". >>> Thus, for the case of monitoring unidirectional SR tunnels, I consider >>> that there's no need to create any additional state on the egress node. >>> Of course, if there were bidirectional SR tunnels, then control of the >>> reverse direction of the BFD session would not require use of the Retur= n >>> Path sub-TLV. >>> As for LSP-Ping, I just propose that the Segment Routing MPLS Tunnel >>> sub-TLV MAY be used Reply Path TLV defined in RFC 7110. I viewed the >>> proposal as invitation to technical discussion. >>> >>> Regards, >>> Greg >>> >>> On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro (cpignata) < >>> cpignata@cisco.com> wrote: >>> >>>> Thank you Greg! >>>> >>>> Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems >>>> quite similar to the text removed at https://tools.ietf.org/rfcdiff >>>> ?url2=3Ddraft-ietf-mpls-bfd-directed-05.txt, then the complete set of >>>> outstanding technical comments that triggered the removal of that text= from >>>> draft-ietf-mpls-bfd-directed-05.txt might peek your interest :-) >>>> >>>> One that I recall is: why use label values when every other return-pat= h >>>> sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-direct= ed, >>>> uses TFSs? >>>> >>>> Best, >>>> >>>> =E2=80=94 Carlos. >>>> >>>> On May 9, 2017, at 12:00 PM, Greg Mirsky wrote= : >>>> >>>> Dear Carlos, >>>> I've decided to re-start the discussion and am interested to hear >>>> technical comments to the proposed solution. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro (cpignata) < >>>> cpignata@cisco.com> wrote: >>>> >>>>> Dear Greg, >>>>> >>>>> Cursorily scanning through this, it seems that most concerns raised >>>>> and comments made about the SR sections of draft-ietf-mpls-bfd-direct= ed-0N >>>>> (with N < 5) apply to your new draft. >>>>> >>>>> This is one of those: https://www.ietf.org/ma >>>>> il-archive/web/mpls/current/msg15860.html =E2=80=94 the list archive = shows a >>>>> few more. The copy/paste did not address the comments. >>>>> >>>>> Best, >>>>> >>>>> =E2=80=94 Carlos. >>>>> >>>>> On May 8, 2017, at 11:33 PM, Greg Mirsky >>>>> wrote: >>>>> >>>>> Dear All, >>>>> perhaps this new draft may is of interest to you. >>>>> Your comments, suggestions are most welcome and greatly appreciated. >>>>> >>>>> Regards, >>>>> Greg >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: >>>>> Date: Mon, May 8, 2017 at 8:29 PM >>>>> Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt >>>>> To: Gregory Mirsky >>>>> >>>>> >>>>> >>>>> A new version of I-D, draft-mirsky-spring-bfd-00.txt >>>>> has been successfully submitted by Greg Mirsky and posted to the >>>>> IETF repository. >>>>> >>>>> Name: draft-mirsky-spring-bfd >>>>> Revision: 00 >>>>> Title: Bidirectional Forwarding Detection (BFD) in Segment >>>>> Routing Networks Using MPLS Dataplane >>>>> Document date: 2017-05-08 >>>>> Group: Individual Submission >>>>> Pages: 7 >>>>> URL: https://www.ietf.org/internet- >>>>> drafts/draft-mirsky-spring-bfd-00.txt >>>>> Status: https://datatracker.ietf.org/ >>>>> doc/draft-mirsky-spring-bfd/ >>>>> Htmlized: https://tools.ietf.org/html/draft-mirsky-spring-bfd-0= 0 >>>>> Htmlized: https://datatracker.ietf.org/ >>>>> doc/html/draft-mirsky-spring-bfd-00 >>>>> >>>>> >>>>> Abstract: >>>>> Segment Routing architecture leverages the paradigm of source >>>>> routing. It can be realized in the Multiprotocol Label Switching >>>>> (MPLS) network without any change to the data plane. A segment is >>>>> encoded as an MPLS label and an ordered list of segments is encode= d >>>>> as a stack of labels. Bidirectional Forwarding Detection (BFD) is >>>>> expected to monitor any kind of paths between systems. This >>>>> document >>>>> defines how to use Label Switched Path Ping to bootstrap and contr= ol >>>>> path in reverse direction of a BFD session on the Segment Routing >>>>> network over MPLS dataplane. >>>>> >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > --94eb2c04713888651a054f32160f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos,
RFC 7110 defined sub-TLVs by extensively re= -using TFS sub-TLVs. Even more, they've referenced explanations of fiel= ds to the TFS-defining RFCs. I guess only Flags field was introduced in RFC= 7110 with Primary and Secondary bit flag fields being defined.
<= br>
As, I've said in the discussion on BFD directed, this is = proposal, it make sense to me as the head-end has all the information alrea= dy. I always welcome technical comments and appreciate well-argumented disc= ussion. What would be the reason not to use the proposed approach but do it= TFS-like style?

Regards,
Greg

On Wed, May 10,= 2017 at 1:01 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com>= wrote:
You are right =E2=80=94 sorry about that! =E2=80=9CTFS=E2=80=9D is not used= in any of those RFCs or drafts, although it is used on email discussions a= bout LSP Ping.

Indeed, TFS for =E2=80=9CTarget FEC Stack=E2=80=9D from Section 3.2 of= RFC=C2=A08029.

Thanks,

=E2=80=94 Carlos.

On May 10, 2017, at 3:41 PM, Robert Raszuk <robert@raszuk.net> wrote:


Never mind .. I guess you made it up from "Target FEC Stack" :)<= /div>



On Wed, May 10, 2017 at 9:40 PM, Robert Raszuk <= span dir=3D"ltr"> <robert@raszuk.ne= t> wrote:
Hi Carlos,

Sorry what is "TFS" ?=C2=A0

RFC 7110 does not even use such abbreviation neither do=C2=A0draft-ietf-mpls-bfd-directed=C2=A0:) Google also seems to be pretty clueless about it.=C2=A0<= /div>

Just curious as you keep using this term in each email :)=C2=A0

Thx,
R.

On Wed, May 10, 2017 at 9:24 PM, Carlos Pignatar= o (cpignata) <cpignata@cisco.com> wrote:
Greg,

In the MPLS data plane, FECs are also instantiated through a label sta= ck. But RFC 7110 does not use numeric label values, it uses TFSs. That does= not create any additional state. E.g.,:=C2=A0https://w= ww.ietf.org/mail-archive/web/mpls/current/msg16091.html

Thanks,

=E2=80=94 Carlos.



On May 9, 2017, at 3:43 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Carlos,
I probably would characterize anything that starts with Why not as a t= echnical comment but rather as a question.
According to=C2=A0draft-ietf-spring-segment-routing-mpls, "= In the MPLS=C2=A0dat= aplane,the SR head= er is instantiated through a label stack".
At the same time, one of advantages of SR is that &= quot;per-flow state only [maintained] at the ingress node to the SR=C2=A0domain".
Thus, for the case of monitoring uni= directional SR tunnels, I consider that there's no need to create any a= dditional state on the egress node.
Of course, if there were bidirection= al SR tunnels, then control of the reverse direction of the BFD session wou= ld not require use of the Return Path sub-TLV.
As for LSP-Ping, I just propose that= the Segment Routing MPLS Tunnel sub-TLV MAY be used Reply Path TLV defined= in RFC 7110. I viewed the proposal as invitation to technical discussion.=

Regards,
Greg

On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro= (cpignata) <cpignata@cisco.com> wrote:
Thank you Greg!

Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems quite= similar to the text removed at https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-bfd-directe= d-05.txt, then the complete set of outstanding technical comments that = triggered the removal of that text from draft-ietf-mpls-bfd-directed-0= 5.txt might peek your interest :-)

One that I recall is: why use label values when every other return-pat= h sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directed,= uses TFSs?=C2=A0

Best,

=E2=80=94 Carlos.

On May 9, 2017, at 12:00 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear Carlos,
I've decided to re-start the discussion and am interested to hear = technical comments to the proposed solution.=C2=A0

Regards,
Greg

On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro= (cpignata) <cpignata@cisco.com> wrote:
Dear Greg,

Cursorily scanning through this, it seems that most concerns raised an= d comments made about the SR sections of=C2=A0draft-ietf-mpls-bfd-directed-0N (with N < 5) apply to your new draft.

This is one of those:=C2=A0https://www.ietf.org/ma= il-archive/web/mpls/current/msg15860.html =E2=80=94 the list = archive shows a few more. The copy/paste did not address the comments.

Best,

=E2=80=94 Carlos.

On May 8, 2017, at 11:33 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear All,
perhaps this new draft may is of interest to you.
Your comments, suggestions are most welcome and greatly appreciated.

Regards,
Greg

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <gregimirsky@gmail.com>



A new version of I-D, draft-mirsky-spring-bfd-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-spring-bfd
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bidirectional Forwarding Detection= (BFD) in Segment Routing Networks Using MPLS Dataplane
Document date:=C2=A0 2017-05-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-spring-bfd-00.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-mirsky-spring-bfd-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-mirsky-spring-bfd-00<= /a>


Abstract:
=C2=A0 =C2=A0Segment Routing architecture leverages the paradigm of source<= br> =C2=A0 =C2=A0routing.=C2=A0 It can be realized in the Multiprotocol Label S= witching
=C2=A0 =C2=A0(MPLS) network without any change to the data plane.=C2=A0 A s= egment is
=C2=A0 =C2=A0encoded as an MPLS label and an ordered list of segments is en= coded
=C2=A0 =C2=A0as a stack of labels.=C2=A0 Bidirectional Forwarding Detection= (BFD) is
=C2=A0 =C2=A0expected to monitor any kind of paths between systems.=C2=A0 T= his document
=C2=A0 =C2=A0defines how to use Label Switched Path Ping to bootstrap and c= ontrol
=C2=A0 =C2=A0path in reverse direction of a BFD session on the Segment Rout= ing
=C2=A0 =C2=A0network over MPLS dataplane.




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

The IETF Secretariat


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls









--94eb2c04713888651a054f32160f-- From nobody Wed May 10 14:47:11 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CB412EAF8; Wed, 10 May 2017 14:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 7wOx3NkFB9O8; Wed, 10 May 2017 14:47:01 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC75A12EAF7; Wed, 10 May 2017 14:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12580; q=dns/txt; s=iport; t=1494452821; x=1495662421; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CZZz7Qo6X3DWhaUoCU9P1AhjSzYq80VtFiZavCivxvI=; b=hAmFCtsAum6v6Ekg+WIOSx87/AZHu6Vtp9+EZJ1zbHTiyT7uvaBPp2AX TXNhzNoRGxdMC0N3l8nw19NJI+Kqfs+huUdI63e6BFNjTHirP5GR6a+pW 0SOhFDsWb9S/kzQIh/Tc5bGhXe8CH6GMqoXwr96wnQCSMxgDiFU26vTcZ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAQBziRNZ/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHg2KKGJE3IXKHMY1Pgg8hC4V4AhqEaD8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQECAQEBIRE6CQIFCwIBCBEBAgECAQICJgICAh8GCxUCBggCBA4FG?= =?us-ascii?q?4luAw0IDrIugiaHLw2DOAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4VUgV4rC4I?= =?us-ascii?q?xNIJUTYETEQIBG4MOL4IxBYlEhl6GTYZgOwGHG4cshFOCBFWEZoNmhkaLLYR3K?= =?us-ascii?q?IN2AR84TDMLcBUcKhIBhGMcgWN2AYZdK4EDgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.38,321,1491264000"; d="scan'208";a="241919226" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 May 2017 21:46:59 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v4ALkx00009723 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 May 2017 21:46:59 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 10 May 2017 17:46:58 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 10 May 2017 17:46:58 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: Robert Raszuk , "mpls@ietf.org" , "spring@ietf.org" , "rtg-bfd@ietf.org" Thread-Topic: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt Thread-Index: AQHSyNwl4f82jzKO5Eq8Ccd1kzJOwKHsbA8AgAAB9QCAADyAAIABjQKAgAAEOwCAAACOgIAABY2AgAAW5gCAAAZ4gA== Date: Wed, 10 May 2017 21:46:58 +0000 Message-ID: <5AFE9872-1C3D-4FF1-8136-0074CBD7AB65@cisco.com> References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> <9D886964-6C21-427C-8733-7731D5A996D3@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.52] Content-Type: text/plain; charset="utf-8" Content-ID: <87381B06DDDDEE43A40CAD31C4E2C7C2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 21:47:03 -0000 R3JlZywNCg0KPiBPbiBNYXkgMTAsIDIwMTcsIGF0IDU6MjMgUE0sIEdyZWcgTWlyc2t5IDxncmVn aW1pcnNreUBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGkgQ2FybG9zLA0KPiBSRkMgNzExMCBk ZWZpbmVkIHN1Yi1UTFZzIGJ5IGV4dGVuc2l2ZWx5IHJlLXVzaW5nIFRGUyBzdWItVExWcy4gRXZl biBtb3JlLCB0aGV5J3ZlIHJlZmVyZW5jZWQgZXhwbGFuYXRpb25zIG9mIGZpZWxkcyB0byB0aGUg VEZTLWRlZmluaW5nIFJGQ3MuIEkgZ3Vlc3Mgb25seSBGbGFncyBmaWVsZCB3YXMgaW50cm9kdWNl ZCBpbiBSRkMgNzExMCB3aXRoIFByaW1hcnkgYW5kIFNlY29uZGFyeSBiaXQgZmxhZyBmaWVsZHMg YmVpbmcgZGVmaW5lZC4NCj4gDQo+IEFzLCBJJ3ZlIHNhaWQgaW4gdGhlIGRpc2N1c3Npb24gb24g QkZEIGRpcmVjdGVkLCB0aGlzIGlzIHByb3Bvc2FsLCBpdCBtYWtlIHNlbnNlIHRvIG1lIGFzIHRo ZSBoZWFkLWVuZCBoYXMgYWxsIHRoZSBpbmZvcm1hdGlvbiBhbHJlYWR5LiBJIGFsd2F5cyB3ZWxj b21lIHRlY2huaWNhbCBjb21tZW50cyBhbmQgYXBwcmVjaWF0ZSB3ZWxsLWFyZ3VtZW50ZWQgZGlz Y3Vzc2lvbi4NCg0KRnJvbSBteSBwZXJzcGVjdGl2ZSwgdGhlIHdlbGwgYXJndW1lbnQgZGlzY3Vz c2lvbiBhbHJlYWR5IGhhcHBlbmVkIG9uIHRoaXMgZXhhY3QgdGV4dCBhbmQgdGhpcyBwcm9wb3Nl ZCBhcHByb2FjaC4gVGhleSBoYXBwZW5lZCBhbHJlYWR5IHR3aWNlIG9uIG11bHRpcGxlIFdHTENz IGluIEJGRCwgYW5kIHRoYXQgdGV4dCB3YXMgcmVtb3ZlZC4gQXNraW5nIGFnYWluIHVuZGVyIGEg ZGlmZmVyZW50IGRyYWZ0IGZpbGVuYW1lIGRvZXMgbm90IGNoYW5nZSB0aGUgYXJndW1lbnRzIGFs cmVhZHkgcHJlc2VudGVkLg0KDQpUaGUgcHJvcG9zYWwgaXMgYnJva2VuLg0KDQo+IFdoYXQgd291 bGQgYmUgdGhlIHJlYXNvbiBub3QgdG8gdXNlIHRoZSBwcm9wb3NlZCBhcHByb2FjaCBidXQgZG8g aXQgVEZTLWxpa2Ugc3R5bGU/DQo+IA0KDQpZb3UgY2FuIHJlYWQgdGhlc2UgcmVhc29ucyBvbiB0 aGUgbGlzdCBhcmNoaXZlcyBvbiB0aGUgcHJldmlvdXMgZGlzY3Vzc2lvbi4gSSBhbnN3ZXJlZCB0 aGlzIHF1ZXN0aW9uIGFscmVhZHkuIEJ1dCwgZm9yIGNvbXBsZXRlbmVzczoNCg0KTGFiZWwgdmFs dWVzIGNhbiBjaGFuZ2UuIFdpdGggbGFiZWxzIHRoZXJlIGlzIG5vIHZhbGlkYXRpb24gcG9zc2li bGUgdGhhdCB3aGF0IGRpc3RyaWJ1dGVkIGJ5IGEgZ2l2ZW4gbGFiZWwgZGlzdHJpYnV0aW9uIHBy b3RvY29sIGlzIHdoYXQgaXMgbWVhbnQgaW4gdGhlIGRhdGEgcGxhbmUuIA0KDQpNb3JlIGltcG9y dGFudGx5LCBhZ2FpbiwgYSB0ZWNobmljYWwgZXhhbXBsZSBvZiB3aHkgdGhpcyBpcyBicm9rZW4g YW5kIGJhY2t3YXJkczoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1pcnNr eS1zcHJpbmctYmZkLTAwI3NlY3Rpb24tNCBzYXlzOg0KDQogICBUaGUgSUFOQSBpcyByZXF1ZXN0 ZWQgdG8gYXNzaWduIG5ldyBzdWItVExWIHR5cGUgZnJvbSAiTXVsdGlwcm90b2NvbA0KICAgTGFi ZWwgU3dpdGNoaW5nIEFyY2hpdGVjdHVyZSAoTVBMUykgTGFiZWwgU3dpdGNoZWQgUGF0aHMgKExT UHMpIFBpbmcNCiAgIFBhcmFtZXRlcnMgLSBUTFZzIiByZWdpc3RyeSwgIlN1Yi1UTFZzIGZvciBU TFYgVHlwZXMgMSwgMTYsIGFuZCAyMSINCiAgIHN1Yi1yZWdpc3RyeS4NCg0KICAgICArLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t Kw0KICAgICB8IFZhbHVlICAgfCBEZXNjcmlwdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICB8 IFJlZmVyZW5jZSAgICAgfA0KICAgICArLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KICAgICB8IFggKFRCRCkgfCBTZWdtZW50 IFJvdXRpbmcgTVBMUyBUdW5uZWwgc3ViLVRMViB8IFRoaXMgZG9jdW1lbnQgfA0KICAgICArLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tKw0KDQoNCk5vdywgVExWIFR5cGVzIDEsIDE2LCBhbmQgMjEgZm9yIE1QTFMgTFNQIFBpbmcg YXJlIA0KDQogICAgICAgICAxICAgVGFyZ2V0IEZFQyBTdGFjaw0KICAgICAgMTYgICAgUmV2ZXJz ZS1wYXRoIFRhcmdldCBGRUMgU3RhY2sNCiAgICAgIDIxICAgIFJlcGx5IFBhdGggDQoNCk1QTFMg TFNQIFBpbmcgVExWcyAxLCAxNiwgYW5kIDIxIG5lZWQgYSBzdWItVExWIHdpdGggYSBGRUMuIE5v dCB3aXRoIGEgTGFiZWwgdmFsdWUuIFRoYXQgaXMgd2h5LCBUTFYgMSBpcyBjYWxsZWQg4oCcVGFy Z2V0IEZFQyBTdGFja+KAnSAoc29tZXRpbWVzIHJlZmVycmVkIHRvIGluZm9ybWFsbHkgYXMgVEZT KQ0KDQpIb3dldmVyLCB5b3UgYXJlIGRlZmluaW5nIGEgcHJvdG9jb2wgc3RydWN0dXJlIHRoYXQg aG9sZHMgbnVtZXJpYyBMYWJlbCB2YWx1ZXMsIGFuZCB5b3Ugc29tZWhvdyB3YW50IHRoYXQgdG8g YmUgdXNlZCBpbiBUTFYgMSBmb3IgTVBMUyBMU1AgUGluZ+KApg0KDQpIb3cgZG8geW91IGVudmlz aW9uIHRoaXMgdG8gd29yayB3aXRoIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MDI5 I3NlY3Rpb24tMy4yPyANCg0KVGhhdCBpcyB5ZXQgYW5vdGhlciByZWFzb24gd2h5IEZFQ3MgYXJl IGJlaW5nIGRlZmluZWQgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1tcGxzLXNwcmluZy1sc3AtcGluZy0wMg0KDQpIb3BlIHRoYXQgaGVscHMsDQoNCuKAlCBDYXJs b3MuDQpQUzogQXMgSSBmaW5kIHRoaXMgcmVwZXRpdGl2ZSwgdGhpcyBpcyBteSBsYXN0IGVtYWls IG9uIHRoZSBzdWJqZWN0Lg0KDQoNCg0KPiBSZWdhcmRzLA0KPiBHcmVnDQo+IA0KPiBPbiBXZWQs IE1heSAxMCwgMjAxNyBhdCAxOjAxIFBNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgPGNw aWduYXRhQGNpc2NvLmNvbT4gd3JvdGU6DQo+IFlvdSBhcmUgcmlnaHQg4oCUIHNvcnJ5IGFib3V0 IHRoYXQhIOKAnFRGU+KAnSBpcyBub3QgdXNlZCBpbiBhbnkgb2YgdGhvc2UgUkZDcyBvciBkcmFm dHMsIGFsdGhvdWdoIGl0IGlzIHVzZWQgb24gZW1haWwgZGlzY3Vzc2lvbnMgYWJvdXQgTFNQIFBp bmcuDQo+IA0KPiBJbmRlZWQsIFRGUyBmb3Ig4oCcVGFyZ2V0IEZFQyBTdGFja+KAnSBmcm9tIFNl Y3Rpb24gMy4yIG9mIFJGQyA4MDI5Lg0KPiANCj4gVGhhbmtzLA0KPiANCj4g4oCUIENhcmxvcy4N Cj4gDQo+PiBPbiBNYXkgMTAsIDIwMTcsIGF0IDM6NDEgUE0sIFJvYmVydCBSYXN6dWsgPHJvYmVy dEByYXN6dWsubmV0PiB3cm90ZToNCj4+IA0KPj4gDQo+PiBOZXZlciBtaW5kIC4uIEkgZ3Vlc3Mg eW91IG1hZGUgaXQgdXAgZnJvbSAiVGFyZ2V0IEZFQyBTdGFjayIgOikNCj4+IA0KPj4gDQo+PiAN Cj4+IE9uIFdlZCwgTWF5IDEwLCAyMDE3IGF0IDk6NDAgUE0sIFJvYmVydCBSYXN6dWsgPHJvYmVy dEByYXN6dWsubmV0PiB3cm90ZToNCj4+IEhpIENhcmxvcywNCj4+IA0KPj4gU29ycnkgd2hhdCBp cyAiVEZTIiA/IA0KPj4gDQo+PiBSRkMgNzExMCBkb2VzIG5vdCBldmVuIHVzZSBzdWNoIGFiYnJl dmlhdGlvbiBuZWl0aGVyIGRvIGRyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZWQgOikgR29vZ2xl IGFsc28gc2VlbXMgdG8gYmUgcHJldHR5IGNsdWVsZXNzIGFib3V0IGl0LiANCj4+IA0KPj4gSnVz dCBjdXJpb3VzIGFzIHlvdSBrZWVwIHVzaW5nIHRoaXMgdGVybSBpbiBlYWNoIGVtYWlsIDopIA0K Pj4gDQo+PiBUaHgsDQo+PiBSLg0KPj4gDQo+PiBPbiBXZWQsIE1heSAxMCwgMjAxNyBhdCA5OjI0 IFBNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNpc2NvLmNvbT4gd3Jv dGU6DQo+PiBHcmVnLA0KPj4gDQo+PiBJbiB0aGUgTVBMUyBkYXRhIHBsYW5lLCBGRUNzIGFyZSBh bHNvIGluc3RhbnRpYXRlZCB0aHJvdWdoIGEgbGFiZWwgc3RhY2suIEJ1dCBSRkMgNzExMCBkb2Vz IG5vdCB1c2UgbnVtZXJpYyBsYWJlbCB2YWx1ZXMsIGl0IHVzZXMgVEZTcy4gVGhhdCBkb2VzIG5v dCBjcmVhdGUgYW55IGFkZGl0aW9uYWwgc3RhdGUuIEUuZy4sOiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cxNjA5MS5odG1sDQo+PiANCj4+IFRo YW5rcywNCj4+IA0KPj4g4oCUIENhcmxvcy4NCj4+IA0KPj4gDQo+PiANCj4+PiBPbiBNYXkgOSwg MjAxNywgYXQgMzo0MyBQTSwgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT4gd3Jv dGU6DQo+Pj4gDQo+Pj4gSGkgQ2FybG9zLA0KPj4+IEkgcHJvYmFibHkgd291bGQgY2hhcmFjdGVy aXplIGFueXRoaW5nIHRoYXQgc3RhcnRzIHdpdGggV2h5IG5vdCBhcyBhIHRlY2huaWNhbCBjb21t ZW50IGJ1dCByYXRoZXIgYXMgYSBxdWVzdGlvbi4NCj4+PiBBY2NvcmRpbmcgdG8gZHJhZnQtaWV0 Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMsICJJbiB0aGUgTVBMUyBkYXRhcGxhbmUsdGhl IFNSIGhlYWRlciBpcyBpbnN0YW50aWF0ZWQgdGhyb3VnaCBhIGxhYmVsIHN0YWNrIi4NCj4+PiBB dCB0aGUgc2FtZSB0aW1lLCBvbmUgb2YgYWR2YW50YWdlcyBvZiBTUiBpcyB0aGF0ICJwZXItZmxv dyBzdGF0ZSBvbmx5IFttYWludGFpbmVkXSBhdCB0aGUgaW5ncmVzcyBub2RlIHRvIHRoZSBTUiBk b21haW4iLg0KPj4+IFRodXMsIGZvciB0aGUgY2FzZSBvZiBtb25pdG9yaW5nIHVuaWRpcmVjdGlv bmFsIFNSIHR1bm5lbHMsIEkgY29uc2lkZXIgdGhhdCB0aGVyZSdzIG5vIG5lZWQgdG8gY3JlYXRl IGFueSBhZGRpdGlvbmFsIHN0YXRlIG9uIHRoZSBlZ3Jlc3Mgbm9kZS4NCj4+PiBPZiBjb3Vyc2Us IGlmIHRoZXJlIHdlcmUgYmlkaXJlY3Rpb25hbCBTUiB0dW5uZWxzLCB0aGVuIGNvbnRyb2wgb2Yg dGhlIHJldmVyc2UgZGlyZWN0aW9uIG9mIHRoZSBCRkQgc2Vzc2lvbiB3b3VsZCBub3QgcmVxdWly ZSB1c2Ugb2YgdGhlIFJldHVybiBQYXRoIHN1Yi1UTFYuDQo+Pj4gQXMgZm9yIExTUC1QaW5nLCBJ IGp1c3QgcHJvcG9zZSB0aGF0IHRoZSBTZWdtZW50IFJvdXRpbmcgTVBMUyBUdW5uZWwgc3ViLVRM ViBNQVkgYmUgdXNlZCBSZXBseSBQYXRoIFRMViBkZWZpbmVkIGluIFJGQyA3MTEwLiBJIHZpZXdl ZCB0aGUgcHJvcG9zYWwgYXMgaW52aXRhdGlvbiB0byB0ZWNobmljYWwgZGlzY3Vzc2lvbi4NCj4+ PiANCj4+PiBSZWdhcmRzLA0KPj4+IEdyZWcNCj4+PiANCj4+PiBPbiBUdWUsIE1heSA5LCAyMDE3 IGF0IDk6MDcgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lzY28u Y29tPiB3cm90ZToNCj4+PiBUaGFuayB5b3UgR3JlZyENCj4+PiANCj4+PiBTaW5jZSBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAgc2VlbXMgcXVp dGUgc2ltaWxhciB0byB0aGUgdGV4dCByZW1vdmVkIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZWQtMDUudHh0LCB0aGVuIHRo ZSBjb21wbGV0ZSBzZXQgb2Ygb3V0c3RhbmRpbmcgdGVjaG5pY2FsIGNvbW1lbnRzIHRoYXQgdHJp Z2dlcmVkIHRoZSByZW1vdmFsIG9mIHRoYXQgdGV4dCBmcm9tIGRyYWZ0LWlldGYtbXBscy1iZmQt ZGlyZWN0ZWQtMDUudHh0IG1pZ2h0IHBlZWsgeW91ciBpbnRlcmVzdCA6LSkNCj4+PiANCj4+PiBP bmUgdGhhdCBJIHJlY2FsbCBpczogd2h5IHVzZSBsYWJlbCB2YWx1ZXMgd2hlbiBldmVyeSBvdGhl ciByZXR1cm4tcGF0aCBzdWItVExWIGZvciBCRkQgYW5kIGZvciBMU1AtUGluZywgaW5jbHVkaW5n IGRyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZWQsIHVzZXMgVEZTcz8gDQo+Pj4gDQo+Pj4gQmVz dCwNCj4+PiANCj4+PiDigJQgQ2FybG9zLg0KPj4+IA0KPj4+PiBPbiBNYXkgOSwgMjAxNywgYXQg MTI6MDAgUE0sIEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb20+IHdyb3RlOg0KPj4+ PiANCj4+Pj4gRGVhciBDYXJsb3MsDQo+Pj4+IEkndmUgZGVjaWRlZCB0byByZS1zdGFydCB0aGUg ZGlzY3Vzc2lvbiBhbmQgYW0gaW50ZXJlc3RlZCB0byBoZWFyIHRlY2huaWNhbCBjb21tZW50cyB0 byB0aGUgcHJvcG9zZWQgc29sdXRpb24uIA0KPj4+PiANCj4+Pj4gUmVnYXJkcywNCj4+Pj4gR3Jl Zw0KPj4+PiANCj4+Pj4gT24gVHVlLCBNYXkgOSwgMjAxNyBhdCA4OjUxIEFNLCBDYXJsb3MgUGln bmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+IERlYXIg R3JlZywNCj4+Pj4gDQo+Pj4+IEN1cnNvcmlseSBzY2FubmluZyB0aHJvdWdoIHRoaXMsIGl0IHNl ZW1zIHRoYXQgbW9zdCBjb25jZXJucyByYWlzZWQgYW5kIGNvbW1lbnRzIG1hZGUgYWJvdXQgdGhl IFNSIHNlY3Rpb25zIG9mIGRyYWZ0LWlldGYtbXBscy1iZmQtZGlyZWN0ZWQtME4gKHdpdGggTiA8 IDUpIGFwcGx5IHRvIHlvdXIgbmV3IGRyYWZ0Lg0KPj4+PiANCj4+Pj4gVGhpcyBpcyBvbmUgb2Yg dGhvc2U6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbXBscy9jdXJyZW50 L21zZzE1ODYwLmh0bWwg4oCUIHRoZSBsaXN0IGFyY2hpdmUgc2hvd3MgYSBmZXcgbW9yZS4gVGhl IGNvcHkvcGFzdGUgZGlkIG5vdCBhZGRyZXNzIHRoZSBjb21tZW50cy4NCj4+Pj4gDQo+Pj4+IEJl c3QsDQo+Pj4+IA0KPj4+PiDigJQgQ2FybG9zLg0KPj4+PiANCj4+Pj4+IE9uIE1heSA4LCAyMDE3 LCBhdCAxMTozMyBQTSwgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT4gd3JvdGU6 DQo+Pj4+PiANCj4+Pj4+IERlYXIgQWxsLA0KPj4+Pj4gcGVyaGFwcyB0aGlzIG5ldyBkcmFmdCBt YXkgaXMgb2YgaW50ZXJlc3QgdG8geW91Lg0KPj4+Pj4gWW91ciBjb21tZW50cywgc3VnZ2VzdGlv bnMgYXJlIG1vc3Qgd2VsY29tZSBhbmQgZ3JlYXRseSBhcHByZWNpYXRlZC4NCj4+Pj4+IA0KPj4+ Pj4gUmVnYXJkcywNCj4+Pj4+IEdyZWcNCj4+Pj4+IA0KPj4+Pj4gLS0tLS0tLS0tLSBGb3J3YXJk ZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQo+Pj4+PiBGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPg0KPj4+Pj4gRGF0ZTogTW9uLCBNYXkgOCwgMjAxNyBhdCA4OjI5IFBNDQo+Pj4+PiBTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1pcnNreS1zcHJpbmctYmZk LTAwLnR4dA0KPj4+Pj4gVG86IEdyZWdvcnkgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb20+ DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtbWlyc2t5LXNwcmluZy1iZmQtMDAudHh0DQo+Pj4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhlDQo+Pj4+PiBJRVRGIHJl cG9zaXRvcnkuDQo+Pj4+PiANCj4+Pj4+IE5hbWU6ICAgICAgICAgICBkcmFmdC1taXJza3ktc3By aW5nLWJmZA0KPj4+Pj4gUmV2aXNpb246ICAgICAgIDAwDQo+Pj4+PiBUaXRsZTogICAgICAgICAg QmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBpbiBTZWdtZW50IFJvdXRp bmcgTmV0d29ya3MgVXNpbmcgTVBMUyBEYXRhcGxhbmUNCj4+Pj4+IERvY3VtZW50IGRhdGU6ICAy MDE3LTA1LTA4DQo+Pj4+PiBHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ Pj4+PiBQYWdlczogICAgICAgICAgNw0KPj4+Pj4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1taXJza3ktc3ByaW5nLWJmZC0wMC50eHQN Cj4+Pj4+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1taXJza3ktc3ByaW5nLWJmZC8NCj4+Pj4+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQtMDANCj4+Pj4+IEh0bWxp emVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW1p cnNreS1zcHJpbmctYmZkLTAwDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+ PiAgICBTZWdtZW50IFJvdXRpbmcgYXJjaGl0ZWN0dXJlIGxldmVyYWdlcyB0aGUgcGFyYWRpZ20g b2Ygc291cmNlDQo+Pj4+PiAgICByb3V0aW5nLiAgSXQgY2FuIGJlIHJlYWxpemVkIGluIHRoZSBN dWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZw0KPj4+Pj4gICAgKE1QTFMpIG5ldHdvcmsgd2l0 aG91dCBhbnkgY2hhbmdlIHRvIHRoZSBkYXRhIHBsYW5lLiAgQSBzZWdtZW50IGlzDQo+Pj4+PiAg ICBlbmNvZGVkIGFzIGFuIE1QTFMgbGFiZWwgYW5kIGFuIG9yZGVyZWQgbGlzdCBvZiBzZWdtZW50 cyBpcyBlbmNvZGVkDQo+Pj4+PiAgICBhcyBhIHN0YWNrIG9mIGxhYmVscy4gIEJpZGlyZWN0aW9u YWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMNCj4+Pj4+ICAgIGV4cGVjdGVkIHRvIG1v bml0b3IgYW55IGtpbmQgb2YgcGF0aHMgYmV0d2VlbiBzeXN0ZW1zLiAgVGhpcyBkb2N1bWVudA0K Pj4+Pj4gICAgZGVmaW5lcyBob3cgdG8gdXNlIExhYmVsIFN3aXRjaGVkIFBhdGggUGluZyB0byBi b290c3RyYXAgYW5kIGNvbnRyb2wNCj4+Pj4+ICAgIHBhdGggaW4gcmV2ZXJzZSBkaXJlY3Rpb24g b2YgYSBCRkQgc2Vzc2lvbiBvbiB0aGUgU2VnbWVudCBSb3V0aW5nDQo+Pj4+PiAgICBuZXR3b3Jr IG92ZXIgTVBMUyBkYXRhcGxhbmUuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+ Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4+Pj4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+Pj4+PiANCj4+Pj4+ IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IG1wbHMgbWFpbGluZyBs aXN0DQo+Pj4+PiBtcGxzQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCj4+Pj4gDQo+Pj4+IA0KPj4+IA0KPj4+IA0KPj4gDQo+PiANCj4+ IA0KPiANCj4gDQoNCg== From nobody Wed May 10 23:29:22 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F26128CD5; Wed, 10 May 2017 23:29:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even To: Cc: mpls@ietf.org, draft-ietf-mpls-tp-aps-updates.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149448416047.16649.7655814250953782130@ietfa.amsl.com> Date: Wed, 10 May 2017 23:29:20 -0700 Archived-At: Subject: [mpls] Genart last call review of draft-ietf-mpls-tp-aps-updates-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 06:29:20 -0000 Reviewer: Roni Even Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-mpls-tp-aps-updates-?? Reviewer: Roni Even Review Date: 2017-05-10 IETF LC End Date: 2017-05-19 IESG Telechat date: 2017-05-25 Summary: The document is ready for publication as a standard track RFC Major issues: Minor issues: Nits/editorial comments: From nobody Thu May 11 07:12:38 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6030B1314C5; Thu, 11 May 2017 07:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFFeE1pe30VQ; Thu, 11 May 2017 07:12:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF28E129AC7; Thu, 11 May 2017 07:05:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMS65534; Thu, 11 May 2017 14:05:47 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.201.109.59]) by LHREML712-CAH.china.huawei.com ([10.201.108.35]) with mapi id 14.03.0301.000; Thu, 11 May 2017 15:05:43 +0100 From: Italo Busi To: "ietf@ietf.org" CC: "mpls@ietf.org" , "draft-ietf-mpls-tp-shared-ring-protection@ietf.org" Thread-Topic: Last Call: (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard Thread-Index: AQHSwFHT6RfRe34k+0+8cXprdYx99aHvEoSQ Date: Thu, 11 May 2017 14:05:42 +0000 Message-ID: <91E3A1BD737FDF4FA14118387FF6766B157346F2@lhreml504-mbs> References: <149339519935.2881.8322243003635696392.idtracker@ietfa.amsl.com> In-Reply-To: <149339519935.2881.8322243003635696392.idtracker@ietfa.amsl.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.243.209] 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.0A020205.59146FBC.02BE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2308c4b72cc3415953b99e51bfb7d306 Archived-At: Subject: Re: [mpls] Last Call: (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 14:12:14 -0000 SSB0aGluayB0aGUgZHJhZnQgaXMgcmVhZHkgdG8gYmUgcHVibGlzaGVkLg0KDQpJIGhhdmUgcmVj ZW50bHkgZGlzY3Vzc2VkIHdpdGggc29tZSBhdXRob3JzIG9mIHRoZSBkcmFmdCBzb21lIHF1ZXN0 aW9ucyBmb3IgY2xhcmlmaWNhdGlvbiBhbmQgaXQgbWlnaHQgYmUgd29ydGh3aGlsZSBjb25zaWRl cmluZyBtaW5vciB0ZXh0IGNoYW5nZXMgcHJvcG9zZWQgYmVsb3cgdG8gZnVydGhlciBpbXByb3Zl IHRleHQgY2xhcml0eS4NCg0KMSkgU2VjdGlvbiA0LjMuMS4yIGFuZCA0LjMuMi4yDQoNClRoZSB0 ZXh0IGRlc2NyaWJpbmcgZWdyZXNzIG5vZGUgZmFpbHVyZXMgaW1wbHkgdGhhdCwgYWxzbyBpbiBj YXNlIG9mIHdyYXBwaW5nIGFuZCBzaG9ydC13cmFwcGluZywgdGhlIGluZ3Jlc3Mgbm9kZSwgd2hl biBub3RpZmllZCAoYnkgUlBTKSBhYm91dCBlZ3Jlc3Mgbm9kZSBmYWlsdXJlLCB3aWxsIG5vdCBz ZW5kIHRyYWZmaWMgdG8gZWl0aGVyIHRoZSB3b3JraW5nIG9yIHRoZSBwcm90ZWN0aW9uIHR1bm5l bCAobGlrZSBpdCBkb2VzIHdpdGggc3RlZXJpbmcgcHJvdGVjdGlvbikuIEl0IG1pZ2h0IGJlIHdv cnRod2hpbGUgYWRkaW5nIHNvbWUgZXhwbGljaXQgdGV4dA0KDQpPTEQgVEVYVCAoU2VjdGlvbiA0 LjMuMS4yKQ0KICAgSW4gb25lIHNwZWNpYWwgY2FzZSB3aGVyZSBub2RlIEQgZmFpbHMsIGFsbCB0 aGUgcmluZyB0dW5uZWxzIHdpdGgNCiAgIG5vZGUgRCBhcyBlZ3Jlc3Mgd2lsbCBiZWNvbWUgdW51 c2FibGUuIEhvd2V2ZXIsIGJlZm9yZSB0aGUgZmFpbHVyZQ0KICAgbG9jYXRpb24gaW5mb3JtYXRp b24gaXMgcHJvcGFnYXRlZCB0byBhbGwgdGhlIHJpbmcgbm9kZXMsIHRoZQ0KICAgd3JhcHBpbmcg cHJvdGVjdGlvbiBtZWNoYW5pc20gbWF5IGNhdXNlIHRlbXBvcmFyeSB0cmFmZmljIGxvb3A6DQoN Ck5FVyBURVhUIChTZWN0aW9uIDQuMy4xLjIpDQogICBJbiBvbmUgc3BlY2lhbCBjYXNlIHdoZXJl IG5vZGUgRCBmYWlscywgYWxsIHRoZSByaW5nIHR1bm5lbHMgd2l0aA0KICAgbm9kZSBEIGFzIGVn cmVzcyB3aWxsIGJlY29tZSB1bnVzYWJsZS4gVGhlIGluZ3Jlc3Mgbm9kZSB3aWxsIHVwZGF0ZSBp dHMgcmluZyBtYXAgYWNjb3JkaW5nIHRvIHJlY2VpdmVkIFJQUyBtZXNzYWdlcyBhbmQgZGV0ZXJt aW5lIHRoYXQgdGhlIGVncmVzcyBub2RlIGlzIG5vdCByZWFjaGFibGUgdGh1cyBpdCB3aWxsIG5v dCBzZW5kIHRyYWZmaWMgdG8gZWl0aGVyIHRoZSB3b3JraW5nIG9yIHRoZSBwcm90ZWN0aW9uIHR1 bm5lbC4gSG93ZXZlciwgYmVmb3JlIHRoZSBmYWlsdXJlDQogICBsb2NhdGlvbiBpbmZvcm1hdGlv biBpcyBwcm9wYWdhdGVkIHRvIGFsbCB0aGUgcmluZyBub2RlcywgdGhlDQogICB3cmFwcGluZyBw cm90ZWN0aW9uIG1lY2hhbmlzbSBtYXkgY2F1c2UgdGVtcG9yYXJ5IHRyYWZmaWMgbG9vcDoNCg0K T0xEIFRFWFQgKFNlY3Rpb24gNC4zLjIuMikNCiAgIDwuLi4+IFdoZW4gbm9kZSBEDQogICBmYWls cywgdHJhZmZpYyBvZiBMU1AxIGNhbm5vdCBiZSBwcm90ZWN0ZWQgYnkgYW55IHJpbmcgdHVubmVs cyB3aGljaA0KICAgdXNlIG5vZGUgRCBhcyB0aGUgZWdyZXNzIG5vZGUuICBIb3dldmVyLCBiZWZv cmUgdGhlIGZhaWx1cmUgbG9jYXRpb24NCiAgIGluZm9ybWF0aW9uIGlzIHByb3BhZ2F0ZWQgdG8g YWxsIHRoZSByaW5nIG5vZGVzIHVzaW5nIHRoZSBSUFMNCiAgIHByb3RvY29sLCBub2RlIEMgc3dp dGNoZXMgYWxsIHRoZSB0cmFmZmljIG9uIHRoZSB3b3JraW5nIHJpbmcgdHVubmVsIA0KICAgPC4u Lj4NCg0KTkVXIFRFWFQgKFNlY3Rpb24gNC4zLjIuMikNCiAgIDwuLi4+IFdoZW4gbm9kZSBEDQog ICBmYWlscywgdHJhZmZpYyBvZiBMU1AxIGNhbm5vdCBiZSBwcm90ZWN0ZWQgYnkgYW55IHJpbmcg dHVubmVscyB3aGljaA0KICAgdXNlIG5vZGUgRCBhcyB0aGUgZWdyZXNzIG5vZGUuIFRoZSBpbmdy ZXNzIG5vZGUgd2lsbCB1cGRhdGUgaXRzIHJpbmcgbWFwIGFjY29yZGluZyB0byByZWNlaXZlZCBS UFMgbWVzc2FnZXMgYW5kIGRldGVybWluZSB0aGF0IHRoZSBlZ3Jlc3Mgbm9kZSBpcyBub3QgcmVh Y2hhYmxlIHRodXMgaXQgd2lsbCBub3Qgc2VuZCB0cmFmZmljIHRvIGVpdGhlciB0aGUgd29ya2lu ZyBvciB0aGUgcHJvdGVjdGlvbiB0dW5uZWwuIEhvd2V2ZXIsIGJlZm9yZSB0aGUgZmFpbHVyZSBs b2NhdGlvbg0KICAgaW5mb3JtYXRpb24gaXMgcHJvcGFnYXRlZCB0byBhbGwgdGhlIHJpbmcgbm9k ZXMgdXNpbmcgdGhlIFJQUw0KICAgcHJvdG9jb2wsIG5vZGUgQyBzd2l0Y2hlcyBhbGwgdGhlIHRy YWZmaWMgb24gdGhlIHdvcmtpbmcgcmluZyB0dW5uZWwgDQogICA8Li4uPg0KDQoyKSAgU2VjdGlv biA0LjMuMg0KDQpXaXRoIHNob3J0LXdyYXBwaW5nIHRoZSB0d28gdHJhZmZpYyBkaXJlY3Rpb25z IG9mIHByb3RlY3RlZCBMU1BzIGFyZSBubyBsb25nZXIgY28tcm91dGVkIHVuZGVyIHByb3RlY3Rp b24gc3dpdGNoaW5nIGNvbmRpdGlvbnMuIFRoaXMgc2hvdWxkIGJlIG1lbnRpb25lZC4NCg0KT0xE IFRFWFQNCiAgIFdpdGggc2hvcnQgd3JhcHBpbmcgcHJvdGVjdGlvbiwgZGF0YSB0cmFmZmljIHN3 aXRjaGluZyBpcyBleGVjdXRlZA0KICAgb25seSBhdCB0aGUgbm9kZSB1cHN0cmVhbSB0byB0aGUg ZmFpbHVyZSwgYW5kIGRhdGEgdHJhZmZpYyBsZWF2ZXMgdGhlDQogICByaW5nIGluIHRoZSBwcm90 ZWN0aW9uIHJpbmcgdHVubmVsIGF0IHRoZSBlZ3Jlc3Mgbm9kZS4gIFRoaXMgc2NoZW1lDQogICBj YW4gcmVkdWNlIHRoZSBhZGRpdGlvbmFsIGxhdGVuY3kgYW5kIGJhbmR3aWR0aCBjb25zdW1wdGlv biB3aGVuDQogICB0cmFmZmljIGlzIHN3aXRjaGVkIHRvIHRoZSBwcm90ZWN0aW9uIHBhdGguDQoN Ck5FVyBURVhUDQogICBXaXRoIHNob3J0IHdyYXBwaW5nIHByb3RlY3Rpb24sIGRhdGEgdHJhZmZp YyBzd2l0Y2hpbmcgaXMgZXhlY3V0ZWQNCiAgIG9ubHkgYXQgdGhlIG5vZGUgdXBzdHJlYW0gdG8g dGhlIGZhaWx1cmUsIGFuZCBkYXRhIHRyYWZmaWMgbGVhdmVzIHRoZQ0KICAgcmluZyBpbiB0aGUg cHJvdGVjdGlvbiByaW5nIHR1bm5lbCBhdCB0aGUgZWdyZXNzIG5vZGUuICBUaGlzIHNjaGVtZQ0K ICAgY2FuIHJlZHVjZSB0aGUgYWRkaXRpb25hbCBsYXRlbmN5IGFuZCBiYW5kd2lkdGggY29uc3Vt cHRpb24gd2hlbg0KICAgdHJhZmZpYyBpcyBzd2l0Y2hlZCB0byB0aGUgcHJvdGVjdGlvbiBwYXRo LiBIb3dldmVyIHRoZSB0d28gZGlyZWN0aW9ucyBvZiBhIHByb3RlY3RlZCBiaWRpcmVjdGlvbmFs IExTUCBhcmUgbm8gbG9uZ2VyIGNvLXJvdXRlZCB1bmRlciBwcm90ZWN0aW9uIHN3aXRjaGluZyBj b25kaXRpb25zLg0KDQozKSBTZWN0aW9uIDQuMy4yDQoNClRoZSBkaWZmZXJlbmNlIGJldHdlZW4g d3JhcHBpbmcgYW5kIHNob3J0LXdyYXBwaW5nIGlzIGluIHRoZSB3YXkgcHJvdGVjdGlvbiB0dW5u ZWwgaXMgY29uZmlndXJlZC4NCg0KT0xEIFRFWFQNCiAgIEluIHRoZSB0cmFkaXRpb25hbCB3cmFw cGluZyBzb2x1dGlvbiwgaW4gbm9ybWFsIHN0YXRlIHRoZSBwcm90ZWN0aW9uDQogICByaW5nIHR1 bm5lbCBpcyBhIGNsb3NlZCByaW5nLCB3aGlsZSBpbiB0aGUgc2hvcnQgd3JhcHBpbmcgc29sdXRp b24sDQogICB0aGUgcHJvdGVjdGlvbiByaW5nIHR1bm5lbCBpcyBlbmRlZCBhdCB0aGUgZWdyZXNz IG5vZGUsIHdoaWNoIGlzDQogICBzaW1pbGFyIHRvIHRoZSB3b3JraW5nIHJpbmcgdHVubmVsLg0K DQpORVcgVEVYVA0KICAgSW4gdGhlIHRyYWRpdGlvbmFsIHdyYXBwaW5nIHNvbHV0aW9uLCB0aGUg cHJvdGVjdGlvbg0KICAgcmluZyB0dW5uZWwgaXMgY29uZmlndXJlZCBhcyBhIGNsb3NlZCByaW5n LCB3aGlsZSBpbiB0aGUgc2hvcnQgd3JhcHBpbmcgc29sdXRpb24sDQogICB0aGUgcHJvdGVjdGlv biByaW5nIHR1bm5lbCBpcyBjb25maWd1cmVkIGFzIGVuZGVkIGF0IHRoZSBlZ3Jlc3Mgbm9kZSwg d2hpY2ggaXMNCiAgIHNpbWlsYXIgdG8gdGhlIHdvcmtpbmcgcmluZyB0dW5uZWwuDQoNClRoYW5r cywgSXRhbG8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRoZSBJRVNHIFtt YWlsdG86aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmddIA0KU2VudDogc2FiYXRvIDI5IGFwcmlsZSAy MDE3IDAwOjAwDQpUbzogSUVURi1Bbm5vdW5jZQ0KQ2M6IG1wbHNAaWV0Zi5vcmc7IGRiMzU0NkBh dHQuY29tOyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXRwLXNoYXJlZC1y aW5nLXByb3RlY3Rpb25AaWV0Zi5vcmc7IEVyaWMgR3JheTsgRXJpYy5HcmF5QEVyaWNzc29uLmNv bQ0KU3ViamVjdDogTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1tcGxzLXRwLXNoYXJlZC1yaW5nLXBy b3RlY3Rpb24tMDUudHh0PiAoU2hhcmVkLVJpbmcgcHJvdGVjdGlvbiAoTVNSUCkgbWVjaGFuaXNt IGZvciByaW5nIHRvcG9sb2d5KSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KDQoNClRoZSBJRVNHIGhh cyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hp bmcgV0cNCihtcGxzKSB0byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KLSAnU2hh cmVkLVJpbmcgcHJvdGVjdGlvbiAoTVNSUCkgbWVjaGFuaXNtIGZvciByaW5nIHRvcG9sb2d5Jw0K ICA8ZHJhZnQtaWV0Zi1tcGxzLXRwLXNoYXJlZC1yaW5nLXByb3RlY3Rpb24tMDUudHh0PiBhcyBQ cm9wb3NlZCBTdGFuZGFyZA0KDQpUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4g dGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNpdHMgZmluYWwgY29tbWVudHMgb24gdGhpcyBh Y3Rpb24uIFBsZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZSBpZXRmQGlldGYu b3JnIG1haWxpbmcgbGlzdHMgYnkgMjAxNy0wNS0xMi4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMg bWF5IGJlIHNlbnQgdG8gaWVzZ0BpZXRmLm9yZyBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxl YXNlIHJldGFpbiB0aGUgYmVnaW5uaW5nIG9mIHRoZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0 b21hdGVkIHNvcnRpbmcuDQoNCkFic3RyYWN0DQoNCg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgcmVxdWlyZW1lbnRzLCBhcmNoaXRlY3R1cmUgYW5kIHNvbHV0aW9ucyBmb3INCiAgIE1QTFMt VFAgU2hhcmVkIFJpbmcgUHJvdGVjdGlvbiAoTVNSUCkgaW4gYSByaW5nIHRvcG9sb2d5IGZvciBw b2ludC0NCiAgIHRvLXBvaW50IChQMlApIHNlcnZpY2VzLiAgVGhlIE1TUlAgbWVjaGFuaXNtIGlz IGRlc2NyaWJlZCB0byBtZWV0IHRoZQ0KICAgcmluZyBwcm90ZWN0aW9uIHJlcXVpcmVtZW50cyBh cyBkZXNjcmliZWQgaW4gUkZDIDU2NTQuICBUaGlzIGRvY3VtZW50DQogICBkZWZpbmVzIHRoZSBS aW5nIFByb3RlY3Rpb24gU3dpdGNoIChSUFMpIFByb3RvY29sIHRoYXQgaXMgdXNlZCB0bw0KICAg Y29vcmRpbmF0ZSB0aGUgcHJvdGVjdGlvbiBiZWhhdmlvciBvZiB0aGUgbm9kZXMgb24gTVBMUyBy aW5nLg0KDQoNCg0KDQoNClRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWENCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy10cC1zaGFyZWQtcmluZy1wcm90 ZWN0aW9uLw0KDQpJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtdHAtc2hhcmVkLXJpbmctcHJv dGVjdGlvbi9iYWxsb3QvDQoNClRoZSBmb2xsb3dpbmcgSVBSIERlY2xhcmF0aW9ucyBtYXkgYmUg cmVsYXRlZCB0byB0aGlzIEktRDoNCg0KICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9p cHIvMjY4MC8NCiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzI2ODEvDQogICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yNjgyLw0KICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9pcHIvMjY4My8NCg0KDQoNCg0KDQoNCg== From nobody Thu May 11 08:11:58 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B281129B6C; Thu, 11 May 2017 08:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=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_DKIM_INVALID=0.01] 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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93iodSC_qysq; Thu, 11 May 2017 08:11:53 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0106.outbound.protection.outlook.com [104.47.38.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2367C129B39; Thu, 11 May 2017 08:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZQkbq9TqpZCTvrJiS7vRXtBCkjZOrjMH8Q/gSz0QWbA=; b=U7n6beGJn8VEMmaGeDpf8OdqltJWIq78GV5gfO1W8xnL8qz7TmcCEpjv2ht7afaqsNTsHnuWmCBwOxicj5R4AQ3CiRcOhXplI9YRxK9FLXgjHdyPZQiEf6hTwpEwhtbPq/cDBV72NZHEEMGWR1BTdGo//h1f9tJ0qaaUtwKZVBI= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.36.231] (66.129.241.13) by BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Thu, 11 May 2017 15:04:42 +0000 To: "Bocci, Matthew (Nokia - GB)" , "mpls@ietf.org" , "draft-bryant-mpls-sfl-framework@ietf.org" References: <74FA86D7-E0FB-4E5D-A5D3-64324CB2A656@nokia.com> CC: "mpls-chairs@ietf.org" From: Eric C Rosen Message-ID: <49a42b8b-13b2-f436-d6e9-a84c4d978c13@juniper.net> Date: Thu, 11 May 2017 11:04:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <74FA86D7-E0FB-4E5D-A5D3-64324CB2A656@nokia.com> Content-Type: multipart/alternative; boundary="------------022010A439B3B56847849FD8" X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BN6PR18CA0019.namprd18.prod.outlook.com (10.175.188.29) To BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ac558877-bd24-4634-93ba-08d4987f0dcb X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 3:EPwH+vUCsFemWl+OGVkVpLTdo1gIBLsCwUBJwn3NXKT57IzdLTdrjkR9DAqGdJsido8V7Ei10+JhLUdqWG2s5Gn/lZ8vCNVo79eh+0yjycobNhZegzzOQYQBnhdMWBeunX4NI25zdeGSZgun19J72Wzd2nALBxCexDuhlj70fBRvjcvA6ta7wAz/IH2w+J0WZ3aD0MX0LWPstX4y4k5ZVdzvMhgbVSLV2kH5cLUs4l37UnZa1oqsC+OGK7E1kI0FtZ4DKYZMnW1hnyI4fURqHMYecpuxRsQp6I4GrKgmSZUqZ9Pbz7M2xGMa5MfJRbwr+ccLcdCfLnOdL7n5neNdJLPi6sO0u7mdyk7c8rnbnwY=; 25:SQ7aG2HuoMJlAp7hiI7iP8F5XD98wr0nx2T5Dcl/IsAbwd9ZPPsIYj1PGdinczGz6x8r/WLZrZQ+5paAZQgrncnLdDB/mIQoHZcdebmE6FsaWQ5ZMTas6Az+95pkRGuoVVitqN20y3BLskrWIMz9ZuFzKEqUoS5uL7xMyZ0NwzXaSMfY8cTFcEuus6PtzDs+jmhEsG45efLOWYJU0+tqYWdky1HZblxHMAuQPk/SFRO/q8wduToNXU1o+QBauSCB6ushYBS83XEj3h92/ZXvKoAfLJ7py9KLhpC3X3SNlQHEF4+LisGDVORxLdeo3n42ExbiCm/qFOBEfQ1pz424dwY3gi1oyZtucT3ASsZmCneXecTKqcrgnLvyDdXsIRMr+QwDpDFATLtwhFS8Dh1Kv85kMycF+GrGj3VkFvRegji0vLJW6xDzGTxlrE1P7mzmUmGi+k8Jt0sBsyEfIA9AnimQwnAhtIuS3RSlbTAAqdI= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 31:1XtKBMUkoDQRChBil+HA8RnpNwqPPI1hZ0alSMqXEZY5EHJMgY7VpCD3MnRFmGkDSFATJqfa1NDLNzzEMEo55LYIU+AVXSBLBlC5XVxGZF1BaQHI/mTAtATz4ATrlDQfUMv64rJd68806jiFgWm+FZ8R9w2v5uD5cboydsJRi3FulJ2o+jJSz9Lm8w/ev7HoVLCR3oqGg2x+ikMqLRu69WWrTT0yT7TqmXIUKnUFzq4=; 20:bMAqCXYae7EzIJN+Ed1JG6eAQvg0R1fDGU6pOWVuHUrWfQXsyxBrdMleuYziIV4BQ7Zz3O1JIv9tpWAcalxXtFtCgXiBH8LLVdiHpIiel78PcuA+B28NyWu9XIHjZSdBLqOm/h2aQZ34Q4+/rzuYKTB2FK1YomDVaxxbAUAfbygFY0aui4uOVyAH02ypLsZ1WCqhE0oLmjMRnT5q2Nfeb9PHzaeuTK8T3hEZ2qK3P28Lfy8bP4mHstAjkNRzJ0yXOJNwIoBKavt9wmWC29bT3kX1v01n5u+heoJImOBHQoY6kUcxhP3pgP/B3B4YzFHR15fPSNLVIyr3mVvsHZ+MhYn1ju3kOJ0bSspyjCBpCnSucpcZwJ0obf72PNCpdrIfWSFIxQZ7W9E2PMp2XmXCc4VOd/ProoBLzjORjhx/oA/AvvinsXn059nUFR/l2CbjrkWOa5dTQLd33ncJVTsNQb94P5gTMV4MyIIHv/rMffytTrA1q9/eUkkrwSMlWyuCLPhML88+IiMDEaq7/LvInLnRrZZHJJS9mkTeEw+VxeeSRiH1gLvpA1vcoGIZvCYNCGozSU8dusoIbqXBhVnDAIjk1ePFM4UCttlkQ6vQkXg= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(82608151540597); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148); SRVR:BL2PR05MB2180; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 4:IKn8i4kM32NPEkV/5K01VbqvKfi7GBHKbdXsiE7/E5ntPcwYoTxRHzFG6xCnldFmMfp4RjNdg2blQXG7YhJoe/TcPkxa5DYUVB+tL8BgugJH4g3pnJGBVC/c6tl1+2QpTNquoD3QHNBlYit4ZsFwAvumMKaH/FtVE6U0tE3osUu5kE3aQdvII+kO38ISmo3QY0o3w55OVqrdoxSiqXskK/ejV6Acp40mdhiCmBD/ks33yz4l2s4VLsXs/VS/NM05Em16lJvhKFzFlI/KXgfa6VQwtxTpcRyTR8PL+bQkaQ8zOx9dO56kJJTQMf5ECIk1Ewzio3Ue/LM1/OBmeZsJzpI/LOcBaHFAq2yb8J+7rU49SoyKJSeddrdvpVBtvD5j1RBzYa9+JivyxU+cZkWV9KK0WvM1CXc5qrxC1BBHdNuDbQYPRrGNmwHM1zj1H/49W8+2mHlekU0VCMe/uC0HUjMZ7aQSMjsRm98SEA7eiI8pVPXWmyuRTdGZsKFXnxetHepnMga1MyEKB6bS2XtX4zS7CHB7uFFNQ7jlKEYxVnR4LGDCqAlnjK/LiWOHRzpHlFX90c3rS5VTaXT0/5wE4oy5+Vx21R7zvYEWx4jCb3TvlFnn6fwwsGKoPafCOiROYX/WM8C2jfE/IgranOKFCVMILCnroeE1JJvaeUm/Ke8mwCdShpxX5r/6PGitvw2WJoEl83u1XREiHddqoLzZvUGu0Sv+NYgDeaQsxD8h4tPdVPWSNQD38XTskeSdikl3iweSYtT1uDUlt5aVpZvlToZQTBCHUwCjsCCFvKb+y37jiiHxWQnmf47g5xY1OH10uBZbPo9R/uwo0+/nvtbV9peXSAWlzYXJMyvU2s9MoWI= X-Forefront-PRVS: 0304E36CA3 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39450400003)(39840400002)(39860400002)(39850400002)(39400400002)(39410400002)(377454003)(24454002)(478600001)(189998001)(4001350100001)(6246003)(25786009)(53546009)(38730400002)(81166006)(8676002)(229853002)(5660300001)(83506001)(33646002)(36756003)(230783001)(84326002)(65826007)(512944002)(66066001)(6116002)(3846002)(7736002)(31686004)(54356999)(42186005)(2201001)(50986999)(76176999)(90366009)(53936002)(2950100002)(6666003)(64126003)(2906002)(6486002)(77096006)(2501003)(4326008)(86362001)(31696002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB2180; H:[172.29.36.231]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2PR05MB2180; 23:NhfhVIWx5nh7sa0lWLDk9FoT7RmPXDcwq2YLh2qSW?= =?us-ascii?Q?3cSi5u/UQcKrgTnu2YSAYmOllCdgp0PxEwH7sziUdjPDIDLsRUhQjBl3XCIL?= =?us-ascii?Q?feJ6avHhl2lDtVnY3bT+LGME7oPbpTtwtOEPMuVfroC52NDfoUr+JT9c0Srn?= =?us-ascii?Q?fdpq4XAI66LN1BsAHy7y2o3npXzBzU2xtXi82PX6jgFruFJLxkkhvpJBHN37?= =?us-ascii?Q?GMDfYmjuGAIOoPUElULSS0h11g8ovYCltgY0GTk5KMvvT8hzwyBCrDCic/yr?= =?us-ascii?Q?i9Cp4s+9q8+2YRfvw1juBkAwuNms+Q2wDw26R1+cm+lmh42NSr1l6MveI99l?= =?us-ascii?Q?Tcr/stvpz/mAO9hd+l6mmIuKoQ87ECN9WfZ7O/rRc+QNNoH/k5D7LA147TbG?= =?us-ascii?Q?FSQPSYkPbQLWL2/jUG1wfHrAy54ePfSvLBDP5JzhQGHWgoK0I9gocPDN5JK6?= =?us-ascii?Q?2L2y/ppYJHMwMH15Qs/ulvWbwRrCSZhYKGMjfv8IZ7O+OlSqnGRyU5Al3NXN?= =?us-ascii?Q?rTtTqC3i4bV2JWJsb3Zv7UCbm0onyYvGVs+sGKbaO1ruk0MpwTYnqjv1Wx+2?= =?us-ascii?Q?r3dDQuMWL0n6AYG7fun9Hya68EvwgK3L157GNLiMWe80/oUsfxDYv0TmUVc6?= =?us-ascii?Q?jUWtI+KJuO+0FBoEKa36WHYqB0OvEopcP+Hwtrmf/dyJjFJjhAiAPJnXr6cQ?= =?us-ascii?Q?mluKM6xH+J0Wb3Ppi5Gwh93QqbUiZt0+wsKF/9gWasK/5IQV3rxAQdd2uWl8?= =?us-ascii?Q?17F7McwZP7HYp2D8o9Ydx6Atrk2rxBPdtYyzhAOobMmCXdyv0q4hzI/Krvg/?= =?us-ascii?Q?TL7hMOQiNtdEm4wegpJ9gwC/pXY5Ido32eaVbCt4l64630ysPj/IzipuDko+?= =?us-ascii?Q?so7pQeKSJ5Y5TIAlUjTLmFmQ/RlzYIbWBHTMDbay4l/tT7KRswC3nPzKDcvo?= =?us-ascii?Q?PIHqD8Ggz0gvASalPMzN8qS/MZeknLwXd+n2uplo9tWIIS8r+1HN6/M1JDIU?= =?us-ascii?Q?S6gfLs0R8lYuO0UqfYIlvhYInIoVnvv2V4/okntLOJOrpNhS06auJQaGTFG6?= =?us-ascii?Q?el7hbl7uCEiEaNHvDV0JuF6EDIRn4+hK9Iq1Av6v/F/vIxvDoW7suqdRJ8BS?= =?us-ascii?Q?73f3NPqvQVV18JDAo3DVxSTP+r+ol0XQ9BZ82ypW1K519RnDiqNejWzrzZ+e?= =?us-ascii?Q?oVx7ZHycRViuua0Jk1aCaYZN8wrJyvcWEY24b5ZikykSIg3b7RPuJpSZj1Vh?= =?us-ascii?Q?XAzjmorlbBLIGMiPx4sO0Ao2Qus4a+bTCuGT/u/?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 6:FE/ibHw6IzsqjtB56ULX8boTUAvetD9ETEIEXjqvoDd4uK7iHtEFFpH2ok0o6Qv+lywMJ/dEqIl0GBoOIvDsCFReljSPIoc1vROj03GDQIJH2LsZKQV0uiqV9FIUf+BWGbWHP7iX+K6TNpVnYWyPeGXDMEodidTcdeS2nL6Qlb6zWIR1FLRH5N/WudWWUS2hQ3adSyU7rOsK4T+n5ntGkMHZ+rV0YpllBHsvfcZkGfxEK6ngWeExyZY79m6M24FXvbJHiF2Ct5/oeEfwt7iwJ4KljW3yU5pOmycY9d/mlCHepTJ9sdoFGlgiUc0y2xCdQqBgZ+wwfCwcQSUxdSp0T7awSSCt2N30Z690+3Dxh+/tNxxhxJiYmmKhGrkqr2ELxV6Dac1y80NnbS6r8Q01p0XF2tt7UYxztbm69cmIgwJAqNNjhRnGq3CTbPMNOjgzXIPPPQSM6Rs50po1giKjpLZUvjxKNvydvjA6+m3BWBNzOu/roJ/ysK8KsWLK5LOuqyFGeHcu0As/5PX+g6MEny9bJ2Xhobl+njMJJkSwPJ4=; 5:bshMWhROHehbkDDScszkRJ1I+qOdq44rCd+jZ0sD422v3IqXZOcvXhKVYRR51UWaLx0PKqIAYQEIzfMfx1wuMiK+SbnsP3/0BKnLWizs0RX4gYs9Ij9ajqerNzyLtwXmi+Jyj8Ls5ixtxyY8usJfRg==; 24:J11sFDEn/j9bxtkjE02ZpGObT4yTtckxPpvQDe+tRaaBFAaLQ1TkHV8QUn9fwffl4y1p92Kc2zhBNgs2amJRkvG+GRQwGKeCq3iA5bpzm1o= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 7:lNaYNznE7to+HgkHqNXYwU29by4+voyjPrOubpV6HUxKzOz/L64YpOwyjOD9/JHZjoQRToOi/xn1pBzBxSgfdT7/+V/rzs+qH7JF58Up+xOETgHGJvNlwXIIc2zTjtw6DBVBw5cqFCW0IVI4lRmMAsbYSQ3R3j3EvZrfHrYdd0TxA02eP5evwkvH7mQXZh4d27LnRV9JjUcyqysVetGe2fev2HPs5FUrp16jaGaEJ0uHzkiTM3N/wQtAfJgNtnPJyY4ttW5wTCh/hFCKezH2SropeEATkbsd8nAmVEQXuvwIIR7roDfpE03+bHKVRzf4HRWmDXvn+QMC68qIbpGh6A== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2017 15:04:42.0412 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2180 Archived-At: Subject: Re: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-framework-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 15:11:57 -0000 --------------022010A439B3B56847849FD8 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit On 5/10/2017 7:00 AM, Bocci, Matthew (Nokia - GB) wrote: > The EL is effectively saying all other things being equal, here is > some additional information to distinguish flows. It is in addition > to, but not an alternative to the rest of the label stack. Do you think there is any situation in which (a) one has given the same EL value to two packets, but (b) one would be perfectly happy to see the packets delivered out of order? Or to put it another way, once an ingress node has assigned a particular EL value to a particular set of packets, is there any advantage to including other fields in the ECMP hash? > I dont think that it is reasonable to mandate that LSRs only consider > the EL and ignore all other labels in the stack given the impact on > the deployed base Certainly one cannot mandate the deployed base to be other than it is, but it would be interesting to know whether the common implementation is really the preferred behavior. --------------022010A439B3B56847849FD8 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit On 5/10/2017 7:00 AM, Bocci, Matthew (Nokia - GB) wrote:
The EL is effectively saying all other things being equal, here is some additional information to distinguish flows. It is in addition to, but not an alternative to the rest of the label stack.

Do you think there is any situation in which (a) one has given the same EL value to two packets, but (b) one would be perfectly happy to see the packets delivered out of order? Or to put it another way, once an ingress node has assigned a particular EL value to a particular set of packets, is there any advantage to including other fields in the ECMP hash?

I dont think that it is reasonable to mandate that LSRs only consider the EL and ignore all other labels in the stack given the impact on the deployed base

Certainly one cannot mandate the deployed base to be other than it is, but it would be interesting to know whether the common implementation is really the preferred behavior.




--------------022010A439B3B56847849FD8-- From nobody Thu May 11 09:38:47 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 211DD1314AE; Thu, 11 May 2017 09:38:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149452072608.16657.9940427362268822447@ietfa.amsl.com> Date: Thu, 11 May 2017 09:38:46 -0700 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-rfc3107bis-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 16:38:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Using BGP to Bind MPLS Labels to Address Prefixes Author : Eric C. Rosen Filename : draft-ietf-mpls-rfc3107bis-02.txt Pages : 22 Date : 2017-05-11 Abstract: This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels, organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s), and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc3107bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-rfc3107bis-02 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-rfc3107bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rfc3107bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 11 09:50:44 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CA31289C3; Thu, 11 May 2017 09:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWqHEw-hOz_V; Thu, 11 May 2017 09:50:28 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0130.outbound.protection.outlook.com [104.47.41.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 F2106127201; Thu, 11 May 2017 09:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ryc7GD4VNhQMA986xapb1G5NC7rMgimtB1IZfTk6kp4=; b=eRep0z60nSyUJp0Uls1AfZGB/nET4Qkh0QMTT8PZForMZ3hzT9u7dPQCa960QOA790uM/VFAt+lz2kmAsdSQyL84wW3Eps6113ZfYPipZEFV8FpN/zlP3pk6MR+vlpuO/WQZ0iFNAsf71S5AlrFSSES8mSsyqOgt2YXO8592Opg= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.36.231] (66.129.241.13) by BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Thu, 11 May 2017 16:45:22 +0000 To: Loa Andersson , "mpls@ietf.org" , , BESS References: <93a6a754-0a2e-2053-542c-a4ce8bf9213b@pi.nu> <61e452c6-80eb-ff94-878d-3152270fc032@pi.nu> CC: "mpls-chairs@ietf.org" , , , "" , From: Eric C Rosen Message-ID: <589f3a5e-b663-cc36-bff4-4f2d9b6c207e@juniper.net> Date: Thu, 11 May 2017 12:45:19 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <61e452c6-80eb-ff94-878d-3152270fc032@pi.nu> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BN6PR05CA0012.namprd05.prod.outlook.com (10.174.92.153) To BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 12d82135-7261-408d-384e-08d4988d1e67 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 3:TcpluUUk1BYSY1RxIwqEKqOq6H4/NZCosGvl1mnSDseyhGD4dBbmX3t6qsI6yixoB36GJNkW1Vg0lHFp5ybv44v9svnbLOBjHC/STByIRwik+tRL3+QRgCn/34vY5e6KftTN70tbCx2cA1BgUPugoTWEUevb0BBsrRImPZzXjjSeqI+CjkoosiKQMat/dbpZv6CRp26JNjZJgUcq4TSBUnPiXHB0Kqc72LKGs3bIDmvJOP6zRQwQ2nKy/jgIo7DVftWtepwdar3WpZ15oGb9ImZMqVrdeuoA56E1kZEMnwJnjLc/E3A3mwk50VG4taQ9WPNWGi6dmYfvc0hI9JTF3VKpBrYsukGPyW7zjkmgf94=; 25:YK8TJ/RSOKuw09C6vEzAo6Yo7kWRa2JkYSdrKIGAs4iuXkSjppCmAA0+7MVWibdAm35S3vAfQVb2ZUNKRlo2gCfotgxvTyv0sYJD0M5Donu8H9Ul7RHb4qlo50lKsxkIvMteCn6u64BniDQRJMfBYKs8x/DbagNMDOYAMCZdnD9ffT0YWB8LXYRpM6YLJ1NqLGB07ThKIM3wE0SZBlkM7MsauIrNTvbt3tjmLRums6/S5WKgodwHjKr+yy0Ta4gv56cfg1qCtck19b0psdtxwuXqcJNOW37fHGdbykhhpY9PUG4zuals0NP2WxH/ALOOl7iv1OcgQSKc4XwBscfpRLk29OJpfPdC7u67XDYq63uQfdXyQsxIT7DrxJUzlMdX2L4tdaAMio3p+cwv/80XuWEHX88qjEhGA2h6GQPjmo0VXQRsepUrHlxri4hmb6kn7FuL3HG76Mr3qJUFmSdkvVcD+R72oZ4QTvWBhxgeu64= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 31:XgY5KcJcVFfl1qE3rJPexwqLfiGXvZs6Rv9rYlhFBmTSJQHoDY3dNw1IrZnJHnBrEFhr+DZRhIVOqblUQoLMLliRC9/QHqq2DdRk+pmkvBuQsXz3XUA1PtryUuAtGC9+WaRJb36ooMorQD//nxyrhH7APnMjxM/T+haOcBlx6fvCqLFmPqAQL0Max9Zwk+FaYjPQ8NS96BNZVLNzhiWqSSNqzHAtc+P+eCPGg0tWk5g=; 20:K30crcLAzUDhpO+IRxO7cHsjRQ3TbDDNnRb070baGVL9Zc+vdIUC8nECo2yUgeQTtkzEcPvezmQdvlY6Z7oG+pgdLkzZTuVGKCMQCKfxwH5Bcf0A0QFFRLt1BFRawpQ/zG4J/ZUqJ++YQAOy18sR3IFkp4mWjMA5HLxQ9vQIewoSDFw+4T4NjSQ3o1UaN87QQuADP7qYsIVX/vMXn7FtxibIr9514NrV69KzBS6xvoXkjNq73onb2A4NseyaVvbZ3gY5iFJW845BjJFYsRyKeReNfdj58TwqTviOXEBrKeM450wP3IPhek9jAYU16cg/tE/oLCRor9hEtElr+KMJcoOu9jwR2wATp108wiDyyXQ4fWxGCFQQLKfl7P+3enHcAuX4RflOtzyS+33t1qlM2lkG/Qglwt/IHQclHEneym+GBYrh4mDMVPaTXf/DyUuSShryMz7IURMb/iIVpOptjJttHihFQhTy0q9pyi6WnlD8uFGWiNhlhZ+sc6TNp35SyIcLz5wtvRoOOj1PoJHXJ64hw9fa+nE0GnAg8zDVVR/h5IlXS4KAedXBKzcA3sTcztR6Z3JLE+3Ptvnw48SU5sVrlcGzfQxrlo2ElrKyu3g= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148); SRVR:BL2PR05MB2180; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB2180; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 4:SMku9yxcbji8wUEAxWej1ellYzDggA6dSzYcZ3YOPno8C1LW7b1qAp87Ovpw+oCSm2BPylwcT0V/i4rFAlYWIBR2kHUuneqTL50UO6PeIbVwrEt8e0C0/DNQ559mmi+iXGWw2QKIoN4CSQaf/4p/+IX6/fzRrJEGGZGT+/aAugc9JKmz+MSD7vv/zLveKCncfT5jpv3CR+ENmF4FIayxeUoKKCKdFypsvkHszoaHe4U/dLGSRJeo0GvZVfwLzmbxAYMolLISdr2BvYI90ezmqda2Joej0bzezuS075ep4xciNkGhRgKFmdVJJicBkNseolahssVIyMrVlCw/Gm7wOoQNvFvdgvlyw/7MTQwdkEqR3THnGfPskUddZ35AO0nzj6NQV/C3XdV6AX0wMPV0BtOVElIuPydgCXUOtRYcXkesb4jmqbbE0ibV8HsQugiX1buLV1+BIPzogm5GUdL2S0xbTpC9DzB23zh89Vd7Ao9BPrC42TPRVGXp9Bl+0zkfy8gJZcvJgrAOaB1z597EK/b7S/gUpRmt719PSGr0cat+oJ/2lfEmHbFR+xfSp6nFB4e3TQ3TKvTiN+/dWDhf95kLz5NPepMsn/+LuFBlB5SzC8CXUnnFNmTTJL3S5/9gUEWa0kVRZ1SMZT15CabnPQyg6RWl6COFJauVH4d7+K85dqcEdcSZsGYhHNkM3zhXD1s3RDTvOCre+VbelhzvVzKBvYnumubPlC+wPl+Xw7JFgmXEKy1RBHW6Tf71aLT4hg6+OsUWphzHPhytUu0qvfUiUvpevdzkzViZuMjHgac= X-Forefront-PRVS: 0304E36CA3 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39860400002)(39840400002)(39450400003)(39410400002)(39400400002)(39850400002)(478600001)(4001350100001)(189998001)(3260700006)(6246003)(25786009)(38730400002)(81166006)(8676002)(229853002)(5660300001)(83506001)(33646002)(36756003)(230783001)(65826007)(65806001)(230700001)(66066001)(6116002)(47776003)(3846002)(305945005)(65956001)(7736002)(50466002)(31686004)(54906002)(42186005)(2201001)(54356999)(50986999)(76176999)(90366009)(53936002)(2950100002)(6666003)(64126003)(2906002)(23676002)(77096006)(6486002)(2501003)(86362001)(4326008)(31696002)(558084003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB2180; H:[172.29.36.231]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTDJQUjA1TUIyMTgwOzIzOlF2L2p3WFlKcjlEeXZmRmdnTVJJeUpKakN1?= =?utf-8?B?dmUrWG9qWUxuZjloVTVSd1BKYmtvVU5RY2RROWdIZ1NxYzJGZklWck1vTm8x?= =?utf-8?B?S3l6bUdpbERPSVZlOFRiVW8wOGpaZlo4L3VoU1pienJpZ2h5eDF3TFpRRTJG?= =?utf-8?B?eGNPZmx4QW52NUpuUmVsaEJFbXJQdmlQSTFseGVUdW9WSll2azZTN2EwY2dv?= =?utf-8?B?T2R2NHArbjBxbmxlSktlWU5NNHZxdndycEdpYm1xalJVOFVtczAveVF6aUQz?= =?utf-8?B?bHEyVHV1WXRlYUE3aVRrNE4rWmR5RnNDVDlUcGZnWFpxQUpjU3hWRlBzb0NR?= =?utf-8?B?dml3ZTRCRXFVNklZbWZ1RnVmL05lV2ZWNkJiTDlaUXFWSysydjVtdllmbFZB?= =?utf-8?B?UWJWYmJPOFNOZ2lZR3ZOLzdMaythRkQzZnloYTNjYkVrNEJIM1BIcStMVkgr?= =?utf-8?B?TmlIa0NjdkVhdnphaCtRTmdZOW5pVG55bDBkb1BFaWR4KzZaNy95VCt2YU13?= =?utf-8?B?a0JkeS9sKzZrUHpqcXA3eGdKaTdIZWJwZzVETDNBS3YybmZYUzFmWnV2NmVv?= =?utf-8?B?T01yUWNiQitvY2hHb01JaTdtRDNlT2I1TGN3RUErSUFPUSt3VS9Ub08wMG83?= =?utf-8?B?ek9SVXB4MGJGb3pSaG5WYy9aL0wvSzhneEkyZW9uRkJacnA1L0FnWExxTEZz?= =?utf-8?B?Y2NkZDkzTW05SlVkVjdlZWdZeUpDcDhCeGRQTFFYWHVvdzRqQ0JNMEdoa1B3?= =?utf-8?B?UGZubkw2c2FjVm5saEJpRUNsWlpIVk9reDBkSHdNbnJYNGd3QnpaS3JVTEVm?= =?utf-8?B?eXdoU3VkYVZhS1VWN0p1S3VkREFVdStwcFNQSTBkekNQVGNJWDhQcTZqL0RY?= =?utf-8?B?S3R1M1RsbVE5aFRsNzZIZU15SFlwQmtvNGtkVndvR2JZQnVNY3YwY2lac1dW?= =?utf-8?B?Y3ZQS0xlTWJUaURqOS9OZ0x0RUYyWlpHN3ovK1JDelkrakhhVVc4Vmg5Nkd3?= =?utf-8?B?Um9HZVE2RHMxTit1ZHhqZlNyeFBqTXFnWTBKVk1ZcUNnOGVwUzQ5S1RsdDBu?= =?utf-8?B?NEZya3NGZDdwZ3lya2xoWWdZR0lKTXQ1S3RxTkZuTVpWS3hVUUhYcm9CUmQ5?= =?utf-8?B?UVFlK2RhN3BiZVg5b3NuQ1NvZjZyYTc5QkoxOXRVak9wMElqQUtTcVFKUXF3?= =?utf-8?B?MkRzNXJmUGJ2Q3kzSW80M0NLUHdYWU14ZDJGMlorQjlJSlVzNGYxWTl4cCtv?= =?utf-8?B?bDBncC9YUXAxNlB0eXhGWkdGcHUxZGZqanJVK2J5VlM1Q2FzeGpRMURRWjFE?= =?utf-8?B?TFFHRGdhbytrTUVSWk0rSzM3TFJtdUVXbmc3a0dEQjV0YVR3VUI3dlV1OEJz?= =?utf-8?B?cWdkTXJXNVBtN3VSeVhMQnZwVkVmVFQ3M1FWeWdqcEVUZXhMVTY1YkdDbTRP?= =?utf-8?B?WW5RbUNXOEV4Mytla0ZwSkhnMG5TS3lFSVArL0dlb3h4dWtOaVVDY24rc3Mw?= =?utf-8?B?bERzZENEOXhUZnUvMVA2bDNzV1VNMUdUYWlVdnZoTG5yLzhIWVZycVFUT25u?= =?utf-8?B?M3VSblp5Y084UGlwd3dMZWpXL2RReTJkSUFnZjZyZ2ozaGtaZ3lTSjE3T21m?= =?utf-8?B?Ymt3aG13ZmFxRmhJY0w4aGVMcUU4TVBOMDhIYjA2ZVVodnI5NGZRWVdPTDZ6?= =?utf-8?B?MEhTM1YrUldPMnQ5Y1FabUI2M2FDbk0ySEhhZXNpdllJUEVIeUE2S3daSXh2?= =?utf-8?B?OWNVTGo1Z3dQMUcrTFJ6NmhENjhOQjB3MVBMZ3dTWkJDSC8zVWVUQ2xVbEtP?= =?utf-8?B?VzY1RDNoZDNpMFhqWWJGcjRiR05ZRjRKWXB2MXNJZlMrWk1NREJjblNwWXFT?= =?utf-8?Q?5gN/fKMSc8c=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 6:DN45Obo9fjHs6g9VK5mfvypaQqp3Pa/JiTGet+ygjeq/KIK3LBPvyGN0pZTrq32WFzUAwK4ZjdlxWx3b6sHGqTEtH1Qx+zftBwb1wSWltKL5fCa2aGLq9WvVIUSWZjHuSa/BVdAIxB0vIJ6dFIQaptkYrAF8fJ/VyrYM6tYYBsBQVKUVzlRiDOnboflAcG35E1M25ttNMrCH/Un9TcvoJDa1Pby3fasKihwMSd6dBbis/OufBgj3KVPANy+7Mqy5mCLgTtWS4/2hkqFllM/fHk3fpQDrXJRlHpiCRNus6biH3sLi3H4HRCvtMVDRSf3UERdvI+Mwok7ocC76Xf86VS1csyIQ2It31ZPuy0yXsLjdxHIzVwh+/8A27cYmvzwdwjA2OjOsYE175WsmaD0YvQ6wX9JX5Z7GVLK8BUb8ROicwdiEckATc/uwnTVFkhRW89tD23LC1qxoZHMaURazwdPmSJ0gcEubjQUbu5nCjezKhtuuMU7/jH/VCKFt8/LrEhxQPeYynKy0OV7bWpZD8VBhGpo9SbYGCzHtgaF8iv4=; 5:N/TatCJ+Tq2e108FaAe69U180g93fNE6Q5B7uAq/czmWxpLFDoTAGCNabFlbJDxo8Ce01I1VpttYD0yVgRo+iM1Yr5zXlOrCzvC5+w3foHCaQqWaR0bijR1a/W7RsmGw68Ww/309/zp+Oo5FkEbzvg==; 24:cZhWWdhRWtaNxgTVB71QiEI64vbQmnuWppESTXjZ8Z6stfVKm8ELIMeSgDF7EQzcN+p2nYVK1mJ6uwrYctdSPpYt0t6Ycxul7p+RiguvjrM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 7:Sjmi9kcMQYUIVWb4X6bRc0gXiGtrawaq10cofKni75nfcj1nzsROgI6J+JnPlWnxjTvsaxClhDCnJwY/T9Ra59uYWAjZciUqqsGAx6YVyLN9jcpwSHesq/xWWCCw12anUX+XBr6Lpb+7KMkbZIT6dney450qWzxXNGqwFbSBgqpfKt/Xm7lMS4a4Au75wPSS9INEpwId0LilqRDMFoffdlqZc249QmXjVp4c1ou/+236oGqnK6BWc4WM0Eo8WMvoGChm7nFeKuLeFuWUaV6MXcgO8euwBwsxoWpXXFwg+85WkTP8SBeO8KQVABoIXuzTvXLejQizKjuibHA822EPAg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2017 16:45:22.3035 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2180 Archived-At: Subject: Re: [mpls] Closed -- Working Group Last Call on draft-ietf-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 16:50:30 -0000 I have now posted draft-ietf-mpls-rfc3107bis-02.txt, which I believe addresses the LC comments. From nobody Thu May 11 10:30:45 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD7B129405; Thu, 11 May 2017 10:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 v0PFWIbc_z32; Thu, 11 May 2017 10:30:40 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 78786129418; Thu, 11 May 2017 10:25:22 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id l9so27122822wre.1; Thu, 11 May 2017 10:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=yHClJdmTYZRkEIedvJAIpvp3GQd0CAGV1+U15Y3Y8l4=; b=KZbGsARf1atC1Ser+ahMRIY1XrBT0SpFAVMBayhM/Ie1f9g7waSkeV2n2QhNh6wZnd n+mMFWaeFmWTJ18io9yOEiifE8G4CATxtIVgc7XN2+T5GRR+bROME/bjPmuAoODuMixr s5NkJ1LjD7fVsLSxNL/wcVptaEQCJRLo6XABdZ5nutmisQUcQkGYgN4Ndm0Nx5+uvFK1 AGXfc+pQ74c8zlS1uwvfDqEH/zuQa/As3H488Hmj5YOBgPkbXrnQXWYYMQyGIupzX2ki N7EoJaco9FOTM/ISZ3/isLYCSV8Q08ewg+CFfDsV1Tn4ZUlVTwnPKS4zqFEGdrSK/Xsk 9p9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=yHClJdmTYZRkEIedvJAIpvp3GQd0CAGV1+U15Y3Y8l4=; b=KhFSTjMvtsx2HNfcMpcw/jYoDfnDqlR7fiq0fYd8kY6BA4Yd/he0AR6MHWoFKbZ1Mn UcTg7mmtRL7N31UyZwTEi5qONlEkuNSrA8WebK4UeXDsZb5NPsyMFcXizgI+BgMq25gv YpoUQW8mQlt/m2QtH672TP2wd63ddx71AKy1YDUmy5pzoGSyscGLasXTwQG0OMuc1uVP lwPn3uSxzUbkpuw3ELJ7xjsfOmWWhfvat6nWgJivZ2+Vyx+0UpA1ngslNf3GW6EfMumo pBToHFOPqLg2j0SVS2jHIj4bHiRI9wDYfdfAJuIzWnI4wxPyynipmdAsNV+mKqzhWt5T W//g== X-Gm-Message-State: AODbwcBKFyRE8Hp5iJRE2Tpc7/WVnbC+wjMe5sfi/rEzu+Pp4/cp6z6/ a2BiJ5jr8VP8qA== X-Received: by 10.223.130.104 with SMTP id 95mr179627wrb.150.1494523521054; Thu, 11 May 2017 10:25:21 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id c184sm1734064wmd.2.2017.05.11.10.25.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 May 2017 10:25:20 -0700 (PDT) To: Eric C Rosen , "Bocci, Matthew (Nokia - GB)" , "mpls@ietf.org" , "draft-bryant-mpls-sfl-framework@ietf.org" References: <74FA86D7-E0FB-4E5D-A5D3-64324CB2A656@nokia.com> <49a42b8b-13b2-f436-d6e9-a84c4d978c13@juniper.net> Cc: "mpls-chairs@ietf.org" From: Stewart Bryant Message-ID: <83752d0b-4b6e-808a-15ac-0f7e632388ed@gmail.com> Date: Thu, 11 May 2017 18:25:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <49a42b8b-13b2-f436-d6e9-a84c4d978c13@juniper.net> Content-Type: multipart/alternative; boundary="------------CE2F0227F6E5D29E1F1C2D1E" Archived-At: Subject: Re: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-framework-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 17:30:43 -0000 This is a multi-part message in MIME format. --------------CE2F0227F6E5D29E1F1C2D1E Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 11/05/2017 16:04, Eric C Rosen wrote: > On 5/10/2017 7:00 AM, Bocci, Matthew (Nokia - GB) wrote: >> The EL is effectively saying all other things being equal, here is >> some additional information to distinguish flows. It is in addition >> to, but not an alternative to the rest of the label stack. > > Do you think there is any situation in which (a) one has given the > same EL value to two packets, but (b) one would be perfectly happy to > see the packets delivered out of order? Or to put it another way, > once an ingress node has assigned a particular EL value to a > particular set of packets, is there any advantage to including other > fields in the ECMP hash? I think not, and thus was surprised when I found out that EL did not of itself define the flow to the forwarders. Clearly I should have read RFC > >> I dont think that it is reasonable to mandate that LSRs only >> consider the EL and ignore all other labels in the stack given the >> impact on the deployed base > > Certainly one cannot mandate the deployed base to be other than it is, > but it would be interesting to know whether the common implementation > is really the preferred behavior. > > As we do more with MPLS it seems to me that we would like the EL to set the path for the flow, with other labels being ignored. Aborting the hash calculation on finding an ELI and just using the next label is simple operation, simpler than for example skipping the SPLs, and in the case of an extended SPL and the label that follows. - Stewart > > --------------CE2F0227F6E5D29E1F1C2D1E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 11/05/2017 16:04, Eric C Rosen wrote:
On 5/10/2017 7:00 AM, Bocci, Matthew (Nokia - GB) wrote:
The EL is effectively saying all other things being equal, here is some additional information to distinguish flows. It is in addition to, but not an alternative to the rest of the label stack.

Do you think there is any situation in which (a) one has given the same EL value to two packets, but (b) one would be perfectly happy to see the packets delivered out of order? Or to put it another way, once an ingress node has assigned a particular EL value to a particular set of packets, is there any advantage to including other fields in the ECMP hash?

I think not, and thus was surprised when I found out that EL did not of itself define the flow to the forwarders. Clearly I should have read RFC


I dont think that it is reasonable to mandate that LSRs only consider the EL and ignore all other labels in the stack given the impact on the deployed base

Certainly one cannot mandate the deployed base to be other than it is, but it would be interesting to know whether the common implementation is really the preferred behavior.



As we do more with MPLS it seems to me that we would like the EL to set the path for the flow, with other labels being ignored. Aborting the hash calculation on finding an ELI and just using the next label is simple operation, simpler than for example skipping the SPLs, and in the case of an extended SPL and the label that follows.

- Stewart




--------------CE2F0227F6E5D29E1F1C2D1E-- From nobody Thu May 11 17:10:36 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10F4129A8F; Thu, 11 May 2017 17:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG-RNfOEdiEA; Thu, 11 May 2017 17:10:27 -0700 (PDT) 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 38C4A129407; Thu, 11 May 2017 17:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12544; q=dns/txt; s=iport; t=1494547576; x=1495757176; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oY06cxB/9cpn1RiE3zlPRn2cB90zu2HDCw45KwdGh1M=; b=A5tVZ+7EB1CRjMkn528D69FfeYSTFsvTTs/ZhcSsw4bgWJYO9pPTqWrg QbLvi2qRi2KFU/x+KwGe+R8EL5PEBUJWT4SSTGc59ASaawqlKqTjhUbaB 7aumqLYIh2+xwTL7A8wnOvajs734bsciMAzUa74Q0accMvVdkyqFgpC/V w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQCq+xRZ/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMB4NiihiRW4gliBeFOIIPhiQCGoR2PxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQMjCj4DBgUOAgIBCBEEAQEoAwICAhkGERQJCAIEAQ0FCIoCAxWwc?= =?us-ascii?q?IImhy4NgzgBAQEBAQEBAQEBAQEBAQEBAQEBAQEdBYg3AYMbglSBYBECASERDxC?= =?us-ascii?q?CXIJgBZZvhmA7AY5HhEqCDYU7iiyLLYkVAR84fwtwFUaGdXaHT4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,326,1491264000"; d="scan'208,217";a="242429036" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 May 2017 00:06:14 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v4C06Ee3001398 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 May 2017 00:06:14 GMT Received: from xch-aln-011.cisco.com (173.36.7.21) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 11 May 2017 19:06:14 -0500 Received: from xch-aln-011.cisco.com ([173.36.7.21]) by XCH-ALN-011.cisco.com ([173.36.7.21]) with mapi id 15.00.1210.000; Thu, 11 May 2017 19:06:14 -0500 From: "Siva Sivabalan (msiva)" To: George Swallow , Loa Andersson CC: "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-bryant-mpls-rfc6374-sfl@ietf.org" , Greg Mirsky Thread-Topic: IPR poll on draft-bryant-mpls-rfc6374-sfl Thread-Index: AQHSvwbZY/1AylBzzEGvYY6f8p7xNKHZZ3aAgAy4iYCACcjdcA== Date: Fri, 12 May 2017 00:06:14 +0000 Message-ID: <2402ac8af9694deeaf4c3ec29c75c51d@XCH-ALN-011.cisco.com> References: <8b495d71-1291-cd59-9faa-fff371c9535f@pi.nu> <3596E602-376D-4E67-A6E8-5965D3449D7E@gmail.com> In-Reply-To: <3596E602-376D-4E67-A6E8-5965D3449D7E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.254.122] Content-Type: multipart/alternative; boundary="_000_2402ac8af9694deeaf4c3ec29c75c51dXCHALN011ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] IPR poll on draft-bryant-mpls-rfc6374-sfl X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 00:10:33 -0000 --_000_2402ac8af9694deeaf4c3ec29c75c51dXCHALN011ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBrbm93IG9mIG5vIGZ1cnRoZXIgSVBSIGJleW9uZCB0aGF0IHdoaWNoIGhhcyBiZWVuIGRpc2Ns b3NlZCBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuDQoNClRoYW5rcywNClNpdmENCg0KDQpGcm9tOiBH ZW9yZ2UgU3dhbGxvdyBbbWFpbHRvOnN3YWxsb3cuaWV0ZkBnbWFpbC5jb21dDQpTZW50OiBGcmlk YXksIE1heSA1LCAyMDE3IDk6NDAgQU0NClRvOiBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+DQpD YzogbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWJyeWFudC1tcGxz LXJmYzYzNzQtc2ZsQGlldGYub3JnOyBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29t Pg0KU3ViamVjdDogUmU6IElQUiBwb2xsIG9uIGRyYWZ0LWJyeWFudC1tcGxzLXJmYzYzNzQtc2Zs DQoNCkkga25vdyBvZiBubyBmdXJ0aGVyIElQUiBiZXlvbmQgdGhhdCB3aGljaCBoYXMgYmVlbiBk aXNjbG9zZWQgYWdhaW5zdCB0aGlzIGRvY3VtZW50Lg0KDQpHZW9yZ2UNCg0KT24gQXByIDI3LCAy MDE3LCBhdCA3OjI0IEFNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0 bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90ZToNCkhpIExvYSwNCkknbSBub3QgYXdhcmUg b2YgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQgb3RoZXIgdGhhdCBhbHJlYWR5IGJlZW4g ZGlzY2xvc2VkLg0KDQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBXZWQsIEFwciAyNiwgMjAxNyBhdCA4 OjMxIFBNLCBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4+IHdyb3Rl Og0KV29ya2luZyBHcm91cCwNCg0KVGhlIGF1dGhvciBvZiBkcmFmdC1icnlhbnQtbXBscy1yZmM2 Mzc0LXNmbCBoYXMgdG9sZCB1cyB0aGF0DQp0aGUgZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUgY29u c2lkZXJlZCBmb3Igd29ya2luZyBhZG9wdGlvbi4NCg0KVGhlIGRvY3VtZW50IGJlZW4gdGhyb3Vn aCBNUExTLVJUIHJldmlldy4gV2Ugd2lsbCBkbyBhbiBJUFIgcG9sbA0KcGFyYWxsZWwgdG8gdGhl IHN0YXJ0IG9mIHRoZSBhZG9wdGlvbiBwb2xsLg0KDQpUaGlzIG1haWwgc3RhcnRzIHRoZSBJUFIg cG9sbC4NCg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdC1i cnlhbnQtbXBscy1yZmM2Mzc0LXNmbD8NCg0KSWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Ns b3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMNCihzZWUgUkZDcyAzOTc5LCA0 ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KDQpUaGVyZSBpcyBvbmUgSVBS IGRpc2Nsb3N1cmUgZmlsZWQgZGlyZWN0bHkgYWdhaW5zdCB0aGlzIGRvY3VtZW50Lg0KDQpJZiB5 b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2Ug cmVzcG9uZCB0bw0KdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBh cmUgYXdhcmUgb2YgYW55IHJlbGV2YW50DQpJUFIuICpUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUg c2VudCB0byB0aGUgTVBMUyB3ZyBtYWlsaW5nIGxpc3QuKiBUaGUNCmRvY3VtZW50IHdpbGwgbm90 IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbg0KcmVj ZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuDQoNCklmIHlvdSBhcmUgb24g dGhlIE1QTFMgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9y DQpjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91 IGFyZSBhd2FyZSBvZiBhbnkNCklQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGlu IGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy4NCg0KDQovTG9hDQptcGxzIHdnIGNvLWNoYWly DQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9h QG1haWwwMS5odWF3ZWkuY29tPG1haWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20+DQpTZW5pb3Ig TVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udTxtYWlsdG86bG9h QHBpLm51Pg0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYg NzM5IDgxIDIxIDY0PHRlbDolMkI0NiUyMDczOSUyMDgxJTIwMjElMjA2ND4NCg0K --_000_2402ac8af9694deeaf4c3ec29c75c51dXCHALN011ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGtub3cgb2Ygbm8gZnVydGhlciBJUFIgYmV5b25k IHRoYXQgd2hpY2ggaGFzIGJlZW4gZGlzY2xvc2VkIGFnYWluc3QgdGhpcyBkb2N1bWVudC4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5TaXZhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gR2VvcmdlIFN3YWxsb3cgW21haWx0bzpzd2FsbG93Lmll dGZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWF5IDUsIDIwMTcgOTo0 MCBBTTxicj4NCjxiPlRvOjwvYj4gTG9hIEFuZGVyc3NvbiAmbHQ7bG9hQHBpLm51Jmd0Ozxicj4N CjxiPkNjOjwvYj4gbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWJy eWFudC1tcGxzLXJmYzYzNzQtc2ZsQGlldGYub3JnOyBHcmVnIE1pcnNreSAmbHQ7Z3JlZ2ltaXJz a3lAZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogSVBSIHBvbGwgb24gZHJh ZnQtYnJ5YW50LW1wbHMtcmZjNjM3NC1zZmw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBrbm93IG9mIG5vIGZ1cnRoZXIgSVBSIGJleW9uZCB0 aGF0IHdoaWNoIGhhcyBiZWVuIGRpc2Nsb3NlZCBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdl b3JnZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBBcHIgMjcsIDIwMTcsIGF0IDc6 MjQgQU0sIEdyZWcgTWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwu Y29tIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIExvYSw8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gbm90IGF3YXJlIG9m IGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0IG90aGVyIHRoYXQgYWxyZWFkeSBiZWVuIGRp c2Nsb3NlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkdyZWc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gV2VkLCBBcHIgMjYsIDIwMTcgYXQgODozMSBQTSwgTG9hIEFuZGVyc3Nv biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSIgdGFyZ2V0PSJfYmxhbmsiPmxvYUBwaS5u dTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldvcmtpbmcgR3JvdXAsPGJyPg0KPGJyPg0KVGhlIGF1dGhvciBvZiBkcmFmdC1i cnlhbnQtbXBscy1yZmM2Mzc0LXNmbCBoYXMgdG9sZCB1cyB0aGF0PGJyPg0KdGhlIGRvY3VtZW50 IGlzIHJlYWR5IHRvIGJlIGNvbnNpZGVyZWQgZm9yIHdvcmtpbmcgYWRvcHRpb24uPGJyPg0KPGJy Pg0KVGhlIGRvY3VtZW50IGJlZW4gdGhyb3VnaCBNUExTLVJUIHJldmlldy4gV2Ugd2lsbCBkbyBh biBJUFIgcG9sbDxicj4NCnBhcmFsbGVsIHRvIHRoZSBzdGFydCBvZiB0aGUgYWRvcHRpb24gcG9s bC48YnI+DQo8YnI+DQpUaGlzIG1haWwgc3RhcnRzIHRoZSBJUFIgcG9sbC48YnI+DQo8YnI+DQpB cmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWJyeWFudC1tcGxz LXJmYzYzNzQtc2ZsPzxicj4NCjxicj4NCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9z ZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzPGJyPg0KKHNlZSBSRkNzIDM5Nzks IDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuPGJyPg0KPGJyPg0KVGhlcmUg aXMgb25lIElQUiBkaXNjbG9zdXJlIGZpbGVkIGRpcmVjdGx5IGFnYWluc3QgdGhpcyBkb2N1bWVu dC48YnI+DQo8YnI+DQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBj b250cmlidXRvciBwbGVhc2UgcmVzcG9uZCB0bzxicj4NCnRoaXMgZW1haWwgcmVnYXJkbGVzcyBv ZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudDxicj4NCklQUi4g KlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBNUExTIHdnIG1haWxpbmcgbGlz dC4qIFRoZTxicj4NCmRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2Ug dW50aWwgYSByZXNwb25zZSBoYXMgYmVlbjxicj4NCnJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3Ig YW5kIGNvbnRyaWJ1dG9yLjxicj4NCjxicj4NCklmIHlvdSBhcmUgb24gdGhlIE1QTFMgV0cgZW1h aWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yPGJyPg0KY29udHJpYnV0 b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUg b2YgYW55PGJyPg0KSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9y bWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLjxicj4NCjxicj4NCjxicj4NCi9Mb2E8YnI+DQptcGxzIHdn IGNvLWNoYWlyPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJo b2VuemIiPi0tIDwvc3Bhbj48YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5M b2EgQW5kZXJzc29uJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZW1haWw6IDxhIGhyZWY9Im1h aWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj4NCmxvYUBtYWlsMDEu aHVhd2VpLmNvbTwvYT48L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+U2VuaW9yIE1Q TFMgRXhwZXJ0Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0 bzpsb2FAcGkubnUiIHRhcmdldD0iX2JsYW5rIj4NCmxvYUBwaS5udTwvYT48L3NwYW4+PGJyPg0K PHNwYW4gY2xhc3M9ImhvZW56YiI+SHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkmbmJz cDsgJm5ic3A7ICZuYnNwO3Bob25lOiA8YSBocmVmPSJ0ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIx JTIwNjQiIHRhcmdldD0iX2JsYW5rIj4NCiYjNDM7NDYgNzM5IDgxIDIxIDY0PC9hPjwvc3Bhbj48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2402ac8af9694deeaf4c3ec29c75c51dXCHALN011ciscocom_-- From nobody Thu May 11 22:12:11 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42963129C39; Thu, 11 May 2017 22:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 ONsnIxQXbCqZ; Thu, 11 May 2017 22:12:06 -0700 (PDT) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 80B5B129C37; Thu, 11 May 2017 22:06:59 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.3]) by rmmx-syy-dmz-app07-12007 (RichMail) with SMTP id 2ee7591542ece97-328ec; Fri, 12 May 2017 13:06:53 +0800 (CST) X-RM-TRANSID: 2ee7591542ece97-328ec X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.2.51.63]) by rmsmtp-syy-appsvr02-12002 (RichMail) with SMTP id 2ee2591542ecd15-51d50; Fri, 12 May 2017 13:06:52 +0800 (CST) X-RM-TRANSID: 2ee2591542ecd15-51d50 From: "Weiqiang Cheng" To: "'Italo Busi'" , Cc: , References: <149339519935.2881.8322243003635696392.idtracker@ietfa.amsl.com> <91E3A1BD737FDF4FA14118387FF6766B157346F2@lhreml504-mbs> In-Reply-To: <91E3A1BD737FDF4FA14118387FF6766B157346F2@lhreml504-mbs> Date: Fri, 12 May 2017 13:06:58 +0800 Message-ID: <003801d2cadd$955a6c40$c00f44c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHSwFHT6RfRe34k+0+8cXprdYx99aHvEoSQgAEmtiA= Content-Language: zh-cn Archived-At: Subject: Re: [mpls] Last Call: (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 05:12:09 -0000 Hi Italo, Thank you very much for your detailed review and valuable comments. We authors will make some modifications based on your comments. B.R. Weiqiang Cheng -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Italo Busi [mailto:Italo.Busi@huawei.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B45=E6=9C=8811=E6=97=A5 = 22:06 =E6=94=B6=E4=BB=B6=E4=BA=BA: ietf@ietf.org =E6=8A=84=E9=80=81: mpls@ietf.org; = draft-ietf-mpls-tp-shared-ring-protection@ietf.org =E4=B8=BB=E9=A2=98: RE: Last Call: = (Shared-Ring = protection (MSRP) mechanism for ring topology) to Proposed Standard I think the draft is ready to be published. I have recently discussed with some authors of the draft some questions = for clarification and it might be worthwhile considering minor text = changes proposed below to further improve text clarity. 1) Section 4.3.1.2 and 4.3.2.2 The text describing egress node failures imply that, also in case of = wrapping and short-wrapping, the ingress node, when notified (by RPS) = about egress node failure, will not send traffic to either the working = or the protection tunnel (like it does with steering protection). It = might be worthwhile adding some explicit text OLD TEXT (Section 4.3.1.2) In one special case where node D fails, all the ring tunnels with node D as egress will become unusable. However, before the failure location information is propagated to all the ring nodes, the wrapping protection mechanism may cause temporary traffic loop: NEW TEXT (Section 4.3.1.2) In one special case where node D fails, all the ring tunnels with node D as egress will become unusable. The ingress node will update = its ring map according to received RPS messages and determine that the = egress node is not reachable thus it will not send traffic to either the = working or the protection tunnel. However, before the failure location information is propagated to all the ring nodes, the wrapping protection mechanism may cause temporary traffic loop: OLD TEXT (Section 4.3.2.2) <...> When node D fails, traffic of LSP1 cannot be protected by any ring tunnels which use node D as the egress node. However, before the failure location information is propagated to all the ring nodes using the RPS protocol, node C switches all the traffic on the working ring tunnel=20 <...> NEW TEXT (Section 4.3.2.2) <...> When node D fails, traffic of LSP1 cannot be protected by any ring tunnels which use node D as the egress node. The ingress node will update its ring = map according to received RPS messages and determine that the egress = node is not reachable thus it will not send traffic to either the = working or the protection tunnel. However, before the failure location information is propagated to all the ring nodes using the RPS protocol, node C switches all the traffic on the working ring tunnel=20 <...> 2) Section 4.3.2 With short-wrapping the two traffic directions of protected LSPs are no = longer co-routed under protection switching conditions. This should be = mentioned. OLD TEXT With short wrapping protection, data traffic switching is executed only at the node upstream to the failure, and data traffic leaves the ring in the protection ring tunnel at the egress node. This scheme can reduce the additional latency and bandwidth consumption when traffic is switched to the protection path. NEW TEXT With short wrapping protection, data traffic switching is executed only at the node upstream to the failure, and data traffic leaves the ring in the protection ring tunnel at the egress node. This scheme can reduce the additional latency and bandwidth consumption when traffic is switched to the protection path. However the two = directions of a protected bidirectional LSP are no longer co-routed = under protection switching conditions. 3) Section 4.3.2 The difference between wrapping and short-wrapping is in the way = protection tunnel is configured. OLD TEXT In the traditional wrapping solution, in normal state the protection ring tunnel is a closed ring, while in the short wrapping solution, the protection ring tunnel is ended at the egress node, which is similar to the working ring tunnel. NEW TEXT In the traditional wrapping solution, the protection ring tunnel is configured as a closed ring, while in the short = wrapping solution, the protection ring tunnel is configured as ended at the egress node, = which is similar to the working ring tunnel. Thanks, Italo -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org]=20 Sent: sabato 29 aprile 2017 00:00 To: IETF-Announce Cc: mpls@ietf.org; db3546@att.com; mpls-chairs@ietf.org; = draft-ietf-mpls-tp-shared-ring-protection@ietf.org; Eric Gray; = Eric.Gray@Ericsson.com Subject: Last Call: = (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed = Standard The IESG has received a request from the Multiprotocol Label Switching = WG (mpls) to consider the following document: - 'Shared-Ring protection (MSRP) mechanism for ring topology' as Proposed = Standard The IESG plans to make a decision in the next few weeks, and solicits = final comments on this action. Please send substantive comments to the = ietf@ietf.org mailing lists by 2017-05-12. Exceptionally, comments may = be sent to iesg@ietf.org instead. In either case, please retain the = beginning of the Subject line to allow automated sorting. Abstract This document describes requirements, architecture and solutions for MPLS-TP Shared Ring Protection (MSRP) in a ring topology for point- to-point (P2P) services. The MSRP mechanism is described to meet the ring protection requirements as described in RFC 5654. This document defines the Ring Protection Switch (RPS) Protocol that is used to coordinate the protection behavior of the nodes on MPLS ring. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protectio= n/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protectio= n/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2680/ https://datatracker.ietf.org/ipr/2681/ https://datatracker.ietf.org/ipr/2682/ https://datatracker.ietf.org/ipr/2683/ From nobody Thu May 11 23:23:43 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC9D1286B1; Thu, 11 May 2017 23:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 iXwVn8cW3Amf; Thu, 11 May 2017 23:23:29 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F71612EA7F; Thu, 11 May 2017 23:19:00 -0700 (PDT) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 12 May 2017 15:18:58 +0900 Received: from SMTP5.etri.info ([169.254.5.137]) by SMTP1.etri.info ([10.2.6.30]) with mapi id 14.03.0319.002; Fri, 12 May 2017 15:18:57 +0900 From: =?ks_c_5601-1987?B?waTFwr3E?= To: "ietf@ietf.org" CC: "mpls@ietf.org" , "draft-ietf-mpls-tp-shared-ring-protection@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: [mpls] Last Call: (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard Thread-Index: AQHSwDiELaN/BQQqsk29ttW8LV5UxaHwOl/w Date: Fri, 12 May 2017 06:18:55 +0000 Message-ID: References: <149339519935.2881.8322243003635696392.idtracker@ietfa.amsl.com> In-Reply-To: <149339519935.2881.8322243003635696392.idtracker@ietfa.amsl.com> Accept-Language: en-US, ko-KR Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.73.86] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Last Call: (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 06:23:33 -0000 RGVhciBhdXRob3JzLA0KDQpJIGhhdmUgdHdvIGNvbW1lbnRzIG9uIHRoaXMgZHJhZnQuDQoNCjEp IFNlY3Rpb24gNC40LjEgKGxhc3QgdHdvIHBhcmFncmFwaHMgYWJvdmUgRmlndXJlIDExKQ0KDQpG b2xsb3dpbmcgdHdvIHNlbnRlbmNlcyBhcmUgZHVwbGljYXRlZCBpbiB0aGUgbGFzdCB0d28gcGFy YWdyYXBocyBhYm92ZSBGaWd1cmUgMTEuDQoNCkZpZ3VyZSAxMSBzaG93cyB0aGUgdG9wb2xvZ3kg b2Ygc2luZ2xlLW5vZGUgaW50ZXJjb25uZWN0ZWQNCnJpbmdzLiBOb2RlIEMgaXMgdGhlIGludGVy Y29ubmVjdGlvbiBub2RlIGJldHdlZW4gUmluZzEgYW5kDQpSaW5nMi4NCg0KUHJvcG9zZWQgY2hh bmdlOiBkZWxldGUgdGhlIGxhc3QgcGFyYWdyYXBoLg0KDQoNCjIpIFNlY3Rpb24gNS4xLjQuMiAo M3JkIHBhcmFncmFwaCBmcm9tIHRoZSBib3R0b20pDQoNClRoZSBsYXN0IHR3byBidWxsZXQgaXRl bXMgY29ycmVzcG9uZCB0byBjb25kaXRpb25zIHdoaWNoIHRyaWdnZXIgc3RhdGUgdHJhbnNpdGlv biBmcm9tIHRoZSBTd2l0Y2hpbmcgc3RhdGUgdG8gdGhlIElkbGUgc3RhdGUuIEhvd2V2ZXIsIGN1 cnJlbnQgdGV4dCBhYm92ZSB0aG9zZSBidWxsZXQgaXRlbXMgaXMgZGVzY3JpYmluZyBhZHZlcnNl bHkuDQoNClByb3Bvc2VkIGNoYW5nZTogDQoNCk9MRCBURVhUDQpJbiBvbmUgb2YgdGhlIGZvbGxv d2luZyBjb25kaXRpb25zLCB0cmFuc2l0aW9uIGZyb20gdGhlIElkbGUgc3RhdGUgdG8NCnRoZSBT d2l0Y2hpbmcgc3RhdGUgTVVTVCBiZSB0cmlnZ2VyZWQ6DQoNCk5FVyBURVhUDQpJbiBvbmUgb2Yg dGhlIGZvbGxvd2luZyBjb25kaXRpb25zLCB0cmFuc2l0aW9uIGZyb20gdGhlIFN3aXRjaGluZyBz dGF0ZSB0bw0KdGhlIElkbGUgc3RhdGUgTVVTVCBiZSB0cmlnZ2VyZWQ6DQoNCkJlc3QgcmVnYXJk cywNClRhZXNpaw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtcGxzIFtt YWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGhlIElFU0cNClNlbnQ6 IFNhdHVyZGF5LCBBcHJpbCAyOSwgMjAxNyAxOjAwIEFNDQpUbzogSUVURi1Bbm5vdW5jZQ0KQ2M6 IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy10cC1zaGFyZWQtcmluZy1wcm90ZWN0aW9u QGlldGYub3JnOyBtcGxzLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogW21wbHNdIExhc3QgQ2Fs bDogPGRyYWZ0LWlldGYtbXBscy10cC1zaGFyZWQtcmluZy1wcm90ZWN0aW9uLTA1LnR4dD4gKFNo YXJlZC1SaW5nIHByb3RlY3Rpb24gKE1TUlApIG1lY2hhbmlzbSBmb3IgcmluZyB0b3BvbG9neSkg dG8gUHJvcG9zZWQgU3RhbmRhcmQNCg0KDQpUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0 IGZyb20gdGhlIE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIFdHDQoobXBscykgdG8gY29u c2lkZXIgdGhlIGZvbGxvd2luZyBkb2N1bWVudDoNCi0gJ1NoYXJlZC1SaW5nIHByb3RlY3Rpb24g KE1TUlApIG1lY2hhbmlzbSBmb3IgcmluZyB0b3BvbG9neScNCiAgPGRyYWZ0LWlldGYtbXBscy10 cC1zaGFyZWQtcmluZy1wcm90ZWN0aW9uLTA1LnR4dD4gYXMgUHJvcG9zZWQgU3RhbmRhcmQNCg0K VGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBuZXh0IGZldyB3ZWVrcywg YW5kIHNvbGljaXRzIGZpbmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBz dWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGUgaWV0ZkBpZXRmLm9yZyBtYWlsaW5nIGxpc3RzIGJ5 IDIwMTctMDUtMTIuIEV4Y2VwdGlvbmFsbHksIGNvbW1lbnRzIG1heSBiZSBzZW50IHRvIGllc2dA aWV0Zi5vcmcgaW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBsZWFzZSByZXRhaW4gdGhlIGJlZ2lu bmluZyBvZiB0aGUgU3ViamVjdCBsaW5lIHRvIGFsbG93IGF1dG9tYXRlZCBzb3J0aW5nLg0KDQpB YnN0cmFjdA0KDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHJlcXVpcmVtZW50cywgYXJj aGl0ZWN0dXJlIGFuZCBzb2x1dGlvbnMgZm9yDQogICBNUExTLVRQIFNoYXJlZCBSaW5nIFByb3Rl Y3Rpb24gKE1TUlApIGluIGEgcmluZyB0b3BvbG9neSBmb3IgcG9pbnQtDQogICB0by1wb2ludCAo UDJQKSBzZXJ2aWNlcy4gIFRoZSBNU1JQIG1lY2hhbmlzbSBpcyBkZXNjcmliZWQgdG8gbWVldCB0 aGUNCiAgIHJpbmcgcHJvdGVjdGlvbiByZXF1aXJlbWVudHMgYXMgZGVzY3JpYmVkIGluIFJGQyA1 NjU0LiAgVGhpcyBkb2N1bWVudA0KICAgZGVmaW5lcyB0aGUgUmluZyBQcm90ZWN0aW9uIFN3aXRj aCAoUlBTKSBQcm90b2NvbCB0aGF0IGlzIHVzZWQgdG8NCiAgIGNvb3JkaW5hdGUgdGhlIHByb3Rl Y3Rpb24gYmVoYXZpb3Igb2YgdGhlIG5vZGVzIG9uIE1QTFMgcmluZy4NCg0KDQoNCg0KDQpUaGUg ZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlhDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLW1wbHMtdHAtc2hhcmVkLXJpbmctcHJvdGVjdGlvbi8NCg0KSUVTRyBkaXNj dXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1tcGxzLXRwLXNoYXJlZC1yaW5nLXByb3RlY3Rpb24vYmFsbG90Lw0KDQpU aGUgZm9sbG93aW5nIElQUiBEZWNsYXJhdGlvbnMgbWF5IGJlIHJlbGF0ZWQgdG8gdGhpcyBJLUQ6 DQoNCiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzI2ODAvDQogICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yNjgxLw0KICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9pcHIvMjY4Mi8NCiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzI2 ODMvDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From nobody Fri May 12 00:02:30 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8320C126D05; Fri, 12 May 2017 00:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-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 aCtEfvFVGzsE; Fri, 12 May 2017 00:02:26 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F9312EAB7; Thu, 11 May 2017 23:57:35 -0700 (PDT) Received: from [192.168.0.103] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C302C18014F3; Fri, 12 May 2017 08:57:33 +0200 (CEST) From: Loa Andersson To: "mpls@ietf.org" , "draft-bryant-mpls-rfc6374-sfl@ietf.org" , "mpls-chairs@ietf.org" Message-ID: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> Date: Fri, 12 May 2017 08:57:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 07:02:29 -0000 Working Group, This is to start a two week poll on adopting draft-bryant- mpls-rfc6374-sfl-04 as a MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. There two IPR disclosure against this document. All the authors have stated on the MPLS wg mailing list that they are unaware of any other IPRs that those that has been disclosed The working group adoption poll ends May 26, 2017. /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri May 12 01:50:06 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628061293F5; Fri, 12 May 2017 01:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSxgoPPxspoC; Fri, 12 May 2017 01:49:55 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67CFE1294EE; Fri, 12 May 2017 01:44:59 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id g12so6667248wrg.2; Fri, 12 May 2017 01:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:references:to:cc:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=zA4+xFcN3Y5xzlgwWHtiX4AW2ohHaxXilAE9v98kyzo=; b=AgILdqA04wj7WFkrcGmk9KlwGwgvqIROySWVh3fL2S2HtaCOJSdx5h7KM+AV23DVL5 4LlKo76lFaQ09WsbkjztDIzVsdWYuNwRWSqzRFrwrQVUUtdoMqT6RQyaD1c4j2XK3Opb ZACqvBLuS8uqn8okLH5OANlQMCscKh7+ifJHma0ySovik8SwqlUYtHoUCj6LHkkJgOz3 Idg4F8VgkXDOHxzJh4UBhWxm8ae+G/oCmCm0BHuuNZT3T+aBJZtwC8djdJhGXAXFE7rx 8wg9rsfXmcwXd57kiWYTN6nnC4Baff4Lta5xIRSw3SMsJezipDJ6pD/jcJptzFCn1k9H w78Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=zA4+xFcN3Y5xzlgwWHtiX4AW2ohHaxXilAE9v98kyzo=; b=egHn0t/FmE14WEUo31F9Ax1g7jH1YYSdKq7fMUxUQwJ2JhSIKj3/TcFx+M1kOkFi/7 jMFOZoQn4wzXAB0NmU49Z/z2LJj9R5MgxDS3nO6M+clL/YL+KIbJ3IXkpsuQ0CNGdn8a zkUo0MkN1UtIJqDe8+cmsUPP77dNps6nwXgMic6gTMorqvBmSnRf06UUqeS/i/Zn7vG/ Nq6C5YADXlJqhjWoIlrMK6DdOXq29ug9mS7m5EZ6lc+hPRWc6ZZqqeXbnE48tDlGUBqB FvAfO9B5elH3AXNW99R1NO7szuJSJ+XvWLq9uIdTqMW2L3744RjyUPTvkla0c2ahDSFD 0VNg== X-Gm-Message-State: AODbwcDBoxIEWNaVA59NAqpvpAZf/l+p6jaktY7V4a9Acngv5p1ChquG QprL3AE7RT+5iGUS X-Received: by 10.80.140.203 with SMTP id r11mr2241576edr.18.1494578697642; Fri, 12 May 2017 01:44:57 -0700 (PDT) Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id t17sm861288edh.1.2017.05.12.01.44.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 May 2017 01:44:52 -0700 (PDT) Reply-To: huubatwork@gmail.com References: <149339519935.2881.8322243003635696392.idtracker@ietfa.amsl.com> To: =?UTF-8?B?7KCV7YOc7Iud?= , "ietf@ietf.org" Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-shared-ring-protection@ietf.org" , "mpls-chairs@ietf.org" From: Huub van Helvoort Message-ID: <7af362b9-17da-8d57-421c-d45ad07ab154@gmail.com> Date: Fri, 12 May 2017 10:45:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=euc-kr; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] Last Call: (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 08:49:58 -0000 Hello Taesik, Thank you very much for reviewing the draft in detail and for your valid comments. We, the authors of the draft, will incorporate your comments. Best regards, Huub. --------- > Dear authors, > > I have two comments on this draft. > > 1) Section 4.4.1 (last two paragraphs above Figure 11) > > Following two sentences are duplicated in the last two paragraphs above Figure 11. > > Figure 11 shows the topology of single-node interconnected > rings. Node C is the interconnection node between Ring1 and > Ring2. > > Proposed change: delete the last paragraph. > > > 2) Section 5.1.4.2 (3rd paragraph from the bottom) > > The last two bullet items correspond to conditions which trigger state transition from the Switching state to the Idle state. However, current text above those bullet items is describing adversely. > > Proposed change: > > OLD TEXT > In one of the following conditions, transition from the Idle state to > the Switching state MUST be triggered: > > NEW TEXT > In one of the following conditions, transition from the Switching state to > the Idle state MUST be triggered: > > Best regards, > Taesik > > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of The IESG > Sent: Saturday, April 29, 2017 1:00 AM > To: IETF-Announce > Cc: mpls@ietf.org; draft-ietf-mpls-tp-shared-ring-protection@ietf.org; mpls-chairs@ietf.org > Subject: [mpls] Last Call: (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard > > > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > - 'Shared-Ring protection (MSRP) mechanism for ring topology' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-05-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes requirements, architecture and solutions for > MPLS-TP Shared Ring Protection (MSRP) in a ring topology for point- > to-point (P2P) services. The MSRP mechanism is described to meet the > ring protection requirements as described in RFC 5654. This document > defines the Ring Protection Switch (RPS) Protocol that is used to > coordinate the protection behavior of the nodes on MPLS ring. > > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ballot/ > > The following IPR Declarations may be related to this I-D: > > https://datatracker.ietf.org/ipr/2680/ > https://datatracker.ietf.org/ipr/2681/ > https://datatracker.ietf.org/ipr/2682/ > https://datatracker.ietf.org/ipr/2683/ > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- ================================================================ Always remember that you are unique...just like everyone else... From nobody Fri May 12 02:02:28 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA72012E04A; Fri, 12 May 2017 02:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 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_H2=-2.8, SPF_HELO_PASS=-0.001, 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 nB4UmjYfs9VT; Fri, 12 May 2017 02:02:24 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0115.outbound.protection.outlook.com [104.47.33.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D46127419; Fri, 12 May 2017 01:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=O0xTkorGDT/8MLYPzb8DxdPyD3/xUkrNcOtD4lpVXb0=; b=j5WeQRZdlmncSD4P0MwWcmXdBnIkVVugU6UDYpgQXjjF9mQDAANYD0QwY7ZCJFNteWlT67DPF4CXVeZKeDW1CeYZLj4yWP2ozIbR+YBLj98eEweNKnQAAhtEuM60Q5ZcHnU4Ih52m+ORrnnkl6/bRi4Fsbo1uCq5SRimqB5+EPg= 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.1084.16; Fri, 12 May 2017 08:57:32 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.1084.021; Fri, 12 May 2017 08:57:32 +0000 From: Jonathan Hardwick To: Eric C Rosen CC: "rtg-dir@ietf.org" , "draft-ietf-mpls-rfc3107bis@ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" Thread-Topic: Routing directorate review of draft-ietf-mpls-rfc3107-bis Thread-Index: AdK/UgoPnMchP/X0SOKBF6US5Kr0PwE6EMqAAC5SQVAA+HX/gACKBdZw Date: Fri, 12 May 2017 08:57:31 +0000 Message-ID: References: <9913c8e1-50fe-34c1-a8d5-2d5efefafc5e@juniper.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none; juniper.net; dmarc=none action=none header.from=metaswitch.com; x-originating-ip: [86.132.79.244] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1909; 7:d5iqkdVui3Agoeyj35pSaakpluAv18cNRXX1C+6QLqrG/6AcwFfWZskI+D4bETPgHWjdlCTA9UlormmlswKKBO7Nq1Y2eRlFi8AGE6OwvDasuEr1O1DUbxEcW9OMIGOYiLkt8xeN4nT74Etc9bFNPrvU4FNqI0I2VzmUEDkzbz0una2szpPDgphcWQ5SYz7xrtl0aIQK3TubMD1cRcCiAezUDzQ8fNopIG5G2igyxEvZhnyu5l1EY+R+yprvTeaIzgSMXJ8tNkuRQnMpU4OOUF99g3d1lHXnxRlx5WFk87yM4ugWpZXgVQnqEg+5XX3Nef8NDw76N6XbY6VEd4QI9Q== x-ms-office365-filtering-correlation-id: e7590ac5-e37a-421b-ddd1-08d49914ed07 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BY2PR0201MB1909; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:BY2PR0201MB1909; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1909; x-forefront-prvs: 0305463112 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39410400002)(39450400003)(39840400002)(39400400002)(13464003)(74316002)(38730400002)(110136004)(122556002)(6246003)(3660700001)(2900100001)(33656002)(86362001)(3280700002)(9686003)(55016002)(6506006)(8666007)(54906002)(99286003)(77096006)(1941001)(305945005)(6116002)(189998001)(6436002)(229853002)(102836003)(3846002)(7736002)(53936002)(6916009)(2906002)(8676002)(8936002)(7696004)(81166006)(5660300001)(478600001)(2950100002)(230783001)(25786009)(53546009)(54356999)(4326008)(66066001)(50986999)(93886004)(76176999)(72206003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1909; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2017 08:57:31.9943 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1909 Archived-At: Subject: Re: [mpls] Routing directorate review of draft-ietf-mpls-rfc3107-bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 09:02:27 -0000 SGkgRXJpYw0KDQpUaGFua3MgZm9yIG1ha2luZyB0aGVzZSBjaGFuZ2VzLiAgVGhpcyByZXNvbHZl cyBteSBjb25jZXJuLg0KDQpCZXN0IHJlZ2FyZHMNCkpvbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBFcmljIEMgUm9zZW4gW21haWx0bzplcm9zZW5AanVuaXBlci5uZXRd IA0KU2VudDogMDkgTWF5IDIwMTcgMTY6MDQNClRvOiBKb25hdGhhbiBIYXJkd2ljayA8Sm9uYXRo YW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5jb20+OyBkcmFmdC1pZXRmLW1wbHMtcmZjMzEwN2Jpc0Bp ZXRmLm9yZzsgbXBscy1jaGFpcnNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcNCkNjOiBydGctZGly QGlldGYub3JnDQpTdWJqZWN0OiBSZTogUm91dGluZyBkaXJlY3RvcmF0ZSByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1tcGxzLXJmYzMxMDctYmlzDQoNCkhpIEpvbiwNCg0KSSd2ZSBtYWRlIHNvbWUgbW9k aWZpY2F0aW9ucyB0byBzZWN0aW9uIDUgaW4gcmVzcG9uc2UgdG8geW91ciBjb21tZW50cy4gIA0K V2hpbGUgSSBkb24ndCB3YW50IHRvIGdldCBpbnRvIGEgbG90IG9mIGRldGFpbHMgYWJvdXQgdGhl IGltcGxlbWVudGF0aW9uIGRpZmZlcmVuY2VzLCBJIGRvIHRoaW5rIGl0IGlzIGZhaXIgdG8gYXNr IHRoYXQgc2VjdGlvbiA1IHBvaW50IG91dCBtb3JlIGNsZWFybHkgdGhhdCB0aGVyZSBjYW4gYmUg aW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcywgYW5kIHRoYXQgaXQgbWlnaHQgbm90IGJlIHBvc3Np YmxlIHRvIGFjaGlldmUgYSBkZXNpcmVkIHNldCBvZiBsb2NhbCBwb2xpY2llcyB3aXRoIHNvbWUg aW1wbGVtZW50YXRpb25zIG9yIHNvbWUgY29tYmluYXRpb25zIG9mIGltcGxlbWVudGF0aW9uLiAg U2VlIGJlbG93IGZvciB0aGUgcHJvcG9zZWQgbmV3IGNvbnRlbnRzIG9mIFNlY3Rpb24gNS4NCg0K RXJpYw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KNS4gIFJlbGF0aW9uc2hpcCBCZXR3ZWVuIFNB RkktNCBhbmQgU0FGSS0xIFJvdXRlcw0KDQogICAgSXQgaXMgcG9zc2libGUgdGhhdCBhIEJHUCBz cGVha2VyIHdpbGwgcmVjZWl2ZSBib3RoIGEgU0FGSS0xIHJvdXRlIA0KZm9yIHByZWZpeCBQIGFu ZCBhIFNBRkktNCByb3V0ZSBmb3IgcHJlZml4IFAuICBEaWZmZXJlbnQgaW1wbGVtZW50YXRpb25z IA0KdHJlYXQgdGhpcyBzaXR1YXRpb24gaW4gZGlmZmVyZW50IHdheXMuDQoNCiAgICBGb3IgZXhh bXBsZSwgc29tZSBpbXBsZW1lbnRhdGlvbnMgbWF5IHJlZ2FyZCBTQUZJLTEgcm91dGVzIGFuZCAN ClNBRkktNCByb3V0ZXMgYXMgY29tcGxldGVseSBpbmRlcGVuZGVudCwgYW5kIG1heSB0cmVhdCB0 aGVtIGluIGEgInNoaXBzIA0KaW4gdGhlIG5pZ2h0IiBmYXNoaW9uLiAgSW4gdGhpcyBjYXNlLCBi ZXN0cGF0aCBzZWxlY3Rpb24gZm9yIHRoZSB0d28gDQpTQUZJcyBpcyBpbmRlcGVuZGVudCwgYW5k IHRoZXJlIHdpbGwgYmUgYSBiZXN0IFNBRkktMSByb3V0ZSB0byBQIGFzIHdlbGwgDQphcyBhIGJl c3QgU0FGSS00IHJvdXRlIHRvIFAuICBXaGljaCBwYWNrZXRzIGdldCBmb3J3YXJkZWQgYWNjb3Jk aW5nIHRvIA0KdGhlIHJvdXRlcyBvZiB3aGljaCBTQUZJIGlzIHRoZW4gYSBtYXR0ZXIgb2YgbG9j YWwgcG9saWN5Lg0KDQogICAgT3RoZXIgaW1wbGVtZW50YXRpb25zIG1heSB0cmVhdCB0aGUgU0FG SS0xIGFuZCBTQUZJLTQgcm91dGVzIGZvciBhIA0KZ2l2ZW4gcHJlZml4IGFzIGNvbXBhcmFibGUs IHN1Y2ggdGhhdCB0aGUgYmVzdCByb3V0ZSB0byBwcmVmaXggUCBpcyANCmVpdGhlciBhIFNBRkkt MSByb3V0ZSBvciBhIFNBRkktNCByb3V0ZSwgYnV0IG5vdCBib3RoLiAgSW4gc3VjaCANCmltcGxl bWVudGF0aW9ucywgaWYgbG9hZC1iYWxhbmNpbmcgaXMgZG9uZSBhbW9uZyBhIHNldCBvZiBlcXVh bCBjb3N0IA0Kcm91dGVzLCBzb21lIG9mIHRoZSBlcXVhbCBjb3N0IHJvdXRlcyBtYXkgYmUgU0FG SS0xIHJvdXRlcyBhbmQgc29tZSBtYXkgDQpiZSBTQUZJLTQgcm91dGVzLiAgV2hldGhlciB0aGlz IGlzIGFsbG93ZWQgaXMgYWdhaW4gYSBtYXR0ZXIgb2YgbG9jYWwgDQpwb2xpY3kuDQoNCiAgICBT b21lIGltcGxlbWVudGF0aW9ucyBtYXkgYWxsb3cgYSBzaW5nbGUgQkdQIHNlc3Npb24gdG8gY2Fy cnkgVVBEQVRFUyANCm9mIGJvdGggU0FGSS0xIGFuZCBTQUZJLTQ7IG90aGVyIGltcGxlbWVudGF0 aW9ucyBtYXkgZGlzYWxsb3cgdGhpcy4gIA0KU29tZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhbGxv dyBib3RoIFNBRklzIG9uIHRoZSBzYW1lIHNlc3Npb24gbWF5IHRyZWF0IA0KdGhlIHJlY2VpcHQg b2YgYSBTQUZJLTEgcm91dGUgZm9yIHByZWZpeCBQIG9uIGEgZ2l2ZW4gc2Vzc2lvbiBhcyBhbiAN CmltcGxpY2l0IHdpdGhkcmF3YWwgb2YgYSBwcmV2aW91cyBTQUZJLTQgcm91dGUgZm9yIHByZWZp eCBQIG9uIHRoYXQgDQpzZXNzaW9uLCBhbmQgdmljZSB2ZXJzYS4gIE90aGVyIGltcGxlbWVudGF0 aW9ucyBtYXkgaGF2ZSBkaWZmZXJlbnQgYmVoYXZpb3IuDQoNCiAgICBBIEJHUCBzcGVha2VyIG1h eSByZWNlaXZlIGEgU0FGSS00IHJvdXRlIG92ZXIgYSBnaXZlbiBCR1Agc2Vzc2lvbiwgDQpidXQg bWF5IGhhdmUgb3RoZXIgQkdQIHNlc3Npb25zIGZvciB3aGljaCBTQUZJLTQgaXMgbm90IGVuYWJs ZWQuICBJbiANCnRoaXMgY2FzZSwgdGhlIEJHUCBzcGVha2VyIE1BWSBjb252ZXJ0IHRoZSBTQUZJ LTQgcm91dGUgdG8gYSBTQUZJLTEgDQpyb3V0ZSBhbmQgdGhlbiBwcm9wYWdhdGUgdGhlIHJlc3Vs dCBvdmVyIHRoZSBzZXNzaW9uIG9uIHdoaWNoIFNBRkktNCBpcyANCm5vdCBlbmFibGVkLiAgV2hl dGhlciB0aGlzIGlzIGRvbmUgaXMgYSBtYXR0ZXIgb2YgbG9jYWwgcG9saWN5Lg0KDQogICAgVGhl c2UgZGlmZmVyZW5jZXMgaW4gdGhlIGJlaGF2aW9yIG9mIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlv bnMgbWF5IA0KcmVzdWx0IGluIHVuZXhwZWN0ZWQgYmVoYXZpb3Igb3IgbGFjayBvZiBpbnRlcm9w ZXJhYmlsaXR5LiAgSW4gc29tZSANCmNhc2VzLCBpdCBtYXkgYmUgZGlmZmljdWx0IG9yIGltcG9z c2libGUgdG8gYWNoaWV2ZSB0aGUgZGVzaXJlZCBwb2xpY2llcyANCndpdGggY2VydGFpbiBpbXBs ZW1lbnRhdGlvbnMgb3IgY29tYmluYXRpb25zIG9mIGltcGxlbWVudGF0aW9ucy4NCg0KDQo= From nobody Fri May 12 04:25:50 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0EF1294DF; Fri, 12 May 2017 04:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 kLTz_UBmz3SZ; Fri, 12 May 2017 04:25:47 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DCB12EB57; Fri, 12 May 2017 04:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1676; q=dns/txt; s=iport; t=1494588000; x=1495797600; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bHq28bU84RZHE9XZCoQnqMhy04tocbsn4GbGLaHe4AU=; b=aXvD5t+lAnau8FC7UbA/lCNYAGJDMiZkjeU2n1qiuwGONMhikLKwykou h9KjL+45rFafPU+MInVLTi8NLxEXoA0Pahr8U0M149MPmsyACvGrUaCFU B2/2LgVKDafkEiBNdDsznju7c4xEcEZDifY89YBU+TXtmGd+gu5DMA+Rs s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DjAAD2mRVZ/4MNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHg2SKGKdQgg8hC4V4AhqEfT8YAQIBAQEBAQEBayiFGQI?= =?us-ascii?q?BAwEBIRE3AxkCAgEIGgImAgICGQwLFRACBAESiiMOrxqCJop0AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARoFBYEGhzKDG4Q0EgEcF4J7gmAFngoBkxqCBIU7iiyUQgEfOH8?= =?us-ascii?q?LcBVGhnV2hj2BIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,329,1491264000"; d="scan'208";a="424794584" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 May 2017 11:19:59 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v4CBJwa0029906 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 May 2017 11:19:59 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 12 May 2017 07:19:58 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 12 May 2017 07:19:58 -0400 From: "Acee Lindem (acee)" To: Loa Andersson , "mpls@ietf.org" , "draft-bryant-mpls-rfc6374-sfl@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: [mpls] woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl Thread-Index: AQHSyu2/yf+Oc5NYQkOGREk43gsijqHwjXqA Date: Fri, 12 May 2017 11:19:58 +0000 Message-ID: References: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> In-Reply-To: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.206] Content-Type: text/plain; charset="utf-8" Content-ID: <68A7A9ED0BDB9545BB3FC3079644D38F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 11:25:49 -0000 SSBzdXBwb3J0IGFkb3B0aW9uLiBTeW5jaHJvbm91cyBsYWJlbHMgYXJlIGFuIGludGVyZXN0aW5n IGNvbmNlcHQuDQpUaGFua3MsDQpBY2VlIA0KDQpPbiA1LzEyLzE3LCAyOjU3IEFNLCAibXBscyBv biBiZWhhbGYgb2YgTG9hIEFuZGVyc3NvbiINCjxtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIGxvYUBwaS5udT4gd3JvdGU6DQoNCj5Xb3JraW5nIEdyb3VwLA0KPg0KPlRoaXMgaXMg dG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIG9uIGFkb3B0aW5nIGRyYWZ0LWJyeWFudC0NCj5tcGxz LXJmYzYzNzQtc2ZsLTA0IGFzIGEgTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPg0KPlBs ZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgKHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRoZSBtcGxz IHdvcmtpbmcNCj5ncm91cCBtYWlsaW5nIGxpc3QgKG1wbHNAaWV0Zi5vcmcpLiBQbGVhc2UgZ2l2 ZSBhIHRlY2huaWNhbA0KPm1vdGl2YXRpb24gZm9yIHlvdXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwg ZXNwZWNpYWxseSBpZiB5b3UgdGhpbmsgdGhhdA0KPnRoZSBkb2N1bWVudCBzaG91bGQgbm90IGJl IGFkb3B0ZWQgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPg0KPlRoZXJlIHR3byBJUFIg ZGlzY2xvc3VyZSBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuDQo+DQo+DQo+QWxsIHRoZSBhdXRob3Jz IGhhdmUgc3RhdGVkIG9uIHRoZSBNUExTIHdnIG1haWxpbmcgbGlzdCB0aGF0IHRoZXkgYXJlDQo+ dW5hd2FyZSBvZiBhbnkgb3RoZXIgSVBScyB0aGF0IHRob3NlIHRoYXQgaGFzIGJlZW4gZGlzY2xv c2VkDQo+DQo+VGhlIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gcG9sbCBlbmRzIE1heSAyNiwgMjAx Ny4NCj4NCj4vTG9hDQo+bXBscyB3ZyBjby1jaGFpcg0KPi0tIA0KPg0KPg0KPkxvYSBBbmRlcnNz b24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+ U2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCj5I dWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEg NjQNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pm1wbHMgbWFpbGluZyBsaXN0DQo+bXBsc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscw0KDQo= From nobody Fri May 12 08:47:46 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E1E124234; Fri, 12 May 2017 08:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hX9fbo1bhpeo; Fri, 12 May 2017 08:47:42 -0700 (PDT) Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (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 2BE2312EB85; Fri, 12 May 2017 08:42:01 -0700 (PDT) Received: by mail-wr0-x243.google.com with SMTP id g12so8029650wrg.2; Fri, 12 May 2017 08:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=JYvWH//XbRkGWQ++S4UaWgxRQ8O0vyoJxu4tSNUe/Vw=; b=B6pTNPTqu2rKtlMG2+vgjOOn00pWyBgml9CkfqZv4JBS0o7hycR7vfPMVYbv6LyOjt 12uhbtc5C/CCN23ko3Yggl5buzo4dZMXCuXkKhwTO/SC+pzF4/aZCb3GH2jaCgjvinRV Bxvi+lYqBvkv0Y5uLbxDKsj6VMgZu+ZSzTk6PCJQ1oF5sMoxx6KOMlNR/qUU4xAxbdIS BxVDB6BU2M2IVr5UJDFkjuQdkLN5V750YrQ05U4+qsthbyuN87iYg3hHz14Cs74vRoJp LRe8P87LaUlPeAe14fOwIPntpO15V3TGts5Xc0ZiJMeHk+CHpgkRz8Kewn2iygsxuJ+E dyKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=JYvWH//XbRkGWQ++S4UaWgxRQ8O0vyoJxu4tSNUe/Vw=; b=R6xJ6UO2bBV7ONR/oFo4ISc0ON8F+NLe6A5SFrjNfzUi19uXK3GFXZ8LaF7MYXQ16w XDs90CJ1D2mCbhSARHlynJKHBuCH4XLos4YoflbkObh0hA0C49kxlzk2XpGLeVCnO3rH rn7H59kBQqlv919Kh/1rpPXKPdPBwNIDeqcu/SnToWFT7crYKQVs9dJ3pcfof5tMjEfu es6d+8Z+QCkU32H+YLJzQBkxys4wHc7yZk8OoXEuxFwbAmfYK0it6BBsIaFajPv8TL7e k3zArekiME6tZcBW0eLjrrxjo1QduEqaDm/2HYA0OBrbunC4jIToQv0VeBCHYMuaLTLr kvbQ== X-Gm-Message-State: AODbwcCaWyGZOviEgf/w8PCVsAWQ71TIW5UgsBqa6eF3l+GDdw9S5Fz4 wnWVzbvqokGPVA== X-Received: by 10.223.150.76 with SMTP id c12mr3270774wra.202.1494603719512; Fri, 12 May 2017 08:41:59 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id m127sm2325388wmb.10.2017.05.12.08.41.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 May 2017 08:41:58 -0700 (PDT) To: "Acee Lindem (acee)" , Loa Andersson , "mpls@ietf.org" , "draft-bryant-mpls-rfc6374-sfl@ietf.org" , "mpls-chairs@ietf.org" References: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> From: Stewart Bryant Message-ID: <547b38bf-b5b6-13e1-ccac-0f0c711e34be@gmail.com> Date: Fri, 12 May 2017 16:41:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 15:47:44 -0000 Yes, I agree, as we look at how we might develop MPLS by attaching more instructions to packets, I think this is a useful concept, but then as an author I would think that :) - Stewart On 12/05/2017 12:19, Acee Lindem (acee) wrote: > I support adoption. Synchronous labels are an interesting concept. > Thanks, > Acee > > On 5/12/17, 2:57 AM, "mpls on behalf of Loa Andersson" > wrote: > >> Working Group, >> >> This is to start a two week poll on adopting draft-bryant- >> mpls-rfc6374-sfl-04 as a MPLS working group document. >> >> Please send your comments (support/not support) to the mpls working >> group mailing list (mpls@ietf.org). Please give a technical >> motivation for your support/not support, especially if you think that >> the document should not be adopted as a working group document. >> >> There two IPR disclosure against this document. >> >> >> All the authors have stated on the MPLS wg mailing list that they are >> unaware of any other IPRs that those that has been disclosed >> >> The working group adoption poll ends May 26, 2017. >> >> /Loa >> mpls wg co-chair >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls From nobody Fri May 12 10:07:23 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3367F12EBDB; Fri, 12 May 2017 10:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOvFZltADPna; Fri, 12 May 2017 10:07:18 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 5A031129AD3; Fri, 12 May 2017 10:02:56 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id n23so6561109pfb.3; Fri, 12 May 2017 10:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=cZ44/OSFhEfRCTi93gMuoTD/RGvplqv2hqDFIgtOgRE=; b=YJ+CSjpdQqJj+M0FIKHP2TbaWvijcTAbzktnrbdMwsUV1YAdhjqdFe16/JZ/kanQER I3d9bflQ3o7Bzo7zH2x9Qe/La7vIKzGKnrXuPsLPYl+eGyu9a+MjQWy5bPgJ4I+5TEU6 ogty7cJez+eTyy4HSYUm6p7NXcl8dHC+4Bm+2gzZMfzxwNQNhi6j8LeK9ISl5VXEjYQn mfRn7km/KrZgOL+jPwYI+k9djFiZS3apoIXW0Y66yw7MSZhnhOPlRM6edG7k5biUEtAY hKZPpUaF0I0OtqC7rtWeT4I4elprOd/znwGcMg/aI3kFPuRe+mXCibaR728tGsVTdBj5 xeCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=cZ44/OSFhEfRCTi93gMuoTD/RGvplqv2hqDFIgtOgRE=; b=ZPdCRk2dROvxSwvejbbZun8F2LoeKNbgOVi55Kzi8kmIU0ruHDFqgGH/J7pmGFGojw nQAncgvU35EI/rVQIJrIAN3Cc2pI5lA8+5LlksTlriS/Rw47bAFlakzUeYcJuxw2Rsmb At8O6cqAiqnng8+yWH6ATE2BLaRJ+WJmFp/93335AtGgufwuaHWk1ZvDHjiIG3vftPsD wdjwUJrHy0sbWJKETGRb3KG/IBThX+yqrBm8oIt7SCHKnEayjLSN5AEpRz/qV3Hvyn8p RBy5ya47nBD2ynajfE6whYhPiiDSZ9tlyRk0fZq0Fm5oDBs1L9zIORohFrxJekcO37yM 74vA== X-Gm-Message-State: AODbwcBNPKipEtli5breEgkuJjVzhXZlYxWZ/WlQLJNY4MnBcs1a0Me2 9tCDgPsW1V89oPPH X-Received: by 10.99.121.67 with SMTP id u64mr5517138pgc.230.1494608574713; Fri, 12 May 2017 10:02:54 -0700 (PDT) Received: from [192.168.1.2] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id w3sm5652796pfw.67.2017.05.12.10.02.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 May 2017 10:02:53 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Fri, 12 May 2017 10:02:54 -0700 From: Jeff Tantsura To: Loa Andersson , "mpls@ietf.org" , "draft-bryant-mpls-rfc6374-sfl@ietf.org" , "mpls-chairs@ietf.org" Message-ID: Thread-Topic: [mpls] woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl References: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> In-Reply-To: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [mpls] woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 17:07:22 -0000 yes/support =E2=80=93 rather promising concept =20 Cheers, Jeff =20 On 5/11/17, 23:57, "mpls on behalf of Loa Andersson" wrote: Working Group, =20 This is to start a two week poll on adopting draft-bryant- mpls-rfc6374-sfl-04 as a MPLS working group document. =20 Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. =20 There two IPR disclosure against this document. =20 =20 All the authors have stated on the MPLS wg mailing list that they are unaware of any other IPRs that those that has been disclosed =20 The working group adoption poll ends May 26, 2017. =20 /Loa mpls wg co-chair --=20 =20 =20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 =20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 From nobody Fri May 12 11:10:12 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E571314C9; Fri, 12 May 2017 11:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 37d0-mPHNYKz; Fri, 12 May 2017 11:10:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CB51314DA; Fri, 12 May 2017 11:05:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMU62559; Fri, 12 May 2017 18:05:10 +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.301.0; Fri, 12 May 2017 19:05:09 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.175]) by SJCEML702-CHM.china.huawei.com ([169.254.4.161]) with mapi id 14.03.0235.001; Fri, 12 May 2017 11:05:05 -0700 From: Uma Chunduri To: Loa Andersson , "mpls@ietf.org" , "draft-bryant-mpls-rfc6374-sfl@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: [mpls] woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl Thread-Index: AQHSyu3HzzkTBra2JkqXZgZWEM0uC6Hw/qTg Date: Fri, 12 May 2017 18:05:05 +0000 Message-ID: <25B4902B1192E84696414485F5726854018A3093@SJCEML701-CHM.china.huawei.com> References: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> In-Reply-To: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5915F957.00C3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c85e91d35601c61dc3167a4e3e71e7c9 Archived-At: Subject: Re: [mpls] woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 18:10:10 -0000 Support. -- Uma C. -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, May 11, 2017 11:58 PM To: mpls@ietf.org; draft-bryant-mpls-rfc6374-sfl@ietf.org; mpls-chairs@ietf= .org Subject: [mpls] woeking group adoption poll on draft-bryant-mpls-rfc6374-sf= l Working Group, This is to start a two week poll on adopting draft-bryant- mpls-rfc6374-sfl-04 as a MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. There two IPR disclosure against this document. All the authors have stated on the MPLS wg mailing list that they are unawa= re of any other IPRs that those that has been disclosed The working group adoption poll ends May 26, 2017. /Loa mpls wg co-chair --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri May 12 11:20:07 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A8913012A; Fri, 12 May 2017 11:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XogT9GZ3q10O; Fri, 12 May 2017 11:20:03 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 7C47D12EBAF; Fri, 12 May 2017 11:15:29 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id l18so75026847oig.2; Fri, 12 May 2017 11:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kyXNGEnGUsXXT3V1491fuJcb4hCw8AbkZtjqKme6wM0=; b=XtHyZrNv26hhVR8OSZqcbBrfnx76pubM7ak3AntRmTIFMQVeSplf1q76OGDiePU/FA JPRLO7zBidG2L7MlwtwxV1iRwMVw07fWVKoW1oTCnkoEZu/5AGjKhMTf07zI1D0X0hMc n5pAN5oD1W1pmMez2GqccjGJXBti1KgEHMKUA6fuo9t+sThoTDFuoeC0VqhsyDZF879U SjN0jdy5XU7tFOlKbmvMgCDgrviuMEXUEy9TnMrCC2tTZLCmor1Q0CPO0rTDX8Zd9KUn 2mYTAmqWgz+SCGCTgqLmwYKGBFKfNGFo6KpgofJHp0pwYFISeoxTueSAYfaWvm88g0FN GJGA== 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=kyXNGEnGUsXXT3V1491fuJcb4hCw8AbkZtjqKme6wM0=; b=QX/zJ+hRKBf+QWzLvkXZ53onlaQUkKsEXKRDSkcQkp8huTGRm34qwaDsCDYvPd/ask uHcVwHgeFcluuqX61zTcVnNDq0Hyym+kmhkIbYBm3sQh0ClNlWNC/jW5J//b1Kv2QPKV ptEXur18RnyooMpvpjFz0vcv27GZ/TS7GBDKIfthy/3kWpmxgyL1LJZ7qp7aWXobPY2z flP2LSymtlq2d5x8QUGus06H033bUlX+I1TENX1d7UlhABUD6e3rM/aA/uUicL+d2x1H VjjgH4o7v+7EzrjlHDeo3PPnVStijw6pfSxR2R/qcax4B2BHVostp2ziUltt6iwDbjFR q3kQ== X-Gm-Message-State: AODbwcCGih3/EKZ3pMOd31Z9jPmqAjWrlf29juOrUaSmsvaPB+gPDdwE SkSCcR7EH/yIK/tWDNMsiwjJdLvo1r4F X-Received: by 10.157.2.232 with SMTP id 95mr2422927otl.219.1494612928815; Fri, 12 May 2017 11:15:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.246 with HTTP; Fri, 12 May 2017 11:15:28 -0700 (PDT) Received: by 10.157.52.246 with HTTP; Fri, 12 May 2017 11:15:28 -0700 (PDT) In-Reply-To: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> References: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> From: Greg Mirsky Date: Fri, 12 May 2017 11:15:28 -0700 Message-ID: To: Loa Andersson Cc: mpls@ietf.org, draft-bryant-mpls-rfc6374-sfl@ietf.org, "mpls-chairs@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0bbff2b2e605054f57b02a" Archived-At: Subject: Re: [mpls] woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 18:20:05 -0000 --94eb2c0bbff2b2e605054f57b02a Content-Type: text/plain; charset="UTF-8" yes/ support as co-author. Regards, Greg On May 12, 2017 12:02 AM, "Loa Andersson" wrote: > Working Group, > > This is to start a two week poll on adopting draft-bryant- > mpls-rfc6374-sfl-04 as a MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There two IPR disclosure against this document. > > > All the authors have stated on the MPLS wg mailing list that they are > unaware of any other IPRs that those that has been disclosed > > The working group adoption poll ends May 26, 2017. > > /Loa > mpls wg co-chair > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --94eb2c0bbff2b2e605054f57b02a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
yes/ support as co-author.=C2=A0
Regards= , Greg=C2=A0

On May 12, 2017 12:02 AM, "Loa Andersson" <loa@pi.nu> wrote:
Working Group,

This is to start a two week poll on adopting draft-bryant-
mpls-rfc6374-sfl-04 as a MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls= @ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

There two IPR disclosure against this document.


All the authors have stated on the MPLS wg mailing list that they are
unaware of any other IPRs that those that has been disclosed

The working group adoption poll ends May 26, 2017.

/Loa
mpls wg co-chair
--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=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 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64
--94eb2c0bbff2b2e605054f57b02a-- From nobody Sun May 14 02:16:13 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D94B1292D3; Sun, 14 May 2017 02:16:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: Cc: mpls@ietf.org, draft-ietf-mpls-tp-aps-updates.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149475337228.2843.4160391987888372254@ietfa.amsl.com> Date: Sun, 14 May 2017 02:16:12 -0700 Archived-At: Subject: [mpls] Opsdir last call review of draft-ietf-mpls-tp-aps-updates-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 09:16:12 -0000 Reviewer: Jürgen Schönwälder Review result: Ready The document is about the changes it suggests. Not being an MPLS geek, I can't judge the details. That said, from an operational point of view, fixing ambiguities in specifications is usually a very good thing. From nobody Mon May 15 19:46:36 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEE112714F; Mon, 15 May 2017 19:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 vGC0t_tSN85g; Mon, 15 May 2017 19:46:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C87B12EB73; Mon, 15 May 2017 19:43:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMZ67711; Tue, 16 May 2017 02:43:15 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 16 May 2017 03:43:14 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 16 May 2017 10:43:01 +0800 From: "Dongjie (Jimmy)" To: Loa Andersson , "mpls@ietf.org" , "draft-bryant-mpls-rfc6374-sfl@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: [mpls] woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl Thread-Index: AQHSyu3Jp1q7dLZPKkKJRVowuo0y6qH2RWdQ Date: Tue, 16 May 2017 02:43:01 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927936AB5E2@NKGEML515-MBX.china.huawei.com> References: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> In-Reply-To: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.591A6744.001D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c85e91d35601c61dc3167a4e3e71e7c9 Archived-At: Subject: Re: [mpls] woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 02:46:35 -0000 Support the adoption. SFL is a useful tool for performance measurement. -Jie > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Friday, May 12, 2017 2:58 PM > To: mpls@ietf.org; draft-bryant-mpls-rfc6374-sfl@ietf.org; > mpls-chairs@ietf.org > Subject: [mpls] woeking group adoption poll on draft-bryant-mpls-rfc6374-= sfl >=20 > Working Group, >=20 > This is to start a two week poll on adopting draft-bryant- > mpls-rfc6374-sfl-04 as a MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical motivation fo= r your > support/not support, especially if you think that the document should not= be > adopted as a working group document. >=20 > There two IPR disclosure against this document. >=20 >=20 > All the authors have stated on the MPLS wg mailing list that they are > unaware of any other IPRs that those that has been disclosed >=20 > The working group adoption poll ends May 26, 2017. >=20 > /Loa > mpls wg co-chair > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Mon May 15 23:40:59 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7543212EB0C; Mon, 15 May 2017 23:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dg1-tVE_ycbc; Mon, 15 May 2017 23:40:55 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EA1F12EB37; Mon, 15 May 2017 23:36:56 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id w10so13785316oif.0; Mon, 15 May 2017 23:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0D6g0OMGwBD4cPEcXj4CimrU7NJoY1YWUFcIqoX09Is=; b=mn5pFKMQF1c9jD8XHKqhWq36A9L5/OSsm2qa6bF72Rl+8KnvNqdAcE6X7IuoLKNTJy 6fBRWxKPtxX+N2rRhwhor5WcUwN2gi+9H7+0boE1dr1kIyXBzR/9asg6nqPQXvgRY3Y0 tVyIyyzdAZ58XLHTH7zGbPzrcpQYQdBcbTUBrKhBteeQAu3jJWvzdv4bQs83RVWOSBpG 5os4+IjArg3mbcHiwB/ID5/MRdTwyCzgOFfmfpc+EqPieZTiSNO0nV2mAuo4h/yaBOi6 nfW1PQeHz1DPhQx7xE//kcnhLL05Swx2WqP+pjNoHUg9dXcUqE1c47Vym7JFoCbLV6Sa gG0w== 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=0D6g0OMGwBD4cPEcXj4CimrU7NJoY1YWUFcIqoX09Is=; b=IZCckivjSbxw20t/p+rjY3U4qaarKrHeETDgmKNsXoWNAGdLzK24uT3aDoZNgWWWac 8DaQ7EVqFu6r6qjzibcWDERPEOV0VVgphHahKz3f6BYQi4phBWpAN7I6nkNShYbRncIH Yi6cjC8ZdFegpnYzpIcW2spzMU4OVwFrmT2CIdURSSsVmVftJHEucRFMSzWfeb25q2I1 LuiNTdP5BTDtqpEpsOaI1r5jOBqX9zUBp2HuResmBnsXu8ic/PSKw9ToLNwIYohjE1cV CzdxqGAmj6DIBFSYEmKUIAx0wjJBg0sX3oD2Wzk474ror50isszPwsRAQIRUiHuXd59F LZKA== X-Gm-Message-State: AODbwcDon2gybgFfYSrUBTslp8pTRPr8ZUqgpECa69m8sqtprQrLwlXm OwtJ462dNbgA55CVwJOhjEWbTpZTfA== X-Received: by 10.157.33.98 with SMTP id l31mr5547737otd.245.1494916615305; Mon, 15 May 2017 23:36:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.132 with HTTP; Mon, 15 May 2017 23:36:34 -0700 (PDT) In-Reply-To: <76CD132C3ADEF848BD84D028D243C927936AB5E2@NKGEML515-MBX.china.huawei.com> References: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> <76CD132C3ADEF848BD84D028D243C927936AB5E2@NKGEML515-MBX.china.huawei.com> From: "Andrew G. Malis" Date: Tue, 16 May 2017 14:36:34 +0800 Message-ID: To: "Dongjie (Jimmy)" Cc: Loa Andersson , "mpls@ietf.org" , "draft-bryant-mpls-rfc6374-sfl@ietf.org" , "mpls-chairs@ietf.org" Content-Type: multipart/alternative; boundary="001a113ac6a6d2fe32054f9e65cf" Archived-At: Subject: Re: [mpls] woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 06:40:57 -0000 --001a113ac6a6d2fe32054f9e65cf Content-Type: text/plain; charset="UTF-8" I agree, I also support adoption. Cheers, Andy On Tue, May 16, 2017 at 10:43 AM, Dongjie (Jimmy) wrote: > Support the adoption. SFL is a useful tool for performance measurement. > > -Jie > > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > > Sent: Friday, May 12, 2017 2:58 PM > > To: mpls@ietf.org; draft-bryant-mpls-rfc6374-sfl@ietf.org; > > mpls-chairs@ietf.org > > Subject: [mpls] woeking group adoption poll on > draft-bryant-mpls-rfc6374-sfl > > > > Working Group, > > > > This is to start a two week poll on adopting draft-bryant- > > mpls-rfc6374-sfl-04 as a MPLS working group document. > > > > Please send your comments (support/not support) to the mpls working > > group mailing list (mpls@ietf.org). Please give a technical motivation > for your > > support/not support, especially if you think that the document should > not be > > adopted as a working group document. > > > > There two IPR disclosure against this document. > > > > > > All the authors have stated on the MPLS wg mailing list that they are > > unaware of any other IPRs that those that has been disclosed > > > > The working group adoption poll ends May 26, 2017. > > > > /Loa > > mpls wg co-chair > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a113ac6a6d2fe32054f9e65cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree, I also support adoption.

Cheer= s,
Andy


=
On Tue, May 16, 2017 at 10:43 AM, Dongjie (Jimmy= ) <jie.dong@huawei.com> wrote:
Support the adoption. SFL is a useful tool for performance measureme= nt.

-Jie

> -----Original Message-----
> From: mpls [mailto:mpls-bounc= es@ietf.org] On Behalf Of Loa Andersson
> Sent: Friday, May 12, 2017 2:58 PM > To: mpls@ietf.org; draft-bryant-mpls-rfc6374-sfl@<= wbr>ietf.org;
> mpls-chairs@ietf.org
> Subject: [mpls] woeking group adoption poll on draft-bryant-mpls-rfc63= 74-sfl
>
> Working Group,
>
> This is to start a two week poll on adopting draft-bryant-
> mpls-rfc6374-sfl-04 as a MPLS working group document.
>
> Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org= ). Please give a technical motivation for your
> support/not support, especially if you think that the document should = not be
> adopted as a working group document.
>
> There two IPR disclosure against this document.
>
>
> All the authors have stated on the MPLS wg mailing list that they are<= br> > unaware of any other IPRs that those that has been disclosed
>
> The working group adoption poll ends May 26, 2017.
>
> /Loa
> mpls wg co-chair
> --
>
>
> Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
> Senior MPLS Expert=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 loa@pi.= nu
> Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64=
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

--001a113ac6a6d2fe32054f9e65cf-- From nobody Tue May 16 07:09:50 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5E9128768; Tue, 16 May 2017 07:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 6qvOn6SzHE7k; Tue, 16 May 2017 07:09:46 -0700 (PDT) Received: from mx01.telecomitalia.it (mx01.telecomitalia.it [217.169.121.10]) (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 372BC129B82; Tue, 16 May 2017 07:04:43 -0700 (PDT) X-AuditID: d9a9790a-bc3ff7000000439d-f5-591b06f9c3a2 Received: from TELMBXA06RM001.telecomitalia.local ( [10.14.252.34]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx01.telecomitalia.it () with SMTP id BB.A0.17309.9F60B195; Tue, 16 May 2017 16:04:42 +0200 (CEST) From: Fioccola Giuseppe To: Loa Andersson , "mpls@ietf.org" , "draft-bryant-mpls-rfc6374-sfl@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl Thread-Index: AQHSyu27gh7taFKM70GhcTnValjhfKH3Aq/Q Date: Tue, 16 May 2017 14:04:38 +0000 Message-ID: <9f24874d23224a358cb9615a6309d721@TELMBXB02RM001.telecomitalia.local> References: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> In-Reply-To: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.239] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRmVeSWpSXmKPExsXCxfdHSfcXm3SkwaUGVouGyTYW/+bOYbZY d/kUm8WtpStZHVg8liz5yeQxa3obWwBTVAOjTWJeXn5JYkmqQkpqcbKtkktmcXJOYmZuapFC SGpOanJ+rpJCZoqtkrGSQkFOYnJqbmpeia1SYkFBal6Kkh2XAgawASrLzFNIzUvOT8nMS7dV 8gz217WwMLXUNVSyCyxNLS7JV8hNLS5OTE/PzFdITVgvmHHo6iuWgks8FfdufGZsYFzB08XI ySEhYCJxauNv1i5GLg4hgalMEn+aDrKBJNgEbCQOvjrBBpIQETjGKHH4+hywhLCAh8SD/9uY QGwRAS+JhVO+skDYRhIXb95gBLFZBFQlenuugNm8AoES/75PB+sVErCQmL+pD6yeU8BSYu6d yWBzGAVkJSbsXgRWzywgLvFi+gl2iOsEJJbsOc8MYYtKvHz8jxXCNpDYunQfC4StKPG0eSqU LSOx8MhkoBoOoDmaEut36UOMVJSY0v2QHeIcQYmTM5+wTGAUnYVk2yyEjllIOmYh6VjAyLKK UTS3wsBQrwQSZZkliTmZiXqZJZsYgWni5spKrh2Mr1c5H2IU4GBU4uGN+y4VKcSaWFZcmXuI UYKDWUmEt5tFOlKINyWxsiq1KD++qDQntfgQow8wvCYyS4km5wNTWF5JvKGJhaWhsYWFkaGF mSkOYSVxXqXDQOMF0oFpKjs1tSC1CGYcEwenVAOjshvvs78xwtsdanpuuhf9qNQXeZbBPs/P e9n7GYJWKzvV1l7517I6QPXC7HiXb35d/Y2v7P8e6L94ufOj+vVd+s4Ld8cY9Ry9Yb3z3T7R g6v28LHNX13reU/C0Yg5UonjW/Ikqey51mdawtP00vsuPmm/mhzHXfJGaLvrZJ6kJQFuJxRa 2cSVWIozEg21mIuKEwGUIsXMQAMAAA== Archived-At: Subject: [mpls] R: woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 14:09:50 -0000 U3VwcG9ydCB0aGUgYWRvcHRpb24gYXMgY28tYXV0aG9yLiANClRoYW5rcywNCg0KR2l1c2Vw cGUNCg0KLS0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCkRhOiBMb2EgQW5kZXJzc29u IFttYWlsdG86bG9hQHBpLm51XSANCkludmlhdG86IHZlbmVyZMOsIDEyIG1hZ2dpbyAyMDE3 IDA4OjU4DQpBOiBtcGxzQGlldGYub3JnOyBkcmFmdC1icnlhbnQtbXBscy1yZmM2Mzc0LXNm bEBpZXRmLm9yZzsgbXBscy1jaGFpcnNAaWV0Zi5vcmcNCk9nZ2V0dG86IHdvZWtpbmcgZ3Jv dXAgYWRvcHRpb24gcG9sbCBvbiBkcmFmdC1icnlhbnQtbXBscy1yZmM2Mzc0LXNmbA0KDQpX b3JraW5nIEdyb3VwLA0KDQpUaGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCBvbiBh ZG9wdGluZyBkcmFmdC1icnlhbnQtDQptcGxzLXJmYzYzNzQtc2ZsLTA0IGFzIGEgTVBMUyB3 b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChz dXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcg bGlzdCAobXBsc0BpZXRmLm9yZykuIFBsZWFzZSBnaXZlIGEgdGVjaG5pY2FsIG1vdGl2YXRp b24gZm9yIHlvdXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBpZiB5b3UgdGhp bmsgdGhhdCB0aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBiZSBhZG9wdGVkIGFzIGEgd29ya2lu ZyBncm91cCBkb2N1bWVudC4NCg0KVGhlcmUgdHdvIElQUiBkaXNjbG9zdXJlIGFnYWluc3Qg dGhpcyBkb2N1bWVudC4NCg0KDQpBbGwgdGhlIGF1dGhvcnMgaGF2ZSBzdGF0ZWQgb24gdGhl IE1QTFMgd2cgbWFpbGluZyBsaXN0IHRoYXQgdGhleSBhcmUgdW5hd2FyZSBvZiBhbnkgb3Ro ZXIgSVBScyB0aGF0IHRob3NlIHRoYXQgaGFzIGJlZW4gZGlzY2xvc2VkDQoNClRoZSB3b3Jr aW5nIGdyb3VwIGFkb3B0aW9uIHBvbGwgZW5kcyBNYXkgMjYsIDIwMTcuDQoNCi9Mb2ENCm1w bHMgd2cgY28tY2hhaXINCi0tIA0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAg ICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQpTZW5pb3IgTVBMUyBFeHBl cnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KSHVhd2VpIFRlY2hub2xv Z2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQoNClF1ZXN0 byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNp dmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8g cXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBx dWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3Jh IGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNv cnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFs IG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3Jhemll LiANCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwg YW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRo ZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcg b3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1h aWwsIFRoYW5rcy4gDQoNClJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVz dGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4NCg== From nobody Tue May 16 07:17:30 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE0F12EBA2; Tue, 16 May 2017 07:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 LoKgdPt25TWZ; Tue, 16 May 2017 07:17:27 -0700 (PDT) Received: from mx01.telecomitalia.it (mx01.telecomitalia.it [217.169.121.10]) (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 3320312EB94; Tue, 16 May 2017 07:12:46 -0700 (PDT) X-AuditID: d9a9790a-bc3ff7000000439d-1f-591b08dd1881 Received: from TELMBXB06RM001.telecomitalia.local ( [10.14.252.35]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx01.telecomitalia.it () with SMTP id D4.D1.17309.DD80B195; Tue, 16 May 2017 16:12:45 +0200 (CEST) From: Cociglio Mauro To: Loa Andersson , "mpls@ietf.org" , "draft-bryant-mpls-rfc6374-sfl@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl Thread-Index: AQHSyu27gh7taFKM70GhcTnValjhfKH3Aq/QgAADScA= Date: Tue, 16 May 2017 14:12:44 +0000 Message-ID: References: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> <9f24874d23224a358cb9615a6309d721@TELMBXB02RM001.telecomitalia.local> In-Reply-To: <9f24874d23224a358cb9615a6309d721@TELMBXB02RM001.telecomitalia.local> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.234] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRmVeSWpSXmKPExsXCxfdHWfcuh3SkwdSFwhYNk20s/s2dw2yx 7vIpNotbS1eyOrB4LFnyk8lj1vQ2tgCmqAZGm8S8vPySxJJUhZTU4mRbJZfM4uScxMzc1CKF kNSc1OT8XCWFzBRbJWMlhYKcxOTU3NS8ElulxIKC1LwUJTsuBQxgA1SWmaeQmpecn5KZl26r 5Bnsr2thYWqpa6hkF1iaWlySr5CbWlycmJ6ema+QmrBeMOPx6hWMBTP4KjZ/PMnYwPiCt4uR k0NCwETi0/P37F2MXBxCAlOZJGbO3swCkmATMJM4s+UZG0hCROAYo8Th63PYQBLCAh4SD/5v YwKxRQS8JBZO+coCYVtJHOz7D1bDIqAqsXLfTbAaXoFAiQmbp4PFhQQaGCW2TAwBsTkFgiTm fbsB1ssoICsxYfciRhCbWUBc4sX0E+wQ1wlILNlznhnCFpV4+fgfK4RtILF16T4WCFtRYsrv nYwQtozEwiOTgWo4gOZoSqzfpQ8xEqik+yE7xDmCEidnPmGZwCg6C8m2WQgds5B0zELSsYCR ZRWjaG6FgaFeCSTKMksSczIT9TJLNjEC08TNlZVcOxhfr3I+xCjAwajEwxv3XSpSiDWxrLgy 9xCjBAezkgivArt0pBBvSmJlVWpRfnxRaU5q8SFGH2B4TWSWEk3OB6awvJJ4QxMLS0NjCwsj QwszUxzCSuK8SoeBxgukA9NUdmpqQWoRzDgmDk6pBkb13fYfy4peMjw8fPlK677I9GXR91YK 8falGW5ete06nznDhoepl9c311W/er92p/HT4nsSurvPGC+8UKVQZFd4qlE1wnPG6oAm//6H GmEh99PD9/THSbtaKpRc155bcqpkm6Ge9fTvnj51abzObwUXSa7XeaX+LHTp77Qj2apvD+9T K4oP+KbEUpyRaKjFXFScCABj0x5lQAMAAA== Archived-At: Subject: [mpls] R: woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 14:17:29 -0000 U3VwcG9ydCB0aGUgYWRvcHRpb24uIA0KUmVnYXJkcy4NCg0KTWF1cm8NCg0KX19fX19fX19f X19fX19fX19fXw0KTWF1cm8gQ29jaWdsaW8NClRJTQ0KVmlhIEcuIFJlaXNzIFJvbW9saSwg Mjc0DQoxMDE0OCAtIFRvcmlubyAoSXRhbHkpDQpUZWwuOiArMzkwMTEyMjg1MDI4DQpNb2Jp bGU6ICszOTMzNTc2Njk3NTENCl9fX19fX19fX19fX19fX19fX18NCg0KLS0tLS1NZXNzYWdn aW8gb3JpZ2luYWxlLS0tLS0NCkRhOiBMb2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBpLm51 XSANCkludmlhdG86IHZlbmVyZMOsIDEyIG1hZ2dpbyAyMDE3IDA4OjU4DQpBOiBtcGxzQGll dGYub3JnOyBkcmFmdC1icnlhbnQtbXBscy1yZmM2Mzc0LXNmbEBpZXRmLm9yZzsgbXBscy1j aGFpcnNAaWV0Zi5vcmcNCk9nZ2V0dG86IHdvZWtpbmcgZ3JvdXAgYWRvcHRpb24gcG9sbCBv biBkcmFmdC1icnlhbnQtbXBscy1yZmM2Mzc0LXNmbA0KDQpXb3JraW5nIEdyb3VwLA0KDQpU aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCBvbiBhZG9wdGluZyBkcmFmdC1icnlh bnQtDQptcGxzLXJmYzYzNzQtc2ZsLTA0IGFzIGEgTVBMUyB3b3JraW5nIGdyb3VwIGRvY3Vt ZW50Lg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0 KSB0byB0aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCAobXBsc0BpZXRmLm9y ZykuIFBsZWFzZSBnaXZlIGEgdGVjaG5pY2FsIG1vdGl2YXRpb24gZm9yIHlvdXIgc3VwcG9y dC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBpZiB5b3UgdGhpbmsgdGhhdCB0aGUgZG9jdW1l bnQgc2hvdWxkIG5vdCBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4N Cg0KVGhlcmUgdHdvIElQUiBkaXNjbG9zdXJlIGFnYWluc3QgdGhpcyBkb2N1bWVudC4NCg0K DQpBbGwgdGhlIGF1dGhvcnMgaGF2ZSBzdGF0ZWQgb24gdGhlIE1QTFMgd2cgbWFpbGluZyBs aXN0IHRoYXQgdGhleSBhcmUgdW5hd2FyZSBvZiBhbnkgb3RoZXIgSVBScyB0aGF0IHRob3Nl IHRoYXQgaGFzIGJlZW4gZGlzY2xvc2VkDQoNClRoZSB3b3JraW5nIGdyb3VwIGFkb3B0aW9u IHBvbGwgZW5kcyBNYXkgMjYsIDIwMTcuDQoNCi9Mb2ENCm1wbHMgd2cgY28tY2hhaXINCi0t IA0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9h QG1haWwwMS5odWF3ZWkuY29tDQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAg ICAgICAgICAgIGxvYUBwaS5udQ0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkg ICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1 b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNv bmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6 aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25p IHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8g cXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRp IGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJv dnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLiANCg0KVGhpcyBlLW1haWwg YW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25s eS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkg ZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMg YW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4gDQoNClJp c3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6gg bmVjZXNzYXJpby4NCg== From nobody Tue May 16 14:51:50 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34782130134; Tue, 16 May 2017 14:51:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: mpls@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149497149320.6703.6316544462704238394@ietfa.amsl.com> Date: Tue, 16 May 2017 14:51:33 -0700 Archived-At: Subject: [mpls] IPR Disclosure ZTE Corporation's Statement about IPR related to draft-jin-jounay-mpls-mldp-hsmp and draft-ietf-mpls-mldp-hsmp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 21:51:33 -0000 Dear Frederic JOUNAY, IJsbrand Wijnands, Nicolai Leymann, Lizhong Jin: An IPR disclosure that pertains to your RFC entitled "LDP Extensions for Hub and Spoke Multipoint Label Switched Path" (RFC7140) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2998/). The title of the IPR disclosure is "ZTE Corporation's Statement about IPR related to draft-jin-jounay-mpls-mldp-hsmp and draft-ietf-mpls-mldp-hsmp" Thank you IETF Secretariat From nobody Tue May 16 17:39:20 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D41129C31 for ; Tue, 16 May 2017 17:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 GMWZb1i1eYTu for ; Tue, 16 May 2017 17:39:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A6E126557 for ; Tue, 16 May 2017 17:35:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGT22627; Wed, 17 May 2017 00:35:39 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 17 May 2017 01:35:39 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 17 May 2017 08:35:31 +0800 From: Lizhenbin To: Loa Andersson , "mpls@ietf.org" Thread-Topic: woeking group adoption poll on draft-bryant-mpls-rfc6374-sfl Thread-Index: AQHSyu27p9G0p2HQc0i8a2EJgj4o06H2fr4AgAE2EbA= Date: Wed, 17 May 2017 00:35:30 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8DF07C86@NKGEML515-MBX.china.huawei.com> References: <99e4ec1e-c7d7-4fd4-3bfc-57c317dead58@pi.nu> <9f24874d23224a358cb9615a6309d721@TELMBXB02RM001.telecomitalia.local> In-Reply-To: <9f24874d23224a358cb9615a6309d721@TELMBXB02RM001.telecomitalia.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.77] 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.0A0B0201.591B9ADC.004E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 772640fde177c265f69e716051939294 Archived-At: Subject: [mpls] =?utf-8?b?562U5aSNOiB3b2VraW5nIGdyb3VwIGFkb3B0aW9uIHBvbGwg?= =?utf-8?q?on_draft-bryant-mpls-rfc6374-sfl?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 00:39:19 -0000 U3VwcG9ydCB0aGUgYWRvcHRpb24gYXMgY28tYXV0aG9yLiANCg0KDQpCZXN0IFJlZ2FyZHMsDQpa aGVuYmluKFJvYmluKQ0KDQoNCg0KLS0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCkRhOiBM b2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBpLm51XSANCkludmlhdG86IHZlbmVyZMOsIDEyIG1h Z2dpbyAyMDE3IDA4OjU4DQpBOiBtcGxzQGlldGYub3JnOyBkcmFmdC1icnlhbnQtbXBscy1yZmM2 Mzc0LXNmbEBpZXRmLm9yZzsgbXBscy1jaGFpcnNAaWV0Zi5vcmcNCk9nZ2V0dG86IHdvZWtpbmcg Z3JvdXAgYWRvcHRpb24gcG9sbCBvbiBkcmFmdC1icnlhbnQtbXBscy1yZmM2Mzc0LXNmbA0KDQpX b3JraW5nIEdyb3VwLA0KDQpUaGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCBvbiBhZG9w dGluZyBkcmFmdC1icnlhbnQtDQptcGxzLXJmYzYzNzQtc2ZsLTA0IGFzIGEgTVBMUyB3b3JraW5n IGdyb3VwIGRvY3VtZW50Lg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0L25v dCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCAobXBsc0Bp ZXRmLm9yZykuIFBsZWFzZSBnaXZlIGEgdGVjaG5pY2FsIG1vdGl2YXRpb24gZm9yIHlvdXIgc3Vw cG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBpZiB5b3UgdGhpbmsgdGhhdCB0aGUgZG9jdW1l bnQgc2hvdWxkIG5vdCBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4NCg0K VGhlcmUgdHdvIElQUiBkaXNjbG9zdXJlIGFnYWluc3QgdGhpcyBkb2N1bWVudC4NCg0KDQpBbGwg dGhlIGF1dGhvcnMgaGF2ZSBzdGF0ZWQgb24gdGhlIE1QTFMgd2cgbWFpbGluZyBsaXN0IHRoYXQg dGhleSBhcmUgdW5hd2FyZSBvZiBhbnkgb3RoZXIgSVBScyB0aGF0IHRob3NlIHRoYXQgaGFzIGJl ZW4gZGlzY2xvc2VkDQoNClRoZSB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIHBvbGwgZW5kcyBNYXkg MjYsIDIwMTcuDQoNCi9Mb2ENCm1wbHMgd2cgY28tY2hhaXINCi0tIA0KDQoNCkxvYSBBbmRlcnNz b24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQpT ZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KSHVh d2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0 DQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBl c2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlh IG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBx dWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFi YmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2Vt ZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRl IGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLiANCg0KVGhpcyBl LW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWlu IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25s eS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxz ZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlz ZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4gDQoNClJpc3BldHRhIGwnYW1i aWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4NCg== From nobody Tue May 16 18:02:52 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0045213147C; Tue, 16 May 2017 18:02:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema To: Cc: mpls@ietf.org, draft-ietf-mpls-tp-aps-updates.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149498296095.6616.14922755167741082096@ietfa.amsl.com> Date: Tue, 16 May 2017 18:02:40 -0700 Archived-At: Subject: [mpls] Secdir last call review of draft-ietf-mpls-tp-aps-updates-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 01:02:41 -0000 Reviewer: Christian Huitema Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is: Ready. This document, draft-ietf-mpls-tp-aps-updates-03, describes a set of fixes to the MPLS Transport Profile (MPLS-TP) Linear Protection defined in RFC 6378. Linear Protection is meant to provide rapid and simple protection switching. MPLS-TP allows end-points in a "protected domain" to coordinate when the traffic shall be sent on the normal path, or switched to the pre-established protection path. The protocol was updated in RFC 7271. The current document updates RFC 7271. It adds a better definition for the initialization of the protocol state, and defines a limited set of changes in the state machine. The security sections states that "No specific security issue is raised in addition to those ones already documented in [RFC7271]. It may be noted that tightening the description of initializing behavior may help to protect networks from re-start attack." I agree with that assessment. From nobody Thu May 18 09:39:26 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0359912AF77; Thu, 18 May 2017 09:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvgDVce6juXy; Thu, 18 May 2017 09:39:23 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0096.outbound.protection.outlook.com [104.47.38.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96321200ED; Thu, 18 May 2017 09:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LJx0uzYZd8kNC+tmJHOeWirSUxaOxGF3c76b11d/Jkw=; b=TjtrOPM/wfrtkNcA78XO4JwMl4VOwieDXAeIGPLO9yEN5QbfPIeK6UyJPzphEFZcvtJuk/aix4WsA6FFpmnNoU2q2vMEV4PBuzohbTCdCDAOFXsBT8tp+XlA0572XpYVT4Rb32gvqldlP5rN7uldafByuQ84IP/84yzT1WG4JYk= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from pboucek-sslvpn-nc.jnpr.net (66.129.241.11) by BN3PR05MB2497.namprd05.prod.outlook.com (10.167.3.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Thu, 18 May 2017 16:32:12 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 May 2017 12:32:09 -0400 Message-ID: CC: , To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN6PR16CA0010.namprd16.prod.outlook.com (10.172.212.148) To BN3PR05MB2497.namprd05.prod.outlook.com (10.167.3.26) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PR05MB2497: X-MS-Office365-Filtering-Correlation-Id: 4f6ec1d2-24fb-4660-6d21-08d49e0b7045 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR05MB2497; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 3:pcJ5bnLnPZ8Hzl0DKlWTYQc/kyIe9C1B4O5pePpPtopcEAHTvco22JQ9wMxDpjg0jLzX4aYFMyuiITbUmE8PI9Y1mxgK/LX0aN45SWpsRh456BhLc8sm/quwRwr6dtr9tgZT4bWeWo8b/ZoVZiZKU0deQEMplZrqqkqbwc1mcUbZfIku8hoOWjK6i/jM40FmbWYnfLYkGDSaCNnfIwdTxWHYZfW/kNL21duMxW+NTOSbLXRi8EcxsN6kS2AyOqdymhMjXckwaLYrKWGvA1xkk04PyG2I6a55zTEuti2ciakSd6ejl1PBvva3rhLJ8S/MLQZJPlyQHJifzEgZoXIpTG49dTiqdKZ+w7rNQwv9l3o=; 25:cUSegfgeWQSy6uUwTmt4OagvkIxjClRJZv46+z/vGed7WZfdA18GMhm5THgR/zMBx/FSGHO74NC5zsJM18/PyNINHDWLDKSMGbuhwj+WNADgHy3IOAJ8pPPRcsbfGHiwyhJ+C+wdB+NyFG+THvCNbQfD++leQHmnDCVBmSb1yfjGY//GDXudl9ZypflXj8PQR7fSZh14CZQ7scN2hwvLnz9odS7Kcfs8epMnd/QxKgbNq81i6nBcE3hb/E90/s4NeqXREwHouVg0wI/1Ir83i1EbzvOeQ+6T+I5PGVaq7uhL7215Yws1LUF7eYBu6aWEk3IqdckpbBgIHc74L3wKHqm87ZDpPQlW4XpPOy9Hzk3ZFr8lEc0VjIjhNmgdqYiCJeLji/7k8KZUrvv8g+3NMw0EVNgjBojWnoxrgF0L4IIl5da72f1vRtyLC6pC2W/rxYCMkAc4NW2iJKaqt52NQIJPAGWO8LX0IVlwvo/W5rE= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 31:db3wpvV1AtErlx6iadHel7N9PVZtnMiaQSsElIMz77/Ek8iq+UMijYwmRvj1QVbue6CAG6vjo2v1uWBs/3F0vOnFsk0/Ai1zJBjy6xOtkNlsfmo24YgbJELzvZyF66+RFVdlsxi2N32s7VY2em5YA+SJQK7kwCIK/71HCQvEkbGS+HqQRcW1fmP0abqXzGguQatd0o9dxsyvrja6ib3ueBN72VdMqK2diah2FIS26MFbSOHSP5MnLVmAYF7VYVFs; 20:vnEguiC8pECH+MyPJ+1lkLxGKBl1ZgSEUUVP7LGUmXYlemSzSwygTv22ftKpNxUkwAq2M3XRdBYjCVbRu+BkJz+5pWCvB0kAyNbTMWGK7eOswh3zbn+jwGEASEAlR0rhDIob7zT3mTjwDdBO6rHuGCQN8bjVqUFzs0reJVL4EupT8HBkpmp8O81L+Iaaujh/mQPEB+6gfaDKvNZ9MQgd+ycn8uxTrXLJY5URCoqQbzS919ltbhyb2735L59zqSLvXqfoiEuBpCfjKuXcOm5P1bAvxn2LWxe4NwidYXwu41HvcaVLj3sjj3YpICXyrOwQmDoqPLUD64BJJ3hDnjgRro2X+dDijA+KS/lp/5fk75uCvKVRID9hD/z3kp+ogdJfpIf0WCsEHoLZsBejajBc5dcVuu+foy9gjfYmV61ohySjJIcs6BKua8BIpRgjtPbA9AxPGXpEBc8g/CRL8EbOmWfvZeqgsSsm7y4CAkfISZntrM0yRmlFxrERSjD0Wli2HLAV07xbbdVLrPv0ACqFRCfBC6heD4U7EfAYFkEOzutnLx0W+ugHQcp69Yb4Hu42cW967pIViu8M3dmG2CWNbRJ8++z8nT6cRvJVKxyltLw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(20161123560025)(6072148); SRVR:BN3PR05MB2497; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2497; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 4:2iaFMbKd1Rwu+XXOeSFqkh2DFcLnvRvZUfwbj2INIbHwzi4PbtFOHOHuY2n1ouzQHcguaReJHM5D/NxTOc0s6u8vOeQOxGdGgpjApEc+52ikkUIQu8y3NNI7Q21ctKTgATDfyJtJVBKIcBZbtypg2xc8AjtUki+QJjVW21PUwEBhqE34qQ+U1y0qcVYNxkKsQT24fQ159v6qwA39PaT9AZpnmoNurLJa++s7INTeN6VaPTduuJdaHvaNkI277m2DJbzgdHdXE63xJskAWYfO/bAQzof4P6MZm/uMnJSZwdofBp9Kxnur1AQuegJIv3MANewfDE1shDV4lDUVwDVYT0c1O2DH5zeIaWNGsRwkNGj2G3KsMwGc58jpWXCKVYMhldQghCsuaU3bi30pW1KIUjVBDvogTrcaaAif2MATMFpOGRV8Wzm+IZhEfc3pABUJD0OVfqjOI1m4kczCJepmcANm2EI9JlOY5Kw4Ovxp9iqm+lSykiCQDk4zqgkAWzmUBW9+duh8lbpECRO8umOPnp6m8ZhLhCqSuJlXlQ7jjvJNClyRlWWOv1R8XgInQXoQtuqz4EJhmRKBFFqGQckbWNMheELYx9vgasuj7mr/Rnl9+l1tFj2CuyJpnE7c2hHHFEGR5gMArBFVcjYDrmEuhy3M+quAeOHoL84r3QBZFkxOGhmRg/lEJpe5fwXZ7QDaEQqB4qjN1fx8dPIgKDKAeGhlhtdvEodgZKmQ49HoLK1fGgEZHEHoRFr30/ySuE1ygVaNc1AuxFRxUaGYf4B9Km9KEwCMPvte91iHytv50oii0a9BobzXb7TrEysLIldW9DuJl4YBkXtpq8Sn2dVKR8ByFjGTQ4adAx4wysgwlOA= X-Forefront-PRVS: 0311124FA9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39860400002)(39450400003)(39850400002)(39840400002)(39400400002)(53754006)(2906002)(189998001)(38730400002)(305945005)(50986999)(966005)(478600001)(66066001)(230783001)(7736002)(110136004)(8676002)(25786009)(54906002)(2351001)(97756001)(81166006)(42186005)(8746002)(6512007)(6306002)(33656002)(50226002)(6506006)(46406003)(5660300001)(53936002)(86362001)(6486002)(6916009)(6666003)(23726003)(53416004)(36756003)(4326008)(6116002)(3846002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2497; H:pboucek-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2497; 23:n2+sgE6Y7ThOEL0QMgq7FFwXSJRrA8GH+irzw/HKC?= =?us-ascii?Q?9pHwKpXqO+j1hjnKbNB0YmId6hfSzzKB9Zs8//V0bZ1dKKyXjjt4mSJO0qlB?= =?us-ascii?Q?bHueV827g/n1+qFRE8UEko1xKy8CANTbIRwaDCMTFfmSYuNy4UmGtUYT2jMX?= =?us-ascii?Q?5LW76TDG9En1knZ9m8/QByjKV9MuhWe7UUuyvCAKOS77yGVLDBuL9DizDERG?= =?us-ascii?Q?o2Shmh98Y9RBdPiuOKQ+E2OlxMlxZn/KMXsqbwKFcthKhXXP0DBDyI7VixJn?= =?us-ascii?Q?RTcbEWJ/HHXj+x6h7z6m/M2WeDnmzQjYWk+pFcsxUozr5hyPZ3Ctnql0rFny?= =?us-ascii?Q?eQ4sKQD/AmRmEutxLSCsbfKyr0tUS8Cy8DA5X6QJCZI75JfZ+WRRd8em8v9z?= =?us-ascii?Q?N7x79tq2uyx66+PB0yit/9GKWWSs4TDeCqhgXDnJLujAouOuqVgBTLEbCvL0?= =?us-ascii?Q?NmjHMAySOJl5ncd/9T2CcNdtB/YFXUGWBgBRCbg9ddwYWyYw7EY4hBDNUlUI?= =?us-ascii?Q?3/R+zVHZLXQejOnv058DVJBYjROr9fPnG8ovbQYqbAdFq89GVdN8C0c+YJQK?= =?us-ascii?Q?dNBcu9bnVR/R3kbVwzAFadJz4fP6D21YBAIs666thQvX+EjnEV1aREt+SGHC?= =?us-ascii?Q?7xvMUhvPA1TsZ0fW1rGla67HTTtTHpaulWJC1ozJXWWNr8sEUFa0Z2mTd69n?= =?us-ascii?Q?DZP9m31Rd//hcLoCePD6/enpLrHCPCXeYGNi0U2b8ct4BfAEdx+oPBJT/qkV?= =?us-ascii?Q?Zi/vGsr10JGH4CD6JSNKoovTOQIWzCw8Pyi8st7gxsqDCU6xQB8LE8C/uCDN?= =?us-ascii?Q?UpfIugiMz3L8i/sqgIdYVroi7lw36Ddblpg3UDHS4SuxNjEjx8NgBRP/UDBz?= =?us-ascii?Q?RqIiPZJg66jaU1cidFozw/euMXv4uOdAVzZ3A6kg1o83Ya3FRHi9OCqBeKfX?= =?us-ascii?Q?5zOeiwkX8Hi+XvVLhu6eG9f6yCZuvgpO7ReiaUSEuYwmYas6Ivf/vNfVDS72?= =?us-ascii?Q?i3MoP+UYWAQDy/icfFOilw055PS7q5pI4fJaXW4AKDk3o3M6MtEHjhx1eu69?= =?us-ascii?Q?ikF0aBczrWTrzC/deMqTpzPJPzSjwqABWqb+x7CxPe4zyaAa5VM8SQPpTC4F?= =?us-ascii?Q?+ZQLgaMR8o=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 6:Dk3FE8hGbYzLux2A1jDjtfEqFLFRn4NpBqqUrqQzVY6t7belF6UOQPgxj77/oXw8GJtPZi893ABkzkEZZowYMYrLSMIdgm55EVnFZJG5rS81VnH7rrKmg0nAn578pA3BocMXDlC84MpWPBjXzgnp1ebf9CahKsfp5pSF/iIbbLd4Pb1ctyDXCfyfp9yHhor4XXXkUeLs3zD+m0yLaCT7RCGkqASr1QfYOZTdWrce/JSdnch6QJpZaAPGuM+EXmGM4K8OgkzFVfYAqs5zCU3YHnL3sIK94JatIhGz6D2gep5ISQwY4TZbxZDfesp10aJ52tZFGEfEUZ+nYX9U5IBnEd8Ku1aguZ3sf5/AbNNw0Ii9l53SlOOUJsRuavXi1dYgpHqHo3SAHbd92TYpWstM6a/ysD5P5mJ9Dpod0UqY/6PLcSYVE8uGjGgQgxjXzZN4Rf1y2Wm8zJ0FOWhhoHl9HeYYBHry0BVWqMm0f3kRk1adbOCJcNWD8UqB93MLvhRFcxTcJxHoZSx/GbRQUQVtcJtAOW9ebqr9BPLxJty7Td8=; 5:pcgTbBo9MIDoFgDnnxh5tiYwKpRCtYvS3URRzmHDBl+IK8Zw/dPcQOjaEheqdeBcQSUW5vn2p6z4Bh/7J8rnJOtjZO00FEBJdstIL7p1s5edRlyT4soHKMmCn7ncGKQs/KDNTtLeWRysmgyuAEMYYg==; 24:ftvV967GcVcAUHjIiD4PeqGY6iQ5+1F1oKN81dhzNnyHCb8zXg/su+bWCVRWabyZahO/GuHW2yGncWg/s6bzqxuFgrkICGZ0vrau6rw28es= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 7:iEPc3KVglWRVSSxX+w4YvBDTt6L+Qk99wpdWTrFwbsz8Woz8U/LehNQcUjUOKF1nU2r8hsCWP+AbtVJCSSIVzgL40fI4ARqyNp62qALpviswrlDtQe2lDVWZr98UlFQ1jQ2BXGEYQf5Ay7qNaKMZBDl9CSqQP2IVc2nTDYFKR86/01Jgb1/rzJT5+5Z0AZmVUpFlSgurj6yQ7BAkz3Dc50iKCsLyFlOQlFSnOsF76k1XEV220kW6KkcoIT/W2QYujrB4gJriVXFczAa5csVpTynvc0Feo2YsxyyU48zOijO5V6bxRF6P166GAO67v6sL6nZbbgN7bVleyAM7nyn5rQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2017 16:32:12.8384 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2497 Archived-At: Subject: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 16:39:25 -0000 Hi All, IDR working group adoption has been requested for = draft-decraene-idr-next-hop-capability-03. Please send your comments to = the IDR mailing list before June 2, 2017. Please remember that we need = affirmative support in order to adopt the draft, so don't be shy. draft datatracker page: = https://datatracker.ietf.org/doc/draft-decraene-idr-next-hop-capability/ slides from IETF-98: = https://www.ietf.org/proceedings/98/slides/slides-98-idr-08-bgp-next-hop-d= ependent-capabilities-00.pdf Since in part this draft specifies a replacement for the Entropy Label = Capability Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 = and deprecated by RFC 7447, I have cc'd the MPLS WG mailing list. Since = the proposed new attribute is a generic container with the ELCA = replacement just the first application, the current draft is targeted to = IDR and not MPLS (this was discussed during IETF-93).=20 Thanks, --John= From nobody Thu May 18 09:42:39 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A1E1287A7; Thu, 18 May 2017 09:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh1WEEYfnHQA; Thu, 18 May 2017 09:42:35 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0118.outbound.protection.outlook.com [104.47.41.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 1C178129A9F; Thu, 18 May 2017 09:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hAkeEpbqDM0OrAde+Yp4TrR12isYLzeSiJCNQpvgc1k=; b=IRuWzW2IKgToSf05nJmY3cgGBO/WXv0Kf6f787rP44EPfjXo370Cz2ZMtTIrFuSih1mYbo2isVeJ29Ei3hiLsoqSzclnahhhTzWYFjt78v9EP3zfqMznmDka4RBmvkzFXPHwsel7S3xJDKEsTsfc9EUNRifYBkb3k+soBDWhFTU= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from pboucek-sslvpn-nc.jnpr.net (66.129.241.11) by SN2PR05MB2511.namprd05.prod.outlook.com (10.166.213.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.8; Thu, 18 May 2017 16:34:55 +0000 From: John G.Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 May 2017 12:34:51 -0400 Message-ID: CC: , To: idr wg MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN6PR11CA0024.namprd11.prod.outlook.com (10.172.17.34) To SN2PR05MB2511.namprd05.prod.outlook.com (10.166.213.20) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN2PR05MB2511: X-MS-Office365-Filtering-Correlation-Id: 0f24d004-edf5-47b0-7405-08d49e0bd13f X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:SN2PR05MB2511; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 3:Xm2PBLkOowPfmxMC/VRNzqy+oH1jPjPrSlckB+ZUi0PBSNgIzRRUTG1b7JJ0mi3UuY0CT4LJvzR/AVTPbv6B1WrtBt4bIyQWNiaQNJodYYEjIAmF3C1IgdY6a8YguoHOcq1pBOHHmB8B23Fip4nLX8A803WAs49ioVxqeo6RFlDvTDbyoN6kDVNUYT8w4bsP6zYZrVl97QfB6PexGplbran53ZBj3e7ulVwhjqk8GaSOC4QkQs2L1Makdx6qnrzYb0NfZEd7qRXbwzfrij3TMGDD7zSGI+pcYa+TwcgWYSEGamO2dExJbSf0DZkWrBb1s0Yyg920I02DbS6oqvhq5EuArNCkjGRfOxMhS8J7kHk=; 25:ucbNvhUeWEX7zdIHLrWRA0iS9TcDqcHJKsXAS3LfZ2jZGtOy7lHBZ04V/2xk4af+QNOzrf9/sMk54DvxZPS+xsygL09uurhbboVzqhN73AMqlFlzA6nHwsJHU3SfDpnEVP3sa+/WOhZ5toCCxTgjuNXkLKYz4OBVzW9plJacOR9N6+HfwyGb/Gvu1uKet0iCtyLapNLdu/PWc3WDQCtYWr4gqG5J1g55YgOdm7AJQrW4BABxRZi7HtK6qqHlseOMB9Qw+U5MjY4y+s0XH/GrmFkH70lA4AN91PJuZrtlwGZSeXtlr7JBCDiQUuZWvpZO/3WNflYwjKr7R25VzYt0h5mZbEKrKhjp2NprDHCwHVVKEFnB64YxETyy0773ZA0cYekaZB7kr5RFxadtQiM6mP4FelWOaoCvl/voq4PiN9Ul74V/ybJAtFC64FMketBAyoIFkXeRmnM1Fmake879diWGxHbv43e+Uz2OCCUVIWE= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 31:235ymXanjSxf7dax7dKEllPOC5CD9ipPKNIsc6iiGaofaChgizTx5qbQMPnvI1ODq+ZkqzTDdmteyFv0VKFNcVTBhZoJZAKUrRqi2Scc63angXGYH8b5W7JmFstnl8rdWrsjAhcET+RFxeU7WpGFz03FCkKVKShWVqp5oxBr0/aDtxFGA+MNY7jlfrmnauHpfFnbQf9+S7yMBO5sjx+ISpG744Esu7yat2+qr+R4h/NyfpjeoaFteyZjkUer4brB; 20:gEqr5fNg05CBJ5E1QsdyYcznyq6paZoHpeP1xMKioRQe0dx2EHEoUDV/WAtNFZaXvDIcYTrM4ukhplIT25fTxSo9mavNZObb1owKd0fJYQrqEMLsD5hyEgkci1V1JqvTL1ABEB5E6lMdbR12LeCY6m0yyqgAgW1rhvHr20sTijEv8gGvkF4PQojzA2PTqrTAYJbJbvev2a2GH3UafTZjqZKL6UtqiUlwwkf7J5bQwNbCWj3Kw8r++CSiJdLSFzXoz9wl3zGrLvTiZ5JcIh/7vm9CWbYQ6J6fUlgz/yLDyr+CjH2R9imsomLWsIeNuAvMiIynAoelTGzpC/zZmvoNbdK2Wz8vMr6R6UGRYGmUGxWOnvr60HNohOrQF0mjXWXFutlz5FYQP67GC1l3MLJ5OrvyOTbjorcZP4N3B33bRWhBmOcetFxw2wADer/+4LMxR0Imqfx0RdfbrFHUQ7aD5DZwvFgA8lrQ7FpbzolHGY9vuYfFFPQRP995DEGys1oOV1VRL1uhejbXgpXh0Fza2BtDbRMmCoScqDdmTDrjI/1PZlmPXmSK2VtGRGsoiSBsdJ29Bq37ftXMyi8UfLl6ifPyTqCqjNwwE9n86P62Mh8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:SN2PR05MB2511; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2511; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 4:CAGSZ61X6PlT8ZJRzk5sJXzWiDweY99IAPtmDfAWbsLKC7NjldKrbjMENGpKNZY/YPJkZWPlGb8OPjCQU9Vony802B744M+aFYmBq/MtaY41fdi16xdNuLCN46vL/rI2EUYfthoQageT8PyVV0NkorEt1VP53sI0yVf3tZHU4hKrubJZMp0V1TKKO6kJzcEK5/vQ0DmtGyLdXEC4nP8erdh6PgW1nVVu0Y0XA0I7OZogVeC1haZH4qHvTL/LXn2u4mzHyjwoDCqtt/F9bYBy7GLfC6ZD+lP7zFQaRFPuDGgKpGD52mb8Jk6CeBfOSmhlj/VcaAnsNdY/XvJb4glOk5ftq2p1vpOXQnLa0WIT9SPzUpKJXyYj//8KoIfAb7vvVDZdVqkJnGocS9ZBAEQnJ2bIbGhJwb9LfoCps0gRkSKLuDyf5LqDRw4xpnWHoPHpRY5qUorR5tUrVsF8EvUcdHDZGcmQzU0V2NfBFWMATjt0RScaSKX9HPqSmaCaSoWGTX71W8AblDBiD3fG/aF27JZSjkQPDF/0mvXLT2dkUQ1bqLDGrlUN99+e3hAnGBm4pNOwgfe7MxCMlWW4pcRAEprgw90h2KeGvU/SWzKK57IIbBFo4O77gghlRLofDuQ2EdvdSSpEagbr75Mf0IXzKI9do9Y5FwZlOQunp/Ou42uBob/YiJeODX/xP5Q8nsK4lrocUqHmVnUcy043y9Rg3rsiirOfqhYyLTlHlZQnHyGEtj89S7okP451nfBp7CV590X0ZGWCYK2XgFdcmqZkFWaPWxBHUXeAITloTvzjCrV0XAxPJenLwhjMQqNcJGCGVewr3MucF9dnw7eBoE8AGtlh9YlhpIwAL8ikHMHwYRg= X-Forefront-PRVS: 0311124FA9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39840400002)(39860400002)(39850400002)(39450400003)(39400400002)(53754006)(230783001)(25786009)(4326008)(450100002)(6916009)(6666003)(478600001)(36756003)(46406003)(189998001)(66066001)(2906002)(6506006)(53936002)(6306002)(6512007)(54906002)(966005)(6486002)(81166006)(8676002)(8746002)(50226002)(305945005)(33656002)(5660300001)(7736002)(50986999)(38730400002)(110136004)(97756001)(86362001)(23726003)(42186005)(3846002)(6116002)(53416004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2511; H:pboucek-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2511; 23:ij8a+jUiXesY9Bx3cPo90xEsHiV2YH3rtJOerzxM3?= =?us-ascii?Q?0LzA2ogZ3JYKFNAISGDuFDqOIBuVVuDcQce2gQnsQzm3ItLHYA1zMUPkopPV?= =?us-ascii?Q?zVAWQLtcFxW6+1ug3I/TUbLbPG3QJeZFDDvUyrMl4jKGXBAlfuZTrqGIyLul?= =?us-ascii?Q?VcZjYpDUpdX0qta9tvV559BA9Y2Y1KMkpwHj3/5p8gDvEMDMuXjI2Kyow664?= =?us-ascii?Q?vwEyAP6mICSqmlbazlV/hJUXipW43rgHdUAawGf/M7dTVM0eB+ozfYhjHve0?= =?us-ascii?Q?Bg/EGlkHNOv6p/2IE0pn9Ljn2UmkKAvv1myoN/s/d7ngTql2GmUUg2qlcMrO?= =?us-ascii?Q?+T0I41u0HQ2vebDcj89YtR09Answ1Q4tTc5LGytLul19KFYJo9BKJBfg+dYP?= =?us-ascii?Q?vtyZpJkOasNAk8+HdW4T2lJiMYb0d4tSshvDBBZ4ErLvG0kPP71avTiiKIlG?= =?us-ascii?Q?U4yU295tp3YAbogQToHOFehvQ4gxbmHmCMhComn45HJU1cZ52jwLXOREXvWF?= =?us-ascii?Q?2b7DWFWbKD4cVI8kZsR8Wyh6nEDS2mpRfwATW2Npt8gNHVh1EhV8QTYYRb8z?= =?us-ascii?Q?LJtY3r/LJVTSC6crIHZpCq0wbfINc2rAZTiusmp+Ni09ppbpDIK+xgkGdB3C?= =?us-ascii?Q?1FTAqlFKz/giR/bNsdMo4VGFiUW4heGmPH5msRR/LkJe1+mrHu9Zfz9cYnu5?= =?us-ascii?Q?tpqs68zo/VUpTYohbjfLirP1qjCroRaTvPifTtIeE8CFHO6ckLxqV5Hp1A94?= =?us-ascii?Q?do3swwfIhSlFyZDHy7SS51IiK3lIaZOMSPOkZgMR9EBKwkNOFSLwYYOJ/uXS?= =?us-ascii?Q?AmzpJ7NP7PGLn1KNBShyM6StTxkdnC59/bgZU03AO+nygZ9eeYIetAU1DGqj?= =?us-ascii?Q?iR6sljEKHB3WpdxjyYf/XQRyG2IvgiY5eNkaVSgHWPdiJbSunioaNE+EtnjI?= =?us-ascii?Q?1uKyu5OpXvrOURJpZ/uk85MR2SsS5DBzBGxVOaInF/oorcfNRv4+cilv2joq?= =?us-ascii?Q?YafRna35yBQtdce9MB+9nh6a/jFlWsYzTyFgYnNwKrppPI9rpx3PN2pktZs1?= =?us-ascii?Q?OR+KtWMeAgtgYSw3E0j0JLq6LBQL+povpMHH6q5J8DqKvzQXQklqAnPf/u8m?= =?us-ascii?Q?4Slw0vwGiWVkXe6rWL0bKm1FCcAWKY6?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 6:bJrRDABAFyCx6Jj7x32ZAaeuWlWb0JgRVeKgQGyMUGfu4W/A9qgMaYwkv0vBAsFuWOAVgU3kiac7W+RMq0lDds2jGKfYYOrA/0ArYvg99naFTyZl6SW4RPUp4QHPfV26TfZUpCToFfphA5CFLZGkV3kVtXsCwJuRGHdWsJHT4qle7MShx8QJbMyWP4HOcxDazX+UeEBxZzDURDXaqKCNmbCMmj+lEpVLVDjxzeGErruiWE+clOQ49hupirGJPxHsFYzgV5SX6Kcg3mHsr2m6iP0vG9ljyDioFt6zcsdSbdI2rJx5fZI6yOVSm/lNoucYsxQ41sYPc/Us275lVnMOIq9w2GTJuCQSD5M43UVy+3KkBQUJYOQFoGCTFM4Hu/KRIgjsbpM6Pr2L4CuBizXYL9LY2xsjFxf2a+QHxi06bP14QYeKiFmgQ/KrArYQQRaHQjwyQF/voYI6LeZZN8oGLRmM7ZkYqTBeD+eJ0CchJOKETGdUnCfi+VS4ne/P+ImmS854TeHTVOhgAQAA3AUH8ZRdQiPHBpQgBp+t0KqXAQQ=; 5:JxkPyoRyfF4E01qUXMszhqpfw1J+idBDL2UsRDIlap6UymMkt3pYqBXsO/8fXR/9A9Nny+GhjIJ9lKbQvFkyq16UlK4ojZ6fDaBoQWhNuB+96+4us9DFORzfhuYIW9pTbt/vDXiGcm7sJoTLr3JfVQ==; 24:lGmZIyPNaS6pfKZfE211UsD3tuEhJc9evQb2hAGFHcBYnOfLe6iO/5U71ktplQr48/TXQZQ56j5WErXgSSl/+giSEHYpqeCOadAwsBm6XRw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 7:7IrOF1rWsh8geYLzq00cAtfuZ3EjrnBqUJYPXYayoAKr7rnENfzHfSiFw3vSe4eIXaPd5HDsL/+96AWSTTelQ++llFY8CWj94J4IrdXdB4UnbpoEM81QGNtj3yQVsbzvevqnUeHyOpWYSvcRMJ/2+JBrgWGsL3aMJ12alUKbnDcuuKCYGtGF/9/0OSVQUMdYljJO0QgRfikVJ0xTMmrmTojC/0tVmFAEpP9wXZAyvvH5FlKDGx9wplUR+Mgk8bIH+pb9zrOc4n86bCA9LnoEOR6NmAWLIOE30yPfENjj6R6N8ISz/JUXdI9+msmyztOL8kYdl3Td5XXWHdfWcG53Kg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2017 16:34:55.3984 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2511 Archived-At: Subject: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 16:42:38 -0000 [resending, correcting draft@ietf address] Hi All, IDR working group adoption has been requested for = draft-decraene-idr-next-hop-capability-03. Please send your comments to = the IDR mailing list before June 2, 2017. Please remember that we need = affirmative support in order to adopt the draft, so don't be shy. draft datatracker page: = https://datatracker.ietf.org/doc/draft-decraene-idr-next-hop-capability/ slides from IETF-98: = https://www.ietf.org/proceedings/98/slides/slides-98-idr-08-bgp-next-hop-d= ependent-capabilities-00.pdf Since in part this draft specifies a replacement for the Entropy Label = Capability Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 = and deprecated by RFC 7447, I have cc'd the MPLS WG mailing list. Since = the proposed new attribute is a generic container with the ELCA = replacement just the first application, the current draft is targeted to = IDR and not MPLS (this was discussed during IETF-93).=20 Thanks, --John= From nobody Thu May 18 09:44:52 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91ACB1273B1; Thu, 18 May 2017 08:49:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: "Daniele Ceccarelli" , "Julien Meuric" , "Jonathan Hardwick" , "Fatai Zhang" , "George Swallow" , "Nicolai Leymann" , "Loa Andersson" , "Lou Berger" , "Vishnu Pavan Beeram" , "JP Vasseur" Cc: Alvaro Retana , Deborah Brungard , david.sinicrope@ericsson.com, Julien Meuric , Multiprotocol Label Switching Discussion List , David Sinicrope , Jonathan Hardwick , Fatai Zhang , George Swallow , Path Computation Element Discussion List , Vishnu Beeram , Alia Atlas , Daniele Ceccarelli , Traffic Engineering Architecture and Signaling Discussion List , Loa Andersson , Lou Berger , Common Control and Measurement Plane Discussion List , michael.fargano@centurylink.com, JP Vasseur , Nicolai Leymann X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149512259248.6703.11615243589366763423.idtracker@ietfa.amsl.com> Date: Thu, 18 May 2017 08:49:52 -0700 Archived-At: X-Mailman-Approved-At: Thu, 18 May 2017 09:44:50 -0700 Subject: [mpls] New Liaison Statement, "Liaison to IETF on Flex Ethernet for IP/MPLS Networks" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 15:49:53 -0000 Title: Liaison to IETF on Flex Ethernet for IP/MPLS Networks Submission Date: 2017-05-18 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1523/ From: Michael Fargano To: Vishnu Pavan Beeram , Lou Berger ,Nicolai Leymann ,Loa Andersson ,George Swallow ,Jonathan Hardwick ,JP Vasseur ,Julien Meuric ,Daniele Ceccarelli ,Fatai Zhang Cc: Alvaro Retana ,Deborah Brungard ,Julien Meuric ,Multiprotocol Label Switching Discussion List ,David Sinicrope ,Jonathan Hardwick ,Fatai Zhang ,George Swallow ,Path Computation Element Discussion List ,JP Vasseur ,Vishnu Beeram ,Alia Atlas ,Daniele Ceccarelli ,Traffic Engineering Architecture and Signaling Discussion List ,Loa Andersson ,Lou Berger ,Common Control and Measurement Plane Discussion List ,Nicolai Leymann Response Contacts: michael.fargano@centurylink.com, david.sinicrope@ericsson.com Technical Contacts: Purpose: For information Body: At our 2017Q2 meeting in Taipei, the Broadband Forum initiated a new project entitled “Applicability of Flex Ethernet in IP/MPLS Networks”. This project addresses the architecture, requirements and use cases in IP/MPLS networks to deploy Flex Ethernet (a.k.a. FlexE) as a new type of nodal interface. OIF published “Flex Ethernet Implementation Agreement” (IA OIF-FLEXE-01.0) in March 2016. Our project intends to use FlexE and its related aspects specified by that document including data plane characteristics and provisioning requirements in IP/MPLS networks, including: • Interconnection between routers on FlexE interfaces in IP/MPLS networks. • End-to-end MPLS LSPs on FlexE-based channels. • Control plane protocols (e.g. RSVP-TE, PCEP) including their extensions and their applicability aspects for managing FlexE based MPLS LSP. • Aspects of using FlexE interfaces and FlexE-based MPLS LSP as a network slicing instance. • Co-existence of FlexE-based and other data link based MPLS LSPs and their operation. • New services and applications that FlexE-capable IP/MPLS networks can enable. We are sending this liaison to inform you about our intention. We noticed that there are IETF drafts at CCAMP WG that propose to use GMPLS protocols with extensions to support FlexE based MPLS LSP; we are interested in learning the progress and status of the progress. Sincerely, Michael Fargano, Broadband Forum Technical Committee Chair Attachments: Liaison to IETF CCAMP on FlexE-Cheng-Huawei https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-05-18-broadband-forum-mpls-ccamp-pce-teas-liaison-to-ietf-on-flex-ethernet-for-ipmpls-networks-attachment-1.pdf From nobody Thu May 18 09:50:16 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AB3129B5B; Thu, 18 May 2017 09:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3-hmPsERPM0; Thu, 18 May 2017 09:50:11 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B03129B11; Thu, 18 May 2017 09:43:54 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v4IGgsLM031596; Thu, 18 May 2017 12:43:36 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 2ahcqh67e3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 May 2017 12:43:36 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4IGhWno001045; Thu, 18 May 2017 12:43:33 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v4IGhPwe000876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 May 2017 12:43:29 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 18 May 2017 16:43:17 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.22]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0319.002; Thu, 18 May 2017 12:43:17 -0400 From: "UTTARO, JAMES" To: "John G. Scudder" , "idr@ietf.org" CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@bgp.nu" Thread-Topic: [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHSz/VbbtgMRJCYzUCZ6VS0E4P+OKH6S7fg Date: Thu, 18 May 2017 16:43:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.199.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-18_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705180109 Archived-At: Subject: Re: [mpls] [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 16:50:14 -0000 Support.. Jim Uttaro -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Thursday, May 18, 2017 12:32 PM To: idr@ietf.org Cc: mpls@ietf.org; draft-decraene-idr-next-hop-capability@bgp.nu Subject: [Idr] Working Group adoption call for draft-decraene-idr-next-hop-= capability-03 Hi All, IDR working group adoption has been requested for draft-decraene-idr-next-h= op-capability-03. Please send your comments to the IDR mailing list before = June 2, 2017. Please remember that we need affirmative support in order to = adopt the draft, so don't be shy. draft datatracker page: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-= 3A__datatracker.ietf.org_doc_draft-2Ddecraene-2Didr-2Dnext-2Dhop-2Dcapabili= ty_&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3Ds7ZzB4JbPv3nYuoSx5Gy8Q&m=3DuE= t9VJjdOq8-CRAQO7tO6Nh_vCyKhYyJhsqSbexoXqM&s=3DlHgIBjcYVBRZZK0HaMd0vxoXEUTG2= KYrTSurKXc4kQQ&e=3D=20 slides from IETF-98: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A_= _www.ietf.org_proceedings_98_slides_slides-2D98-2Didr-2D08-2Dbgp-2Dnext-2Dh= op-2Ddependent-2Dcapabilities-2D00.pdf&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjI= g&r=3Ds7ZzB4JbPv3nYuoSx5Gy8Q&m=3DuEt9VJjdOq8-CRAQO7tO6Nh_vCyKhYyJhsqSbexoXq= M&s=3D_q8MPlyS0Hia3dat0d2Hnk59t5roNiWw8MQMA_A9Dwk&e=3D=20 Since in part this draft specifies a replacement for the Entropy Label Capa= bility Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 and dep= recated by RFC 7447, I have cc'd the MPLS WG mailing list. Since the propos= ed new attribute is a generic container with the ELCA replacement just the = first application, the current draft is targeted to IDR and not MPLS (this = was discussed during IETF-93).=20 Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_idr&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3Ds7ZzB4JbPv3nYuoSx5G= y8Q&m=3DuEt9VJjdOq8-CRAQO7tO6Nh_vCyKhYyJhsqSbexoXqM&s=3DCxg9u0gjAhIpPkWIKjD= lSKDLNtsKfnxk2R4kaVnjFjA&e=3D=20 From nobody Thu May 18 11:53:37 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0708012420B; Thu, 18 May 2017 11:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPCI8_50niGP; Thu, 18 May 2017 11:53:26 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 B980912EB1A; Thu, 18 May 2017 11:48:22 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id f27so6703645pfe.0; Thu, 18 May 2017 11:48:22 -0700 (PDT) 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=kpRIb8omIABQFqQf3LnKigb3FP/MPO+fxJdzRvztEYc=; b=KkCW7dc7gwRz+4ohaU4tbiMlZcLLWNgbm00LoBQhY2Bmj795FF4+lRlH8kBtnOQ5JB TmNpXN9tGXw4T3HEwsFj2HqCbeuViEqd35fn1NbcNwYu5umlO02s07+1lVilXU0hFOKe LN+RUToHqvrs8ssxsu8dgf/aM3KBC/O6Q98nTFf0XNMm4STPcXSjKqGv2Bg/KlF4Cznf QFlmfy5AtU0adF7X3iT7vMZXqOab01XnmaYRxiZml1Qe/RirmSAhRYFRdl/cMLJ3dYK7 LeMK8uiCYD34aWEiL/fWwaQ3nbaSFTWSfhPRPEy4Fj/tvsLGJNidVYrqRjBRtZahqc27 +nuw== 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=kpRIb8omIABQFqQf3LnKigb3FP/MPO+fxJdzRvztEYc=; b=APei/Lu5JlAsYRL+PQAwHA03P9KRM4ychBczxXeNVgnJTuO1gWJM9Zi4kquLUVBjEk zbrtpI2uKxLFLZTwu9dCare/KRMoL9N57WfQwAeJQ91t/+wmOHAEu8TzOHVJF5GQAFxW GprQFE+Haiu4cyu9nK6fVGLnJFg/mlLG3BdR8iI9rCg/KH2e//r3LQGFOARQZX+q5wA9 hbIXMYvLvi/eOoIGQt5+HVPGK7BQ/azGe0/MpQE10JXzpzW/O2XwhFJMS7p2El4lqojh Z5hICiwa9sCSxMylp8Ap0sMZs9kvofWW+jXDRFU5LocXCRSm89S2bi2+9gdZNNtp7cJP XNEQ== X-Gm-Message-State: AODbwcD4xeHev9kpP0UhUrfLplAwPOHCBqIjxqyLJPyTty29KaN278rI uq0HRN14VmjbANWSHcc= X-Received: by 10.98.138.150 with SMTP id o22mr6056854pfk.120.1495133301861; Thu, 18 May 2017 11:48:21 -0700 (PDT) Received: from ?IPv6:2607:fb90:21a2:5f1d:92e:2836:e74a:ae21? ([2607:fb90:21a2:5f1d:92e:2836:e74a:ae21]) by smtp.gmail.com with ESMTPSA id x80sm12213118pff.105.2017.05.18.11.48.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 11:48:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (14E304) In-Reply-To: Date: Thu, 18 May 2017 11:48:18 -0700 Cc: idr wg , mpls@ietf.org, draft-decraene-idr-next-hop-capability@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <74A5B0E5-5526-454F-B11F-52B8BBFB7500@gmail.com> References: To: "John G.Scudder" Archived-At: Subject: Re: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 18:53:28 -0000 John, Yes/support Regards, Jeff > On May 18, 2017, at 09:34, John G.Scudder wrote: >=20 > [resending, correcting draft@ietf address] >=20 > Hi All, >=20 > IDR working group adoption has been requested for draft-decraene-idr-next-= hop-capability-03. Please send your comments to the IDR mailing list before J= une 2, 2017. Please remember that we need affirmative support in order to ad= opt the draft, so don't be shy. >=20 > draft datatracker page: https://datatracker.ietf.org/doc/draft-decraene-id= r-next-hop-capability/ > slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-98-= idr-08-bgp-next-hop-dependent-capabilities-00.pdf >=20 > Since in part this draft specifies a replacement for the Entropy Label Cap= ability Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 and dep= recated by RFC 7447, I have cc'd the MPLS WG mailing list. Since the propose= d new attribute is a generic container with the ELCA replacement just the fi= rst application, the current draft is targeted to IDR and not MPLS (this was= discussed during IETF-93).=20 >=20 > Thanks, >=20 > --John > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu May 18 12:38:30 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E07E129BCE; Thu, 18 May 2017 12:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAKMT-hU-r4T; Thu, 18 May 2017 12:38:26 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0120.outbound.protection.outlook.com [104.47.1.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 3EF0D129C39; Thu, 18 May 2017 12:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pU0drFTAxOpm9t4+JUKRj32PUuqEWUGGu/J2lU0NWGo=; b=QLPlGD8GhElPSQ9NB6EXxUb3Dvx2woCeKPxI9aTcw0NN5m3e6TNf2BWXFMLfmRy3a9pS2IeS/+2XBCHg8L/yoYBTr3wxl6E/h1eOaAWIKk1+MTVZzSTfkcKDyxNvB+QudriZkjZOzAzLJSeh5YGYeCg8rbXF0vQpxnVnlakfqS8= Received: from AM2PR07MB0961.eurprd07.prod.outlook.com (10.162.37.144) by AM2PR07MB0963.eurprd07.prod.outlook.com (10.162.37.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Thu, 18 May 2017 19:32:43 +0000 Received: from AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::8ca8:abc5:c3c7:9d6d]) by AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::8ca8:abc5:c3c7:9d6d%15]) with mapi id 15.01.1124.007; Thu, 18 May 2017 19:32:43 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: "John G. Scudder" , "idr@ietf.org" CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@bgp.nu" Thread-Topic: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHSz/VTfsG4m8/9b0SvgXKKVya+jKH6ex4h Date: Thu, 18 May 2017 19:32:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [13.69.77.72] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0963; 7:Q6g/PDd4Js7rM75Ycg5P8KzKwBULoUXzTGdUB9A8xFt+FxlRG50KUQgX3IdTsNp0NA/bng7yZQXqp5SDwtShj4fmo4IOFSv+r7/GAKeN6BmRGLCrMQe9rZLqphNQVRFScOd7/ACL7r5jvxRNwst4CFCYWMtXZH1Krm4X3pLHcuGaohrxtHL9NEZrOTjvoQ11lvb2Ctjjt4QuGWkArVcikCQJmd5s/5fhcMKNIy2+sRNg5jtaAak1p7JB9pRhKTtqGuM22Zo26MBowcWFC9UYg75y+uwlD/leaSmDMu+MpsAdC+UGqZRypEaATQAjKa7xrf8VAvXhpUfNyaXm5oeDHA== x-ms-traffictypediagnostic: AM2PR07MB0963: x-ms-office365-filtering-correlation-id: 6cccd0cf-45be-439e-4e9b-08d49e24a760 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:AM2PR07MB0963; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(138986009662008)(81439100147899); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(6072148); SRVR:AM2PR07MB0963; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0963; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39400400002)(39840400002)(39450400003)(39860400002)(377454003)(53754006)(8936002)(66066001)(53936002)(3846002)(2501003)(99286003)(6116002)(102836003)(55016002)(8666007)(966005)(2906002)(3280700002)(33656002)(230783001)(189998001)(3660700001)(6246003)(606005)(6306002)(45080400002)(74316002)(38730400002)(7696004)(25786009)(53546009)(229853002)(6436002)(478600001)(76176999)(54356999)(7736002)(2950100002)(7906003)(50986999)(8676002)(81166006)(4326008)(86362001)(54896002)(6506006)(5250100002)(9686003)(54906002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0963; H:AM2PR07MB0961.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB0961C7CEDDBC9B1E33CA1EDC83E40AM2PR07MB0961eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2017 19:32:42.9419 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0963 Archived-At: Subject: Re: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 19:38:28 -0000 --_000_AM2PR07MB0961C7CEDDBC9B1E33CA1EDC83E40AM2PR07MB0961eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as coauthor Get Outlook for iOS ________________________________ From: mpls on behalf of John G. Scudder Sent: Thursday, May 18, 2017 6:32:09 PM To: idr@ietf.org Cc: mpls@ietf.org; draft-decraene-idr-next-hop-capability@bgp.nu Subject: [mpls] Working Group adoption call for draft-decraene-idr-next-hop= -capability-03 Hi All, IDR working group adoption has been requested for draft-decraene-idr-next-h= op-capability-03. Please send your comments to the IDR mailing list before = June 2, 2017. Please remember that we need affirmative support in order to = adopt the draft, so don't be shy. draft datatracker page: https://datatracker.ietf.org/doc/draft-decraene-idr= -next-hop-capability/ slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-98-i= dr-08-bgp-next-hop-dependent-capabilities-00.pdf Since in part this draft specifies a replacement for the Entropy Label Capa= bility Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 and dep= recated by RFC 7447, I have cc'd the MPLS WG mailing list. Since the propos= ed new attribute is a generic container with the ELCA replacement just the = first application, the current draft is targeted to IDR and not MPLS (this = was discussed during IETF-93). Thanks, --John _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_AM2PR07MB0961C7CEDDBC9B1E33CA1EDC83E40AM2PR07MB0961eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support as coauthor

Get Ou= tlook for iOS
From: mpls <mpls-bounc= es@ietf.org> on behalf of John G. Scudder <jgs@juniper.net>
Sent: Thursday, May 18, 2017 6:32:09 PM
To: idr@ietf.org
Cc: mpls@ietf.org; draft-decraene-idr-next-hop-capability@bgp.nu
Subject: [mpls] Working Group adoption call for draft-decraene-idr-n= ext-hop-capability-03
 
Hi All,

IDR working group adoption has been requested for draft-decraene-idr-next-h= op-capability-03. Please send your comments to the IDR mailing list before = June 2, 2017. Please remember that we need affirmative support in order to = adopt the draft, so don't be shy.

draft datatracker page: https://datatracker.ietf.org/doc/draft-decraene-idr-next-hop-capability/
slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-98-idr-08-bgp-next-hop-de= pendent-capabilities-00.pdf

Since in part this draft specifies a replacement for the Entropy Label Capa= bility Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 and dep= recated by RFC 7447, I have cc'd the MPLS WG mailing list. Since the propos= ed new attribute is a generic container with the ELCA replacement just the first application, the current draft is= targeted to IDR and not MPLS (this was discussed during IETF-93).

Thanks,

--John
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org= /mailman/listinfo/mpls
 --_000_AM2PR07MB0961C7CEDDBC9B1E33CA1EDC83E40AM2PR07MB0961eurp_-- From nobody Thu May 18 20:42:56 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD6C12EC93; Thu, 18 May 2017 20:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iYNT4Vuvsj0; Thu, 18 May 2017 20:42:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5331912EC05; Thu, 18 May 2017 20:36:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNI51776; Fri, 19 May 2017 03:36:31 +0000 (GMT) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 19 May 2017 04:36:30 +0100 Received: from DGGEML508-MBX.china.huawei.com ([169.254.3.58]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0301.000; Fri, 19 May 2017 11:36:24 +0800 From: Mach Chen To: "John G.Scudder" , idr wg CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@ietf.org" Thread-Topic: [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHSz/XO6alx6m5qqUe3FpQYrOWE/aH7AbaQ Date: Fri, 19 May 2017 03:36:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0206.591E6840.0065, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.58, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1ada34d609d191a64797e5ab1479bf87 Archived-At: Subject: Re: [mpls] [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 03:42:49 -0000 Hi John, I have read the draft and think it's useful, support the adoption! Best regards, Mach > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G.Scudder > Sent: Friday, May 19, 2017 12:35 AM > To: idr wg > Cc: mpls@ietf.org; draft-decraene-idr-next-hop-capability@ietf.org > Subject: [Idr] Working Group adoption call for draft-decraene-idr-next-ho= p- > capability-03 >=20 > [resending, correcting draft@ietf address] >=20 > Hi All, >=20 > IDR working group adoption has been requested for draft-decraene-idr- > next-hop-capability-03. Please send your comments to the IDR mailing list > before June 2, 2017. Please remember that we need affirmative support in > order to adopt the draft, so don't be shy. >=20 > draft datatracker page: https://datatracker.ietf.org/doc/draft-decraene-i= dr- > next-hop-capability/ > slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-98= - > idr-08-bgp-next-hop-dependent-capabilities-00.pdf >=20 > Since in part this draft specifies a replacement for the Entropy Label > Capability Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 a= nd > deprecated by RFC 7447, I have cc'd the MPLS WG mailing list. Since the > proposed new attribute is a generic container with the ELCA replacement > just the first application, the current draft is targeted to IDR and not = MPLS > (this was discussed during IETF-93). >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu May 18 23:19:32 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEC5128959; Thu, 18 May 2017 23:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, 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 iZVPqeAghDEU; Thu, 18 May 2017 23:19:22 -0700 (PDT) Received: from relais-inet.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 06527129B4C; Thu, 18 May 2017 23:15:17 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 5C8DFC070E; Fri, 19 May 2017 08:15:15 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 365704005B; Fri, 19 May 2017 08:15:15 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0339.000; Fri, 19 May 2017 08:15:14 +0200 From: To: "John G. Scudder" , "idr@ietf.org" CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@bgp.nu" Thread-Topic: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHSz/VUMuKlyuGzfEiqqaYW51iPraH7LoQw Date: Fri, 19 May 2017 06:15:14 +0000 Message-ID: <16074_1495174515_591E8D73_16074_7054_1_88132E969123D14D9BD844E1CD516EDE1435D575@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 06:19:24 -0000 Hi, Support. Cheers, Christian. -----Message d'origine----- De=A0: mpls [mailto:mpls-bounces@ietf.org] De la part de John G. Scudder Envoy=E9=A0: jeudi 18 mai 2017 18:32 =C0=A0: idr@ietf.org Cc=A0: mpls@ietf.org; draft-decraene-idr-next-hop-capability@bgp.nu Objet=A0: [mpls] Working Group adoption call for draft-decraene-idr-next-ho= p-capability-03 Hi All, IDR working group adoption has been requested for draft-decraene-idr-next-h= op-capability-03. Please send your comments to the IDR mailing list before = June 2, 2017. Please remember that we need affirmative support in order to = adopt the draft, so don't be shy. draft datatracker page: https://datatracker.ietf.org/doc/draft-decraene-idr= -next-hop-capability/ slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-98-i= dr-08-bgp-next-hop-dependent-capabilities-00.pdf Since in part this draft specifies a replacement for the Entropy Label Capa= bility Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 and dep= recated by RFC 7447, I have cc'd the MPLS WG mailing list. Since the propos= ed new attribute is a generic container with the ELCA replacement just the = first application, the current draft is targeted to IDR and not MPLS (this = was discussed during IETF-93).=20 Thanks, --John _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ 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 May 18 23:54:39 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB93127775; Thu, 18 May 2017 23:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 4wY6xjAGO3gx; Thu, 18 May 2017 23:54:29 -0700 (PDT) Received: from relais-inet.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 2382B12EB9B; Thu, 18 May 2017 23:49:58 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 9159D1C03D8; Fri, 19 May 2017 08:49:56 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 6C9854004C; Fri, 19 May 2017 08:49:56 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0339.000; Fri, 19 May 2017 08:49:56 +0200 From: To: John G.Scudder , idr wg CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@ietf.org" Thread-Topic: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHSz/XFR+Oe8TWL5EePssWVkm2tf6H7OE7A Date: Fri, 19 May 2017 06:49:54 +0000 Message-ID: <30171_1495176596_591E9594_30171_3117_1_9E32478DFA9976438E7A22F69B08FF921DDBB1C0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 06:54:31 -0000 Support -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of John G.Scudder Sent: Thursday, May 18, 2017 18:35 To: idr wg Cc: mpls@ietf.org; draft-decraene-idr-next-hop-capability@ietf.org Subject: [mpls] Working Group adoption call for draft-decraene-idr-next-hop= -capability-03 [resending, correcting draft@ietf address] Hi All, IDR working group adoption has been requested for draft-decraene-idr-next-h= op-capability-03. Please send your comments to the IDR mailing list before = June 2, 2017. Please remember that we need affirmative support in order to = adopt the draft, so don't be shy. draft datatracker page: https://datatracker.ietf.org/doc/draft-decraene-idr= -next-hop-capability/ slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-98-i= dr-08-bgp-next-hop-dependent-capabilities-00.pdf Since in part this draft specifies a replacement for the Entropy Label Capa= bility Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 and dep= recated by RFC 7447, I have cc'd the MPLS WG mailing list. Since the propos= ed new attribute is a generic container with the ELCA replacement just the = first application, the current draft is targeted to IDR and not MPLS (this = was discussed during IETF-93).=20 Thanks, --John _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ 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 Fri May 19 00:05:09 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6216C129521; Fri, 19 May 2017 00:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGUgFURvyWIQ; Fri, 19 May 2017 00:04:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7AD012943E; Thu, 18 May 2017 23:59:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGX30328; Fri, 19 May 2017 06:59:57 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 19 May 2017 07:59:56 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 19 May 2017 14:59:49 +0800 From: Lizhenbin To: "John G.Scudder" , idr wg CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@ietf.org" Thread-Topic: [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHS0FIOt4Cv3ITG7EuOJlGgfY6Dj6H7OhCw Date: Fri, 19 May 2017 06:59:49 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8DF08365@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.77] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.591E97ED.0067, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3a10ae5535c0fae47502216cb648b2a1 Archived-At: Subject: [mpls] =?gb2312?b?tPC4tDogW0lkcl0gV29ya2luZyBHcm91cCBhZG9wdGlv?= =?gb2312?b?biBjYWxsIGZvciBkcmFmdC1kZWNyYWVuZS1pZHItbmV4dC1ob3AtY2FwYWJp?= =?gb2312?b?bGl0eS0wMw==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 07:05:00 -0000 SGksDQoNClN1cHBvcnQuDQoNCkJlc3QgUmVnYXJkcywNClpoZW5iaW4oUm9iaW4pDQoNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gRy5TY3VkZGVyDQo+IFNlbnQ6IEZyaWRheSwg TWF5IDE5LCAyMDE3IDEyOjM1IEFNDQo+IFRvOiBpZHIgd2cgPGlkckBpZXRmLm9yZz4NCj4gQ2M6 IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LWRlY3JhZW5lLWlkci1uZXh0LWhvcC1jYXBhYmlsaXR5QGll dGYub3JnDQo+IFN1YmplY3Q6IFtJZHJdIFdvcmtpbmcgR3JvdXAgYWRvcHRpb24gY2FsbCBmb3Ig DQo+IGRyYWZ0LWRlY3JhZW5lLWlkci1uZXh0LWhvcC0NCj4gY2FwYWJpbGl0eS0wMw0KPiANCj4g W3Jlc2VuZGluZywgY29ycmVjdGluZyBkcmFmdEBpZXRmIGFkZHJlc3NdDQo+IA0KPiBIaSBBbGws DQo+IA0KPiBJRFIgd29ya2luZyBncm91cCBhZG9wdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9y IGRyYWZ0LWRlY3JhZW5lLWlkci0gDQo+IG5leHQtaG9wLWNhcGFiaWxpdHktMDMuIFBsZWFzZSBz ZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIElEUiBtYWlsaW5nIA0KPiBsaXN0IGJlZm9yZSBKdW5l IDIsIDIwMTcuIFBsZWFzZSByZW1lbWJlciB0aGF0IHdlIG5lZWQgYWZmaXJtYXRpdmUgDQo+IHN1 cHBvcnQgaW4gb3JkZXIgdG8gYWRvcHQgdGhlIGRyYWZ0LCBzbyBkb24ndCBiZSBzaHkuDQo+IA0K PiBkcmFmdCBkYXRhdHJhY2tlciBwYWdlOiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZGVjcmFlbmUtaWRyLQ0KPiBuZXh0LWhvcC1jYXBhYmlsaXR5Lw0KPiBzbGlk ZXMgZnJvbSBJRVRGLTk4OiANCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgv c2xpZGVzL3NsaWRlcy05OC0NCj4gaWRyLTA4LWJncC1uZXh0LWhvcC1kZXBlbmRlbnQtY2FwYWJp bGl0aWVzLTAwLnBkZg0KPiANCj4gU2luY2UgaW4gcGFydCB0aGlzIGRyYWZ0IHNwZWNpZmllcyBh IHJlcGxhY2VtZW50IGZvciB0aGUgRW50cm9weSBMYWJlbCANCj4gQ2FwYWJpbGl0eSBBdHRyaWJ1 dGUgKEVMQ0EpIHRoYXQgd2FzIGRlZmluZWQgYnkgdGhlIE1QTFMgV0cgaW4gUkZDIA0KPiA2Nzkw IGFuZCBkZXByZWNhdGVkIGJ5IFJGQyA3NDQ3LCBJIGhhdmUgY2MnZCB0aGUgTVBMUyBXRyBtYWls aW5nIGxpc3QuIA0KPiBTaW5jZSB0aGUgcHJvcG9zZWQgbmV3IGF0dHJpYnV0ZSBpcyBhIGdlbmVy aWMgY29udGFpbmVyIHdpdGggdGhlIEVMQ0EgDQo+IHJlcGxhY2VtZW50IGp1c3QgdGhlIGZpcnN0 IGFwcGxpY2F0aW9uLCB0aGUgY3VycmVudCBkcmFmdCBpcyB0YXJnZXRlZCANCj4gdG8gSURSIGFu ZCBub3QgTVBMUyAodGhpcyB3YXMgZGlzY3Vzc2VkIGR1cmluZyBJRVRGLTkzKS4NCj4gDQo+IFRo YW5rcywNCj4gDQo+IC0tSm9obg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBJZHIgbWFpbGluZyBsaXN0DQo+IElkckBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K From nobody Fri May 19 07:20:10 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE388127599; Fri, 19 May 2017 07:20:08 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 VHSSRet5SFao; Fri, 19 May 2017 07:20:06 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10137.outbound.protection.outlook.com [40.107.1.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8325412700F; Fri, 19 May 2017 07:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QS/nP/SqgGMAhiu2eKxYjt5CxQMkYkhlyX45W07n8M0=; b=mEWOxXBNf3KGRIA7CMoneztE31s5icEnpj7gkw0lGfDh21Yb8wm8W9XAXyJ4Ik57FmzGKQnZ1wfYkpHohKfwI9PpbZ6Sdy/gGowy61p2OLNKxJzL3WSccJvGxMJrRChJw9/mLlG97Ox3zJll1wvsSFzL9W4IQz0zQJL4KPfRR3Y= Received: from DB4PR07MB314.eurprd07.prod.outlook.com (10.141.234.15) by DB4PR07MB316.eurprd07.prod.outlook.com (10.141.234.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Fri, 19 May 2017 14:20:02 +0000 Received: from DB4PR07MB314.eurprd07.prod.outlook.com ([fe80::d934:270e:e6a2:4f43]) by DB4PR07MB314.eurprd07.prod.outlook.com ([fe80::d934:270e:e6a2:4f43%16]) with mapi id 15.01.1124.007; Fri, 19 May 2017 14:20:02 +0000 From: "Bocci, Matthew (Nokia - GB)" To: Stewart Bryant , Eric C Rosen , "mpls@ietf.org" , "draft-bryant-mpls-sfl-framework@ietf.org" CC: "mpls-chairs@ietf.org" Thread-Topic: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-framework-04 Thread-Index: AQHSyXyubno0L7diUE+waDh2NhVRQ6HvPNmAgAAnSoCADG+ngA== Date: Fri, 19 May 2017 14:20:02 +0000 Message-ID: References: <74FA86D7-E0FB-4E5D-A5D3-64324CB2A656@nokia.com> <49a42b8b-13b2-f436-d6e9-a84c4d978c13@juniper.net> <83752d0b-4b6e-808a-15ac-0f7e632388ed@gmail.com> In-Reply-To: <83752d0b-4b6e-808a-15ac-0f7e632388ed@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 authentication-results: spf=none (sender IP is ) smtp.mailfrom=matthew.bocci@nokia.com; x-originating-ip: [81.131.107.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB316; 7:MYsR6Ma24jVd+Uy4vLdsozwKfh9nJU3AvyiROob02yNz6H4jnoo6+Qn4G63z7pbUAtoX5zgicSbJyLUDmKN7HXpTMjRAvSRXjQP17dK4NHllPwqcWDhkLHOWqacCPcazqDlK1xcp+PvbfY/YAht52NBIjiCn0Jm3vHjJk9murNQI7/agsUp6Gqjk0K8hwbl67c+jjdFh3w2MGYFWghVDCLJUMW6XisA37lFC+mpP2iChY/GJnNeAQnuUf5+RyKLk5FssgIxH/ggxjuEClV/uxxD71OYU1C8h4znV5HESaTLcRruxOcuMdRhYEK2Xu9IInF651sl2LF6eNoJVQwA9Mg== x-ms-traffictypediagnostic: DB4PR07MB316: x-ms-office365-filtering-correlation-id: d3252a4e-6897-432a-0937-08d49ec223d8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB4PR07MB316; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(138986009662008)(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(6072148); SRVR:DB4PR07MB316; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB316; x-forefront-prvs: 031257FE13 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39850400002)(39400400002)(39840400002)(39860400002)(189002)(199003)(24454002)(377454003)(76176999)(8676002)(33656002)(50986999)(4001350100001)(54356999)(189998001)(36756003)(229853002)(7736002)(2906002)(2950100002)(2900100001)(3660700001)(478600001)(99286003)(3280700002)(81166006)(8936002)(6436002)(8666007)(6306002)(2201001)(230783001)(25786009)(6246003)(2501003)(1941001)(6512007)(54896002)(5250100002)(38730400002)(5660300001)(4326008)(53936002)(102836003)(3846002)(6116002)(6506006)(6486002)(86362001)(83506001)(39060400002)(53546009)(66066001)(83716003)(82746002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR07MB316; H:DB4PR07MB314.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E2F245601EAA4D30983A49314F976496nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2017 14:20:02.6099 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB316 Archived-At: Subject: Re: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-framework-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 14:20:09 -0000 --_000_E2F245601EAA4D30983A49314F976496nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpYywgU3Rld2FydA0KDQpGcm9tOiBTdGV3YXJ0IEJyeWFudCA8c3Rld2FydC5icnlhbnRAZ21h aWwuY29tPg0KRGF0ZTogVGh1cnNkYXksIDExIE1heSAyMDE3IGF0IDE4OjI1DQpUbzogRXJpYyBD IFJvc2VuIDxlcm9zZW5AanVuaXBlci5uZXQ+LCAiQm9jY2ksIE1hdHRoZXcgKE5va2lhIC0gR0Ip IiA8bWF0dGhldy5ib2NjaUBub2tpYS5jb20+LCAibXBsc0BpZXRmLm9yZyIgPG1wbHNAaWV0Zi5v cmc+LCAiZHJhZnQtYnJ5YW50LW1wbHMtc2ZsLWZyYW1ld29ya0BpZXRmLm9yZyIgPGRyYWZ0LWJy eWFudC1tcGxzLXNmbC1mcmFtZXdvcmtAaWV0Zi5vcmc+DQpDYzogIm1wbHMtY2hhaXJzQGlldGYu b3JnIiA8bXBscy1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNdIE1QTFMtUlQg cmV2aWV3IG9mIGRyYWZ0LWJyeWFudC1tcGxzLXNmbC1mcmFtZXdvcmstMDQNCg0KDQoNCg0KT24g MTEvMDUvMjAxNyAxNjowNCwgRXJpYyBDIFJvc2VuIHdyb3RlOg0KT24gNS8xMC8yMDE3IDc6MDAg QU0sIEJvY2NpLCBNYXR0aGV3IChOb2tpYSAtIEdCKSB3cm90ZToNCg0KVGhlIEVMIGlzIGVmZmVj dGl2ZWx5IHNheWluZyDigJxhbGwgb3RoZXIgdGhpbmdzIGJlaW5nIGVxdWFsLCBoZXJlIGlzIHNv bWUgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0byBkaXN0aW5ndWlzaCBmbG93c+KAnS4gSXQgaXMg aW4gYWRkaXRpb24gdG8sIGJ1dCBub3QgYW4gYWx0ZXJuYXRpdmUgdG8gdGhlIHJlc3Qgb2YgdGhl IGxhYmVsIHN0YWNrLg0KDQpEbyB5b3UgdGhpbmsgdGhlcmUgaXMgYW55IHNpdHVhdGlvbiBpbiB3 aGljaCAoYSkgb25lIGhhcyBnaXZlbiB0aGUgc2FtZSBFTCB2YWx1ZSB0byB0d28gcGFja2V0cywg YnV0IChiKSBvbmUgd291bGQgYmUgcGVyZmVjdGx5IGhhcHB5IHRvIHNlZSB0aGUgcGFja2V0cyBk ZWxpdmVyZWQgb3V0IG9mIG9yZGVyPyAgIE9yIHRvIHB1dCBpdCBhbm90aGVyIHdheSwgb25jZSBh biBpbmdyZXNzIG5vZGUgaGFzIGFzc2lnbmVkIGEgcGFydGljdWxhciBFTCB2YWx1ZSB0byBhIHBh cnRpY3VsYXIgc2V0IG9mIHBhY2tldHMsIGlzIHRoZXJlIGFueSBhZHZhbnRhZ2UgdG8gaW5jbHVk aW5nIG90aGVyIGZpZWxkcyBpbiB0aGUgRUNNUCBoYXNoPw0KDQpJIHRoaW5rIG5vdCwgYW5kIHRo dXMgd2FzIHN1cnByaXNlZCB3aGVuIEkgZm91bmQgb3V0IHRoYXQgRUwgZGlkIG5vdCBvZiBpdHNl bGYgZGVmaW5lIHRoZSBmbG93IHRvIHRoZSBmb3J3YXJkZXJzLiBDbGVhcmx5IEkgc2hvdWxkIGhh dmUgcmVhZCBSRkMNCg0KTUI+IEnigJltIG5vdCBlbnRpcmVseSBzdXJlIG9mIHRoYXQuIE9uZSBj b3VsZCBlbnZpc2FnZSBzaXR1YXRpb25zIHdoZXJlIGR1cGxpY2F0ZSBmbG93cyBhcmUgYXNzaWdu ZWQgdGhlIHNhbWUgRUwgdmFsdWUgYnV0IHNlbnQgb24gZGlmZmVyZW50IExTUHMgb3ZlciB0aGUg c2FtZSBwYXRoIG9yIHN1YnNldCBvZiBhIHBhdGguIEhvd2V2ZXIsIHRoZXJlIGlzIG5vIHJlYXNv biB0byBtYWludGFpbiB0aGUgb3JkZXIgb2YgdGhlIHBhY2tldHMgYmV0d2VlbiB0aGUgZGlmZmVy ZW50IGZsb3dzIHdpdGggdGhlIHNhbWUgRUwgdmFsdWUuIE9mIGNvdXJzZSwgdGhpcyBkb2VzbuKA mXQgYnJlYWsgdGhlIFNGTCBhcHBsaWNhdGlvbiBhbmQgc28gbWF5YmUgdGhhdCBpcyBub3QgcmVs ZXZhbnQgdG8gdGhpcyBkcmFmdC4NCg0KSSBkb27igJl0IHRoaW5rIHRoYXQgaXQgaXMgcmVhc29u YWJsZSB0byBtYW5kYXRlIHRoYXQgTFNScyBvbmx5IGNvbnNpZGVyIHRoZSBFTCBhbmQgaWdub3Jl IGFsbCBvdGhlciBsYWJlbHMgaW4gdGhlIHN0YWNrIGdpdmVuIHRoZSBpbXBhY3Qgb24gdGhlIGRl cGxveWVkIGJhc2UNCg0KQ2VydGFpbmx5IG9uZSBjYW5ub3QgbWFuZGF0ZSB0aGUgZGVwbG95ZWQg YmFzZSB0byBiZSBvdGhlciB0aGFuIGl0IGlzLCBidXQgaXQgd291bGQgYmUgaW50ZXJlc3Rpbmcg dG8ga25vdyB3aGV0aGVyIHRoZSBjb21tb24gaW1wbGVtZW50YXRpb24gaXMgcmVhbGx5IHRoZSBw cmVmZXJyZWQgYmVoYXZpb3IuDQoNCg0KQXMgd2UgZG8gbW9yZSB3aXRoIE1QTFMgaXQgc2VlbXMg dG8gbWUgdGhhdCB3ZSB3b3VsZCBsaWtlIHRoZSBFTCB0byBzZXQgdGhlIHBhdGggZm9yIHRoZSBm bG93LCB3aXRoIG90aGVyIGxhYmVscyBiZWluZyBpZ25vcmVkLiBBYm9ydGluZyB0aGUgaGFzaCBj YWxjdWxhdGlvbiBvbiBmaW5kaW5nIGFuIEVMSSBhbmQganVzdCB1c2luZyB0aGUgbmV4dCBsYWJl bCBpcyBzaW1wbGUgb3BlcmF0aW9uLCBzaW1wbGVyIHRoYW4gZm9yIGV4YW1wbGUgc2tpcHBpbmcg dGhlIFNQTHMsIGFuZCBpbiB0aGUgY2FzZSBvZiBhbiBleHRlbmRlZCBTUEwgYW5kIHRoZSBsYWJl bCB0aGF0IGZvbGxvd3MuDQoNCk1CPiBJIGFncmVlIGl0IGRvZXNu4oCZdCBzZWVtIGFyZHVvdXMg YXQgYWxsLCBidXQgdGhlIG90aGVyIGJlaGF2aW91ciBpcyBhbGxvd2VkIGJ5IFJGQzY3OTAuIFBl cmhhcHMgeW91IGNvdWxkIHVwZGF0ZSB0aGUgdGV4dCBpbiBCdWxsZXQgMiBvZiBTZWN0aW9uIDQg dG8gZXhwbGljaXRseSBzdGF0ZSB0aGF0IFNGTCBhcHBsaWNhdGlvbnMgcmVxdWlyZSB0aGF0IHRo ZSBpbnRlcnZlbmluZyBNUExTIG5ldHdvcmsgTVVTVCBsb2FkIGJhbGFuY2Ugc29sZWx5IGJhc2Vk IG9uIHRoZSBlbnRyb3B5IGxhYmVsIChzbyB0aGF04oCZcyBzdHJpY3RlciB0aGFuIHRoZSBjdXJy ZW50IHRleHQgaW4gU2VjdGlvbiA0LjIgb2YgUkZDIDY3OTApLg0KDQpCZXN0IHJlZ2FyZHMsDQoN Ck1hdHRoZXcNCg0KDQoNCg0KDQoNCg== --_000_E2F245601EAA4D30983A49314F976496nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <4A553FCD468C974B98BCF8D6E84BFB6C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5 NS4wcHQgODQyLjBwdDsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0i Izk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5FcmljLCBTdGV3 YXJ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5TdGV3YXJ0IEJyeWFu dCAmbHQ7c3Rld2FydC5icnlhbnRAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVy c2RheSwgMTEgTWF5IDIwMTcgYXQgMTg6MjU8YnI+DQo8Yj5UbzogPC9iPkVyaWMgQyBSb3NlbiAm bHQ7ZXJvc2VuQGp1bmlwZXIubmV0Jmd0OywgJnF1b3Q7Qm9jY2ksIE1hdHRoZXcgKE5va2lhIC0g R0IpJnF1b3Q7ICZsdDttYXR0aGV3LmJvY2NpQG5va2lhLmNvbSZndDssICZxdW90O21wbHNAaWV0 Zi5vcmcmcXVvdDsgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtkcmFmdC1icnlhbnQtbXBs cy1zZmwtZnJhbWV3b3JrQGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1icnlhbnQtbXBscy1zZmwt ZnJhbWV3b3JrQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7bXBscy1jaGFpcnNA aWV0Zi5vcmcmcXVvdDsgJmx0O21wbHMtY2hhaXJzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6IDwvYj5SZTogW21wbHNdIE1QTFMtUlQgcmV2aWV3IG9mIGRyYWZ0LWJyeWFudC1tcGxzLXNm bC1mcmFtZXdvcmstMDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHA+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMS8wNS8yMDE3IDE2OjA0LCBFcmlj IEMgUm9zZW4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gNS8xMC8yMDE3IDc6MDAgQU0sIEJvY2NpLCBNYXR0aGV3IChOb2tpYSAtIEdCKSB3 cm90ZTo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBFTCBpcyBlZmZlY3RpdmVseSBzYXlp bmcg4oCcYWxsIG90aGVyIHRoaW5ncyBiZWluZyBlcXVhbCwgaGVyZSBpcyBzb21lIGFkZGl0aW9u YWwgaW5mb3JtYXRpb24gdG8gZGlzdGluZ3Vpc2ggZmxvd3PigJ0uIEl0IGlzIGluIGFkZGl0aW9u IHRvLCBidXQgbm90IGFuIGFsdGVybmF0aXZlIHRvIHRoZSByZXN0IG9mIHRoZSBsYWJlbCBzdGFj ay48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQpEbyB5b3UgdGhpbmsgdGhlcmUgaXMgYW55IHNpdHVhdGlvbiBpbiB3aGljaCAo YSkgb25lIGhhcyBnaXZlbiB0aGUgc2FtZSBFTCB2YWx1ZSB0byB0d28gcGFja2V0cywgYnV0IChi KSBvbmUgd291bGQgYmUgcGVyZmVjdGx5IGhhcHB5IHRvIHNlZSB0aGUgcGFja2V0cyBkZWxpdmVy ZWQgb3V0IG9mIG9yZGVyPyZuYnNwOyZuYnNwOyBPciB0byBwdXQgaXQgYW5vdGhlciB3YXksIG9u Y2UgYW4gaW5ncmVzcyBub2RlIGhhcyBhc3NpZ25lZCBhIHBhcnRpY3VsYXIgRUwgdmFsdWUNCiB0 byBhIHBhcnRpY3VsYXIgc2V0IG9mIHBhY2tldHMsIGlzIHRoZXJlIGFueSBhZHZhbnRhZ2UgdG8g aW5jbHVkaW5nIG90aGVyIGZpZWxkcyBpbiB0aGUgRUNNUCBoYXNoPzxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSSB0aGluayBub3QsIGFu ZCB0aHVzIHdhcyBzdXJwcmlzZWQgd2hlbiBJIGZvdW5kIG91dCB0aGF0IEVMIGRpZCBub3Qgb2Yg aXRzZWxmIGRlZmluZSB0aGUgZmxvdyB0byB0aGUgZm9yd2FyZGVycy4gQ2xlYXJseSBJIHNob3Vs ZCBoYXZlIHJlYWQgUkZDPGJyPg0KPGJyPg0KTUImZ3Q7IEnigJltIG5vdCBlbnRpcmVseSBzdXJl IG9mIHRoYXQuIE9uZSBjb3VsZCBlbnZpc2FnZSBzaXR1YXRpb25zIHdoZXJlIGR1cGxpY2F0ZSBm bG93cyBhcmUgYXNzaWduZWQgdGhlIHNhbWUgRUwgdmFsdWUgYnV0IHNlbnQgb24gZGlmZmVyZW50 IExTUHMgb3ZlciB0aGUgc2FtZSBwYXRoIG9yIHN1YnNldCBvZiBhIHBhdGguIEhvd2V2ZXIsIHRo ZXJlIGlzIG5vIHJlYXNvbiB0byBtYWludGFpbiB0aGUgb3JkZXIgb2YgdGhlIHBhY2tldHMgYmV0 d2Vlbg0KIHRoZSBkaWZmZXJlbnQgZmxvd3Mgd2l0aCB0aGUgc2FtZSBFTCB2YWx1ZS4gT2YgY291 cnNlLCB0aGlzIGRvZXNu4oCZdCBicmVhayB0aGUgU0ZMIGFwcGxpY2F0aW9uIGFuZCBzbyBtYXli ZSB0aGF0IGlzIG5vdCByZWxldmFudCB0byB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgZG9u4oCZdCB0aGluayB0 aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8gbWFuZGF0ZSB0aGF0IExTUnMgb25seSBjb25zaWRlciB0 aGUgRUwgYW5kIGlnbm9yZSBhbGwgb3RoZXIgbGFiZWxzIGluIHRoZSBzdGFjayBnaXZlbiB0aGUg aW1wYWN0IG9uIHRoZSBkZXBsb3llZCBiYXNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48YnI+DQpDZXJ0YWlubHkgb25lIGNhbm5vdCBtYW5kYXRlIHRoZSBkZXBsb3llZCBiYXNlIHRv IGJlIG90aGVyIHRoYW4gaXQgaXMsIGJ1dCBpdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBrbm93 IHdoZXRoZXIgdGhlIGNvbW1vbiBpbXBsZW1lbnRhdGlvbiBpcyByZWFsbHkgdGhlIHByZWZlcnJl ZCBiZWhhdmlvci4mbmJzcDsNCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQXMgd2UgZG8gbW9yZSB3aXRoIE1QTFMg aXQgc2VlbXMgdG8gbWUgdGhhdCB3ZSB3b3VsZCBsaWtlIHRoZSBFTCB0byBzZXQgdGhlIHBhdGgg Zm9yIHRoZSBmbG93LCB3aXRoIG90aGVyIGxhYmVscyBiZWluZyBpZ25vcmVkLiBBYm9ydGluZyB0 aGUgaGFzaCBjYWxjdWxhdGlvbiBvbiBmaW5kaW5nIGFuIEVMSSBhbmQganVzdCB1c2luZyB0aGUg bmV4dCBsYWJlbCBpcyBzaW1wbGUgb3BlcmF0aW9uLCBzaW1wbGVyIHRoYW4gZm9yIGV4YW1wbGUg c2tpcHBpbmcNCiB0aGUgU1BMcywgYW5kIGluIHRoZSBjYXNlIG9mIGFuIGV4dGVuZGVkIFNQTCBh bmQgdGhlIGxhYmVsIHRoYXQgZm9sbG93cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TUImZ3Q7 IEkgYWdyZWUgaXQgZG9lc27igJl0IHNlZW0gYXJkdW91cyBhdCBhbGwsIGJ1dCB0aGUgb3RoZXIg YmVoYXZpb3VyIGlzIGFsbG93ZWQgYnkgUkZDNjc5MC4gUGVyaGFwcyB5b3UgY291bGQgdXBkYXRl IHRoZSB0ZXh0IGluIEJ1bGxldCAyIG9mIFNlY3Rpb24gNCB0byBleHBsaWNpdGx5IHN0YXRlIHRo YXQgU0ZMIGFwcGxpY2F0aW9ucyByZXF1aXJlIHRoYXQgdGhlIGludGVydmVuaW5nIE1QTFMgbmV0 d29yayBNVVNUDQogbG9hZCBiYWxhbmNlIHNvbGVseSBiYXNlZCBvbiB0aGUgZW50cm9weSBsYWJl bCAoc28gdGhhdOKAmXMgc3RyaWN0ZXIgdGhhbiB0aGUgY3VycmVudCB0ZXh0IGluIFNlY3Rpb24g NC4yIG9mIFJGQyA2NzkwKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCByZWdhcmRzLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXR0aGV3PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E2F245601EAA4D30983A49314F976496nokiacom_-- From nobody Fri May 19 07:35:45 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75A5128616; Fri, 19 May 2017 07:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 5HkPk6g7opTa; Fri, 19 May 2017 07:35:42 -0700 (PDT) Received: from relais-inet.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 48F181286AB; Fri, 19 May 2017 07:35:42 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id E8F1A16047E; Fri, 19 May 2017 16:35:40 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id C3A5E18006C; Fri, 19 May 2017 16:35:40 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0339.000; Fri, 19 May 2017 16:35:40 +0200 From: To: John G.Scudder , idr wg CC: "draft-decraene-idr-next-hop-capability@ietf.org" , "mpls@ietf.org" Thread-Topic: Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHSz/XDMEbdgHHx3UaZwRey+FXRtKH7uesw Date: Fri, 19 May 2017 14:35:39 +0000 Message-ID: <31901_1495204540_591F02BC_31901_10655_1_53C29892C857584299CBF5D05346208A31D1D7CA@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 14:35:44 -0000 Support as coauthor > -----Original Message----- > From: John G.Scudder [mailto:jgs@juniper.net] > Sent: Thursday, May 18, 2017 6:35 PM > To: idr wg > Cc: draft-decraene-idr-next-hop-capability@ietf.org; mpls@ietf.org > Subject: Working Group adoption call for draft-decraene-idr-next-hop-cap= ability-03 >=20 > [resending, correcting draft@ietf address] >=20 > Hi All, >=20 > IDR working group adoption has been requested for draft-decraene-idr-nex= t-hop- > capability-03. Please send your comments to the IDR mailing list before = June 2, 2017. Please > remember that we need affirmative support in order to adopt the draft, s= o don't be shy. >=20 > draft datatracker page: https://datatracker.ietf.org/doc/draft-decraene-= idr-next-hop- > capability/ > slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-9= 8-idr-08-bgp-next- > hop-dependent-capabilities-00.pdf >=20 > Since in part this draft specifies a replacement for the Entropy Label C= apability Attribute > (ELCA) that was defined by the MPLS WG in RFC 6790 and deprecated by RFC= 7447, I have > cc'd the MPLS WG mailing list. Since the proposed new attribute is a gen= eric container with > the ELCA replacement just the first application, the current draft is ta= rgeted to IDR and not > MPLS (this was discussed during IETF-93). >=20 > Thanks, >=20 > --John ___________________________________________________________________________= ______________________________________________ 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 Fri May 19 09:56:09 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1E6129526; Fri, 19 May 2017 09:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kr2c8R8Qq7I3; Fri, 19 May 2017 09:56:05 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0116.outbound.protection.outlook.com [104.47.34.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3023E1294F4; Fri, 19 May 2017 09:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=k6NQKnZXKS7/4CcHpZgnx3DLwjiOWLU4hOklFOWhE0I=; b=iwsTZxIqIyZYxBKxj+TjyMDWCxU2cx2wYDlbzJlnuPehEK/xH4Oi2kQW9OLUhOUZX4deYj7yly30c/eGa9tMedIw5e+3BIK+Q934rnYjcnhrlxwGFqLAWCPbrB/N7s2kc8GMS/RQEZGDlEv19BAqHGjyoyQx4H0PC2StGXEZ4Is= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.39.62] (66.129.241.12) by BY2PR05MB2181.namprd05.prod.outlook.com (10.166.112.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.5; Fri, 19 May 2017 16:56:02 +0000 To: "Bocci, Matthew (Nokia - GB)" , Stewart Bryant , "mpls@ietf.org" , "draft-bryant-mpls-sfl-framework@ietf.org" References: <74FA86D7-E0FB-4E5D-A5D3-64324CB2A656@nokia.com> <49a42b8b-13b2-f436-d6e9-a84c4d978c13@juniper.net> <83752d0b-4b6e-808a-15ac-0f7e632388ed@gmail.com> Cc: "mpls-chairs@ietf.org" From: Eric C Rosen Message-ID: <43c90b31-bac3-d543-4aa9-f6485c2b7628@juniper.net> Date: Fri, 19 May 2017 12:55:58 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BN6PR1301CA0023.namprd13.prod.outlook.com (10.174.84.164) To BY2PR05MB2181.namprd05.prod.outlook.com (10.166.112.9) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY2PR05MB2181: X-MS-Office365-Filtering-Correlation-Id: 10c3ad3a-4000-43d6-2b6a-08d49ed7ef4d X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BY2PR05MB2181; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 3:rnWPpb+5o6ejDFm4bdxcTw514gTYLijfx8anl/rDGgj5zkiAjNN6sEBKcSvYOPwI67YPU0dvo8j0mO5ekkVfqWlB4zMO7uwBpIqEr3qf8bXmhnaE32bEd0BdgHRIx/feAf+HqDSiQlfHNe9m+MnaV8IO2ZKE7zMJiFnMHm28AIrbj78Ma/5LIcnMuFuJMj6IGsGswerGEYKtRjEWSHv7LW0obSFpxxFE7/jWMzfhaEk8m1hfby0WvA92qK9GIe5I4WZXt1DedbMVh6Y+BCByFHDzl/jwz+x3J+vjAj3jIbEHcL1YDaGK2ypVFP5KWASwG9fUV56h5hMW+fZrdIgEp/VARnbLSSuuaZ9Soxmhv50=; 25:uqnxvtXcgeU0FvcZ525zcnayjEP9ya2/o6SAJaefxceHz102TJyXJ9w15nTBIBYvAhNgAybTTyPVH/9orgHdGIq4Kec3TEwTfZ3LTYYvMp6AcgFhP+1vcBNteeKyYc4FdIM7XWCj6OQA4ADwudw+1hvA80Uw3BC2WEwZPTvCpm0pfYy3Ta9sGyVw+0VzQ8oDo82kcDu57lKPSBOnyQ5XoKO5Hbt6Cw2KbuF6FBflnGuqYivU6gmj+QOyGbK0RJz5pHjLBWVWngP+xcINpHjf5y3S7Z7QTRk0B4nn/SgTj0FFDq60jZBA5xn4UhxQ1KtT5gmTLZs1S1tRCwWBVKUIjVi8e8lob1hYLWyrWcVfB87dJup7ouXCC3nnYMmws6SXUIT8ucdeKD7irYv4+M0ausyCp3vnGR4D26FkgerJkNr6InAPGcHv8Af2wqvFOyCGlNacQ+RFHmijqWITug9iBor42SMozsLHpxkU5H771l0= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 31:Ye9Bnbz8s3jDfOs1VEhtNx42/BpAslpuZE3zMlQjbFSHUnJYgHIm6KwXnNQyD4OgY7y089vMexMaONcWi1EQ6dRuYo/4pQFoIXi5BEZ6uY0YAVRc8RBj24O/Bf3BQwpo0y2biTtc0yazj1cZMpyv0UZdw/Tu1YNTWZ/R6xu92nD4nBJULa9UbmuhwEHX/pVyIlSUY0p/wP1Mp0PybVoJB+RjerVbgyH9nzsSv/ekEQU=; 20:0sogbl2DaHUuMVSQ751gF/++TQYr5VMpED2M25x/hnOX98n9dAVT6RtvwSiv4fqj/upc4BAXx56jLZVrXjJ2dQF92XgUgpFOUIH6CKKjdJfOZ/arnMr7yUdDavmO9kq4vSObSM33rEo4dYZCZnnSwnhm7eYN+N1PNkkqWMlfy2iRKz/tv2R7QSXL2vITAdOWsQqN6+dn+Z16KCoXPNjU7/mcBGc7or3H2V3fTukC4WBB5Td4+7d+60fLjGX9muciEMicibRX6CtwXiNZ9uAPp1oJB21rnkeK2eRXD3SwPPlqYYDyibdNFxfTX+Zno+RLzL//+NZQ2suzOhKXC2QQsCxg29MmvzzAYnJhTJldNNW4hyiQHaiUZqAFo6k5dddJOwnBtQ0hbnnDAdhmKb07yCFU8stpWqMaFU7I/qhzdckLR1DriaN7zbO8TBnyX+Nz37AIHo0LtXbGrF/D3dG2cZ5E/OzBVfaJfIzlQfkvNKg18Zlgq4N8pQysRvysUtz6sgeL6VVxhSGK0GrFf78r4xQHjJRoXQQzarMooWHzhVmfKsDZj2NCXYiHehe+td3N2jKi/7t7Rp6cbTywIFlfLC9OWSBmPHq0gexYPMz5R3w= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:BY2PR05MB2181; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB2181; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 4:Kj+xbR9zn8HWtuwZBbCVHJHJs1uD5OqdiZD2QDqV6qV0vJqGy4vo1Zagu/Q2pFS2anw2KEq+k5ebWCedcfgvkAwulgg9X8UV4QppHct7LoVvlebwIeIhWc2hO+bfqvU7zce+Qy/86T4ckz7/SD1I85BpkQh/qW8IDWFJW6ELBrHnoSxdLHejPCqPfkyicvMor/v0figGgTqbkHdXWVfOpyONoqoDhYJ7OuUetUc05omrOrtrGu95TB8BcWUjtLn3RnHqkecjoP/9YC8rxPvMbjO/wm1UT29mvkUeOPP/2pxqvSjW+qKizuoKpkCVdK/sHLmYo+mMqXKvfYIpdfQzpNye2hqzl6y2fBRVq/oQAXdCYBMbITW9TQXB0K06PtDlHQLNcpoltL3aXWOmQFVQ3VDZ6UKat5XSEYJ5DplmRaY2H1pml57Ry3xXQKyd6V6hho6TJhCLxTNs3N0brkSg0xwKWMmZjqsBUt2y9HOVCwR5uMDUMUwt5ccz2PsGmkPLBjEsBoDIsKJ56Cd4UfDCvVo5lTDZpzgp0lynA4J+PuhBXPlDsDNQvWs2YDzSmyTImpEsjI7yqump2hdRvIqUP0ezozBZn3MQ6w6cbKx056r+ao9Jfp3QH81y/RGMwkXSieQ1fZo3x5Tu4SJdFRsFLMueEVoYzwppyqQu5b50/xUjWJhsGF+hM/MS1+km3gxHBbC7S7unIW4ozF68+UWdZqDV1QtLQP4h6o4goz5SjU9FmH7QXGUHAJSdzp4bwbLDFgzx7dinnN0GJWGqwrKeRPpSmtT69NWltkzzwo9CGdqQ+cBO4ScRbGZRmislOvYv X-Forefront-PRVS: 031257FE13 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39400400002)(39450400003)(39860400002)(39840400002)(39410400002)(39850400002)(377454003)(24454002)(25786009)(50466002)(3260700006)(77096006)(81166006)(53546009)(478600001)(3846002)(230700001)(7736002)(305945005)(53936002)(90366009)(6116002)(6486002)(33646002)(38730400002)(54356999)(50986999)(4001350100001)(42186005)(76176999)(36756003)(83506001)(4326008)(31686004)(189998001)(6246003)(6666003)(2501003)(5660300001)(23676002)(229853002)(230783001)(2201001)(2950100002)(65826007)(31696002)(2906002)(8676002)(86362001)(65956001)(47776003)(65806001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2181; H:[172.29.39.62]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjA1TUIyMTgxOzIzOmpHSUNITHNzNHBxNVEwMmR6SHpEZjVPTnVq?= =?utf-8?B?QVdPWldmTkIyQzNQbEt0dEJZR1JDaXJrZ3RaNVFKTjh2SHY4RmVPck1GcGxq?= =?utf-8?B?MndYMjJpUHZJRm12U3p0SmhwS1Q0V05jSGNnM0J5Tlp6czNiM1pZMXBySytt?= =?utf-8?B?VCtnMGpReFp2NnFUVVFPRlAzeitkaHYyYmVQTWo4a0d0SVVnZTdZRkFyNkl4?= =?utf-8?B?aURxZVFSaFhEZGFBcU9DUDFSWTA5bkZvYnFkUjl5YXZkaStZaVhYZUNiV0gy?= =?utf-8?B?RHVTMTFTZUlVeDNxYUdXTjd2b2U5c1F2M29sQlZiUEtoYy81b0FBMVNLQUxW?= =?utf-8?B?dzc5Y0JHNHVXa0hOUGRrZHUzSk9qa2J2YjZCRUFHdFU5ZUlzUm5CSWNKMjB5?= =?utf-8?B?ZDJBcmVWREd6azc1c095a1psUWVpZEpGc1pmc0RPN1VNQUlFMUpWVnB1RUhL?= =?utf-8?B?Q0pCNmFlcEx6UnE3cTNtYWVlQUFKK0xEQkR1WmYvb0hwa3k4NDV6aVNYaEFn?= =?utf-8?B?VktYdTN1ZmliTGMyamhqVVNkR3NIK1ZnQzUzYjZYd2NiNUlEY1VjM1lHa3JK?= =?utf-8?B?M241b3I5aEltY1pMdFNyQUhPNEV0MDJhVU9tVWY2bzVhSE5qRHhLVTRYdDJL?= =?utf-8?B?cjlPYW9vcThIWnBBd2V1SWxTRVNaWkM2NkprNnJPTG5wZXR0QjYwUjlpV0do?= =?utf-8?B?b3NaT2dBSWNyWXdiY1gyMG4wVm5SM0MzQVd1N1V2dGVEZU9ubEZ0b3JkY3B0?= =?utf-8?B?RjM2MGY0a0pHUnd6VVgrRm85NDRqUi92QlB1dWk5NWlPOXFkNnVaUnptTHFJ?= =?utf-8?B?eW1OQ2Nwbm03cTZQYWVWd3VOVGZYQW5FNjJ2S2paQ1MxWXBNMzBTcHgxd2FV?= =?utf-8?B?WDVsQzZweEVRYXBRd2VQNGx1dmJIaTVVK1ZXaG54RENYSE5oU09qTkwvVXcr?= =?utf-8?B?MWFFZ3pUQmlXUTNDeUN5M3dlY00vdjFzVlpJUmRoWGJuWHRjTTBpT2N4czRL?= =?utf-8?B?amNtQ3hHNk9PR3p3eDlrQ0pIY1FMRkFOSUdhM3FFK0lENXRoQS9wUnNyKzZX?= =?utf-8?B?UmRyTWZWaXZPK090R1NldmZvNHZWVUpMbzM0aXJBS0lxSlRjVTcxRjBiRU1J?= =?utf-8?B?dUpacnhNYnNDMjduUi94bVlub245ZmQ5M0dXcjJDajZGUTloSUMvOW1jTGtu?= =?utf-8?B?UHk5bUxWUk1INCtSY1dKMUE5d1BpblorckV1clBzZUJtZnBsL2NKejQ5UlF3?= =?utf-8?B?THkxR0pUbjU4ak5DbnVIcTBXZ0hqZ0doMlhwemppamVHOFNvVlFtcXQwbWlW?= =?utf-8?B?ZW1obGs5SHRSWUpJVmdzdERrQUVucE9jU2xIM2JGRW1LU2VSUE41TU81Mmt4?= =?utf-8?B?M2JReHIxVWtNd2NXMFUrYzE0UDFBajlTYUw4OXRrbGw0T2VLTTZPVnNkMXVq?= =?utf-8?B?YW8rRlAvTzhDL1FJOXFpeThDZll0WmtEbU5Nd25ZWndhRXg5dlkyTFdaaVN2?= =?utf-8?B?em0vaktObnlnSmZWQVJ6SkhFZjE5enVPMUNaZW16TVdxc1BSNWNGcU9ISFVw?= =?utf-8?B?Z2Zzd0NYdERLdFpIMDBsNktwNmZYRWk1VkRkNGNWWm8zcmI0UElVOWtjWW9X?= =?utf-8?B?dXI3emVTblFEcVB2d2dEaFZ2VEhmdFQ3a0N2US9SYTVydDJIdmNocVJlYkJt?= =?utf-8?B?SERaL0xPMnF2RGtvdzVOMHZMKzZjK2JjNmd6aXRBWCtscnhYV1VCQk1JTk5E?= =?utf-8?B?aEI0MnFsOXhnK2NpYUhtTTM5QWZFZEw2VjAvUy9USWxaZU1OUVdBTHRuRTE0?= =?utf-8?B?M2JLMm9vYWJvZ01ybVcrdVVDQXltc3d0SERBN2hZdUNCKzFNUjBBRFl4M0Mr?= =?utf-8?Q?WRyxpJa4Dyc=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 6:VQY5oo82UpZffA2TVpjoR7cUP8U+2NziTA26WHmQogggflz7ufrQKxXarCjGY3b7R1a1FjGz4ttefsR3MXcQrwDVPSy1b3DNA3NsBtX9e2qU/r0jlTshywwljaS/PjBYJwv3OUdqtVZK1LfYPM43CtR8hItLhG1O0XCD1JVbCoJwF837usGsfDeHajMoH0vmGgiptQL0mTFqlAop7ED2lmlj7C8rRPvtUsolqSqGChd2kTEkZFSjvshY5CKAkRGF2MWZTrsYi1WQg01xBera0pIJ0NjDucF5FEmtsA8/tykS21HQmvdYG0M8Aw5yscbSHHCGIKD/Uxq2IQNQ4hv87ZurUE6OtiLp3kBB0NnlPq+fNiOmIS1dqwKCMd/EptIUmuwT0OKcmNSvdxg7bPVtgN7J5QpGZkSl/2bHqiRaP9W6EKt+4WxgsnI+kyklsHAMOHgTHQk398N3Yplh/hRzWlnQtPdfpMFNy7DpscYahqOnyHYiY5DaHihcI2bsb1Mf0h71LxKyMZta0rpkjF4PJEDCKXUZ22kH/ZWWWuK89Vo=; 5:lJT04C1fPookw287MGslHu2YPF8dgjyvNjoXm50+CF1EhxAu3YmNjDJJzW4o0ZjIVYlTj/ixC49RvENWH+nPbWlMiko5pKZoUXb/g4swNm2eOy679VzZBrwaMwMJ2Eb1p6I/QxpME0QwlhjLGm0w7g==; 24:HZSabbTLj+yr0XApJLP+x/SelpzYSqnUvywTaF1mGZ8+oQRyPIsdD6xdyIZyFtD7thnM5iYxl84XwP75m71YTX4R5qHZwmAiHfOAApSvvgg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2181; 7:aX0JjOTEC2gTa9Ge5gvZeA1n1vHuBeb9JfSCnFiqpVyguhA8/V2k3pdDs10OAJw9XLEMJ1g6Cg2Wqz4XEpXsQ4A7nHPK/GW1QRGy82PdwMZ97ooM5LUoYmTATw2egaqJm0dDuD0nDSSGZhQLDrT/MvopAMhRqKyOaNt38NDiOroKtoDgFHxZW94j80s1CTrjMf4M3G023QT7cwWE+pAIZH2h4ArWYemRUKijlqfnaZEnzKO0QVlt6VtgxT/DpKee6T9JAKS1wr3iROxwpKtGRQ+w8TxM9mMPjHsfYknCtwU6ciGofUNBGjZ92Z3fFOdyJ308ga6eou24Xs+sOJ7SdQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 May 2017 16:56:02.5953 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2181 Archived-At: Subject: Re: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-framework-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 16:56:07 -0000 On 5/19/2017 10:20 AM, Bocci, Matthew (Nokia - GB) wrote: > One could envisage situations where duplicate flows are assigned the > same EL value but sent on different LSPs over the same path or subset > of a path. I suppose that if two flows have different ingress nodes, they might by coincidence get assigned the same EL value. then if their paths intersected downstream, the EL itself might not provide enough entropy. Is that the sort of situation you're thinking of? Of course, if the EL is computed by the ingress as, say, a hash of the TCP header, one could minimize the probability of that by including the ingress node's address (or even some random value) in the hash. From nobody Fri May 19 17:43:10 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4289A129B50; Fri, 19 May 2017 17:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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_H2=-2.8, SPF_HELO_PASS=-0.001, 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=netorgft1331857.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 UWLFkXRqov0Q; Fri, 19 May 2017 17:43:05 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0041.outbound.protection.outlook.com [104.47.34.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F807129524; Fri, 19 May 2017 17:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IBbB9v9qPJYR7GCQN8KT721TFgjbB4GallD348OpObo=; b=H8CzXHlI/pji3qnHSv4RO5H9LXFVxlotpT4yyR4Aedy/n6/Rnz/v+XHin5Fqwx1EUbpA+h87rep4WMobpgnJCU8KAmSPEzJqOPvIA9WrOHRHACmmXpC1tHqnTu2Kp+YTz9q3azURa6FztaHPGB+6V6z3YyykqXJaPPsKeeLLT0Y= Received: from CY4PR18MB1127.namprd18.prod.outlook.com (10.173.184.14) by CY4PR18MB1125.namprd18.prod.outlook.com (10.173.184.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.14; Sat, 20 May 2017 00:43:03 +0000 Received: from CY4PR18MB1127.namprd18.prod.outlook.com ([10.173.184.14]) by CY4PR18MB1127.namprd18.prod.outlook.com ([10.173.184.14]) with mapi id 15.01.1101.019; Sat, 20 May 2017 00:43:03 +0000 From: Keyur Patel To: "bruno.decraene@orange.com" , John G.Scudder , idr wg CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@ietf.org" Thread-Topic: [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHS0QIJYQaYgmju5kW1w24bFzBjqA== Date: Sat, 20 May 2017 00:43:03 +0000 Message-ID: <921E0107-5131-42CC-9EFC-E9A914D9C2FB@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=arrcus.com; x-originating-ip: [2601:646:8981:c940:a562:f602:c222:98fd] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR18MB1125; 7:E8EwjOZhKSRGXj7BZMCJWD/gABKqBM8+4utRt/bSTh/nGnLa28nIQSWNiAlDTJi/wsf0VNmI9/4MzCjT5zHNLwZCrs25x8Up2wk9DKOZmFjMJeX78uvvSfhXVVbW+OIEP/N6I312/AjXvshuPyi0slks1OMiLJpjFi/oBkuhzZMTsNvnq9FPJF37nVrOGJPA+/DdPm9oCZWrBY9ulkMbeuDtN/b2PV+q7aYbV6/tngpMiLO++TuIyIdGHNzew5SmyOwABgO8PPo9i7KukLeEsVHOqL2bpZ/zcr8q8+f8BcTCdANWlKvEOQaCG1T2RXM+91SqrrI+13108+KUQ+aA4A== x-ms-traffictypediagnostic: CY4PR18MB1125: x-ms-office365-filtering-correlation-id: d0dc4fce-9e9a-45c6-a1e9-08d49f192c4b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201702281549075); SRVR:CY4PR18MB1125; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(138986009662008)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201703061421075)(20161123564025)(2016111802025)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(6043046)(6072148); SRVR:CY4PR18MB1125; BCL:0; PCL:0; RULEID:; SRVR:CY4PR18MB1125; x-forefront-prvs: 03137AC81E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39400400002)(13464003)(24454002)(377454003)(53754006)(6506006)(6436002)(8666007)(54906002)(6512007)(966005)(81166006)(53936002)(99286003)(8676002)(6246003)(189998001)(8936002)(82746002)(6306002)(38730400002)(305945005)(122556002)(229853002)(508600001)(86362001)(230783001)(36756003)(50986999)(3280700002)(102836003)(6116002)(54356999)(83716003)(5660300001)(77096006)(6486002)(2900100001)(25786009)(53546009)(4326008)(2906002)(2501003)(1941001)(33656002)(3660700001)(5890100001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR18MB1125; H:CY4PR18MB1127.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8732224DEFEF7E45A235D451DBB3AE27@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2017 00:43:03.1574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR18MB1125 Archived-At: Subject: Re: [mpls] [Idr] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 00:43:08 -0000 U3VwcG9ydC4gSG93ZXZlciwgSXQgd291bGQgYmUgZ3JlYXQgaWYgdGhlIGF0dHJpYnV0ZSBmb3Jt YXQgYWRvcHRzIG5ldyBhdHRyaWJ1dGUgZGVmaW5pdGlvbiBvZiA6IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWJncC1hdHRyaWJ1dGUtYW5ub3VuY2VtZW50 Lw0KDQpUaGlzIHdpbGwgaGVscCBzY29wZSB0aGUgYXR0cmlidXRlIGFubm91bmNlbWVudHMuDQoN ClJlZ2FyZHMsDQpLZXl1cg0KDQpPbiA1LzE5LzE3LCA3OjM1IEFNLCAiSWRyIG9uIGJlaGFsZiBv ZiBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIiA8aWRyLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+IHdyb3RlOg0KDQogICAgU3VwcG9ydCBh cyBjb2F1dGhvcg0KICAgIA0KICAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAg ID4gRnJvbTogSm9obiBHLlNjdWRkZXIgW21haWx0bzpqZ3NAanVuaXBlci5uZXRdDQogICAgID4g U2VudDogVGh1cnNkYXksIE1heSAxOCwgMjAxNyA2OjM1IFBNDQogICAgID4gVG86IGlkciB3Zw0K ICAgICA+IENjOiBkcmFmdC1kZWNyYWVuZS1pZHItbmV4dC1ob3AtY2FwYWJpbGl0eUBpZXRmLm9y ZzsgbXBsc0BpZXRmLm9yZw0KICAgICA+IFN1YmplY3Q6IFdvcmtpbmcgR3JvdXAgYWRvcHRpb24g Y2FsbCBmb3IgZHJhZnQtZGVjcmFlbmUtaWRyLW5leHQtaG9wLWNhcGFiaWxpdHktMDMNCiAgICAg PiANCiAgICAgPiBbcmVzZW5kaW5nLCBjb3JyZWN0aW5nIGRyYWZ0QGlldGYgYWRkcmVzc10NCiAg ICAgPiANCiAgICAgPiBIaSBBbGwsDQogICAgID4gDQogICAgID4gSURSIHdvcmtpbmcgZ3JvdXAg YWRvcHRpb24gaGFzIGJlZW4gcmVxdWVzdGVkIGZvciBkcmFmdC1kZWNyYWVuZS1pZHItbmV4dC1o b3AtDQogICAgID4gY2FwYWJpbGl0eS0wMy4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0 aGUgSURSIG1haWxpbmcgbGlzdCBiZWZvcmUgSnVuZSAyLCAyMDE3LiBQbGVhc2UNCiAgICAgPiBy ZW1lbWJlciB0aGF0IHdlIG5lZWQgYWZmaXJtYXRpdmUgc3VwcG9ydCBpbiBvcmRlciB0byBhZG9w dCB0aGUgZHJhZnQsIHNvIGRvbid0IGJlIHNoeS4NCiAgICAgPiANCiAgICAgPiBkcmFmdCBkYXRh dHJhY2tlciBwYWdlOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kZWNy YWVuZS1pZHItbmV4dC1ob3AtDQogICAgID4gY2FwYWJpbGl0eS8NCiAgICAgPiBzbGlkZXMgZnJv bSBJRVRGLTk4OiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85OC9zbGlkZXMvc2xp ZGVzLTk4LWlkci0wOC1iZ3AtbmV4dC0NCiAgICAgPiBob3AtZGVwZW5kZW50LWNhcGFiaWxpdGll cy0wMC5wZGYNCiAgICAgPiANCiAgICAgPiBTaW5jZSBpbiBwYXJ0IHRoaXMgZHJhZnQgc3BlY2lm aWVzIGEgcmVwbGFjZW1lbnQgZm9yIHRoZSBFbnRyb3B5IExhYmVsIENhcGFiaWxpdHkgQXR0cmli dXRlDQogICAgID4gKEVMQ0EpIHRoYXQgd2FzIGRlZmluZWQgYnkgdGhlIE1QTFMgV0cgaW4gUkZD IDY3OTAgYW5kIGRlcHJlY2F0ZWQgYnkgUkZDIDc0NDcsIEkgaGF2ZQ0KICAgICA+IGNjJ2QgdGhl IE1QTFMgV0cgbWFpbGluZyBsaXN0LiBTaW5jZSB0aGUgcHJvcG9zZWQgbmV3IGF0dHJpYnV0ZSBp cyBhIGdlbmVyaWMgY29udGFpbmVyIHdpdGgNCiAgICAgPiB0aGUgRUxDQSByZXBsYWNlbWVudCBq dXN0IHRoZSBmaXJzdCBhcHBsaWNhdGlvbiwgdGhlIGN1cnJlbnQgZHJhZnQgaXMgdGFyZ2V0ZWQg dG8gSURSIGFuZCBub3QNCiAgICAgPiBNUExTICh0aGlzIHdhcyBkaXNjdXNzZWQgZHVyaW5nIElF VEYtOTMpLg0KICAgICA+IA0KICAgICA+IFRoYW5rcywNCiAgICAgPiANCiAgICAgPiAtLUpvaG4N CiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQogICAgDQogICAgQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQogICAgcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCiAgICBhIGwnZXhw ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0K ICAgIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCiAgICANCiAgICBUaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KICAgIHRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLg0KICAgIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLg0KICAgIEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y IGZhbHNpZmllZC4NCiAgICBUaGFuayB5b3UuDQogICAgDQogICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBJZHIgbWFpbGluZyBsaXN0DQogICAg SWRyQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZHINCiAgICANCg0K From nobody Fri May 19 17:48:52 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3421293D9; Fri, 19 May 2017 17:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 k_wPo8O3Wv_2; Fri, 19 May 2017 17:48:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5ED126BF6; Fri, 19 May 2017 17:48:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGY49517; Sat, 20 May 2017 00:48:44 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 20 May 2017 01:48:43 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Sat, 20 May 2017 08:48:38 +0800 From: "Dongjie (Jimmy)" To: "John G.Scudder" , idr wg CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@ietf.org" Thread-Topic: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHSz/XUX67d8sloskeDYSDEq7Y1FqH8ZX+A Date: Sat, 20 May 2017 00:48:38 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927936BBA12@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.591F926C.005C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1ea2c9a9dd395df487029a298745cbb0 Archived-At: Subject: Re: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 00:48:50 -0000 Support the adoption.=20 -Jie > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of John G.Scudder > Sent: Friday, May 19, 2017 12:35 AM > To: idr wg > Cc: mpls@ietf.org; draft-decraene-idr-next-hop-capability@ietf.org > Subject: [mpls] Working Group adoption call for > draft-decraene-idr-next-hop-capability-03 >=20 > [resending, correcting draft@ietf address] >=20 > Hi All, >=20 > IDR working group adoption has been requested for > draft-decraene-idr-next-hop-capability-03. Please send your comments to t= he > IDR mailing list before June 2, 2017. Please remember that we need > affirmative support in order to adopt the draft, so don't be shy. >=20 > draft datatracker page: > https://datatracker.ietf.org/doc/draft-decraene-idr-next-hop-capability/ > slides from IETF-98: > https://www.ietf.org/proceedings/98/slides/slides-98-idr-08-bgp-next-hop-= d > ependent-capabilities-00.pdf >=20 > Since in part this draft specifies a replacement for the Entropy Label > Capability Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 > and deprecated by RFC 7447, I have cc'd the MPLS WG mailing list. Since t= he > proposed new attribute is a generic container with the ELCA replacement j= ust > the first application, the current draft is targeted to IDR and not MPLS = (this > was discussed during IETF-93). >=20 > Thanks, >=20 > --John > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri May 19 23:45:09 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EEF127909; Fri, 19 May 2017 23:45:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149526270007.30807.7914963763043233675@ietfa.amsl.com> Date: Fri, 19 May 2017 23:45:00 -0700 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-lag-multipath-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 06:45:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces Authors : Nobo Akiya George Swallow Stephane Litkowski Bruno Decraene John E. Drake Mach(Guoyi) Chen Filename : draft-ietf-mpls-lsp-ping-lag-multipath-02.txt Pages : 27 Date : 2017-05-19 Abstract: This document defines an extension to the MPLS Label Switched Path (LSP) Ping and Traceroute as specified in RFC 8029. The extension allows the MPLS LSP Ping and Traceroute to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. This document updates RFC8029. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-lag-multipath/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-lag-multipath-02 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-lsp-ping-lag-multipath-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-lag-multipath-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 20 12:40:21 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DAF1292AE; Sat, 20 May 2017 12:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0whlIItKAD_d; Sat, 20 May 2017 12:40:11 -0700 (PDT) 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 34E28126C25; Sat, 20 May 2017 12:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UPuJx4GUm5FP2q8NV0DUWc8LuYqN8LfuF6thtSo49qY=; b=UzJ189oRpYe5IllIzSkt2bI7gLACipwD/2J6bUN6K5Ze8YuLdz3PCzdGpHSwxAM8Nv1DF7z1KYTaIR2kMzLwxkwFFI8y1/oV5M6GssaRjKaSIpTCBRZ/eRRIg7wX6gra99NzlsyKW2yzztduKcPGlxKW4z0g0DVh9+SJAtvywpk= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from pboucek-sslvpn-nc.jnpr.net (66.129.241.11) by CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Sat, 20 May 2017 19:40:09 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Sat, 20 May 2017 15:40:01 -0400 Cc: mpls@ietf.org, draft-decraene-idr-next-hop-capability@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: idr@ietf.org X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN6PR20CA0072.namprd20.prod.outlook.com (10.171.181.162) To CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY1PR05MB2507: X-MS-Office365-Filtering-Correlation-Id: d77a4e27-1594-4fbf-817e-08d49fb806de X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 3:Z5oAxVgNPgC60slo7MjjmZXWBwoRgn+iSAB2S25YLXuDZnWPz92sKVVEPEdSUs7f+FA96qiRirteQchb/aNOkAZGugPR2XVqXxZBG4RK9/cA7TrDpdwQVEujRdhlaGTCZpkD4Grcsg07fyDLovUNcXqtDkp9+LZZC014TR03g2LQoa2N0uLp9vc3dEodz3hBdfE+MVMKPu67+GVoyYPwP+SnSdDp6kIEhHw2TcLjV4R53MLE5kvuYYaGlZFh+Q/y0Wf1C8OLdFP00rSQjYD25zzOoev2M+wgHALiUd1yVFatXdvlcspuBDspwSrWBosy7lOW5y+hxtGeRPi59tzzEFUBzLivKZuz+6nmx27093E=; 25:JasVcoQ3v4G0tzdzw7mGRU3D4babf4+MjSQCujgXdO3U+R//qqTDDZHNA84HyWJnDqhJ4xusV81mqaqHW8tTdOrwSdDa4t8+AdApO6EHEOvKWz7NfqMKn+hDNDvyvtwJ20krGYmnSNYgNAIq2g/4dtwqgEznG/5wyprS9JWEbLAX+hR7DdYRLCT8yUuyJ7ZWaKjq5RqkogrLOoe3iV2EFqAZJuEbdDLcjQAkmoxaaSUi8IZx3Z/zILkS0oR3XnrGquDECxUR5IOx37hCU7103Gz0cCRqIdAn/GWGUgp1ShKsgyaej6q/8iGhHZnHzB1CPiATQS2X2DN0HoBxVW5UmjDF8bWT+9N2FlwZV/eZp0ZhcSNUoPaDrvfGqQl31kRLqX+SYQ3lNMGdCK2RohLTiNxreCM2/jMf/AsIjrqnaIrrYl85/Tc7EAl0rcUMdX0Of387YuFOeC4igrqSk4iGzCJKjf6VkSjNqT7pdIBcMqM= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 31:JEFe/SIKZJNLQC+XK0qNKgah4IBZmi/KnNY4dCTaH8t7jkVpr8qa9g8wyHzwE3XI/5rZcbzgwRT7xSYacWoh1pW/3Qej6mOoUxXVMWuCgrpTE5+++05RpG4fbRsbDe/pWzJLT+iE/ZpQ7vUi8+TqvSTjr3aTPbAaGtGQFCRua5AsZncyFG909UoVC0EdabPyyZpKvnPR1lGbYCwe1PFNz1tcvECDnMcRUe3to+SVRHUfyYAe4gmKDz+k8UJTQrVa; 20:VtAeiCnpNbf3VICi4ok8YsLdic6GWDqJiD3I0dtwqvKvkyc7u2RrmYgPTjwvgnSUVxgJ7Lw0p9CB1K1TZtZybKpYb6wzYCaUiNlNF7OQNWt9D2OEy0S8+TpzJCLG2Ss6EgrIOO9pItxKD/6z70vnyHiPVznoXyNqrh2VhatpwZ9zKnun2xtTifgorcTc2oRbsrcJynsq1HNAPyhN9ISUE6AcbQc/eXc5CBUEDn95rSYlbCXI6SyT5VBlaLC4HAu4J2kZnSditkf3wO/YCvSBY15SOc0780VQEkFckkMDKi2d9jkY1x4khysCv1dCPJzvvMaJGOxka/plv0h4W9C7+6UqjVbVT8uhwErUPiIqAnFpPf+VlJQwB6eb76Gl3XrDbXjpDrYsPZA5nUuAuihoSUmidjWf5afiYJ0YByid/VpHhvodxbWJDrkCLAoIs1ABTu7CMTPLDmF86gGxksBXMLXetceRsAK5d9RmhFt/Z7ObE7tJaKOWFDYcY8RzxxSlRE12BM7PQ8opELcCNUVeENYA2kp/xElsnyVT5e+Ryjf6W1jZwUak3EvCgxA6MEXYP7dPiiaNt3MFDAOQx/NPMRpsROnCsoAv9rCiiSDEC4U= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703036)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2507; 4:YUyq9Ezsf5R0apakj97Kkjm9NYB7BvONhIpS6LHpEZ?= =?us-ascii?Q?bnTUXWxOP/C4bR+B81nAJ+xIM5ZPiuuhenlA1YRB/jRPOu2koT2cssVJxtpc?= =?us-ascii?Q?Cbg615V14HgrpfxNjpdSUA6VwqtePJA6WGHwEVZ0oQqFXTwdETKgQf6bNbME?= =?us-ascii?Q?2jwVlISWWCeipJHqBhQfHKm5JdfYKxoN2tRcZHWJgjd6hVMUa5jKHcDbNEHK?= =?us-ascii?Q?uRdPWlRTzb4+gMWNpEm6LzI+bJtTZ2FAW09qS+Q3o9g+r+C2AMgvrZvOqfwL?= =?us-ascii?Q?aiK8/ljiK0sERKWvsEzz6FDCuPssA6T+dvXZy2e7Ah2JU+YWZGJr9GAGrWKX?= =?us-ascii?Q?D3KLr2pHZQje1UAHqTYaTPBgIfquked+hs67G7Udp38xT9PGaNRhK2rzsmPS?= =?us-ascii?Q?XV05a/t9B1PKffx2jNoPA3QI7j9ih5nmud8v7p/x72PFY37V3UD9k50mSxip?= =?us-ascii?Q?90PcEYJBBd+jyaReEp/Oq6/pgL70CectkOtLcpPn6vpGO5iqYdoKnSMNCgJl?= =?us-ascii?Q?wZA7bGL0JSWDSj1KTvGPCx42aj6CkA3/x0V4F4ETeVXGgkgLqJ3LA+Lfe9Aj?= =?us-ascii?Q?WYMge5YpIXEIESfK2GkKCSFvTpoZi38VfuG6mr+G/f8KgC/m977roXAjlkyw?= =?us-ascii?Q?r4sfPx77frhqo3BQ2v6cM6LDs/IUs7GImOHA+ehBybTb+MaWAKxI3c/FHzwu?= =?us-ascii?Q?9ZUBez2YHDDe5tk1LeLEB/PUvfp73Cl94oFmBP36f5GdUPJDi9BWVasqsyNe?= =?us-ascii?Q?mpxHvt0FBp1DBWzVyYADQUhqql1ufXCp2M1SyzIoqjBSPg1ef1Nz/Ml3rQYD?= =?us-ascii?Q?6Sgdtmxt1hN+D7Dnv9OJJ6z+UCMJo1mQxESm7KDS7N7A42weMQFyAZtUYu1j?= =?us-ascii?Q?ReCBEZei2Lu62v8iPadZtTgyksTHU98LffNyqU0YNG21D5y8Z3JhZY+PZzfG?= =?us-ascii?Q?/sQ++V2/RvJaXaQN5Kc/BWdnSVFGQdvsLBb+Time/kN1QeGRYkhmhL7r6xCr?= =?us-ascii?Q?kcF1L0QDqbz0vaspho25xGhU9XG1tKsZKk3vz2ItB4T1mLE6aK2evvUyL8Vh?= =?us-ascii?Q?eJicgv/d8ZhTgZY2kW+kv9ciu3keYtWAZD8iRKpwgZOJYu7f1qcRkz4wyjnk?= =?us-ascii?Q?qi2x8IOz0GHocJH6d3Vl6W4irECHrH73hbsY7/eaedzgdf1B0m+QexLYeacu?= =?us-ascii?Q?k7wQXyCjDbT12rSEDFvsYEZJgqmhTffYetDuCRb3x+HfnToNK89Pjxzahnk+?= =?us-ascii?Q?Yrec1+tYvgJcP0gYE=3D?= X-Forefront-PRVS: 03137AC81E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(979002)(6009001)(39840400002)(39860400002)(39850400002)(39410400002)(39450400003)(39400400002)(377454003)(24454002)(53754006)(6246003)(305945005)(110136004)(966005)(478600001)(6306002)(33656002)(229853002)(50466002)(86362001)(38730400002)(230783001)(23726003)(6512007)(82746002)(42186005)(25786009)(53416004)(6116002)(83716003)(3846002)(50986999)(189998001)(66066001)(53936002)(50226002)(4326008)(47776003)(81166006)(450100002)(57306001)(5660300001)(2361001)(8746002)(2950100002)(76176999)(2351001)(6506006)(6486002)(7736002)(2906002)(6666003)(6916009)(8676002)(36756003)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:pboucek-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2507; 23:PaJs2Bcrfjt1glWLplsNramC8L4t9t7fpAnIVQ3Pz?= =?us-ascii?Q?wMXdDA4MWsykGM2veuitutAPKEXEhOxekQQ3OdoyEU5jdTUn/F2CMclgN5MJ?= =?us-ascii?Q?kqMboMKAqYqi4DpWU9pcbmx2gxjJ2zKzVYymBGOL6FC7+QcJPCHwAlhfjfaQ?= =?us-ascii?Q?zv1CYpAOkya18atq7DT4lnb6+LPuKA/xjVFahKt0nyCrsDlxEO8Oic/F91FH?= =?us-ascii?Q?z+la5JVHKS0g1PTnNEX90YlA3LIgdH0fBJ8bT5kRYPewfxR6UsQNNM4Zrt/9?= =?us-ascii?Q?jbghQKDsWjhhkHhBSXRUQlvSp8hRt4uzboSKVIOZVNBri/djh6JBk8DsX3HP?= =?us-ascii?Q?9p7uyO8VUw+oy59f4YGdMJwQzDqd6TPk5/XCdUSVWbRDLgvK+Ilr6BS1sCi3?= =?us-ascii?Q?NO02p38ecyvK/VXm6Hnwm1YFVpx09l6cdNBcUHXjoC+er/Rai+xN2HGBIk5k?= =?us-ascii?Q?JsgXi7sMbnr3DVDOQvV3URjTQ7RO26BkeOjKoxS7odcosfyRqTSYZl/runZ4?= =?us-ascii?Q?TA90ISYnWJvIUoqA0nycTwJquOugjgLHZTWKRpswrSqBFArsSg9t8ZdxvI4j?= =?us-ascii?Q?+7yVbQDjuJmW1/IP7LsRt4ZtoLqyjZ1alNcsXaY6QJid1w26rsumCH0tBfzH?= =?us-ascii?Q?CTV2xlyCvLlGahQ56mlvmLS+gnJT9bwfmTwR0lEVXsphnHOfMP8w9yF8tRZm?= =?us-ascii?Q?FgoRX3zl2OY3YyJV/0hIzo2g9OHB27lEIVzfX6wt+iKWN1aR9rHDWsQCgE+4?= =?us-ascii?Q?WOBCuYXsXQY8+og5kkK9tVKyAuj/ouNL/bKNncsg2UaQbSiaFFhfYb20owif?= =?us-ascii?Q?BrvnS8twl6Ms5rzpYoVmgfm4iwa8RIdzBEyr3rbKPwK1Men3yWnJs/GRr/3m?= =?us-ascii?Q?NxfUzv/7aB88mVxBFkQl4GX3ZQLwz0U9lMnVJWDmaLNE6PYdtDz7AIVCF4nA?= =?us-ascii?Q?SGcCEFSIODcfZycf1LGonTvDOJDOrI6pvB7SllOSsP1I273Ura7O8EnkThw2?= =?us-ascii?Q?GfZVpWbFOCQl9dhm1lSRadXUtpKgt6d6F90fCzcVXZVNYqCDPOYeYm8C3Fwd?= =?us-ascii?Q?yBMYNgXZwvgmfCFHW8nZ1mLRvn3cWY1DxK67Hf4tr4/fG6WFGlSeUFiJpPaN?= =?us-ascii?Q?xZDwnV58lrITmSJR5cwUCmwljcZ4efEnT7gcp2opdkzY03+t9FrvKm/OdmG6?= =?us-ascii?Q?rSbP4vSVhYcA9TS5tIDB6MNwESRmQBW8WYAncit+LjeJ0d5QCF99shaWNouB?= =?us-ascii?Q?0pqQLr8ysMX8zNBlZ4V05jUYOdq4+k1GKVSXJIcsZ1o7aeHdKnbhDyCHUIf9?= =?us-ascii?Q?uUPddTXXtNOSTqPcqiTPr61jjrBYXY038at0vBYKzpf6EgMzL2UZIxGWXGgY?= =?us-ascii?Q?KuYNSK9SExM6sBeYPNuPE64Os3ylsPRDRZtYHpCHtJs8zUTODVK4kAAjewDE?= =?us-ascii?Q?2Ttzf6XZCr06whnH7gkq6Nw7rJJPISvAc1I6i25qcbH42T2lK05?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 6:KDUqryk/6mYKzahrTvoRS5yISA1kaYAFZ7avuBRjkJ9XPOLYMYFVYoaHeJBK4KjrzlWQjk+RUth2e6KCCSlvulDc1iFBojmx65z/HPZS8HNYVechFoIirFgoukzlL/9L3EWEfzQrOsROvMU6TGsL3NVKQb/YUuN9UgLjC6M+Q1ATOBKZffT5Gm4dXiNBjrz3VM3DRz+IX5pW20sOn9tG5MaKLXYfuBoSYCcoR76bn5oMCX+t2TpSYS/qyZ5h/EBuzAsf1TuNxSaazmFUlbn7Y8SRdMcPDX2w3CenKT8kwkBoJ0IWmQunyDKV1XnDjPWRDwyN4CYayFQPFRbJo2rvZPLytsPgDK3kIi4tOSytCfM2P1qH/5dtUvu7FTOMSFDJklbN+p2MrYKXcJdSjPwZmAwy+bB9uatkpsnsqvQQRFcC03tdJimxzcHT9Ey0Dcv/DqDF6wLhkR5Txn9k77/DcXBFzZIsy1RlMN/tT4wBL+RFnDK0nPWjU1TZI8hhLrzjWswkMH/yqob2nf1+qxOwX8Yqg4KTVVfW6ciyuiHecwU= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 5:3WOHAuUHrOmIFq/teguklN7WjFvrC2Uqjpd6fB86YgSj9WjXOGu70zg7rcw6qM7BhFRg5zLVip9W2SA64MpGS+GvlsB1AGThQFDtmZvmf3iCoebcAyN4akDG+RW1tN+AnLeMJClGG/lzMfGGN64KZRlTru6/guZ0vKch8HIZ1v92MWaawQuvZYZ49a8x7lavuXCfhos8dm5CRbC8a35SsHHnfKLZJlgS9DbWrBtedOmU6vHnjqMJaEQVX6gnufYWAycHGP3xfzNZhFYPVzaPsyQVomlnyJZsxWLsiu/02gus9m0IuJ4tCkJsp8B9B0VfY4a4UmLV9aFkkdOh9I9oTWJ0b0+nFxPKeqA6HFL8ZjmDIGXBZOSQwSjcSScqC2tSmb3wH+1fPDU6ND3r361Yv6F4N480yTazanPKK0tap2M7OSFXAGzz8x8cwdeE1eVgTBCl0mE9nEbGzF09Xl8J6jijW17KOgmjAnJS2PA4mS1l8ZXinP5sj6KBCKNS3jwl; 24:BG0AjnCEmQZ2vWHNbGeiClP12og1eJpzpbkH/ldGGuUNpR4IgZeJFYfq0z9cKVZVFLKs43x1fLPQcLwXN1PTnHf6W4/F9N8M/S+lzVywMdo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 7:jrDIna6/1SpQJjzOHcIoOxhMb+d/pEhi0KsNasUo+YpYE0++/f1Ac64N2e9q7oeqwIje0MzDWuMni+BWJNfEtZ2h9PMl38gMZ7ob54pUM57C+uQIp+m2oDVt67v57sepr0HPTEGUHE1invxQQLC5GcaHbHTq4TQQ+6aaRp3kLRdxzjqxDpbpftgANFJD9sz7GEWpZe8jipz9zErgdVTLUSztNjxMlFYfDYyTTUSp5gk7Wtk+b34IpqrTReMWurr1TCihXcSE+a5JxhIYYYV2NVPczFa4pz7Dydy19UQxdm/s/ulr4yaefXLTIpU2kGxOGIrz5TzFbEg9SmlzYYg4Hw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 May 2017 19:40:09.8189 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507 Archived-At: Subject: Re: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 19:40:13 -0000 BTW I forgot to mention, authors, please say if you're aware of any IPR = that applies. Regards, --John > On May 18, 2017, at 12:32 PM, John G. Scudder wrote: >=20 > Hi All, >=20 > IDR working group adoption has been requested for = draft-decraene-idr-next-hop-capability-03. Please send your comments to = the IDR mailing list before June 2, 2017. Please remember that we need = affirmative support in order to adopt the draft, so don't be shy. >=20 > draft datatracker page: = https://datatracker.ietf.org/doc/draft-decraene-idr-next-hop-capability/ > slides from IETF-98: = https://www.ietf.org/proceedings/98/slides/slides-98-idr-08-bgp-next-hop-d= ependent-capabilities-00.pdf >=20 > Since in part this draft specifies a replacement for the Entropy Label = Capability Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 = and deprecated by RFC 7447, I have cc'd the MPLS WG mailing list. Since = the proposed new attribute is a generic container with the ELCA = replacement just the first application, the current draft is targeted to = IDR and not MPLS (this was discussed during IETF-93).=20 >=20 > Thanks, >=20 > --John From nobody Mon May 22 00:03:05 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56529129B6C for ; Mon, 22 May 2017 00:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 9JKu2rvefPjN for ; Mon, 22 May 2017 00:03:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08163129B6D for ; Mon, 22 May 2017 00:02:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNN06009; Mon, 22 May 2017 07:02:58 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 22 May 2017 08:02:57 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 22 May 2017 15:02:47 +0800 From: Xuxiaohu To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-xu-mpls-service-chaining-01.txt Thread-Index: AQHSyWGscDurMPAbREWzexnvBaUXtKH4Q6Bg Date: Mon, 22 May 2017 07:02:47 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA902E@NKGEML515-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] 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.0A020204.59228D22.009C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7310a0121f9a465931709deb6c8b49fc Archived-At: Subject: [mpls] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-xu-mpls-service-chaining-01=2Etxt?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 07:03:04 -0000 SGkgYWxsLA0KDQpBcyBpbGx1c3RyYXRlZCBpbiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXh1LW1wbHMtdW5pZmllZC1zb3VyY2Utcm91dGluZy1pbnN0cnVjdGlvbiksIHRoZSBN UExTIHNvdXJjZSByb3V0aW5nIG1lY2hhbmlzbSBkZXZlbG9wZWQgYnkgdGhlIFNQUklORyBXRyBj YW4gYmUgbGV2ZXJhZ2VkIHRvIHJlYWxpemUgYSB1bmlmaWVkIHNvdXJjZSByb3V0aW5nIGluc3Ry dWN0aW9uIHdoaWNoIHdvcmtzIGFjcm9zcyBib3RoIElQdjQgdW5kZXJsYXkgYW5kIElQdjYgdW5k ZXJsYXksIGluIGFkZGl0aW9uIHRvIHRoZSBNUExTIHVuZGVybGF5LiBJbiBvdGhlciB3b3Jkcywg YWx0aG91Z2ggdGhlIE1QTFMgd2FzIG9yaWdpbmFsbHkgZGV2ZWxvcGVkIGFzIGEgdHJhbnNwb3J0 IHRlY2hub2xvZ3ksIGl0IGRvZXNuJ3QgcHJldmVudCB1cyBmcm9tIHVzaW5nIGl0IGFzIGFuIG92 ZXJsYXkgaW5zdHJ1Y3Rpb24uIEluIGZhY3QsIHRoZSBWUE4gbGFiZWwgYW5kIFBXIGxhYmVsIGFy ZSBjb25jcmV0ZSBleGFtcGxlcyBvZiBvdmVybGF5IGluc3RydWN0aW9ucy4NCg0KVGhlIHVuaWZp ZWQgc291cmNlIHJvdXRpbmcgaW5zdHJ1Y3Rpb24gY29uY2VwdCBjb3VsZCBiZSBsZXZlcmFnZWQg ZnVydGhlciB0byByZWFsaXplIGEgdHJhbnNwb3J0LWluZGVwZW5kZW50IHNlcnZpY2UgZnVuY3Rp b24gY2hhaW5pbmcgYnkgZW5jb2RpbmcgdGhlIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBpbmZvcm1h dGlvbiBvciBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGluZm9ybWF0aW9uIGFzIGEgdW5pZmllZCBz b3VyY2Ugcm91dGluZyBpbnN0cnVjdGlvbiAoYS5rLmEuLCBhbiBNUExTIGxhYmVsIHN0YWNrKS4g U2luY2UgdGhlIHVuaWZpZWQgc291cmNlIHJvdXRpbmcgaW5zdHJ1Y3Rpb24gY291bGQgd29yayBh Y3Jvc3MgZGlmZmVyZW50IHVuZGVybGF5IG5ldHdvcmtzIGluY2x1ZGluZyBJUHY0LCBJUHY2IGFu ZCBNUExTIHVuZGVybGF5LCB0aGUgc2VydmljZSBmdW5jdGlvbiBlbmNhcHN1bGF0aW9uIGhlYWRl ciBpbXBsZW1lbnRlZCBpbiB0aGUgZm9ybSBvZiBhIHVuaWZpZWQgc291cmNlIHJvdXRpbmcgaW5z dHJ1Y3Rpb24gKGEuay5hLiwgYW4gTVBMUyBsYWJlbCBzdGFjaykgaXMgdHJhbnNwb3J0LWluZGVw ZW5kZW50IGFjY29yZGluZ2x5Lg0KDQpBbnkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSBt b3JlIHRoYW4gd2VsY29tZS4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gLS0tLS3pgq7k u7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0Neac iDEw5pelIDE1OjQ3DQo+IOaUtuS7tuS6ujogSGFtaWQgQXNzYXJwb3VyOyBMdWlzIE0uIENvbnRy ZXJhczsgWHV4aWFvaHU7IFN0ZXdhcnQgQnJ5YW50Ow0KPiBkYW5pZWwuYmVybmllckBiZWxsLmNh OyBMdWlzIENvbnRyZXJhczsgRGFuaWVsIEJlcm5pZXI7IEhpbWFuc2h1IFNoYWgNCj4g5Li76aKY OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXh1LW1wbHMtc2VydmljZS1jaGFp bmluZy0wMS50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteHUtbXBs cy1zZXJ2aWNlLWNoYWluaW5nLTAxLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFhpYW9odSBYdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+IA0K PiBOYW1lOgkJZHJhZnQteHUtbXBscy1zZXJ2aWNlLWNoYWluaW5nDQo+IFJldmlzaW9uOgkwMQ0K PiBUaXRsZToJCVNlcnZpY2UgQ2hhaW5pbmcgdXNpbmcgYW4gVW5pZmllZCBTb3VyY2UgUm91dGlu ZyBJbnN0cnVjdGlvbg0KPiBEb2N1bWVudCBkYXRlOgkyMDE3LTA1LTEwDQo+IEdyb3VwOgkJSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJMTENCj4gVVJMOg0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteHUtbXBscy1zZXJ2aWNlLWNoYWluaW5nLTAx LnR4dA0KPiBTdGF0dXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXh1LW1wbHMtc2VydmljZS1jaGFpbmluZy8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1tcGxzLXNlcnZpY2UtY2hhaW5pbmctMDENCj4gSHRt bGl6ZWQ6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQteHUt bXBscy1zZXJ2aWNlLWNoYWluaW5nLTAxDQo+IERpZmY6DQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC14dS1tcGxzLXNlcnZpY2UtY2hhaW5pbmctMDENCj4gDQo+IEFi c3RyYWN0Og0KPiAgICBTb3VyY2UgUGFja2V0IFJvdXRpbmcgaW4gTmV0d29ya2luZyAoU1BSSU5H KSBXRyBpcyBkZXZlbG9waW5nIGFuIE1QTFMNCj4gICAgc291cmNlIHJvdXRpbmcgbWVjaGFuaXNt LiAgVGhlIE1QTFMgc291cmNlIHJvdXRpbmcgbWVjaGFuaXNtIGNhbiBiZQ0KPiAgICBsZXZlcmFn ZWQgdG8gcmVhbGl6ZSBhIHVuaWZpZWQgc291cmNlIHJvdXRpbmcgaW5zdHJ1Y3Rpb24gd2hpY2gg d29ya3MNCj4gICAgYWNyb3NzIGJvdGggSVB2NCBhbmQgSVB2NiB1bmRlcmxheXMgaW4gYWRkaXRp b24gdG8gdGhlIE1QTFMgdW5kZXJsYXkuDQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhv dyB0byBsZXZlcmFnZSB0aGUgdW5pZmllZCBzb3VyY2Ugcm91dGluZw0KPiAgICBpbnN0cnVjdGlv biB0byByZWFsaXplIGEgdHJhbnNwb3J0LWluZGVwZW5kZW50IHNlcnZpY2UgZnVuY3Rpb24NCj4g ICAgY2hhaW5pbmcgYnkgZW5jb2RpbmcgdGhlIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBpbmZvcm1h dGlvbiBvciBzZXJ2aWNlDQo+ICAgIGZ1bmN0aW9uIGNoYWluIGluZm9ybWF0aW9uIGFzIGFuIE1Q TFMgbGFiZWwgc3RhY2suDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv bg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon May 22 00:13:17 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3D7129B7A; Mon, 22 May 2017 00:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzIT0TehTNO1; Mon, 22 May 2017 00:13:05 -0700 (PDT) Received: from relais-inet.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 54002129B79; Mon, 22 May 2017 00:13:05 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 85D54A03D1; Mon, 22 May 2017 09:13:03 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 55ED340075; Mon, 22 May 2017 09:13:03 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0339.000; Mon, 22 May 2017 09:13:03 +0200 From: To: "John G. Scudder" CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@ietf.org" , "idr@ietf.org" Thread-Topic: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHS0aDeX67d8sloskeDYSDEq7Y1FqH/8SBA Date: Mon, 22 May 2017 07:13:02 +0000 Message-ID: <26881_1495437183_59228F7F_26881_13214_1_53C29892C857584299CBF5D05346208A31D21DCD@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 07:13:07 -0000 I'm not aware of IPR. Note that this draft borrows a very small subset from RFC 6790 (Entropy Lab= el) which has IPR https://datatracker.ietf.org/ipr/search/?rfc=3D6790&submi= t=3Drfc Regards, --Bruno > -----Original Message----- > From: John G. Scudder [mailto:jgs@juniper.net] > Sent: Saturday, May 20, 2017 9:40 PM > To: idr@ietf.org > Cc: mpls@ietf.org; draft-decraene-idr-next-hop-capability@ietf.org > Subject: Re: [mpls] Working Group adoption call for draft-decraene-idr-n= ext-hop-capability- > 03 >=20 > BTW I forgot to mention, authors, please say if you're aware of any IPR = that applies. >=20 > Regards, >=20 > --John >=20 > > On May 18, 2017, at 12:32 PM, John G. Scudder wrote: > > > > Hi All, > > > > IDR working group adoption has been requested for draft-decraene-idr-n= ext-hop- > capability-03. Please send your comments to the IDR mailing list before = June 2, 2017. Please > remember that we need affirmative support in order to adopt the draft, s= o don't be shy. > > > > draft datatracker page: https://datatracker.ietf.org/doc/draft-decraen= e-idr-next-hop- > capability/ > > slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides= -98-idr-08-bgp- > next-hop-dependent-capabilities-00.pdf > > > > Since in part this draft specifies a replacement for the Entropy Label= Capability Attribute > (ELCA) that was defined by the MPLS WG in RFC 6790 and deprecated by RFC= 7447, I have > cc'd the MPLS WG mailing list. Since the proposed new attribute is a gen= eric container with > the ELCA replacement just the first application, the current draft is ta= rgeted to IDR and not > MPLS (this was discussed during IETF-93). > > > > Thanks, > > > > --John ___________________________________________________________________________= ______________________________________________ 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 May 22 01:13:07 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9C5129BA9 for ; Mon, 22 May 2017 01:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 ZO4mSgPZwUX2 for ; Mon, 22 May 2017 01:13:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C9C129BA3 for ; Mon, 22 May 2017 01:13:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHB47249; Mon, 22 May 2017 08:13:01 +0000 (GMT) Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 22 May 2017 09:12:47 +0100 Received: from DGGEML508-MBS.china.huawei.com ([169.254.4.216]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0301.000; Mon, 22 May 2017 16:12:39 +0800 From: Mach Chen To: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-lag-multipath-02.txt Thread-Index: AQHS0TTYBGUAVAL7bEyZg8t0VpwAtqIAAmFw Date: Mon, 22 May 2017 08:12:39 +0000 Message-ID: References: <149526270007.30807.7914963763043233675@ietfa.amsl.com> In-Reply-To: <149526270007.30807.7914963763043233675@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59229D8E.0077, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.216, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 44bed5a195fd8f8358dfee1cf8e3ab00 Archived-At: Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-lag-multipath-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 08:13:06 -0000 Hi MPLSers, We just uploaded a revision, the mainly updates are references. We'd apprec= iate that you could spend some time to review this draft, any comments and = feedbacks are welcome!=20 Thanks, Mach (on behalf of the co-authors) > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Saturday, May 20, 2017 2:45 PM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-lag-multipath-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiprotocol Label Switching of the IET= F. >=20 > Title : Label Switched Path (LSP) Ping/Trace Multipath = Support for > Link Aggregation Group (LAG) Interfaces > Authors : Nobo Akiya > George Swallow > Stephane Litkowski > Bruno Decraene > John E. Drake > Mach(Guoyi) Chen > Filename : draft-ietf-mpls-lsp-ping-lag-multipath-02.txt > Pages : 27 > Date : 2017-05-19 >=20 > Abstract: > This document defines an extension to the MPLS Label Switched Path > (LSP) Ping and Traceroute as specified in RFC 8029. The extension > allows the MPLS LSP Ping and Traceroute to discover and exercise > specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link > Aggregation Group (LAG) interfaces. >=20 > This document updates RFC8029. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-lag-multipath/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-lag-multipath-02 > https://datatracker.ietf.org/doc/html/draft-ietf-mpls-lsp-ping-lag-multip= ath- > 02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-lsp-ping-lag-multipat= h-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Mon May 22 08:02:12 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE27120046; Mon, 22 May 2017 08:02:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-mpls-tp-shared-ring-protection@ietf.org, Eric Gray , mpls-chairs@ietf.org, Eric.Gray@Ericsson.com, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149546532470.14956.16147225784444997069.idtracker@ietfa.amsl.com> Date: Mon, 22 May 2017 08:02:04 -0700 Archived-At: Subject: [mpls] Warren Kumari's No Objection on draft-ietf-mpls-tp-shared-ring-protection-05: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 15:02:05 -0000 Warren Kumari has entered the following ballot position for draft-ietf-mpls-tp-shared-ring-protection-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some nits and a question: 3. MPLS-TP Ring Protection Criteria and Requirements a. The number of OAM entities... "Each ring-node requires only one instance of the RPS protocol. " --- not super important, but is this "Each ring-node requires only one instance of the RPS protocol (regardless of the number of rings)" or "Each ring-node requires only one instance of the RPS protocol per ring"? -- if a node participates in multiple rings, does it need an instance for each ring? (I suspect that this is somewhat of an implementation choice, but am not sure). 4. Shared Ring Protection Architecture 4.1. Ring Tunnel "... ring tunnels which provides a server layer for the LSPs traverse the ring." I think "for the LSP's traversing the ring." (or perhaps "which traverse the ring.") From nobody Mon May 22 13:29:02 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73683128792; Mon, 22 May 2017 13:28:54 -0700 (PDT) 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_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuerhtnXwrjk; Mon, 22 May 2017 13:28:52 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0125.outbound.protection.outlook.com [104.47.1.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 CAA74126CF9; Mon, 22 May 2017 13:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=154qFWHKdgiLmqY1IIqzt+Pe2nO/ucX7TB2MXI0/cCM=; b=bmrxp7AlTEUtLO+KqueTEc28zjwIdJQ+61fkap20GNmKWGJxDOr1dd5b8jbsW+XkaSN0BnO8qePybeEOdGlWJQpqmyfcLcr5mK9PmZyZKjppW/IyEf2gG7D//gCiZ//5kM0mzV/sP5QXCK+0SukZXzxdN5cp2ipnGFJQ6BegL/Y= Received: from AM2PR07MB0961.eurprd07.prod.outlook.com (10.162.37.144) by AM2PR07MB0963.eurprd07.prod.outlook.com (10.162.37.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Mon, 22 May 2017 20:28:48 +0000 Received: from AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::8ca8:abc5:c3c7:9d6d]) by AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::8ca8:abc5:c3c7:9d6d%15]) with mapi id 15.01.1124.007; Mon, 22 May 2017 20:28:48 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: "bruno.decraene@orange.com" , "John G. Scudder" CC: "mpls@ietf.org" , "draft-decraene-idr-next-hop-capability@ietf.org" , "idr@ietf.org" Thread-Topic: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 Thread-Index: AQHSz/VTfsG4m8/9b0SvgXKKVya+jKH9odKAgAJT9gCAAMWPAA== Date: Mon, 22 May 2017 20:28:47 +0000 Message-ID: References: <26881_1495437183_59228F7F_26881_13214_1_53C29892C857584299CBF5D05346208A31D21DCD@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <26881_1495437183_59228F7F_26881_13214_1_53C29892C857584299CBF5D05346208A31D21DCD@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: nl-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170403 authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [89.225.206.56] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0963; 7:6FtqS5dQo3avWibi8C1F38rteaaF0wKiqXQ/oRlC1fv6Llxsr/VxLyiBlhr+JkSByF7E1tAzohP4PklRl7aUWxp4/s/90SpOilCTWEV4hnksCFC5dsa+QyOgXk3IE/Rhw1K7IECqJ72T7O+So4iTBOUErLD9f7uws5VjnCQGKyfYqCL+xQ2GDPPDXmAuQHEtPg5VozmNklccxJEgjdm/wd/zqpGQ02trHX7C7G+Lq261h8CAAMdx0WqL3EciH1R9+zJ6YDxgM+bAa1mLq3snY+QzNph+JPQwj5IibINS43G1sM0XIQr7LxC5EjG6EsUiFDnU69aa+3oNaU+4Yzb89A== x-ms-traffictypediagnostic: AM2PR07MB0963: x-ms-office365-filtering-correlation-id: 0411bc1d-ee5c-4907-c825-08d4a1512728 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:AM2PR07MB0963; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(138986009662008)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(6072148); SRVR:AM2PR07MB0963; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0963; x-forefront-prvs: 03152A99FF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39840400002)(39400400002)(39850400002)(39410400002)(13464003)(24454002)(53754006)(377454003)(82746002)(4001350100001)(25786009)(83506001)(83716003)(38730400002)(53546009)(86362001)(54356999)(54906002)(76176999)(36756003)(229853002)(2950100002)(6512007)(6506006)(305945005)(6436002)(7736002)(478600001)(81166006)(5660300001)(5890100001)(8676002)(4326008)(50986999)(8666007)(102836003)(189998001)(2501003)(6116002)(99286003)(6246003)(66066001)(6306002)(2900100001)(8936002)(53936002)(3846002)(3660700001)(230783001)(33656002)(2906002)(3280700002)(6486002)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0963; H:AM2PR07MB0961.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <08B8BEB4EDC0FC44868DFB740D15B09D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2017 20:28:47.2458 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0963 Archived-At: Subject: Re: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 20:28:54 -0000 Tm90IGF3YXJlIG9mIElQUiBlaXRoZXIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0DQoNCk9uIDIyLzA1 LzIwMTcsIDA4OjEzLCAiYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSIgPGJydW5vLmRlY3JhZW5l QG9yYW5nZS5jb20+IHdyb3RlOg0KDQogICAgSSdtIG5vdCBhd2FyZSBvZiBJUFIuDQogICAgDQog ICAgTm90ZSB0aGF0IHRoaXMgZHJhZnQgYm9ycm93cyBhIHZlcnkgc21hbGwgc3Vic2V0IGZyb20g UkZDIDY3OTAgKEVudHJvcHkgTGFiZWwpIHdoaWNoIGhhcyBJUFIgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9pcHIvc2VhcmNoLz9yZmM9Njc5MCZzdWJtaXQ9cmZjDQogICAgDQogICAgUmVn YXJkcywNCiAgICAtLUJydW5vDQogICAgDQogICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCiAgICAgPiBGcm9tOiBKb2huIEcuIFNjdWRkZXIgW21haWx0bzpqZ3NAanVuaXBlci5uZXRd DQogICAgID4gU2VudDogU2F0dXJkYXksIE1heSAyMCwgMjAxNyA5OjQwIFBNDQogICAgID4gVG86 IGlkckBpZXRmLm9yZw0KICAgICA+IENjOiBtcGxzQGlldGYub3JnOyBkcmFmdC1kZWNyYWVuZS1p ZHItbmV4dC1ob3AtY2FwYWJpbGl0eUBpZXRmLm9yZw0KICAgICA+IFN1YmplY3Q6IFJlOiBbbXBs c10gV29ya2luZyBHcm91cCBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1kZWNyYWVuZS1pZHItbmV4 dC1ob3AtY2FwYWJpbGl0eS0NCiAgICAgPiAwMw0KICAgICA+IA0KICAgICA+IEJUVyBJIGZvcmdv dCB0byBtZW50aW9uLCBhdXRob3JzLCBwbGVhc2Ugc2F5IGlmIHlvdSdyZSBhd2FyZSBvZiBhbnkg SVBSIHRoYXQgYXBwbGllcy4NCiAgICAgPiANCiAgICAgPiBSZWdhcmRzLA0KICAgICA+IA0KICAg ICA+IC0tSm9obg0KICAgICA+IA0KICAgICA+ID4gT24gTWF5IDE4LCAyMDE3LCBhdCAxMjozMiBQ TSwgSm9obiBHLiBTY3VkZGVyIDxqZ3NAanVuaXBlci5uZXQ+IHdyb3RlOg0KICAgICA+ID4NCiAg ICAgPiA+IEhpIEFsbCwNCiAgICAgPiA+DQogICAgID4gPiBJRFIgd29ya2luZyBncm91cCBhZG9w dGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LWRlY3JhZW5lLWlkci1uZXh0LWhvcC0N CiAgICAgPiBjYXBhYmlsaXR5LTAzLiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBJ RFIgbWFpbGluZyBsaXN0IGJlZm9yZSBKdW5lIDIsIDIwMTcuIFBsZWFzZQ0KICAgICA+IHJlbWVt YmVyIHRoYXQgd2UgbmVlZCBhZmZpcm1hdGl2ZSBzdXBwb3J0IGluIG9yZGVyIHRvIGFkb3B0IHRo ZSBkcmFmdCwgc28gZG9uJ3QgYmUgc2h5Lg0KICAgICA+ID4NCiAgICAgPiA+IGRyYWZ0IGRhdGF0 cmFja2VyIHBhZ2U6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRlY3Jh ZW5lLWlkci1uZXh0LWhvcC0NCiAgICAgPiBjYXBhYmlsaXR5Lw0KICAgICA+ID4gc2xpZGVzIGZy b20gSUVURi05ODogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3Ns aWRlcy05OC1pZHItMDgtYmdwLQ0KICAgICA+IG5leHQtaG9wLWRlcGVuZGVudC1jYXBhYmlsaXRp ZXMtMDAucGRmDQogICAgID4gPg0KICAgICA+ID4gU2luY2UgaW4gcGFydCB0aGlzIGRyYWZ0IHNw ZWNpZmllcyBhIHJlcGxhY2VtZW50IGZvciB0aGUgRW50cm9weSBMYWJlbCBDYXBhYmlsaXR5IEF0 dHJpYnV0ZQ0KICAgICA+IChFTENBKSB0aGF0IHdhcyBkZWZpbmVkIGJ5IHRoZSBNUExTIFdHIGlu IFJGQyA2NzkwIGFuZCBkZXByZWNhdGVkIGJ5IFJGQyA3NDQ3LCBJIGhhdmUNCiAgICAgPiBjYydk IHRoZSBNUExTIFdHIG1haWxpbmcgbGlzdC4gU2luY2UgdGhlIHByb3Bvc2VkIG5ldyBhdHRyaWJ1 dGUgaXMgYSBnZW5lcmljIGNvbnRhaW5lciB3aXRoDQogICAgID4gdGhlIEVMQ0EgcmVwbGFjZW1l bnQganVzdCB0aGUgZmlyc3QgYXBwbGljYXRpb24sIHRoZSBjdXJyZW50IGRyYWZ0IGlzIHRhcmdl dGVkIHRvIElEUiBhbmQgbm90DQogICAgID4gTVBMUyAodGhpcyB3YXMgZGlzY3Vzc2VkIGR1cmlu ZyBJRVRGLTkzKS4NCiAgICAgPiA+DQogICAgID4gPiBUaGFua3MsDQogICAgID4gPg0KICAgICA+ ID4gLS1Kb2huDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIA0KICAgIENlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KICAgIHBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQog ICAgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwNCiAgICBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQogICAgDQog ICAgVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh dzsNCiAgICB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi4NCiAgICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCiAgICBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuDQogICAgVGhhbmsgeW91Lg0KICAgIA0KICAgIA0KDQo= From nobody Tue May 23 12:42:10 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF4412EA52; Tue, 23 May 2017 12:42:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-mpls-tp-shared-ring-protection@ietf.org, Eric Gray , mpls-chairs@ietf.org, Eric.Gray@Ericsson.com, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149556852369.28549.1939050026668607048.idtracker@ietfa.amsl.com> Date: Tue, 23 May 2017 12:42:03 -0700 Archived-At: Subject: [mpls] Ben Campbell's No Objection on draft-ietf-mpls-tp-shared-ring-protection-05: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 19:42:04 -0000 Ben Campbell has entered the following ballot position for draft-ietf-mpls-tp-shared-ring-protection-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: - The abbreviation "MSRP" is already used by RFC 4975. Please avoid overloading it if at all possible. (And you probably want to collide with "Manufacturer's Suggested Retail Price" even less.) -4.4.2: "When the service LSP passes through the interconnected rings, the direction of the working ring tunnels used on both rings SHOULD be the same. " Would it ever make sense for the directions to be different? (That is, why not MUST?) If so, a few words about that would be helpful. -5.1, 3rd bullet: "Determination of the affected traffic SHOULD be performed by examining the RPS requests (indicating the nodes adjacent to the failure or failures) and the stored ring map (indicating the relative position of the failure and the added traffic destined towards that failure)." Would it ever make sense to violate that SHOULD? (That is, why not MUST?) -6.2: Why "standards action"? That's a high bar. Are there reasons why a lower bar like "specification required" would not be appropriate? For example, are we in danger of running out of code points? Is this registry at unusual risk for poor quality registrations? Editorial: -3: Is this section expected to be useful to implementors? It reads more like evidence to the WG that this meets the requirements. I suspect people won't much care about that once this is published as an RFC. Please consider moving it to an appendix, or even removing it entirely. -4.4.2: "For example, if the service LSP uses the clockwise working ring tunnel on Ring1, when the service LSP leaves Ring1 and enters Ring2, the working ring tunnel used on Ring2 SHOULD also follow the clockwise direction." Please avoid repeating the 2119 "SHOULD" in the example. - 5.1: "The MSRP protection operation MUST be controlled with the help of the Ring Protection Switch protocol (RPS)." That seems like a statement of fact, rather than an implementation requirement. Starting around 5.1, I notice several uses of the word "source" as a verb, where from context it seems like you mean "to send" or "to originate". Is that a term of art? I usually think of "source" as a verb to mind "acquire","find" or "find a source for" -5.3: "... thus RPS SHOULD be capable of identifying and handling the different failures on the ring ..." That seems like a statement of fact. From nobody Tue May 23 19:22:50 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA791205D3; Tue, 23 May 2017 19:22:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-mpls-tp-aps-updates@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149559256256.28439.7438793838191577539.idtracker@ietfa.amsl.com> Date: Tue, 23 May 2017 19:22:42 -0700 Archived-At: Subject: [mpls] Adam Roach's No Objection on draft-ietf-mpls-tp-aps-updates-03: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 02:22:42 -0000 Adam Roach has entered the following ballot position for draft-ietf-mpls-tp-aps-updates-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-aps-updates/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The acronym table lists two one-letter acronyms, which appear to actually be keys to codes in a table instead of actual acronyms. I would propose moving the definition of "i" and "N" from section 3 into section 4.2. Also, section 3 contains expansions for "PF:DW:R," "PF:W:L," and "PF:W:R," but not "SA:MP:R," and "SA:MW:R." This seems oddly inconsistent; I would suggest adding entries for the two "SA:..." acronyms. From nobody Tue May 23 23:21:33 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0638E1204DA; Tue, 23 May 2017 23:21:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-mpls-tp-shared-ring-protection@ietf.org, Eric Gray , mpls-chairs@ietf.org, Eric.Gray@Ericsson.com, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149560689201.28401.2592268750185030462.idtracker@ietfa.amsl.com> Date: Tue, 23 May 2017 23:21:32 -0700 Archived-At: Subject: [mpls] Eric Rescorla's Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 06:21:32 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-mpls-tp-shared-ring-protection-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The security considerations of this document seem unacceptably incomplete, as they basically just point to other documents. The RPS protocol defined in this document is carried in the G-ACh [RFC5586], which is a generalization of the Associated Channel defined in [RFC4385]. The security considerations specified in these documents apply to the proposed RPS mechanism. The security considerations of those documents don't seem that great either. However, I believe that they miss a new security issue raised by the mechanism in this draft, which is that a member of the ring appears to be able to forge reports of errors at other parts of the ring. Specifically, S 5.1.3.3 says: When a node is in a pass-through state, it MUST transfer the received RPS Request in the same direction. When a node is in a pass-through state, it MUST enable the traffic flow on protection ring tunnels in both directions. This seems not to involve any filtering, which suggests that node B can send a forged SF from C->D and from D->C, which at least potentially temporarily breaks the link there, causing traffic diversion. More generally, this system assumes that every node trusts every other node completely. That must at least be stated. Incidentally, the text above appears to contain a bug in that it doesn't talk about processing incoming RPS requests intended for the receiving node, but I may just have missed the section where it says that. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 4.1.1. protect these LSPs that traverse the ring, a clockwise working ring tunnel (RcW_D) via E->F->A->B->C->D, and its anticlockwise protection ring tunnel (RaP_D) via D->C->B->A->F->E->D are established, Also, an anti-clockwise working ring tunnel (RaW_D) via C->B->A->F->E->D, and its clockwise protection ring tunnel (RcP_D) via D->E->F->A->B->C->D Why does the protection tunnel include D on both ends whereas the working tunnel does not? S 4.2. packets are periodically exchanged between each pair of MEPs to monitor the link health. Three consecutive lost CC packets will be interpreted as a link failure. Is this a normative statement (i.e., does it need a MUST). S 4.3.2.1. Why do you ever not use short wrapping? S 5.1.4.1 A node MUST revert from pass-through state to the idle state when it detects NR codes incoming from both directions. Both directions revert simultaneously from the pass-through state to the idle state. incoming within what time frame? From nobody Wed May 24 02:33:30 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F8A1293EB; Wed, 24 May 2017 02:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 uP0tuc9RuuhI; Wed, 24 May 2017 02:33:25 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (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 E0B72124BE8; Wed, 24 May 2017 02:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1495618405; x=1527154405; h=from:to:cc:subject:date:message-id:mime-version; bh=Jvi7n7VM6YRwZFiw5qSkwSkAdyR+lnlSq6l3hG7d5mk=; b=9G1uisl6Enrgcf4ShHdQXTHOwp4nLrxAtcegZVVUUn12J2nuawSoVkkI 7bD5ljQv1CXAOJcb1rgFABdP4G9vXRXUc8tgpRxNUpXUSV6ZWTkqgRALV AuiClpojZlnObpn6/7RKkg0+hoVbWox53KrVp/5t6VsL8i71Jvm7jzoI0 JCaleXth56jhPaZYVeAC3OVFyr8AMOnh/MOnr7W2V1ZVk+tp+Yxz9PXwN lc/3pcx/NXXC0suu/NAJxSWpUVsx4SnCaSH+z/8A1cmgnGAo9kca93LtR n0Tzkxu/YG5WcpTuKHQ8cDrHHvwxKhE//PUvHIzg7jmC2WHCIKiHplzP0 w==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2017 11:33:21 +0200 X-IronPort-AV: E=Sophos; i="5.38,385,1491256800"; d="scan'208,217"; a="18819030" Received: from he105661.emea1.cds.t-internal.com ([10.169.119.57]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 24 May 2017 11:33:21 +0200 Received: from HE105662.EMEA1.cds.t-internal.com (10.169.119.58) by HE105661.emea1.cds.t-internal.com (10.169.119.57) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 24 May 2017 11:33:21 +0200 Received: from HE105662.EMEA1.cds.t-internal.com ([fe80::442c:834e:c489:d2c4]) by HE105662.emea1.cds.t-internal.com ([fe80::442c:834e:c489:d2c4%26]) with mapi id 15.00.1263.000; Wed, 24 May 2017 11:33:21 +0200 From: To: CC: Thread-Topic: WGLC for draft-ietf-mpls-bfd-directed Thread-Index: AdLUcMggDQBvyYSLQg6+G4R+EOGYRg== Date: Wed, 24 May 2017 09:33:21 +0000 Message-ID: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.166.19] Content-Type: multipart/alternative; boundary="_000_db3adc45477f4e44ac48f1fb449a1850HE105662emea1cdstintern_" MIME-Version: 1.0 Archived-At: Subject: [mpls] WGLC for draft-ietf-mpls-bfd-directed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 09:33:28 -0000 --_000_db3adc45477f4e44ac48f1fb449a1850HE105662emea1cdstintern_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Working Group, The authors have updated draft-ietf-mpls-bfd-directed and think that the dr= aft is ready for WGLC. Therefore this e-mail starts a WG LC which will end on the 7th of June. Please note that draft-ietf-mpls-bfd-directed did not pass the previous working group last call, because of an IPR disclosure: https://datatracker.ietf.org/ipr/2892/ The authors have updated the draft and they believe that the IPR is no long= er in scope. Please notify the list if you still think the IPR is an issue and please st= ate if you think it is OK to continue with the publication of this document. Best regards Nic --_000_db3adc45477f4e44ac48f1fb449a1850HE105662emea1cdstintern_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Working Group,
 
The authors have updated draft-ietf-mpls-bfd-directed and think that t= he draft is ready for WGLC.
Therefore this e-mail starts a WG LC which will end on the 7th of June= .
        
Please note that draft-ietf-mpls-bfd-directed did not pass the
previous working group last call, because of an IPR disclosure:
 
 
The authors have updated the draft and they believe that the IPR is no= longer in scope.
Please notify the list if you still think the IPR is an issue and plea= se state if you think it
is OK to continue with the publication of this document.
 
  Best regards
 
    Nic
&nbs= p;
&nbs= p;
 --_000_db3adc45477f4e44ac48f1fb449a1850HE105662emea1cdstintern_-- From nobody Wed May 24 05:47:22 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFFB129C26; Wed, 24 May 2017 05:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 3MkeUWYs3W6k; Wed, 24 May 2017 05:47:19 -0700 (PDT) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 DC4351287A0; Wed, 24 May 2017 05:47:18 -0700 (PDT) Received: by mail-wr0-x242.google.com with SMTP id j27so3204322wre.2; Wed, 24 May 2017 05:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version; bh=ClrpU5vZnfJndWX3kHrUz78eI8XAhEEt9MHeDsAXZnk=; b=oGQn4o94cDg+e0Lq9tnMFAN76391sV44iVelJkvS56kNUMDTcFR3V7ng3eiR+9qMwp hYidlQ8ZzuuJG8dC+BQGC7T9lbpik6xxx+wahoI/9ZYHhVYlxnlIxGDXAccBO6BKdjVG kYq+bDxj42CVCENODQ5ihVDldeYbMLU/tYxiY7S9XT2G3z+dzkYjdFsut4uDevLsJA3y Sx1g9QHo4fHUEkwQWwvrjR93yWAwSvL1S2ZxsGWDaYI7xhuPPkDKE+OdDmhqyuK+ji6d 1gyQBByGugeByMMZfwzf3ZZhPh2K0odxwScCbg6tSMtuDFmw7hRT3sqiCIvkGWkWLXtV RlxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version; bh=ClrpU5vZnfJndWX3kHrUz78eI8XAhEEt9MHeDsAXZnk=; b=Ld35u/Phhw1hyykygIkRl0cHW+necLV6wEx9xIxhjBigZFYtMPkIKEtJXLd3YWWodx pOXsqZKgRVlmejpRLZWB8Ki1lT9jU3BoCjBW9eGFP5anstY8cwlqUFaGBHHVuJ4MddxA uydoH4sAqD0rjYUXxy6OC11oQdOvcm7tiUfP7UQOmf4eaEr33sXsqOPV2FMJTa+0huYn EYPjMN2cQpGV2o1wh4xhNFyCrVE0hxCacp4Jxrjs4kL1Klb23YuHm6oIdxCUVIPBsnL+ 8pbMGNUCPFMjBlfX+8c4+GhOKLAGaeRK752E0CFD3NgNDWo8/1a4vI1JOC/W3+Mg6nQt NtsA== X-Gm-Message-State: AODbwcBJswSPoR/E7JvdyYddWfax/eATsCuQAINazyUEihNJrzkqJtV7 64Cj3ooHewOMNw== X-Received: by 10.223.157.29 with SMTP id k29mr20291909wre.156.1495630037435; Wed, 24 May 2017 05:47:17 -0700 (PDT) Received: from [172.28.4.31] ([195.238.226.2]) by smtp.gmail.com with ESMTPSA id p139sm5028956wmg.14.2017.05.24.05.47.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 05:47:16 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 24 May 2017 05:47:16 -0700 From: Jeff Tantsura To: , CC: Message-ID: <79E63287-61B2-4446-8E6C-08CE69D562D0@gmail.com> Thread-Topic: [mpls] WGLC for draft-ietf-mpls-bfd-directed Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3578449636_586434008" Archived-At: Subject: Re: [mpls] WGLC for draft-ietf-mpls-bfd-directed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 12:47:21 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3578449636_586434008 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable support as co-author =20 Updated draft doesn=E2=80=99t have any IPR associated with it that I=E2=80=99m aware of= .=20 Thanks! =20 Cheers, Jeff =20 =20 From: mpls on behalf of Date: Wednesday, May 24, 2017 at 02:33 To: Cc: Subject: [mpls] WGLC for draft-ietf-mpls-bfd-directed =20 Dear Working Group, =20 The authors have updated draft-ietf-mpls-bfd-directed and think that the dr= aft is ready for WGLC. Therefore this e-mail starts a WG LC which will end on the 7th of June. =20 Please note that draft-ietf-mpls-bfd-directed did not pass the=20 previous working group last call, because of an IPR disclosure: =20 https://datatracker.ietf.org/ipr/2892/ =20 The authors have updated the draft and they believe that the IPR is no long= er in scope. Please notify the list if you still think the IPR is an issue and please st= ate if you think it=20 is OK to continue with the publication of this document. =20 Best regards =20 Nic =20 =20 _______________________________________________ mpls mailing list mpls@ietf= .org https://www.ietf.org/mailman/listinfo/mpls=20 --B_3578449636_586434008 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

support as co-author

=  <= /p>

Upd= ated draft doesn’t have any IPR associated with it that I’m awar= e of.

Thanks!

<= span style=3D'font-size:10.5pt;font-family:Calibri;color:black'> 

Cheers,

Jeff

 

 

From: mpls <mp= ls-bounces@ietf.org> on behalf of <N.Leymann@telekom.de>
Date= : Wednesday, May 24, 2017 at 02:33
To: <mpls@ietf.org>Cc: <mpls-chairs@ietf.org>
Subject: [mpls] WGLC for= draft-ietf-mpls-bfd-directed

 

Dear Working Group,

 

The authors hav= e updated draft-ietf-mpls-bfd-directed and think that the draft is ready for= WGLC.

Therefore this e-= mail starts a WG LC which will end on the 7th of June.

=

       &nb= sp;

Please note that dr= aft-ietf-mpls-bfd-directed did not pass the

previous working group last call, because of an IPR dis= closure:

 

 

The authors have updated the draft and they believ= e that the IPR is no longer in scope.

Please notify the list if you still think the IPR is an issue = and please state if you think it

is OK to continue with the publication of this document.

 

  Best regards

 

    Nic

 

 

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

--B_3578449636_586434008-- From nobody Wed May 24 06:19:14 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A0D129B0D; Wed, 24 May 2017 06:19:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-mpls-tp-shared-ring-protection@ietf.org, Eric Gray , mpls-chairs@ietf.org, Eric.Gray@Ericsson.com, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149563195266.28533.2114103150241285236.idtracker@ietfa.amsl.com> Date: Wed, 24 May 2017 06:19:12 -0700 Archived-At: Subject: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-mpls-tp-shared-ring-protection-05=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 13:19:13 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-mpls-tp-shared-ring-protection-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Two technical comments that I think are important to address but do not warrant a discuss: 1) section 5.2: "As shown in Figure 14, when no protection switching is active on the ring, each node MUST send RPS requests with No Request (NR) to its two adjacent nodes periodically." What does periodically mean here? Can you maybe give a number or even a normative statement like "and MUST NOT send more often than every X seconds" to avoid unnecessary congestion...? 2) section 5.1.1: "A ring node which is not the destination of the received RPS message MUST forward it to the next node along the ring immediately." Why would you forward these? I thought you only send messages to your neighbors? Maybe I missed this but is there a use case for this scenario? Otherwise it might be safer to not forward to avoid that messages with a wrong destination node ID circle around forever. If you forward maybe you also need a hop-count to decrease or at least say that messages that are received and have the own node ID as source node ID MUST be dropped...? Further, as mentioned by Ben for a couple of case, some of the uses of normative language in section 5 seems not to be appropriate as they don't specify a concrete implementation action. Please check carefully and change some to lower case instead, e.g. "The MSRP protection operation MUST be controlled with the help of the Ring Protection Switch protocol (RPS). " "The RPS protocol MUST carry the ring status information and RPS requests,.." (this sounds like a requirement on the protocol design but when you implement the protocol as specified there is no way to not do it, so this MUST is unnecessary) "Each node on the ring MUST be uniquely identified by assigning it a node ID." (also requirement-like; the MUST in the next sentence is the important one) "When a node detects a failure and determines that protection switching is required, it MUST send the appropriate RPS request in both directions to the destination node." "MSRP mechanism SHOULD support multiple protection switches in the ring, resulting in the ring being segmented into two or more separate segments. " "The first three RPS protocol messages carrying new RPS request SHOULD be transmitted as fast as possible." (Again the later SHOULD is the more important one) There may be more… From nobody Wed May 24 06:22:40 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931C5129B25; Wed, 24 May 2017 06:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebyHdjyCrtIb; Wed, 24 May 2017 06:22:26 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 B99AC129B0D; Wed, 24 May 2017 06:22:26 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id w10so241471001oif.0; Wed, 24 May 2017 06:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+tOdzGLXxz57gI/dQWamsDBvGrMJ9NmiI8veeqT/2Rc=; b=pMMvZNrjxDQYD2+1wWeZ5wD7+PcA860g/LYtI91KZQaRchfcWjkogdDL5v5BNsf6eQ bvQV+SLL+5rF9NmPjLPwb9sd2zH61pHNADnlakEKctBMXUWJqhqJ62p0+NDMbk0WSxBv 8jXcx2NA9EffkuhCxLXcfIxbY9oBQFVIkkWpmer5csUFwi336KewHHjN2lmgwkbR5vjw PlLnKhHRFoEvHNAqyg21Xce/aagsZN54yB1JGb22jhj54h3bLtyG70uQCTeL+UyuNl0v swS7ACL+oN9HYuA/34pr+rFNnsLh5hCvW6hHkuxkU1mhFi26h/NCVj3RIo8BIPwzD2s3 EDhg== 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=+tOdzGLXxz57gI/dQWamsDBvGrMJ9NmiI8veeqT/2Rc=; b=jc64GMCGgA1g9G741x+ss0tSX47nfKhnNM5YuJhuR7rC6gSuZVVZiiFf4nPw6btlRw cGs3i3ApD6kVbY4XLtJc69JqwT6cczy2FuPmNjgioRWjfNMIYji7RmKQlatH3Pg8XnOD CnEeRAAYLE8LGMhSjGZ31CRYmXroU9ft7qASyZj/HMePk5jHDr+DBV5bPjYhWyFokYlj i5oz0pdiZmX5HbCdrYnUbixev8q0KQDP52gxlPLE25m7z6g/11KwQvkjxiu7oT+ZsoBj /QXm1kyeSBrynjsDkXaGuMDpIIkuffwBpIkXElaaSw/mIWey/Ye+nmHgOo5ogcBtOlEW wzIQ== X-Gm-Message-State: AODbwcCokPWL/+cxMg/yjO7uIkSX0IIFl6tZu5A5/WryI60OwEdtEcqq b9hmUEITOfRhHwf++KNoWs8d5sHP3A== X-Received: by 10.202.198.208 with SMTP id w199mr15389709oif.115.1495632146054; Wed, 24 May 2017 06:22:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.246 with HTTP; Wed, 24 May 2017 06:22:25 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Wed, 24 May 2017 21:22:25 +0800 Message-ID: To: "n.leymann@telekom.de" Cc: "mpls@ietf.org" , mpls-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a1134fbb4c7c690055044fe82" Archived-At: Subject: Re: [mpls] WGLC for draft-ietf-mpls-bfd-directed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 13:22:38 -0000 --001a1134fbb4c7c690055044fe82 Content-Type: text/plain; charset="UTF-8" Hi Nick, I don't know of any IETF regulations or rules that prescribe to prevent progressing a document based on type of IPR Disclosure. I'd note that authors did their best to ensure that appropriate IPR Disclosures were filed as soon as possible. I believe that there were no concerns regarding timing of the IPR Disclosures related to earlier versions of the draft. Regards, Greg On Wed, May 24, 2017 at 5:33 PM, wrote: > Dear Working Group, > > The authors have updated draft-ietf-mpls-bfd-directed and think that the > draft is ready for WGLC. > Therefore this e-mail starts a WG LC which will end on the 7th of June. > > Please note that draft-ietf-mpls-bfd-directed did not pass the > previous working group last call, because of an IPR disclosure: > > *https://datatracker.ietf.org/ipr/2892/* > > > The authors have updated the draft and they believe that the IPR is no > longer in scope. > Please notify the list if you still think the IPR is an issue and please > state if you think it > is OK to continue with the publication of this document. > > Best regards > > Nic > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --001a1134fbb4c7c690055044fe82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nick,
I don't know of any IETF regulations or r= ules that prescribe to prevent progressing a document based on type of IPR = Disclosure. I'd note that authors did their best to ensure that appropr= iate IPR Disclosures were filed as soon as possible. I believe that there w= ere no concerns regarding timing of the IPR Disclosures related to earlier = versions of the draft.

Regards,
Greg

On Wed, M= ay 24, 2017 at 5:33 PM, <N.Leymann@telekom.de> wrote:
Dear Working Group,
=C2=A0
The authors have updated draft-ietf-mpls-bfd-directed and think that t= he draft is ready for WGLC.
Therefore this e-mail starts a WG LC which will end on the 7th of June= .
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Please note that draft-ietf-mpls-bfd-directed did not pass the
previous working group last call, because of an IPR disclosure:
=C2=A0
=C2=A0
The authors have updated the draft and they believe that the IPR is no= longer in scope.
Please notify the list if you still think the IPR is an issue and plea= se state if you think it
is OK to continue with the publication of this document.
=C2=A0
=C2=A0 Best regards
=C2=A0
=C2=A0=C2=A0=C2=A0 Nic
=C2= =A0
=C2= =A0

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


--001a1134fbb4c7c690055044fe82-- From nobody Wed May 24 06:32:14 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 018AE129B28; Wed, 24 May 2017 06:32:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-mpls-tp-shared-ring-protection@ietf.org, mpls-chairs@ietf.org, Eric.Gray@Ericsson.com, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149563272600.28525.2879582761085460802.idtracker@ietfa.amsl.com> Date: Wed, 24 May 2017 06:32:06 -0700 Archived-At: Subject: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-tp-shared-ring-protection-05: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 13:32:06 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-mpls-tp-shared-ring-protection-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document describes 3 different protection mechanisms and it specifies that all nodes "MUST use the same protection mechanism". When should these mechanisms be used? What are the conditions that an operator should take into account when selecting between them? I would like to see operational considerations explained. From nobody Wed May 24 06:35:36 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA710129B28; Wed, 24 May 2017 06:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np15K37EV5lK; Wed, 24 May 2017 06:35:34 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 6395E1293FD; Wed, 24 May 2017 06:35:34 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id w10so241983399oif.0; Wed, 24 May 2017 06:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OdL7syrtXb2+0GCFVpbEOjgXi3gz4BRlyFD6zG0rkCk=; b=BDklVeegeKI84fV3k5uA3UaR4eCKTnIzFhtvhtGs3h9+Hos7iCiMo6o2lg8uV6CwzK 2mcbFZtLsLwoxGrml+O2FVfK7GXE7kMZpiRiYkPOA9udrSVm+xJ4X+9fPTJNHPPvr4RW /ZfFSFdkbpMikjAqfDYu8OA3Ih2RDm1gwM9Hnzp3mrKOGbi7+Ho60F+BA1qLsAwMEOH2 Gzvz3susKlheWCV8fQFr+QbzG/DG7X94TXFKpLLy0tiC0DC5WCpWEVF6FF4FRohlOBT6 kTRkzwUGHOO9VMC5EYap9B/HWkZL1oW07eoKtJ8GPNXC6cgQekL12wDcLs4Ks/1GqXGp n4QA== 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=OdL7syrtXb2+0GCFVpbEOjgXi3gz4BRlyFD6zG0rkCk=; b=B6hMEYSt4dOKpNSJZKd1eBmgcENBO4TG5CpNGkHUps6wMuOg1J9xf8Vg5k0EYdspVM izlyfcxbTQvlOOoM4WlRiSWUmjlb8gloEC1tNXkV848BYUJ1WJAg74NT+dvFZtynE9hl sPv9aVVd2z24SRRaOuBsgkRtQ+KJfqbJ1C9hNCTTo5yjWGVKxphBmaORdi+UeXMv/DYp FRLelySVLnOgBEhzH7Apdk19Dv86Pm8SHNpgNyH+/X/D8wqGGyvVA77s1j80J8JGXT2F ftmOy9kKht9C6GMvURZK3JajFOGLo78l6+zTM5pMIeUCjlprXFbMsbSGGkI2xRKJeBef TEMg== X-Gm-Message-State: AODbwcDXf0FkXRyu2Gc1UgpYAAWnxfouTc9iIepAljHfEajx7/7mfNbk dga4G7yMH/G8Xa03fXZ50aTZ3idU1KTy X-Received: by 10.157.82.87 with SMTP id q23mr4278032otg.52.1495632933753; Wed, 24 May 2017 06:35:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.246 with HTTP; Wed, 24 May 2017 06:35:33 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Wed, 24 May 2017 21:35:33 +0800 Message-ID: To: "n.leymann@telekom.de" Cc: "mpls@ietf.org" , mpls-chairs@ietf.org Content-Type: multipart/alternative; boundary="f403043c4becbb19110550452d37" Archived-At: Subject: Re: [mpls] WGLC for draft-ietf-mpls-bfd-directed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 13:35:36 -0000 --f403043c4becbb19110550452d37 Content-Type: text/plain; charset="UTF-8" Support as co-author The question whether the previously disclosed IPR is applicable to the current version of the draft, in my view, should be evaluated by the holder of the IPR. To the best of my understanding, the IPR is not applicable. Regards, Greg On Wed, May 24, 2017 at 5:33 PM, wrote: > Dear Working Group, > > The authors have updated draft-ietf-mpls-bfd-directed and think that the > draft is ready for WGLC. > Therefore this e-mail starts a WG LC which will end on the 7th of June. > > Please note that draft-ietf-mpls-bfd-directed did not pass the > previous working group last call, because of an IPR disclosure: > > *https://datatracker.ietf.org/ipr/2892/* > > > The authors have updated the draft and they believe that the IPR is no > longer in scope. > Please notify the list if you still think the IPR is an issue and please > state if you think it > is OK to continue with the publication of this document. > > Best regards > > Nic > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --f403043c4becbb19110550452d37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Support as co-author

The question wheth= er the =C2=A0previously disclosed IPR is applicable to the current version = of the draft, in my view, should be evaluated by the holder of the IPR. To = the best of my understanding, the IPR is not applicable.

Regards,
Greg=C2=A0
=
On Wed, May 24, 2017 at 5:33 PM, <N.Le= ymann@telekom.de> wrote:
Dear Working Group,
=C2=A0
The authors have updated draft-ietf-mpls-bfd-directed and think that t= he draft is ready for WGLC.
Therefore this e-mail starts a WG LC which will end on the 7th of June= .
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Please note that draft-ietf-mpls-bfd-directed did not pass the
previous working group last call, because of an IPR disclosure:
=C2=A0
=C2=A0
The authors have updated the draft and they believe that the IPR is no= longer in scope.
Please notify the list if you still think the IPR is an issue and plea= se state if you think it
is OK to continue with the publication of this document.
=C2=A0
=C2=A0 Best regards
=C2=A0
=C2=A0=C2=A0=C2=A0 Nic
=C2= =A0
=C2= =A0

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


--f403043c4becbb19110550452d37-- From nobody Wed May 24 08:33:05 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE7412EB1A; Wed, 24 May 2017 08:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 (2048-bit key) header.d=cooperw.in header.b=KLnmkXpt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BTfy7zZE 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 9Zp_bhdBGfO9; Wed, 24 May 2017 08:32:49 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A07C12EB0F; Wed, 24 May 2017 08:32:41 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E378220A03; Wed, 24 May 2017 11:32:40 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 24 May 2017 11:32:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=V8LVUJjp1gfvZeFcC4 26aDRezJw+5CpCG+uwLDNzClQ=; b=KLnmkXpt2clthH+xZued8oSIFznnvpv6b3 1rentOkiKIFEifcYc4xMziHnN91FzuechYNW9Neosg5eaXJ3fbaUi4VsP9Qc85hl vcTpgJzHxyz4bc3dyBTYfmaPmvMxNvfVyvvBOMfBQCagibK2kvraYp3ZJtetxetB f8yfBPXrd/n0pFYBTggNyK8MFVKwzMCXg4hRWWPA4MZYUqmY3WVS6QCVdbaXtPj+ Qp02WRSki9fTwJucqKXqhltDklUz64rmx22wH8pKW+xAEoRraLDhHqaiNv2lSr+G gGd5U/du9J1Mwz2W4Rid2hOHFy0NIce9LywfxWNV/dh2H9F+2q9A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=V8LVUJjp1gfvZeFcC426aDRezJw+5CpCG+uwLDNzClQ=; b=BTfy7zZE qqfwyHUyw3nCAbEzU/rb4iOs8aH6IlccM0gUILVGgDH1df7oiXHDPTg3afFBIILI hoqG0ShkcaX183fHsknubpxkP25gccZnE/WYxp+9kmsvAcDaAhKPwEtucOnneRfW 8xbp/gTQXjnhf0C9lf6XCFPDXxf8FY3bms/UBgqNKQquve85UeHeyKM4VxMTd/LM fngTlmkCUNUA3Dmdec1LVZgukCK7r1X72ZDr6NiZ4nL+x3qTJ7BlNnbWT+4RhlrW 7xPyY7R0eAG17gUuhb+vpEL1eVdFQLTFMvRQx7u8cu+GyvVG5lMKkVs2eh8spKin KzbINdpmfgECmA== X-ME-Sender: X-Sasl-enc: K7BEo66j85FMtLGG9X0MlZVZe8RqsP2F3NcQQxE2/09u 1495639960 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.165]) by mail.messagingengine.com (Postfix) with ESMTPA id EB3AD7E824; Wed, 24 May 2017 11:32:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <149448416047.16649.7655814250953782130@ietfa.amsl.com> Date: Wed, 24 May 2017 11:32:38 -0400 Cc: "gen-art >> General area reviewing team" , mpls@ietf.org, draft-ietf-mpls-tp-aps-updates.all@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <3C50B542-9E79-4799-AA44-2339FC34E528@cooperw.in> References: <149448416047.16649.7655814250953782130@ietfa.amsl.com> To: Roni Even X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [mpls] [Gen-art] Genart last call review of draft-ietf-mpls-tp-aps-updates-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 15:32:51 -0000 Roni, thanks for your review. I have balloted No Objection. Alissa > On May 11, 2017, at 2:29 AM, Roni Even wrote: > > Reviewer: Roni Even > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-mpls-tp-aps-updates-?? > Reviewer: Roni Even > Review Date: 2017-05-10 > IETF LC End Date: 2017-05-19 > IESG Telechat date: 2017-05-25 > > Summary: > > The document is ready for publication as a standard track RFC > > Major issues: > > Minor issues: > > Nits/editorial comments: > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed May 24 08:36:47 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63571129B7E; Wed, 24 May 2017 08:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 hynGLauzYiEB; Wed, 24 May 2017 08:36:43 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A31127369; Wed, 24 May 2017 08:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3790; q=dns/txt; s=iport; t=1495640203; x=1496849803; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CHn/GRw6IZTv7miMkmX6L7hna4nz2m4IVpTVHUFzpeg=; b=FrwkBxone6VFdKU+nzOPHRq3501N1qsg46zOG0J6o1g1MG1gpqolyFI3 6JhTHbS4trM0UUL56PB2aDfBpWwGcEyb9ECk/oXjRR/0mJ4K3iqk3/4dT WHWSWgsQXv5vJ6RGOymFGiNzPrxeVEW/kWi3fDfDM1eCppbsRTbdpsUfE I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C0AACIpyVZ/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHg2iKGJFZlXeCDyELhXgCGoJUPxgBAgEBAQEBAQFrHQu?= =?us-ascii?q?FGAEBAQECAQEBIRE6CwULAgEGAhgCAiYCAgIlCxUQAQEEDgWKHggOjxadYIImi?= =?us-ascii?q?z8BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhVSBXiuCcYQ1EgEcOoJYL4IxBZZ?= =?us-ascii?q?5hyoBhx+MCIIGhTyKNZRNAR84fwtxFUYSAYRkHIFjdoZ1gSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,386,1491264000"; d="scan'208";a="252344804" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2017 15:36:42 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v4OFagHT009029 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 May 2017 15:36:42 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 24 May 2017 11:36:41 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 24 May 2017 11:36:41 -0400 From: "Carlos Pignataro (cpignata)" To: "n.leymann@telekom.de" CC: mpls , "mpls-chairs@ietf.org" Thread-Topic: [mpls] WGLC for draft-ietf-mpls-bfd-directed Thread-Index: AdLUcMggDQBvyYSLQg6+G4R+EOGYRgAVEiEA Date: Wed, 24 May 2017 15:36:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.82.104] Content-Type: text/plain; charset="utf-8" Content-ID: <4762A3ABDF1A824B83D5766F3B8C54CF@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] WGLC for draft-ietf-mpls-bfd-directed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 15:36:45 -0000 TmljLA0KDQpJIGRvIG5vdCBzdXBwb3J0IGFkdmFuY2luZyB0aGlzIGRvY3VtZW50IGluIGl0cyBj dXJyZW50IGZvcm0uIEl0IGhhcyBtYW55IHRlY2huaWNhbCBkZWZpY2llbmNpZXMsIHNvbWUgb2Yg d2hpY2ggYXJlIGxpc3RlZCBhbmQgZGVzY3JpYmVkIGJlbG93Lg0KDQpJIGFsc28gYmVsaWV2ZSB5 b3VyIFdHTEMgbm90ZSBzaG91bGQgaGF2ZSBiZWVuIG11Y2ggbW9yZSBkZXRhaWxlZCBhbmQgY29t cHJlaGVuc2l2ZS4NCg0KSSBiZWxpZXZlIHRoaXMgaXMgdGhlIDNyZCBXR0xDIG9uIHRoaXMgZG9j dW1lbnQsIGNvcnJlY3Q/IChUaGF0IGdpdmVzIGEgbmV3IG1lYW5pbmcgdG8g4oCcTGFzdOKAnSA6 LSkgSWYgc28sIHRoYXQgc2hvdWxkIGhhdmUgYWxzbyBiZWVuIGNsYXJpZmllZCBpbiB0aGUgV0dM QyBlbWFpbCwgd2l0aCBhIG11Y2ggbW9yZSBjbGVhciBleHBsYW5hdGlvbiBhbmQgY29tcHJlaGVu c2l2ZSBzZXQgb2YgZGV0YWlscyBvZiBob3cgY29uY2VybnMgd2VyZSBkaXNjdXNzZWQgYW5kIGFk ZHJlc3NlZC4NCg0KPiBUaGUgYXV0aG9ycyBoYXZlIHVwZGF0ZWQgZHJhZnQtaWV0Zi1tcGxzLWJm ZC1kaXJlY3RlZCBhbmQgdGhpbmsgdGhhdCB0aGUgZHJhZnQgaXMgcmVhZHkgZm9yIFdHTEMuDQoN CkkgYW0gdmVyeSBjb25jZXJuZWQgdGhhdCB0aGVyZSB3YXMgbm8gZGlzY3Vzc2lvbiBvbiB0aGUg bGlzdCBvZiBhbnkgb2YgdGhvc2UgY2hhbmdlcy4gIFRoZSBhdXRob3JzIGJlbGlldmUgdGhlIGRy YWZ0IGlzIHJlYWR5IOKAlCBkbyB5b3UgYmVsaWV2ZSBzbyBhcyB3ZWxsLCBOaWM/IFdhcyBhIHNo ZXBoZXJkIHJldmlldyBwZXJmb3JtZWQgYW5kIGlzIHRoYXQgYXZhaWxhYmxlPw0KDQo+IFBsZWFz ZSBub3RlIHRoYXQgZHJhZnQtaWV0Zi1tcGxzLWJmZC1kaXJlY3RlZCBkaWQgbm90IHBhc3MgdGhl DQo+IHByZXZpb3VzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLCBiZWNhdXNlIG9mIGFuIElQUiBk aXNjbG9zdXJlOg0KDQpJcyB0aGF0IHRoZSAxc3Qgb3IgMm5kIFdHTEM/IEkgdGhpbmsgdGhpcyBz dGF0ZW1lbnQgaXMgYW4gb3ZlcnNpbXBsaWZpY2F0aW9uLiBUaGVyZSB3ZXJlIG1hbnkgdGVjaG5p Y2FsIGNvbmNlcm5zLiANCg0KQW55d2F5LCBzY2FubmluZyB0aHJvdWdoIHRoaXMgZG9jdW1lbnQs IHNvbWUgdGVjaG5pY2FsIGlzc3VlczoNCg0KMS4gVGhpcyBhcHByb2FjaCBhc3N1bWVzIHRoYXQg RkVDcyBkbyBub3QgZXZlciBjaGFuZ2UuIEEgcmV2ZXJzZSBwYXRoIGlzIGluc3RydWN0ZWQgYXQg c2V0dXAvYm9vdHN0cmFwIHdpdGggTVBMUyBMU1AgUGluZyDigJQgd2hhdCBoYXBwZW5zIGlmIHBh dGhzIGNoYW5nZT8hPyBJZiBhIHJldHVybiB0dW5uZWwgaXMgc3VkZGVubHkgZGVsZXRlZCBmcm9t IHVuZGVybmVhdGg/DQoyLiDigJxDYXNlIG9mIE1QTFMgRGF0YSBQbGFuZeKAnSDigJQgaXMgdGhl cmUgYW55IG90aGVyIG5vbi1NUExTIGNhc2U/IFRoaXMgcG9pbnRzIHRvIHRoZSBmYWN0IG9mIGxh Y2sgb2YgcmV2aWV3IGFuZCBlZGl0b3JpYWwgc2xvcHBpbmVzcy4NCjMuIOKAnEV4YWN0bHkgb25l IHN1Yi1UTFYgTVVTVCBiZSBpbmNsdWRlZCBpbiB0aGUgUmV2ZXJzZSBQYXRoIFRMVi7igJ0g4oCU IHNvIGJhc2ljYWxseSwgbm8gVHVubmVscyBjYW4gYmUgcmV0dXJuIHBhdGg/IT8NCjQuIFRoZSDi gJxVc2UgQ2FzZSBTY2VuYXJpb+KAnSB1c2VzIDIxMTkgbGFuZ3VhZ2UgaW4gYSB3YXkgdGhhdCBk b2VzIG5vdCBtYWtlIHNlbnNlLg0KDQpQbGVhc2Ugbm90ZSwgdGhpcyBpcyBub3QgYW4gZXhoYXVz dGl2ZSBsaXN0LCBidXQgYSAyIG1pbnV0ZSBzY2FuIHRocm91Z2ggdGhlIGRvYy4NCg0KVGhhbmtz IQ0KDQpDYXJsb3MuDQoNCg0KPiBPbiBNYXkgMjQsIDIwMTcsIGF0IDI6MzMgQU0sIG4ubGV5bWFu bkB0ZWxla29tLmRlIDxOLkxleW1hbm5AdGVsZWtvbS5kZT4gd3JvdGU6DQo+IA0KPiBEZWFyIFdv cmtpbmcgR3JvdXAsDQo+ICANCj4gVGhlIGF1dGhvcnMgaGF2ZSB1cGRhdGVkIGRyYWZ0LWlldGYt bXBscy1iZmQtZGlyZWN0ZWQgYW5kIHRoaW5rIHRoYXQgdGhlIGRyYWZ0IGlzIHJlYWR5IGZvciBX R0xDLg0KPiBUaGVyZWZvcmUgdGhpcyBlLW1haWwgc3RhcnRzIGEgV0cgTEMgd2hpY2ggd2lsbCBl bmQgb24gdGhlIDd0aCBvZiBKdW5lLg0KPiAgICAgICAgICANCj4gUGxlYXNlIG5vdGUgdGhhdCBk cmFmdC1pZXRmLW1wbHMtYmZkLWRpcmVjdGVkIGRpZCBub3QgcGFzcyB0aGUNCj4gcHJldmlvdXMg d29ya2luZyBncm91cCBsYXN0IGNhbGwsIGJlY2F1c2Ugb2YgYW4gSVBSIGRpc2Nsb3N1cmU6DQo+ ICANCj4gICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yODkyLw0KPiAgDQo+IFRo ZSBhdXRob3JzIGhhdmUgdXBkYXRlZCB0aGUgZHJhZnQgYW5kIHRoZXkgYmVsaWV2ZSB0aGF0IHRo ZSBJUFIgaXMgbm8gbG9uZ2VyIGluIHNjb3BlLg0KPiBQbGVhc2Ugbm90aWZ5IHRoZSBsaXN0IGlm IHlvdSBzdGlsbCB0aGluayB0aGUgSVBSIGlzIGFuIGlzc3VlIGFuZCBwbGVhc2Ugc3RhdGUgaWYg eW91IHRoaW5rIGl0DQo+IGlzIE9LIHRvIGNvbnRpbnVlIHdpdGggdGhlIHB1YmxpY2F0aW9uIG9m IHRoaXMgZG9jdW1lbnQuDQo+ICANCj4gICBCZXN0IHJlZ2FyZHMNCj4gIA0KPiAgICAgTmljDQo+ ICANCj4gIA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBtcGxzIG1haWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQo= From nobody Wed May 24 12:11:20 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5286128CFF; Wed, 24 May 2017 12:11:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149565307077.8604.5322314944272057487@ietfa.amsl.com> Date: Wed, 24 May 2017 12:11:10 -0700 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-app-aware-tldp-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 19:11:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Application-aware Targeted LDP Authors : Santosh Esale Raveendra Torvi Luay Jalil Uma Chunduri Kamran Raza Filename : draft-ietf-mpls-app-aware-tldp-08.txt Pages : 17 Date : 2017-05-24 Abstract: Recent targeted LDP (tLDP) applications such as remote loop-free alternate (LFA) and BGP auto discovered pseudowire may automatically establish a tLDP session to any LSR in a network. The initiating LSR has information about the targeted applications to administratively control initiation of the session. However, the responding LSR has no such information to control acceptance of this session. This document defines a mechanism to advertise and negotiate Targeted Applications Capability (TAC) during LDP session initialization. As the responding LSR becomes aware of targeted applications, it may establish a limited number of tLDP sessions for certain applications. In addition, each targeted application is mapped to LDP Forwarding Equivalence Class (FEC) Elements to advertise only necessary LDP FEC- label bindings over the session. This document updates RFC 7473 for enabling advertisement of LDP FEC-label bindings over the session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-app-aware-tldp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-app-aware-tldp-08 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-app-aware-tldp-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-app-aware-tldp-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 24 13:10:17 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FE2127B52; Wed, 24 May 2017 13:10:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-mpls-tp-shared-ring-protection@ietf.org, Eric Gray , mpls-chairs@ietf.org, Eric.Gray@Ericsson.com, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149565660910.8641.739437988075507213.idtracker@ietfa.amsl.com> Date: Wed, 24 May 2017 13:10:09 -0700 Archived-At: Subject: [mpls] Spencer Dawkins' Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 20:10:09 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-mpls-tp-shared-ring-protection-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I want to thank the authors for a very readable draft. It was a pleasure to review, and that's a high bar for the subject. I have loads of questions, but my first set of questions is an expansion of Alvaro's comment that I think rises to the level of a Discuss. Please note that I'm asking questions, not proposing text changes, so I really do want to discuss it. ---------- my first set of questions In this text, Three typical ring protection mechanisms are described in this section: wrapping, short wrapping and steering. All nodes on the same ring MUST use the same protection mechanism. I would like to understand what happens if they aren't - and I'm asking, mostly as a way of encouraging guidance for operators in debugging cases where they're not all using the same mechanism. I'm not asking for a full mesh of possible misconfigurations, only for a sentence or two ("If they aren't all using the same protection mechanism, the following things may happen"). More broadly, I'd like to understand why wrapping and short wrapping are both defined. It seems like the only functional difference is that short wrapping doesn't give you as much latency. Is that right? 24 pages in, I see this: o In rings utilizing the wrapping protection, each node detects the failure or receives the RPS request as the destination node MUST perform the switch from/to the working ring tunnels to/from the protection ring tunnels if it has no higher priority active RPS request. o In rings utilizing the short wrapping protection, each node detects the failure or receives the RPS request as the destination node MUST perform the switch only from the working ring tunnels to the protection ring tunnels. so I'm pretty sure there are differences beyond what I was seeing, earlier in the document. And, of course, I'm not sure what the effect of choosing steering over wrapping/short wrapping would be, for my users, but that can wait until we talk about wrapping and short wrapping ... At a minimum, I'd like to see guidance for operators in choosing among the three protection mechanisms. Why would they choose any one of the three? I also note that this MUST seems to be repeated using different words in section 5.1, as All nodes in the same ring MUST use the same protection mechanism, Wrapping, steering or short-wrapping. If that's saying the same thing, one MUST is all you need. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ---------- all the other questions In this text, When the service LSP passes through the interconnected rings, the direction of the working ring tunnels used on both rings SHOULD be the same. For example, if the service LSP uses the clockwise working ring tunnel on Ring1, when the service LSP leaves Ring1 and enters Ring2, the working ring tunnel used on Ring2 SHOULD also follow the clockwise direction. I'm not understanding why this is a SHOULD, and not a MUST. If the direction of the working ring tunnels used on both rings is not the same, does this still work? If it still works, why does this matter? But, either way, you might usefully say something about why this isn't always the right thing to do, even if you just give one example. The point of SHOULD is that implementers make their own informed decisions, so providing information that will inform those decisions seems important. I wanted to call out Ring switches MUST be preempted by higher priority RPS requests. For example, consider a protection switch that is active due to a manual switch request on the given link, and another protection switch is required due to a failure on another link. Then an RPS request MUST be generated, the former protection switch MUST be dropped, and the latter protection switch established. MSRP mechanism SHOULD support multiple protection switches in the ring, resulting in the ring being segmented into two or more separate segments. This may happen when several RPS requests of the same priority exist in the ring due to multiple failures or external switch commands. as really good examples of the kind of text I think would help the places in this document ("For example", "This may happen when") where no examples are given. Thanks for providing those examples! Ouch. Do I understand from o Protection Switching Mode (M): This 2-bit field indicates the protection switching mode used by the sending node of the RPS message. This can be used to check that the ring nodes on the same ring use the same protection switching mechanism. The defined values of the M field are listed as below: +------------------+-----------------------------+ | Bits (MSB-LSB) | Protecton Switching Mode | +------------------+-----------------------------+ | 0 0 | Reserved | | 0 1 | Wrapping | | 1 0 | Short Wrapping | | 1 1 | Steering | +------------------+-----------------------------+ that you already have three protection mechanisms, and have only one possible codepoint to allocate for any future optimizations? Assuming that "0 0" can be unReserved ... Could you clarify what "anyway" means in this text? When multiple MS RPS requests exist at the same time addressing different links and there is no higher priority request on the ring, no switch SHOULD be executed and existing switches MUST be dropped. The nodes MUST signal, anyway, the MS RPS request code. I'm seeing that the commands like LP described in section 5.2.1.1 are used in the document before these (I'm serious) helpful and clear explanations appear. If it's possible to move section 5.2.1.1 up in the document, that would be great, but if it isn't possible, a forward pointer would be helpful to readers who don't already know what the command abbreviations mean. I'm really confused by this SHOULD: The PSC protocol [RFC6378] is designed for point-to-point LSPs, on which the protection switching can only be performed on one or both of the end points of the LSP. The RPS protocol is designed for ring tunnels, which consist of multiple ring nodes, and the failure could happen on any segment of the ring, thus RPS SHOULD be capable of identifying and handling the different failures on the ring, and coordinating the protection switching behavior of all the nodes on the ring. I suspect that's because it's not a 2119 SHOULD, but if people think it is, I wouldn't mind understanding why. Section 5.3, "RPS and PSC Comparison on Ring Topology" is really helpful, but it appears 43 pages in. Given that I'd expect people to be asking why they should implement a new protection switching protocol when they've already implemented PSC, I'd think this would be much more useful, early in the document. I'm somewhat confused about the code point allocation strategy in this text: The RPS Request Field is 8 bits, the allocated values are as follows: Value Description Reference ------- --------------------------- --------------- 0 No Request (NR) this document 1 Reverse Request (RR) this document 2 unassigned 3 Exercise (EXER) this document 4 unassigned 5 Wait-To-Restore (WTR) this document 6 Manual Switch (MS) this document 7-10 unassigned 11 Signal Fail (SF) this document 12 unassigned 13 Forced Switch (FS) this document 14 unassigned 15 Lockout of Protection (LP) this document 16-254 unassigned 255 Reserved My first question is, why the highest priority RPS value is 15, given that the field is 8 bits wide. If anyone ever needs to add a code point higher than the highest priority code point, will that work well? I can imagine code that says "if operation_priority is greater than highest_priority, it's an error", for example. I may have other questions depending on your answer, but let's start there. From nobody Wed May 24 13:31:24 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CDD129B2B; Wed, 24 May 2017 13:31:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-mpls-tp-aps-updates@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149565787534.8704.16535764503280127950.idtracker@ietfa.amsl.com> Date: Wed, 24 May 2017 13:31:15 -0700 Archived-At: Subject: [mpls] Warren Kumari's No Objection on draft-ietf-mpls-tp-aps-updates-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 20:31:16 -0000 Warren Kumari has entered the following ballot position for draft-ietf-mpls-tp-aps-updates-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-aps-updates/ There are no remarks associated with this position. From nobody Thu May 25 02:20:15 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEDF128D6F; Thu, 25 May 2017 02:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3QVXoxvOuwQ; Thu, 25 May 2017 02:20:12 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80FA129400; Thu, 25 May 2017 02:20:11 -0700 (PDT) Received: from [192.168.0.103] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 66B971801557; Thu, 25 May 2017 11:20:10 +0200 (CEST) To: "mpls@ietf.org" Cc: draft-ietf-mpls-rfc3107bis@ietf.org, "mpls-chairs@ietf.org" From: Loa Andersson Message-ID: <699158e5-ca4a-4e8b-7b85-7013ec2579e2@pi.nu> Date: Thu, 25 May 2017 11:20:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] implementation poll for draft-ietf-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 09:20:14 -0000 Working Group, We are preparing the publication request for draft-ietf-mpls-rfc3107bis, part of the preparation is the Shepherd Write-Up. One question for the Shepherd Write-Up is for existing and planned implementations. This mail starts an Implementation Poll for draft-ietf-mpls-rfc3107bis. If you are aware of existing implementations of draft-ietf-mpls- rfc3107bis, please disclose this on the mpls wg mailing list or directly to the wg chairs. /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu May 25 02:36:14 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E271201FA; Thu, 25 May 2017 02:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ms8NhTkWAv1l; Thu, 25 May 2017 02:36:11 -0700 (PDT) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 AE5AC12EA6A; Thu, 25 May 2017 02:36:10 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id g15so32011397wmc.2; Thu, 25 May 2017 02:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:references:to:cc:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=OAkvKCokLPEXiIKbSrqlOl2i7559zD/IV9KIZPKy9nw=; b=Mbs14JncRnenQggnDyNSU2aGi83Gg0rc9KG0QS7S03UsR+thH4nkk1DAduJUvADsCc IfvuUwo4GfaLx1lDRvhLB1vHvH3qkRFcoW64rIDwksk/FVBCO8m1lKsbY/QqkhuXd1Ng 0v9mCk2Tg+U/Gv/3iFxcnFII7e/QvX+ksB+lT+3BEYKPBCTNnpQ5JbzbsGQve3iM94MT trZEl4dhFeiLtKhudn0WkbgNi34zXq4bG5102K93BLIdkDElkTjnHTKGSSeiGbKUoQ+u t9rL8nRoV3ILF4c5lqT1lRIZAWkk9e7wcQBdDmGsdhj6thUqBtRRZw9m+0G+9q8+74iA MikA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=OAkvKCokLPEXiIKbSrqlOl2i7559zD/IV9KIZPKy9nw=; b=pm07igrI5YdpyqIEwZhYUAP/xg/ABo35Yr39g8OFgVTfDxkrf7OcP1GGOpksWs34K9 kWgo0PO7oVgMzedpI2HtxHM8dvdwNqg+DJBAPQfyo9Gn8Td8ZPyKNBIa3pnTXMFuJpbW 5NPUIUCr3wplTfkBh6j7ksjTG3+06bKoDbmq8a4gM+VC8PrlXIeYBIyFW0cYNAzsbFKs s7l3O0RTfXstXn432QoM41FIO7y2TkwmeAh91U/jM9111aH6a+Reza62OmciqbRd7j9Q y/VxGDPZciecYGXl5JlD5YnkQ7HfFNehUDwWQYNXxsNeOh6y8lIIvDSsZgToTVUyoIO4 th8w== X-Gm-Message-State: AODbwcB1vdU+OajwHMdHjf5SvPr4z/T9g/5qa4ghkLLHI++gl45/iSb2 rqpz/H0izteRyQ== X-Received: by 10.80.169.42 with SMTP id l39mr29330893edc.105.1495704969197; Thu, 25 May 2017 02:36:09 -0700 (PDT) Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id t55sm2408745edd.23.2017.05.25.02.36.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 02:36:08 -0700 (PDT) Reply-To: huubatwork@gmail.com References: <149560689201.28401.2592268750185030462.idtracker@ietfa.amsl.com> To: Eric Rescorla , The IESG Cc: draft-ietf-mpls-tp-shared-ring-protection@ietf.org, Eric Gray , mpls-chairs@ietf.org, mpls@ietf.org From: Huub van Helvoort Message-ID: <71a35d11-69b4-6f77-350d-92b99f7f1fda@gmail.com> Date: Thu, 25 May 2017 11:36:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <149560689201.28401.2592268750185030462.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] Eric Rescorla's Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 09:36:13 -0000 Hello Eric, Thank you for reviewing the security aspects of our draft. Please see my response in-line [Huub] > Eric Rescorla has entered the following ballot position for > draft-ietf-mpls-tp-shared-ring-protection-05: Discuss > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > The security considerations of this document seem unacceptably > incomplete, as they basically just point to other documents. > > The RPS protocol defined in this document is carried in the G-ACh > [RFC5586], which is a generalization of the Associated Channel > defined in [RFC4385]. The security considerations specified in > these > documents apply to the proposed RPS mechanism. > > The security considerations of those documents don't seem that great > either. However, I believe that they miss a new security issue raised > by the mechanism in this draft, which is that a member of the ring > appears to be able to forge reports of errors at other parts of the > ring. Specifically, S 5.1.3.3 says: > > When a node is in a pass-through state, it MUST transfer the > received > RPS Request in the same direction. > > When a node is in a pass-through state, it MUST enable the traffic > flow on protection ring tunnels in both directions. > > This seems not to involve any filtering, which suggests that node B > can send a forged SF from C->D and from D->C, which at least > potentially > temporarily breaks the link there, causing traffic diversion. > > More generally, this system assumes that every node trusts every > other node completely. That must at least be stated. > > Incidentally, the text above appears to contain a bug in that it > doesn't talk about processing incoming RPS requests intended for > the receiving node, but I may just have missed the section where > it says that. [Huub] your discuss is applicable to any OAM protocol where an intermediate node can forge false OAM messages and affect traffic. Regarding this draft, a forged SF may cause a protection switch if the protocol does not detect a failure of protocol caused by a wrong sequence or illegal combination of received RPS messages from the clock-wise and the anti-clock-wise direction in the ring. The protection switch itself will not cause a loss of traffic. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > S 4.1.1. > protect these LSPs that traverse the ring, a clockwise working ring > tunnel (RcW_D) via E->F->A->B->C->D, and its anticlockwise > protection > ring tunnel (RaP_D) via D->C->B->A->F->E->D are established, Also, > an > anti-clockwise working ring tunnel (RaW_D) via C->B->A->F->E->D, and > its clockwise protection ring tunnel (RcP_D) via D->E->F->A->B->C->D > > Why does the protection tunnel include D on both ends whereas the > working > tunnel does not? [Huub] the working ring tunnel should not be a closed loop. the protection ring tunnel is closed until a protection switch is activated, at that time the protection ring tunnel is opened at the appropriate location to transport the protected traffic. > S 4.2. > packets are periodically exchanged between each pair of MEPs to > monitor the link health. Three consecutive lost CC packets will be > interpreted as a link failure. > > Is this a normative statement (i.e., does it need a MUST). [Huub] he MUST is a requirement for the SF detection described in RFC6371 and ITU-T G.806 . > S 4.3.2.1. > Why do you ever not use short wrapping? [Huub] wrapping is a mechanism that can be used in case an LSP is dropped in several nodes (p-2-mp application). Short wrapping can be used only in p-2-p application. > S 5.1.4.1 > A node MUST revert from pass-through state to the idle state when it > detects NR codes incoming from both directions. Both directions > revert simultaneously from the pass-through state to the idle state. > > incoming within what time frame? [Huub] this time depends on the propagation delay in the ring and the RPS processing time in each node. Because of the 50 ms switching objective a 100 ms timer could be used. Best regards, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From nobody Thu May 25 03:02:14 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D549312EA5A; Thu, 25 May 2017 03:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbPGDjx0BRO8; Thu, 25 May 2017 03:02:10 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::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 2514A12E058; Thu, 25 May 2017 03:02:10 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id g15so32128206wmc.2; Thu, 25 May 2017 03:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:references:to:cc:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=AwXes+QMTEcQv193gj990tOISmi7fYJmsRnp8UXkZGA=; b=XkNY+bd7R7m3QDpuISUBAaXd/UQowUwjEAO26NzCItqnq70/RLJ2uoIAIGqvsXZ6kg Qh6eBIj1acpkXCqiBGMC/Wqb6qr96EeHL2KdrodEtViPTc6aMKa/p9w3k3PcLuMpgI8r rLDtubHkA80C+fUUhu+/dH/AbUs8jrqeEek76XEEHfinnvGizyvyTviQmsSiHwQKS7tN I2ARO5siDDMV8vg/5ZTNu0I8sH607aEOSIrHbduF6iwExuJhauX/Es8H4HUrP67Wx8Xz 6R1gKRvK2SW2gNe3FntouhrWdr5M2oZmGnbh4D61NwwPfbaJQ8YyALbcgiD7O1karipL PlVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=AwXes+QMTEcQv193gj990tOISmi7fYJmsRnp8UXkZGA=; b=eYJngeF25wTzLiFBgIBpj7nvCYaaxnBCLeNv3dZ3PHtl+tdMbwF7fJ0Crp7if3YC06 MqHhWpV7dI1dPNCGuO/zuFGFrif17tvUJrcFtClgVAIpUayiAht4JrIUWpsp+Vp41/Mi EXBMbNVSCanzS3Cd3NpV/iBLGvfVQjZxMuNGYM0H6Uw+2Sm4z4dwJ9j+fvzEm0HmHEm0 WQJzuh25cKvoyx3f7j7pWp9seXWlxBhyZ4csbyitc9U4a9OBpTED51rqfke6FmoaC0fB B9M3+Oz9VqQmAir7mcQuvTjxfqE/f4rXHPfiP7D+KEcltfLfK0nmKU+YxOVz5db7nBJU SQYA== X-Gm-Message-State: AODbwcBRzPcnF1QrcT1IV7WZf671jpely+tdgepVgDV4VWjmkoqGtiu5 vlSKVhDU5XqlRg== X-Received: by 10.80.181.99 with SMTP id z32mr27721420edd.6.1495706528488; Thu, 25 May 2017 03:02:08 -0700 (PDT) Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id b9sm2584114eda.46.2017.05.25.03.02.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 03:02:07 -0700 (PDT) Reply-To: huubatwork@gmail.com References: <149565660910.8641.739437988075507213.idtracker@ietfa.amsl.com> To: Spencer Dawkins , The IESG Cc: draft-ietf-mpls-tp-shared-ring-protection@ietf.org, Eric Gray , mpls-chairs@ietf.org, mpls@ietf.org From: Huub van Helvoort Message-ID: Date: Thu, 25 May 2017 12:02:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <149565660910.8641.739437988075507213.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] Spencer Dawkins' Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 10:02:13 -0000 Hello Spencer, Thank you for your review of our draft. Please find my response in-line [Huub] > Spencer Dawkins has entered the following ballot position for > draft-ietf-mpls-tp-shared-ring-protection-05: Discuss > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I want to thank the authors for a very readable draft. It was a pleasure > to review, and that's a high bar for the subject. [Huub] thank you! > I have loads of questions, but my first set of questions is an expansion > of Alvaro's comment that I think rises to the level of a Discuss. Please > note that I'm asking questions, not proposing text changes, so I really > do want to discuss it. [Huub] OK, understood. > ---------- my first set of questions > > In this text, > > Three typical ring protection mechanisms are described in this > section: wrapping, short wrapping and steering. All nodes on the > same ring MUST use the same protection mechanism. > > I would like to understand what happens if they aren't - and I'm asking, > mostly as a way of encouraging guidance for operators in debugging cases > where they're not all using the same mechanism. I'm not asking for a full > mesh of possible misconfigurations, only for a sentence or two ("If they > aren't all using the same protection mechanism, the following things may > happen"). [Huub] if the MRPS protocol in any node detects RPS message with a mode that was not provisioned in that node a failure of protocol will be reported, and the protection mechanism will not be activated. > More broadly, I'd like to understand why wrapping and short wrapping are > both defined. It seems like the only functional difference is that short > wrapping doesn't give you as much latency. Is that right? > > 24 pages in, I see this: > > o In rings utilizing the wrapping protection, each node detects the > failure or receives the RPS request as the destination node MUST > perform the switch from/to the working ring tunnels to/from the > protection ring tunnels if it has no higher priority active RPS > request. > > o In rings utilizing the short wrapping protection, each node > detects the failure or receives the RPS request as the > destination > node MUST perform the switch only from the working ring tunnels > to > the protection ring tunnels. > > so I'm pretty sure there are differences beyond what I was seeing, > earlier in the document. [Huub] wrapping is a mechanism that can be used in case an LSP is dropped in several nodes (p-2-mp application). In this case the traffic will still have to reach every node in the ring. Short wrapping can be used only in p-2-p application. Now the traffic can be dropped at the moment the egress node is reached. Steering has the least additional propagation delay, but during a short time the traffic may be duplicated, which may not be desirable is some applications. > And, of course, I'm not sure what the effect of choosing steering over > wrapping/short wrapping would be, for my users, but that can wait until > we talk about wrapping and short wrapping ... > > At a minimum, I'd like to see guidance for operators in choosing among > the three protection mechanisms. Why would they choose any one of the > three? [Huub] more explanatory text can be added, it could be in the introduction proposed by Alvaro. > I also note that this MUST seems to be repeated using different words in > section 5.1, as > > All nodes in the same ring MUST use the same protection mechanism, > Wrapping, steering or short-wrapping. > > If that's saying the same thing, one MUST is all you need. [Huub] OK, point taken. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ---------- all the other questions [Huub] I will answer your questions later (I am currently on holiday and risk a divorce if I don't stop now :-( ) Best regards, Huub. > > In this text, > > When the service LSP passes through the interconnected rings, the > direction of the working ring tunnels used on both rings SHOULD be > the same. For example, if the service LSP uses the clockwise > working > ring tunnel on Ring1, when the service LSP leaves Ring1 and enters > Ring2, the working ring tunnel used on Ring2 SHOULD also follow the > clockwise direction. > > I'm not understanding why this is a SHOULD, and not a MUST. If the > direction of the working ring tunnels used on both rings is not the same, > does this still work? > > If it still works, why does this matter? But, either way, you might > usefully say something about why this isn't always the right thing to do, > even if you just give one example. The point of SHOULD is that > implementers make their own informed decisions, so providing information > that will inform those decisions seems important. > > I wanted to call out > > Ring switches MUST be preempted by higher priority RPS requests. > For > example, consider a protection switch that is active due to a manual > switch request on the given link, and another protection switch is > required due to a failure on another link. Then an RPS request MUST > be generated, the former protection switch MUST be dropped, and the > latter protection switch established. > > MSRP mechanism SHOULD support multiple protection switches in the > ring, resulting in the ring being segmented into two or more > separate > segments. This may happen when several RPS requests of the same > priority exist in the ring due to multiple failures or external > switch commands. > > as really good examples of the kind of text I think would help the places > in this document ("For example", "This may happen when") where no > examples are given. Thanks for providing those examples! > > Ouch. Do I understand from > > o Protection Switching Mode (M): This 2-bit field indicates the > protection switching mode used by the sending node of the RPS > message. This can be used to check that the ring nodes on the > same ring use the same protection switching mechanism. The > defined values of the M field are listed as below: > > +------------------+-----------------------------+ > | Bits (MSB-LSB) | Protecton Switching Mode | > +------------------+-----------------------------+ > | 0 0 | Reserved | > | 0 1 | Wrapping | > | 1 0 | Short Wrapping | > | 1 1 | Steering | > +------------------+-----------------------------+ > > that you already have three protection mechanisms, and have only one > possible codepoint to allocate for any future optimizations? Assuming > that "0 0" can be unReserved ... > > Could you clarify what "anyway" means in this text? > > When multiple MS RPS requests exist at the same time addressing > different links and there is no higher priority request on the ring, > no switch SHOULD be executed and existing switches MUST be dropped. > The nodes MUST signal, anyway, the MS RPS request code. > > I'm seeing that the commands like LP described in section 5.2.1.1 are > used in the document before these (I'm serious) helpful and clear > explanations appear. If it's possible to move section 5.2.1.1 up in the > document, that would be great, but if it isn't possible, a forward > pointer would be helpful to readers who don't already know what the > command abbreviations mean. > > I'm really confused by this SHOULD: > > The PSC protocol [RFC6378] is designed for point-to-point LSPs, on > which the protection switching can only be performed on one or both > of the end points of the LSP. The RPS protocol is designed for ring > tunnels, which consist of multiple ring nodes, and the failure could > happen on any segment of the ring, thus RPS SHOULD be capable of > identifying and handling the different failures on the ring, and > coordinating the protection switching behavior of all the nodes on > the ring. > > I suspect that's because it's not a 2119 SHOULD, but if people think it > is, I wouldn't mind understanding why. > > Section 5.3, "RPS and PSC Comparison on Ring Topology" is really helpful, > but it appears 43 pages in. Given that I'd expect people to be asking why > they should implement a new protection switching protocol when they've > already implemented PSC, I'd think this would be much more useful, early > in the document. > > I'm somewhat confused about the code point allocation strategy in this > text: > > The RPS Request Field is 8 bits, the allocated values are as > follows: > > Value Description Reference > ------- --------------------------- --------------- > 0 No Request (NR) this document > 1 Reverse Request (RR) this document > 2 unassigned > 3 Exercise (EXER) this document > 4 unassigned > 5 Wait-To-Restore (WTR) this document > 6 Manual Switch (MS) this document > 7-10 unassigned > 11 Signal Fail (SF) this document > 12 unassigned > 13 Forced Switch (FS) this document > 14 unassigned > 15 Lockout of Protection (LP) this document > 16-254 unassigned > 255 Reserved > > My first question is, why the highest priority RPS value is 15, given > that the field is 8 bits wide. If anyone ever needs to add a code point > higher than the highest priority code point, will that work well? I can > imagine code that says "if operation_priority is greater than > highest_priority, it's an error", for example. > > I may have other questions depending on your answer, but let's start > there. > > -- ================================================================ Always remember that you are unique...just like everyone else... From nobody Thu May 25 03:05:22 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEF612EAA4 for ; Thu, 25 May 2017 03:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1c6mmik3qSqT for ; Thu, 25 May 2017 03:05:15 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E4ED12EA95 for ; Thu, 25 May 2017 03:05:14 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id 187so45054584ybg.0 for ; Thu, 25 May 2017 03:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fBarIjs3qT/dz4n7KbUv5pF5+Mmizw62ZsgjsY5WFXY=; b=0Co5yMGgIHjBUCa1DYU4LuwY5ypLDRGrD4JoyuUT/HwqRvZj2bmR624unbmsilj2QL 3M9f83WWchzrYRAI+rDZZS8hlfpXnbFX8pgIifjkWWZfEXqNFURLIhF9XEMJLJ55MoWP DgAWfFw2wnpAR+Mez9XtD3M+72I2Jd+gGEvwVvR43mOKm8m6y2rQnT4gMYGerXCkjFfV O69iNqIFh79IT0jI/j3GnXFOBTLKy56a/dHtGtJ8DOdadeYg+hb10d8BpUp4G5gdz9T4 LGMuGYkBjz+E+1Xsfbgm1rHVBCKGO7jZ9aOhUiUywRf0caWPMB8QbQAxilIr+7negtQm CmKg== 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=fBarIjs3qT/dz4n7KbUv5pF5+Mmizw62ZsgjsY5WFXY=; b=VvOUVJVLrutpTBxFqeW3S/MF7gErwdnPUzL5FDMkX3fSRRz2kTWmXx4hkKKWCK5wDG N2S7M4LArgY0WJryx65z74Bh3eKHiKntal8AlzpGW+LW4AzTVFowRdF4dcT0kXFENOsl Me8/adas41IXoMcBv7mnsDJlYufbu0WLD7ihlQ7+Zi+bmQTspPjuDqe/dQg8N/uxGEHz jTQf4/Ly8vcxyYez+pf/3DtM7qfLVG45YuCWkOrPBKYdAivEjVezKItEmGHzcafmwFgZ pE0bgOCy/2pXvWYL2xjVB/c6l+fKvOQ5JnpX4PRq3YUdnNdx2GhARLjD5hOd7/ACcVQx vi8A== X-Gm-Message-State: AODbwcAUgxsQb9AgiqpOr+eVIKAQFhxETnUZG7Hf970OJk33JMC1jM8P llhkomE2rOAW2fKvZEvXBi2zZHiDRLnn X-Received: by 10.37.173.21 with SMTP id y21mr32197698ybi.52.1495706713123; Thu, 25 May 2017 03:05:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Thu, 25 May 2017 03:04:32 -0700 (PDT) In-Reply-To: <71a35d11-69b4-6f77-350d-92b99f7f1fda@gmail.com> References: <149560689201.28401.2592268750185030462.idtracker@ietfa.amsl.com> <71a35d11-69b4-6f77-350d-92b99f7f1fda@gmail.com> From: Eric Rescorla Date: Thu, 25 May 2017 18:04:32 +0800 Message-ID: To: huubatwork@gmail.com Cc: The IESG , draft-ietf-mpls-tp-shared-ring-protection@ietf.org, Eric Gray , mpls-chairs@ietf.org, mpls@ietf.org Content-Type: multipart/alternative; boundary="f403045db94e5309420550565bc7" Archived-At: Subject: Re: [mpls] Eric Rescorla's Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 10:05:18 -0000 --f403045db94e5309420550565bc7 Content-Type: text/plain; charset="UTF-8" On Thu, May 25, 2017 at 5:36 PM, Huub van Helvoort wrote: > Hello Eric, > > Thank you for reviewing the security aspects of our draft. > > Please see my response in-line [Huub] > > Eric Rescorla has entered the following ballot position for >> draft-ietf-mpls-tp-shared-ring-protection-05: Discuss >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-r >> ing-protection/ >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> The security considerations of this document seem unacceptably >> incomplete, as they basically just point to other documents. >> >> The RPS protocol defined in this document is carried in the G-ACh >> [RFC5586], which is a generalization of the Associated Channel >> defined in [RFC4385]. The security considerations specified in >> these >> documents apply to the proposed RPS mechanism. >> >> The security considerations of those documents don't seem that great >> either. However, I believe that they miss a new security issue raised >> by the mechanism in this draft, which is that a member of the ring >> appears to be able to forge reports of errors at other parts of the >> ring. Specifically, S 5.1.3.3 says: >> >> When a node is in a pass-through state, it MUST transfer the >> received >> RPS Request in the same direction. >> >> When a node is in a pass-through state, it MUST enable the traffic >> flow on protection ring tunnels in both directions. >> >> This seems not to involve any filtering, which suggests that node B >> can send a forged SF from C->D and from D->C, which at least >> potentially >> temporarily breaks the link there, causing traffic diversion. >> >> More generally, this system assumes that every node trusts every >> other node completely. That must at least be stated. >> >> Incidentally, the text above appears to contain a bug in that it >> doesn't talk about processing incoming RPS requests intended for >> the receiving node, but I may just have missed the section where >> it says that. >> > [Huub] your discuss is applicable to any OAM protocol where an > intermediate node can forge false OAM messages and affect traffic. > OK, but it's the job of the Security Considerations section to document this stuff. I'd also ask why you don't specify filtering, which would prevent at least this form of attack. Regarding this draft, a forged SF may cause a protection switch if > the protocol does not detect a failure of protocol caused by a wrong > sequence or illegal combination of received RPS messages from the > clock-wise and the anti-clock-wise direction in the ring. > The protection switch itself will not cause a loss of traffic. Loss of traffic is not the only kind of attack. ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> S 4.1.1. >> protect these LSPs that traverse the ring, a clockwise working ring >> tunnel (RcW_D) via E->F->A->B->C->D, and its anticlockwise >> protection >> ring tunnel (RaP_D) via D->C->B->A->F->E->D are established, Also, >> an >> anti-clockwise working ring tunnel (RaW_D) via C->B->A->F->E->D, and >> its clockwise protection ring tunnel (RcP_D) via D->E->F->A->B->C->D >> >> Why does the protection tunnel include D on both ends whereas the >> working >> tunnel does not? >> > > [Huub] the working ring tunnel should not be a closed loop. the > protection ring tunnel is closed until a protection switch is activated, > at that time the protection ring tunnel is opened at the appropriate > location to transport the protected traffic. Can you point me to the section of the document where I can read more about this? > > > S 4.2. >> packets are periodically exchanged between each pair of MEPs to >> monitor the link health. Three consecutive lost CC packets will be >> interpreted as a link failure. >> >> Is this a normative statement (i.e., does it need a MUST). >> > > [Huub] he MUST is a requirement for the SF detection described in RFC6371 > and ITU-T G.806 . OK, so my question is whether you need to add a MUST here. S 5.1.4.1 >> A node MUST revert from pass-through state to the idle state when it >> detects NR codes incoming from both directions. Both directions >> revert simultaneously from the pass-through state to the idle state. >> >> incoming within what time frame? >> > > [Huub] this time depends on the propagation delay in the ring and the > RPS processing time in each node. > Because of the 50 ms switching objective a 100 ms timer could be used. > It seems like the document should specify this. -Ekr > > Best regards, Huub. > > > -- > ================================================================ > Always remember that you are unique...just like everyone else... > > --f403045db94e5309420550565bc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 25, 2017 at 5:36 PM, Huub van Helvoort &l= t;huubatwork@gmai= l.com> wrote:
Hello Eric,
Thank you for reviewing the security aspects of our draft.

Please see my response in-line [Huub]

Eric Rescorla has entered the following ballot position for
draft-ietf-mpls-tp-shared-ring-protection-05: Discuss

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.= org/doc/draft-ietf-mpls-tp-shared-ring-protection/

-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

The security considerations of this document seem unacceptably
incomplete, as they basically just point to other documents.

=C2=A0 =C2=A0 The RPS protocol defined in this document is carried in the G= -ACh
=C2=A0 =C2=A0 [RFC5586], which is a generalization of the Associated Channe= l
=C2=A0 =C2=A0 defined in [RFC4385].=C2=A0 The security considerations speci= fied in
these
=C2=A0 =C2=A0 documents apply to the proposed RPS mechanism.

The security considerations of those documents don't seem that great either. However, I believe that they miss a new security issue raised
by the mechanism in this draft, which is that a member of the ring
appears to be able to forge reports of errors at other parts of the
ring. Specifically, S 5.1.3.3 says:

=C2=A0 =C2=A0 When a node is in a pass-through state, it MUST transfer the<= br> received
=C2=A0 =C2=A0 RPS Request in the same direction.

=C2=A0 =C2=A0 When a node is in a pass-through state, it MUST enable the tr= affic
=C2=A0 =C2=A0 flow on protection ring tunnels in both directions.

This seems not to involve any filtering, which suggests that node B
can send a forged SF from C->D and from D->C, which at least
potentially
temporarily breaks the link there, causing traffic diversion.

More generally, this system assumes that every node trusts every
other node completely. That must at least be stated.

Incidentally, the text above appears to contain a bug in that it
doesn't talk about processing incoming RPS requests intended for
the receiving node, but I may just have missed the section where
it says that.
[Huub] your discuss is applicable to any OAM protocol where an
intermediate node can forge false OAM messages and affect traffic.

OK, but it's the job of the Security Consid= erations section to document
this stuff. I'd also ask why you= don't specify filtering, which would
prevent at least this f= orm of attack.


Regarding this draft, a forged SF may cause a protection switch if
the protocol does not detect a failure of protocol caused by a wrong
sequence or illegal combination of received RPS messages from the
clock-wise and the anti-clock-wise direction in the ring.
The protection switch itself will not cause a loss of traffic.
=

Loss of traffic is not the only kind of attack.


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

S 4.1.1.
=C2=A0 =C2=A0 protect these LSPs that traverse the ring, a clockwise workin= g ring
=C2=A0 =C2=A0 tunnel (RcW_D) via E->F->A->B->C->D, and its a= nticlockwise
protection
=C2=A0 =C2=A0 ring tunnel (RaP_D) via D->C->B->A->F->E->D= are established, Also,
an
=C2=A0 =C2=A0 anti-clockwise working ring tunnel (RaW_D) via C->B->A-= >F->E->D, and
=C2=A0 =C2=A0 its clockwise protection ring tunnel (RcP_D) via D->E->= F->A->B->C->D

Why does the protection tunnel include D on both ends whereas the
working
tunnel does not?

 [Huub] the working ring tunnel should not be a closed loop. the
protection ring tunnel is closed until a protection switch is activated, at that time the protection ring tunnel is opened at the appropriate
location to transport the protected traffic.

Can you point me to the section of the document where I can read more
about this?=C2=A0


S 4.2.
=C2=A0 =C2=A0 packets are periodically exchanged between each pair of MEPs = to
=C2=A0 =C2=A0 monitor the link health.=C2=A0 Three consecutive lost CC pack= ets will be
=C2=A0 =C2=A0 interpreted as a link failure.

Is this a normative statement (i.e., does it need a MUST).

 [Huub] he MUST is a requirement for the SF detection described in RFC6371 and ITU-T G.806 .

OK, so my question is whe= ther you need to add a MUST here.


S 5.1.4.1
=C2=A0 =C2=A0 A node MUST revert from pass-through state to the idle state = when it
=C2=A0 =C2=A0 detects NR codes incoming from both directions.=C2=A0 Both di= rections
=C2=A0 =C2=A0 revert simultaneously from the pass-through state to the idle= state.

incoming within what time frame?

 [Huub] this time depends on the propagation delay in the ring and the
RPS processing time in each node.
Because of the 50 ms switching objective a 100 ms timer could be used.
<= /blockquote>

It seems like the document should specify t= his.

-Ekr
=C2=A0

Best regards, Huub.


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Always remember that you are unique...just like everyone else...


--f403045db94e5309420550565bc7-- From nobody Thu May 25 05:58:53 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F32129535; Thu, 25 May 2017 05:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9PM1va4ZCqH; Thu, 25 May 2017 05:58:41 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (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 7EC4E12944A; Thu, 25 May 2017 05:58:41 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id 187so45918378ybg.0; Thu, 25 May 2017 05:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=639QTUXSMTYY79Dzswz5Emahyug3FOxmHKU3VIb8y7U=; b=gpeUmY/EJXa4mynQVYFYmrzR0XcwNJGSNZZsOzixki7IAm1Vi7n4lrLm+nEVzqJlCW AurQsnN93F7f96QPweDx36hdg8oW7wnbEPQcIlkguPByuiZth88k9IpAqW7cR+KmWu3M 7fuC/l/fhXVmvtP2SHv9Qt4tfapGA2JBVCH3R9RPHsLHTfOz2gDxfJcBKkUuIx1Wnu/P 8vzT4xhJcJ8dfm0fQ+TdVYQxoD5md0lCrKpsASDmANHgAxW1DgxA7zH8+ixM/eyzBf9l hSc/lW+lvgE6y+hgNyu8baKjzSwFvmvHHi8Y1SDtxHw5iULvxFxsIU32Qk6TcXjr78rB TpCw== 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=639QTUXSMTYY79Dzswz5Emahyug3FOxmHKU3VIb8y7U=; b=hBiwZcOoV2mH0Lo1huSbilzypQpAlU2zS31VqLYRVqSXEn2dXhNeGnpTdm0tHetbpZ MzQx/ga74H9/U9VUGCC+TAec33JQVCW6LcBJx2ksRi7Fghrw2deZwo0GMQDNmjtuD+dh AAcjYXI0nYgq8xr5ucttYcX2uedyPjEk6ZseNMxZjzXACqtbh3q+MkYRil15VTCJtQNr Xjd+DEPqGN+oFV43p7kaSD8XsNh9+la0cxx/9+WpKgnoEMj8F5f7Zmf0QcktqpgFMKeq 0I6IE6kM/Tv8kxF/ZdpLhVfg6Vdl4tvE11Zr/gu3mNeRKSs3lWP2WdvFVcui1HRLpqn8 0BiQ== X-Gm-Message-State: AODbwcBr8N1AKbotS7Nd0jJV8XXdCXNF2atUgtQDvdu11TC7qN6X/KLx pmdIFB3VPuR7CLQ56b4IugwgbAB/FA== X-Received: by 10.37.31.195 with SMTP id f186mr32016177ybf.25.1495717120685; Thu, 25 May 2017 05:58:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.163.130 with HTTP; Thu, 25 May 2017 05:58:40 -0700 (PDT) In-Reply-To: References: <149565660910.8641.739437988075507213.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Thu, 25 May 2017 07:58:40 -0500 Message-ID: To: huubatwork@gmail.com Cc: The IESG , draft-ietf-mpls-tp-shared-ring-protection@ietf.org, Eric Gray , "mpls-chairs@ietf.org" , "mpls@ietf.org" Content-Type: multipart/alternative; boundary="001a1143e3bea9d3aa055058c73c" Archived-At: Subject: Re: [mpls] Spencer Dawkins' Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 12:58:45 -0000 --001a1143e3bea9d3aa055058c73c Content-Type: text/plain; charset="UTF-8" To everyone else except Huub, because he shouldn't see this e-mail before the telechat anyway, being on vacation :D On Thu, May 25, 2017 at 5:02 AM, Huub van Helvoort wrote: > Hello Spencer, > > Thank you for your review of our draft. > Please find my response in-line [Huub] > > Spencer Dawkins has entered the following ballot position for >> draft-ietf-mpls-tp-shared-ring-protection-05: Discuss >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-r >> ing-protection/ >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I want to thank the authors for a very readable draft. It was a pleasure >> to review, and that's a high bar for the subject. >> > > [Huub] thank you! > > I have loads of questions, but my first set of questions is an expansion >> of Alvaro's comment that I think rises to the level of a Discuss. Please >> note that I'm asking questions, not proposing text changes, so I really >> do want to discuss it. >> > > [Huub] OK, understood. > > ---------- my first set of questions >> >> In this text, >> >> Three typical ring protection mechanisms are described in this >> section: wrapping, short wrapping and steering. All nodes on the >> same ring MUST use the same protection mechanism. >> >> I would like to understand what happens if they aren't - and I'm asking, >> mostly as a way of encouraging guidance for operators in debugging cases >> where they're not all using the same mechanism. I'm not asking for a full >> mesh of possible misconfigurations, only for a sentence or two ("If they >> aren't all using the same protection mechanism, the following things may >> happen"). >> > > [Huub] if the MRPS protocol in any node detects RPS message with a > mode that was not provisioned in that node a failure of protocol will > be reported, and the protection mechanism will not be activated. This sentence, alone, would be enough to answer this part of my Discuss, if it were in the document. More broadly, I'd like to understand why wrapping and short wrapping are >> both defined. It seems like the only functional difference is that short >> wrapping doesn't give you as much latency. Is that right? >> >> 24 pages in, I see this: >> >> o In rings utilizing the wrapping protection, each node detects the >> failure or receives the RPS request as the destination node MUST >> perform the switch from/to the working ring tunnels to/from the >> protection ring tunnels if it has no higher priority active RPS >> request. >> >> o In rings utilizing the short wrapping protection, each node >> detects the failure or receives the RPS request as the >> destination >> node MUST perform the switch only from the working ring tunnels >> to >> the protection ring tunnels. >> >> so I'm pretty sure there are differences beyond what I was seeing, >> earlier in the document. >> > > [Huub] wrapping is a mechanism that can be used in case an LSP is dropped > in several nodes (p-2-mp application). In this case the traffic will still > have > to reach every node in the ring. > Short wrapping can be used only in p-2-p application. Now the traffic can > be dropped at the moment the egress node is reached. > Steering has the least additional propagation delay, but during a short > time > the traffic may be duplicated, which may not be desirable is some > applications. This explanation would be sufficient to answer this part of my Discuss, if it was in the document. It is somewhere between possible and likely that there's actually a reference that describes the mechanisms in more detail, so if you included something like "the functional differences between these protection mechanisms are described in [WhatEver]", that would be fine, instead. > > And, of course, I'm not sure what the effect of choosing steering over >> wrapping/short wrapping would be, for my users, but that can wait until >> we talk about wrapping and short wrapping ... >> >> At a minimum, I'd like to see guidance for operators in choosing among >> the three protection mechanisms. Why would they choose any one of the >> three? >> > > [Huub] more explanatory text can be added, it could be in the introduction > proposed by Alvaro. I only saw Alvaro saying that he also wanted operational guidance included, but it's very likely that whatever you do to answer Alvaro's Comment would answer this part of my DIscuss. We were complaining about the same thing, it's just that I was more concerned about it ;-) > > I also note that this MUST seems to be repeated using different words in >> section 5.1, as >> >> All nodes in the same ring MUST use the same protection mechanism, >> Wrapping, steering or short-wrapping. >> >> If that's saying the same thing, one MUST is all you need. >> > > [Huub] OK, point taken. Thanks. I wasn't sure whether it was saying the same thing in different words, or saying something different. This sounds like it's saying the same thing in different words, and can be safely deleted. So - from 10,000 meters up, it looks like we know how to clear my Discuss. Please let me know when you (get back from vacation and) submit the next version, and I'll clear. I look forward to chatting about my Comments, but we won't be Discussing them, only chatting. Spencer > > ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> ---------- all the other questions >> > > [Huub] I will answer your questions later > (I am currently on holiday and risk a divorce if I don't stop now :-( ) > > Best regards, Huub. > > > >> In this text, >> >> When the service LSP passes through the interconnected rings, the >> direction of the working ring tunnels used on both rings SHOULD be >> the same. For example, if the service LSP uses the clockwise >> working >> ring tunnel on Ring1, when the service LSP leaves Ring1 and enters >> Ring2, the working ring tunnel used on Ring2 SHOULD also follow the >> clockwise direction. >> >> I'm not understanding why this is a SHOULD, and not a MUST. If the >> direction of the working ring tunnels used on both rings is not the same, >> does this still work? >> >> If it still works, why does this matter? But, either way, you might >> usefully say something about why this isn't always the right thing to do, >> even if you just give one example. The point of SHOULD is that >> implementers make their own informed decisions, so providing information >> that will inform those decisions seems important. >> >> I wanted to call out >> >> Ring switches MUST be preempted by higher priority RPS requests. >> For >> example, consider a protection switch that is active due to a manual >> switch request on the given link, and another protection switch is >> required due to a failure on another link. Then an RPS request MUST >> be generated, the former protection switch MUST be dropped, and the >> latter protection switch established. >> >> MSRP mechanism SHOULD support multiple protection switches in the >> ring, resulting in the ring being segmented into two or more >> separate >> segments. This may happen when several RPS requests of the same >> priority exist in the ring due to multiple failures or external >> switch commands. >> >> as really good examples of the kind of text I think would help the places >> in this document ("For example", "This may happen when") where no >> examples are given. Thanks for providing those examples! >> >> Ouch. Do I understand from >> >> o Protection Switching Mode (M): This 2-bit field indicates the >> protection switching mode used by the sending node of the RPS >> message. This can be used to check that the ring nodes on the >> same ring use the same protection switching mechanism. The >> defined values of the M field are listed as below: >> >> +------------------+-----------------------------+ >> | Bits (MSB-LSB) | Protecton Switching Mode | >> +------------------+-----------------------------+ >> | 0 0 | Reserved | >> | 0 1 | Wrapping | >> | 1 0 | Short Wrapping | >> | 1 1 | Steering | >> +------------------+-----------------------------+ >> >> that you already have three protection mechanisms, and have only one >> possible codepoint to allocate for any future optimizations? Assuming >> that "0 0" can be unReserved ... >> >> Could you clarify what "anyway" means in this text? >> >> When multiple MS RPS requests exist at the same time addressing >> different links and there is no higher priority request on the ring, >> no switch SHOULD be executed and existing switches MUST be dropped. >> The nodes MUST signal, anyway, the MS RPS request code. >> >> I'm seeing that the commands like LP described in section 5.2.1.1 are >> used in the document before these (I'm serious) helpful and clear >> explanations appear. If it's possible to move section 5.2.1.1 up in the >> document, that would be great, but if it isn't possible, a forward >> pointer would be helpful to readers who don't already know what the >> command abbreviations mean. >> >> I'm really confused by this SHOULD: >> >> The PSC protocol [RFC6378] is designed for point-to-point LSPs, on >> which the protection switching can only be performed on one or both >> of the end points of the LSP. The RPS protocol is designed for ring >> tunnels, which consist of multiple ring nodes, and the failure could >> happen on any segment of the ring, thus RPS SHOULD be capable of >> identifying and handling the different failures on the ring, and >> coordinating the protection switching behavior of all the nodes on >> the ring. >> >> I suspect that's because it's not a 2119 SHOULD, but if people think it >> is, I wouldn't mind understanding why. >> >> Section 5.3, "RPS and PSC Comparison on Ring Topology" is really helpful, >> but it appears 43 pages in. Given that I'd expect people to be asking why >> they should implement a new protection switching protocol when they've >> already implemented PSC, I'd think this would be much more useful, early >> in the document. >> >> I'm somewhat confused about the code point allocation strategy in this >> text: >> >> The RPS Request Field is 8 bits, the allocated values are as >> follows: >> >> Value Description Reference >> ------- --------------------------- --------------- >> 0 No Request (NR) this document >> 1 Reverse Request (RR) this document >> 2 unassigned >> 3 Exercise (EXER) this document >> 4 unassigned >> 5 Wait-To-Restore (WTR) this document >> 6 Manual Switch (MS) this document >> 7-10 unassigned >> 11 Signal Fail (SF) this document >> 12 unassigned >> 13 Forced Switch (FS) this document >> 14 unassigned >> 15 Lockout of Protection (LP) this document >> 16-254 unassigned >> 255 Reserved >> >> My first question is, why the highest priority RPS value is 15, given >> that the field is 8 bits wide. If anyone ever needs to add a code point >> higher than the highest priority code point, will that work well? I can >> imagine code that says "if operation_priority is greater than >> highest_priority, it's an error", for example. >> >> I may have other questions depending on your answer, but let's start >> there. >> >> >> > > -- > ================================================================ > Always remember that you are unique...just like everyone else... > > --001a1143e3bea9d3aa055058c73c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To everyone else except Huub, because he shouldn't see= this e-mail before the telechat anyway, being on vacation :D

On Thu, May 25, 2017 at 5:02 AM= , Huub van Helvoort <huubatwork@gmail.com> wrote:
Hello Spencer,

Thank you for your review of our draft.
Please find my response in-line [Huub]

Spencer Dawkins has entered the following ballot position for
draft-ietf-mpls-tp-shared-ring-protection-05: Discuss

 The document, along with other ballot positions, can be found here:
https://datatracker.ietf.= org/doc/draft-ietf-mpls-tp-shared-ring-protection/

-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

I want to thank the authors for a very readable draft. It was a pleasure to review, and that's a high bar for the subject.

[Huub] thank you!

I have loads of questions, but my first set of questions is an expansion of Alvaro's comment that I think rises to the level of a Discuss. Pleas= e
note that I'm asking questions, not proposing text changes, so I really=
do want to discuss it.

 [Huub] OK, understood.

---------- my first set of questions

In this text,

=C2=A0 =C2=A0 Three typical ring protection mechanisms are described in thi= s
=C2=A0 =C2=A0 section: wrapping, short wrapping and steering.=C2=A0 All nod= es on the
=C2=A0 =C2=A0 same ring MUST use the same protection mechanism.

I would like to understand what happens if they aren't - and I'm as= king,
mostly as a way of encouraging guidance for operators in debugging cases where they're not all using the same mechanism. I'm not asking for = a full
mesh of possible misconfigurations, only for a sentence or two ("If th= ey
aren't all using the same protection mechanism, the following things ma= y
happen").

 [Huub] if the MRPS protocol in any node detects RPS message with a
mode that was not provisioned in that node a failure of protocol will
be reported, and the protection mechanism will not be activated.

This sentence, alone, would be enough to answer this = part of my Discuss, if it were in the document.

More broadly, = I'd like to understand why wrapping and short wrapping are
both defined. It seems like the only functional difference is that short wrapping doesn't give you as much latency. Is that right?

24 pages in, I see this:

=C2=A0 =C2=A0 o=C2=A0 In rings utilizing the wrapping protection, each node= detects the
=C2=A0 =C2=A0 =C2=A0 =C2=A0failure or receives the RPS request as the desti= nation node MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0perform the switch from/to the working ring tunn= els to/from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0protection ring tunnels if it has no higher prio= rity active RPS
=C2=A0 =C2=A0 =C2=A0 =C2=A0request.

=C2=A0 =C2=A0 o=C2=A0 In rings utilizing the short wrapping protection, eac= h node
=C2=A0 =C2=A0 =C2=A0 =C2=A0detects the failure or receives the RPS request = as the
destination
=C2=A0 =C2=A0 =C2=A0 =C2=A0node MUST perform the switch only from the worki= ng ring tunnels
to
=C2=A0 =C2=A0 =C2=A0 =C2=A0the protection ring tunnels.

so I'm pretty sure there are differences beyond what I was seeing,
earlier in the document.

 [Huub] wrapping is a mechanism that can be used in case an LSP is dropped in several nodes (p-2-mp application). In this case the traffic will still = have
to reach every node in the ring.
Short wrapping can be used only in p-2-p application. Now the traffic can be dropped at the moment the egress node is reached.
Steering has the least additional propagation delay, but during a short tim= e
the traffic may be duplicated, which may not be desirable is some applicati= ons.

This explanation would be sufficient t= o answer this part of my Discuss, if it was in the document.=C2=A0

It is somewhere between possible and likely that there'= ;s actually a reference that describes the mechanisms in more detail, so if= you included something like "the functional differences between these= protection mechanisms are described in [WhatEver]", that would be fin= e, instead.
=C2=A0
And, of course, I'm not sure what the = effect of choosing steering over
wrapping/short wrapping would be, for my users, but that can wait until
we talk about wrapping and short wrapping ...

At a minimum, I'd like to see guidance for operators in choosing among<= br> the three protection mechanisms. Why would they choose any one of the
three?

 [Huub] more explanatory text can be added, it could be in the introduction<= br> proposed by Alvaro.

I only saw Alvaro sayin= g that he also wanted operational guidance included, but it's very like= ly that whatever you do to answer Alvaro's Comment would answer this pa= rt of my DIscuss. We were complaining about the same thing, it's just t= hat I was more concerned about it ;-)
=C2=A0

I also note that this MUST seems to be repeated using different words in section 5.1, as

=C2=A0 =C2=A0 All nodes in the same ring MUST use the same protection mecha= nism,
=C2=A0 =C2=A0 Wrapping, steering or short-wrapping.

If that's saying the same thing, one MUST is all you need.

 [Huub] OK, point taken.

Thanks. I wasn'= t sure whether it was saying the same thing in different words, or saying s= omething different. This sounds like it's saying the same thing in diff= erent words, and can be safely deleted.=C2=A0

So -= from 10,000 meters up, it looks like we know how to clear my Discuss. Plea= se let me know when you (get back from vacation and) submit the next versio= n, and I'll clear.

I look forward to chatting = about my Comments, but we won't be Discussing them, only chatting.

Spencer



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

---------- all the other questions

 [Huub] I will answer your questions later
(I am currently on holiday and risk a divorce if I don't stop now :-(= =C2=A0 )

Best regards, Huub.



In this text,

=C2=A0 =C2=A0 When the service LSP passes through the interconnected rings,= the
=C2=A0 =C2=A0 direction of the working ring tunnels used on both rings SHOU= LD be
=C2=A0 =C2=A0 the same.=C2=A0 For example, if the service LSP uses the cloc= kwise
working
=C2=A0 =C2=A0 ring tunnel on Ring1, when the service LSP leaves Ring1 and e= nters
=C2=A0 =C2=A0 Ring2, the working ring tunnel used on Ring2 SHOULD also foll= ow the
=C2=A0 =C2=A0 clockwise direction.

I'm not understanding why this is a SHOULD, and not a MUST. If the
direction of the working ring tunnels used on both rings is not the same, does this still work?

If it still works, why does this matter? But, either way, you might
usefully say something about why this isn't always the right thing to d= o,
even if you just give one example. The point of SHOULD is that
implementers make their own informed decisions, so providing information that will inform those decisions seems important.

I wanted to call out

=C2=A0 =C2=A0 Ring switches MUST be preempted by higher priority RPS reques= ts.
For
=C2=A0 =C2=A0 example, consider a protection switch that is active due to a= manual
=C2=A0 =C2=A0 switch request on the given link, and another protection swit= ch is
=C2=A0 =C2=A0 required due to a failure on another link.=C2=A0 Then an RPS = request MUST
=C2=A0 =C2=A0 be generated, the former protection switch MUST be dropped, a= nd the
=C2=A0 =C2=A0 latter protection switch established.

=C2=A0 =C2=A0 MSRP mechanism SHOULD support multiple protection switches in= the
=C2=A0 =C2=A0 ring, resulting in the ring being segmented into two or more<= br> separate
=C2=A0 =C2=A0 segments.=C2=A0 This may happen when several RPS requests of = the same
=C2=A0 =C2=A0 priority exist in the ring due to multiple failures or extern= al
=C2=A0 =C2=A0 switch commands.

as really good examples of the kind of text I think would help the places in this document ("For example", "This may happen when"= ) where no
examples are given. Thanks for providing those examples!

Ouch. Do I understand from

=C2=A0 =C2=A0 o=C2=A0 Protection Switching Mode (M): This 2-bit field indic= ates the
=C2=A0 =C2=A0 =C2=A0 =C2=A0protection switching mode used by the sending no= de of the RPS
=C2=A0 =C2=A0 =C2=A0 =C2=A0message.=C2=A0 This can be used to check that th= e ring nodes on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0same ring use the same protection switching mech= anism.=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 =C2=A0defined values of the M field are listed as belo= w:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +------------------+------= -----------------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 Bits (MSB-LSB)=C2= =A0 |=C2=A0 =C2=A0Protecton Switching Mode=C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +------------------+------= -----------------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A00 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reserv= ed=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A00 1=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Wrappi= ng=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A01 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0Short Wrappin= g=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A01 1=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Steeri= ng=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 +------------------+------= -----------------------+

that you already have three protection mechanisms, and have only one
possible codepoint to allocate for any future optimizations? Assuming
that "0 0" can be unReserved ...

Could you clarify what "anyway" means in this text?

=C2=A0 =C2=A0 When multiple MS RPS requests exist at the same time addressi= ng
=C2=A0 =C2=A0 different links and there is no higher priority request on th= e ring,
=C2=A0 =C2=A0 no switch SHOULD be executed and existing switches MUST be dr= opped.
=C2=A0 =C2=A0 The nodes MUST signal, anyway, the MS RPS request code.

I'm seeing that the commands like LP described in section 5.2.1.1=C2=A0= are
used in the document before these (I'm serious) helpful and clear
explanations appear. If it's possible to move section 5.2.1.1 up in the=
document, that would be great, but if it isn't possible, a forward
pointer would be helpful to readers who don't already know what the
command abbreviations mean.

I'm really confused by this SHOULD:

=C2=A0 =C2=A0 The PSC protocol [RFC6378] is designed for point-to-point LSP= s, on
=C2=A0 =C2=A0 which the protection switching can only be performed on one o= r both
=C2=A0 =C2=A0 of the end points of the LSP.=C2=A0 The RPS protocol is desig= ned for ring
=C2=A0 =C2=A0 tunnels, which consist of multiple ring nodes, and the failur= e could
=C2=A0 =C2=A0 happen on any segment of the ring, thus RPS SHOULD be capable= of
=C2=A0 =C2=A0 identifying and handling the different failures on the ring, = and
=C2=A0 =C2=A0 coordinating the protection switching behavior of all the nod= es on
=C2=A0 =C2=A0 the ring.

I suspect that's because it's not a 2119 SHOULD, but if people thin= k it
is, I wouldn't mind understanding why.

Section 5.3, "RPS and PSC Comparison on Ring Topology" is really = helpful,
but it appears 43 pages in. Given that I'd expect people to be asking w= hy
they should implement a new protection switching protocol when they've<= br> already implemented PSC, I'd think this would be much more useful, earl= y
in the document.

I'm somewhat confused about the code point allocation strategy in this<= br> text:

=C2=A0 =C2=A0 The RPS Request Field is 8 bits, the allocated values are as<= br> follows:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Value=C2=A0 =C2=A0 =C2=A0 =C2=A0Description=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reference
=C2=A0 =C2=A0 =C2=A0 =C2=A0-------=C2=A0 --------------------------- ------= ---------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A0No Request (NR)=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this document
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1=C2=A0 =C2=A0 =C2=A0Reverse Request (RR= )=C2=A0 =C2=A0 =C2=A0 =C2=A0 this document
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2=C2=A0 =C2=A0 =C2=A0unassigned
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3=C2=A0 =C2=A0 =C2=A0Exercise (EXER)=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this document
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4=C2=A0 =C2=A0 =C2=A0unassigned
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5=C2=A0 =C2=A0 =C2=A0Wait-To-Restore (WT= R)=C2=A0 =C2=A0 =C2=A0 =C2=A0this document
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6=C2=A0 =C2=A0 =C2=A0Manual Switch (MS)= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this document
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A07-10=C2=A0 =C2=A0unassigned
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A011=C2=A0 =C2=A0 =C2=A0Signal Fail (SF)=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this document
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A012=C2=A0 =C2=A0 =C2=A0unassigned
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A013=C2=A0 =C2=A0 =C2=A0Forced Switch (FS)= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this document
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A014=C2=A0 =C2=A0 =C2=A0unassigned
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015=C2=A0 =C2=A0 =C2=A0Lockout of Protecti= on (LP)=C2=A0 this document
=C2=A0 =C2=A0 =C2=A0 =C2=A016-254=C2=A0 =C2=A0unassigned
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0255=C2=A0 =C2=A0 Reserved

My first question is, why the highest priority RPS value is 15, given
that the field is 8 bits wide. If anyone ever needs to add a code point
higher than the highest priority code point, will that work well? I can
imagine code that says "if operation_priority is greater than
highest_priority, it's an error", for example.

I may have other questions depending on your answer, but let's start there.




--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Always remember that you are unique...just like everyone else...


--001a1143e3bea9d3aa055058c73c-- From nobody Thu May 25 06:06:20 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7499012944A; Thu, 25 May 2017 06:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsYZfh5e0K98; Thu, 25 May 2017 06:06:16 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7741200C5; Thu, 25 May 2017 06:06:15 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id p73so91806212ywp.0; Thu, 25 May 2017 06:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+/W6IenDB08/ZqDAFDCaGgMuaBNLgeTJGFcMxfTOYQA=; b=vLB07ckMT+owI1LczG3gGJV58dIDK6cJvJIz2IuJx7FHc3anGlhNQMpJUs9zKDD2oH V2EaNTHlXPFGhNEMRusueCWuZYHOvbE63Qo8kA4Cs+omSM0QLrhkcAHmLrzn6CtCdCmR 2Yrw9Kjn9sZXLb1Osk66fxZnF9VYkkuGhcaP/WxK5HsfNgSIQpQ76AO9t4CKF5u11Ioy nTHjJnNm9rt2HAxDiLnRf/gqH/oFZYe/S4ChFHVVVGi7z444fjAgYRv42D9TPcmBpp3f gX2q38y5/wvjxS3Q/IuVCLxZu0X5JkI9n6wDWPnbtXje8ayEpMseo0QWJhJlMNjhXnJu +SkQ== 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=+/W6IenDB08/ZqDAFDCaGgMuaBNLgeTJGFcMxfTOYQA=; b=KpUfN4JQWVJ1PX+zvDGsy3bvTer85lzIcKjNeaF+whmBWOHPDV0KeCN3kfJ2mfdnuX zvAy/Nkh6H3XzlcCDdQZVd47+Yj17bPX+u0h/Ih6pticVW6+tC4BR3kpUiIozxQXggVT oqcJjHzQYHAABjX2FH0AIhqr9xkRSADwfr0JVD8a8VniUXZT5GP6s4n8EWsDRMHBb30v yyELWainEvGdEXCM/VT8jUzYgTHawJv7/UvBoLrvhtXUzOOMHkGQLJiS/cC6HcmfIzhU XFcjjoS1Up81Bnn6lfIUHNYTG5Ws5hvBqYWZ9ASEPKoc25/aioBzEOWTSdLqTio6ypFE k6Xg== X-Gm-Message-State: AODbwcC8PRYqpiECp5qjFwZmC5O3bT+e3Qgm6EPNbLkBQaPGNJdUwpM+ 4xgHvYssxjunHsoMftj6svWskCYnBw== X-Received: by 10.13.228.69 with SMTP id n66mr466890ywe.275.1495717575187; Thu, 25 May 2017 06:06:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.163.130 with HTTP; Thu, 25 May 2017 06:06:14 -0700 (PDT) In-Reply-To: <71a35d11-69b4-6f77-350d-92b99f7f1fda@gmail.com> References: <149560689201.28401.2592268750185030462.idtracker@ietfa.amsl.com> <71a35d11-69b4-6f77-350d-92b99f7f1fda@gmail.com> From: Spencer Dawkins at IETF Date: Thu, 25 May 2017 08:06:14 -0500 Message-ID: To: huubatwork@gmail.com Cc: Eric Rescorla , The IESG , "mpls@ietf.org" , draft-ietf-mpls-tp-shared-ring-protection@ietf.org, "mpls-chairs@ietf.org" , Eric Gray Content-Type: multipart/alternative; boundary="94eb2c034ce4c0f7dd055058e25d" Archived-At: Subject: Re: [mpls] Eric Rescorla's Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 13:06:19 -0000 --94eb2c034ce4c0f7dd055058e25d Content-Type: text/plain; charset="UTF-8" Hi, Huub, I'm replying in the thread on Eric's Discuss, but only because his Comments are related to my ballot position. On Thu, May 25, 2017 at 4:36 AM, Huub van Helvoort wrote: > Hello Eric, > > Thank you for reviewing the security aspects of our draft. > > Please see my response in-line [Huub] > > Eric Rescorla has entered the following ballot position for >> draft-ietf-mpls-tp-shared-ring-protection-05: Discuss >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-r >> ing-protection/ >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> The security considerations of this document seem unacceptably >> incomplete, as they basically just point to other documents. >> >> The RPS protocol defined in this document is carried in the G-ACh >> [RFC5586], which is a generalization of the Associated Channel >> defined in [RFC4385]. The security considerations specified in >> these >> documents apply to the proposed RPS mechanism. >> >> The security considerations of those documents don't seem that great >> either. However, I believe that they miss a new security issue raised >> by the mechanism in this draft, which is that a member of the ring >> appears to be able to forge reports of errors at other parts of the >> ring. Specifically, S 5.1.3.3 says: >> >> When a node is in a pass-through state, it MUST transfer the >> received >> RPS Request in the same direction. >> >> When a node is in a pass-through state, it MUST enable the traffic >> flow on protection ring tunnels in both directions. >> >> This seems not to involve any filtering, which suggests that node B >> can send a forged SF from C->D and from D->C, which at least >> potentially >> temporarily breaks the link there, causing traffic diversion. >> >> More generally, this system assumes that every node trusts every >> other node completely. That must at least be stated. >> >> Incidentally, the text above appears to contain a bug in that it >> doesn't talk about processing incoming RPS requests intended for >> the receiving node, but I may just have missed the section where >> it says that. >> > [Huub] your discuss is applicable to any OAM protocol where an > intermediate node can forge false OAM messages and affect traffic. > > Regarding this draft, a forged SF may cause a protection switch if > the protocol does not detect a failure of protocol caused by a wrong > sequence or illegal combination of received RPS messages from the > clock-wise and the anti-clock-wise direction in the ring. > The protection switch itself will not cause a loss of traffic. > > ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> S 4.1.1. >> protect these LSPs that traverse the ring, a clockwise working ring >> tunnel (RcW_D) via E->F->A->B->C->D, and its anticlockwise >> protection >> ring tunnel (RaP_D) via D->C->B->A->F->E->D are established, Also, >> an >> anti-clockwise working ring tunnel (RaW_D) via C->B->A->F->E->D, and >> its clockwise protection ring tunnel (RcP_D) via D->E->F->A->B->C->D >> >> Why does the protection tunnel include D on both ends whereas the >> working >> tunnel does not? >> > > [Huub] the working ring tunnel should not be a closed loop. the > protection ring tunnel is closed until a protection switch is activated, > at that time the protection ring tunnel is opened at the appropriate > location to transport the protected traffic. The response you provided to Eric made this much clearer to me. It might very well be helpful to include in the document. S 4.2. >> packets are periodically exchanged between each pair of MEPs to >> monitor the link health. Three consecutive lost CC packets will be >> interpreted as a link failure. >> >> Is this a normative statement (i.e., does it need a MUST). >> > > [Huub] he MUST is a requirement for the SF detection described in RFC6371 > and ITU-T G.806 . > > S 4.3.2.1. >> Why do you ever not use short wrapping? >> > > [Huub] wrapping is a mechanism that can be used in case an LSP is dropped > in several nodes (p-2-mp application). > Short wrapping can be used only in p-2-p application. You and I, and Alvaro in his Comment, are already talking about guidance in choosing between the protection mechanisms in the thread on my Discuss, but this looks like a FABulous factoid to include in that guidance :D Spencer S 5.1.4.1 >> A node MUST revert from pass-through state to the idle state when it >> detects NR codes incoming from both directions. Both directions >> revert simultaneously from the pass-through state to the idle state. >> >> incoming within what time frame? >> > > [Huub] this time depends on the propagation delay in the ring and the > RPS processing time in each node. > Because of the 50 ms switching objective a 100 ms timer could be used. > > Best regards, Huub. > > > -- > ================================================================ > Always remember that you are unique...just like everyone else... > > --94eb2c034ce4c0f7dd055058e25d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Huub,

I'm replying in the threa= d on Eric's Discuss, but only because his Comments are related to my ba= llot position.

On Thu, May 25, 2017 at 4:36 AM, Huub van Helvoort <<= a href=3D"mailto:huubatwork@gmail.com" target=3D"_blank">huubatwork@gmail.c= om> wrote:
Hello Eric,

Thank you for reviewing the security aspects of our draft.

Please see my response in-line [Huub]

Eric Rescorla has entered the following ballot position for
draft-ietf-mpls-tp-shared-ring-protection-05: Discuss

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.= org/doc/draft-ietf-mpls-tp-shared-ring-protection/

-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

The security considerations of this document seem unacceptably
incomplete, as they basically just point to other documents.

=C2=A0 =C2=A0 The RPS protocol defined in this document is carried in the G= -ACh
=C2=A0 =C2=A0 [RFC5586], which is a generalization of the Associated Channe= l
=C2=A0 =C2=A0 defined in [RFC4385].=C2=A0 The security considerations speci= fied in
these
=C2=A0 =C2=A0 documents apply to the proposed RPS mechanism.

The security considerations of those documents don't seem that great either. However, I believe that they miss a new security issue raised
by the mechanism in this draft, which is that a member of the ring
appears to be able to forge reports of errors at other parts of the
ring. Specifically, S 5.1.3.3 says:

=C2=A0 =C2=A0 When a node is in a pass-through state, it MUST transfer the<= br> received
=C2=A0 =C2=A0 RPS Request in the same direction.

=C2=A0 =C2=A0 When a node is in a pass-through state, it MUST enable the tr= affic
=C2=A0 =C2=A0 flow on protection ring tunnels in both directions.

This seems not to involve any filtering, which suggests that node B
can send a forged SF from C->D and from D->C, which at least
potentially
temporarily breaks the link there, causing traffic diversion.

More generally, this system assumes that every node trusts every
other node completely. That must at least be stated.

Incidentally, the text above appears to contain a bug in that it
doesn't talk about processing incoming RPS requests intended for
the receiving node, but I may just have missed the section where
it says that.
[Huub] your discuss is applicable to any OAM protocol where an
intermediate node can forge false OAM messages and affect traffic.

Regarding this draft, a forged SF may cause a protection switch if
the protocol does not detect a failure of protocol caused by a wrong
sequence or illegal combination of received RPS messages from the
clock-wise and the anti-clock-wise direction in the ring.
The protection switch itself will not cause a loss of traffic.

-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

S 4.1.1.
=C2=A0 =C2=A0 protect these LSPs that traverse the ring, a clockwise workin= g ring
=C2=A0 =C2=A0 tunnel (RcW_D) via E->F->A->B->C->D, and its a= nticlockwise
protection
=C2=A0 =C2=A0 ring tunnel (RaP_D) via D->C->B->A->F->E->D= are established, Also,
an
=C2=A0 =C2=A0 anti-clockwise working ring tunnel (RaW_D) via C->B->A-= >F->E->D, and
=C2=A0 =C2=A0 its clockwise protection ring tunnel (RcP_D) via D->E->= F->A->B->C->D

Why does the protection tunnel include D on both ends whereas the
working
tunnel does not?

 [Huub] the working ring tunnel should not be a closed loop. the
protection ring tunnel is closed until a protection switch is activated, at that time the protection ring tunnel is opened at the appropriate
location to transport the protected traffic.

=C2=A0The response you provided to Eric made this much clearer to me. It = might very well be helpful to include in the document.

=
S 4.2.
=C2=A0 =C2=A0 packets are periodically exchanged between each pair of MEPs = to
=C2=A0 =C2=A0 monitor the link health.=C2=A0 Three consecutive lost CC pack= ets will be
=C2=A0 =C2=A0 interpreted as a link failure.

Is this a normative statement (i.e., does it need a MUST).

 [Huub] he MUST is a requirement for the SF detection described in RFC6371 and ITU-T G.806 .

S 4.3.2.1.
Why do you ever not use short wrapping?

 [Huub] wrapping is a mechanism that can be used in case an LSP is dropped in several nodes (p-2-mp application).
Short wrapping can be used only in p-2-p application.

=
You and I, and Alvaro in his Comment, are already talking about = guidance in choosing between the protection mechanisms in the thread on my = Discuss, but this looks like a FABulous factoid to include in that guidance= :D

Spencer

S 5.1.4.1
=C2=A0 =C2=A0 A node MUST revert from pass-through state to the idle state = when it
=C2=A0 =C2=A0 detects NR codes incoming from both directions.=C2=A0 Both di= rections
=C2=A0 =C2=A0 revert simultaneously from the pass-through state to the idle= state.

incoming within what time frame?

 [Huub] this time depends on the propagation delay in the ring and the
RPS processing time in each node.
Because of the 50 ms switching objective a 100 ms timer could be used.

Best regards, Huub.


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Always remember that you are unique...just like everyone else...


--94eb2c034ce4c0f7dd055058e25d-- From nobody Thu May 25 06:38:41 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BD312778E; Thu, 25 May 2017 06:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgF8J8WYzgLF; Thu, 25 May 2017 06:38:38 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D284E126B72; Thu, 25 May 2017 06:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9014; q=dns/txt; s=iport; t=1495719517; x=1496929117; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gy8u9O2FKPLlMOpqgyhVChRzeKaFyKkSXLdcn6ow7dE=; b=YNI1VKg7iKdS3Il9R7EyZKQf7Ie8oZvVSsm7tdXDZyaK1hPKIll7CcDY q3Zb7d6UbBNaxbDyGq8A8ySgG1gAapjGs6S99/2i2USNTfQa34sWbd/Bo wOjPkFD2z+dI8bjz6o3640x5o9PajkEgh3FsVCRtINTTzCAkcqX41xo5q o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnAABT3SZZ/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoENB4NoihiaBYgYhTiCD4YkAhqCYz8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGQYjVhACAQg7BAMCAgIfERQRAgQBDQWJRUwDFa8UgiYrhwYNhAcBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdhl+CCYJxgleFIS+CMQWWeYZvOwGOT4RYkXeLMokbAR8?= =?us-ascii?q?4gQpzFVgBhR2BSnaIF4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,391,1491264000"; d="scan'208,217";a="431283279" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 May 2017 13:38:37 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v4PDca1O020010 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 May 2017 13:38:36 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 25 May 2017 08:38:36 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 25 May 2017 08:38:36 -0500 From: "Alvaro Retana (aretana)" To: Spencer Dawkins at IETF , "huubatwork@gmail.com" CC: "mpls-chairs@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-tp-shared-ring-protection@ietf.org" , The IESG , Eric Gray Thread-Topic: Spencer Dawkins' Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT) Thread-Index: AQHS1T4CyeG/Rethf0qxjjuT6S+0OaIFVpgA///Y3YA= Date: Thu, 25 May 2017 13:38:35 +0000 Message-ID: <4203C4E8-7DE2-4BA5-A2BC-D31AA37FE9ED@cisco.com> References: <149565660910.8641.739437988075507213.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.174.242] Content-Type: multipart/alternative; boundary="_000_4203C4E87DE24BA5A2BCD31AA37FE9EDciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Spencer Dawkins' Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 13:38:40 -0000 --_000_4203C4E87DE24BA5A2BCD31AA37FE9EDciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SHV1YjoNCg0KSGkhDQoNCkkgZG9u4oCZdCB0aGluayB0aGF0IGp1c3QgcHV0dGluZyBhIHBhcmFn cmFwaCBpbiB0aGUgSW50cm9kdWN0aW9uIHdvdWxkIGJlIGVub3VnaCBvcGVyYXRpb25hbCBndWlk YW5jZS4gIElkZWFsbHksIEkgd291bGQgbGlrZSB0byBzZWUgYSBzZXBhcmF0ZSBTZWN0aW9uIG9u IE9wZXJhdGlvbmFsIENvbnNpZGVyYXRpb25zIGV4cGxhaW5pbmcgd2hlbi93aHkgZWFjaCBzaG91 bGQgYmUgY29uc2lkZXJlZC4NCg0KQWxzbywgcmZjNTcwNiBvZmZlcnMgZ29vZCBndWlkYW5jZSDi gJMgSSByZWFsaXplIG5vdCBhbGwgc2VjdGlvbnMgdGhlcmUgd291bGQgYXBwbHkgaW4gdGhpcyBj YXNlLg0KDQpUaGFua3MhDQoNCkFsdmFyby4NCg0KT24gNS8yNS8xNywgOTo1OCBBTSwgImllc2cg b24gYmVoYWxmIG9mIFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIiA8aWVzZy1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzppZXNnLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBzcGVuY2VyZGF3 a2lucy5pZXRmQGdtYWlsLmNvbTxtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+ PiB3cm90ZToNCg0KDQpBdCBhIG1pbmltdW0sIEknZCBsaWtlIHRvIHNlZSBndWlkYW5jZSBmb3Ig b3BlcmF0b3JzIGluIGNob29zaW5nIGFtb25nDQp0aGUgdGhyZWUgcHJvdGVjdGlvbiBtZWNoYW5p c21zLiBXaHkgd291bGQgdGhleSBjaG9vc2UgYW55IG9uZSBvZiB0aGUNCnRocmVlPw0KDQpbSHV1 Yl0gbW9yZSBleHBsYW5hdG9yeSB0ZXh0IGNhbiBiZSBhZGRlZCwgaXQgY291bGQgYmUgaW4gdGhl IGludHJvZHVjdGlvbg0KcHJvcG9zZWQgYnkgQWx2YXJvLg0KDQpJIG9ubHkgc2F3IEFsdmFybyBz YXlpbmcgdGhhdCBoZSBhbHNvIHdhbnRlZCBvcGVyYXRpb25hbCBndWlkYW5jZSBpbmNsdWRlZCwg YnV0IGl0J3MgdmVyeSBsaWtlbHkgdGhhdCB3aGF0ZXZlciB5b3UgZG8gdG8gYW5zd2VyIEFsdmFy bydzIENvbW1lbnQgd291bGQgYW5zd2VyIHRoaXMgcGFydCBvZiBteSBESXNjdXNzLiBXZSB3ZXJl IGNvbXBsYWluaW5nIGFib3V0IHRoZSBzYW1lIHRoaW5nLCBpdCdzIGp1c3QgdGhhdCBJIHdhcyBt b3JlIGNvbmNlcm5lZCBhYm91dCBpdCA7LSkNCg0K --_000_4203C4E87DE24BA5A2BCD31AA37FE9EDciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <62BD1F7FE0E536479817F21B231F6812@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3Rl eHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNv SW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5IdXViOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkhpITxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkkgZG9u4oCZdCB0aGluayB0aGF0IGp1c3QgcHV0dGluZyBh IHBhcmFncmFwaCBpbiB0aGUgSW50cm9kdWN0aW9uIHdvdWxkIGJlIGVub3VnaCBvcGVyYXRpb25h bCBndWlkYW5jZS4mbmJzcDsgSWRlYWxseSwgSSB3b3VsZCBsaWtlIHRvIHNlZSBhIHNlcGFyYXRl IFNlY3Rpb24gb24gT3BlcmF0aW9uYWwgQ29uc2lkZXJhdGlvbnMgZXhwbGFpbmluZw0KIHdoZW4v d2h5IGVhY2ggc2hvdWxkIGJlIGNvbnNpZGVyZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ QWxzbywgcmZjNTcwNiBvZmZlcnMgZ29vZCBndWlkYW5jZSDigJMgSSByZWFsaXplIG5vdCBhbGwg c2VjdGlvbnMgdGhlcmUgd291bGQgYXBwbHkgaW4gdGhpcyBjYXNlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5BbHZhcm8uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA1LzI1LzE3LCA5OjU4 IEFNLCAmcXVvdDtpZXNnIG9uIGJlaGFsZiBvZiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmllc2ctYm91bmNlc0BpZXRmLm9yZyI+aWVzZy1ib3VuY2Vz QGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpzcGVuY2VyZGF3a2lu cy5pZXRmQGdtYWlsLmNvbSI+c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbjtmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6 IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48YnI+DQpBdCBhIG1pbmltdW0sIEknZCBsaWtlIHRvIHNlZSBndWlkYW5jZSBmb3Igb3Bl cmF0b3JzIGluIGNob29zaW5nIGFtb25nPGJyPg0KdGhlIHRocmVlIHByb3RlY3Rpb24gbWVjaGFu aXNtcy4gV2h5IHdvdWxkIHRoZXkgY2hvb3NlIGFueSBvbmUgb2YgdGhlPGJyPg0KdGhyZWU/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCltIdXViXSBtb3JlIGV4cGxhbmF0b3J5 IHRleHQgY2FuIGJlIGFkZGVkLCBpdCBjb3VsZCBiZSBpbiB0aGUgaW50cm9kdWN0aW9uPGJyPg0K cHJvcG9zZWQgYnkgQWx2YXJvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgb25seSBzYXcgQWx2YXJvIHNh eWluZyB0aGF0IGhlIGFsc28gd2FudGVkIG9wZXJhdGlvbmFsIGd1aWRhbmNlIGluY2x1ZGVkLCBi dXQgaXQncyB2ZXJ5IGxpa2VseSB0aGF0IHdoYXRldmVyIHlvdSBkbyB0byBhbnN3ZXIgQWx2YXJv J3MgQ29tbWVudCB3b3VsZCBhbnN3ZXIgdGhpcyBwYXJ0IG9mDQogbXkgRElzY3Vzcy4gV2Ugd2Vy ZSBjb21wbGFpbmluZyBhYm91dCB0aGUgc2FtZSB0aGluZywgaXQncyBqdXN0IHRoYXQgSSB3YXMg bW9yZSBjb25jZXJuZWQgYWJvdXQgaXQgOy0pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_4203C4E87DE24BA5A2BCD31AA37FE9EDciscocom_-- From nobody Thu May 25 07:26:49 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A721243F3; Thu, 25 May 2017 07:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpQDT-IO76ZO; Thu, 25 May 2017 07:26:39 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 7B3BC1293FD; Thu, 25 May 2017 07:26:39 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id b204so281940896oii.1; Thu, 25 May 2017 07:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T90lCL9/8QLxvK2yduIMfsYfVnX4V2W9V10b8UEwHV0=; b=dT3chD3F9u2kseSeZxmiPfH1K51sOS+PAAUdlIC21N/UUFI4JfMJC45nyNqzMG/+5j DPjGNQB8dTgzl7Ll7oYwJ5c9AQ8m8xygN8aUA18GEzMfHcmI9+o3JaWbnC0sBsnvxaPA iKM+7MWlqdPWMJcCwUsjDG4013QAm8cswN+lAPBjkPYkVZnA9j+cqfHdUKw2D9BF0+F0 rYn07yfE6W1N+74B5iQo0977py1j+XIoHBtDzNJeKrfSyEK5T2XY9wFZKViUAQJ5G0u5 wtX54MHOZ+VLilSZeVH+XnOH3kGxQct7UvEEAgMFb2dpBQt0NQiNG9Xb9BMYPb8zOOQC Ydqw== 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=T90lCL9/8QLxvK2yduIMfsYfVnX4V2W9V10b8UEwHV0=; b=NGnHDVhvPC8RRLAErOiIXs9jKRmveSMjkO+0qRUpOLBRhDSw8+GyI14/7kVAq9tG1T v6vx2AVfpHvzQVtzANfeWTFAfAnUYdwpWFwATrcrXzA6um9+bNrVSM0Rij3dM+N4awR6 MipSsOkmo7r97lUn6+A7++IWpUodjeOHq4nPYK2sXPuNLuna+MuNckE413JSW2Hka299 u/h66rM3bfM9N/Kso+gTMJOkEm/sBWhFOwWTJyAljnNYnJ8FpSPh6qDGavI+6RLAS6vf cRH7F1oJUbQD2hdwST9XFzQXSSNBCK/sMkXfiTiDywPXOjMBRoE4/rCMfyeAuD7ih9DC 1d1w== X-Gm-Message-State: AODbwcDqvYmjvANgph9mdEk89Jv4HHhHp2jV67DISRmvWkJ/PBJ6UICt 9aoFdu9IhxxgQ/FMpLnZg9Dp5EI5yQ== X-Received: by 10.157.2.232 with SMTP id 95mr6803601otl.219.1495722398862; Thu, 25 May 2017 07:26:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.246 with HTTP; Thu, 25 May 2017 07:26:38 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Thu, 25 May 2017 22:26:38 +0800 Message-ID: To: "Carlos Pignataro (cpignata)" Cc: "n.leymann@telekom.de" , mpls , "mpls-chairs@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0bbff244528205505a02ee" Archived-At: Subject: Re: [mpls] WGLC for draft-ietf-mpls-bfd-directed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 14:26:42 -0000 --94eb2c0bbff244528205505a02ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Carlos, thank you for taking two minutes to write the message. From it all I've found only one concern that, in my view, may be considered technical. Thus I'll bring it to the forefront and will try to explain how the situation may be handled. You wrote: 1. This approach assumes that FECs do not ever change. A reverse path is instructed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what happens if = paths change?!? If a return tunnel is suddenly deleted from underneath? I consider it to be the case that should be handled by properly operating the network rather then auto-discovering it and auto-recovering. I hardly believe that a tunnel may be "suddenly deleted" without the operator being aware of that. And if that is the case, then the operator may proactively re-signal return path for those BFD sessions that may be affected by the planned change in the network. Even more, BFD sessions to decrease chance of receiving false negative during period the remote BFD peer switches to new recommended path. Thank you for the editorial suggestion to consider renaming the section. We'll discuss and share our proposal to improve the wording. Others may decide to respond to the rest of your message. There's nothing of technical substance, as I see it. Regards, Greg On Wed, May 24, 2017 at 11:36 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Nic, > > I do not support advancing this document in its current form. It has many > technical deficiencies, some of which are listed and described below. > > I also believe your WGLC note should have been much more detailed and > comprehensive. > > I believe this is the 3rd WGLC on this document, correct? (That gives a > new meaning to =E2=80=9CLast=E2=80=9D :-) If so, that should have also be= en clarified in > the WGLC email, with a much more clear explanation and comprehensive set = of > details of how concerns were discussed and addressed. > > > The authors have updated draft-ietf-mpls-bfd-directed and think that th= e > draft is ready for WGLC. > > I am very concerned that there was no discussion on the list of any of > those changes. The authors believe the draft is ready =E2=80=94 do you b= elieve so > as well, Nic? Was a shepherd review performed and is that available? > > > Please note that draft-ietf-mpls-bfd-directed did not pass the > > previous working group last call, because of an IPR disclosure: > > Is that the 1st or 2nd WGLC? I think this statement is an > oversimplification. There were many technical concerns. > > Anyway, scanning through this document, some technical issues: > > 1. This approach assumes that FECs do not ever change. A reverse path is > instructed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what happens i= f paths > change?!? If a return tunnel is suddenly deleted from underneath? > 2. =E2=80=9CCase of MPLS Data Plane=E2=80=9D =E2=80=94 is there any other= non-MPLS case? This > points to the fact of lack of review and editorial sloppiness. > 3. =E2=80=9CExactly one sub-TLV MUST be included in the Reverse Path TLV.= =E2=80=9D =E2=80=94 so > basically, no Tunnels can be return path?!? > 4. The =E2=80=9CUse Case Scenario=E2=80=9D uses 2119 language in a way th= at does not make > sense. > > Please note, this is not an exhaustive list, but a 2 minute scan through > the doc. > > Thanks! > > Carlos. > > > > On May 24, 2017, at 2:33 AM, n.leymann@telekom.de > wrote: > > > > Dear Working Group, > > > > The authors have updated draft-ietf-mpls-bfd-directed and think that th= e > draft is ready for WGLC. > > Therefore this e-mail starts a WG LC which will end on the 7th of June. > > > > Please note that draft-ietf-mpls-bfd-directed did not pass the > > previous working group last call, because of an IPR disclosure: > > > > https://datatracker.ietf.org/ipr/2892/ > > > > The authors have updated the draft and they believe that the IPR is no > longer in scope. > > Please notify the list if you still think the IPR is an issue and pleas= e > state if you think it > > is OK to continue with the publication of this document. > > > > Best regards > > > > Nic > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --94eb2c0bbff244528205505a02ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Carlos,
thank you for taking two minutes to write= the message. From it all I've found only one concern that, in my view,= may be considered technical. Thus I'll bring it to the forefront and w= ill try to explain how the situation may be handled.
You wrote:
1. This approach assumes that FEC= s do not ever change. A reverse path is instructed at setup/bootstrap with = MPLS LSP Ping =E2=80=94 what happens if paths change?!? If a return tunnel = is suddenly deleted from underneath?
I consider it to be the case that should be handled by prop= erly operating the network rather then auto-discovering it and auto-recover= ing. I hardly believe that a tunnel may be "suddenly deleted" wit= hout the operator being aware of that. And if that is the case, then the op= erator may proactively re-signal return path for those BFD sessions that ma= y be affected by the planned change in the network. Even more, BFD sessions= to decrease chance of receiving false negative during period the remote BF= D peer switches to new recommended path.

Than= k you for the editorial suggestion to consider renaming the section. We'= ;ll discuss and share our proposal to improve the wording.

Others may decide to respond to the rest of your message. The= re's nothing of technical substance, as I see it.

Regards,
Greg

O= n Wed, May 24, 2017 at 11:36 PM, Carlos Pignataro (cpignata) <cpignata@ci= sco.com> wrote:
Nic,

I do not support advancing this document in its current form. It has many t= echnical deficiencies, some of which are listed and described below.

I also believe your WGLC note should have been much more detailed and compr= ehensive.

I believe this is the 3rd WGLC on this document, correct? (That gives a new= meaning to =E2=80=9CLast=E2=80=9D :-) If so, that should have also been cl= arified in the WGLC email, with a much more clear explanation and comprehen= sive set of details of how concerns were discussed and addressed.

> The authors have updated draft-ietf-mpls-bfd-directed and think that t= he draft is ready for WGLC.

I am very concerned that there was no discussion on the list of any = of those changes.=C2=A0 The authors believe the draft is ready =E2=80=94 do= you believe so as well, Nic? Was a shepherd review performed and is that a= vailable?

> Please note that draft-ietf-mpls-bfd-directed did not pass the
> previous working group last call, because of an IPR disclosure:

Is that the 1st or 2nd WGLC? I think this statement is an oversimpli= fication. There were many technical concerns.

Anyway, scanning through this document, some technical issues:

1. This approach assumes that FECs do not ever change. A reverse path is in= structed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what happens if pa= ths change?!? If a return tunnel is suddenly deleted from underneath?
2. =E2=80=9CCase of MPLS Data Plane=E2=80=9D =E2=80=94 is there any other n= on-MPLS case? This points to the fact of lack of review and editorial slopp= iness.
3. =E2=80=9CExactly one sub-TLV MUST be included in the Reverse Path TLV.= =E2=80=9D =E2=80=94 so basically, no Tunnels can be return path?!?
4. The =E2=80=9CUse Case Scenario=E2=80=9D uses 2119 language in a way that= does not make sense.

Please note, this is not an exhaustive list, but a 2 minute scan through th= e doc.

Thanks!

Carlos.


> On May 24, 2017, at 2:33 AM, n= .leymann@telekom.de <N.Leyma= nn@telekom.de> wrote:
>
> Dear Working Group,
>
> The authors have updated draft-ietf-mpls-bfd-directed and think that t= he draft is ready for WGLC.
> Therefore this e-mail starts a WG LC which will end on the 7th of June= .
>
> Please note that draft-ietf-mpls-bfd-directed did not pass the
> previous working group last call, because of an IPR disclosure:
>
>=C2=A0 =C2=A0https://datatracker.ietf.org/ipr/2892/
>
> The authors have updated the draft and they believe that the IPR is no= longer in scope.
> Please notify the list if you still think the IPR is an issue and plea= se state if you think it
> is OK to continue with the publication of this document.
>
>=C2=A0 =C2=A0Best regards
>
>=C2=A0 =C2=A0 =C2=A0Nic
>
>
> __________________= _____________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

--94eb2c0bbff244528205505a02ee-- From nobody Fri May 26 12:45:26 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E9C129408; Fri, 26 May 2017 12:45:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk CC: mpls@ietf.org, draft-ietf-mpls-app-aware-tldp@ietf.org, mpls-chairs@ietf.org, db3546@att.com, loa@pi.nu Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149582792501.8620.3320009206996108580.idtracker@ietfa.amsl.com> Date: Fri, 26 May 2017 12:45:25 -0700 Archived-At: Subject: [mpls] Last Call: (Application-aware Targeted LDP) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 19:45:25 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Application-aware Targeted LDP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-06-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Recent targeted LDP (tLDP) applications such as remote loop-free alternate (LFA) and BGP auto discovered pseudowire may automatically establish a tLDP session to any LSR in a network. The initiating LSR has information about the targeted applications to administratively control initiation of the session. However, the responding LSR has no such information to control acceptance of this session. This document defines a mechanism to advertise and negotiate Targeted Applications Capability (TAC) during LDP session initialization. As the responding LSR becomes aware of targeted applications, it may establish a limited number of tLDP sessions for certain applications. In addition, each targeted application is mapped to LDP Forwarding Equivalence Class (FEC) Elements to advertise only necessary LDP FEC- label bindings over the session. This document updates RFC 7473 for enabling advertisement of LDP FEC-label bindings over the session. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-app-aware-tldp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mpls-app-aware-tldp/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2507/ https://datatracker.ietf.org/ipr/2796/ From nobody Fri May 26 14:14:49 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0461270FC; Fri, 26 May 2017 14:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 SxSiFhFfmLDZ; Fri, 26 May 2017 14:14:46 -0700 (PDT) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 D2374126CBF; Fri, 26 May 2017 14:14:45 -0700 (PDT) Received: by mail-qk0-x243.google.com with SMTP id u75so2647283qka.1; Fri, 26 May 2017 14:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc:message-id :references:to; bh=FogzP5feMKcZGX+4meiE6SY8pM2kKLN4c/KQ0rQcDNM=; b=FhQCy1sDuwi+mvi9cDmHqSf4sPuz6oKW7EKuJXTIVoPlGZEs14yTkiVGNgd2Kc9obX cAnkwuPFY3nX/tExaM7dDoubQT5xouVya5x6TFI4tOqdBMWDAevOKyJ+i+pcfjc/I4/N Ol+US9tpxyxLHSfUSxjYsYXpyBBzcIrQAMc0R+SqIQ07UkKbtM0Q2saTsPVHI4LtYQ2k 40bGCQnubUBq30ZIFBHaiGQea17X5zjbyUkr+MNJoiVPT+JAFeeZumif/N+iPHwLXomk 7jM0cVUxN+Z+xZHXnA9/ImGly1gN0GK2ogzh0bCOawpgIVyD7IYeJ4AaUZRxQ/Gpzz9A bbtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=FogzP5feMKcZGX+4meiE6SY8pM2kKLN4c/KQ0rQcDNM=; b=gx+if0OnJZPyI1hPVJNfC58O8yqCchk9tEUVCBt7znz+aYUdwO9pBs4hvPRq8duqh8 ++zfMLnQjWXocqwyYHusENTy/ZtMXqvLBLPOYuacB2CYumjGGv3H6qtNeHQIf2KWLv1D 5me7J9wVNzb3TPPwZMUUiij7lvhZZI46KSdT9oQSUICLIFBMsV/CP0jmwCfCNKk8urTB PrQGNis7Mc8ZCOPclAnaetEldhuoKAiYzlgUaCOGPQBYururGUupbaWvkY7iNxx6k1AD 6S7IBOy+DRvHcMaZdDxfTsJ09kPVu268qptiFrEwC4E30ls/OiK+MCyuhksrPtHiZXbO 5Nsg== X-Gm-Message-State: AODbwcDGKz/v0cW0iuoAFj7d7jy/jvcdsWaB/onGWx2D9gYdnpcFCnkJ YUp93clWrrvAXXE8bH4= X-Received: by 10.55.166.137 with SMTP id p131mr4302523qke.132.1495833284953; Fri, 26 May 2017 14:14:44 -0700 (PDT) Received: from rtp-cpignata-8913.cisco.com ([173.38.117.66]) by smtp.gmail.com with ESMTPSA id y56sm1275858qty.51.2017.05.26.14.14.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 May 2017 14:14:44 -0700 (PDT) Sender: Carlos Pignataro Content-Type: multipart/alternative; boundary="Apple-Mail=_C691818F-D3A2-4F9E-93BF-FAF15FC5BC9F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carlos Pignataro In-Reply-To: Date: Fri, 26 May 2017 17:14:43 -0400 Cc: "n.leymann@telekom.de" , mpls , "mpls-chairs@ietf.org" X-Mao-Original-Outgoing-Id: 517526083.839503-a9db964ff1a76c40da890ab6935c22bb Message-Id: <18E37CDD-D0D0-4BE3-99AF-44E5BADCAD5D@cisco.com> References: To: Greg Mirsky X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [mpls] WGLC for draft-ietf-mpls-bfd-directed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 21:14:48 -0000 --Apple-Mail=_C691818F-D3A2-4F9E-93BF-FAF15FC5BC9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greg, Anytime =E2=80=94 I wanted to reply so that there was at least one = non-author message about it. You and I have very different views on = what is a technical concern. For example this comment describes a specific technical concern: * =E2=80=9CExactly one sub-TLV MUST be included in the Reverse Path = TLV.=E2=80=9D Basically, the document says that the return path cannot have a FEC = Stack (e.g., nested FECs or a Tunnel or...). It is not clear why.=20 Basically it flattens MPLS to one label on return. In contrast, RFC 7110 allows for multiple FECs: Reply Path: It is used to describe the return path that an echo reply will be send along. It is variable in length and can contain zero, one or more Target FEC sub-TLVs [RFC4379]. A second technical issue: * =E2=80=9C This approach assumes that FECs do not ever change=E2=80=A6.=E2= =80=9D I find the response of =E2=80=9Cpunt it to the operator=E2=80=9D = complete unsatisfactory. We are trying to reduce OpEx, not build tools = that put the burden on operators. Basically, the root cause stems from the fact that RFC 7110 uses a = return path construct for a response immediate sent and elicited by the = reply, whereas your draft attempts to mimic the method but for a = protocol in which there is a bootstrapping, and after that, no mechanism = for update although the underlying network can change. This proposal as it is right now, basically makes an existing protocol = more brittle than it was before, and the network operations more = complex. Another technical concern, the description in Section 4. And then = there=E2=80=99s also the indication of IPR but a conflicting message = from one of the authors. Please note I was not making specific suggestions =E2=80=94 technical or = editorial. Just pointing out that there are technical issues with this = document. Technically. =E2=80=94 Carlos. > On May 25, 2017, at 10:26 AM, Greg Mirsky > wrote: >=20 > Dear Carlos, > thank you for taking two minutes to write the message. =46rom it all = I've found only one concern that, in my view, may be considered = technical. Thus I'll bring it to the forefront and will try to explain = how the situation may be handled. > You wrote: > 1. This approach assumes that FECs do not ever change. A reverse path = is instructed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what = happens if paths change?!? If a return tunnel is suddenly deleted from = underneath? > I consider it to be the case that should be handled by properly = operating the network rather then auto-discovering it and = auto-recovering. I hardly believe that a tunnel may be "suddenly = deleted" without the operator being aware of that. And if that is the = case, then the operator may proactively re-signal return path for those = BFD sessions that may be affected by the planned change in the network. = Even more, BFD sessions to decrease chance of receiving false negative = during period the remote BFD peer switches to new recommended path. >=20 > Thank you for the editorial suggestion to consider renaming the = section. We'll discuss and share our proposal to improve the wording. >=20 > Others may decide to respond to the rest of your message. There's = nothing of technical substance, as I see it. >=20 > Regards, > Greg >=20 > On Wed, May 24, 2017 at 11:36 PM, Carlos Pignataro (cpignata) = > wrote: > Nic, >=20 > I do not support advancing this document in its current form. It has = many technical deficiencies, some of which are listed and described = below. >=20 > I also believe your WGLC note should have been much more detailed and = comprehensive. >=20 > I believe this is the 3rd WGLC on this document, correct? (That gives = a new meaning to =E2=80=9CLast=E2=80=9D :-) If so, that should have also = been clarified in the WGLC email, with a much more clear explanation and = comprehensive set of details of how concerns were discussed and = addressed. >=20 > > The authors have updated draft-ietf-mpls-bfd-directed and think that = the draft is ready for WGLC. >=20 > I am very concerned that there was no discussion on the list of any of = those changes. The authors believe the draft is ready =E2=80=94 do you = believe so as well, Nic? Was a shepherd review performed and is that = available? >=20 > > Please note that draft-ietf-mpls-bfd-directed did not pass the > > previous working group last call, because of an IPR disclosure: >=20 > Is that the 1st or 2nd WGLC? I think this statement is an = oversimplification. There were many technical concerns. >=20 > Anyway, scanning through this document, some technical issues: >=20 > 1. This approach assumes that FECs do not ever change. A reverse path = is instructed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what = happens if paths change?!? If a return tunnel is suddenly deleted from = underneath? > 2. =E2=80=9CCase of MPLS Data Plane=E2=80=9D =E2=80=94 is there any = other non-MPLS case? This points to the fact of lack of review and = editorial sloppiness. > 3. =E2=80=9CExactly one sub-TLV MUST be included in the Reverse Path = TLV.=E2=80=9D =E2=80=94 so basically, no Tunnels can be return path?!? > 4. The =E2=80=9CUse Case Scenario=E2=80=9D uses 2119 language in a way = that does not make sense. >=20 > Please note, this is not an exhaustive list, but a 2 minute scan = through the doc. >=20 > Thanks! >=20 > Carlos. >=20 >=20 > > On May 24, 2017, at 2:33 AM, n.leymann@telekom.de = > wrote: > > > > Dear Working Group, > > > > The authors have updated draft-ietf-mpls-bfd-directed and think that = the draft is ready for WGLC. > > Therefore this e-mail starts a WG LC which will end on the 7th of = June. > > > > Please note that draft-ietf-mpls-bfd-directed did not pass the > > previous working group last call, because of an IPR disclosure: > > > > https://datatracker.ietf.org/ipr/2892/ = > > > > The authors have updated the draft and they believe that the IPR is = no longer in scope. > > Please notify the list if you still think the IPR is an issue and = please state if you think it > > is OK to continue with the publication of this document. > > > > Best regards > > > > Nic > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls = >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls = >=20 --Apple-Mail=_C691818F-D3A2-4F9E-93BF-FAF15FC5BC9F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Greg,

Anytime =E2=80=94 I wanted to reply so that there was at = least one non-author message about it.  You and I have very = different views on what is a technical concern.

For example this comment describes a = specific technical concern:
* =E2=80=9CExactly one = sub-TLV MUST be included in the Reverse Path TLV.=E2=80=9D

Basically, the document = says that the return path cannot have a FEC Stack (e.g., nested FECs or = a Tunnel or...). It is not clear why. 
Basically= it flattens MPLS to one label on return.

In contrast, RFC 7110 allows for = multiple FECs:

   Reply Path:  It is used to = describe the return path that an echo
    =   reply will be send along.  It is variable in length and = can
      contain zero, one or more = Target FEC sub-TLVs [RFC4379].

A second technical issue:
* =E2=80=9C This approach assumes that FECs do not ever = change=E2=80=A6.=E2=80=9D

I find the response of =E2=80=9Cpunt it to the operator=E2=80=9D= complete unsatisfactory. We are trying to reduce OpEx, not build tools = that put the burden on operators.

Basically, the root cause stems from = the fact that RFC 7110 uses a return path construct for a response = immediate sent and elicited by the reply, whereas your draft attempts to = mimic the method but for a protocol in which there is a bootstrapping, = and after that, no mechanism for update although the underlying network = can change.

This= proposal as it is right now, basically makes an existing protocol more = brittle than it was before, and the network operations more = complex.

Another= technical concern, the description in Section 4. And then there=E2=80=99s= also the indication of IPR but a conflicting message from one of the = authors.

Please = note I was not making specific suggestions =E2=80=94 technical or = editorial. Just pointing out that there are technical issues with this = document.

Technically.

=E2=80=94 Carlos.

On = May 25, 2017, at 10:26 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Dear Carlos,
thank = you for taking two minutes to write the message. =46rom it all I've = found only one concern that, in my view, may be considered technical. = Thus I'll bring it to the forefront and will try to explain how the = situation may be handled.
You wrote:
1. This approach = assumes that FECs do not ever change. A reverse path is instructed at = setup/bootstrap with MPLS LSP Ping =E2=80=94 what happens if paths = change?!? If a return tunnel is suddenly deleted from = underneath?
I consider it to be the case that = should be handled by properly operating the network rather then = auto-discovering it and auto-recovering. I hardly believe that a tunnel = may be "suddenly deleted" without the operator being aware of that. And = if that is the case, then the operator may proactively re-signal return = path for those BFD sessions that may be affected by the planned change = in the network. Even more, BFD sessions to decrease chance of receiving = false negative during period the remote BFD peer switches to new = recommended path.

Thank you for the = editorial suggestion to consider renaming the section. We'll discuss and = share our proposal to improve the wording.

Others may decide to respond to the rest of your message. = There's nothing of technical substance, as I see it.

Regards,
Greg

On Wed, = May 24, 2017 at 11:36 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Nic,

I do not support advancing this document in its current form. It has = many technical deficiencies, some of which are listed and described = below.

I also believe your WGLC note should have been much more detailed and = comprehensive.

I believe this is the 3rd WGLC on this document, correct? (That gives a = new meaning to =E2=80=9CLast=E2=80=9D :-) If so, that should have also = been clarified in the WGLC email, with a much more clear explanation and = comprehensive set of details of how concerns were discussed and = addressed.

> The authors have updated draft-ietf-mpls-bfd-directed and think = that the draft is ready for WGLC.

I am very concerned that there was no discussion on the list of = any of those changes.  The authors believe the draft is ready =E2=80=94= do you believe so as well, Nic? Was a shepherd review performed and is = that available?

> Please note that draft-ietf-mpls-bfd-directed did not pass the
> previous working group last call, because of an IPR disclosure:

Is that the 1st or 2nd WGLC? I think this statement is an = oversimplification. There were many technical concerns.

Anyway, scanning through this document, some technical issues:

1. This approach assumes that FECs do not ever change. A reverse path is = instructed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what happens = if paths change?!? If a return tunnel is suddenly deleted from = underneath?
2. =E2=80=9CCase of MPLS Data Plane=E2=80=9D =E2=80=94 is there any = other non-MPLS case? This points to the fact of lack of review and = editorial sloppiness.
3. =E2=80=9CExactly one sub-TLV MUST be included in the Reverse Path = TLV.=E2=80=9D =E2=80=94 so basically, no Tunnels can be return = path?!?
4. The =E2=80=9CUse Case Scenario=E2=80=9D uses 2119 language in a way = that does not make sense.

Please note, this is not an exhaustive list, but a 2 minute scan through = the doc.

Thanks!

Carlos.


> On May 24, 2017, at 2:33 AM, n.leymann@telekom.de <N.Leymann@telekom.de> wrote:
>
> Dear Working Group,
>
> The authors have updated draft-ietf-mpls-bfd-directed and think = that the draft is ready for WGLC.
> Therefore this e-mail starts a WG LC which will end on the 7th of = June.
>
> Please note that draft-ietf-mpls-bfd-directed did not pass the
> previous working group last call, because of an IPR disclosure:
>
>   https://datatracker.ietf.org/ipr/2892/
>
> The authors have updated the draft and they believe that the IPR is = no longer in scope.
> Please notify the list if you still think the IPR is an issue and = please state if you think it
> is OK to continue with the publication of this document.
>
>   Best regards
>
>     Nic
>
>
> = _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls

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


= --Apple-Mail=_C691818F-D3A2-4F9E-93BF-FAF15FC5BC9F-- From nobody Tue May 30 21:29:58 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129C812956B; Tue, 30 May 2017 21:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A25pHxPD7OmZ; Tue, 30 May 2017 21:29:54 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 28D45129B4C; Tue, 30 May 2017 21:29:53 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id o12so9312393iod.3; Tue, 30 May 2017 21:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vIpN6NuOAg+1gj5dAhyaEePJpGe/aksfkZfRdFRkIp0=; b=O00LiUD5FYhvBWT4YulTDMiYhzsYSlCPI/a/UN9Yhj32ovVEcnzXB3yCVBPt9syhvv gSzY6dc3Z7uzBlGx/lDRUv2TFXJNqtHxm0FGb6c+IxQjvMQVT2OchDY5VZSFjvneQ7Gk XvOHnlcfYUNsAaK3lksw5raMAofDbNKTkvJuPP5wuqNCX1JeVW5rFDdZaK/QxxiehZDg EWrZ8uzoyERrSIwtsSH07b8czRR5q6ki9spaSx9JXJwalLTnARsEApBuFEPnCTK7bv69 rEYYvEtM/95kGy2yrTjkQNYEm8GPmq9eZRhZxHTOsXULLGdyz1Seqcr9dyJZIqwlft20 9osA== 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=vIpN6NuOAg+1gj5dAhyaEePJpGe/aksfkZfRdFRkIp0=; b=D1+oB3NqIf0lka6PG5bUYCQjEXzzf4QhcY7WBGOTqx1E8JGesR/c1TpTdqpAhmY+uS xqI3oCiDiHA/c+GoJP4r0fVv9eBm7pD+6/5CPNPFiDCDVDKuMMKNLglHHz69SZKt326/ 16GnqUV2wgJMh2KqzApnRh7TFq46OS/KhGHPpPjH0j1JUuy/Mddmah+TZoiKHs4t+wDU iyF+rPmOdM5VbkMCWpARDRLYr4JGPHWqua4lhIA+7zwp4iiDjVxs2EfqeSTyfIA5DZIG fQczoWmob1iwgXMIjXeyvZflIm8nALuMWzoTfQptUtW3/ZGTdVAna3S3exWigOoWdOd+ 1nqg== X-Gm-Message-State: AODbwcBxjDcgx099NWVeOL/7rvAIJSpPyYsNpd7JCRhHZH5Bt2tUQouL t7JzlgVjlZ0aoUjY1kBEjgkxqseAiw== X-Received: by 10.157.82.87 with SMTP id q23mr10271477otg.52.1496204993147; Tue, 30 May 2017 21:29:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.246 with HTTP; Tue, 30 May 2017 21:29:52 -0700 (PDT) In-Reply-To: <18E37CDD-D0D0-4BE3-99AF-44E5BADCAD5D@cisco.com> References: <18E37CDD-D0D0-4BE3-99AF-44E5BADCAD5D@cisco.com> From: Greg Mirsky Date: Wed, 31 May 2017 12:29:52 +0800 Message-ID: To: Carlos Pignataro Cc: "n.leymann@telekom.de" , mpls , "mpls-chairs@ietf.org" Content-Type: multipart/alternative; boundary="f403043c4bec20bb5b0550ca5fac" Archived-At: Subject: Re: [mpls] WGLC for draft-ietf-mpls-bfd-directed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 04:29:57 -0000 --f403043c4bec20bb5b0550ca5fac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos, we clearly have different interpretation of what operational simplicity means. Of course, someone may come up with mechanism to monitor the reverse path of the BFD session that was set according to BFD Reverse Path TLV but I don't see that neither necessary, nor helpful because that may hide from an operator real failure. Regarding the number of sub-TLVs in BFD Reverse Path TLV. I can assume that authors followed in the path of reasoning set by RFC 4379 (now RFC 8029). RFC 8029 defines procedures to verify correlation between the MPLS data plane and control plane. In example in Section 3.2 we see that listing all FECs is optional and it is perfectly valid to include single FEC that characterizes the outer MPLS label. Using the same approach in RFC 7110, in my opinion, was not only right but necessary. But for case of controlling the reverse direction of a BFD session that seems unnecessary. Additionally, RFC 7110 allows operator to pass the right for the final selection of the return path for Echo Reply to the egress node, to the responder. That may be useful for Echo Request/Reply as the egress returns information on how it concluded the selection process based on received Reply Path TLV. For BFD Reverse Path TLV, egress uses Return Code and Return Sub-code in Echo Reply to indicate whether the requested path is available to the egress node. If the path is not available, then the operator may send another request in LSP Ping using BFD Reverse Path TLV. Regards, Greg On Sat, May 27, 2017 at 5:14 AM, Carlos Pignataro wrote: > Greg, > > Anytime =E2=80=94 I wanted to reply so that there was at least one non-au= thor > message about it. You and I have very different views on what is a > technical concern. > > For example this comment describes a specific technical concern: > * =E2=80=9CExactly one sub-TLV MUST be included in the Reverse Path TLV.= =E2=80=9D > > Basically, the document says that the return path cannot have a FEC Stack > (e.g., nested FECs or a Tunnel or...). It is not clear why. > Basically it flattens MPLS to one label on return. > > In contrast, RFC 7110 allows for multiple FECs: > > Reply Path: It is used to describe the return path that an echo > reply will be send along. It is variable in length and can > contain zero, one or more Target FEC sub-TLVs [RFC4379]. > > A second technical issue: > * =E2=80=9C This approach assumes that FECs do not ever change=E2=80=A6.= =E2=80=9D > > I find the response of =E2=80=9Cpunt it to the operator=E2=80=9D complete= unsatisfactory. > We are trying to reduce OpEx, not build tools that put the burden on > operators. > > Basically, the root cause stems from the fact that RFC 7110 uses a return > path construct for a response immediate sent and elicited by the reply, > whereas your draft attempts to mimic the method but for a protocol in whi= ch > there is a bootstrapping, and after that, no mechanism for update althoug= h > the underlying network can change. > > This proposal as it is right now, basically makes an existing protocol > more brittle than it was before, and the network operations more complex. > > Another technical concern, the description in Section 4. And then there= =E2=80=99s > also the indication of IPR but a conflicting message from one of the > authors. > > Please note I was not making specific suggestions =E2=80=94 technical or > editorial. Just pointing out that there are technical issues with this > document. > > Technically. > > =E2=80=94 Carlos. > > On May 25, 2017, at 10:26 AM, Greg Mirsky wrote: > > Dear Carlos, > thank you for taking two minutes to write the message. From it all I've > found only one concern that, in my view, may be considered technical. Thu= s > I'll bring it to the forefront and will try to explain how the situation > may be handled. > You wrote: > 1. This approach assumes that FECs do not ever change. A reverse path is > instructed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what happens i= f paths > change?!? If a return tunnel is suddenly deleted from underneath? > I consider it to be the case that should be handled by properly operating > the network rather then auto-discovering it and auto-recovering. I hardly > believe that a tunnel may be "suddenly deleted" without the operator bein= g > aware of that. And if that is the case, then the operator may proactively > re-signal return path for those BFD sessions that may be affected by the > planned change in the network. Even more, BFD sessions to decrease chance > of receiving false negative during period the remote BFD peer switches to > new recommended path. > > Thank you for the editorial suggestion to consider renaming the section. > We'll discuss and share our proposal to improve the wording. > > Others may decide to respond to the rest of your message. There's nothing > of technical substance, as I see it. > > Regards, > Greg > > On Wed, May 24, 2017 at 11:36 PM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Nic, >> >> I do not support advancing this document in its current form. It has man= y >> technical deficiencies, some of which are listed and described below. >> >> I also believe your WGLC note should have been much more detailed and >> comprehensive. >> >> I believe this is the 3rd WGLC on this document, correct? (That gives a >> new meaning to =E2=80=9CLast=E2=80=9D :-) If so, that should have also b= een clarified in >> the WGLC email, with a much more clear explanation and comprehensive set= of >> details of how concerns were discussed and addressed. >> >> > The authors have updated draft-ietf-mpls-bfd-directed and think that >> the draft is ready for WGLC. >> >> I am very concerned that there was no discussion on the list of any of >> those changes. The authors believe the draft is ready =E2=80=94 do you = believe so >> as well, Nic? Was a shepherd review performed and is that available? >> >> > Please note that draft-ietf-mpls-bfd-directed did not pass the >> > previous working group last call, because of an IPR disclosure: >> >> Is that the 1st or 2nd WGLC? I think this statement is an >> oversimplification. There were many technical concerns. >> >> Anyway, scanning through this document, some technical issues: >> >> 1. This approach assumes that FECs do not ever change. A reverse path is >> instructed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what happens = if paths >> change?!? If a return tunnel is suddenly deleted from underneath? >> 2. =E2=80=9CCase of MPLS Data Plane=E2=80=9D =E2=80=94 is there any othe= r non-MPLS case? This >> points to the fact of lack of review and editorial sloppiness. >> 3. =E2=80=9CExactly one sub-TLV MUST be included in the Reverse Path TLV= .=E2=80=9D =E2=80=94 so >> basically, no Tunnels can be return path?!? >> 4. The =E2=80=9CUse Case Scenario=E2=80=9D uses 2119 language in a way t= hat does not make >> sense. >> >> Please note, this is not an exhaustive list, but a 2 minute scan through >> the doc. >> >> Thanks! >> >> Carlos. >> >> >> > On May 24, 2017, at 2:33 AM, n.leymann@telekom.de >> wrote: >> > >> > Dear Working Group, >> > >> > The authors have updated draft-ietf-mpls-bfd-directed and think that >> the draft is ready for WGLC. >> > Therefore this e-mail starts a WG LC which will end on the 7th of June= . >> > >> > Please note that draft-ietf-mpls-bfd-directed did not pass the >> > previous working group last call, because of an IPR disclosure: >> > >> > https://datatracker.ietf.org/ipr/2892/ >> > >> > The authors have updated the draft and they believe that the IPR is no >> longer in scope. >> > Please notify the list if you still think the IPR is an issue and >> please state if you think it >> > is OK to continue with the publication of this document. >> > >> > Best regards >> > >> > Nic >> > >> > >> > _______________________________________________ >> > mpls mailing list >> > mpls@ietf.org >> > https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > > --f403043c4bec20bb5b0550ca5fac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,
we clearly have different interpretation of= what operational simplicity means. Of course, someone may come up with mec= hanism to monitor the reverse path of the BFD session that was set accordin= g to BFD Reverse Path TLV but I don't see that neither necessary, nor h= elpful because that may hide from an operator real failure.
R= egarding the number of sub-TLVs in BFD Reverse Path TLV. I can assume that = authors followed in the path of reasoning set by RFC 4379 (now RFC 8029). R= FC 8029 defines procedures to verify correlation between the MPLS data plan= e and control plane. In example in Section 3.2 we see that listing all FECs= is optional and it is perfectly valid to include single FEC that character= izes the outer MPLS label. Using the same approach in RFC 7110, in my opini= on, was not only right but necessary. But for case of controlling the rever= se direction of a BFD session that seems unnecessary.
Additionall= y, RFC 7110 allows operator to pass the right for the final selection of th= e return path for Echo Reply to the egress node, to the responder. That may= be useful for Echo Request/Reply as the egress returns information on how = it concluded the selection process based on received Reply Path TLV. For BF= D Reverse Path TLV, egress uses Return Code and Return Sub-code in Echo Rep= ly to indicate whether the requested path is available to the egress node. = If the path is not available, then the operator may send another request in= LSP Ping using BFD Reverse Path TLV.

Regards,
Greg

On Sat, May 27, 2017 at 5:14 AM, Carlos Pignataro &= lt;cpignata@cisco.c= om> wrote:
Greg,

Anytime =E2=80=94 I wanted to = reply so that there was at least one non-author message about it.=C2=A0 You= and I have very different views on what is a technical concern.
=
For example this comment describes a specific technical conc= ern:
* =E2=80=9CExactly one sub-TLV MUST be included in the Rever= se Path TLV.=E2=80=9D

Basically, the document says= that the return path cannot have a FEC Stack (e.g., nested FECs or a Tunne= l or...). It is not clear why.=C2=A0
Basically it flattens MPLS t= o one label on return.

In contrast, RFC 7110 allow= s for multiple FECs:

=C2=A0 =C2=A0Reply Path:= =C2=A0It is used to describe the return path that an echo
=C2=A0= =C2=A0 =C2=A0 reply will be send along.=C2=A0 It is variable in length and= can
=C2=A0 =C2=A0 =C2=A0 contain zero, one or more Target FEC su= b-TLVs [RFC4379].

A second technical issue:<= /div>
* =E2=80=9C This approach assumes that FECs do not ever change=E2= =80=A6.=E2=80=9D

I find the response of =E2=80=9Cp= unt it to the operator=E2=80=9D complete unsatisfactory. We are trying to r= educe OpEx, not build tools that put the burden on operators.
Basically, the root cause stems from the fact that RFC 7110 use= s a return path construct for a response immediate sent and elicited by the= reply, whereas your draft attempts to mimic the method but for a protocol = in which there is a bootstrapping, and after that, no mechanism for update = although the underlying network can change.

This p= roposal as it is right now, basically makes an existing protocol more britt= le than it was before, and the network operations more complex.
<= br>
Another technical concern, the description in Section 4. And = then there=E2=80=99s also the indication of IPR but a conflicting message f= rom one of the authors.

Please note I was not maki= ng specific suggestions =E2=80=94 technical or editorial. Just pointing out= that there are technical issues with this document.

Technically.
=E2=80=94 Carlos.

On May 25, 2017, at 10:26 AM, Gr= eg Mirsky <gr= egimirsky@gmail.com> wrote:

Dear Carlos,
thank you= for taking two minutes to write the message. From it all I've found on= ly one concern that, in my view, may be considered technical. Thus I'll= bring it to the forefront and will try to explain how the situation may be= handled.
You wrote:
1= . This approach assumes that FECs do not ever change. A reverse path is ins= tructed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what happens if pat= hs change?!? If a return tunnel is suddenly deleted from underneath?=
I consider it to be the cas= e that should be handled by properly operating the network rather then auto= -discovering it and auto-recovering. I hardly believe that a tunnel may be = "suddenly deleted" without the operator being aware of that. And = if that is the case, then the operator may proactively re-signal return pat= h for those BFD sessions that may be affected by the planned change in the = network. Even more, BFD sessions to decrease chance of receiving false nega= tive during period the remote BFD peer switches to new recommended path.

Thank you for the editorial suggestion to consi= der renaming the section. We'll discuss and share our proposal to impro= ve the wording.

Others may decide to respond = to the rest of your message. There's nothing of technical substance, as= I see it.

Regards,
Greg
=
On Wed, May 24, 2017 at 11:36 PM, Carlos Pig= nataro (cpignata) <cpignata@cisco.com> wrote:
Nic,

I do not support advancing this document in its current form. It has many t= echnical deficiencies, some of which are listed and described below.

I also believe your WGLC note should have been much more detailed and compr= ehensive.

I believe this is the 3rd WGLC on this document, correct? (That gives a new= meaning to =E2=80=9CLast=E2=80=9D :-) If so, that should have also been cl= arified in the WGLC email, with a much more clear explanation and comprehen= sive set of details of how concerns were discussed and addressed.

> The authors have updated draft-ietf-mpls-bfd-directed and think that t= he draft is ready for WGLC.

I am very concerned that there was no discussion on the list of any = of those changes.=C2=A0 The authors believe the draft is ready =E2=80=94 do= you believe so as well, Nic? Was a shepherd review performed and is that a= vailable?

> Please note that draft-ietf-mpls-bfd-directed did not pass the
> previous working group last call, because of an IPR disclosure:

Is that the 1st or 2nd WGLC? I think this statement is an oversimpli= fication. There were many technical concerns.

Anyway, scanning through this document, some technical issues:

1. This approach assumes that FECs do not ever change. A reverse path is in= structed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what happens if pa= ths change?!? If a return tunnel is suddenly deleted from underneath?
2. =E2=80=9CCase of MPLS Data Plane=E2=80=9D =E2=80=94 is there any other n= on-MPLS case? This points to the fact of lack of review and editorial slopp= iness.
3. =E2=80=9CExactly one sub-TLV MUST be included in the Reverse Path TLV.= =E2=80=9D =E2=80=94 so basically, no Tunnels can be return path?!?
4. The =E2=80=9CUse Case Scenario=E2=80=9D uses 2119 language in a way that= does not make sense.

Please note, this is not an exhaustive list, but a 2 minute scan through th= e doc.

Thanks!

Carlos.


> On May 24, 2017, at 2:33 AM, n.leymann@telekom.de <N.Leymann@telekom.de> wrote:
>
> Dear Working Group,
>
> The authors have updated draft-ietf-mpls-bfd-directed and think that t= he draft is ready for WGLC.
> Therefore this e-mail starts a WG LC which will end on the 7th of June= .
>
> Please note that draft-ietf-mpls-bfd-directed did not pass the
> previous working group last call, because of an IPR disclosure:
>
>=C2=A0 =C2=A0https://datatracker.ietf.org/ipr/2892/
>
> The authors have updated the draft and they believe that the IPR is no= longer in scope.
> Please notify the list if you still think the IPR is an issue and plea= se state if you think it
> is OK to continue with the publication of this document.
>
>=C2=A0 =C2=A0Best regards
>
>=C2=A0 =C2=A0 =C2=A0Nic
>
>
> ____________________________________________= ___
> mpls mailing list
> mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


--f403043c4bec20bb5b0550ca5fac-- From nobody Tue May 30 22:33:22 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5AA1294F0; Tue, 30 May 2017 22:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWsw5LPuBHsb; Tue, 30 May 2017 22:33:18 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 9DE101272E1; Tue, 30 May 2017 22:33:18 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id l18so2892896oig.2; Tue, 30 May 2017 22:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1hBoRf7X47F42iubZDIgM5LTbp+j+KMLOFDYcRsIK+Q=; b=Lk40M0dkrf98S5i4ez/fKwiqvBq7RudArwDe2SDVQ6DcFLiznz2X/NNZ5QWha+VYcT D8pJ+4eGUr0FQqm0Mq2vldxSptNqRMEtzrlJW/mFhmUNUJmKZp9cs680B4bWUmpaJfLd wTc8/zzLkRAlwtzc++7MBcHiQ4dxZ+v0dy8WRLGfMCPv9iZgjnYx+0DrCtSuFBvrbyS+ IFHF9Qxvi88+B+bBZa7dw1cq2TGC//2dPPeO87fBSCqNTUXMPpXVHqW63Ke8hZQgPY23 0akvggDR/wq3GHwKO50s+TGNrj/MTmMSSAfIG94zfd+ZoD3OXXylFhcbz7zVWtMcLdkv WJBw== 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=1hBoRf7X47F42iubZDIgM5LTbp+j+KMLOFDYcRsIK+Q=; b=LhT+FAXS7c4WJ65Ys75Y/8HuV5a/fFJgP5A/M81MCQMvtGHJbHGCAbOyuuvd9K8fPo ++DVCkP0PIjsWgmSZnmB3PaDD9ZuhRbRlkVjCV0J7PddnNKR2djX/c9eF+dXzolD/erT cIRtJZv3PeDkoWf7k20av9kwnO+lRllC1fL1yqROy3EYD0AGGotWlE2saIORfnPm/wvK EjOvlQIaaXL61S19P35ErMk5HNRHNdx/IrRJiUQwbriwgvGTh7v0BLTnamhBFUx79anw yWXknNtPIVwU2lY2/Hv5UNIWJ237YTVjncfeETvWOIBC65Y+wOfYxjNvUsEeAcdoOWmX +THA== X-Gm-Message-State: AODbwcCw3/98ChyQqHqZjWqI5K3HZjO6jOOS38cvfvVPRDGaln38l4OS X0+7xBA72nWXyJJHdNCK0bbdSV/q7Q== X-Received: by 10.157.82.87 with SMTP id q23mr10343542otg.52.1496208798013; Tue, 30 May 2017 22:33:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.246 with HTTP; Tue, 30 May 2017 22:33:17 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Wed, 31 May 2017 13:33:17 +0800 Message-ID: To: "n.leymann@telekom.de" Cc: "mpls@ietf.org" , mpls-chairs@ietf.org Content-Type: multipart/alternative; boundary="f403043c4becea93860550cb41e1" Archived-At: Subject: Re: [mpls] WGLC for draft-ietf-mpls-bfd-directed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 05:33:20 -0000 --f403043c4becea93860550cb41e1 Content-Type: text/plain; charset="UTF-8" Hi Carlos, after more consideration realized that you have brought up valid concern and I propose the following change to address it: - in section 3.1.1 OLD TEXT Exactly one sub-TLV MUST be included in the Reverse Path TLV. If more than one sub-TLV is present in the Reverse Path TLV, then, in order to avoid ambiguity of which of TLVs to use, the egress BFD peer MUST send Echo Reply with the received Reverse Path TLVs and set the Return Code to "Too Many TLVs Detected" Section 3.2. NEW TEXT One or more sub-TLVs MAY be included in the BFD Reverse Path TLV.The BFD Reverse Path TLV MAY list a stack of FECs that directly corresponds to the label stack. - section 3.2 - remove the first bullet describing return code "Too Many TLVs Detected" - section 5.2 - remove request to allocate return code value for "Too Many TLVs Detected" Hope these changes will address your concern. Regards, Greg On Wed, May 24, 2017 at 9:22 PM, Greg Mirsky wrote: > Hi Nick, > I don't know of any IETF regulations or rules that prescribe to prevent > progressing a document based on type of IPR Disclosure. I'd note that > authors did their best to ensure that appropriate IPR Disclosures were > filed as soon as possible. I believe that there were no concerns regarding > timing of the IPR Disclosures related to earlier versions of the draft. > > Regards, > Greg > > On Wed, May 24, 2017 at 5:33 PM, wrote: > >> Dear Working Group, >> >> The authors have updated draft-ietf-mpls-bfd-directed and think that the >> draft is ready for WGLC. >> Therefore this e-mail starts a WG LC which will end on the 7th of June. >> >> Please note that draft-ietf-mpls-bfd-directed did not pass the >> previous working group last call, because of an IPR disclosure: >> >> *https://datatracker.ietf.org/ipr/2892/* >> >> >> The authors have updated the draft and they believe that the IPR is no >> longer in scope. >> Please notify the list if you still think the IPR is an issue and please >> state if you think it >> is OK to continue with the publication of this document. >> >> Best regards >> >> Nic >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> > --f403043c4becea93860550cb41e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, May= 24, 2017 at 9:22 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Nick,
I = don't know of any IETF regulations or rules that prescribe to prevent p= rogressing a document based on type of IPR Disclosure. I'd note that au= thors did their best to ensure that appropriate IPR Disclosures were filed = as soon as possible. I believe that there were no concerns regarding timing= of the IPR Disclosures related to earlier versions of the draft.

Regards,
Greg

On Wed, May 24, 20= 17 at 5:33 PM, <N.Leymann@telekom.de> wrote:
Dear Working Group,
=C2=A0
The authors have updated draft-ietf-mpls-bfd-directed and think that t= he draft is ready for WGLC.
Therefore this e-mail starts a WG LC which will end on the 7th of June= .
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Please note that draft-ietf-mpls-bfd-directed did not pass the
previous working group last call, because of an IPR disclosure:
=C2=A0
=C2=A0
The authors have updated the draft and they believe that the IPR is no= longer in scope.
Please notify the list if you still think the IPR is an issue and plea= se state if you think it
is OK to continue with the publication of this document.
=C2=A0
=C2=A0 Best regards
=C2=A0
=C2=A0=C2=A0=C2=A0 Nic
=C2= =A0
=C2= =A0

_____________________________________= __________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls



--f403043c4becea93860550cb41e1-- From nobody Wed May 31 04:29:58 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC8B12EA94; Wed, 31 May 2017 04:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O3APiAIt5At; Wed, 31 May 2017 04:29:53 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6766512EA8C; Wed, 31 May 2017 04:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23781; q=dns/txt; s=iport; t=1496230193; x=1497439793; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MPHEVLgTgmT6DZIAI6Zv3HrYiVulFYBaxKusoH06Nfo=; b=Hq2Xt9p7vC0ZcMg4utVyeTEp23vjxJa2MTfq1Y07IQwHMtrFEKjzgP1f K/wJGSuo8soPO9OpLOXeakXMlHQNffdYO+PLt4kT5aBX7eHJr0k7q3NHY ulA7i9jKds34b16RL5vmN/526eH5jEfZA53ra9Calrg2VL9PKQVeT9iNt g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiAABxqC5Z/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm48K2IzWo4KkU4hcoc3jVCCDyEBCoV4AoJdPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUYAQEBAQIBAQFsCwULAgEIGCcHIQYLFBEBAQQOBYlGTAMNCBCuHoczDYQRA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGYYFgKwuBXVg0gliBYhIBIzGDCYIxBZZ?= =?us-ascii?q?5hm87AYcfhzCEWIIGhTyKNYkBgjGJGwEfOH8LdBVGEgGENzkcgWIBdoclgi4BA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.38,423,1491264000"; d="scan'208,217";a="428758535" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 May 2017 11:29:52 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v4VBTp63004622 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 May 2017 11:29:51 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 May 2017 07:29:50 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 31 May 2017 07:29:50 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: "n.leymann@telekom.de" , mpls , "mpls-chairs@ietf.org" Thread-Topic: [mpls] WGLC for draft-ietf-mpls-bfd-directed Thread-Index: AdLUcMggDQBvyYSLQg6+G4R+EOGYRgAVEiEAAC/YdAAAQIsngADYXPYAAAZJJV8= Date: Wed, 31 May 2017 11:29:50 +0000 Message-ID: References: <18E37CDD-D0D0-4BE3-99AF-44E5BADCAD5D@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_C046D750C9344890A65C001951104E68ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] WGLC for draft-ietf-mpls-bfd-directed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 11:29:57 -0000 --_000_C046D750C9344890A65C001951104E68ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Greg, Thanks for the response! - even if it doesn't address the technical concern= s. Sorry if I am not being clear enough or I cannot explain it better, but = I do believe there are major unresolved technical issues. To recap, this is just my technical opinion, and as my final response to th= is: 1. This draft forbids (in uppercase) the use of a stack in the return path.= The explanation you gave is that "that seems unnecessary". 2. This draft does not specify procedures of what happens if the return spe= cified FEC changes. Your response says "uses Return Code and Return Sub-cod= e in Echo Reply" which is at bootstrap, but not what happens after the BFD = session is up and the path changes (I.e. There's no more MPLS Ping) 3. For some reason you add "someone may come up with mechanism to monitor t= he reverse path of the BFD session" but that's what section 4 is doing. 4. Pushing the operator to make more decisions and take more actions does n= ot simplify. Net-net: makes bfd more brittle (was this run by the BFD WG?) Thanks! Carlos. Sent from my iPad On May 31, 2017, at 12:29 AM, Greg Mirsky > wrote: Hi Carlos, we clearly have different interpretation of what operational simplicity mea= ns. Of course, someone may come up with mechanism to monitor the reverse pa= th of the BFD session that was set according to BFD Reverse Path TLV but I = don't see that neither necessary, nor helpful because that may hide from an= operator real failure. Regarding the number of sub-TLVs in BFD Reverse Path TLV. I can assume that= authors followed in the path of reasoning set by RFC 4379 (now RFC 8029). = RFC 8029 defines procedures to verify correlation between the MPLS data pla= ne and control plane. In example in Section 3.2 we see that listing all FEC= s is optional and it is perfectly valid to include single FEC that characte= rizes the outer MPLS label. Using the same approach in RFC 7110, in my opin= ion, was not only right but necessary. But for case of controlling the reve= rse direction of a BFD session that seems unnecessary. Additionally, RFC 7110 allows operator to pass the right for the final sele= ction of the return path for Echo Reply to the egress node, to the responde= r. That may be useful for Echo Request/Reply as the egress returns informat= ion on how it concluded the selection process based on received Reply Path = TLV. For BFD Reverse Path TLV, egress uses Return Code and Return Sub-code = in Echo Reply to indicate whether the requested path is available to the eg= ress node. If the path is not available, then the operator may send another= request in LSP Ping using BFD Reverse Path TLV. Regards, Greg On Sat, May 27, 2017 at 5:14 AM, Carlos Pignataro > wrote: Greg, Anytime =97 I wanted to reply so that there was at least one non-author mes= sage about it. You and I have very different views on what is a technical = concern. For example this comment describes a specific technical concern: * =93Exactly one sub-TLV MUST be included in the Reverse Path TLV.=94 Basically, the document says that the return path cannot have a FEC Stack (= e.g., nested FECs or a Tunnel or...). It is not clear why. Basically it flattens MPLS to one label on return. In contrast, RFC 7110 allows for multiple FECs: Reply Path: It is used to describe the return path that an echo reply will be send along. It is variable in length and can contain zero, one or more Target FEC sub-TLVs [RFC4379]. A second technical issue: * =93 This approach assumes that FECs do not ever change=85.=94 I find the response of =93punt it to the operator=94 complete unsatisfactor= y. We are trying to reduce OpEx, not build tools that put the burden on ope= rators. Basically, the root cause stems from the fact that RFC 7110 uses a return p= ath construct for a response immediate sent and elicited by the reply, wher= eas your draft attempts to mimic the method but for a protocol in which the= re is a bootstrapping, and after that, no mechanism for update although the= underlying network can change. This proposal as it is right now, basically makes an existing protocol more= brittle than it was before, and the network operations more complex. Another technical concern, the description in Section 4. And then there=92s= also the indication of IPR but a conflicting message from one of the autho= rs. Please note I was not making specific suggestions =97 technical or editoria= l. Just pointing out that there are technical issues with this document. Technically. =97 Carlos. On May 25, 2017, at 10:26 AM, Greg Mirsky > wrote: Dear Carlos, thank you for taking two minutes to write the message. From it all I've fou= nd only one concern that, in my view, may be considered technical. Thus I'l= l bring it to the forefront and will try to explain how the situation may b= e handled. You wrote: 1. This approach assumes that FECs do not ever change. A reverse path is in= structed at setup/bootstrap with MPLS LSP Ping =97 what happens if paths ch= ange?!? If a return tunnel is suddenly deleted from underneath? I consider it to be the case that should be handled by properly operating t= he network rather then auto-discovering it and auto-recovering. I hardly be= lieve that a tunnel may be "suddenly deleted" without the operator being aw= are of that. And if that is the case, then the operator may proactively re-= signal return path for those BFD sessions that may be affected by the plann= ed change in the network. Even more, BFD sessions to decrease chance of rec= eiving false negative during period the remote BFD peer switches to new rec= ommended path. Thank you for the editorial suggestion to consider renaming the section. We= 'll discuss and share our proposal to improve the wording. Others may decide to respond to the rest of your message. There's nothing o= f technical substance, as I see it. Regards, Greg On Wed, May 24, 2017 at 11:36 PM, Carlos Pignataro (cpignata) > wrote: Nic, I do not support advancing this document in its current form. It has many t= echnical deficiencies, some of which are listed and described below. I also believe your WGLC note should have been much more detailed and compr= ehensive. I believe this is the 3rd WGLC on this document, correct? (That gives a new= meaning to =93Last=94 :-) If so, that should have also been clarified in t= he WGLC email, with a much more clear explanation and comprehensive set of = details of how concerns were discussed and addressed. > The authors have updated draft-ietf-mpls-bfd-directed and think that the = draft is ready for WGLC. I am very concerned that there was no discussion on the list of any of thos= e changes. The authors believe the draft is ready =97 do you believe so as= well, Nic? Was a shepherd review performed and is that available? > Please note that draft-ietf-mpls-bfd-directed did not pass the > previous working group last call, because of an IPR disclosure: Is that the 1st or 2nd WGLC? I think this statement is an oversimplificatio= n. There were many technical concerns. Anyway, scanning through this document, some technical issues: 1. This approach assumes that FECs do not ever change. A reverse path is in= structed at setup/bootstrap with MPLS LSP Ping =97 what happens if paths ch= ange?!? If a return tunnel is suddenly deleted from underneath? 2. =93Case of MPLS Data Plane=94 =97 is there any other non-MPLS case? This= points to the fact of lack of review and editorial sloppiness. 3. =93Exactly one sub-TLV MUST be included in the Reverse Path TLV.=94 =97 = so basically, no Tunnels can be return path?!? 4. The =93Use Case Scenario=94 uses 2119 language in a way that does not ma= ke sense. Please note, this is not an exhaustive list, but a 2 minute scan through th= e doc. Thanks! Carlos. > On May 24, 2017, at 2:33 AM, n.leymann@telekom.de > wrote: > > Dear Working Group, > > The authors have updated draft-ietf-mpls-bfd-directed and think that the = draft is ready for WGLC. > Therefore this e-mail starts a WG LC which will end on the 7th of June. > > Please note that draft-ietf-mpls-bfd-directed did not pass the > previous working group last call, because of an IPR disclosure: > > https://datatracker.ietf.org/ipr/2892/ > > The authors have updated the draft and they believe that the IPR is no lo= nger in scope. > Please notify the list if you still think the IPR is an issue and please = state if you think it > is OK to continue with the publication of this document. > > Best regards > > Nic > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_C046D750C9344890A65C001951104E68ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi, Greg,

Thanks for the response! - even if it doesn't address the tec= hnical concerns. Sorry if I am not being clear enough or I cannot explain i= t better, but I do believe there are major unresolved technical issues. 

To recap, this is just my technical opinion, and as my final = response to this:
1. This draft forbids (in uppercase) the use of a stack in th= e return path. The explanation you gave is that "that seems unnecessar= y". 
2. This draft does not specify procedures of what happens if the return spe= cified FEC changes. Your response says "uses Return Code and Return Sub-code in Echo Re= ply" which is at bootstrap, but not what happens after the BFD session is up and the path changes (I.e. Th= ere's no more MPLS Ping)
3. For some reason you add "someone may come up with mec= hanism to monitor the reverse path of the BFD session" but that= 's what section 4 is doing. 
4. Pushing the operator to make more decisio= ns and take more actions does not simplify. 

Net-net: makes bfd more brittle (was this ru= n by the BFD WG?)

Thanks!

Carlos. 

Sent from my iPad

On May 31, 2017, at 12:29 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Carlos,
we clearly have different interpretation of what operational simplicit= y means. Of course, someone may come up with mechanism to monitor the rever= se path of the BFD session that was set according to BFD Reverse Path TLV b= ut I don't see that neither necessary, nor helpful because that may hide from an operator real failure.
Regarding the number of sub-TLVs in BFD Reverse Path TLV. I can assume= that authors followed in the path of reasoning set by RFC 4379 (now RFC 80= 29). RFC 8029 defines procedures to verify correlation between the MPLS dat= a plane and control plane. In example in Section 3.2 we see that listing all FECs is optional and it is perfectl= y valid to include single FEC that characterizes the outer MPLS label. Usin= g the same approach in RFC 7110, in my opinion, was not only right but nece= ssary. But for case of controlling the reverse direction of a BFD session that seems unnecessary.
Additionally, RFC 7110 allows operator to pass the right for the final= selection of the return path for Echo Reply to the egress node, to the res= ponder. That may be useful for Echo Request/Reply as the egress returns inf= ormation on how it concluded the selection process based on received Reply Path TLV. For BFD Reverse Path T= LV, egress uses Return Code and Return Sub-code in Echo Reply to indicate w= hether the requested path is available to the egress node. If the path is n= ot available, then the operator may send another request in LSP Ping using BFD Reverse Path TLV.

Regards,
Greg

On Sat, May 27, 2017 at 5:14 AM, Carlos Pignatar= o <cpignata@cisco.= com> wrote:
Greg,

Anytime =97 I wanted to reply so that there was at least one non-autho= r message about it.  You and I have very different views on what is a = technical concern.

For example this comment describes a specific technical concern:
* =93Exactly one sub-TLV MUST be included in the Reverse Path TLV.=94<= /div>

Basically, the document says that the return path cannot have a FEC St= ack (e.g., nested FECs or a Tunnel or...). It is not clear why. 
Basically it flattens MPLS to one label on return.

In contrast, RFC 7110 allows for multiple FECs:

   Reply Path:  It is used to describe the return path = that an echo
      reply will be send along.  It is variable in= length and can
      contain zero, one or more Target FEC sub-TLVs [RF= C4379].

A second technical issue:
* =93 This approach assumes that FECs do not ever change=85.=94

I find the response of =93punt it to the operator=94 complete unsatisf= actory. We are trying to reduce OpEx, not build tools that put the burden o= n operators.

Basically, the root cause stems from the fact that RFC 7110 uses a ret= urn path construct for a response immediate sent and elicited by the reply,= whereas your draft attempts to mimic the method but for a protocol in whic= h there is a bootstrapping, and after that, no mechanism for update although the underlying network can ch= ange.

This proposal as it is right now, basically makes an existing protocol= more brittle than it was before, and the network operations more complex.<= /div>

Another technical concern, the description in Section 4. And then ther= e=92s also the indication of IPR but a conflicting message from one of the = authors.

Please note I was not making specific suggestions =97 technical or edi= torial. Just pointing out that there are technical issues with this documen= t.

Technically.

=97 Carlos.

On May 25, 2017, at 10:26 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear Carlos,
thank you for taking two minutes to write the message. From it all I'v= e found only one concern that, in my view, may be considered technical. Thu= s I'll bring it to the forefront and will try to explain how the situation = may be handled.
You wrote:
1. This approach assumes that FECs do= not ever change. A reverse path is instructed at setup/bootstrap with MPLS= LSP Ping =97 what happens if paths change?!? If a return tunnel is suddenl= y deleted from underneath?
I consider it to be the case that sho= uld be handled by properly operating the network rather then auto-discoveri= ng it and auto-recovering. I hardly believe that a tunnel may be "sudd= enly deleted" without the operator being aware of that. And if that is the case, then the operator may proactively = re-signal return path for those BFD sessions that may be affected by the pl= anned change in the network. Even more, BFD sessions to decrease chance of = receiving false negative during period the remote BFD peer switches to new recommended path.

Thank you for the editorial suggestio= n to consider renaming the section. We'll discuss and share our proposal to= improve the wording.

Others may decide to respond to the r= est of your message. There's nothing of technical substance, as I see it.

Regards,
Greg

On Wed, May 24, 2017 at 11:36 PM, Carlos Pignata= ro (cpignata) <cpignata@cisco.com> wrote:
Nic,

I do not support advancing this document in its current form. It has many t= echnical deficiencies, some of which are listed and described below.

I also believe your WGLC note should have been much more detailed and compr= ehensive.

I believe this is the 3rd WGLC on this document, correct? (That gives a new= meaning to =93Last=94 :-) If so, that should have also been clarified in t= he WGLC email, with a much more clear explanation and comprehensive set of = details of how concerns were discussed and addressed.

> The authors have updated draft-ietf-mpls-bfd-directed and think that t= he draft is ready for WGLC.

I am very concerned that there was no discussion on the list of any = of those changes.  The authors believe the draft is ready =97 do you b= elieve so as well, Nic? Was a shepherd review performed and is that availab= le?

> Please note that draft-ietf-mpls-bfd-directed did not pass the
> previous working group last call, because of an IPR disclosure:

Is that the 1st or 2nd WGLC? I think this statement is an oversimpli= fication. There were many technical concerns.

Anyway, scanning through this document, some technical issues:

1. This approach assumes that FECs do not ever change. A reverse path is in= structed at setup/bootstrap with MPLS LSP Ping =97 what happens if paths ch= ange?!? If a return tunnel is suddenly deleted from underneath?
2. =93Case of MPLS Data Plane=94 =97 is there any other non-MPLS case? This= points to the fact of lack of review and editorial sloppiness.
3. =93Exactly one sub-TLV MUST be included in the Reverse Path TLV.=94 =97 = so basically, no Tunnels can be return path?!?
4. The =93Use Case Scenario=94 uses 2119 language in a way that does not ma= ke sense.

Please note, this is not an exhaustive list, but a 2 minute scan through th= e doc.

Thanks!

Carlos.


> On May 24, 2017, at 2:33 AM, n.leymann@telekom.de <N.Leymann@telekom.de> wrote:
>
> Dear Working Group,
>
> The authors have updated draft-ietf-mpls-bfd-directed and think that t= he draft is ready for WGLC.
> Therefore this e-mail starts a WG LC which will end on the 7th of June= .
>
> Please note that draft-ietf-mpls-bfd-directed did not pass the
> previous working group last call, because of an IPR disclosure:
>
>   https://datatracker.ietf.org/ipr/2892/
>
> The authors have updated the draft and they believe that the IPR is no= longer in scope.
> Please notify the list if you still think the IPR is an issue and plea= se state if you think it
> is OK to continue with the publication of this document.
>
>   Best regards
>
>     Nic
>
>
> ______________________________= _________________
> mpls mailing list
> mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls

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



--_000_C046D750C9344890A65C001951104E68ciscocom_-- From nobody Wed May 31 07:53:01 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FF8129B55; Wed, 31 May 2017 07:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5kS0rD_50dQ; Wed, 31 May 2017 07:52:57 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 E9396129B1D; Wed, 31 May 2017 07:52:56 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id w10so18423719oif.0; Wed, 31 May 2017 07:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xQ9xIkICoYQlP+f1XNWwKgj0Y9V17dv0IW6dzGTFGoo=; b=MBaiFbjna02xRhGAttcuD1XSFeaMrAppks0NzIZfheS0Ln6AZl+EYNDe1nqHCl7OHB ubmZfu6slRPnqp2VVoVHUuRk2vj8pw/nhFtyx1CFDmKrydF1pVKVPBNXRzRVaLG/p8VI mDA7JOC0RauB1l/oF+IP0/IRrFOU5Y2+gFcnS7VYoXNhFsmWps+NPWjT3SGUyUthO0Xq 6XDJPNgXLYmDj4LWgTVrz/D4UxnjN4AxFVpbe/2ataHP7fYuT8ivO/8t7gMyd6a0cIJu sr1kvNwV8UpfAcosrXmdwRC4xIVF4A9GjgqnQjVIivzu3eMwpQ3Y2Mbkfjhr98LFAxzT dopA== 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=xQ9xIkICoYQlP+f1XNWwKgj0Y9V17dv0IW6dzGTFGoo=; b=cLDbE478JSx443hfBbHwdSrmtokkXfvgzFb/d7X2z+6mwnauqMG20X53+VKmOyRxds GiPj4D6O8UV3liDKfaswQYE29/yzugDwA3WDKhXvKLUwh/nX0aKumgfFb9sIRMU6qtrt cg1Nx2N/KMEgntfiehdti5CYkGpFAU40fz1ppSBoLp7t2hcD0NMowDLgkdji0CW9NpEz alxHIkfXXHtCVQ7kddKYS/dirk2sL9LPtkQrDNQ4DCDs3qQ2gmSHt6wxyLPsA9RLA+F8 8CziQwAR0Z3X3VeDJXwRp0P/pU2gkiaF9Rq/pw0tvm0h+p6rzNpnWZGumGy0pOWIZQmJ 0jOA== X-Gm-Message-State: AODbwcCgDJ2YjYoLHuwFnguUPukMN25ad7OY9V4s6e6Gt3m4pMndsVzq F+LT9IWOngcem+r1zWN9579hS8rpzw== X-Received: by 10.157.52.98 with SMTP id v89mr6667963otb.160.1496242376245; Wed, 31 May 2017 07:52:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.225 with HTTP; Wed, 31 May 2017 07:52:55 -0700 (PDT) In-Reply-To: References: <18E37CDD-D0D0-4BE3-99AF-44E5BADCAD5D@cisco.com> From: Greg Mirsky Date: Wed, 31 May 2017 22:52:55 +0800 Message-ID: To: "Carlos Pignataro (cpignata)" Cc: "n.leymann@telekom.de" , mpls , "mpls-chairs@ietf.org" Content-Type: multipart/alternative; boundary="001a1141584c5588fa0550d313e1" Archived-At: Subject: Re: [mpls] WGLC for draft-ietf-mpls-bfd-directed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 14:53:00 -0000 --001a1141584c5588fa0550d313e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos, please find my answers in-line tagged GIM>>. Regards, Greg On Wed, May 31, 2017 at 7:29 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, Greg, > > Thanks for the response! - even if it doesn't address the technical > concerns. Sorry if I am not being clear enough or I cannot explain it > better, but I do believe there are major unresolved technical issues. > > To recap, this is just my technical opinion, and as my final response to > this: > 1. This draft forbids (in uppercase) the use of a stack in the return > path. The explanation you gave is that "that seems unnecessary". > GIM>> Please consider this mail . I hope it addresses this concern. > 2. This draft does not specify procedures of what happens if the return > specified FEC changes. Your response says "uses Return Code and Return > Sub-code in Echo Reply" which is at bootstrap, but not what happens after > the BFD session is up and the path changes (I.e. There's no more MPLS Pin= g) > GIM>> As I've noted, if the change results from the planned operation, then, I believe, the operator may take precautionary actions to re-signal new reverse path for BFD sessions that will be affected. > 3. For some reason you add "someone may come up with mechanism to monitor > the reverse path of the BFD session" but that's what section 4 is doing. > GIM>> The proposal is to add optional mechanism to direct the reverse direction of the BFD session. The proposed mechanism is not intended to serve as failure localization and characterization tool. In that regard I've suggested that some other mechanism may be used. After all, if the chosen return path deemed unstable, then another may be signaled using the described mechanism. > 4. Pushing the operator to make more decisions and take more actions does > not simplify. > GIM>> What can be expressed as data model, I believe, can then be used in flow of orchestrating network. > > Net-net: makes bfd more brittle (was this run by the BFD WG?) > > Thanks! > > Carlos. > > Sent from my iPad > > On May 31, 2017, at 12:29 AM, Greg Mirsky wrote: > > Hi Carlos, > we clearly have different interpretation of what operational simplicity > means. Of course, someone may come up with mechanism to monitor the rever= se > path of the BFD session that was set according to BFD Reverse Path TLV bu= t > I don't see that neither necessary, nor helpful because that may hide fro= m > an operator real failure. > Regarding the number of sub-TLVs in BFD Reverse Path TLV. I can assume > that authors followed in the path of reasoning set by RFC 4379 (now RFC > 8029). RFC 8029 defines procedures to verify correlation between the MPLS > data plane and control plane. In example in Section 3.2 we see that listi= ng > all FECs is optional and it is perfectly valid to include single FEC that > characterizes the outer MPLS label. Using the same approach in RFC 7110, = in > my opinion, was not only right but necessary. But for case of controlling > the reverse direction of a BFD session that seems unnecessary. > Additionally, RFC 7110 allows operator to pass the right for the final > selection of the return path for Echo Reply to the egress node, to the > responder. That may be useful for Echo Request/Reply as the egress return= s > information on how it concluded the selection process based on received > Reply Path TLV. For BFD Reverse Path TLV, egress uses Return Code and > Return Sub-code in Echo Reply to indicate whether the requested path is > available to the egress node. If the path is not available, then the > operator may send another request in LSP Ping using BFD Reverse Path TLV. > > Regards, > Greg > > On Sat, May 27, 2017 at 5:14 AM, Carlos Pignataro > wrote: > >> Greg, >> >> Anytime =E2=80=94 I wanted to reply so that there was at least one non-a= uthor >> message about it. You and I have very different views on what is a >> technical concern. >> >> For example this comment describes a specific technical concern: >> * =E2=80=9CExactly one sub-TLV MUST be included in the Reverse Path TLV.= =E2=80=9D >> >> Basically, the document says that the return path cannot have a FEC Stac= k >> (e.g., nested FECs or a Tunnel or...). It is not clear why. >> Basically it flattens MPLS to one label on return. >> >> In contrast, RFC 7110 allows for multiple FECs: >> >> Reply Path: It is used to describe the return path that an echo >> reply will be send along. It is variable in length and can >> contain zero, one or more Target FEC sub-TLVs [RFC4379]. >> >> A second technical issue: >> * =E2=80=9C This approach assumes that FECs do not ever change=E2=80=A6.= =E2=80=9D >> >> I find the response of =E2=80=9Cpunt it to the operator=E2=80=9D complet= e unsatisfactory. >> We are trying to reduce OpEx, not build tools that put the burden on >> operators. >> >> Basically, the root cause stems from the fact that RFC 7110 uses a retur= n >> path construct for a response immediate sent and elicited by the reply, >> whereas your draft attempts to mimic the method but for a protocol in wh= ich >> there is a bootstrapping, and after that, no mechanism for update althou= gh >> the underlying network can change. >> >> This proposal as it is right now, basically makes an existing protocol >> more brittle than it was before, and the network operations more complex= . >> >> Another technical concern, the description in Section 4. And then there= =E2=80=99s >> also the indication of IPR but a conflicting message from one of the >> authors. >> >> Please note I was not making specific suggestions =E2=80=94 technical or >> editorial. Just pointing out that there are technical issues with this >> document. >> >> Technically. >> >> =E2=80=94 Carlos. >> >> On May 25, 2017, at 10:26 AM, Greg Mirsky wrote: >> >> Dear Carlos, >> thank you for taking two minutes to write the message. From it all I've >> found only one concern that, in my view, may be considered technical. Th= us >> I'll bring it to the forefront and will try to explain how the situation >> may be handled. >> You wrote: >> 1. This approach assumes that FECs do not ever change. A reverse path is >> instructed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what happens = if paths >> change?!? If a return tunnel is suddenly deleted from underneath? >> I consider it to be the case that should be handled by properly operatin= g >> the network rather then auto-discovering it and auto-recovering. I hardl= y >> believe that a tunnel may be "suddenly deleted" without the operator bei= ng >> aware of that. And if that is the case, then the operator may proactivel= y >> re-signal return path for those BFD sessions that may be affected by the >> planned change in the network. Even more, BFD sessions to decrease chanc= e >> of receiving false negative during period the remote BFD peer switches t= o >> new recommended path. >> >> Thank you for the editorial suggestion to consider renaming the section. >> We'll discuss and share our proposal to improve the wording. >> >> Others may decide to respond to the rest of your message. There's nothin= g >> of technical substance, as I see it. >> >> Regards, >> Greg >> >> On Wed, May 24, 2017 at 11:36 PM, Carlos Pignataro (cpignata) < >> cpignata@cisco.com> wrote: >> >>> Nic, >>> >>> I do not support advancing this document in its current form. It has >>> many technical deficiencies, some of which are listed and described bel= ow. >>> >>> I also believe your WGLC note should have been much more detailed and >>> comprehensive. >>> >>> I believe this is the 3rd WGLC on this document, correct? (That gives a >>> new meaning to =E2=80=9CLast=E2=80=9D :-) If so, that should have also = been clarified in >>> the WGLC email, with a much more clear explanation and comprehensive se= t of >>> details of how concerns were discussed and addressed. >>> >>> > The authors have updated draft-ietf-mpls-bfd-directed and think that >>> the draft is ready for WGLC. >>> >>> I am very concerned that there was no discussion on the list of any of >>> those changes. The authors believe the draft is ready =E2=80=94 do you= believe so >>> as well, Nic? Was a shepherd review performed and is that available? >>> >>> > Please note that draft-ietf-mpls-bfd-directed did not pass the >>> > previous working group last call, because of an IPR disclosure: >>> >>> Is that the 1st or 2nd WGLC? I think this statement is an >>> oversimplification. There were many technical concerns. >>> >>> Anyway, scanning through this document, some technical issues: >>> >>> 1. This approach assumes that FECs do not ever change. A reverse path i= s >>> instructed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what happens= if paths >>> change?!? If a return tunnel is suddenly deleted from underneath? >>> 2. =E2=80=9CCase of MPLS Data Plane=E2=80=9D =E2=80=94 is there any oth= er non-MPLS case? This >>> points to the fact of lack of review and editorial sloppiness. >>> 3. =E2=80=9CExactly one sub-TLV MUST be included in the Reverse Path TL= V.=E2=80=9D =E2=80=94 so >>> basically, no Tunnels can be return path?!? >>> 4. The =E2=80=9CUse Case Scenario=E2=80=9D uses 2119 language in a way = that does not >>> make sense. >>> >>> Please note, this is not an exhaustive list, but a 2 minute scan throug= h >>> the doc. >>> >>> Thanks! >>> >>> Carlos. >>> >>> >>> > On May 24, 2017, at 2:33 AM, n.leymann@telekom.de < >>> N.Leymann@telekom.de> wrote: >>> > >>> > Dear Working Group, >>> > >>> > The authors have updated draft-ietf-mpls-bfd-directed and think that >>> the draft is ready for WGLC. >>> > Therefore this e-mail starts a WG LC which will end on the 7th of Jun= e. >>> > >>> > Please note that draft-ietf-mpls-bfd-directed did not pass the >>> > previous working group last call, because of an IPR disclosure: >>> > >>> > https://datatracker.ietf.org/ipr/2892/ >>> > >>> > The authors have updated the draft and they believe that the IPR is n= o >>> longer in scope. >>> > Please notify the list if you still think the IPR is an issue and >>> please state if you think it >>> > is OK to continue with the publication of this document. >>> > >>> > Best regards >>> > >>> > Nic >>> > >>> > >>> > _______________________________________________ >>> > mpls mailing list >>> > mpls@ietf.org >>> > https://www.ietf.org/mailman/listinfo/mpls >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >> >> >> > --001a1141584c5588fa0550d313e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,
please find my answers in-line tagged GIM&g= t;>.

Regards,
Greg

On Wed, May 31, 2017 at 7:29 P= M, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:<= br>
Hi, Greg,

Thanks for the response! - even if it doesn&#= 39;t address the technical concerns. Sorry if I am not being clear enough o= r I cannot explain it better, but I do believe there are major unresolved technical issues.=C2=A0

To recap, this is just my technical opinion, = and as my final response to this:
1. This draft forbids (in uppercase) the use = of a stack in the return path. The explanation you gave is that "that = seems unnecessary".=C2=A0
GI= M>> Please consider this mail=C2=A0. I hope it addresses this c= oncern.
2. This draft does not specify procedures of what happens if the return spe= cified FEC changes. Your response says "uses Return Code and Return Sub-code in Echo Reply" which is at bootstrap, but not what happens after the BFD session is up and the path changes (I.e. Th= ere's no more MPLS Ping)
GIM>> As I&= #39;ve noted, if the change results from the planned operation, then, I bel= ieve, the operator may take precautionary actions to re-signal new reverse = path for BFD sessions that will be affected. =C2=A0
3. For some reason you = add "someone may = come up with mechanism to monitor the reverse path of the BFD session" but that's what section 4 is doing.=C2=A0
GIM>> The proposal is to add optional mechanism to direct the= reverse direction of the BFD session. The proposed mechanism is not intend= ed to serve as failure localization and characterization tool. In that rega= rd I've suggested that some other mechanism may be used. After all, if = the chosen return path deemed unstable, then another may be signaled using = the described mechanism.
4. Pushing the operator= to make more decisions and take more actions does not simplify.=C2=A0
GIM>> What can be expressed as data model, I= believe, can then be used in flow of orchestrating network.=C2=A0

Net-net: makes bfd more= brittle (was this run by the BFD WG?)

Thanks!

Carlos.=C2=A0

Sent from my iPad

On May 31, 2017, at 12:29 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Carlos,
we clearly have different interpretation of what operational simplicit= y means. Of course, someone may come up with mechanism to monitor the rever= se path of the BFD session that was set according to BFD Reverse Path TLV b= ut I don't see that neither necessary, nor helpful because that may hide from an operator real failure.
Regarding the number of sub-TLVs in BFD Reverse Path TLV. I can assume= that authors followed in the path of reasoning set by RFC 4379 (now RFC 80= 29). RFC 8029 defines procedures to verify correlation between the MPLS dat= a plane and control plane. In example in Section 3.2 we see that listing all FECs is optional and it is perfectl= y valid to include single FEC that characterizes the outer MPLS label. Usin= g the same approach in RFC 7110, in my opinion, was not only right but nece= ssary. But for case of controlling the reverse direction of a BFD session that seems unnecessary.
Additionally, RFC 7110 allows operator to pass the right for the final= selection of the return path for Echo Reply to the egress node, to the res= ponder. That may be useful for Echo Request/Reply as the egress returns inf= ormation on how it concluded the selection process based on received Reply Path TLV. For BFD Reverse Path T= LV, egress uses Return Code and Return Sub-code in Echo Reply to indicate w= hether the requested path is available to the egress node. If the path is n= ot available, then the operator may send another request in LSP Ping using BFD Reverse Path TLV.

Regards,
Greg

On Sat, May 27, 2017 at 5:14 AM, Carlos Pignatar= o <cpignata@cisco.= com> wrote:
Greg,

Anytime =E2=80=94 I wanted to reply so that there was at least one non= -author message about it.=C2=A0 You and I have very different views on what= is a technical concern.

For example this comment describes a specific technical concern:
* =E2=80=9CExactly one sub-TLV MUST be included in the Reverse Path TL= V.=E2=80=9D

Basically, the document says that the return path cannot have a FEC St= ack (e.g., nested FECs or a Tunnel or...). It is not clear why.=C2=A0
Basically it flattens MPLS to one label on return.

In contrast, RFC 7110 allows for multiple FECs:

=C2=A0 =C2=A0Reply Path: =C2=A0It is used to describe the return path = that an echo
=C2=A0 =C2=A0 =C2=A0 reply will be send along.=C2=A0 It is variable in= length and can
=C2=A0 =C2=A0 =C2=A0 contain zero, one or more Target FEC sub-TLVs [RF= C4379].

A second technical issue:
* =E2=80=9C This approach assumes that FECs do not ever change=E2=80= =A6.=E2=80=9D

I find the response of =E2=80=9Cpunt it to the operator=E2=80=9D compl= ete unsatisfactory. We are trying to reduce OpEx, not build tools that put = the burden on operators.

Basically, the root cause stems from the fact that RFC 7110 uses a ret= urn path construct for a response immediate sent and elicited by the reply,= whereas your draft attempts to mimic the method but for a protocol in whic= h there is a bootstrapping, and after that, no mechanism for update although the underlying network can ch= ange.

This proposal as it is right now, basically makes an existing protocol= more brittle than it was before, and the network operations more complex.<= /div>

Another technical concern, the description in Section 4. And then ther= e=E2=80=99s also the indication of IPR but a conflicting message from one o= f the authors.

Please note I was not making specific suggestions =E2=80=94 technical = or editorial. Just pointing out that there are technical issues with this d= ocument.

Technically.

=E2=80=94 Carlos.

On May 25, 2017, at 10:26 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear Carlos,
thank you for taking two minutes to write the message. From it all I&#= 39;ve found only one concern that, in my view, may be considered technical.= Thus I'll bring it to the forefront and will try to explain how the si= tuation may be handled.
You wrote:
1. This approach assumes that FECs do= not ever change. A reverse path is instructed at setup/bootstrap with MPLS= LSP Ping =E2=80=94 what happens if paths change?!? If a return tunnel is s= uddenly deleted from underneath?
I consider it to be the case that sho= uld be handled by properly operating the network rather then auto-discoveri= ng it and auto-recovering. I hardly believe that a tunnel may be "sudd= enly deleted" without the operator being aware of that. And if that is the case, then the operator may proactively = re-signal return path for those BFD sessions that may be affected by the pl= anned change in the network. Even more, BFD sessions to decrease chance of = receiving false negative during period the remote BFD peer switches to new recommended path.

Thank you for the editorial suggestio= n to consider renaming the section. We'll discuss and share our proposa= l to improve the wording.

Others may decide to respond to the r= est of your message. There's nothing of technical substance, as I see i= t.

Regards,
Greg

On Wed, May 24, 2017 at 11:36 PM, Carlos Pignata= ro (cpignata) <cpignata@cisco.com> wrote:
Nic,

I do not support advancing this document in its current form. It has many t= echnical deficiencies, some of which are listed and described below.

I also believe your WGLC note should have been much more detailed and compr= ehensive.

I believe this is the 3rd WGLC on this document, correct? (That gives a new= meaning to =E2=80=9CLast=E2=80=9D :-) If so, that should have also been cl= arified in the WGLC email, with a much more clear explanation and comprehen= sive set of details of how concerns were discussed and addressed.

> The authors have updated draft-ietf-mpls-bfd-directed and think that t= he draft is ready for WGLC.

I am very concerned that there was no discussion on the list of any = of those changes.=C2=A0 The authors believe the draft is ready =E2=80=94 do= you believe so as well, Nic? Was a shepherd review performed and is that a= vailable?

> Please note that draft-ietf-mpls-bfd-directed did not pass the
> previous working group last call, because of an IPR disclosure:

Is that the 1st or 2nd WGLC? I think this statement is an oversimpli= fication. There were many technical concerns.

Anyway, scanning through this document, some technical issues:

1. This approach assumes that FECs do not ever change. A reverse path is in= structed at setup/bootstrap with MPLS LSP Ping =E2=80=94 what happens if pa= ths change?!? If a return tunnel is suddenly deleted from underneath?
2. =E2=80=9CCase of MPLS Data Plane=E2=80=9D =E2=80=94 is there any other n= on-MPLS case? This points to the fact of lack of review and editorial slopp= iness.
3. =E2=80=9CExactly one sub-TLV MUST be included in the Reverse Path TLV.= =E2=80=9D =E2=80=94 so basically, no Tunnels can be return path?!?
4. The =E2=80=9CUse Case Scenario=E2=80=9D uses 2119 language in a way that= does not make sense.

Please note, this is not an exhaustive list, but a 2 minute scan through th= e doc.

Thanks!

Carlos.


> On May 24, 2017, at 2:33 AM, n.leymann@telekom.de <N.Leymann@telekom.de> wrote:
>
> Dear Working Group,
>
> The authors have updated draft-ietf-mpls-bfd-directed and think that t= he draft is ready for WGLC.
> Therefore this e-mail starts a WG LC which will end on the 7th of June= .
>
> Please note that draft-ietf-mpls-bfd-directed did not pass the
> previous working group last call, because of an IPR disclosure:
>
>=C2=A0 =C2=A0https://datatracker.ietf.org/ipr/2892/
>
> The authors have updated the draft and they believe that the IPR is no= longer in scope.
> Please notify the list if you still think the IPR is an issue and plea= se state if you think it
> is OK to continue with the publication of this document.
>
>=C2=A0 =C2=A0Best regards
>
>=C2=A0 =C2=A0 =C2=A0Nic
>
>
> _________= ______________________________________
> mpls mailing list
> mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls

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




--001a1141584c5588fa0550d313e1-- From nobody Wed May 31 11:25:22 2017 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C27EE127337; Wed, 31 May 2017 11:25:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mpls@ietf.org, tsaad@cisco.com, mpls-chairs@ietf.org, db3546@att.com X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149625511973.19789.11180641547882265491.idtracker@ietfa.amsl.com> Date: Wed, 31 May 2017 11:25:19 -0700 Archived-At: Subject: [mpls] mpls - New Meeting Session Request for IETF 99 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 18:25:20 -0000 A new meeting session request has just been submitted by Tarek Saad, a Secretary of the mpls working group. --------------------------------------------------------- Working Group Name: Multiprotocol Label Switching Area Name: Routing Area Session Requester: Tarek Saad Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: teas ccamp pce spring bess bfd idr pals bier detnet Second Priority: nvo3 sfc i2rs rtgarea rtgwg Third Priority: ospf isis sidr People who must be present: George Swallow Loa Andersson Deborah Brungard Nicolai Leymann Tarek Saad Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed May 31 20:55:44 2017 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7488912EB15; Wed, 31 May 2017 20:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 VlZnvBCp5NAu; Wed, 31 May 2017 20:55:40 -0700 (PDT) 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 E4AAB12EB0F; Wed, 31 May 2017 20:55:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BF76FB8198E; Wed, 31 May 2017 20:55:19 -0700 (PDT) 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, mpls@ietf.org Message-Id: <20170601035519.BF76FB8198E@rfc-editor.org> Date: Wed, 31 May 2017 20:55:19 -0700 (PDT) Archived-At: Subject: [mpls] RFC 8169 on Residence Time Measurement in MPLS Networks X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 03:55:42 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8169 Title: Residence Time Measurement in MPLS Networks Author: G. Mirsky, S. Ruffini, E. Gray, J. Drake, S. Bryant, A. Vainshtein Status: Standards Track Stream: IETF Date: May 2017 Mailbox: gregimirsky@gmail.com, stefano.ruffini@ericsson.com, Eric.Gray@Ericsson.com, jdrake@juniper.net, stewart.bryant@gmail.com, alexander.vainshtein@ecitele.com Pages: 30 Characters: 66556 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-residence-time-15.txt URL: https://www.rfc-editor.org/info/rfc8169 DOI: 10.17487/RFC8169 This document specifies a new Generic Associated Channel (G-ACh) for Residence Time Measurement (RTM) and describes how it can be used by time synchronization protocols within an MPLS domain. Residence time is the variable part of the propagation delay of timing and synchronization messages; knowing this delay for each message allows for a more accurate determination of the delay to be taken into account when applying the value included in a Precision Time Protocol event message. This document is a product of the Multiprotocol Label Switching 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
Hi Carlos,
after more consideration realized that you = have brought up valid concern and I propose the following change to address= it:
  • in section 3.1.1
OLD TEXT
Exactly one sub-TLV MUST be included in the Reverse Path= TLV. If more than one sub-TLV is present in the Reverse Path TLV, then, in order to avoid ambiguity of which of TLVs to use, the egress BFD peer MUST send Echo Reply with the received Reverse Path TLVs and set the Return Code to "Too Many TLVs Detected" Section 3.2.
NEW TEXT
One or =
more sub-TLVs MAY be included in the BFD Reverse Path TLV.The BFD Reverse P=
ath TLV MAY list a stack of FECs that directly corresponds to the label sta=
ck.
  • section 3.=
2 - remove the first bullet describing return code "Too Many TLVs Detected"=

  • section 5.2 - remove r=
equest to allocate return code value for "Too Many TLVs Detected"=


Hope th=
ese changes will address your concern.
Regards,
Greg
=