From nobody Mon Apr 1 08:15:34 2019 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 9D5B9120243; Mon, 1 Apr 2019 08:15:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 VqgOf1sYIbMJ; Mon, 1 Apr 2019 08:15:25 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::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 7F192120259; Mon, 1 Apr 2019 08:15:07 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id v84so7563790oif.4; Mon, 01 Apr 2019 08:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=8xVm5Id5BhTKIoFp9crvkkw0BWTHdlpr+PMdq1Qqg6o=; b=aJp8GvdFcdG6azmaf2FdMBXFo45dv7uAxN/pNq0PLY8I65kFM+g7tgP6p4o96cQmKv y/RNNhwr7A2Zm1YBJE46oZnThUSSifJ7t/5IbBKwPhEmtxZmNiAFPMWGItlhVsO+W9Tw hsg0K0mS2kvvc/0tZLgv1LF7I2v/OA9LJx/L49l3CHl3yp3gLkQToLUIWn9wQfJu9NC+ K5a0Sw6diE5odF8Q2iW/5fGKqoXYFklqJZ8lDuIkAut9lgfdSlXn1/mfLlI9yIvnc3Iy dTkDHB8YtVRVUqQirzgCyFJ6mQGyMNNlXK2o/1AxAx+NrQTPHLqmKnVqK1+EXhWCP2jm MZ5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=8xVm5Id5BhTKIoFp9crvkkw0BWTHdlpr+PMdq1Qqg6o=; b=J/8zzvw7zcnO0u430CRYZWsw/roHyqOttvL20JvlhQM5poUXJ1xjBqdfBt4lnHneGq 02OljhUi3o8FpSDeMntqCsjB0jey8rxVSOc1DZ7rrFmjp9kiuRQZUiSGAVbzAMfX++Cc 9pxt4+QweeM7SkBw199sqx+PGM/swi6Xpl5wrtBJ29muEmgmD94Z+d0NuWrLd9yoisor ltNIqvobanIPxRkxr1A4kANIfhuTi4MbqAZz86dk3cxIZYkCXXH7SXPTTechoCNfqY1X ab1LSCaWhixTDRMpfH2PZx5WQ751nyFl2OxTaI3M9tjXDHCNYJ+/nr6pjq+CPdLmoXdv z1nw== X-Gm-Message-State: APjAAAXAykVTvIMN6A4pDczg+i3CC8rQ4TGopdMfL6qmzdyO5iLB2xKQ XiaMmIyxC7xQnF2XApXC7KHSqqYfsoZ5cciUH1k= X-Google-Smtp-Source: APXvYqx0aNydlUfHyB9Ff9S+mAVgI7rJ/KoUuGpBZOWI0xHo+mvNSC1fc1x/sQb+ZLFOTLE8ozlMX5oAZiK1OUqY/NQ= X-Received: by 2002:aca:388a:: with SMTP id f132mr13419726oia.115.1554131706367; Mon, 01 Apr 2019 08:15:06 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 1 Apr 2019 11:15:05 -0400 From: Alvaro Retana In-Reply-To: References: <155208210011.3264.12148702952456660789.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Date: Mon, 1 Apr 2019 11:15:05 -0400 Message-ID: To: Mach Chen Cc: "mpls@ietf.org" , The IESG , "mpls-chairs@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004ad3990585797c7f" Archived-At: Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 15:15:30 -0000 --0000000000004ad3990585797c7f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On March 14, 2019 at 2:33:44 AM, Mach Chen (mach.chen@huawei.com) wrote: Mach: ... > (2) =C2=A76: "Otherwise, if the responder does not know the LSR Capabilit= y TLV, an > MPLS echo reply with the return code set to "One or more of the TLVs was > not understood" MUST be sent back to the initiator LSR." Given that this is > the case where the new TLV is not known, then we can't Normatively direct > those nodes to do anything (since they probably don't implement anything in > this document). s/MUST/must + add a reference to rfc8029 (where the > behavior is > specified) [The same text appears again in =C2=A73 and =C2=A73.2. Writing= the > specification is one place is enough.] It's more accurate to call it a "Mandatory" TLV that does not require an implementation has to implement it, but will result in return code when a node does not support it, as specified in RFC8029. Maybe we could just remove the "optional", and make it clear to the IANA section, the code point of this TLV should be allocated from the Mandatory range. How do you think? I think that optional should explicitly be replaced with mandatory=E2=80=A6= . And, the IANA section should be clarified to indicate the range. [Mach] As Loa and Deborah pointed out, the TLV should be an optional TLV, but the code point should be allocated from the Mandatory range. Just as the Downstream Detailed Mapping TLV which is used in the RFC8029 is also optional, but has a code point from the Mandatory range. So, the solution would be: keep it as an optional TLV, and update IANA section to indicate the range. Is this OK for you? I think that where we are getting stuck (it may just be me) is in the terminology from rfc8029: Types less than 32768 (i.e., with the high-order bit equal to 0) are mandatory TLVs that MUST either be supported by an implementation or result in the Return Code of 2 ("One or more of the TLVs was not understood") being sent in the echo response. Types greater than or equal to 32768 (i.e., with the high-order bit equal to 1) are optional TLVs that SHOULD be ignored if the implementation does not understand or support them. This text calls "mandatory TLVs" the ones that will result in the error if not supported -- the behavior that you want. The terminology above is only related to that...not to it's use. So...the LSR Capability TLV is "mandatory" from the point of view that it requires a response if not supported...but not from the point of view that it has to be sent. I think that it is unfortunate that rfc8029 decided to use this terminology because, in this case (and I'm sure others in the future), causes unnecessary confusion. I would prefer if the right terminology (from rfc8029) was used. Note that =C2=A76 starts with this text: This document defines a new optional TLV which is referred to as the "LSR Capability TLV. It MAY be included in the MPLS echo request message and the MPLS echo reply message." ...the "MAY" already points at the optional nature of using the TLV. Suggestion: NEW> This document defines a new mandatory TLV (RFC8029, Section 3) which is referred to as the "LSR Capability TLV. It MAY be included=E2=80=A6 Thanks! Alvaro. --0000000000004ad3990585797c7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On March 14, 2019 at 2:33:44 AM, Mach Chen (mach.chen@huawei.com) wrote:
<= div style=3D"font-family:Helvetica,Arial;font-size:13px">
Mach:

...

> (2) =C2=A76= : "Otherwise, if the responder does not know the LSR Capability TLV, a= n=C2=A0

> MPLS echo reply with the return code set to "One o= r more of the TLVs was=C2=A0> not understood" MUST be sent back to the initiator LSR." G= iven that this is=C2=A0
>= ; the case where the new TLV is not known, then we can't Normatively di= rect=C2=A0
> those nodes= to do anything (since they probably don't implement anything in=C2=A0
> this document). s/MUST= /must + add a reference to rfc8029 (where the=C2=A0
> behavior is=C2=A0
> specified) [The same text appears again in =C2=A7= 3 and =C2=A73.2. Writing the=C2=A0
> specification is one place is enough.]=C2=A0

It's more accurate to call it a &quo= t;Mandatory" TLV that does not require an implementation has to implem= ent it, but will result in return code when a node does not support it, as = specified in RFC8029.=C2=A0


Maybe we could just remove the "optional", and make it c= lear to the IANA section, the code point of this TLV should be allocated fr= om the Mandatory range. How do you think?=C2=A0

I think that optional should explicitly be replaced with= mandatory=E2=80=A6. And, the IANA section should be clarified to indicate = the range.

[Mach] As Loa and Deborah pointed out, the TLV should be an= optional TLV, but the code point should be allocated from the Mandatory ra= nge. Just as the Downstream Detailed Mapping TLV which is used in the RFC80= 29 is also optional, but has a code point from the Mandatory range.<= /font>

= =C2=A0=C2=A0So, the solution would be: keep it as an optional TLV, and upda= te IANA section to indicate the range. Is this OK for you?

I think that where we are getting stuck (it may just be me) i= s in the terminology from rfc8029:

=C2= =A0 =C2=A0Types less than 32768 (i.e., with the high-order bit equal to 0) = are

=C2=A0 =C2=A0mandatory TLVs that MU= ST either be supported by an implementation or

=C2=A0 =C2=A0result in the Return Code of 2 ("One or more of t= he TLVs was not

=C2=A0 =C2=A0understood= ") being sent in the echo response.


=C2=A0 =C2=A0Types greater than = or equal to 32768 (i.e., with the high-order bit

=C2=A0 =C2=A0equal to 1) are optional TLVs that SHOULD be ignored= if the

=C2=A0 =C2=A0implementation doe= s not understand or support them.


This text calls "mandatory TLVs" the ones that will result = in the error if not supported -- the behavior that you want.=C2=A0 The term= inology above is only related to that...not to it's use.

<= font face=3D"Courier">So...the LSR Capability TLV is "mandatory" = from the point of view that it requires a response if not supported...but n= ot from the point of view that it has to be sent.

I think that it is unfortunate that rfc8029 decided to use thi= s terminology because, in this case (and I'm sure others in the future)= , causes unnecessary confusion.

I would= prefer if the right terminology (from rfc8029) was used.=C2=A0 Note that = =C2=A76 starts with this text:

=C2=A0 = =C2=A0This document defines a new optional TLV which is referred to as the = "LSR=C2=A0

=C2=A0 =C2=A0Capability= TLV.=C2=A0 It MAY be included in the MPLS echo request message and the=C2= =A0

=C2=A0 =C2=A0MPLS echo reply messag= e."=C2=A0


...the "MAY" already points at the optional natu= re of using the TLV.=C2=A0 Suggestion:

=

NEW>

=C2=A0 =C2=A0This document defines a new mandatory TLV (RFC8029, = Section 3) which is=C2=A0

=C2=A0 =C2=A0referred to as the "LSR Capabilit= y TLV.=C2=A0 It MAY be included=E2=80=A6


Thanks!

Alvaro.

--0000000000004ad3990585797c7f-- From nobody Mon Apr 1 19:42:42 2019 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 57D4612006F; Mon, 1 Apr 2019 19:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErgJVKmyE9KI; Mon, 1 Apr 2019 19:42:30 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 6C9D6120013; Mon, 1 Apr 2019 19:42:29 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [10.201.108.34]) by Forcepoint Email with ESMTP id 14ED01355FD63586F83A; Tue, 2 Apr 2019 03:42:27 +0100 (IST) Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 2 Apr 2019 03:42:26 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.113]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0415.000; Tue, 2 Apr 2019 10:42:23 +0800 From: Mach Chen To: Alvaro Retana CC: "mpls@ietf.org" , The IESG , "mpls-chairs@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" Thread-Topic: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT) Thread-Index: AQHU1fmbThhWFHA7EEKjBTDftquDOKYI0X+wgAEpCwCAALQIUIAcWr2AgAE3zUA= Date: Tue, 2 Apr 2019 02:42:23 +0000 Message-ID: References: <155208210011.3264.12148702952456660789.idtracker@ietfa.amsl.com> 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: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29298896Edggeml510mbxchi_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 02:42:34 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29298896Edggeml510mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWx2YXJvLA0KDQpUaGFua3MgZm9yIHlvdXIgc3VnZ2VzdGlvbiENCg0KUGxlYXNlIHNlZSBt eSByZXBseSBpbmxpbmUod2l0aCBNYWNoIDEp4oCmDQoNCkZyb206IEFsdmFybyBSZXRhbmEgW21h aWx0bzphcmV0YW5hLmlldGZAZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBBcHJpbCAwMSwgMjAx OSAxMToxNSBQTQ0KVG86IE1hY2ggQ2hlbiA8bWFjaC5jaGVuQGh1YXdlaS5jb20+DQpDYzogbXBs c0BpZXRmLm9yZzsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0BpZXRmLm9y ZzsgZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWxhZy1tdWx0aXBhdGhAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJFOiBbbXBsc10gQWx2YXJvIFJldGFuYSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm LW1wbHMtbHNwLXBpbmctbGFnLW11bHRpcGF0aC0wNjogKHdpdGggQ09NTUVOVCkNCg0KT24gTWFy Y2ggMTQsIDIwMTkgYXQgMjozMzo0NCBBTSwgTWFjaCBDaGVuIChtYWNoLmNoZW5AaHVhd2VpLmNv bTxtYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb20+KSB3cm90ZToNCg0KTWFjaDoNCg0KLi4uDQo+ ICgyKSDCpzY6ICJPdGhlcndpc2UsIGlmIHRoZSByZXNwb25kZXIgZG9lcyBub3Qga25vdyB0aGUg TFNSIENhcGFiaWxpdHkgVExWLCBhbg0KPiBNUExTIGVjaG8gcmVwbHkgd2l0aCB0aGUgcmV0dXJu IGNvZGUgc2V0IHRvICJPbmUgb3IgbW9yZSBvZiB0aGUgVExWcyB3YXMNCj4gbm90IHVuZGVyc3Rv b2QiIE1VU1QgYmUgc2VudCBiYWNrIHRvIHRoZSBpbml0aWF0b3IgTFNSLiIgR2l2ZW4gdGhhdCB0 aGlzIGlzDQo+IHRoZSBjYXNlIHdoZXJlIHRoZSBuZXcgVExWIGlzIG5vdCBrbm93biwgdGhlbiB3 ZSBjYW4ndCBOb3JtYXRpdmVseSBkaXJlY3QNCj4gdGhvc2Ugbm9kZXMgdG8gZG8gYW55dGhpbmcg KHNpbmNlIHRoZXkgcHJvYmFibHkgZG9uJ3QgaW1wbGVtZW50IGFueXRoaW5nIGluDQo+IHRoaXMg ZG9jdW1lbnQpLiBzL01VU1QvbXVzdCArIGFkZCBhIHJlZmVyZW5jZSB0byByZmM4MDI5ICh3aGVy ZSB0aGUNCj4gYmVoYXZpb3IgaXMNCj4gc3BlY2lmaWVkKSBbVGhlIHNhbWUgdGV4dCBhcHBlYXJz IGFnYWluIGluIMKnMyBhbmQgwqczLjIuIFdyaXRpbmcgdGhlDQo+IHNwZWNpZmljYXRpb24gaXMg b25lIHBsYWNlIGlzIGVub3VnaC5dDQoNCkl0J3MgbW9yZSBhY2N1cmF0ZSB0byBjYWxsIGl0IGEg Ik1hbmRhdG9yeSIgVExWIHRoYXQgZG9lcyBub3QgcmVxdWlyZSBhbiBpbXBsZW1lbnRhdGlvbiBo YXMgdG8gaW1wbGVtZW50IGl0LCBidXQgd2lsbCByZXN1bHQgaW4gcmV0dXJuIGNvZGUgd2hlbiBh IG5vZGUgZG9lcyBub3Qgc3VwcG9ydCBpdCwgYXMgc3BlY2lmaWVkIGluIFJGQzgwMjkuDQoNCk1h eWJlIHdlIGNvdWxkIGp1c3QgcmVtb3ZlIHRoZSAib3B0aW9uYWwiLCBhbmQgbWFrZSBpdCBjbGVh ciB0byB0aGUgSUFOQSBzZWN0aW9uLCB0aGUgY29kZSBwb2ludCBvZiB0aGlzIFRMViBzaG91bGQg YmUgYWxsb2NhdGVkIGZyb20gdGhlIE1hbmRhdG9yeSByYW5nZS4gSG93IGRvIHlvdSB0aGluaz8N Cg0KSSB0aGluayB0aGF0IG9wdGlvbmFsIHNob3VsZCBleHBsaWNpdGx5IGJlIHJlcGxhY2VkIHdp dGggbWFuZGF0b3J54oCmLiBBbmQsIHRoZSBJQU5BIHNlY3Rpb24gc2hvdWxkIGJlIGNsYXJpZmll ZCB0byBpbmRpY2F0ZSB0aGUgcmFuZ2UuDQoNCltNYWNoXSBBcyBMb2EgYW5kIERlYm9yYWggcG9p bnRlZCBvdXQsIHRoZSBUTFYgc2hvdWxkIGJlIGFuIG9wdGlvbmFsIFRMViwgYnV0IHRoZSBjb2Rl IHBvaW50IHNob3VsZCBiZSBhbGxvY2F0ZWQgZnJvbSB0aGUgTWFuZGF0b3J5IHJhbmdlLiBKdXN0 IGFzIHRoZSBEb3duc3RyZWFtIERldGFpbGVkIE1hcHBpbmcgVExWIHdoaWNoIGlzIHVzZWQgaW4g dGhlIFJGQzgwMjkgaXMgYWxzbyBvcHRpb25hbCwgYnV0IGhhcyBhIGNvZGUgcG9pbnQgZnJvbSB0 aGUgTWFuZGF0b3J5IHJhbmdlLg0KDQogIFNvLCB0aGUgc29sdXRpb24gd291bGQgYmU6IGtlZXAg aXQgYXMgYW4gb3B0aW9uYWwgVExWLCBhbmQgdXBkYXRlIElBTkEgc2VjdGlvbiB0byBpbmRpY2F0 ZSB0aGUgcmFuZ2UuIElzIHRoaXMgT0sgZm9yIHlvdT8NCg0KSSB0aGluayB0aGF0IHdoZXJlIHdl IGFyZSBnZXR0aW5nIHN0dWNrIChpdCBtYXkganVzdCBiZSBtZSkgaXMgaW4gdGhlIHRlcm1pbm9s b2d5IGZyb20gcmZjODAyOToNCg0KICAgVHlwZXMgbGVzcyB0aGFuIDMyNzY4IChpLmUuLCB3aXRo IHRoZSBoaWdoLW9yZGVyIGJpdCBlcXVhbCB0byAwKSBhcmUNCg0KICAgbWFuZGF0b3J5IFRMVnMg dGhhdCBNVVNUIGVpdGhlciBiZSBzdXBwb3J0ZWQgYnkgYW4gaW1wbGVtZW50YXRpb24gb3INCg0K ICAgcmVzdWx0IGluIHRoZSBSZXR1cm4gQ29kZSBvZiAyICgiT25lIG9yIG1vcmUgb2YgdGhlIFRM VnMgd2FzIG5vdA0KDQogICB1bmRlcnN0b29kIikgYmVpbmcgc2VudCBpbiB0aGUgZWNobyByZXNw b25zZS4NCg0KDQoNCiAgIFR5cGVzIGdyZWF0ZXIgdGhhbiBvciBlcXVhbCB0byAzMjc2OCAoaS5l Liwgd2l0aCB0aGUgaGlnaC1vcmRlciBiaXQNCg0KICAgZXF1YWwgdG8gMSkgYXJlIG9wdGlvbmFs IFRMVnMgdGhhdCBTSE9VTEQgYmUgaWdub3JlZCBpZiB0aGUNCg0KICAgaW1wbGVtZW50YXRpb24g ZG9lcyBub3QgdW5kZXJzdGFuZCBvciBzdXBwb3J0IHRoZW0uDQoNCg0KDQpUaGlzIHRleHQgY2Fs bHMgIm1hbmRhdG9yeSBUTFZzIiB0aGUgb25lcyB0aGF0IHdpbGwgcmVzdWx0IGluIHRoZSBlcnJv ciBpZiBub3Qgc3VwcG9ydGVkIC0tIHRoZSBiZWhhdmlvciB0aGF0IHlvdSB3YW50LiAgVGhlIHRl cm1pbm9sb2d5IGFib3ZlIGlzIG9ubHkgcmVsYXRlZCB0byB0aGF0Li4ubm90IHRvIGl0J3MgdXNl Lg0KDQpTby4uLnRoZSBMU1IgQ2FwYWJpbGl0eSBUTFYgaXMgIm1hbmRhdG9yeSIgZnJvbSB0aGUg cG9pbnQgb2YgdmlldyB0aGF0IGl0IHJlcXVpcmVzIGEgcmVzcG9uc2UgaWYgbm90IHN1cHBvcnRl ZC4uLmJ1dCBub3QgZnJvbSB0aGUgcG9pbnQgb2YgdmlldyB0aGF0IGl0IGhhcyB0byBiZSBzZW50 Lg0KDQpJIHRoaW5rIHRoYXQgaXQgaXMgdW5mb3J0dW5hdGUgdGhhdCByZmM4MDI5IGRlY2lkZWQg dG8gdXNlIHRoaXMgdGVybWlub2xvZ3kgYmVjYXVzZSwgaW4gdGhpcyBjYXNlIChhbmQgSSdtIHN1 cmUgb3RoZXJzIGluIHRoZSBmdXR1cmUpLCBjYXVzZXMgdW5uZWNlc3NhcnkgY29uZnVzaW9uLg0K DQpJIHdvdWxkIHByZWZlciBpZiB0aGUgcmlnaHQgdGVybWlub2xvZ3kgKGZyb20gcmZjODAyOSkg d2FzIHVzZWQuICBOb3RlIHRoYXQgwqc2IHN0YXJ0cyB3aXRoIHRoaXMgdGV4dDoNCg0KICAgVGhp cyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IG9wdGlvbmFsIFRMViB3aGljaCBpcyByZWZlcnJlZCB0 byBhcyB0aGUgIkxTUg0KDQogICBDYXBhYmlsaXR5IFRMVi4gIEl0IE1BWSBiZSBpbmNsdWRlZCBp biB0aGUgTVBMUyBlY2hvIHJlcXVlc3QgbWVzc2FnZSBhbmQgdGhlDQoNCiAgIE1QTFMgZWNobyBy ZXBseSBtZXNzYWdlLiINCg0KDQoNCi4uLnRoZSAiTUFZIiBhbHJlYWR5IHBvaW50cyBhdCB0aGUg b3B0aW9uYWwgbmF0dXJlIG9mIHVzaW5nIHRoZSBUTFYuICBTdWdnZXN0aW9uOg0KDQoNCg0KTkVX Pg0KDQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgbWFuZGF0b3J5IFRMViAoUkZDODAy OSwgU2VjdGlvbiAzKSB3aGljaCBpcw0KDQogICByZWZlcnJlZCB0byBhcyB0aGUgIkxTUiBDYXBh YmlsaXR5IFRMVi4gIEl0IE1BWSBiZSBpbmNsdWRlZOKApg0KDQoNCg0KW01hY2ggMV0gVG8gYWxp Z24gd2l0aCB0aGUgVExWIGRlZmluaXRpb24gYXMgZGVmaW5lZCBpbiBSRkM4MjA5IChlLmcuLCBE b3duc3RyZWFtIERldGFpbGVkIE1hcHBpbmcgVExWLCBpdCBoYXMgdGhlIHNhbWUgc2l0dWF0aW9u IGFzIHRoaXMg4oCcTFNSIENhcGFiaWxpdHkgVExW4oCdKSwgaXQgZGVmaW5lcyBhczoNCjMuNDxo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODAyOSNzZWN0aW9uLTMuND4uICBEb3duc3Ry ZWFtIERldGFpbGVkIE1hcHBpbmcgVExWDQogICBUaGUgRG93bnN0cmVhbSBEZXRhaWxlZCBNYXBw aW5nIG9iamVjdCBpcyBhIFRMViB0aGF0IE1BWSBiZSBpbmNsdWRlZA0KICAgaW4gYW4gTVBMUyBl Y2hvIHJlcXVlc3QgbWVzc2FnZS4NCg0KSG93IGFib3V0IGp1c3QgcmVtb3ZlIHRoZSBtYW5kYXRv cnkvb3B0aW9uYWwsIG5vdCB0byBlbXBoYXNpemUgd2hldGhlciBpdCBpcyBtYW5kYXRvcnkgb3Ig b3B0aW9uYWwsIHRoZW4gaXQgbWF5IHJlZHVjZSBzb21lIGNvbmZ1c2lvbiB3aGVuIG90aGVycyBy ZWFkIGl0IGluIHRoZSBmdXR1cmUsICAganVzdCBhcyB0aGUg4oCcRG93bnN0cmVhbSBEZXRhaWxl ZCBNYXBwaW5nIFRMVuKAnSBkb2VzLCAgOg0KDQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBu ZXcgVExWIChSRkM4MDI5LCBTZWN0aW9uIDMpIHdoaWNoIGlzDQoNCiAgIHJlZmVycmVkIHRvIGFz IHRoZSAiTFNSIENhcGFiaWxpdHkgVExWLiAgSXQgTUFZIGJlIGluY2x1ZGVk4oCmDQoNCkFuZCB0 aGUgSUFOQSBzZWN0aW9uIHdpbGwgYmUgdXBkYXRlZCBhczoNCg0K4oCcVGhlIElBTkEgaXMgcmVx dWVzdGVkIHRvIGFzc2lnbiBuZXcgdmFsdWUgVEJEMSAoZnJvbSB0aGUgcmFuZ2UgNC0xNjM4Mykg Zm9yIExTUiBDYXBhYmlsaXR5IFRMViBmcm9tIHRoZSAiTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0 Y2hpbmcgQXJjaGl0ZWN0dXJlIChNUExTKSBMYWJlbCBTd2l0Y2hlZCBQYXRocyAoTFNQcykgUGlu ZyBQYXJhbWV0ZXJzIC0gVExWcyIgcmVnaXN0cnku4oCdDQoNClRoYW5rcyAsDQoNCk1hY2gNCg0K DQoNClRoYW5rcyENCg0KQWx2YXJvLg0K --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29298896Edggeml510mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx IDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJcGFub3NlLTE6MiA0IDUgMyA1 IDQgNiAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCmgzDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiLm oIfpopggMyBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTMuNXB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0K CWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUt Y29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi4zQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5qCH6aKYIDMgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6Iuagh+mimCAzIjsNCglm b250LXdlaWdodDpib2xkO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg 6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEFsdmFybyw8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgc3VnZ2VzdGlvbiE8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QbGVhc2Ugc2VlIG15IHJlcGx5IGlubGlu ZSh3aXRoIE1hY2ggMSnigKY8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48Zm9udCBzaXplPSIyIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTo8L3NwYW4+ PC9mb250PjwvYj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBBbHZhcm8NCiBSZXRhbmEgW21haWx0bzphcmV0YW5hLmlldGZAZ21haWwuY29tXSA8YnI+DQo8 Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiBNb25kYXks IEFwcmlsIDAxLCAyMDE5IDExOjE1IFBNPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPlRvOjwvc3Bhbj48L2I+IE1hY2ggQ2hlbiAmbHQ7bWFjaC5jaGVuQGh1YXdlaS5jb20m Z3Q7PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOjwvc3Bhbj48L2I+ IG1wbHNAaWV0Zi5vcmc7IFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OzsgbXBscy1jaGFp cnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1sYWctbXVsdGlwYXRoQGlldGYu b3JnPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFu PjwvYj4gUkU6IFttcGxzXSBBbHZhcm8gUmV0YW5hJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWll dGYtbXBscy1sc3AtcGluZy1sYWctbXVsdGlwYXRoLTA2OiAod2l0aCBDT01NRU5UKTxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJIZWx2ZXRpY2EiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5PbiBNYXJjaCAxNCwgMjAxOSBhdCAyOjMzOjQ0IEFNLCBNYWNoIENo ZW4gKDxhIGhyZWY9Im1haWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbSI+bWFjaC5jaGVuQGh1YXdl aS5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iSGVsdmV0aWNh Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9 IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk1hY2g6PG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjIiIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1h bDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pjxmb250IHNpemU9IjIiIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPi4uLjwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGZhY2U9IkhlbHZldGlj YSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgKDIpIMKnNjogJnF1b3Q7T3RoZXJ3aXNlLCBpZiB0 aGUgcmVzcG9uZGVyIGRvZXMgbm90IGtub3cgdGhlIExTUiBDYXBhYmlsaXR5IFRMViwgYW4mbmJz cDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDsgTVBMUyBlY2hvIHJlcGx5IHdpdGggdGhlIHJldHVybiBjb2RlIHNldCB0byAm cXVvdDtPbmUgb3IgbW9yZSBvZiB0aGUgVExWcyB3YXM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyBub3QgdW5kZXJzdG9vZCZxdW90OyBN VVNUIGJlIHNlbnQgYmFjayB0byB0aGUgaW5pdGlhdG9yIExTUi4mcXVvdDsgR2l2ZW4gdGhhdCB0 aGlzIGlzPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi cj4NCiZndDsgdGhlIGNhc2Ugd2hlcmUgdGhlIG5ldyBUTFYgaXMgbm90IGtub3duLCB0aGVuIHdl IGNhbid0IE5vcm1hdGl2ZWx5IGRpcmVjdDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7IHRob3NlIG5vZGVzIHRvIGRvIGFueXRoaW5nIChz aW5jZSB0aGV5IHByb2JhYmx5IGRvbid0IGltcGxlbWVudCBhbnl0aGluZyBpbjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7IHRoaXMgZG9j dW1lbnQpLiBzL01VU1QvbXVzdCAmIzQzOyBhZGQgYSByZWZlcmVuY2UgdG8gcmZjODAyOSAod2hl cmUgdGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi cj4NCiZndDsgYmVoYXZpb3IgaXM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyPg0KJmd0OyBzcGVjaWZpZWQpIFtUaGUgc2FtZSB0ZXh0IGFwcGVhcnMg YWdhaW4gaW4gwqczIGFuZCDCpzMuMi4gV3JpdGluZyB0aGU8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyBzcGVjaWZpY2F0aW9uIGlzIG9u ZSBwbGFjZSBpcyBlbm91Z2guXTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpJdCdzIG1vcmUgYWNjdXJhdGUgdG8gY2FsbCBpdCBhICZx dW90O01hbmRhdG9yeSZxdW90OyBUTFYgdGhhdCBkb2VzIG5vdCByZXF1aXJlIGFuIGltcGxlbWVu dGF0aW9uIGhhcyB0byBpbXBsZW1lbnQgaXQsIGJ1dCB3aWxsIHJlc3VsdCBpbiByZXR1cm4gY29k ZSB3aGVuIGEgbm9kZSBkb2VzIG5vdCBzdXBwb3J0IGl0LCBhcyBzcGVjaWZpZWQgaW4gUkZDODAy OS48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpz dGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Zm9udCBzaXplPSIyIiBmYWNlPSJIZWx2ZXRpY2EiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48 YnI+DQpNYXliZSB3ZSBjb3VsZCBqdXN0IHJlbW92ZSB0aGUgJnF1b3Q7b3B0aW9uYWwmcXVvdDss IGFuZCBtYWtlIGl0IGNsZWFyIHRvIHRoZSBJQU5BIHNlY3Rpb24sIHRoZSBjb2RlIHBvaW50IG9m IHRoaXMgVExWIHNob3VsZCBiZSBhbGxvY2F0ZWQgZnJvbSB0aGUgTWFuZGF0b3J5IHJhbmdlLiBI b3cgZG8geW91IHRoaW5rPzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHA+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iSGVsdmV0aWNhIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+SSB0aGluayB0aGF0IG9wdGlvbmFsIHNob3VsZCBleHBsaWNpdGx5 IGJlIHJlcGxhY2VkIHdpdGggbWFuZGF0b3J54oCmLiBBbmQsIHRoZSBJQU5BIHNlY3Rpb24gc2hv dWxkIGJlIGNsYXJpZmllZCB0byBpbmRpY2F0ZSB0aGUgcmFuZ2UuPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W01hY2hdIEFzIExvYSBhbmQgRGVi b3JhaCBwb2ludGVkIG91dCwgdGhlIFRMViBzaG91bGQgYmUgYW4gb3B0aW9uYWwgVExWLCBidXQg dGhlIGNvZGUgcG9pbnQgc2hvdWxkIGJlIGFsbG9jYXRlZCBmcm9tIHRoZSBNYW5kYXRvcnkNCiBy YW5nZS4gSnVzdCBhcyB0aGUgRG93bnN0cmVhbSBEZXRhaWxlZCBNYXBwaW5nIFRMViB3aGljaCBp cyB1c2VkIGluIHRoZSBSRkM4MDI5IGlzIGFsc28gb3B0aW9uYWwsIGJ1dCBoYXMgYSBjb2RlIHBv aW50IGZyb20gdGhlIE1hbmRhdG9yeSByYW5nZS48L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIi IGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwO1NvLCB0aGUgc29s dXRpb24gd291bGQgYmU6IGtlZXAgaXQgYXMgYW4gb3B0aW9uYWwgVExWLCBhbmQgdXBkYXRlIElB TkEgc2VjdGlvbiB0byBpbmRpY2F0ZSB0aGUgcmFuZ2UuIElzIHRoaXMgT0sgZm9yIHlvdT88L3Nw YW4+PC9mb250Pjxmb250IHNpemU9IjIiIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwPjxmb250 IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkNvdXJpZXIiPkkgdGhpbmsgdGhhdCB3aGVyZSB3ZSBhcmUgZ2V0dGluZyBzdHVj ayAoaXQgbWF5IGp1c3QgYmUgbWUpIGlzIGluIHRoZSB0ZXJtaW5vbG9neSBmcm9tIHJmYzgwMjk6 PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJIZWx2ZXRpY2EiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iQ2FtYnJpYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FtYnJpYSZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBzaXpl PSIyIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpDb3VyaWVyIj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FtYnJp YSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJp YSZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJD b3VyaWVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVy Ij5UeXBlcyBsZXNzIHRoYW4gMzI3NjggKGkuZS4sIHdpdGggdGhlIGhpZ2gtb3JkZXIgYml0IGVx dWFsDQogdG8gMCkgYXJlPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJIZWx2ZXRp Y2EiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHA+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FtYnJpYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwv Zm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0i MiIgZmFjZT0iQ2FtYnJpYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FtYnJpYSZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBz aXplPSIyIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpDb3VyaWVyIj5tYW5kYXRvcnkgVExWcyB0aGF0IE1VU1QgZWl0aGVyIGJlIHN1cHBv cnRlZCBieSBhbiBpbXBsZW1lbnRhdGlvbg0KIG9yPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIy IiBmYWNlPSJIZWx2ZXRpY2EiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FtYnJpYSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OyxzZXJpZiI+ Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj4NCjwvc3Bhbj48L2Zv bnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FtYnJpYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFu PjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5yZXN1bHQgaW4gdGhlIFJldHVybiBDb2Rl IG9mIDIgKCZxdW90O09uZSBvciBtb3JlIG9mIHRoZSBUTFZzIHdhcw0KIG5vdDwvc3Bhbj48L2Zv bnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iSGVsdmV0aWNhIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbWJy aWEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbWJy aWEmcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i Q291cmllciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmll ciI+DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbWJyaWEiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssc2Vy aWYiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+dW5kZXJzdG9v ZCZxdW90OykgYmVpbmcgc2VudCBpbiB0aGUgZWNobyByZXNwb25zZS48L3NwYW4+PC9mb250Pjxm b250IHNpemU9IjIiIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNlPSJIZWx2ZXRpY2Ei PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHA+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FtYnJpYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFu PjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iQ2FtYnJpYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9u dCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpDb3VyaWVyIj5UeXBlcyBncmVhdGVyIHRoYW4gb3IgZXF1YWwgdG8gMzI3Njgg KGkuZS4sIHdpdGggdGhlIGhpZ2gtb3JkZXINCiBiaXQ8L3NwYW4+PC9mb250Pjxmb250IHNpemU9 IjIiIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNlPSJDYW1icmlhIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1b3Q7LHNlcmlm Ij4mbmJzcDs8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPg0KPC9zcGFuPjwv Zm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJDYW1icmlhIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3Nw YW4+PC9mb250Pjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPmVxdWFsIHRvIDEpIGFyZSBvcHRpb25h bCBUTFZzIHRoYXQgU0hPVUxEIGJlIGlnbm9yZWQgaWYgdGhlPC9zcGFuPjwvZm9udD48Zm9udCBz aXplPSIyIiBmYWNlPSJIZWx2ZXRpY2EiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FtYnJpYSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90Oyxz ZXJpZiI+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj4NCjwvc3Bh bj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FtYnJpYSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OyxzZXJpZiI+Jm5ic3A7 PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5pbXBsZW1lbnRhdGlvbiBkb2Vz IG5vdCB1bmRlcnN0YW5kIG9yIHN1cHBvcnQgdGhlbS48L3NwYW4+PC9mb250Pjxmb250IHNpemU9 IjIiIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNlPSJIZWx2ZXRpY2EiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHA+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ291cmllciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6Q291cmllciI+VGhpcyB0ZXh0IGNhbGxzICZxdW90O21hbmRhdG9yeSBUTFZzJnF1 b3Q7IHRoZSBvbmVzIHRoYXQgd2lsbCByZXN1bHQgaW4gdGhlIGVycm9yIGlmIG5vdCBzdXBwb3J0 ZWQgLS0gdGhlIGJlaGF2aW9yIHRoYXQgeW91IHdhbnQuPC9zcGFuPjwvZm9udD48Zm9udCBzaXpl PSIyIiBmYWNlPSJDYW1icmlhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDYW1icmlhJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PC9mb250Pjxmb250 IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkNvdXJpZXIiPg0KIFRoZSB0ZXJtaW5vbG9neSBhYm92ZSBpcyBvbmx5IHJlbGF0 ZWQgdG8gdGhhdC4uLm5vdCB0byBpdCdzIHVzZS48L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIi IGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5Tby4uLnRoZSBMU1IgQ2FwYWJp bGl0eSBUTFYgaXMgJnF1b3Q7bWFuZGF0b3J5JnF1b3Q7IGZyb20gdGhlIHBvaW50IG9mIHZpZXcg dGhhdCBpdCByZXF1aXJlcyBhIHJlc3BvbnNlIGlmIG5vdCBzdXBwb3J0ZWQuLi5idXQgbm90IGZy b20gdGhlIHBvaW50IG9mIHZpZXcgdGhhdCBpdCBoYXMgdG8gYmUgc2VudC48L3NwYW4+PC9mb250 Pjxmb250IHNpemU9IjIiIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVy Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5JIHRo aW5rIHRoYXQgaXQgaXMgdW5mb3J0dW5hdGUgdGhhdCByZmM4MDI5IGRlY2lkZWQgdG8gdXNlIHRo aXMgdGVybWlub2xvZ3kgYmVjYXVzZSwgaW4gdGhpcyBjYXNlIChhbmQgSSdtIHN1cmUgb3RoZXJz IGluIHRoZSBmdXR1cmUpLCBjYXVzZXMgdW5uZWNlc3NhcnkgY29uZnVzaW9uLjwvc3Bhbj48L2Zv bnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iSGVsdmV0aWNhIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJp ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPkkg d291bGQgcHJlZmVyIGlmIHRoZSByaWdodCB0ZXJtaW5vbG9neSAoZnJvbSByZmM4MDI5KSB3YXMg dXNlZC48L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbWJyaWEiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssc2Vy aWYiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+DQogTm90ZSB0 aGF0IDwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+wqc8L3NwYW4+PC9mb250 Pjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPjYgc3RhcnRzIHdpdGggdGhpcyB0ZXh0Ojwvc3Bhbj48 L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iSGVsdmV0aWNhIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjIiIGZhY2U9IkNh bWJyaWEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bWJyaWEmcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ291cmllciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291 cmllciI+DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbWJyaWEiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDss c2VyaWYiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+VGhpcyBk b2N1bWVudCBkZWZpbmVzIGEgbmV3IG9wdGlvbmFsIFRMViB3aGljaCBpcyByZWZlcnJlZA0KIHRv IGFzIHRoZSAmcXVvdDtMU1I8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbWJy aWEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbWJy aWEmcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i SGVsdmV0aWNhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbWJyaWEiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssc2VyaWYiPiZuYnNwOzwv c3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+DQo8L3NwYW4+PC9mb250Pjxmb250 IHNpemU9IjIiIGZhY2U9IkNhbWJyaWEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6Q291cmllciI+Q2FwYWJpbGl0eSBUTFYuPC9zcGFuPjwvZm9udD48Zm9u dCBzaXplPSIyIiBmYWNlPSJDYW1icmlhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PC9mb250 Pjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPg0KIEl0IE1BWSBiZSBpbmNsdWRlZCBpbiB0aGUgTVBM UyBlY2hvIHJlcXVlc3QgbWVzc2FnZSBhbmQgdGhlPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIy IiBmYWNlPSJDYW1icmlhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDYW1icmlhJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PC9mb250Pjxmb250IHNp emU9IjIiIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNlPSJDYW1icmlhIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1b3Q7LHNl cmlmIj4mbmJzcDs8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPg0KPC9zcGFu PjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJDYW1icmlhIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1b3Q7LHNlcmlmIj4mbmJzcDs8 L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPk1QTFMgZWNobyByZXBseSBtZXNz YWdlLiZxdW90Ozwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FtYnJpYSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90 OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJIZWx2ZXRp Y2EiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHA+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iSGVsdmV0aWNhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjIiIGZhY2U9IkNv dXJpZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIi Pi4uLnRoZSAmcXVvdDtNQVkmcXVvdDsgYWxyZWFkeSBwb2ludHMgYXQgdGhlIG9wdGlvbmFsIG5h dHVyZSBvZiB1c2luZyB0aGUgVExWLjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i Q2FtYnJpYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FtYnJpYSZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBm YWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpD b3VyaWVyIj4NCiBTdWdnZXN0aW9uOjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i SGVsdmV0aWNhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwPjxmb250IHNpemU9IjIiIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBm YWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpD b3VyaWVyIj5ORVcmZ3Q7PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJIZWx2ZXRp Y2EiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHA+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FtYnJpYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwv Zm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0i MiIgZmFjZT0iQ2FtYnJpYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FtYnJpYSZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBz aXplPSIyIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpDb3VyaWVyIj5UaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgbWFuZGF0b3J5IFRM ViAoUkZDODAyOSwgU2VjdGlvbg0KIDMpIHdoaWNoIGlzPC9zcGFuPjwvZm9udD48Zm9udCBzaXpl PSIyIiBmYWNlPSJDYW1icmlhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDYW1icmlhJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PC9mb250Pjxmb250 IHNpemU9IjIiIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNlPSJDYW1icmlhIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1b3Q7 LHNlcmlmIj4mbmJzcDs8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPg0KPC9z cGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJDYW1icmlhIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1b3Q7LHNlcmlmIj4mbmJz cDs8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPnJlZmVycmVkIHRvIGFzIHRo ZSAmcXVvdDtMU1IgQ2FwYWJpbGl0eSBUTFYuPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBm YWNlPSJDYW1icmlhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDYW1icmlhJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PC9mb250Pjxmb250IHNpemU9 IjIiIGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OkNvdXJpZXIiPg0KIEl0IE1BWSBiZSBpbmNsdWRlZDwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iQ291cmllciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6Q291cmllciI+4oCmPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwPjxmb250 IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwPjxm b250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+W01hY2ggMV0gVG8gYWxpZ24gd2l0aCB0aGUgVExWIGRlZmluaXRp b24gYXMgZGVmaW5lZCBpbiBSRkM4MjA5IChlLmcuLCBEb3duc3RyZWFtIERldGFpbGVkIE1hcHBp bmcgVExWLCBpdCBoYXMgdGhlIHNhbWUgc2l0dWF0aW9uDQogYXMgdGhpcyDigJxMU1IgQ2FwYWJp bGl0eSBUTFbigJ0pLCBpdCBkZWZpbmVzIGFzOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQiPg0KPGEgbmFt ZT0ic2VjdGlvbi0zLjQiPjwvYT48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjODAyOSNzZWN0aW9uLTMuNCI+PGI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7Zm9udC13ZWlnaHQ6Ym9sZCI+My40 PC9zcGFuPjwvZm9udD48L2I+PC9hPjxiPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO2ZvbnQtd2VpZ2h0OmJvbGQiPi4m bmJzcDsNCiBEb3duc3RyZWFtIERldGFpbGVkIE1hcHBpbmcgVExWPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xv cj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IFRoZSBEb3duc3RyZWFtIERldGFpbGVkIE1hcHBpbmcgb2JqZWN0IGlzIGEgVExWIHRo YXQgTUFZIGJlIGluY2x1ZGVkPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaW4gYW4gTVBMUyBlY2hvIHJl cXVlc3QgbWVzc2FnZS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6 ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5Ib3cgYWJvdXQganVzdCByZW1vdmUgdGhlIG1hbmRhdG9yeS9vcHRpb25hbCwg bm90IHRvIGVtcGhhc2l6ZSB3aGV0aGVyIGl0IGlzIG1hbmRhdG9yeSBvciBvcHRpb25hbCwgdGhl biBpdCBtYXkgcmVkdWNlIHNvbWUgY29uZnVzaW9uDQogd2hlbiBvdGhlcnMgcmVhZCBpdCBpbiB0 aGUgZnV0dXJlLCAmbmJzcDsmbmJzcDtqdXN0IGFzIHRoZSDigJxEb3duc3RyZWFtIERldGFpbGVk IE1hcHBpbmcgVExW4oCdIGRvZXMsICZuYnNwOzoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNlPSJDYW1icmlhIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1b3Q7LHNlcmlmIj4mbmJzcDs8 L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPg0KPC9zcGFuPjwvZm9udD48Zm9u dCBzaXplPSIyIiBmYWNlPSJDYW1icmlhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PC9mb250 Pjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPlRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBUTFYg KFJGQzgwMjksIFNlY3Rpb24gMykgd2hpY2gNCiBpczwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0i MiIgZmFjZT0iQ2FtYnJpYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FtYnJpYSZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBz aXplPSIyIiBmYWNlPSJIZWx2ZXRpY2EiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FtYnJpYSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90Oyxz ZXJpZiI+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj4NCjwvc3Bh bj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FtYnJpYSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OyxzZXJpZiI+Jm5ic3A7 PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5yZWZlcnJlZCB0byBhcyB0aGUg JnF1b3Q7TFNSIENhcGFiaWxpdHkgVExWLjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ2FtYnJpYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FtYnJpYSZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIy IiBmYWNlPSJDb3VyaWVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpDb3VyaWVyIj4NCiBJdCBNQVkgYmUgaW5jbHVkZWQ8L3NwYW4+PC9mb250Pjxmb250IHNpemU9 IjIiIGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OkNvdXJpZXIiPuKApjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cD48Zm9udCBz aXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkFuZCB0aGUgSUFOQSBzZWN0aW9uIHdpbGwgYmUgdXBkYXRlZCBhczo8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5 N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJxUaGUg SUFOQSBpcyByZXF1ZXN0ZWQgdG8gYXNzaWduIG5ldyB2YWx1ZSBUQkQxIChmcm9tIHRoZSByYW5n ZSA0LTE2MzgzKSBmb3IgTFNSIENhcGFiaWxpdHkgVExWIGZyb20gdGhlICZxdW90O011bHRpcHJv dG9jb2wgTGFiZWwgU3dpdGNoaW5nDQogQXJjaGl0ZWN0dXJlIChNUExTKSBMYWJlbCBTd2l0Y2hl ZCBQYXRocyAoTFNQcykgUGluZyBQYXJhbWV0ZXJzIC0gVExWcyZxdW90OyByZWdpc3RyeS7igJ08 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMx ZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFu a3MgLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pk1hY2g8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iSGVsdmV0aWNhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPlRoYW5rcyE8L3NwYW4+PC9m b250Pjxmb250IHNpemU9IjIiIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3Vy aWVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5B bHZhcm8uPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJIZWx2ZXRpY2EiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29298896Edggeml510mbxchi_-- From nobody Tue Apr 2 10:24:22 2019 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 A8D9212013F; Tue, 2 Apr 2019 10:24:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 YVkR8dcWkG1F; Tue, 2 Apr 2019 10:24:10 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 06FE11200FB; Tue, 2 Apr 2019 10:24:09 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id 103so12713240otd.9; Tue, 02 Apr 2019 10:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=4KGguUdTJmnLRPEd8Uek8DnuBu7IsmhCjcPrVTBXIh0=; b=KyHGHuVLG5IjoqUagZNA2zuGS01OBuPhbuXkUHA8BO3WRRhs5piMFejHwrQMbi7ZZi SB5BviMZTGhuOEiy4YwtdFRLuu7fpC7ZMaWoZkVWki6ffHxcTg08cJKikIztqVbtMp3O mTu4jRRZZucFS9OhQVTHb+xY0VCKbAC/KsbwKKb6NfntIQ6i3XloxurBifXOlXyUfZFH P0Agv5MfWbYqkBYZKZxFiVeuixoXNTuoi1qs2cuAyehruyJ5qAwTkhj7WhD49xj871pY vocOE+dSPLNNW2D4Z4ATiUHeNnfrxdy6jvfQsKBS59/y/4hkvPAgFaFv4weidFbSR4xc EmLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=4KGguUdTJmnLRPEd8Uek8DnuBu7IsmhCjcPrVTBXIh0=; b=LxYzQRudrYpg5ivwhSxOAGCSnVvFC5XkNLhOzwGPhx2j/nojqpTOpItwujp4lRrNcX m0a4Qn7i7m0+2/5R/qNJgb8T70Wcul3lKuxRGtAOAV2KpXZZDHtUi9SpAoGLI62nTd7K aK3aR6ousgQZElBFXG/UuSC2XCoxO0fdYU9N0orumsbJCbScWbOe9OAbF9GfPXI6aQvj 960o4Kd3bh8jHGDT3YhP/AhDiKYf114ZHEDLNP8AVpQGtA3qfnEdi6bcSvRXXGI0k3Z3 KGSQ0wO22uRNiCMDgfYUXQOhWIq8gD6x3kKfOr8PD+DoLj+cTLUl76ZjKhBhXBzEtQqa v7nw== X-Gm-Message-State: APjAAAUCLr2RRie6j+18w5KpC4zJb3JJqi81P4YwO+tZTbxpj24MU3dK EnmfI2prrGlLCX3g0zPrpz6JA66XCmjOIln+f9k= X-Google-Smtp-Source: APXvYqzoMWJ9HCoPpIHnOL9WLg522Sbp8MUG0JkCVdbJekhHV19mGBdzPrkCdHM3sIC1h/xYjDs2ZiclOjoIl2GwhAc= X-Received: by 2002:a05:6830:1103:: with SMTP id w3mr53126750otq.28.1554225849200; Tue, 02 Apr 2019 10:24:09 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 2 Apr 2019 13:24:08 -0400 From: Alvaro Retana In-Reply-To: References: <155208210011.3264.12148702952456660789.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Date: Tue, 2 Apr 2019 13:24:08 -0400 Message-ID: To: Mach Chen Cc: "mpls-chairs@ietf.org" , "mpls@ietf.org" , The IESG , "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a4761105858f6761" Archived-At: Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 17:24:15 -0000 --000000000000a4761105858f6761 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, that works for me. If we do that, we don=E2=80=99t need the reference= to rfc8029. :-) On April 1, 2019 at 10:42:27 PM, Mach Chen (mach.chen@huawei.com) wrote: How about just remove the mandatory/optional, not to emphasize whether it is mandatory or optional, then it may reduce some confusion when others read it in the future, just as the =E2=80=9CDownstream Detailed Mapping T= LV=E2=80=9D does, : This document defines a new TLV (RFC8029, Section 3) which is referred to as the "LSR Capability TLV. It MAY be included=E2=80=A6 --000000000000a4761105858f6761 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Yes, that works for me.=C2=A0 If we do that, we don=E2= =80=99t need the reference to rfc8029. :-)

On April = 1, 2019 at 10:42:27 PM, Mach Chen (= mach.chen@huawei.com) wrote:

How about just remove the mandatory/optional, not to emphasize wh= ether it is mandatory or optional, then it may reduce some confusion when o= thers read it in the future, =C2=A0=C2=A0just as the =E2=80=9CDownstream De= tailed Mapping TLV=E2=80=9D does, =C2=A0:

=C2=A0=C2=A0=C2=A0This document defines a new TLV (RFC8029, Section 3) w= hich is=C2=A0

=C2=A0=C2=A0=C2=A0referred to as the &q= uot;LSR Capability TLV.=C2=A0=C2=A0It MAY be included=E2=80=A6


--000000000000a4761105858f6761-- From nobody Wed Apr 3 00:02:05 2019 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 81BB41200D7; Wed, 3 Apr 2019 00:01:55 -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.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <155427491541.23002.3783020054876295885@ietfa.amsl.com> Date: Wed, 03 Apr 2019 00:01:55 -0700 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-lag-multipath-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 07:01:56 -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 WG 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-07.txt Pages : 28 Date : 2019-04-02 Abstract: This document defines extensions to the MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. Additionally, a mechanism is defined to enable determination of the capabilities of an LSR supported. 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-lsp-ping-lag-multipath-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-lag-multipath-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 3 00:04:53 2019 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 B86F112049B; Wed, 3 Apr 2019 00:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCO1qQ7_VQ2H; Wed, 3 Apr 2019 00:04:40 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 D7089120013; Wed, 3 Apr 2019 00:04:39 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E8682C2A72C2F744D42E; Wed, 3 Apr 2019 08:04:37 +0100 (IST) Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 3 Apr 2019 08:04:37 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.113]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0415.000; Wed, 3 Apr 2019 15:04:31 +0800 From: Mach Chen To: Alvaro Retana , 'Benjamin Kaduk' CC: "mpls-chairs@ietf.org" , "mpls@ietf.org" , The IESG , "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" Thread-Topic: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT) Thread-Index: AQHU1fmbThhWFHA7EEKjBTDftquDOKYI0X+wgAEpCwCAALQIUIAcWr2AgAE3zUCAAH6WAIABZtCw Date: Wed, 3 Apr 2019 07:04:31 +0000 Message-ID: References: <155208210011.3264.12148702952456660789.idtracker@ietfa.amsl.com> 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: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE292990D6Ddggeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 07:04:43 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE292990D6Ddggeml510mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U291bmRzIGdyZWF0IQ0KDQpUaGlzIGFsc28gc2hvdWxkIGFkZHJlc3MgQmVuamFtaW7igJlzIERJ U0NVU1MuDQoNCkkgaGF2ZSB1cGxvYWRlZCBhIHJldmlzaW9uLCBoZXJlIGFyZSB0aGUgbGlua3M6 DQoNCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1sYWctbXVsdGlwYXRoDQoNCkRpZmY6ICAgICAgICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tcGxzLWxzcC1w aW5nLWxhZy1tdWx0aXBhdGgtMDcNCg0KVGhhbmtzLA0KTWFjaA0KDQpGcm9tOiBBbHZhcm8gUmV0 YW5hIFttYWlsdG86YXJldGFuYS5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXBy aWwgMDMsIDIwMTkgMToyNCBBTQ0KVG86IE1hY2ggQ2hlbiA8bWFjaC5jaGVuQGh1YXdlaS5jb20+ DQpDYzogbXBscy1jaGFpcnNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IFRoZSBJRVNHIDxpZXNn QGlldGYub3JnPjsgZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWxhZy1tdWx0aXBhdGhAaWV0Zi5v cmcNClN1YmplY3Q6IFJFOiBbbXBsc10gQWx2YXJvIFJldGFuYSdzIE5vIE9iamVjdGlvbiBvbiBk cmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctbGFnLW11bHRpcGF0aC0wNjogKHdpdGggQ09NTUVOVCkN Cg0KWWVzLCB0aGF0IHdvcmtzIGZvciBtZS4gIElmIHdlIGRvIHRoYXQsIHdlIGRvbuKAmXQgbmVl ZCB0aGUgcmVmZXJlbmNlIHRvIHJmYzgwMjkuIDotKQ0KDQoNCk9uIEFwcmlsIDEsIDIwMTkgYXQg MTA6NDI6MjcgUE0sIE1hY2ggQ2hlbiAobWFjaC5jaGVuQGh1YXdlaS5jb208bWFpbHRvOm1hY2gu Y2hlbkBodWF3ZWkuY29tPikgd3JvdGU6DQoNCkhvdyBhYm91dCBqdXN0IHJlbW92ZSB0aGUgbWFu ZGF0b3J5L29wdGlvbmFsLCBub3QgdG8gZW1waGFzaXplIHdoZXRoZXIgaXQgaXMgbWFuZGF0b3J5 IG9yIG9wdGlvbmFsLCB0aGVuIGl0IG1heSByZWR1Y2Ugc29tZSBjb25mdXNpb24gd2hlbiBvdGhl cnMgcmVhZCBpdCBpbiB0aGUgZnV0dXJlLCAgIGp1c3QgYXMgdGhlIOKAnERvd25zdHJlYW0gRGV0 YWlsZWQgTWFwcGluZyBUTFbigJ0gZG9lcywgIDoNCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVz IGEgbmV3IFRMViAoUkZDODAyOSwgU2VjdGlvbiAzKSB3aGljaCBpcw0KDQogICByZWZlcnJlZCB0 byBhcyB0aGUgIkxTUiBDYXBhYmlsaXR5IFRMVi4gIEl0IE1BWSBiZSBpbmNsdWRlZOKApg0KDQo= --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE292990D6Ddggeml510mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRp di5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiLnuq/mlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCnAuYWlybWFpbG9uLCBsaS5haXJtYWlsb24sIGRpdi5haXJtYWlsb24N Cgl7bXNvLXN0eWxlLW5hbWU6YWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1u YW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi57qv5paH 5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrnuq/m lofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvdW5kcyBncmVhdCENCjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgYWxzbyBzaG91bGQgYWRkcmVzcyBCZW5qYW1pbuKAmXMg RElTQ1VTUy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGhhdmUgdXBsb2Fk ZWQgYSByZXZpc2lvbiwgaGVyZSBhcmUgdGhlIGxpbmtzOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1sYWctbXVsdGlwYXRoIj4N Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1tcGxzLWxz cC1waW5nLWxhZy1tdWx0aXBhdGg8L2E+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EaWZmOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1sYWctbXVsdGlw YXRoLTA3Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW1w bHMtbHNwLXBpbmctbGFnLW11bHRpcGF0aC0wNzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2Qi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TWFjaDxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtmb250LXdlaWdo dDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IEFsdmFybw0KIFJldGFuYSBbbWFpbHRvOmFyZXRhbmEuaWV0 ZkBnbWFpbC5jb21dIDxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TZW50 Ojwvc3Bhbj48L2I+IFdlZG5lc2RheSwgQXByaWwgMDMsIDIwMTkgMToyNCBBTTxicj4NCjxiPjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+PC9iPiBNYWNoIENoZW4gJmx0 O21hY2guY2hlbkBodWF3ZWkuY29tJmd0Ozxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5DYzo8L3NwYW4+PC9iPiBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9y ZzsgVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7OyBkcmFmdC1pZXRmLW1wbHMtbHNwLXBp bmctbGFnLW11bHRpcGF0aEBpZXRmLm9yZzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJFOiBbbXBsc10gQWx2YXJvIFJldGFuYSdzIE5v IE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctbGFnLW11bHRpcGF0aC0wNjog KHdpdGggQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgZmFjZT0iSGVsdmV0aWNhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+WWVzLCB0aGF0IHdvcmtzIGZv ciBtZS4mbmJzcDsgSWYgd2UgZG8gdGhhdCwgd2UgZG9u4oCZdCBuZWVkIHRoZSByZWZlcmVuY2Ug dG8gcmZjODAyOS4gOi0pPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iSGVsdmV0aWNhIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJhaXJtYWlsb24iPjxmb250IHNpemU9IjIiIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPk9uIEFwcmlsIDEsIDIwMTkgYXQgMTA6NDI6MjcgUE0sIE1hY2ggQ2hlbiAoPGEgaHJl Zj0ibWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tIj5tYWNoLmNoZW5AaHVhd2VpLmNvbTwvYT4p IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBzdHlsZT0i Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBw eCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkhlbHZldGljYSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SG93IGFib3V0IGp1c3QgcmVtb3ZlIHRoZSBtYW5k YXRvcnkvb3B0aW9uYWwsIG5vdCB0byBlbXBoYXNpemUNCiB3aGV0aGVyIGl0IGlzIG1hbmRhdG9y eSBvciBvcHRpb25hbCwgdGhlbiBpdCBtYXkgcmVkdWNlIHNvbWUgY29uZnVzaW9uIHdoZW4gb3Ro ZXJzIHJlYWQgaXQgaW4gdGhlIGZ1dHVyZSwgJm5ic3A7Jm5ic3A7anVzdCBhcyB0aGUg4oCcRG93 bnN0cmVhbSBEZXRhaWxlZCBNYXBwaW5nIFRMVuKAnSBkb2VzLCAmbmJzcDs6PC9zcGFuPjwvZm9u dD48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBz dHlsZT0iZm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFj aW5nOjBweCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJIZWx2ZXRpY2EiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jm5ic3A7VGhpcyBkb2N1bWVudCBkZWZpbmVzDQog YSBuZXcgVExWIChSRkM4MDI5LCBTZWN0aW9uIDMpIHdoaWNoIGlzJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxh Y2siIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNw OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbmJzcDty ZWZlcnJlZCB0byBhcyB0aGUNCiAmcXVvdDtMU1IgQ2FwYWJpbGl0eSBUTFYuJm5ic3A7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkl0IE1BWSBiZSBpbmNs dWRlZOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJIZWx2ZXRpY2EiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE292990D6Ddggeml510mbxchi_-- From nobody Wed Apr 3 08:44:10 2019 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 704221204E0; Wed, 3 Apr 2019 08:43:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <155430623936.22744.8568984984107150586@ietfa.amsl.com> Date: Wed, 03 Apr 2019 08:43:59 -0700 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-bfd-directed-11.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 15:44:02 -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 WG of the IETF. Title : Bidirectional Forwarding Detection (BFD) Directed Return Path Authors : Greg Mirsky Jeff Tantsura Ilya Varlashkin Mach(Guoyi) Chen Filename : draft-ietf-mpls-bfd-directed-11.txt Pages : 8 Date : 2019-04-03 Abstract: Bidirectional Forwarding Detection (BFD) is expected to be able to monitor a wide variety of encapsulations of paths between systems. When a BFD session monitors an explicitly routed unidirectional path there may be a need to direct egress BFD peer to use a specific path for the reverse direction of the BFD session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-bfd-directed/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-bfd-directed-11 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-bfd-directed-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-bfd-directed-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 3 09:16:52 2019 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 31D93120074; Wed, 3 Apr 2019 09:16:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org, mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155430820919.22676.3438359950422110370.idtracker@ietfa.amsl.com> Date: Wed, 03 Apr 2019 09:16:49 -0700 Archived-At: Subject: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-lag-multipath-07: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 16:16:49 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-mpls-lsp-ping-lag-multipath-07: 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-lsp-ping-lag-multipath/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the updates in the -07; we seem to be in agreement on the main path forward. That said, in Section 4.2 we still see that: Based on the procedures described above, every LAG member link will have a Local Interface Index Sub-TLV and a Multipath Data Sub-TLV entries in the DDMAP TLV. The order of the Sub-TLVs in the DDMAP TLV for a LAG member link MUST be Local Interface Index Sub-TLV immediately followed by Multipath Data Sub-TLV. A LAG member link MAY also have a corresponding Remote Interface Index Sub-TLV. When a [...] I think we need "except as follows" or similar at the end of the second sentence, since otherwise we go on to have a MUST that contradicts the "MUST be Local Interface Index [...] immediately followed by Multipath Data". (Also, we missed one instance of "optional" in Section 8: "Local Interface Index Sub-TLV is an optional TLV") ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A couple nits in the new text in the -07: "an new" (should be "a new") and "mechanims" (should be "mechanism"). [the following COMMENT portion has not been revised since the ballot on the -06 and may contain stale information] Am I reading this correctly that the "LSR Capability TLV" created here is basically only applicable to properties of MPLS echo request/reply exchanges? If so, then perhaps the moniker "LSR Capability" is overly generic. Section 1.2 o Label switching over some member links of the LAG is successful, but will be failed over other member links of the LAG. nit: there's some verb tense inconsistency here; maybe "but fails over other member links" would help. Section 2 This document defines an optional TLV to discover the capabilities of a responder LSR and extensions for use with the MPLS LSP Ping and nit: is it only the *responder* LSR we care about, or are there potentially intermediaries in play? The solution consists of the MPLS echo request containing a DDMAP TLV and the optional LSR capability TLV to indicate that separate load nit: Is this "optional capability TLV" the same "optional TLV" that we are defining in this document? If so, calling it "the new optional LSR capability" would aid clarity. (Also, we seem to use both the "capability" and "Capability" capitzliations for describing this TLV.) Section 3 Capability TLV in the MPLS echo request message. When the responder LSR receives an MPLS echo request message with the LSR Capability TLV included, if it knows the LSR Capability TLV, then it MUST include the LSR Capability TLV in the MPLS echo reply message with the LSR Capability TLV describing features and extensions supported by the local LSR. Otherwise, an MPLS echo reply MUST be sent back to the initiator LSR with the return code set to "One or more of the TLVs was not understood". [...] This last MUST seems like something that this document cannot mandate (as it attempts to apply to non-implementations of this document); it could only work if it was an existing requirement from the core MPLS spec, in which case lower-case "must" is appropriate (possibly with section reference). o If the responder LSR does not understand the "LAG Description Indicator flag": * Clear both the "Downstream LAG Info Accommodation flag" and the "Upstream LAG Info Accommodation flag". Similarly, if an LSR does not understand a flag, it cannot give special treatment to packets containing that flag. (Why an LSR would not understand a flag defined in the same document that defines the Capabilities TLV is beyond me, but you seem to want to allow for that case.) If the responder does not know the LSR Capability TLV, an MPLS echo reply with the return code set to "One or more of the TLVs was not understood" MUST be sent back to the initiator LSR. This duplicates the content I quoted at the top of this section's comments. Section 4.1 Once the initiator LSR knows the capabilities that a responder supports, then it sends an MPLS echo request carrying a DDMAP with the "LAG Description Indicator flag" (G) set to the responder LSR. nit: I think the key point is not that the initiator knows the capabilities of the peer, but rather that the initiator knows that the peer supports this specific mechanism. Also, is this "a DDMAP TLV"? Section 4.2 Reading this makes it sound like the "LAG Description Indicator flag" is completely orthogonal to regular DDMAP functionality, so that if I set the LAG description indicator flag but do not otherwise request detailed descriptions, only the LAG interfaces are returned. However, the flag in question has to be inside a DDMAP TLV (and we should really say so, perhaps as "[flag] set *in the DDMAP TLV*"!), so it seems like in practice the LAG information can only be obtained in conjunction with full detailed description information. (The specific suggestion here is to note clearly that the flag is se in the DDMAP TLV.) * The responder LSR MUST include a DDMAP TLV when sending the MPLS echo reply. I got confused on my first pass through this section; adding "There is a single DDMAP TLV for the LAG interface, with member links described using sub-TLVs" here would have kept me from veering onto the wrong path. (I thought there was going to be one DDMAP TLV per member link, plus one for the LAG aggregate, with lots of duplication.) Based on the procedures described above, every LAG member link will have a Local Interface Index Sub-TLV and a Multipath Data Sub-TLV entries in the DDMAP TLV. The order of the Sub-TLVs in the DDMAP TLV for a LAG member link MUST be Local Interface Index Sub-TLV immediately followed by Multipath Data Sub-TLV. A LAG member link MAY also have a corresponding Remote Interface Index Sub-TLV. When a Local Interface Index Sub-TLV, a Remote Interface Index-Sub-TLV and a Multipath Data Sub-TLV are placed in the DDMAP TLV to describe a LAG member link, they MUST be placed in the order of Local Interface Index Sub-TLV, Remote Interface Index-Sub-TLV and Multipath Data Sub- TLV. This last MUST contradicts the previous MUST. I suggest some more text to clarify under which conditions each requirement applies. I'd also suggest not using the figure for conveying a (apparent?) mandatory requirement, and instead adding some text at the end: "The block of local interface index, (optional remote interface index) and multipath data sub-TLVs for each member link MUST appear adjacent to each other in order of increasing local interface index." It's confusing to label the multiplath data sub-TLV as "MANDATORY" when the body text says "MUST add an [sic] Multipath data Sub-TLV [...] if the received DDMAP TLV requested multipath information", i.e., it is not always present, based on the contents of the echo request. When none of the received multipath information maps to a particular LAG member link, then the responder LSR MUST still place the Local Interface Index Sub-TLV and the Multipath Data Sub-TLV for that LAG member link in the DDMAP TLV, the value of Multipath Length field of the Multipath Data Sub-TLV is set to zero. nit: the last comma is a comma splice. Section 5.1.2 It seems like this places a slightly stronger burden on the responder than stock 8029 does, in that there is a MUST-level requirement to act on the 'I' flag in combination with the 'G' flag, whereas for the 'I' flag alone 8029 only has a SHOULD-level requirement to respond accordingly. We may want to call this out as a change in behavior. Section 5.1.3 Expectation is that there's a relationship between the interface index of the outgoing LAG member link at TTL=n and the interface index of the incoming LAG member link at TTL=n+1 for all discovered entropies. In other words, set of entropies that load balances to nit: "The expectation" nit: "discovered entropies" is a strange wording given how the entropy label works; is this more like "all entropies examined"? The initiator LSR sends two MPLS echo request messages to traverse the two LAG member links at TTL=n+1: How does the initiator know (which entropy label values?) to get the echo requests to traverse different member links? o Error case: * One MPLS echo request message reaches TTL=n+1 on an LAG member link 1. * The other MPLS echo request message also reaches TTL=n+1 on an LAG member link 1. One or two MPLS echo request messages sent by the initiator LSR cannot reach the immediate downstream LSR, or the two MPLS echo request messages reach at the immediate downstream LSR from the same LAG member link. The description paragraph doesn't seem to match up the scenario described in the sub-bullets, which leaves me confused as to what scenario(s) are intended to be considered as the "error case". Section 6 This document defines a new optional TLV which is referred to as the "LSR Capability TLV. [...] Is this optional to use or comprehension-optional? (We elsewhere rely on comprehension-mandatory behavior, so in the RFC 8029 terminology this seems to be a "mandatory TLV" even if it is not mandatory to use.) included in the MPLS echo reply message. Otherwise, if the responder does not know the LSR Capability TLV, an MPLS echo reply with the return code set to "One or more of the TLVs was not understood" MUST be sent back to the initiator LSR. This duplicates a requirement stated elsewhere (that really ought to just be using existing required behavior from 8029 anyway). LSR Capability TLV Type is TBD1. Length is 4. The value field of In a hypothetical future where we need to allocate a 33rd capability flag, would we rather create a new "extended capabilities" TLV (burning another 32 bits for type+length) or leave flexibility now for 'length' to increase in multiples of 4 with receivers ignoring bits past what they know about? The "LSR Capability Flags" field is 4 octets in length, this document defines the following flags: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Must Be Zero (Reserved) |U|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I'm wary of describing these as "Must Be Zero", since they're just unallocated but not required to be zero other than by the current state of bit allocations. (I guess this is conventional for MPLS, though? So maybe it's not a problem.) Just "Reserved" would be fine. This document defines two flags. The remaining flags MUST be set to zero when sending and ignored on receipt. Both the U and the D flag MUST be cleared in the MPLS echo request message when sending, and ignored on receipt. Neither, either or both the U and the D flag MAY be set in the MPLS echo reply message. Similarly, I think we want to say "unallocated flags" rather than "the remaining flags". It also seems like the semantics being described here are "the TLV value is ignored in the echo request and only has meaning in the response" (i.e., this is a "tell me your capabilities" exchange, not a "here are mine; what are yours?" exchange). As written, that applies only to the U and D bits, and is not a general property. That may well be a fine choice if we think we might want the two-way exchange for some future allocated bit, but if we do think it's a general property of the mechanism, I'd suggest rewording the text. Section 7 (Per IANA, bits 4 and 5 are already assigned but are not reflected in the diagram.) Section 10 The Detailed Interface and Label Stack TLV format is derived from the Interface and Label Stack TLV format (from [RFC8029]). Two changes are introduced. The first is that the label stack is converted into a sub-TLV. The second is that a new sub-TLV is added to describe an interface index. These fields of Detailed Interface and Label Stack TLV have the same use and meaning as in [RFC8029]. A summary of these fields is as below: nit: Are "These fields" just "The other fields"? The Address Type indicates if the interface is numbered or unnumbered. It also determines the length of the IP Address and Interface fields. The resulting total length of the initial part of the TLV is listed as "K Octets". The Address Type is set to one of the following values: nit: is it better to list the currently allocated values or just refer to the IANA registry? I seee that this "index assigned to the interface" language for unnumbered address types originates from RFC 8029, but both this document and 8029 leave me confused as to the encoding used for this index (for either/both IPv4 or IPv6 address types). [My comment about "Must Be Zero" and allocatable bits also applies here] Section 12 This document also adds a capability "negotiation" mechanism for MPLS echo request/reply exchanges. As MPLS does not offer integrity protection for its messages, this negotiation is only as trustworthy as the network from which messages are accepted as valid, and initiators have no recourse but to accept faithfully the echo replies received. To prevent leakage of vital information to untrusted users, a responder LSR MUST only accept MPLS echo request messages from designated trusted sources via filtering source IP address field of received MPLS echo request messages. [...] I'd prefer to see a note added here about how "source IP address filtering provides only a weak form of access control and is not, in general, a reliable security mechanism. Nonetheless, it is required here in the absence of any more robust mechanism that might be used." Section 13 Should we ask IANA to update the "Interface and Label Stack Address Types" registry to also refer to this document, since we are sharing the registry between the Interface and Label Stack TLV and the Detailed version? Section 13.2 The range 4-31743 spans two different allocation procedures (Standards Action and Specification Required - Experimental RFC needed); I assume that we want the 4-16383 range for Standards Action - mandatory TLVs. Section 13.4 We don't say what range we want this to be allocated from -- I assume 4-16383 since this is a negotiated feature and sending it outside the negotiated scenario should be an error. Section 13.4.1 (I note that some existing sub-TLV registries have "Experimental RFC required" for the experimental ranges, but that is arguably more stringent than necessary; Specification Required seems more appropriate for this case.) Appendix A I was kind of hoping for some more guidance on what an initiator could do in these scenarios to try to get better visibility into the switch behavior (and, hopefully, a workaround to get reliable echo responses that cover all LAG member links). AFAICT there's not a better option than "try a bunch of entropy labels and see what responses you can get back" and that's the same remedy in all the described topologies, but it would be nice to have this stated explicitly for the reader. Section A.1 In the worst case, MPLS echo request messages with specific entropies to exercise every LAG members from R1 to S1 can all reach R2 via same LAG member. [...] I'm confused by the phrase "specific entropies to exercise every LAG members [sic] from R1 to S1" -- is there some deterministic algorithm by which a specific entropy label value will force a specific LAG member link? My understanding was that the entropy was used as input to an opaque hash function and that trial-and-error was the only way to explore the mapping from entropy value to LAG member link taken. From nobody Thu Apr 4 04:24:25 2019 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 36966120092; Thu, 4 Apr 2019 04:24:19 -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.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <155437705914.30923.8905323001003047071@ietfa.amsl.com> Date: Thu, 04 Apr 2019 04:24:19 -0700 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-lag-multipath-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 11:24:19 -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 WG 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-08.txt Pages : 28 Date : 2019-04-04 Abstract: This document defines extensions to the MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. Additionally, a mechanism is defined to enable determination of the capabilities of an LSR supported. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-lsp-ping-lag-multipath-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-lag-multipath-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 Thu Apr 4 04:24:44 2019 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 DC9BA120495; Thu, 4 Apr 2019 04:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItV5hA4al-2R; Thu, 4 Apr 2019 04:24:27 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 3F0B11206A9; Thu, 4 Apr 2019 04:24:27 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 2A6A6955F03197551250; Thu, 4 Apr 2019 12:24:25 +0100 (IST) Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 4 Apr 2019 12:24:24 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.113]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0415.000; Thu, 4 Apr 2019 19:24:22 +0800 From: Mach Chen To: Benjamin Kaduk , The IESG CC: "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" , "mpls-chairs@ietf.org" , "loa@pi.nu" , "mpls@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-lag-multipath-07: (with DISCUSS and COMMENT) Thread-Index: AQHU6jioOlipL0w4g0qDJ1tOkPDTlKYrPATg Date: Thu, 4 Apr 2019 11:24:22 +0000 Message-ID: References: <155430820919.22676.3438359950422110370.idtracker@ietfa.amsl.com> In-Reply-To: <155430820919.22676.3438359950422110370.idtracker@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-lag-multipath-07: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 11:24:37 -0000 SGkgQmVuamFtaW4sDQoNClRoYW5rcyBmb3IgeW91ciBwcm9tcHQgcmVzcG9uc2UhDQoNClBsZWFz ZSBzZWUgbXkgcmVwbGllcyBpbmxpbmUuLi4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBCZW5qYW1pbiBLYWR1ayB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5 QGlldGYub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMDQsIDIwMTkgMTI6MTcgQU0NCj4g VG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1tcGxzLWxzcC1w aW5nLWxhZy1tdWx0aXBhdGhAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQGlldGYub3JnOw0KPiBsb2FA cGkubnU7IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogQmVuamFtaW4gS2FkdWsncyBEaXNjdXNz IG9uIGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1sYWctbXVsdGlwYXRoLQ0KPiAwNzogKHdpdGgg RElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IEJlbmphbWluIEthZHVrIGhhcyBlbnRlcmVkIHRo ZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLW1wbHMtbHNwLXBp bmctbGFnLW11bHRpcGF0aC0wNzogRGlzY3Vzcw0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVh c2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+ IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRv IGN1dCB0aGlzIGludHJvZHVjdG9yeQ0KPiBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+ IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNj dXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVND VVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1sYWct bXVsdGlwYXRoLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gDQo+IFRoYW5rcyBmb3IgdGhlIHVwZGF0ZXMgaW4gdGhlIC0wNzsgd2Ug c2VlbSB0byBiZSBpbiBhZ3JlZW1lbnQgb24gdGhlIG1haW4NCj4gcGF0aCBmb3J3YXJkLiAgVGhh dCBzYWlkLCBpbiBTZWN0aW9uIDQuMiB3ZSBzdGlsbCBzZWUgdGhhdDoNCj4gDQo+ICAgIEJhc2Vk IG9uIHRoZSBwcm9jZWR1cmVzIGRlc2NyaWJlZCBhYm92ZSwgZXZlcnkgTEFHIG1lbWJlciBsaW5r IHdpbGwNCj4gICAgaGF2ZSBhIExvY2FsIEludGVyZmFjZSBJbmRleCBTdWItVExWIGFuZCBhIE11 bHRpcGF0aCBEYXRhIFN1Yi1UTFYNCj4gICAgZW50cmllcyBpbiB0aGUgRERNQVAgVExWLiAgVGhl IG9yZGVyIG9mIHRoZSBTdWItVExWcyBpbiB0aGUgRERNQVAgVExWDQo+ICAgIGZvciBhIExBRyBt ZW1iZXIgbGluayBNVVNUIGJlIExvY2FsIEludGVyZmFjZSBJbmRleCBTdWItVExWDQo+ICAgIGlt bWVkaWF0ZWx5IGZvbGxvd2VkIGJ5IE11bHRpcGF0aCBEYXRhIFN1Yi1UTFYuICBBIExBRyBtZW1i ZXIgbGluaw0KPiAgICBNQVkgYWxzbyBoYXZlIGEgY29ycmVzcG9uZGluZyBSZW1vdGUgSW50ZXJm YWNlIEluZGV4IFN1Yi1UTFYuICBXaGVuIGENCj4gICAgWy4uLl0NCj4gDQo+IEkgdGhpbmsgd2Ug bmVlZCAiZXhjZXB0IGFzIGZvbGxvd3MiIG9yIHNpbWlsYXIgYXQgdGhlIGVuZCBvZiB0aGUgc2Vj b25kDQo+IHNlbnRlbmNlLCBzaW5jZSBvdGhlcndpc2Ugd2UgZ28gb24gdG8gaGF2ZSBhIE1VU1Qg dGhhdCBjb250cmFkaWN0cyB0aGUNCj4gIk1VU1QgYmUgTG9jYWwgSW50ZXJmYWNlIEluZGV4IFsu Li5dIGltbWVkaWF0ZWx5IGZvbGxvd2VkIGJ5IE11bHRpcGF0aA0KPiBEYXRhIi4NCg0KSSBhbSBm aW5lIHRvIGFkZCAiZXhjZXB0IGFzIGZvbGxvd3MiLg0KDQo+IA0KPiAoQWxzbywgd2UgbWlzc2Vk IG9uZSBpbnN0YW5jZSBvZiAib3B0aW9uYWwiIGluIFNlY3Rpb24gODogIkxvY2FsIEludGVyZmFj ZQ0KPiBJbmRleCBTdWItVExWIGlzIGFuIG9wdGlvbmFsIFRMViIpDQo+IA0KPiANCg0KUmVnYXJk aW5nIHRoZSBmb2xsb3dpbmcgY29tbWVudHMsIG1vc3Qgb2YgdGhlbSBhZGRyZXNzZWQgaW4gdmVy c2lvbiAwNywgYSBmZXcgZml4ZWQgaW4gdmVyc2lvbiAwOC4NCg0KDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gQSBjb3VwbGUgbml0cyBpbiB0aGUg bmV3IHRleHQgaW4gdGhlIC0wNzogImFuIG5ldyIgKHNob3VsZCBiZSAiYSBuZXciKSBhbmQNCj4g Im1lY2hhbmltcyIgKHNob3VsZCBiZSAibWVjaGFuaXNtIikuDQoNCkZpeGVkIGluIHZlcnNpb24g MDguDQoNCj4gDQo+IFt0aGUgZm9sbG93aW5nIENPTU1FTlQgcG9ydGlvbiBoYXMgbm90IGJlZW4g cmV2aXNlZCBzaW5jZSB0aGUgYmFsbG90IG9uDQo+IHRoZSAtMDYgYW5kIG1heSBjb250YWluIHN0 YWxlIGluZm9ybWF0aW9uXQ0KPiANCj4gQW0gSSByZWFkaW5nIHRoaXMgY29ycmVjdGx5IHRoYXQg dGhlICJMU1IgQ2FwYWJpbGl0eSBUTFYiIGNyZWF0ZWQgaGVyZSBpcw0KPiBiYXNpY2FsbHkgb25s eSBhcHBsaWNhYmxlIHRvIHByb3BlcnRpZXMgb2YgTVBMUyBlY2hvIHJlcXVlc3QvcmVwbHkgZXhj aGFuZ2VzPw0KPiBJZiBzbywgdGhlbiBwZXJoYXBzIHRoZSBtb25pa2VyICJMU1IgQ2FwYWJpbGl0 eSIgaXMgb3Zlcmx5IGdlbmVyaWMuDQoNCkFsdGhvdWdoIHRoZSAiTFNSIENhcGFiaWxpdHkgVExW IiBpcyBjdXJyZW50bHkgdXNlZCBmb3IgTFNQIFBpbmcsIGl0IGFjdHVhbGx5IGNhbiBiZSBhcHBs aWNhYmxlIGZvciBtb3JlIGdlbmVyaWMgcHVycG9zZS4gSSBpbmNsaW5lIHRvIGtlZXAgaXQgYXMt aXMuIA0KDQo+IA0KPiBTZWN0aW9uIDEuMg0KPiANCj4gICAgbyAgTGFiZWwgc3dpdGNoaW5nIG92 ZXIgc29tZSBtZW1iZXIgbGlua3Mgb2YgdGhlIExBRyBpcyBzdWNjZXNzZnVsLA0KPiAgICAgICBi dXQgd2lsbCBiZSBmYWlsZWQgb3ZlciBvdGhlciBtZW1iZXIgbGlua3Mgb2YgdGhlIExBRy4NCj4g DQo+IG5pdDogdGhlcmUncyBzb21lIHZlcmIgdGVuc2UgaW5jb25zaXN0ZW5jeSBoZXJlOyBtYXli ZSAiYnV0IGZhaWxzIG92ZXIgb3RoZXINCj4gbWVtYmVyIGxpbmtzIiB3b3VsZCBoZWxwLg0KDQpT ZWVtcyBpdCBoYXMgYmVlbiBhZGRyZXNzZWQgaW4gdmVyc2lvbiAwNy4NCg0KPiANCj4gU2VjdGlv biAyDQo+IA0KPiAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4gb3B0aW9uYWwgVExWIHRvIGRp c2NvdmVyIHRoZSBjYXBhYmlsaXRpZXMgb2YNCj4gICAgYSByZXNwb25kZXIgTFNSIGFuZCBleHRl bnNpb25zIGZvciB1c2Ugd2l0aCB0aGUgTVBMUyBMU1AgUGluZyBhbmQNCj4gDQo+IG5pdDogaXMg aXQgb25seSB0aGUgKnJlc3BvbmRlciogTFNSIHdlIGNhcmUgYWJvdXQsIG9yIGFyZSB0aGVyZSBw b3RlbnRpYWxseQ0KPiBpbnRlcm1lZGlhcmllcyBpbiBwbGF5Pw0KDQpPbmx5IHRoZSByZXNwb25k ZXIgTFNSIHdlIGNhcmUgYWJvdXQuDQoNCj4gDQo+ICAgIFRoZSBzb2x1dGlvbiBjb25zaXN0cyBv ZiB0aGUgTVBMUyBlY2hvIHJlcXVlc3QgY29udGFpbmluZyBhIERETUFQIFRMVg0KPiAgICBhbmQg dGhlIG9wdGlvbmFsIExTUiBjYXBhYmlsaXR5IFRMViB0byBpbmRpY2F0ZSB0aGF0IHNlcGFyYXRl IGxvYWQNCj4gDQo+IG5pdDogSXMgdGhpcyAib3B0aW9uYWwgY2FwYWJpbGl0eSBUTFYiIHRoZSBz YW1lICJvcHRpb25hbCBUTFYiIHRoYXQgd2UgYXJlDQo+IGRlZmluaW5nIGluIHRoaXMgZG9jdW1l bnQ/ICBJZiBzbywgY2FsbGluZyBpdCAidGhlIG5ldyBvcHRpb25hbCBMU1IgY2FwYWJpbGl0eSIN Cj4gd291bGQgYWlkIGNsYXJpdHkuICANCg0KKEFsc28sIHdlIHNlZW0gdG8gdXNlIGJvdGggdGhl ICJjYXBhYmlsaXR5IiBhbmQNCj4gIkNhcGFiaWxpdHkiIGNhcGl0emxpYXRpb25zIGZvciBkZXNj cmliaW5nIHRoaXMgVExWLikNCg0KT25seSBvbmUgbGVmdCwgZml4ZWQgaW4gdmVyc2lvbiAwOC4N Cg0KPiANCj4gU2VjdGlvbiAzDQo+IA0KPiAgICBDYXBhYmlsaXR5IFRMViBpbiB0aGUgTVBMUyBl Y2hvIHJlcXVlc3QgbWVzc2FnZS4gIFdoZW4gdGhlIHJlc3BvbmRlcg0KPiAgICBMU1IgcmVjZWl2 ZXMgYW4gTVBMUyBlY2hvIHJlcXVlc3QgbWVzc2FnZSB3aXRoIHRoZSBMU1IgQ2FwYWJpbGl0eSBU TFYNCj4gICAgaW5jbHVkZWQsIGlmIGl0IGtub3dzIHRoZSBMU1IgQ2FwYWJpbGl0eSBUTFYsIHRo ZW4gaXQgTVVTVCBpbmNsdWRlDQo+ICAgIHRoZSBMU1IgQ2FwYWJpbGl0eSBUTFYgaW4gdGhlIE1Q TFMgZWNobyByZXBseSBtZXNzYWdlIHdpdGggdGhlIExTUg0KPiAgICBDYXBhYmlsaXR5IFRMViBk ZXNjcmliaW5nIGZlYXR1cmVzIGFuZCBleHRlbnNpb25zIHN1cHBvcnRlZCBieSB0aGUNCj4gICAg bG9jYWwgTFNSLiAgT3RoZXJ3aXNlLCBhbiBNUExTIGVjaG8gcmVwbHkgTVVTVCBiZSBzZW50IGJh Y2sgdG8gdGhlDQo+ICAgIGluaXRpYXRvciBMU1Igd2l0aCB0aGUgcmV0dXJuIGNvZGUgc2V0IHRv ICJPbmUgb3IgbW9yZSBvZiB0aGUgVExWcw0KPiAgICB3YXMgbm90IHVuZGVyc3Rvb2QiLiAgWy4u Ll0NCj4gDQo+IFRoaXMgbGFzdCBNVVNUIHNlZW1zIGxpa2Ugc29tZXRoaW5nIHRoYXQgdGhpcyBk b2N1bWVudCBjYW5ub3QgbWFuZGF0ZSAoYXMNCj4gaXQgYXR0ZW1wdHMgdG8gYXBwbHkgdG8gbm9u LWltcGxlbWVudGF0aW9ucyBvZiB0aGlzIGRvY3VtZW50KTsgaXQgY291bGQgb25seQ0KPiB3b3Jr IGlmIGl0IHdhcyBhbiBleGlzdGluZyByZXF1aXJlbWVudCBmcm9tIHRoZSBjb3JlIE1QTFMgc3Bl YywgaW4gd2hpY2gNCj4gY2FzZSBsb3dlci1jYXNlICJtdXN0IiBpcyBhcHByb3ByaWF0ZSAocG9z c2libHkgd2l0aCBzZWN0aW9uIHJlZmVyZW5jZSkuDQoNClRoaXMgaXMgYWRkcmVzc2VkIGluIHZl cnNpb24gMDcgYnkgZm9sbG93aW5nIHByb3Bvc2FsOg0KDQoiT3RoZXJ3aXNlLCBhbiBNUExTIGVj aG8gcmVwbHkgbXVzdCBiZSBzZW50IGJhY2sgdG8gdGhlIGluaXRpYXRvciBMU1Igd2l0aCB0aGUg cmV0dXJuIGNvZGUgc2V0IHRvICJPbmUgb3IgbW9yZSBvZiB0aGUgVExWcyB3YXMgbm90IHVuZGVy c3Rvb2QiLCBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIGFzIGRlZmluZWQgU2VjdGlvbiAzIG9mIFJG QzgwMjkuIg0KDQpJcyB0aGlzIE9LIGZvciB5b3U/DQoNCj4gDQo+ICAgIG8gIElmIHRoZSByZXNw b25kZXIgTFNSIGRvZXMgbm90IHVuZGVyc3RhbmQgdGhlICJMQUcgRGVzY3JpcHRpb24NCj4gICAg ICAgSW5kaWNhdG9yIGZsYWciOg0KPiANCj4gICAgICAgKiAgQ2xlYXIgYm90aCB0aGUgIkRvd25z dHJlYW0gTEFHIEluZm8gQWNjb21tb2RhdGlvbiBmbGFnIiBhbmQgdGhlDQo+ICAgICAgICAgICJV cHN0cmVhbSBMQUcgSW5mbyBBY2NvbW1vZGF0aW9uIGZsYWciLg0KPiANCj4gU2ltaWxhcmx5LCBp ZiBhbiBMU1IgZG9lcyBub3QgdW5kZXJzdGFuZCBhIGZsYWcsIGl0IGNhbm5vdCBnaXZlIHNwZWNp YWwNCj4gdHJlYXRtZW50IHRvIHBhY2tldHMgY29udGFpbmluZyB0aGF0IGZsYWcuICAoV2h5IGFu IExTUiB3b3VsZCBub3QNCj4gdW5kZXJzdGFuZCBhIGZsYWcgZGVmaW5lZCBpbiB0aGUgc2FtZSBk b2N1bWVudCB0aGF0IGRlZmluZXMgdGhlIENhcGFiaWxpdGllcw0KPiBUTFYgaXMgYmV5b25kIG1l LCBidXQgeW91IHNlZW0gdG8gd2FudCB0byBhbGxvdyBmb3IgdGhhdA0KPiBjYXNlLikNCg0KVGhp cyBoYXMgYmVlbiBmaXhlZCBpbiB2ZXJzaW9uIDA3IGJ5IHJlbW92aW5nIHRoZSBhYm92ZSBidWxs ZXQuDQoNCj4gDQo+ICAgIElmIHRoZSByZXNwb25kZXIgZG9lcyBub3Qga25vdyB0aGUgTFNSIENh cGFiaWxpdHkgVExWLCBhbiBNUExTIGVjaG8NCj4gICAgcmVwbHkgd2l0aCB0aGUgcmV0dXJuIGNv ZGUgc2V0IHRvICJPbmUgb3IgbW9yZSBvZiB0aGUgVExWcyB3YXMgbm90DQo+ICAgIHVuZGVyc3Rv b2QiIE1VU1QgYmUgc2VudCBiYWNrIHRvIHRoZSBpbml0aWF0b3IgTFNSLg0KPiANCj4gVGhpcyBk dXBsaWNhdGVzIHRoZSBjb250ZW50IEkgcXVvdGVkIGF0IHRoZSB0b3Agb2YgdGhpcyBzZWN0aW9u J3MgY29tbWVudHMuDQoNClRoZSBkdXBsaWNhdGUgdGV4dCBoYXMgYmVlbiByZW1vdmVkIGluIHZl cnNpb24gMDcuDQoNCj4gDQo+IFNlY3Rpb24gNC4xDQo+IA0KPiAgICBPbmNlIHRoZSBpbml0aWF0 b3IgTFNSIGtub3dzIHRoZSBjYXBhYmlsaXRpZXMgdGhhdCBhIHJlc3BvbmRlcg0KPiAgICBzdXBw b3J0cywgdGhlbiBpdCBzZW5kcyBhbiBNUExTIGVjaG8gcmVxdWVzdCBjYXJyeWluZyBhIERETUFQ IHdpdGgNCj4gICAgdGhlICJMQUcgRGVzY3JpcHRpb24gSW5kaWNhdG9yIGZsYWciIChHKSBzZXQg dG8gdGhlIHJlc3BvbmRlciBMU1IuDQo+IA0KPiBuaXQ6IEkgdGhpbmsgdGhlIGtleSBwb2ludCBp cyBub3QgdGhhdCB0aGUgaW5pdGlhdG9yIGtub3dzIHRoZSBjYXBhYmlsaXRpZXMgb2YgdGhlDQo+ IHBlZXIsIGJ1dCByYXRoZXIgdGhhdCB0aGUgaW5pdGlhdG9yIGtub3dzIHRoYXQgdGhlIHBlZXIg c3VwcG9ydHMgdGhpcyBzcGVjaWZpYw0KPiBtZWNoYW5pc20uDQo+IEFsc28sIGlzIHRoaXMgImEg RERNQVAgVExWIj8NCg0KWWVzLCBmaXhlZCBpbiB2ZXJzaW9uIDA3LCB3aXRoIHRoZSBmb2xsb3dp bmcgdXBkYXRlLg0KDQoiT25jZSB0aGUgaW5pdGlhdG9yIExTUiBrbm93cyB0aGF0IGEgcmVzcG9u ZGVyIGNhbiBzdXBwb3J0IHRoaXMgbWVjaGFuaXNtLCB0aGVuIGl0IHNlbmRzIGFuIE1QTFMgZWNo byByZXF1ZXN0IGNhcnJ5aW5nIGEgRERNQVAgVExWIHdpdGggIHRoZSAiTEFHIERlc2NyaXB0aW9u IEluZGljYXRvciBmbGFnIiAoRykgc2V0IHRvIHRoZSByZXNwb25kZXIgTFNSLiINCg0KSXMgdGhp cyBPSyBmb3IgeW91Pw0KDQoNCj4gQWxzbywgaXMgdGhpcyAiYSBERE1BUCBUTFYiPw0KPiANCj4g U2VjdGlvbiA0LjINCj4gDQo+IFJlYWRpbmcgdGhpcyBtYWtlcyBpdCBzb3VuZCBsaWtlIHRoZSAi TEFHIERlc2NyaXB0aW9uIEluZGljYXRvciBmbGFnIiBpcw0KPiBjb21wbGV0ZWx5IG9ydGhvZ29u YWwgdG8gcmVndWxhciBERE1BUCBmdW5jdGlvbmFsaXR5LCBzbyB0aGF0IGlmIEkgc2V0IHRoZQ0K PiBMQUcgZGVzY3JpcHRpb24gaW5kaWNhdG9yIGZsYWcgYnV0IGRvIG5vdCBvdGhlcndpc2UgcmVx dWVzdCBkZXRhaWxlZA0KPiBkZXNjcmlwdGlvbnMsIG9ubHkgdGhlIExBRyBpbnRlcmZhY2VzIGFy ZSByZXR1cm5lZC4gIEhvd2V2ZXIsIHRoZSBmbGFnIGluDQo+IHF1ZXN0aW9uIGhhcyB0byBiZSBp bnNpZGUgYSBERE1BUCBUTFYgKGFuZCB3ZSBzaG91bGQgcmVhbGx5IHNheSBzbywgcGVyaGFwcw0K PiBhcyAiW2ZsYWddIHNldCAqaW4gdGhlIERETUFQIFRMVioiISksIHNvIGl0IHNlZW1zIGxpa2Ug aW4gcHJhY3RpY2UgdGhlIExBRw0KPiBpbmZvcm1hdGlvbiBjYW4gb25seSBiZSBvYnRhaW5lZCBp biBjb25qdW5jdGlvbiB3aXRoIGZ1bGwgZGV0YWlsZWQgZGVzY3JpcHRpb24NCj4gaW5mb3JtYXRp b24uICAoVGhlIHNwZWNpZmljIHN1Z2dlc3Rpb24gaGVyZSBpcyB0byBub3RlIGNsZWFybHkgdGhh dCB0aGUgZmxhZyBpcyBzZQ0KPiBpbiB0aGUgRERNQVAgVExWLikNCg0KRml4ZWQgaW4gdmVyc2lv biAwNyBhcyB5b3Ugc3VnZ2VzdGVkLg0KDQoNCj4gDQo+ICAgICAgICogIFRoZSByZXNwb25kZXIg TFNSIE1VU1QgaW5jbHVkZSBhIERETUFQIFRMViB3aGVuIHNlbmRpbmcgdGhlDQo+ICAgICAgICAg IE1QTFMgZWNobyByZXBseS4NCj4gDQo+IEkgZ290IGNvbmZ1c2VkIG9uIG15IGZpcnN0IHBhc3Mg dGhyb3VnaCB0aGlzIHNlY3Rpb247IGFkZGluZyAiVGhlcmUgaXMgYSBzaW5nbGUNCj4gRERNQVAg VExWIGZvciB0aGUgTEFHIGludGVyZmFjZSwgd2l0aCBtZW1iZXIgbGlua3MgZGVzY3JpYmVkIHVz aW5nIHN1Yi0NCj4gVExWcyIgaGVyZSB3b3VsZCBoYXZlIGtlcHQgbWUgZnJvbSB2ZWVyaW5nIG9u dG8gdGhlIHdyb25nIHBhdGguDQo+IChJIHRob3VnaHQgdGhlcmUgd2FzIGdvaW5nIHRvIGJlIG9u ZSBERE1BUCBUTFYgcGVyIG1lbWJlciBsaW5rLCBwbHVzIG9uZQ0KPiBmb3IgdGhlIExBRyBhZ2dy ZWdhdGUsIHdpdGggbG90cyBvZiBkdXBsaWNhdGlvbi4pDQoNCkZpeGVkIGluIHZlcnNpb24gMDcg YXMgeW91IHN1Z2dlc3RlZC4NCg0KPiANCj4gICAgQmFzZWQgb24gdGhlIHByb2NlZHVyZXMgZGVz Y3JpYmVkIGFib3ZlLCBldmVyeSBMQUcgbWVtYmVyIGxpbmsgd2lsbA0KPiAgICBoYXZlIGEgTG9j YWwgSW50ZXJmYWNlIEluZGV4IFN1Yi1UTFYgYW5kIGEgTXVsdGlwYXRoIERhdGEgU3ViLVRMVg0K PiAgICBlbnRyaWVzIGluIHRoZSBERE1BUCBUTFYuICBUaGUgb3JkZXIgb2YgdGhlIFN1Yi1UTFZz IGluIHRoZSBERE1BUCBUTFYNCj4gICAgZm9yIGEgTEFHIG1lbWJlciBsaW5rIE1VU1QgYmUgTG9j YWwgSW50ZXJmYWNlIEluZGV4IFN1Yi1UTFYNCj4gICAgaW1tZWRpYXRlbHkgZm9sbG93ZWQgYnkg TXVsdGlwYXRoIERhdGEgU3ViLVRMVi4gIEEgTEFHIG1lbWJlciBsaW5rDQo+ICAgIE1BWSBhbHNv IGhhdmUgYSBjb3JyZXNwb25kaW5nIFJlbW90ZSBJbnRlcmZhY2UgSW5kZXggU3ViLVRMVi4gIFdo ZW4gYQ0KPiAgICBMb2NhbCBJbnRlcmZhY2UgSW5kZXggU3ViLVRMViwgYSBSZW1vdGUgSW50ZXJm YWNlIEluZGV4LVN1Yi1UTFYgYW5kIGENCj4gICAgTXVsdGlwYXRoIERhdGEgU3ViLVRMViBhcmUg cGxhY2VkIGluIHRoZSBERE1BUCBUTFYgdG8gZGVzY3JpYmUgYSBMQUcNCj4gICAgbWVtYmVyIGxp bmssIHRoZXkgTVVTVCBiZSBwbGFjZWQgaW4gdGhlIG9yZGVyIG9mIExvY2FsIEludGVyZmFjZQ0K PiAgICBJbmRleCBTdWItVExWLCBSZW1vdGUgSW50ZXJmYWNlIEluZGV4LVN1Yi1UTFYgYW5kIE11 bHRpcGF0aCBEYXRhIFN1Yi0NCj4gICAgVExWLg0KPiANCj4gVGhpcyBsYXN0IE1VU1QgY29udHJh ZGljdHMgdGhlIHByZXZpb3VzIE1VU1QuICBJIHN1Z2dlc3Qgc29tZSBtb3JlIHRleHQgdG8NCj4g Y2xhcmlmeSB1bmRlciB3aGljaCBjb25kaXRpb25zIGVhY2ggcmVxdWlyZW1lbnQgYXBwbGllcy4N Cg0KQ2xhcmlmaWNhdGlvbiB0ZXh0IGFkZGVkIGluIHZlcnNpb24gMDcsIGFuZCBhZGQgImV4Y2Vw dCBhcyBmb2xsb3dzIiBhdCB0aGUgZW5kIG9mIHNlY29uZCBzZW50ZW5jZSBpbiB2ZXJzaW9uIDA4 Lg0KDQoNCj4gDQo+IEknZCBhbHNvIHN1Z2dlc3Qgbm90IHVzaW5nIHRoZSBmaWd1cmUgZm9yIGNv bnZleWluZyBhIChhcHBhcmVudD8pIG1hbmRhdG9yeQ0KPiByZXF1aXJlbWVudCwgYW5kIGluc3Rl YWQgYWRkaW5nIHNvbWUgdGV4dCBhdCB0aGUgZW5kOiAiVGhlIGJsb2NrIG9mIGxvY2FsDQo+IGlu dGVyZmFjZSBpbmRleCwgKG9wdGlvbmFsIHJlbW90ZSBpbnRlcmZhY2UgaW5kZXgpIGFuZCBtdWx0 aXBhdGggZGF0YSBzdWItDQo+IFRMVnMgZm9yIGVhY2ggbWVtYmVyIGxpbmsgTVVTVCBhcHBlYXIg YWRqYWNlbnQgdG8gZWFjaCBvdGhlciBpbiBvcmRlciBvZg0KPiBpbmNyZWFzaW5nIGxvY2FsIGlu dGVyZmFjZSBpbmRleC4iDQoNCkFkZGVkIHRoZSB0ZXh0IGFzIHlvdSBzdWdnZXN0ZWQgaW4gdmVy c2lvbiAwNy4NCg0KPiANCj4gSXQncyBjb25mdXNpbmcgdG8gbGFiZWwgdGhlIG11bHRpcGxhdGgg ZGF0YSBzdWItVExWIGFzICJNQU5EQVRPUlkiIHdoZW4NCj4gdGhlIGJvZHkgdGV4dCBzYXlzICJN VVNUIGFkZCBhbiBbc2ljXSBNdWx0aXBhdGggZGF0YSBTdWItVExWIFsuLi5dIGlmIHRoZQ0KPiBy ZWNlaXZlZCBERE1BUCBUTFYgcmVxdWVzdGVkIG11bHRpcGF0aCBpbmZvcm1hdGlvbiIsIGkuZS4s IGl0IGlzIG5vdCBhbHdheXMNCj4gcHJlc2VudCwgYmFzZWQgb24gdGhlIGNvbnRlbnRzIG9mIHRo ZSBlY2hvIHJlcXVlc3QuDQoNClNpbmNlIGl0J3MganVzdCBhbiBleGFtcGxlIGhlcmUsIHdpbGwg cmVtb3ZlIHRoZSBNQU5EQVRPUlkgYW5kIE9QVElPTkFMLg0KDQpGaXhlZCBpbiB2ZXJzaW9uIDA3 Lg0KDQo+IA0KPiAgICBXaGVuIG5vbmUgb2YgdGhlIHJlY2VpdmVkIG11bHRpcGF0aCBpbmZvcm1h dGlvbiBtYXBzIHRvIGEgcGFydGljdWxhcg0KPiAgICBMQUcgbWVtYmVyIGxpbmssIHRoZW4gdGhl IHJlc3BvbmRlciBMU1IgTVVTVCBzdGlsbCBwbGFjZSB0aGUgTG9jYWwNCj4gICAgSW50ZXJmYWNl IEluZGV4IFN1Yi1UTFYgYW5kIHRoZSBNdWx0aXBhdGggRGF0YSBTdWItVExWIGZvciB0aGF0IExB Rw0KPiAgICBtZW1iZXIgbGluayBpbiB0aGUgRERNQVAgVExWLCB0aGUgdmFsdWUgb2YgTXVsdGlw YXRoIExlbmd0aCBmaWVsZCBvZg0KPiAgICB0aGUgTXVsdGlwYXRoIERhdGEgU3ViLVRMViBpcyBz ZXQgdG8gemVyby4NCj4gDQo+IG5pdDogdGhlIGxhc3QgY29tbWEgaXMgYSBjb21tYSBzcGxpY2Uu DQoNCkZpeGVkIGluIHZlcnNpb24gMDcuDQoNCj4gDQo+IFNlY3Rpb24gNS4xLjINCj4gDQo+IEl0 IHNlZW1zIGxpa2UgdGhpcyBwbGFjZXMgYSBzbGlnaHRseSBzdHJvbmdlciBidXJkZW4gb24gdGhl IHJlc3BvbmRlciB0aGFuDQo+IHN0b2NrIDgwMjkgZG9lcywgaW4gdGhhdCB0aGVyZSBpcyBhIE1V U1QtbGV2ZWwgcmVxdWlyZW1lbnQgdG8gYWN0IG9uIHRoZSAnSScNCj4gZmxhZyBpbiBjb21iaW5h dGlvbiB3aXRoIHRoZSAnRycgZmxhZywgd2hlcmVhcyBmb3IgdGhlICdJJw0KPiBmbGFnIGFsb25l IDgwMjkgb25seSBoYXMgYSBTSE9VTEQtbGV2ZWwgcmVxdWlyZW1lbnQgdG8gcmVzcG9uZCBhY2Nv cmRpbmdseS4NCj4gV2UgbWF5IHdhbnQgdG8gY2FsbCB0aGlzIG91dCBhcyBhIGNoYW5nZSBpbiBi ZWhhdmlvci4NCg0KQ2hhbmdlZCB0byAiU0hPVUxEIiwgdGhlbiBpdCBjYW4gYWxpZ24gd2l0aCBS RkM4MDI5Lg0KDQpGaXhlZCBpbiB2ZXJzaW9uIDA3Lg0KDQo+IA0KPiBTZWN0aW9uIDUuMS4zDQo+ IA0KPiAgICBFeHBlY3RhdGlvbiBpcyB0aGF0IHRoZXJlJ3MgYSByZWxhdGlvbnNoaXAgYmV0d2Vl biB0aGUgaW50ZXJmYWNlDQo+ICAgIGluZGV4IG9mIHRoZSBvdXRnb2luZyBMQUcgbWVtYmVyIGxp bmsgYXQgVFRMPW4gYW5kIHRoZSBpbnRlcmZhY2UNCj4gICAgaW5kZXggb2YgdGhlIGluY29taW5n IExBRyBtZW1iZXIgbGluayBhdCBUVEw9bisxIGZvciBhbGwgZGlzY292ZXJlZA0KPiAgICBlbnRy b3BpZXMuICBJbiBvdGhlciB3b3Jkcywgc2V0IG9mIGVudHJvcGllcyB0aGF0IGxvYWQgYmFsYW5j ZXMgdG8NCj4gDQo+IG5pdDogIlRoZSBleHBlY3RhdGlvbiINCj4gbml0OiAiZGlzY292ZXJlZCBl bnRyb3BpZXMiIGlzIGEgc3RyYW5nZSB3b3JkaW5nIGdpdmVuIGhvdyB0aGUgZW50cm9weSBsYWJl bA0KPiB3b3JrczsgaXMgdGhpcyBtb3JlIGxpa2UgImFsbCBlbnRyb3BpZXMgZXhhbWluZWQiPw0K DQpGaXhlZCBpbiB2ZXJzaW9uIDA3Lg0KDQo+IA0KPiANCj4gICAgVGhlIGluaXRpYXRvciBMU1Ig c2VuZHMgdHdvIE1QTFMgZWNobyByZXF1ZXN0IG1lc3NhZ2VzIHRvIHRyYXZlcnNlDQo+ICAgIHRo ZSB0d28gTEFHIG1lbWJlciBsaW5rcyBhdCBUVEw9bisxOg0KPiANCj4gSG93IGRvZXMgdGhlIGlu aXRpYXRvciBrbm93ICh3aGljaCBlbnRyb3B5IGxhYmVsIHZhbHVlcz8pIHRvIGdldCB0aGUgZWNo bw0KPiByZXF1ZXN0cyB0byB0cmF2ZXJzZSBkaWZmZXJlbnQgbWVtYmVyIGxpbmtzPw0KDQpUaGUg aW5pdGlhdG9yIGNhbm5vdCBleGFjdGx5IGtub3cgd2hpY2ggZW50cm9weSBsYWJlbCB2YWx1ZXMg YXJlIHdvcmthYmxlLiBQcmVzdW1hYmx5LCB0aGUgaW5pdGlhdG9yIGNhbiBzZXQgZGlmZmVyZW50 IHZhbHVlcyBhY2NvcmRpbmcgdG8gdGhlIG51bWJlciBvZiBtZW1iZXIgbGlua3MsIHRoZW4gdGhl IHJlc3BvbmRlciBjYW4gdXNlIGVudHJvcHkgdmFsdWVzIGZvciBoYXNoIHRvIHRyYXZlcnNlIGRp ZmZlcmVudCBtZW1iZXIgbGluay4gVGhpcyBpcyBsZWZ0IHRvIGltcGxlbWVudGF0aW9uLg0KDQo+ IA0KPiAgICBvICBFcnJvciBjYXNlOg0KPiANCj4gICAgICAgKiAgT25lIE1QTFMgZWNobyByZXF1 ZXN0IG1lc3NhZ2UgcmVhY2hlcyBUVEw9bisxIG9uIGFuIExBRyBtZW1iZXINCj4gICAgICAgICAg bGluayAxLg0KPiANCj4gICAgICAgKiAgVGhlIG90aGVyIE1QTFMgZWNobyByZXF1ZXN0IG1lc3Nh Z2UgYWxzbyByZWFjaGVzIFRUTD1uKzEgb24gYW4NCj4gICAgICAgICAgTEFHIG1lbWJlciBsaW5r IDEuDQo+IA0KPiAgICAgICBPbmUgb3IgdHdvIE1QTFMgZWNobyByZXF1ZXN0IG1lc3NhZ2VzIHNl bnQgYnkgdGhlIGluaXRpYXRvciBMU1INCj4gICAgICAgY2Fubm90IHJlYWNoIHRoZSBpbW1lZGlh dGUgZG93bnN0cmVhbSBMU1IsIG9yIHRoZSB0d28gTVBMUyBlY2hvDQo+ICAgICAgIHJlcXVlc3Qg bWVzc2FnZXMgcmVhY2ggYXQgdGhlIGltbWVkaWF0ZSBkb3duc3RyZWFtIExTUiBmcm9tIHRoZQ0K PiAgICAgICBzYW1lIExBRyBtZW1iZXIgbGluay4NCj4gDQo+IFRoZSBkZXNjcmlwdGlvbiBwYXJh Z3JhcGggZG9lc24ndCBzZWVtIHRvIG1hdGNoIHVwIHRoZSBzY2VuYXJpbyBkZXNjcmliZWQNCj4g aW4gdGhlIHN1Yi1idWxsZXRzLCB3aGljaCBsZWF2ZXMgbWUgY29uZnVzZWQgYXMgdG8gd2hhdA0K PiBzY2VuYXJpbyhzKSBhcmUgaW50ZW5kZWQgdG8gYmUgY29uc2lkZXJlZCBhcyB0aGUgImVycm9y IGNhc2UiLg0KDQpUaGUgc3ViLWJ1bGxldHMgYXJlIG5vdCBjb21wbGV0ZSwgd2lsbCBhZGQgYSB0 aGlyZCBzdWItYnVsbGV0IGFzIGJlbG93Og0KDQoiT25lIG9yIGJvdGggTVBMUyBlY2hvIHJlcXVl c3QgbWVzc2FnZXMgY2Fubm90IHJlYWNoIHRoZSBpbW1lZGlhdGUgZG93bnN0cmVhbSBMU1Igb24g d2hpY2hldmVyIGxpbmsuIg0KDQpGaXhlZCBpbiB2ZXJzaW9uIDA3Lg0KDQo+IA0KPiBTZWN0aW9u IDYNCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBvcHRpb25hbCBUTFYgd2hp Y2ggaXMgcmVmZXJyZWQgdG8gYXMgdGhlDQo+ICAgICJMU1IgQ2FwYWJpbGl0eSBUTFYuICBbLi4u XQ0KPiANCj4gSXMgdGhpcyBvcHRpb25hbCB0byB1c2Ugb3IgY29tcHJlaGVuc2lvbi1vcHRpb25h bD8gIChXZSBlbHNld2hlcmUgcmVseSBvbg0KPiBjb21wcmVoZW5zaW9uLW1hbmRhdG9yeSBiZWhh dmlvciwgc28gaW4gdGhlIFJGQyA4MDI5IHRlcm1pbm9sb2d5IHRoaXMNCj4gc2VlbXMgdG8gYmUg YSAibWFuZGF0b3J5IFRMViIgZXZlbiBpZiBpdCBpcyBub3QgbWFuZGF0b3J5IHRvIHVzZS4pDQoN ClNlZSB0aGUgcmVwbHkgdG8gQWx2YXJvLg0KDQpGaXhlZCBpbiB2ZXJzaW9uIDA3Lg0KDQo+IA0K PiAgICBpbmNsdWRlZCBpbiB0aGUgTVBMUyBlY2hvIHJlcGx5IG1lc3NhZ2UuICBPdGhlcndpc2Us IGlmIHRoZSByZXNwb25kZXINCj4gICAgZG9lcyBub3Qga25vdyB0aGUgTFNSIENhcGFiaWxpdHkg VExWLCBhbiBNUExTIGVjaG8gcmVwbHkgd2l0aCB0aGUNCj4gICAgcmV0dXJuIGNvZGUgc2V0IHRv ICJPbmUgb3IgbW9yZSBvZiB0aGUgVExWcyB3YXMgbm90IHVuZGVyc3Rvb2QiIE1VU1QNCj4gICAg YmUgc2VudCBiYWNrIHRvIHRoZSBpbml0aWF0b3IgTFNSLg0KPiANCj4gVGhpcyBkdXBsaWNhdGVz IGEgcmVxdWlyZW1lbnQgc3RhdGVkIGVsc2V3aGVyZSAodGhhdCByZWFsbHkgb3VnaHQgdG8ganVz dCBiZQ0KPiB1c2luZyBleGlzdGluZyByZXF1aXJlZCBiZWhhdmlvciBmcm9tIDgwMjkgYW55d2F5 KS4NCg0KRHVwbGljYXRlIHRleHQgcmVtb3ZlZCBpbiB2ZXJzaW9uIDA3Lg0KDQo+IA0KPiAgICBM U1IgQ2FwYWJpbGl0eSBUTFYgVHlwZSBpcyBUQkQxLiAgTGVuZ3RoIGlzIDQuICBUaGUgdmFsdWUg ZmllbGQgb2YNCj4gDQo+IEluIGEgaHlwb3RoZXRpY2FsIGZ1dHVyZSB3aGVyZSB3ZSBuZWVkIHRv IGFsbG9jYXRlIGEgMzNyZCBjYXBhYmlsaXR5IGZsYWcsDQo+IHdvdWxkIHdlIHJhdGhlciBjcmVh dGUgYSBuZXcgImV4dGVuZGVkIGNhcGFiaWxpdGllcyIgVExWIChidXJuaW5nIGFub3RoZXINCj4g MzIgYml0cyBmb3IgdHlwZStsZW5ndGgpIG9yIGxlYXZlIGZsZXhpYmlsaXR5IG5vdyBmb3IgJ2xl bmd0aCcNCj4gdG8gaW5jcmVhc2UgaW4gbXVsdGlwbGVzIG9mIDQgd2l0aCByZWNlaXZlcnMgaWdu b3JpbmcgYml0cyBwYXN0IHdoYXQgdGhleSBrbm93DQo+IGFib3V0Pw0KDQpJTUhPLCAzMiBiaXQg c2VlbXMgcmVhc29uYWJsZSBlbm91Z2ggZm9yIG1lLiBJIGluY2xpbmUgdG8ga2VlcCB0aGUgZmxh ZyBmaWVsZCBhcyBpcy4NCg0KPiANCj4gICAgICAgVGhlICJMU1IgQ2FwYWJpbGl0eSBGbGFncyIg ZmllbGQgaXMgNCBvY3RldHMgaW4gbGVuZ3RoLCB0aGlzDQo+ICAgICAgIGRvY3VtZW50IGRlZmlu ZXMgdGhlIGZvbGxvd2luZyBmbGFnczoNCj4gDQo+ICAgICAgIDAgICAgICAgICAgICAgICAgICAg MSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCj4gICAgICAgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx DQo+ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCj4gICAgICB8ICAgICAgICAgICAgICAgICAgTXVzdCBCZSBaZXJv IChSZXNlcnZlZCkgICAgICAgICAgICAgICAgICB8VXxEfA0KPiAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IA0K PiBJJ20gd2FyeSBvZiBkZXNjcmliaW5nIHRoZXNlIGFzICJNdXN0IEJlIFplcm8iLCBzaW5jZSB0 aGV5J3JlIGp1c3QgdW5hbGxvY2F0ZWQNCj4gYnV0IG5vdCByZXF1aXJlZCB0byBiZSB6ZXJvIG90 aGVyIHRoYW4gYnkgdGhlIGN1cnJlbnQgc3RhdGUgb2YgYml0IGFsbG9jYXRpb25zLg0KPiAoSSBn dWVzcyB0aGlzIGlzIGNvbnZlbnRpb25hbCBmb3IgTVBMUywgdGhvdWdoPyAgU28gbWF5YmUgaXQn cyBub3QgYSBwcm9ibGVtLikNCj4gSnVzdCAiUmVzZXJ2ZWQiIHdvdWxkIGJlIGZpbmUuDQoNCkNo YW5nZWQgdG8gcmVzZXJ2ZWQsIGZpeGVkIGluIHZlcnNpb24gMDcuDQoNCj4gDQo+ICAgICAgIFRo aXMgZG9jdW1lbnQgZGVmaW5lcyB0d28gZmxhZ3MuICBUaGUgcmVtYWluaW5nIGZsYWdzIE1VU1Qg YmUgc2V0DQo+ICAgICAgIHRvIHplcm8gd2hlbiBzZW5kaW5nIGFuZCBpZ25vcmVkIG9uIHJlY2Vp cHQuICBCb3RoIHRoZSBVIGFuZCB0aGUgRA0KPiAgICAgICBmbGFnIE1VU1QgYmUgY2xlYXJlZCBp biB0aGUgTVBMUyBlY2hvIHJlcXVlc3QgbWVzc2FnZSB3aGVuDQo+ICAgICAgIHNlbmRpbmcsIGFu ZCBpZ25vcmVkIG9uIHJlY2VpcHQuICBOZWl0aGVyLCBlaXRoZXIgb3IgYm90aCB0aGUgVQ0KPiAg ICAgICBhbmQgdGhlIEQgZmxhZyBNQVkgYmUgc2V0IGluIHRoZSBNUExTIGVjaG8gcmVwbHkgbWVz c2FnZS4NCj4gDQo+IFNpbWlsYXJseSwgSSB0aGluayB3ZSB3YW50IHRvIHNheSAidW5hbGxvY2F0 ZWQgZmxhZ3MiIHJhdGhlciB0aGFuICJ0aGUNCj4gcmVtYWluaW5nIGZsYWdzIi4NCg0KRml4ZWQg aW4gdmVyc2lvbiAwNy4NCg0KPiANCj4gSXQgYWxzbyBzZWVtcyBsaWtlIHRoZSBzZW1hbnRpY3Mg YmVpbmcgZGVzY3JpYmVkIGhlcmUgYXJlICJ0aGUgVExWIHZhbHVlIGlzDQo+IGlnbm9yZWQgaW4g dGhlIGVjaG8gcmVxdWVzdCBhbmQgb25seSBoYXMgbWVhbmluZyBpbiB0aGUgcmVzcG9uc2UiDQo+ IChpLmUuLCB0aGlzIGlzIGEgInRlbGwgbWUgeW91ciBjYXBhYmlsaXRpZXMiIGV4Y2hhbmdlLCBu b3QgYSAiaGVyZSBhcmUgbWluZTsgd2hhdA0KPiBhcmUgeW91cnM/IiBleGNoYW5nZSkuICBBcyB3 cml0dGVuLCB0aGF0IGFwcGxpZXMgb25seSB0byB0aGUgVSBhbmQgRCBiaXRzLCBhbmQNCj4gaXMg bm90IGEgZ2VuZXJhbCBwcm9wZXJ0eS4gIFRoYXQgbWF5IHdlbGwgYmUgYSBmaW5lIGNob2ljZSBp ZiB3ZSB0aGluayB3ZSBtaWdodA0KPiB3YW50IHRoZSB0d28td2F5IGV4Y2hhbmdlIGZvciBzb21l IGZ1dHVyZSBhbGxvY2F0ZWQgYml0LCBidXQgaWYgd2UgZG8gdGhpbmsNCj4gaXQncyBhIGdlbmVy YWwgcHJvcGVydHkgb2YgdGhlIG1lY2hhbmlzbSwgSSdkIHN1Z2dlc3QgcmV3b3JkaW5nIHRoZSB0 ZXh0Lg0KDQpJdCdzIGRlc2lnbmVkIGFzIGFuIHVuaWRpcmVjdGlvbmFsIHRvb2wsIG1ha2UgaXQg YSB0d28td2F5IGV4Y2hhbmdlIG1lY2hhbmlzbSB3aWxsIHJlcXVpcmUgbW9yZSBjb25zaWRlcmF0 aW9ucyBhbmQgc3Vic3RhbnRpYWwgY2hhbmdlcyB0byBkcmFmdC4gIFNvLCBJIGlubGluZSB0byBr ZWVwIGl0IGFzLWlzLiBJZiB3ZSBoYXZlIHN1Y2ggdXNlIGNhc2UgaW4gdGhlIGZ1dHVyZSwgd2Ug dXBkYXRlIHRoaXMgbWVjaGFuaXNtIHRoZW4uDQoNCj4gDQo+IFNlY3Rpb24gNw0KPiANCj4gKFBl ciBJQU5BLCBiaXRzIDQgYW5kIDUgYXJlIGFscmVhZHkgYXNzaWduZWQgYnV0IGFyZSBub3QgcmVm bGVjdGVkIGluIHRoZQ0KPiBkaWFncmFtLikNCg0KRml4ZWQgaW4gdmVyc2lvbiAwNy4NCg0KPiAN Cj4gU2VjdGlvbiAxMA0KPiANCj4gICAgVGhlIERldGFpbGVkIEludGVyZmFjZSBhbmQgTGFiZWwg U3RhY2sgVExWIGZvcm1hdCBpcyBkZXJpdmVkIGZyb20gdGhlDQo+ICAgIEludGVyZmFjZSBhbmQg TGFiZWwgU3RhY2sgVExWIGZvcm1hdCAoZnJvbSBbUkZDODAyOV0pLiAgVHdvIGNoYW5nZXMNCj4g ICAgYXJlIGludHJvZHVjZWQuICBUaGUgZmlyc3QgaXMgdGhhdCB0aGUgbGFiZWwgc3RhY2sgaXMg Y29udmVydGVkIGludG8NCj4gICAgYSBzdWItVExWLiAgVGhlIHNlY29uZCBpcyB0aGF0IGEgbmV3 IHN1Yi1UTFYgaXMgYWRkZWQgdG8gZGVzY3JpYmUgYW4NCj4gICAgaW50ZXJmYWNlIGluZGV4LiAg VGhlc2UgZmllbGRzIG9mIERldGFpbGVkIEludGVyZmFjZSBhbmQgTGFiZWwgU3RhY2sNCj4gICAg VExWIGhhdmUgdGhlIHNhbWUgdXNlIGFuZCBtZWFuaW5nIGFzIGluIFtSRkM4MDI5XS4gIEEgc3Vt bWFyeSBvZg0KPiAgICB0aGVzZSBmaWVsZHMgaXMgYXMgYmVsb3c6DQo+IA0KPiBuaXQ6IEFyZSAi VGhlc2UgZmllbGRzIiBqdXN0ICJUaGUgb3RoZXIgZmllbGRzIj8NCg0KRml4ZWQgaW4gdmVyc2lv biAwNy4NCg0KPiANCj4gICAgICAgICAgVGhlIEFkZHJlc3MgVHlwZSBpbmRpY2F0ZXMgaWYgdGhl IGludGVyZmFjZSBpcyBudW1iZXJlZCBvcg0KPiAgICAgICAgICB1bm51bWJlcmVkLiAgSXQgYWxz byBkZXRlcm1pbmVzIHRoZSBsZW5ndGggb2YgdGhlIElQIEFkZHJlc3MNCj4gICAgICAgICAgYW5k IEludGVyZmFjZSBmaWVsZHMuICBUaGUgcmVzdWx0aW5nIHRvdGFsIGxlbmd0aCBvZiB0aGUNCj4g ICAgICAgICAgaW5pdGlhbCBwYXJ0IG9mIHRoZSBUTFYgaXMgbGlzdGVkIGFzICJLIE9jdGV0cyIu ICBUaGUgQWRkcmVzcw0KPiAgICAgICAgICBUeXBlIGlzIHNldCB0byBvbmUgb2YgdGhlIGZvbGxv d2luZyB2YWx1ZXM6DQo+IA0KPiBuaXQ6IGlzIGl0IGJldHRlciB0byBsaXN0IHRoZSBjdXJyZW50 bHkgYWxsb2NhdGVkIHZhbHVlcyBvciBqdXN0IHJlZmVyIHRvIHRoZSBJQU5BDQo+IHJlZ2lzdHJ5 Pw0KDQpTaW5jZSBoZXJlIGl0IGFsc28gaW5jbHVkZSB0aGUgbGVuZ3RoIGZpZWxkLiBJJ2QgbGlr ZSB0byBrZWVwIGl0IGJvdGggaGVyZSBhbmQgdGhlIElBTkEgcmVnaXN0cnkuDQoNCj4gDQo+IEkg c2VlZSB0aGF0IHRoaXMgImluZGV4IGFzc2lnbmVkIHRvIHRoZSBpbnRlcmZhY2UiIGxhbmd1YWdl IGZvciB1bm51bWJlcmVkDQo+IGFkZHJlc3MgdHlwZXMgb3JpZ2luYXRlcyBmcm9tIFJGQyA4MDI5 LCBidXQgYm90aCB0aGlzIGRvY3VtZW50IGFuZCA4MDI5DQo+IGxlYXZlIG1lIGNvbmZ1c2VkIGFz IHRvIHRoZSBlbmNvZGluZyB1c2VkIGZvciB0aGlzIGluZGV4IChmb3IgZWl0aGVyL2JvdGgNCj4g SVB2NCBvciBJUHY2IGFkZHJlc3MgdHlwZXMpLg0KDQpJdCdzIG5vcm1hbGx5IGFuIHVuc2lnbmVk IGludGVnZXIuDQoNCkZpeGVkIGluIHZlcnNpb24gMDcuDQoNCj4gDQo+IFtNeSBjb21tZW50IGFi b3V0ICJNdXN0IEJlIFplcm8iIGFuZCBhbGxvY2F0YWJsZSBiaXRzIGFsc28gYXBwbGllcyBoZXJl XQ0KDQpGaXhlZCBpbiB2ZXJzaW9uIDA3Li4NCg0KPiANCj4gU2VjdGlvbiAxMg0KPiANCj4gVGhp cyBkb2N1bWVudCBhbHNvIGFkZHMgYSBjYXBhYmlsaXR5ICJuZWdvdGlhdGlvbiIgbWVjaGFuaXNt IGZvciBNUExTIGVjaG8NCj4gcmVxdWVzdC9yZXBseSBleGNoYW5nZXMuICBBcyBNUExTIGRvZXMg bm90IG9mZmVyIGludGVncml0eSBwcm90ZWN0aW9uIGZvciBpdHMNCj4gbWVzc2FnZXMsIHRoaXMg bmVnb3RpYXRpb24gaXMgb25seSBhcyB0cnVzdHdvcnRoeSBhcyB0aGUgbmV0d29yayBmcm9tIHdo aWNoDQo+IG1lc3NhZ2VzIGFyZSBhY2NlcHRlZCBhcyB2YWxpZCwgYW5kIGluaXRpYXRvcnMgaGF2 ZSBubyByZWNvdXJzZSBidXQgdG8gYWNjZXB0DQo+IGZhaXRoZnVsbHkgdGhlIGVjaG8gcmVwbGll cyByZWNlaXZlZC4NCj4gDQo+ICAgIFRvIHByZXZlbnQgbGVha2FnZSBvZiB2aXRhbCBpbmZvcm1h dGlvbiB0byB1bnRydXN0ZWQgdXNlcnMsIGENCj4gICAgcmVzcG9uZGVyIExTUiBNVVNUIG9ubHkg YWNjZXB0IE1QTFMgZWNobyByZXF1ZXN0IG1lc3NhZ2VzIGZyb20NCj4gICAgZGVzaWduYXRlZCB0 cnVzdGVkIHNvdXJjZXMgdmlhIGZpbHRlcmluZyBzb3VyY2UgSVAgYWRkcmVzcyBmaWVsZCBvZg0K PiAgICByZWNlaXZlZCBNUExTIGVjaG8gcmVxdWVzdCBtZXNzYWdlcy4gIFsuLi5dDQo+IA0KPiBJ J2QgcHJlZmVyIHRvIHNlZSBhIG5vdGUgYWRkZWQgaGVyZSBhYm91dCBob3cgInNvdXJjZSBJUCBh ZGRyZXNzIGZpbHRlcmluZw0KPiBwcm92aWRlcyBvbmx5IGEgd2VhayBmb3JtIG9mIGFjY2VzcyBj b250cm9sIGFuZCBpcyBub3QsIGluIGdlbmVyYWwsIGEgcmVsaWFibGUNCj4gc2VjdXJpdHkgbWVj aGFuaXNtLiAgTm9uZXRoZWxlc3MsIGl0IGlzIHJlcXVpcmVkIGhlcmUgaW4gdGhlIGFic2VuY2Ug b2YgYW55DQo+IG1vcmUgcm9idXN0IG1lY2hhbmlzbSB0aGF0IG1pZ2h0IGJlIHVzZWQuIg0KDQpB ZGRlZCBpbiB2ZXJzaW9uIDA3Lg0KDQo+IA0KPiBTZWN0aW9uIDEzDQo+IA0KPiBTaG91bGQgd2Ug YXNrIElBTkEgdG8gdXBkYXRlIHRoZSAiSW50ZXJmYWNlIGFuZCBMYWJlbCBTdGFjayBBZGRyZXNz IFR5cGVzIg0KPiByZWdpc3RyeSB0byBhbHNvIHJlZmVyIHRvIHRoaXMgZG9jdW1lbnQsIHNpbmNl IHdlIGFyZSBzaGFyaW5nIHRoZSByZWdpc3RyeQ0KPiBiZXR3ZWVuIHRoZSBJbnRlcmZhY2UgYW5k IExhYmVsIFN0YWNrIFRMViBhbmQgdGhlIERldGFpbGVkIHZlcnNpb24/DQo+IA0KDQpBZGRlZCBp biB2ZXJzaW9uIDA3Lg0KDQoNCj4gU2VjdGlvbiAxMy4yDQo+IA0KPiBUaGUgcmFuZ2UgNC0zMTc0 MyBzcGFucyB0d28gZGlmZmVyZW50IGFsbG9jYXRpb24gcHJvY2VkdXJlcyAoU3RhbmRhcmRzDQo+ IEFjdGlvbiBhbmQgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCAtIEV4cGVyaW1lbnRhbCBSRkMgbmVl ZGVkKTsgSSBhc3N1bWUgdGhhdA0KPiB3ZSB3YW50IHRoZSA0LTE2MzgzIHJhbmdlIGZvciBTdGFu ZGFyZHMgQWN0aW9uIC0gbWFuZGF0b3J5IFRMVnMuDQoNClllcy4NCg0KPiANCj4gU2VjdGlvbiAx My40DQo+IA0KPiBXZSBkb24ndCBzYXkgd2hhdCByYW5nZSB3ZSB3YW50IHRoaXMgdG8gYmUgYWxs b2NhdGVkIGZyb20gLS0gSSBhc3N1bWUNCj4gNC0xNjM4MyBzaW5jZSB0aGlzIGlzIGEgbmVnb3Rp YXRlZCBmZWF0dXJlIGFuZCBzZW5kaW5nIGl0IG91dHNpZGUgdGhlDQo+IG5lZ290aWF0ZWQgc2Nl bmFyaW8gc2hvdWxkIGJlIGFuIGVycm9yLg0KDQpTdWdnZXN0ZWQgcmFuZ2UgYWRkZWQgaW4gdmVy c2lvbiAwNy4NCg0KPiANCj4gU2VjdGlvbiAxMy40LjENCj4gDQo+IChJIG5vdGUgdGhhdCBzb21l IGV4aXN0aW5nIHN1Yi1UTFYgcmVnaXN0cmllcyBoYXZlICJFeHBlcmltZW50YWwgUkZDDQo+IHJl cXVpcmVkIiBmb3IgdGhlIGV4cGVyaW1lbnRhbCByYW5nZXMsIGJ1dCB0aGF0IGlzIGFyZ3VhYmx5 IG1vcmUgc3RyaW5nZW50DQo+IHRoYW4gbmVjZXNzYXJ5OyBTcGVjaWZpY2F0aW9uIFJlcXVpcmVk IHNlZW1zIG1vcmUgYXBwcm9wcmlhdGUgZm9yIHRoaXMgY2FzZS4pDQoNCkNoYW5nZWQgdG8gIiBT cGVjaWZpY2F0aW9uIFJlcXVpcmVkIiBpbiB2ZXJzaW9uIDA3Lg0KDQo+IA0KPiBBcHBlbmRpeCBB DQo+IA0KPiBJIHdhcyBraW5kIG9mIGhvcGluZyBmb3Igc29tZSBtb3JlIGd1aWRhbmNlIG9uIHdo YXQgYW4gaW5pdGlhdG9yIGNvdWxkIGRvIGluDQo+IHRoZXNlIHNjZW5hcmlvcyB0byB0cnkgdG8g Z2V0IGJldHRlciB2aXNpYmlsaXR5IGludG8gdGhlIHN3aXRjaCBiZWhhdmlvciAoYW5kLA0KPiBo b3BlZnVsbHksIGEgd29ya2Fyb3VuZCB0byBnZXQgcmVsaWFibGUgZWNobyByZXNwb25zZXMgdGhh dCBjb3ZlciBhbGwgTEFHDQo+IG1lbWJlciBsaW5rcykuICBBRkFJQ1QgdGhlcmUncyBub3QgYSBi ZXR0ZXIgb3B0aW9uIHRoYW4gInRyeSBhIGJ1bmNoIG9mDQo+IGVudHJvcHkgbGFiZWxzIGFuZCBz ZWUgd2hhdCByZXNwb25zZXMgeW91IGNhbiBnZXQgYmFjayIgYW5kIHRoYXQncyB0aGUNCj4gc2Ft ZSByZW1lZHkgaW4gYWxsIHRoZSBkZXNjcmliZWQgdG9wb2xvZ2llcywgYnV0IGl0IHdvdWxkIGJl IG5pY2UgdG8gaGF2ZSB0aGlzDQo+IHN0YXRlZCBleHBsaWNpdGx5IGZvciB0aGUgcmVhZGVyLg0K DQpBIG5vdGUgYWRkZWQgaW4gdmVyc2lvbiAwNy4NCg0KPiANCj4gU2VjdGlvbiBBLjENCj4gDQo+ ICAgICAgICAgICAgICAgICAgICAgSW4gdGhlIHdvcnN0IGNhc2UsIE1QTFMgZWNobyByZXF1ZXN0 IG1lc3NhZ2VzIHdpdGgNCj4gICAgc3BlY2lmaWMgZW50cm9waWVzIHRvIGV4ZXJjaXNlIGV2ZXJ5 IExBRyBtZW1iZXJzIGZyb20gUjEgdG8gUzEgY2FuDQo+ICAgIGFsbCByZWFjaCBSMiB2aWEgc2Ft ZSBMQUcgbWVtYmVyLiAgWy4uLl0NCj4gDQo+IEknbSBjb25mdXNlZCBieSB0aGUgcGhyYXNlICJz cGVjaWZpYyBlbnRyb3BpZXMgdG8gZXhlcmNpc2UgZXZlcnkgTEFHDQo+IG1lbWJlcnMgW3NpY10g ZnJvbSBSMSB0byBTMSIgLS0gaXMgdGhlcmUgc29tZSBkZXRlcm1pbmlzdGljIGFsZ29yaXRobSBi eQ0KPiB3aGljaCBhIHNwZWNpZmljIGVudHJvcHkgbGFiZWwgdmFsdWUgd2lsbCBmb3JjZSBhIHNw ZWNpZmljIExBRyBtZW1iZXIgbGluaz8NCg0KTm8uDQoNCj4gTXkgdW5kZXJzdGFuZGluZyB3YXMg dGhhdCB0aGUgZW50cm9weSB3YXMgdXNlZCBhcyBpbnB1dCB0byBhbiBvcGFxdWUgaGFzaA0KPiBm dW5jdGlvbiBhbmQgdGhhdCB0cmlhbC1hbmQtZXJyb3Igd2FzIHRoZSBvbmx5IHdheSB0byBleHBs b3JlIHRoZSBtYXBwaW5nDQo+IGZyb20gZW50cm9weSB2YWx1ZSB0byBMQUcgbWVtYmVyIGxpbmsg dGFrZW4uDQoNClllcy4NCg0KVGhhbmtzLA0KTWFjaA0KPiANCg0K From nobody Thu Apr 4 07:49:54 2019 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 4E0FA12024F; Thu, 4 Apr 2019 07:49:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org, mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155438939231.30890.11881015790565057622.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2019 07:49:52 -0700 Archived-At: Subject: [mpls] Benjamin Kaduk's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-08: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 14:49:52 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-mpls-lsp-ping-lag-multipath-08: 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-lsp-ping-lag-multipath/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for resolving my DISCUSS (and COMMENT) points! From nobody Mon Apr 8 01:20:48 2019 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 BAE32120044; Mon, 8 Apr 2019 01:20:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org, mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <155471164675.6386.10341508380803392820.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2019 01:20:46 -0700 Archived-At: Subject: [mpls] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-mpls-lsp-ping-lag-multipath-08=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 08:20:47 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-mpls-lsp-ping-lag-multipath-08: 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-lsp-ping-lag-multipath/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Very useful document and techniques; but, I am afraid that I have some issues with this document in its present form: nothing on the actual technique but rather on how the specification is written. COMMENTS 1) Section 3, I wonder why the "LSR Capability Discovery" TLV is not part of another document: it seems so important to me that it would have deserved its own document (and avoiding the fate sharing with the LAG discovery). Probably too late to change anyway. 2) Section 3.2, while this section is about the generic discovery TLV, the text in 3.2 is only about "LAG Description Indicator" flag. This text should rather be in Section 4. 3) Traceroute with TTL expiring, will it require the 'expiring' LSR to check for capability discovery ? Or is it a 2-step procedure (discover the path, then ask for capabilities)? 4) Section 8, unclear to me where "Local Interface Index" is coming from... is it an opaque value for the initiator or does it have any semantic ? Same question applies to section 9 of course. 5) Section 10, in IPv6 any interface can have multiple IPv6 addresses, so, the text such as "or the interface address" is not applicable, suggestion "or any interface global address" (which can be ambiguous as well, perhaps the 'lowest' address ?) NITS N1) Section 3.1, "it can send an MPLS each request message" I cannot parse this part of the sentence N2)Section 3.2, "When a responder LSR received" the use of past tense seems weird in this sentence, esp when present tense is use after. From nobody Mon Apr 8 02:58:34 2019 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 A7EDA12006D; Mon, 8 Apr 2019 02:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.026 X-Spam-Level: X-Spam-Status: No, score=-1.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_DISPTO=0.25, 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 SK0oY4Py_Ngo; Mon, 8 Apr 2019 02:58:31 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 6F93D1200B8; Mon, 8 Apr 2019 02:58:31 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id s16so11098490edr.3; Mon, 08 Apr 2019 02:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:cc:references:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=4wFL06R3zYgwcF39ZA2u+a+vCexn81JTC6KqhswxpZE=; b=jb3NeiSo1Xgzowdi4mOAkp2Z4DwOn0fvMBwrld4pMzbocE4DO+kKuNbN8P65OX3G5w rI68Q7FBsUffDdWQCOzFz2lncKbDEr2kiREt31EP+4f3+4QHtabg3dFpdktP+mFqjzvy FXmyBPGkH1KJht2ZfnckRfsccSDIlw23OFDGPbq2gBL2E1zFZUdO0eNeYlfVc2rqndFA bufUOkPMNZ433+T34AB+To4UI2zxsrfJBbRO8v+D84zUOciA12ysqEa/mwxBlal1oAU/ rDswhHgoykjD93aGyDAS1W6MkZKL+5nss3izsNeeqxDCtFW34K/VoYjoVXDgDhpHU0UK yclA== 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:to:cc:references:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=4wFL06R3zYgwcF39ZA2u+a+vCexn81JTC6KqhswxpZE=; b=AvacC1F4Y5geNjSH/jCQNuINAFzyj9UkrUnZBJ/iBPGllPBXrITrVwe7N1dyhllpSN +kOr7BOE4nA2r72iYih9YP0gWLL3opAuvKzz72+VHGyOiPkamfHJwRjUiM+EgHZPDtYy rYwfoOzcifaxUfyHeXtWLc2573mIANEMcN54OYZBzzojKXAmsaAVXef1BpnaCf8cpxxo FBzb7j76ZAo7D7NqGY5I9ci/jRSVcpa6lbyPZ4IKVrnpc5CfJMZx7X+oAyTRsJrRz2Ku qj0BQ7wrtcs5Tr4awgWD9YZQbk5mJWWy+LrFKiBfxRc6notyykuv+Nci3gVuelyPZ+rs T4Cg== X-Gm-Message-State: APjAAAXz3GDJgooNL18L4rQFj+XvxEmhoLdaw/f3JkUcxb+mkiMe+NbC dLd6u6DeXdxgHAgGoxnVLH4/HvTU X-Google-Smtp-Source: APXvYqxru9h3whrcmoVU9qEVX5Pe8Ecbe4ZG7NA2e4sczfMp1sVvEYxLXGPrlK3FYI6Xf0gpbxi/eQ== X-Received: by 2002:a17:906:81cf:: with SMTP id e15mr15600728ejx.241.1554717509766; Mon, 08 Apr 2019 02:58:29 -0700 (PDT) Received: from McAsterix.local ([2a02:a211:8e81:2e00:d89:6d4a:d526:1a4d]) by smtp.gmail.com with ESMTPSA id e3sm8615245edb.22.2019.04.08.02.58.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 02:58:28 -0700 (PDT) Reply-To: huubatwork@gmail.com To: "mpls@ietf.org" Cc: "draft-zzhang-mpls-rmr-multicast@ietf.org" , "mpls-chairs@ietf.org" References: <0df832d7-8389-e9dd-95aa-46d8c8d06da5@pi.nu> From: Huub van Helvoort Message-ID: Date: Mon, 8 Apr 2019 11:58:28 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <0df832d7-8389-e9dd-95aa-46d8c8d06da5@pi.nu> Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [mpls] MPLS-RT review of draft-zzhang-mpls-rmr-multicast X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 09:58:33 -0000
All,

I’ve been selected as an MPLS-RT reviewer for draft-zzhang-mpls-rmr-multicast,
which is currently a candidate for MPLS WG adoption.

In the abstract is stated:
   With Resilient MPLS Rings (RMR), although all existing multicast
   procedures and solutions can work as is, there are optimizations that
   could be done for RSVP-TE P2MP tunnel signaling and Fast-ReRouting
   for both mLDP and RSVP-TE P2MP tunnels.
I have carefully read the draft but I could not find any justification
for the optimisation that could be done.
I also did not find any indication how this optimisation has to be
deployed. Do all the nodes in the ring, or in the network have to
support this optimisation before it becomes effective.

I think these issues have to be documented before this draft can
be adopted as WG draft.

Best regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...
From nobody Mon Apr 8 03:42:53 2019 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 20A8E1201C1; Mon, 8 Apr 2019 03:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.328 X-Spam-Level: X-Spam-Status: No, score=-1.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 c3QUHyW7YP6K; Mon, 8 Apr 2019 03:42:50 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 F00D9120058; Mon, 8 Apr 2019 03:42:49 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x38ATNHw001690; Mon, 8 Apr 2019 03:42:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=umAGzhQggPTs+SwaifwGvgRLC2Vi6kC7XSuOqCi1kh4=; b=IahEplIXV6Cg47YK6ablUyfzSlLRgXpplE5rnv5zsz7hgSsgswoRVSMgcPlXa3XdB8B1 FQMVbRhCBaRF7ouLG3ymJNTbJ9szy99e7ja3phjdBaf9+0xmQbp+Bgvnlk9v5E/ZgF4v MG26qPT0hnX2g9+whtejoFXP0LLPG7kpb2dvRyY0QJ0ElSemdPimfpHLiuebMqH+YjD5 tDub+WP4Cbb2gGKKTkzGR3+DB+zsnS/UaB4ADkJ/p92V3QDJ9S+dN1DLqZD+sqIFgpRJ aO7D3nGf+1U9dbB9LHjMDBX0Pp0fHKkFQWBsi42ONlLZHIXYj4vRoLO5SKBK132oBSvE /g== Received: from nam05-co1-obe.outbound.protection.outlook.com (mail-co1nam05lp2056.outbound.protection.outlook.com [104.47.48.56]) by mx0b-00273201.pphosted.com with ESMTP id 2rr2qhg623-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 08 Apr 2019 03:42:46 -0700 Received: from CO2PR05MB2455.namprd05.prod.outlook.com (10.166.95.137) by CO2PR05MB2727.namprd05.prod.outlook.com (10.166.200.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.11; Mon, 8 Apr 2019 10:42:44 +0000 Received: from CO2PR05MB2455.namprd05.prod.outlook.com ([fe80::81e2:bbe8:6851:16b2]) by CO2PR05MB2455.namprd05.prod.outlook.com ([fe80::81e2:bbe8:6851:16b2%6]) with mapi id 15.20.1792.007; Mon, 8 Apr 2019 10:42:44 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "huubatwork@gmail.com" , "mpls@ietf.org" CC: "draft-zzhang-mpls-rmr-multicast@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: MPLS-RT review of draft-zzhang-mpls-rmr-multicast Thread-Index: AQHU5UdoXX/k5SRry0WfLJCBg3kMV6YyGKsAgAAHF+A= Content-Class: Date: Mon, 8 Apr 2019 10:42:44 +0000 Message-ID: References: <0df832d7-8389-e9dd-95aa-46d8c8d06da5@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action msip_labels: MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Enabled=True; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Owner=zzhang@juniper.net; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_SetDate=2019-04-08T10:39:01.9086694Z; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Name=Non-Juniper; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Application=Microsoft Azure Information Protection; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Extended_MSFT_Method=Manual; Sensitivity=Non-Juniper x-originating-ip: [117.38.13.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3061e5a1-dbce-431c-159a-08d6bc0eef1b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:CO2PR05MB2727; x-ms-traffictypediagnostic: CO2PR05MB2727: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(396003)(366004)(376002)(346002)(31014005)(189003)(37854004)(199004)(8936002)(81156014)(102836004)(446003)(6116002)(6246003)(790700001)(316002)(105586002)(53936002)(476003)(229853002)(7696005)(3846002)(106356001)(81166006)(6506007)(4326008)(11346002)(97736004)(2906002)(8676002)(33656002)(53546011)(9326002)(76176011)(68736007)(486006)(26005)(186003)(74316002)(478600001)(2501003)(7736002)(55016002)(71190400001)(71200400001)(14454004)(66066001)(5660300002)(6436002)(52536014)(86362001)(66574012)(6306002)(25786009)(54906003)(9686003)(256004)(14444005)(99286004)(110136005)(53946003)(54896002)(579004)(559001)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2727; H:CO2PR05MB2455.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 3kd93FmdXRsTjI+uTcwoTHfeNhCTMe2V+FkKC6zPDt1nXEvSaFcJNZT+3b0egInOJ9qVyrgoUYnjzEly56hQNBYx7SIdvhXeOkRJavgN3ky8fRB2V7tVhvFVrA651BpLUT/esOCgfGt/HsIb9iL3BzxcKipTRz3gQbg63whzrumI1rF0CjATuUanYLIZ95k/eV+kNArdMjW8wqv4LZ/6XdAaFvHRzFL66axAOg90VFN1iYkwLFw91eNsiWauIJzmtTX7dEPy3XB1k9IBWuyWGKRJ7eM91FiYA/lb4wyeU0RCuPOpG/PUvbMpsDEWKQwHtCRpe0KZEwXseZ1WI+fnBnaddC37wKUlD0vGu1cghoU3PIIN1OZrGorbWdZAllPKW0u0w+Tho9X7KTlNirMmTdz1OzjdM3JWh3wPRrHbppM= Content-Type: multipart/alternative; boundary="_000_CO2PR05MB2455B56BCF23C0059D4EB90DD42C0CO2PR05MB2455namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 3061e5a1-dbce-431c-159a-08d6bc0eef1b X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2019 10:42:44.5466 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2727 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-08_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080095 Archived-At: Subject: Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rmr-multicast X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 10:42:52 -0000 --_000_CO2PR05MB2455B56BCF23C0059D4EB90DD42C0CO2PR05MB2455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huub, Thank you for your review and comments. Please see zzh> below. Non-Juniper From: Huub van Helvoort Sent: Monday, April 8, 2019 5:58 AM To: mpls@ietf.org Cc: draft-zzhang-mpls-rmr-multicast@ietf.org; mpls-chairs@ietf.org Subject: MPLS-RT review of draft-zzhang-mpls-rmr-multicast All, I've been selected as an MPLS-RT reviewer for draft-zzhang-mpls-rmr-multica= st, which is currently a candidate for MPLS WG adoption. In the abstract is stated: With Resilient MPLS Rings (RMR), although all existing multicast procedures and solutions can work as is, there are optimizations that could be done for RSVP-TE P2MP tunnel signaling and Fast-ReRouting for both mLDP and RSVP-TE P2MP tunnels. I have carefully read the draft but I could not find any justification for the optimisation that could be done. Zzh> By "justification", do you mean "need"? I thought the following text p= rovides that: For a conventionally signaled RSVP-TE P2MP tunnel, an ingress LSR discovers leaves and signals one sub-LSP for each leaf. Even though the forwarding state is merged at each hop (i.e, one incoming label mapping to multiple outgoing entries), the control plane maintains individual sub-LSP state. This leads to lots of redundant state on routers close to the ingress. Zzh> Or do you mean "why" the optimization COULD be done? The key is that t= his is a ring, and: ... As the PATH message passes along the ring, the leaves send RESV messages, but only one RESV message reaches the tunnel ingress. Zzh> If you mean "how" it is done, I thought the following describes it: ... With RMR, this can be optimized such that only a single LSP is signaled, with all the leaves listed in the PATH message. As the PATH message passes along the ring, the leaves send RESV messages, but only one RESV message reaches the tunnel ingress. The ingress LSR may also send PATH messages in both directions, so that the tunnel is set up in such a way that minimum delay is incurred for traffic to reach all leaves. Alternatively, the ingress may send PATH message only in one direction for best bandwidth utilization. For example, a leaf D is three hops away from the ingress A in clockwise direction (A,B,C,D) and four hops away in the other direction (A,E,F,G,D), but G is also a leaf so it may be better to just send the PATH message in the anticlockwise direction. Each router establishes forwarding state accordingly. Transit routers switches traffic towards downstream. A transit router could also be a leaf router and in that case it does "drop and continue" - sends traffic off the ring and switches traffic downstream. 2.1. Tunnel Protection and FRR Each node on a ring signals two counter-rotating MP2P RSVP-TE LSPs to itself. As these LSPs are self-signaled after the discovery of the ring, they can be used to protect P2MP LSPs on ring. So neither mLDP nor RSVP-TE has to setup a separate P2P bypass LSPs for link and node protection. I also did not find any indication how this optimisation has to be deployed. Do all the nodes in the ring, or in the network have to support this optimisation before it becomes effective. Zzh> The context is RMR - Resilient MPLS Ring. All routers on the ring need= to support RMR and the multicast optimization for this to be effective. I = can make that clear. I think these issues have to be documented before this draft can be adopted as WG draft. Zzh> Besides explicitly stating that all routers on the ring need to suppor= t the RSVP-TE P2MP optimization for it to be effective, please advise furth= er how the first issue can be better documented. Thanks. Jeffrey 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... --_000_CO2PR05MB2455B56BCF23C0059D4EB90DD42C0CO2PR05MB2455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hu= ub,

=  

Thank= you for your review and comments. Please see zzh> below.

=  

 

Non-Juniper

From: Huub van Hel= voort <huubatwork@gmail.com>
Sent: Monday, April 8, 2019 5:58 AM
To: mpls@ietf.org
Cc: draft-zzhang-mpls-rmr-multicast@ietf.org; mpls-chairs@ietf.org Subject: MPLS-RT review of draft-zzhang-mpls-rmr-multicast

 

All,

 

I’ve been selected as an MPLS-RT reviewer for draft-z= zhang-mpls-rmr-multicast,
which is currently a candidate for MPLS WG adoption.

 

In the abstract is stated:

   With Resilient MP=
LS Rings (RMR), although all existing multicast
   procedures and so=
lutions can work as is, there are optimizations that
   could be done for=
 RSVP-TE P2MP tunnel signaling and Fast-ReRouting
   for both mLDP and=
 RSVP-TE P2MP tunnels.

I have carefully read the draft but I could not find any ju= stification
for the optimisation that could be done.

=  

Zzh&g= t; By “justification", do you mean “need”? I thought= the following text provides that:

=  

   For a conventionally signaled RSVP-TE P2MP tunnel, an ingress LSR

   discovers leaves and signals one sub-LSP for each leaf.  Even though

   the forwarding state is merged at each hop (i.e, one incoming label<= o:p>

   mapping to multiple outgoing entries), the control plane maintains

   individual sub-LSP state.  This leads to lots of redundant state on

   routers close to the ingress.

=  

Zzh&g= t; Or do you mean “why” the optimization COULD be done? The key= is that this is a ring, and:

=  

   … As the PATH message passes along the ring, the leaves

   send RESV messages, but only one RESV message reaches the tunnel

   ingress.

=  

Zzh&g= t; If you mean “how” it is done, I thought the following descri= bes it:

=  

   … With RMR, this can be optimized such

   that only a single LSP is signaled, with all the leaves listed in th= e

   PATH message.  As the P= ATH message passes along the ring, the leaves

   send RESV messages, but only one RESV message reaches the tunnel

   ingress.

 

   The ingress LSR may also send PATH messages in both directions, so

   that the tunnel is set up in such a way that minimum delay is

   incurred for traffic to reach all leaves.  Alternatively, the ingress

   may send PATH message only in one direction for best bandwidth<= /o:p>

   utilization.  For examp= le, a leaf D is three hops away from the

   ingress A in clockwise direction (A,B,C,D) and four hops away in the=

   other direction (A,E,F,G,D), but G is also a leaf so it may be bette= r

   to just send the PATH message in the anticlockwise direction.

 

   Each router establishes forwarding state accordingly.  Transit

   routers switches traffic towards downstream.  A transit router could

   also be a leaf router and in that case it does "drop and contin= ue" -

   sends traffic off the ring and switches traffic downstream.



2.1.  Tunnel Protection and FRR

 

   Each node on a ring signals two counter-rotating MP2P RSVP-TE LSPs t= o

   itself.  As these LSPs = are self-signaled after the discovery of the

   ring, they can be used to protect P2MP LSPs on ring.  So neither mLDP

   nor RSVP-TE has to setup a separate P2P bypass LSPs for link and nod= e

   protection.

=  


I also did not find any indication how this optimisation has to be
deployed. Do all the nodes in the ring, or in the network have to
support this optimisation before it becomes effective.

=  

Zzh&g= t; The context is RMR – Resilient MPLS Ring. All routers on the ring = need to support RMR and the multicast optimization for this to be effective. I can make that clear.

 

I think these issues have to be documented before this draf= t can

be adopted as WG draft.

=  

Zzh> Besides explicitly stating that all routers= on the ring need to support the RSVP-TE P2MP optimization for it to be effective, please advise further how the first issue can be b= etter documented.

 

Thanks.
Jeffrey

 

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...<=
/o:p>
--_000_CO2PR05MB2455B56BCF23C0059D4EB90DD42C0CO2PR05MB2455namp_-- From nobody Mon Apr 8 13:07:54 2019 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 C3AEA120486; Mon, 8 Apr 2019 13:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.016 X-Spam-Level: X-Spam-Status: No, score=-1.016 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_DISPTO=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 eAQS35f11w_M; Mon, 8 Apr 2019 13:07:51 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 EE11412048B; Mon, 8 Apr 2019 13:07:50 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id f19so5826151edw.12; Mon, 08 Apr 2019 13:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:cc:references:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=P9VtCHyYHwOhgzgOej56sHIjP5q6Mol/5ryFJ/bDWe8=; b=Ad/eVTc3mSFp8T/ew5/KDyNAqp83RHhgLBsHtSCZYFLxqh+kUfKcaINb9HD6LgnQks 6gNcNVn0r5iruqgMyn99bNmbNmcUpJrMrhNZHSGNPnSYMAqBwkWSreokRDpdKGPkGiim fxte0eIagQO8cx4aXVyzfJuLHRzyq3YsRn/nJltpyZdeaEhZvv0JOCqAUnBmLn3G+Xls SPosswlbecDtJ9+5H0C9SLvEFustskygLkyPMPNMkrZ6J0W4YFW0JRoisgUl/Sm++7fg oSL/FWH/DXDkxYqDPS2RpMokUcKEQ++cD978aMFHqcdcHO65nRRuBPh8EUndQUldVHO/ 2SNQ== 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:to:cc:references:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=P9VtCHyYHwOhgzgOej56sHIjP5q6Mol/5ryFJ/bDWe8=; b=Jjal2MlO8Nm4/ePaaI70aJp4kUjIlFbKeuzCRLmnF47pcQhUOtlpCwF11hXmuva3JH 6mtq/slATOEZLuJEe4wHLfW1vI4t5hMDFQUJfUGOTozVoMIrddeCjsCGdZeufgp7pqZm 8t/Fwh5Isfy5ugxPDbwNlronGScuxIqXx4kIe/FwjjoMOzHZASeNfR3yuX+iOHzJMicc ZuBnfsreiDCxEzSac+jNgR906SSN69wkcFQDwv5mN2xJlOJfmO75GLLbPPsQTSyOaRb1 1c8O1ApUZl0PClZom+ZG7PV//kDlaEYM4vf99EEjSXbyir3nKKiJBgBlFTgOeRhrnL5h COlQ== X-Gm-Message-State: APjAAAVnjPlELW7qsPPjaMKPc+u7RGcTE4au1YWNQ0Kn2Ric8nzBZnI6 s72EF1UWVO/IXIuUWf2Vzo/oj80H X-Google-Smtp-Source: APXvYqziE+EOeD+XxRwQls0XLwhoIdc3qpj7xkKbQm1/3cDwYNKjO8e3jITuHzZPeMqjZkKtX/85TA== X-Received: by 2002:a17:906:660f:: with SMTP id b15mr9775934ejp.13.1554754069139; Mon, 08 Apr 2019 13:07:49 -0700 (PDT) Received: from McAsterix.local ([2a02:a211:8e81:2e00:b86e:29cf:5825:47f5]) by smtp.gmail.com with ESMTPSA id l44sm9148101edb.37.2019.04.08.13.07.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 13:07:48 -0700 (PDT) Reply-To: huubatwork@gmail.com To: "Jeffrey (Zhaohui) Zhang" , "mpls@ietf.org" Cc: "draft-zzhang-mpls-rmr-multicast@ietf.org" , "mpls-chairs@ietf.org" References: <0df832d7-8389-e9dd-95aa-46d8c8d06da5@pi.nu> From: Huub van Helvoort Message-ID: Date: Mon, 8 Apr 2019 22:07:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rmr-multicast X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 20:07:53 -0000
Hello Jeffrey,

Please see my response in-line [hvh].

Hi Huub,

 

Thank you for your review and comments. Please see zzh> below.

 

 

Non-Juniper

From: Huub van Helvoort <huubatwork@gmail.com>
Sent: Monday, April 8, 2019 5:58 AM
To: mpls@ietf.org
Cc: draft-zzhang-mpls-rmr-multicast@ietf.org; mpls-chairs@ietf.org
Subject: MPLS-RT review of draft-zzhang-mpls-rmr-multicast

 

All,

 

I’ve been selected as an MPLS-RT reviewer for draft-zzhang-mpls-rmr-multicast,
which is currently a candidate for MPLS WG adoption.

 

In the abstract is stated:

   With Resilient MPLS Rings (RMR), although all existing multicast
   procedures and solutions can work as is, there are optimizations that
   could be done for RSVP-TE P2MP tunnel signaling and Fast-ReRouting
   for both mLDP and RSVP-TE P2MP tunnels.

I have carefully read the draft but I could not find any justification
for the optimisation that could be done.

 

Zzh> By “justification", do you mean “need”? I thought the following text provides that:

 

   For a conventionally signaled RSVP-TE P2MP tunnel, an ingress LSR

   discovers leaves and signals one sub-LSP for each leaf.  Even though

   the forwarding state is merged at each hop (i.e, one incoming label

   mapping to multiple outgoing entries), the control plane maintains

   individual sub-LSP state.  This leads to lots of redundant state on

   routers close to the ingress.

[hvh] "lots of state" - can you be more specific? is the redundancy 10% or 90% ?

Zzh> Or do you mean “why” the optimization COULD be done? The key is that this is a ring, and:

 

   … As the PATH message passes along the ring, the leaves

   send RESV messages, but only one RESV message reaches the tunnel

   ingress.

[hvh] can you explain why only one RESV message reaches the tunnel ingress?

 Zzh> If you mean “how” it is done, I thought the following describes it:

 

   … With RMR, this can be optimized such

   that only a single LSP is signaled, with all the leaves listed in the

   PATH message.  As the PATH message passes along the ring, the leaves

   send RESV messages, but only one RESV message reaches the tunnel

   ingress.

 

   The ingress LSR may also send PATH messages in both directions, so

   that the tunnel is set up in such a way that minimum delay is

   incurred for traffic to reach all leaves.  Alternatively, the ingress

   may send PATH message only in one direction for best bandwidth

   utilization.  For example, a leaf D is three hops away from the

   ingress A in clockwise direction (A,B,C,D) and four hops away in the

   other direction (A,E,F,G,D), but G is also a leaf so it may be better

   to just send the PATH message in the anticlockwise direction.

 

   Each router establishes forwarding state accordingly.  Transit

   routers switches traffic towards downstream.  A transit router could

   also be a leaf router and in that case it does "drop and continue" -

   sends traffic off the ring and switches traffic downstream.



2.1.  Tunnel Protection and FRR

 

   Each node on a ring signals two counter-rotating MP2P RSVP-TE LSPs to

   itself.  As these LSPs are self-signaled after the discovery of the

   ring, they can be used to protect P2MP LSPs on ring.  So neither mLDP

   nor RSVP-TE has to setup a separate P2P bypass LSPs for link and node

   protection.

[hvh]  This is clear.

I also did not find any indication how this optimisation has to be
deployed. Do all the nodes in the ring, or in the network have to
support this optimisation before it becomes effective.

 

Zzh> The context is RMR – Resilient MPLS Ring. All routers on the ring need to support RMR and the multicast optimization for this to be effective. I can make that clear.

[hvh] OK. Thanks.

 I think these issues have to be documented before this draft can

be adopted as WG draft.

 

Zzh> Besides explicitly stating that all routers on the ring need to support the RSVP-TE P2MP optimization for it to be effective, please advise further how the first issue can be better documented.

[hvh] when you use the word "optimize" I expect an indication of
the effect of the optimization on performance, or used resources.

Cheers, Huub.


-- 
================================================================
Always remember that you are unique...just like everyone else...
From nobody Tue Apr 9 06:04:59 2019 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 048711207ED; Tue, 9 Apr 2019 06:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 iW81BvfJmanp; Tue, 9 Apr 2019 06:04:55 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 5563D1207EE; Tue, 9 Apr 2019 06:04:54 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x39D4eDf011747; Tue, 9 Apr 2019 06:04:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=vzKPyWjH6gbnAviynGvbhCs+nCAUkhCB7ZKwE/0kuVc=; b=g3CN5kG2+RLmVFUlYpzA6a9Yuek9v/IF02w5jxNWpF5V+Pv9Nzfzd33FAtJB2Hr4wc2C ekuJVXqnecKwV6y8MY06YreCDR0RDooRZxTqYE6zrSDgpOEMwJ8J4AI52ud2Nb0a4/1D BY6Wn5dZ0KqFyInpFJE9o3KLaM2RkojKUd4MzKXJ6DNzuBjcCZsJW8CFTW1XDth/oH5I rRc1VCVcCY0OwzE4bSj7waAai3UyYVCjtjMzV5bBOBxuqF/3JrmHmfnhxLXI4LNYFQxH 2ipWDwmtqrZx7EpLSZwqtm1orUaj7SHpQ9EdYyomsZLYRMzMTNtW9rESL5/NxzcbJFis vw== Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp2056.outbound.protection.outlook.com [104.47.40.56]) by mx0b-00273201.pphosted.com with ESMTP id 2rrrd18cad-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 09 Apr 2019 06:04:51 -0700 Received: from CO2PR05MB2455.namprd05.prod.outlook.com (10.166.95.137) by CO2PR05MB2760.namprd05.prod.outlook.com (10.174.192.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.9; Tue, 9 Apr 2019 13:04:48 +0000 Received: from CO2PR05MB2455.namprd05.prod.outlook.com ([fe80::81e2:bbe8:6851:16b2]) by CO2PR05MB2455.namprd05.prod.outlook.com ([fe80::81e2:bbe8:6851:16b2%6]) with mapi id 15.20.1792.007; Tue, 9 Apr 2019 13:04:48 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "huubatwork@gmail.com" , "mpls@ietf.org" CC: "draft-zzhang-mpls-rmr-multicast@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: MPLS-RT review of draft-zzhang-mpls-rmr-multicast Thread-Index: AQHU5UdoXX/k5SRry0WfLJCBg3kMV6YyGKsAgAAHF+CAAKMngIABGOvA Content-Class: Date: Tue, 9 Apr 2019 13:04:48 +0000 Message-ID: References: <0df832d7-8389-e9dd-95aa-46d8c8d06da5@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=zzhang@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-04-09T13:04:41.9092707Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Internal; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic; Sensitivity=Juniper Internal x-originating-ip: [116.197.188.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ee1214de-ea3d-43da-ef6e-08d6bcebf20b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:CO2PR05MB2760; x-ms-traffictypediagnostic: CO2PR05MB2760: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(396003)(346002)(376002)(136003)(189003)(199004)(31014005)(37854004)(446003)(5660300002)(102836004)(8676002)(97736004)(6506007)(4326008)(2501003)(68736007)(256004)(26005)(6436002)(99286004)(53546011)(25786009)(33656002)(7736002)(74316002)(11346002)(93886005)(476003)(186003)(52536014)(81156014)(81166006)(7696005)(478600001)(14444005)(76176011)(14454004)(8936002)(486006)(55016002)(66574012)(316002)(106356001)(229853002)(6246003)(86362001)(9686003)(6306002)(236005)(53946003)(71190400001)(790700001)(110136005)(54896002)(3846002)(6116002)(2906002)(71200400001)(53936002)(54906003)(66066001)(105586002)(579004)(559001)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2760; H:CO2PR05MB2455.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AJxUut1JBZ/m9k4ApSDEIJMfOCyyC4oON3tRJItG0WqV0ON0xqqpFnTf5QctvqRYtDKK5bkwqFikzy2IXKfKEeMMcM19JQrlg450FWVyRYMsmGdEVLSlQgRuaqyab/x12jZovtC/tzVtGlqlotuQvWJbsHyJtyTGxjb9d/a2Aloh4vw+yUVEsZRGP3Jlb4mjcqqPiAK1C0GHoBqPTDrFAt5O2qHTun7z/nNWnjG4rKRnVMkDEeqjZMHW/xRrVDUTMY758lZSU2OSiYsu/mCffKRj9EL4xLG37EnkRdRlD5kSg97ctVe2PCEJNTLwSGrAcpq93Bvg8533NSq58nuvPKo17A1bDr7CAxn0n+DmEiXjAHZ92NTpUTHHgys339bfq/bZWYU3yIeUhG1iOvGbqtroo2hru4+7t8rPkdiL+oQ= Content-Type: multipart/alternative; boundary="_000_CO2PR05MB24554DED1C246AA9227C1015D42D0CO2PR05MB2455namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: ee1214de-ea3d-43da-ef6e-08d6bcebf20b X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2019 13:04:48.2367 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2760 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-09_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904090083 Archived-At: Subject: Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rmr-multicast X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 13:04:58 -0000 --_000_CO2PR05MB24554DED1C246AA9227C1015D42D0CO2PR05MB2455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Huub, Please see zzh2> below. Juniper Internal From: Huub van Helvoort Sent: Monday, April 8, 2019 4:08 PM To: Jeffrey (Zhaohui) Zhang ; mpls@ietf.org Cc: draft-zzhang-mpls-rmr-multicast@ietf.org; mpls-chairs@ietf.org Subject: Re: MPLS-RT review of draft-zzhang-mpls-rmr-multicast Hello Jeffrey, Please see my response in-line [hvh]. Hi Huub, Thank you for your review and comments. Please see zzh> below. Non-Juniper From: Huub van Helvoort Sent: Monday, April 8, 2019 5:58 AM To: mpls@ietf.org Cc: draft-zzhang-mpls-rmr-multicast@ietf.org; mpls-chairs@ietf.org Subject: MPLS-RT review of draft-zzhang-mpls-rmr-multicast All, I've been selected as an MPLS-RT reviewer for draft-zzhang-mpls-rmr-multica= st, which is currently a candidate for MPLS WG adoption. In the abstract is stated: With Resilient MPLS Rings (RMR), although all existing multicast procedures and solutions can work as is, there are optimizations that could be done for RSVP-TE P2MP tunnel signaling and Fast-ReRouting for both mLDP and RSVP-TE P2MP tunnels. I have carefully read the draft but I could not find any justification for the optimisation that could be done. Zzh> By "justification", do you mean "need"? I thought the following text p= rovides that: For a conventionally signaled RSVP-TE P2MP tunnel, an ingress LSR discovers leaves and signals one sub-LSP for each leaf. Even though the forwarding state is merged at each hop (i.e, one incoming label mapping to multiple outgoing entries), the control plane maintains individual sub-LSP state. This leads to lots of redundant state on routers close to the ingress. [hvh] "lots of state" - can you be more specific? is the redundancy 10% or = 90% ? Zzh2> Depending on how many leaves you have. With traditional RSVP-TE P2MP,= there is one sub-LSP to each leaf. If you have 20 leaves, the saving is 95= % (I mean you only need to maintain 5% of state compared to traditional way= ). If you have 10 leaves, the saving is 90%. I don't think the draft needs = to quantify it. Zzh> Or do you mean "why" the optimization COULD be done? The key is that t= his is a ring, and: ... As the PATH message passes along the ring, the leaves send RESV messages, but only one RESV message reaches the tunnel ingress. [hvh] can you explain why only one RESV message reaches the tunnel ingress? Zzh2> Because only one PATH message is sent, and the RESV state gets merged= accordingly along the way. Zzh> If you mean "how" it is done, I thought the following describes it: ... With RMR, this can be optimized such that only a single LSP is signaled, with all the leaves listed in the PATH message. As the PATH message passes along the ring, the leaves send RESV messages, but only one RESV message reaches the tunnel ingress. The ingress LSR may also send PATH messages in both directions, so that the tunnel is set up in such a way that minimum delay is incurred for traffic to reach all leaves. Alternatively, the ingress may send PATH message only in one direction for best bandwidth utilization. For example, a leaf D is three hops away from the ingress A in clockwise direction (A,B,C,D) and four hops away in the other direction (A,E,F,G,D), but G is also a leaf so it may be better to just send the PATH message in the anticlockwise direction. Each router establishes forwarding state accordingly. Transit routers switches traffic towards downstream. A transit router could also be a leaf router and in that case it does "drop and continue" - sends traffic off the ring and switches traffic downstream. 2.1. Tunnel Protection and FRR Each node on a ring signals two counter-rotating MP2P RSVP-TE LSPs to itself. As these LSPs are self-signaled after the discovery of the ring, they can be used to protect P2MP LSPs on ring. So neither mLDP nor RSVP-TE has to setup a separate P2P bypass LSPs for link and node protection. [hvh] This is clear. I also did not find any indication how this optimisation has to be deployed. Do all the nodes in the ring, or in the network have to support this optimisation before it becomes effective. Zzh> The context is RMR - Resilient MPLS Ring. All routers on the ring need= to support RMR and the multicast optimization for this to be effective. I = can make that clear. [hvh] OK. Thanks. I think these issues have to be documented before this draft can be adopted as WG draft. Zzh> Besides explicitly stating that all routers on the ring need to suppor= t the RSVP-TE P2MP optimization for it to be effective, please advise furth= er how the first issue can be better documented. [hvh] when you use the word "optimize" I expect an indication of the effect of the optimization on performance, or used resources. Zzh2> I see. The optimization is on (simpler) procedures and (less) resourc= es. I don't think we need to quantify it. Zzh2> I will update the draft to point out that all routers on the ring nee= ds to support the optimization - please let me know if that is enough. Zzh2> Thanks! Zzh2> Jeffrey Cheers, 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... --_000_CO2PR05MB24554DED1C246AA9227C1015D42D0CO2PR05MB2455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Huub,=

=  

Pleas= e see zzh2> below.

=  

 

Juniper Internal=

From: Huub van Hel= voort <huubatwork@gmail.com>
Sent: Monday, April 8, 2019 4:08 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; mpls@ietf.or= g
Cc: draft-zzhang-mpls-rmr-multicast@ietf.org; mpls-chairs@ietf.org Subject: Re: MPLS-RT review of draft-zzhang-mpls-rmr-multicast<= /o:p>

 

Hello Jeffrey,

 

Please see my response in-line [hvh].

 

H= i Huub,

&= nbsp;

T= hank you for your review and comments. Please see zzh> below.

&= nbsp;

 

Non-Juniper

From: Huub van = Helvoort <huubatwork@gmail.com>
Sent: Monday, April 8, 2019 5:58 AM
To: mpls@ietf.org
Cc: draf= t-zzhang-mpls-rmr-multicast@ietf.org; mpls-chairs@ietf.org
Subject: MPLS-RT review of draft-zzhang-mpls-rmr-multicast

 

All,

 

I’ve been selected as an MPLS-RT reviewer for draft-z= zhang-mpls-rmr-multicast,
which is currently a candidate for MPLS WG adoption.

 

In the abstract is stated:

   With Resilient MP=
LS Rings (RMR), although all existing multicast
   procedures and so=
lutions can work as is, there are optimizations that
   could be done for=
 RSVP-TE P2MP tunnel signaling and Fast-ReRouting
   for both mLDP and=
 RSVP-TE P2MP tunnels.

I have carefully read the draft but I could not find any ju= stification
for the optimisation that could be done.

&= nbsp;

Z= zh> By “justification", do you mean “need”? I tho= ught the following text provides that:

&= nbsp;

 &nb= sp; For a conventionally signaled RSVP-TE P2MP tunnel, an ingress LS= R

 &nb= sp; discovers leaves and signals one sub-LSP for each leaf.  Even though

 &nb= sp; the forwarding state is merged at each hop (i.e, one incoming la= bel

 &nb= sp; mapping to multiple outgoing entries), the control plane maintai= ns

 &nb= sp; individual sub-LSP state.  This leads to lots of redundant state on

 &nb= sp; routers close to the ingress.

[hvh] "lots of state" - can you be more specific?= is the redundancy 10% or 90% ?

Zzh2&= gt; Depending on how many leaves you have. With traditional RSVP-TE P2MP, t= here is one sub-LSP to each leaf. If you have 20 leaves, the saving is 95% (I mean you only need to maintain 5% of state co= mpared to traditional way). If you have 10 leaves, the saving is 90%. I don= ’t think the draft needs to quantify it.



Z= zh> Or do you mean “why” the optimization COULD be done? The= key is that this is a ring, and:

&= nbsp;

 &nb= sp; … As the PATH message passes along the ring, the leaves

 &nb= sp; send RESV messages, but only one RESV message reaches the tunnel=

 &nb= sp; ingress.

[hvh] can you explain why only one RESV message reaches the= tunnel ingress?

Zzh2&= gt; Because only one PATH message is sent, and the RESV state gets merged a= ccordingly along the way.



&= nbsp;Zzh> If you mean “how” it is done, I thought the follow= ing describes it:

&= nbsp;

 &nb= sp; … With RMR, this can be optimized such

 &nb= sp; that only a single LSP is signaled, with all the leaves listed i= n the

 &nb= sp; PATH message.  As the PATH message passes along the ring, the leaves

 &nb= sp; send RESV messages, but only one RESV message reaches the tunnel=

 &nb= sp; ingress.

 

 &nb= sp; The ingress LSR may also send PATH messages in both directions, = so

 &nb= sp; that the tunnel is set up in such a way that minimum delay is

 &nb= sp; incurred for traffic to reach all leaves.  Alternatively, the ingress

 &nb= sp; may send PATH message only in one direction for best bandwidth

 &nb= sp; utilization.  For example, a leaf D is three hops away from the<= /p>

 &nb= sp; ingress A in clockwise direction (A,B,C,D) and four hops away in= the

 &nb= sp; other direction (A,E,F,G,D), but G is also a leaf so it may be b= etter

 &nb= sp; to just send the PATH message in the anticlockwise direction.

 

 &nb= sp; Each router establishes forwarding state accordingly.  Transit

 &nb= sp; routers switches traffic towards downstream.  A transit router could

 &nb= sp; also be a leaf router and in that case it does "drop and co= ntinue" -

 &nb= sp; sends traffic off the ring and switches traffic downstream.



2.1. = ; Tunnel Protection and FRR

 

 &nb= sp; Each node on a ring signals two counter-rotating MP2P RSVP-TE LS= Ps to

 &nb= sp; itself.  As these LSPs are self-signaled after the discovery of the

 &nb= sp; ring, they can be used to protect P2MP LSPs on ring.  So neither mLDP

 &nb= sp; nor RSVP-TE has to setup a separate P2P bypass LSPs for link and= node

 &nb= sp; protection.

[hvh]  This is clear.


I also did not find any indication how this optimisation ha= s to be
deployed. Do all the nodes in the ring, or in the network have to
support this optimisation before it becomes effective.

&= nbsp;

Z= zh> The context is RMR – Resilient MPLS Ring. All routers on the r= ing need to support RMR and the multicast optimization for this to be effective. I can make that clear.

[hvh] OK. Thanks.


 I think these issues have to be documented before thi= s draft can

be adopted as WG draft.

&= nbsp;

Zzh> Besides explicitly stating that all rou= ters on the ring need to support the RSVP-TE P2MP optimization for it to be effective, please advise further how the first issue can be b= etter documented.

[hvh] when you use the word "optimize" I expect a= n indication of
the effect of the optimization on performance, or used resources.

=  

Zzh2&= gt; I see. The optimization is on (simpler) procedures and (less) resources= . I don’t think we need to quantify it.

Zzh2&= gt; I will update the draft to point out that all routers on the ring needs= to support the optimization – please let me know if that is enough.

Zzh2&= gt; Thanks!

Zzh2&= gt; Jeffrey



Cheers, 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...<=
/o:p>
--_000_CO2PR05MB24554DED1C246AA9227C1015D42D0CO2PR05MB2455namp_-- From nobody Tue Apr 9 08:03:26 2019 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 89C7812088F; Tue, 9 Apr 2019 08:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJS9wWQ2e2Tw; Tue, 9 Apr 2019 08:03:14 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 11F06120872; Tue, 9 Apr 2019 08:03:14 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 14AAB2F7F80ED824C16A; Tue, 9 Apr 2019 16:03:11 +0100 (IST) Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 9 Apr 2019 16:03:09 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.113]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0415.000; Tue, 9 Apr 2019 23:03:03 +0800 From: Mach Chen To: =?utf-8?B?w4lyaWMgVnluY2tl?= , The IESG CC: "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" , "mpls-chairs@ietf.org" , "loa@pi.nu" , "mpls@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtbXBs?= =?utf-8?Q?s-lsp-ping-lag-multipath-08:_(with_COMMENT)?= Thread-Index: AQHU7eP8YAHA51lRdEm7xBeljvkK5qYyKE8g Date: Tue, 9 Apr 2019 15:03:02 +0000 Message-ID: References: <155471164675.6386.10341508380803392820.idtracker@ietfa.amsl.com> In-Reply-To: <155471164675.6386.10341508380803392820.idtracker@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.200.64.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-mpls-lsp-ping-lag-multipath-08=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 15:03:17 -0000 SGkgRXJpYywNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIQ0KDQpQbGVhc2Ugc2VlIG15IHJl cGxpZXMgaW5saW5lLi4uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog w4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+ IFNlbnQ6IE1vbmRheSwgQXByaWwgMDgsIDIwMTkgNDoyMSBQTQ0KPiBUbzogVGhlIElFU0cgPGll c2dAaWV0Zi5vcmc+DQo+IENjOiBkcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctbGFnLW11bHRpcGF0 aEBpZXRmLm9yZzsgbXBscy1jaGFpcnNAaWV0Zi5vcmc7DQo+IGxvYUBwaS5udTsgbXBsc0BpZXRm Lm9yZw0KPiBTdWJqZWN0OiDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0 Zi1tcGxzLWxzcC1waW5nLWxhZy1tdWx0aXBhdGgtMDg6DQo+ICh3aXRoIENPTU1FTlQpDQo+IA0K PiDDiXJpYyBWeW5ja2UgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24g Zm9yDQo+IGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1sYWctbXVsdGlwYXRoLTA4OiBObyBPYmpl Y3Rpb24NCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGlu ZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbA0KPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4g dGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkN Cj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZv ciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlv bnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3Np dGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctbGFnLW11bHRpcGF0aC8NCj4gDQo+IA0KPiAN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBWZXJ5 IHVzZWZ1bCBkb2N1bWVudCBhbmQgdGVjaG5pcXVlczsgYnV0LCBJIGFtIGFmcmFpZCB0aGF0IEkg aGF2ZSBzb21lIGlzc3Vlcw0KPiB3aXRoIHRoaXMgZG9jdW1lbnQgaW4gaXRzIHByZXNlbnQgZm9y bTogbm90aGluZyBvbiB0aGUgYWN0dWFsIHRlY2huaXF1ZSBidXQNCj4gcmF0aGVyIG9uIGhvdyB0 aGUgc3BlY2lmaWNhdGlvbiBpcyB3cml0dGVuLg0KPiANCj4gQ09NTUVOVFMNCj4gDQo+IDEpIFNl Y3Rpb24gMywgSSB3b25kZXIgd2h5IHRoZSAiTFNSIENhcGFiaWxpdHkgRGlzY292ZXJ5IiBUTFYg aXMgbm90IHBhcnQgb2YNCj4gYW5vdGhlciBkb2N1bWVudDogaXQgc2VlbXMgc28gaW1wb3J0YW50 IHRvIG1lIHRoYXQgaXQgd291bGQgaGF2ZSBkZXNlcnZlZCBpdHMNCj4gb3duIGRvY3VtZW50IChh bmQgYXZvaWRpbmcgdGhlIGZhdGUgc2hhcmluZyB3aXRoIHRoZSBMQUcgZGlzY292ZXJ5KS4gUHJv YmFibHkNCj4gdG9vIGxhdGUgdG8gY2hhbmdlIGFueXdheS4NCg0KSW5kZWVkLCBzZWVtcyB0b28g bGF0ZS4NCg0KDQo+IA0KPiAyKSBTZWN0aW9uIDMuMiwgd2hpbGUgdGhpcyBzZWN0aW9uIGlzIGFi b3V0IHRoZSBnZW5lcmljIGRpc2NvdmVyeSBUTFYsIHRoZSB0ZXh0IGluDQo+IDMuMiBpcyBvbmx5 IGFib3V0ICJMQUcgRGVzY3JpcHRpb24gSW5kaWNhdG9yIiBmbGFnLiBUaGlzIHRleHQgc2hvdWxk IHJhdGhlciBiZSBpbg0KPiBTZWN0aW9uIDQuDQoNClRoZXJlIHdlcmUgc29tZSBkaXNjb3Zlcnkg dGV4dCBpbiBzZWN0aW9uIDQsIGJ1dCBpdCBsb29rcyBhIGJpdCByZWR1bmRhbnQsIHRoZXJlIHdl cmUgc29tZSBjb21tZW50cyBhYm91dCB0aGUgcmVkdW5kYW50LiBUaGVuIGl0IHdhcyBkZWNpZGVk IHRvIG1vdmUgdGhlIHRleHQgdG8gc2VjdGlvbiAzLCBhbmQga2VlcCBzZWN0aW9uIDQgY2xlYXJl ci4gIA0KDQpJZiB5b3UgZG8gbm90IG9iamVjdGlvbiwgSSBpbmNsaW5lIHRvIGtlZXAgaXQgYXMg aXMuDQoNCj4gDQo+IDMpIFRyYWNlcm91dGUgd2l0aCBUVEwgZXhwaXJpbmcsIHdpbGwgaXQgcmVx dWlyZSB0aGUgJ2V4cGlyaW5nJyBMU1IgdG8gY2hlY2sgZm9yDQo+IGNhcGFiaWxpdHkgZGlzY292 ZXJ5ID8gT3IgaXMgaXQgYSAyLXN0ZXAgcHJvY2VkdXJlIChkaXNjb3ZlciB0aGUgcGF0aCwgdGhl biBhc2sgZm9yDQo+IGNhcGFiaWxpdGllcyk/DQoNCkl0IGNhbiBiZSBkb25lIGVpdGhlciB3YXks IHRoZSByZXNwb25kZXIgTFNSIG9ubHkgZGVwZW5kcyBvbiB3aGV0aGVyIHRoZXJlIGlzIGEgRGlz Y292ZXJ5IFRMViB0byBwcm9jZXNzIGFuZCByZXBseS4NCg0KPiANCj4gNCkgU2VjdGlvbiA4LCB1 bmNsZWFyIHRvIG1lIHdoZXJlICJMb2NhbCBJbnRlcmZhY2UgSW5kZXgiIGlzIGNvbWluZyBmcm9t Li4uIGlzIGl0DQo+IGFuIG9wYXF1ZSB2YWx1ZSBmb3IgdGhlIGluaXRpYXRvciBvciBkb2VzIGl0 IGhhdmUgYW55IHNlbWFudGljID8gU2FtZSBxdWVzdGlvbg0KPiBhcHBsaWVzIHRvIHNlY3Rpb24g OSBvZiBjb3Vyc2UuDQoNClRoZSBMb2NhbCBpbnRlcmZhY2UgaW5kZXggaXMgYSB2YWx1ZSB0aGF0 IGlzIGFsbG9jYXRlZCBieSB0aGUgcmVzcG9uZGVyIExTUiAobG9jYWwgc2lnbmlmaWNhbnQpLCBp dCdzIG9wYXF1ZSB0byB0aGUgaW5pdGlhdG9yLg0KDQo+IA0KPiA1KSBTZWN0aW9uIDEwLCBpbiBJ UHY2IGFueSBpbnRlcmZhY2UgY2FuIGhhdmUgbXVsdGlwbGUgSVB2NiBhZGRyZXNzZXMsIHNvLCB0 aGUNCj4gdGV4dCBzdWNoIGFzICJvciB0aGUgaW50ZXJmYWNlIGFkZHJlc3MiIGlzIG5vdCBhcHBs aWNhYmxlLCBzdWdnZXN0aW9uICJvciBhbnkNCj4gaW50ZXJmYWNlIGdsb2JhbCBhZGRyZXNzIiAo d2hpY2ggY2FuIGJlIGFtYmlndW91cyBhcyB3ZWxsLCBwZXJoYXBzIHRoZQ0KPiAnbG93ZXN0Jw0K PiBhZGRyZXNzID8pDQoNClNpbmNlIHRoZSB0ZXh0IGFwcGxpZXMgdG8gYm90aCBJUHY0IGFuZCBJ UHY2LiBJIGFtIG5vdCBzdXJlIHRoZSBzdWdnZXN0ZWQgdGV4dCBhcHBsaWVzIHRvIElQdjQgY2Fz ZS4NCg0KQlRXLCB0aGlzIHRleHQgYWxpZ25zIHdpdGggUkZDIDgwMjkuDQoNCg0KPiANCj4gTklU Uw0KPiANCj4gTjEpIFNlY3Rpb24gMy4xLCAiaXQgY2FuIHNlbmQgYW4gTVBMUyBlYWNoIHJlcXVl c3QgbWVzc2FnZSIgSSBjYW5ub3QgcGFyc2UNCj4gdGhpcyBwYXJ0IG9mIHRoZSBzZW50ZW5jZQ0K DQpHb29kIGNhdGNoIQ0KDQpJdCBzaG91bGQgYmUgIiBpdCBjYW4gc2VuZCBhbiBNUExTIGVjaG8g cmVxdWVzdCBtZXNzYWdlIg0KDQoNCj4gDQo+IE4yKVNlY3Rpb24gMy4yLCAiV2hlbiBhIHJlc3Bv bmRlciBMU1IgcmVjZWl2ZWQiIHRoZSB1c2Ugb2YgcGFzdCB0ZW5zZSBzZWVtcw0KPiB3ZWlyZCBp biB0aGlzIHNlbnRlbmNlLCBlc3Agd2hlbiBwcmVzZW50IHRlbnNlIGlzIHVzZSBhZnRlci4NCg0K SG93IGFib3V0ICJXaGVuIGEgcmVzcG9uZGVyIExTUiByZWNlaXZlcyIgPw0KDQpCZXN0IHJlZ2Fy ZHMsDQpNYWNoDQo+IA0KDQo= From nobody Wed Apr 10 03:26:43 2019 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 BEAD21200E6; Wed, 10 Apr 2019 03:26:42 -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, 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 5z7fEfi0IyrL; Wed, 10 Apr 2019 03:26:40 -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 2F690120099; Wed, 10 Apr 2019 03:26:40 -0700 (PDT) Received: from [172.22.5.136] (unknown [46.218.58.220]) (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 2EAD533F5AF; Wed, 10 Apr 2019 12:26:38 +0200 (CEST) To: xiong.quan@zte.com.cn Cc: pce@ietf.org, draft-xiong-pce-pcep-extension-sr-tp@ietf.org, gregory.mirsky@ztetx.com, "mpls@ietf.org" , "spring@ietf.org" References: <201904101547214513821@zte.com.cn> From: Loa Andersson Message-ID: Date: Wed, 10 Apr 2019 12:26:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <201904101547214513821@zte.com.cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] =?utf-8?b?562U5aSNOiBTUi1NUExTLVRQOiBRdWVzdGlvbiBvbiBk?= =?utf-8?q?raft-xiong-pce-pcep-extension-sr-tp?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 10:26:43 -0000 Quan, I think you are right that this discussion will be of interest for the SPRING and MPLS working group. I have copied the working group mailing lists. On 2019-04-10 09:47, xiong.quan@zte.com.cn wrote: > > Hi Loa, > > > Thanks for your review and inspired comment! It is very important and > much appreciated. > > > Refer to your question, we proposed the terminology of the "SR-MPLS-TP" > in the following use case draft. > > https://datatracker.ietf.org/doc/draft-hu-mpls-sr-inter-domain-use-cases/ > > > > We plan to work on the definition and scope of SR-MPLS-TP and start > discussion in MPLS and SPRING working group next week. > > Welcome to review and discuss about that draft and provide suggestions > for SR-MPLS-TP! > > > Best Regards, > > Quan > > > > 原始邮件 > *å‘件人：*LoaAndersson > *收件人：*pce@ietf.org > ;draft-xiong-pce-pcep-extension-sr-tp@ietf.org > ; > *æ—¥ 期 ：*2019å¹´04月10æ—¥ 03:55 > *主 题 ：**SR-MPLS-TP: Question on draft-xiong-pce-pcep-extension-sr-tp* > Authors, Working Group, > > MPLS-TP is defined as a network that: > >    "It MUST be possible to operate and configure the MPLS-TP data >     plane without any IP forwarding capability in the MPLS-TP data >     plane. (RFC 5654, section 2.3, requirement 36.)" > >     ... > >   "It MUST be possible to provide protection for the MPLS-TP data >    plane without any IP forwarding capability in the MPLS-TP data >    plane. (RFC 5654, section 2.5.1.1, requirement 63.)" > > In fact most MPLS-TP networks are deployed without IP in the data > plane. > > SR-MPLS on the other hand is a technology that is defined to USE > IGPs to distribute MPLS-labels, and thus requires IP in the data > plane. > > PCEP also runs over TCP/IP. > > The draft does not discuss this. I think this is needed, do you > have plans to do so? > > /Loa > -- > > > Loa Andersson                        email: loa@pi.nu > Senior MPLS Expert > Bronze Dragon Consulting             phone: +46 739 81 21 64 > > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Wed Apr 10 12:23:49 2019 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 157361201CB; Wed, 10 Apr 2019 12:23:48 -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 DzRyaTeB5MWK; Wed, 10 Apr 2019 12:23:46 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 F0CD6120103; Wed, 10 Apr 2019 12:23:45 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id y5so1946889qkc.11; Wed, 10 Apr 2019 12:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=ngCrT48X3AvCw0xtZ0qbSZ3vbfSmI1ZzQ4OoIS0oYoE=; b=hM51UTkwts9YIaZSYBLmxzmxutJyArUkijejmBCEugitnQ1njRy3xATDMjfqMtmAoV /r3x72tRjC+cApHKT6h3ndoOPEBVOdKNwI2KNLpJ7OrOdyGdsytg6o9vFBlHHwYMfadg a8hnfF2PXtSNZNKTcK8vZvymWuXS6LxO0ftNR6KDhiuXv9UEWHE9N4RlQ5KmPva899TV laho5t/xcapEeUoDIWyW82aSelRTrfU5wjyMFTY63JMWWOAl4hQE9nWkLkyNGzguOeG+ OJA2DyA1h9bOEWPf1nds0VbGQADZLrAtQvYsnNkTSOzoShq2DI1ZcIk6wKojoOOzpJYO +z3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=ngCrT48X3AvCw0xtZ0qbSZ3vbfSmI1ZzQ4OoIS0oYoE=; b=gd2aKlCtsFamHRh6GvVJLxFtP54gqCZlG+2iHRfhjjd8XCzYUhQdGLKRwrTOCi3znW tj2q2r+HQBTbphVjRcbT2JIRyYTF62oOyXcIKpa2btiuVqHHtbSFn1uiE8DE6chruWD9 XSHg8HAsC5BkSfoWdY7TQSSi/EUx76G3dJIvh5u8pgt6fK4eTG9A6Z5rh3kaRzszl58a iMv1YB7nUqyKKcMEqV5S5d9LDi8niu08sHy2SCxQXvfh4+L1HphFMEj55GEWKi0eF/06 WAYkQpeZdRslEMEq0zfNduBVPfvZN7ToUb/GgeJfFRsqWd0ykH45Xz8e+XsCxkZ+oha9 yxWQ== X-Gm-Message-State: APjAAAUQMOuLDGMgCLo26k4jrZ/6emfmnP1G//7UjEGngWoPC1+jobPn +gKXyn+wYi5cDcFoNDuCU6Aa9HSN X-Google-Smtp-Source: APXvYqx8FivCWRMrSxTktDVWisu8LRb+wi8cV1vE8bPprhehhsdQtbADW0dgKQm5QqunJupPofI5Og== X-Received: by 2002:ae9:e012:: with SMTP id m18mr1973251qkk.267.1554924224827; Wed, 10 Apr 2019 12:23:44 -0700 (PDT) Received: from BN8PR06MB6289.namprd06.prod.outlook.com ([52.96.29.13]) by smtp.gmail.com with ESMTPSA id t30sm6952836qkm.25.2019.04.10.12.23.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2019 12:23:44 -0700 (PDT) From: Tarek Saad To: "draft-zzhang-mpls-rmr-multicast@ietf.org" CC: "mpls-chairs@ietf.org" , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-zzhang-mpls-rmr-multicast Thread-Index: ATVjYWU3vXyEqIW2kXE8E4lNxAjcHb8Y4wda X-MS-Exchange-MessageSentRepresentingType: 1 Date: Wed, 10 Apr 2019 19:23:43 +0000 Message-ID: References: <0df832d7-8389-e9dd-95aa-46d8c8d06da5@pi.nu> In-Reply-To: <0df832d7-8389-e9dd-95aa-46d8c8d06da5@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rmr-multicast X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 19:23:48 -0000 SGkgYWxsLA0KDQpJ4oCZdmUgYmVlbiBzZWxlY3RlZCBhcyBhbiBNUExTLVJUIHJldmlld2VyIGZv ciB0aGlzIGRyYWZ0IHRoYXQgaXMgdW5kZXJnb2luZyBXRyBhZG9wdGlvbi4NCkJlbG93IGFyZSBt eSBjb21tZW50cy4NCg0KVGhlIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIGRlc2NyaWJlIGhpZ2gt bGV2ZWwgcmVxdWlyZW1lbnRzIGZvciBtdWx0aWNhc3Qgb3ZlciBSTVIgcmluZ3MgYW5kIGRvY3Vt ZW50IGNvdmVycyBzcGVjaWZpY3MgdGhhdCBhcmUgbm90IGRlcGVuZGVudCBvbiB0aGUgc2lnbmFs aW5nIHByb3RvY29sIHVzZWQgdG8gc2V0dXAgdGhlIE0vUDJNUCBMU1AgcmluZ3MuDQotIEkgc3Rp bGwgZm91bmQsIGhvd2V2ZXIsIGluc3RhbmNlcyB3aGVyZSBpdCdzIHRyeWluZyB0byBkZXNjcmli ZSBwcm90b2NvbCBzcGVjaWZpYyBzaWduYWxpbmcgZGV0YWlscw0KLSBJTU8sIHRoaXMgc2hvdWxk IGJlIGRlZmVycmVkIHRvIHRoZSBvdGhlciBSTVIgcHJvdG9jb2wgc3BlY2lmaWMgZG9jdW1lbnRz Lg0KLSBJZGVhbGx5LCBzaG91bGQgY29uc2lkZXIgaW5jb3Jwb3JhdGluZyB0aGlzIGRvY3VtZW50 IGFzIGEgc2VjdGlvbiBpbnRvIHRoZSBtYWluIFJNUiBoaWdoLWxldmVsIGRvY3VtZW50IElEOiBk cmFmdC1pZXRmLW1wbHMtcm1yLiBXYXMgdGhpcyBjb25zaWRlcmVkPw0KDQo+PiAgIFRoaXMgbGVh ZHMgdG8gbG90cyBvZiByZWR1bmRhbnQgc3RhdGUgb24gcm91dGVycyBjbG9zZSB0byB0aGUgaW5n cmVzcy4NCj4+ICAgV2l0aCBSTVIsIHRoaXMgY2FuIGJlIG9wdGltaXplZCBzdWNoDQo+PiAgIHRo YXQgb25seSBhIHNpbmdsZSBMU1AgaXMgc2lnbmFsZWQsIHdpdGggYWxsIHRoZSBsZWF2ZXMgbGlz dGVkIGluIHRoZSBQQVRIIG1lc3NhZ2UuDQpbVFNdOiBJIHRoaW5rIGEgc2luZ2xlIHN1Yi1MU1Ag c3RhdGUgc3RpbGwgbmVlZHMgdG8gYmUgbWFpbnRhaW5lZCwgcmVnYXJkbGVzcyBpZiB0aGV5IGFy ZSBzaWduYWxlZCBpbiBhIHNpbmdsZSBvciBtdWx0aXBsZSBQQVRIIG1lc3NhZ2VzLiBUaGlzIGlz IG5lZWRlZCBzbyBhIGxlYWYgY2FuIGdyYWZ0ZWQgb3IgcHJ1bmVkIHdpdGhvdXQgYWZmZWN0aW5n IGV4aXN0aW5nIGxlYWZzLg0KTm90ZSwgUkZDNDg3NSBhbHJlYWR5IGFsbG93cyBmb3Igc2lnbmFs aW5nIG11bHRpcGxlIHN1Yi1MU1AocykgaW4gYSBzaW5nbGUgUEFUSCBtZXNzYWdlIChzZWUgcmZj NDg3NSBzZWN0aW9uIDUuMi4yKSAtIHNvIG5vdCBjbGVhciBvZiB0aGUgbmV3IG9wdGltaXphdGlv bnMgbWVudGlvbmVkIGhlcmUuDQoNClNlY3Rpb24gMjoNCj4+IGluZ3Jlc3MgQSBpbiBjbG9ja3dp c2UgZGlyZWN0aW9uIChBLEIsQyxEKSBhbmQgZm91ciBob3BzIGF3YXkgaW4gdGhlLi4uLg0KSSBj b3VsZCBub3QgZmluZCB0aGUgZmlndXJlIHRoYXQgc2hvd3MgdGhvc2Ugbm9kZXM/IElNTywgdGhp cyBoaWdoLWxldmVsIGRlc2NyaXB0aW9uIGNhbiByZWZyYWluIGZyb20gZGVzY3JpYmluZyBzaWdu YWxpbmcgcHJvdG9jb2wgc3BlY2lmaWMgZGV0YWlscy4NCg0KPj4gICBUaGUgUEFUSCBtZXNzYWdl IGRvZXMgbm90IG5lZWQgdG8gbGlzdCBhbGwgbGVhdmVzLiAgQXMgbG9uZyBhcyBhIGxlYWYgc29t ZWhvdyBkZXRlcm1pbmVzIHRoYXQgaXQgaXMgYSBsZWFmLCBpdCBjYW4gc2VuZCBSRVNWIG1lc3Nh Z2Ugd2hlbiBpdCByZWNlaXZlcyB0aGUgUEFUSCBtZXNzYWdlLg0KW1RTXTogV2l0aCBSU1ZQLVRF LCBhIFAyTVAgbm9kZSBkaXNjb3ZlcnMgaXTigJlzIGEgbGVhZiB1cG9uIHByb2Nlc3NpbmcgdGhl IFBBVEggdGhhdCBjb250YWlucyBhIFMyTF9TVUJfTFNQIHdpdGggYSBtYXRjaGluZyBsb2NhbCBh ZGRyZXNzLiBTaW5jZSB0aGUgUEFUSCBtZXNzYWdlIGlzIHJlYWNoaW5nIHRoZSBub2RlLCBub3Qg Y2xlYXIgb24gd2hhdCBpcyBvcHRpbWl6YXRpb24gaW4gdGhpcyBjYXNlLg0KDQo+PiBPbmNlIHRo ZSB0cmFmZmljIGlzIG91dCBvZiB0aGUgcmluZyAgTFNQIG9uIFIzLA0KW1RTXTogSSB0aGluayBj bGVhcmVyIGFzICJPbmNlIHRyYWZmaWMgaXMgb3V0IG9mIHRoZSBDVyBMU1AgdG8gUjMiLiBBbHNv LCBpdCBpcyB1bmNsZWFyIGlmL2hvdyBQTFIoMikgY2FuIGRpc3Rpbmd1aXNoIHdoZXRoZXIgdG8g dHVubmVsIHRyYWZmaWMgb3ZlciBDVyBMU1AgdG8gbm9kZSBSMyBvciB0byBub2RlIFI0IC0gaS5l LiBjYXNlIG9mIFIzIG5vZGUgZmFpbHVyZT8NCg0KPj4gU2VjdGlvbiAzOiBFbmQgdG8gRW5kIFR1 bm5lbHMgd2l0aCBSaW5ncw0KW1RTXTogZG8geW91IG1lYW4gZnVsbCBtZXNoIG9mIHR1bm5lbHMg YmV0d2VlbiBQRXM/IFRoZSBzdW1tYXJ5IEkgY2FuIGRyYXcgZnJvbSB0aGlzIHNtYWxsIHNlY3Rp b24gaXMgdGhhdCBSTVIgKGFzIGFub3RoZXIgZm9ybSBvZiBQLXR1bm5lbHMpIGlzIG5vdCBpbnRy b2R1Y2luZyBhbnkgbmV3IHJlcXVpcmVtZW50cywgcmlnaHQ/DQoNClJlZ2FyZHMsDQpUYXJlaw0K DQoNCu+7v09uIDMvMjgvMTksIDU6MTkgQU0sICJMb2EgQW5kZXJzc29uIiA8bG9hQHBpLm51PiB3 cm90ZToNCg0KICAgIFRhcmVrLCBBbmR5LCBIdXViIGFuZCBSYWppdiwNCiAgICANCiAgICBZb3Ug aGF2ZSBiZSBzZWxlY3RlZCBhcyBNUExTLVJUIHJldmlld2VycyBmb3INCiAgICBkcmFmdC16emhh bmctbXBscy1ybXItbXVsdGljYXN0LTAyLg0KICAgIA0KICAgIE5vdGUgdG8gYXV0aG9yczogWW91 IGhhdmUgYmVlbiBDQydkIG9uIHRoaXMgZW1haWwgc28gdGhhdCB5b3UgY2FuIGtub3cNCiAgICB0 aGF0IHRoaXMgcmV2aWV3IGlzIGdvaW5nIG9uLiBIb3dldmVyLCBwbGVhc2UgZG8gbm90IHJldmll dyB5b3VyIG93bg0KICAgIGRvY3VtZW50Lg0KICAgIA0KICAgIFJldmlld3Mgc2hvdWxkIGNvbW1l bnQgb24gd2hldGhlciB0aGUgZG9jdW1lbnQgaXMgY29oZXJlbnQsIGlzIGl0DQogICAgdXNlZnVs IChpZSwgaXMgaXQgbGlrZWx5IHRvIGJlIGFjdHVhbGx5IHVzZWZ1bCBpbiBvcGVyYXRpb25hbA0K ICAgIG5ldHdvcmtzKSwgYW5kIGlzIHRoZSBkb2N1bWVudCB0ZWNobmljYWxseSBzb3VuZD8gIFdl IGFyZSBpbnRlcmVzdGVkDQogICAgaW4ga25vd2luZyB3aGV0aGVyIHRoZSBkb2N1bWVudCBpcyBy ZWFkeSB0byBiZSBjb25zaWRlcmVkIGZvciBXRw0KICAgIGFkb3B0aW9uIChpZSwgaXQgZG9lc24n dCBoYXZlIHRvIGJlIHBlcmZlY3QgYXQgdGhpcyBwb2ludCwgYnV0IHNob3VsZCBiZQ0KICAgIGEg Z29vZCBzdGFydCkuDQogICAgDQogICAgUmV2aWV3cyBzaG91bGQgYmUgc2VudCB0byB0aGUgZG9j dW1lbnQgYXV0aG9ycywgV0cgY28tY2hhaXJzIGFuZA0KICAgIFdHIHNlY3JldGFyeSwgYW5kIEND J2QgdG8gdGhlIE1QTFMgV0cgZW1haWwgbGlzdC4gSWYgbmVjZXNzYXJ5LCBjb21tZW50cw0KICAg IG1heSBiZSBzZW50IHByaXZhdGVseSB0byBvbmx5IHRoZSBXRyBjaGFpcnMuDQogICAgDQogICAg SWYgeW91IGhhdmUgdGVjaG5pY2FsIGNvbW1lbnRzIHlvdSBzaG91bGQgdHJ5IHRvIGJlIGV4cGxp Y2l0IGFib3V0IHdoYXQNCiAgICAqcmVhbGx5KiBuZWVkIHRvIGJlIHJlc29sdmVkIGJlZm9yZSBh ZG9wdGluZyBpdCBhcyBhIHdvcmtpbmcgZ3JvdXANCiAgICBkb2N1bWVudCwgYW5kIHdoYXQgY2Fu IHdhaXQgdW50aWwgdGhlIGRvY3VtZW50IGlzIGEgd29ya2luZyBncm91cA0KICAgIGRvY3VtZW50 IGFuZCB0aGUgd29ya2luZyBncm91cCBoYXMgdGhlIHJldmlzaW9uIGNvbnRyb2wuDQogICAgDQog ICAgQXJlIHlvdSBhYmxlIHRvIHJldmlldyB0aGlzIGRyYWZ0IGJ5IEFwcmlsIDEyLCAyMDE5PyBQ bGVhc2UgcmVzcG9uZCBpbiBhDQogICAgdGltZWx5IGZhc2hpb24uDQogICAgDQogICAgDQogICAg VGhhbmtzLCBMb2ENCiAgICAoYXMgTVBMUyBXRyBjaGFpcikNCiAgICAtLSANCiAgICANCiAgICAN CiAgICBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBwaS5u dQ0KICAgIFNlbmlvciBNUExTIEV4cGVydA0KICAgIEJyb256ZSBEcmFnb24gQ29uc3VsdGluZyAg ICAgICAgICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KICAgIA0K From nobody Wed Apr 10 18:13:19 2019 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 63D6312046B; Wed, 10 Apr 2019 18:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.338 X-Spam-Level: X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, 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=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 ZXSLpTYNhyqF; Wed, 10 Apr 2019 18:13:15 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 1CAE012068C; Wed, 10 Apr 2019 18:13:15 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3B19wdl002587; Wed, 10 Apr 2019 18:13:11 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=EE0CDNWx/ExMtyxjmT/6805UjwsD5ZnTwiJHHokS+zw=; b=W3wdDvGAn7SdMAwU3Dyv4MHOtdqJtU+v9MdI0q7xOgD18ePDK7vtXJEs1zezkUq6rtTp +oZy9qxZG/b9t11PiuBj1uB75UMKocttLshsTRvEjCk/bkLQ7Mnd4KiYKz/EIi6BNz5q bAyrKUWfyNZmPHnroYQ5wMfHkFnRrJeYGaZdqDoxJ2HUo0NTFkpT2ATDDKMVhxIeGKcq lVmzrWUOVVnqoUpchWcv7aSHL+hVfyTYywUqbnxdbO6sxamUjTGrCFHHiRcbLLkRbKhd ASxBzCB8u9JpZg36bjkMQN8fITPUqELgIbR9jIzgG8asBqvVNOrO7buLMRD5+6dJHgHr IA== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp2053.outbound.protection.outlook.com [104.47.45.53]) by mx0b-00273201.pphosted.com with ESMTP id 2rsssb04yx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 10 Apr 2019 18:13:11 -0700 Received: from CO2PR05MB2455.namprd05.prod.outlook.com (10.166.95.137) by CO2PR05MB2662.namprd05.prod.outlook.com (10.166.95.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.7; Thu, 11 Apr 2019 01:13:08 +0000 Received: from CO2PR05MB2455.namprd05.prod.outlook.com ([fe80::81e2:bbe8:6851:16b2]) by CO2PR05MB2455.namprd05.prod.outlook.com ([fe80::81e2:bbe8:6851:16b2%6]) with mapi id 15.20.1792.007; Thu, 11 Apr 2019 01:13:07 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Tarek Saad , "draft-zzhang-mpls-rmr-multicast@ietf.org" CC: "mpls-chairs@ietf.org" , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-zzhang-mpls-rmr-multicast Thread-Index: AQHU5UdoXX/k5SRry0WfLJCBg3kMV6Y120KAgABZTKA= Content-Class: Date: Thu, 11 Apr 2019 01:13:07 +0000 Message-ID: References: <0df832d7-8389-e9dd-95aa-46d8c8d06da5@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=zzhang@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-04-11T01:13:04.0296200Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Internal; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic; Sensitivity=Juniper Internal x-originating-ip: [117.38.13.71] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c2cb894b-8306-446a-b6d2-08d6be1adb76 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:CO2PR05MB2662; x-ms-traffictypediagnostic: CO2PR05MB2662: x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(136003)(376002)(366004)(396003)(199004)(37854004)(189003)(53754006)(13464003)(2906002)(476003)(6246003)(53936002)(5660300002)(54906003)(53546011)(33656002)(14444005)(256004)(99286004)(7696005)(102836004)(110136005)(6506007)(86362001)(55016002)(9686003)(478600001)(76176011)(6116002)(3846002)(68736007)(14454004)(6436002)(97736004)(106356001)(105586002)(25786009)(7736002)(186003)(4326008)(305945005)(74316002)(2501003)(316002)(11346002)(8676002)(446003)(66066001)(26005)(8936002)(71200400001)(52536014)(81156014)(81166006)(486006)(229853002)(71190400001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2662; H:CO2PR05MB2455.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: dZDP8cPsWPFVCcohtj/eqehpcEyelQVsuefGLIvgrqhFD3aM2QQUK9McJTGijdU1Cviqs7DgyXFGsmUdDHZXFTl5QzKG0m9CbJxYvdL7F+Fvd7eXRQBLMGddubjW4yEX6W7NAGjVm1OI5uF9CpcaM6a+cCGOtjGnY7Ila9u7LturTGI1DKHyVfXRNlpnk15bpGN0D67OQuYIb2hs+6Egn1y4sRYaZ+dFYm4GLQkn2Or7qLwrugRiZEzPU6cTHzEzdsOjZu0IIP8n6ka1AOZrUPDvmTZoF6qBzW/868RibEFm18y9Ehe6mE/sAGM9zgUm3orsfyW6me+6IzKyiTbu0/SUicRN3rywvyGNfRaHVbjRfQO/Htl/DX01ZZ/44/B0JbcDMx1llrHMBU5vrcOYGso7zNd+yYiAYlgwDh8A+AM= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: c2cb894b-8306-446a-b6d2-08d6be1adb76 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 01:13:07.8800 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2662 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-11_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904110006 Archived-At: Subject: Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rmr-multicast X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 01:13:18 -0000 SGkgVGFyZWssDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLiBQbGVhc2Ug c2VlIG15IHJlc3BvbnNlcyBiZWxvdy4NCg0KDQpKdW5pcGVyIEludGVybmFsDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVGFyZWsgU2FhZCA8dHNhYWQubmV0QGdtYWls LmNvbT4NCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMCwgMjAxOSAzOjI0IFBNDQo+IFRvOiBk cmFmdC16emhhbmctbXBscy1ybXItbXVsdGljYXN0QGlldGYub3JnDQo+IENjOiBtcGxzLWNoYWly c0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogTVBMUy1SVCByZXZpZXcg b2YgZHJhZnQtenpoYW5nLW1wbHMtcm1yLW11bHRpY2FzdA0KPiANCj4gSGkgYWxsLA0KPiANCj4g SeKAmXZlIGJlZW4gc2VsZWN0ZWQgYXMgYW4gTVBMUy1SVCByZXZpZXdlciBmb3IgdGhpcyBkcmFm dCB0aGF0IGlzIHVuZGVyZ29pbmcNCj4gV0cgYWRvcHRpb24uDQo+IEJlbG93IGFyZSBteSBjb21t ZW50cy4NCj4gDQo+IFRoZSBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBkZXNjcmliZSBoaWdoLWxl dmVsIHJlcXVpcmVtZW50cyBmb3IgbXVsdGljYXN0DQo+IG92ZXIgUk1SIHJpbmdzIGFuZCBkb2N1 bWVudCBjb3ZlcnMgc3BlY2lmaWNzIHRoYXQgYXJlIG5vdCBkZXBlbmRlbnQgb24NCj4gdGhlIHNp Z25hbGluZyBwcm90b2NvbCB1c2VkIHRvIHNldHVwIHRoZSBNL1AyTVAgTFNQIHJpbmdzLg0KDQpJ dCBkb2VzIG5vdCBkZXNjcmliZSByZXF1aXJlbWVudHMuIFJhdGhlciwgaXQgcG9pbnRzIG91dCB0 aGF0IG11bHRpY2FzdCBjYW4gd29yayBhcyBpcywgb3IgY2FuIGJlIG9wdGltaXplZC4NCg0KPiAt IEkgc3RpbGwgZm91bmQsIGhvd2V2ZXIsIGluc3RhbmNlcyB3aGVyZSBpdCdzIHRyeWluZyB0byBk ZXNjcmliZSBwcm90b2NvbA0KPiBzcGVjaWZpYyBzaWduYWxpbmcgZGV0YWlscw0KPiAtIElNTywg dGhpcyBzaG91bGQgYmUgZGVmZXJyZWQgdG8gdGhlIG90aGVyIFJNUiBwcm90b2NvbCBzcGVjaWZp YyBkb2N1bWVudHMuDQoNClNlY29uZCAyIGRlc2NyaWJlcyBhdCBhIGhpZ2ggbGV2ZWwgaG93IFJT VlAtVEUgUDJNUCB0dW5uZWwgY2FuIGJlIG9wdGltaXplZCB3aXRoIFJNUiwgYnV0IGRvZXMgcmVm ZXIgdG8gW0ktRC56emhhbmctdGVhcy1ybXItcnN2cC1wMm1wXS4gSSBjb3VsZCByZW1vdmUgdGhl IG1ham9yaXR5IG9mIHRoZSB0ZXh0IGluIHNlY3Rpb24gYW5kIHNpbXBseSBwb2ludCBvdXQgdGhh dCBpdCBjb3VsZCBiZSBvcHRpbWl6ZWQuDQoNCj4gLSBJZGVhbGx5LCBzaG91bGQgY29uc2lkZXIg aW5jb3Jwb3JhdGluZyB0aGlzIGRvY3VtZW50IGFzIGEgc2VjdGlvbiBpbnRvIHRoZQ0KPiBtYWlu IFJNUiBoaWdoLWxldmVsIGRvY3VtZW50IElEOiBkcmFmdC1pZXRmLW1wbHMtcm1yLiBXYXMgdGhp cyBjb25zaWRlcmVkPw0KDQpMaWtlIGluIG1hbnkgb3RoZXIgY2FzZXMsIGEgdGVjaG5vbG9neSBt YXkgYmUgZmlyc3Qgc3BlY2lmaWVkIG9ubHkgZm9yIHVuaWNhc3QgaW5pdGlhbGx5IGFuZCB0aGVu IGFkZCBtdWx0aWNhc3QuIEluIHRoaXMgY2FzZSwgd2UgZG9uJ3Qgd2FudCB0byBkZWxheSB0aGUg dW5pY2FzdCBwaWVjZS4NCg0KPiANCj4gPj4gICBUaGlzIGxlYWRzIHRvIGxvdHMgb2YgcmVkdW5k YW50IHN0YXRlIG9uIHJvdXRlcnMgY2xvc2UgdG8gdGhlIGluZ3Jlc3MuDQo+ID4+ICAgV2l0aCBS TVIsIHRoaXMgY2FuIGJlIG9wdGltaXplZCBzdWNoDQo+ID4+ICAgdGhhdCBvbmx5IGEgc2luZ2xl IExTUCBpcyBzaWduYWxlZCwgd2l0aCBhbGwgdGhlIGxlYXZlcyBsaXN0ZWQgaW4gdGhlIFBBVEgN Cj4gbWVzc2FnZS4NCj4gW1RTXTogSSB0aGluayBhIHNpbmdsZSBzdWItTFNQIHN0YXRlIHN0aWxs IG5lZWRzIHRvIGJlIG1haW50YWluZWQsIHJlZ2FyZGxlc3MgaWYNCj4gdGhleSBhcmUgc2lnbmFs ZWQgaW4gYSBzaW5nbGUgb3IgbXVsdGlwbGUgUEFUSCBtZXNzYWdlcy4gVGhpcyBpcyBuZWVkZWQg c28gYQ0KPiBsZWFmIGNhbiBncmFmdGVkIG9yIHBydW5lZCB3aXRob3V0IGFmZmVjdGluZyBleGlz dGluZyBsZWFmcy4NCg0KRG8geW91IG1lYW4gYSAic2VwYXJhdGUgc3ViLUxTUCBzdGF0ZSBzdGls bCBuZWVkIHRvIGJlIG1haW50YWluZWQgZm9yIGVhY2ggbGVhZiI/DQpJIGRvbid0IHRoaW5rIHRo YXQncyBuZWVkZWQgdG8gZ3JhZnQvcHJ1bmUgYSBsZWFmIC0ganVzdCBjb21wYXJlIHRvIGhvdyBt TERQIHdvcmtzLg0KDQo+IE5vdGUsIFJGQzQ4NzUgYWxyZWFkeSBhbGxvd3MgZm9yIHNpZ25hbGlu ZyBtdWx0aXBsZSBzdWItTFNQKHMpIGluIGEgc2luZ2xlDQo+IFBBVEggbWVzc2FnZSAoc2VlIHJm YzQ4NzUgc2VjdGlvbiA1LjIuMikgLSBzbyBub3QgY2xlYXIgb2YgdGhlIG5ldw0KPiBvcHRpbWl6 YXRpb25zIG1lbnRpb25lZCBoZXJlLg0KDQpUaGUgb3B0aW1pemF0aW9uIGhlcmUgaXMgdGhhdCBv bmx5IGEgc2luZ2xlIHN1Yi1MU1AgaXMgbmVlZGVkLg0KDQo+IA0KPiBTZWN0aW9uIDI6DQo+ID4+ IGluZ3Jlc3MgQSBpbiBjbG9ja3dpc2UgZGlyZWN0aW9uIChBLEIsQyxEKSBhbmQgZm91ciBob3Bz IGF3YXkgaW4gdGhlLi4uLg0KPiBJIGNvdWxkIG5vdCBmaW5kIHRoZSBmaWd1cmUgdGhhdCBzaG93 cyB0aG9zZSBub2Rlcz8gSU1PLCB0aGlzIGhpZ2gtbGV2ZWwNCj4gZGVzY3JpcHRpb24gY2FuIHJl ZnJhaW4gZnJvbSBkZXNjcmliaW5nIHNpZ25hbGluZyBwcm90b2NvbCBzcGVjaWZpYyBkZXRhaWxz Lg0KDQpJIGRpZCBub3QgaW5jbHVkZSBhIGZpZ3VyZSwgdGhpbmtpbmcgdGhhdCB0aGUgKEEsQixD LEQpIGNsb2Nrd2lzZSBhbmQgKEEsRSxGLEcsRCkgIGFudGljbG9ja3dpc2UgdGV4dCB3b3VsZCBi ZSBjbGVhciBlbm91Z2guIEkgY2FuIGVpdGhlciBhZGQgYSBmaWd1cmUgb3IgcmVtb3ZlIG1vc3Qg b2YgdGhlIHRleHQgYXMgbWVudGlvbmVkIGVhcmxpZXIuDQoNCj4gDQo+ID4+ICAgVGhlIFBBVEgg bWVzc2FnZSBkb2VzIG5vdCBuZWVkIHRvIGxpc3QgYWxsIGxlYXZlcy4gIEFzIGxvbmcgYXMgYSBs ZWFmDQo+IHNvbWVob3cgZGV0ZXJtaW5lcyB0aGF0IGl0IGlzIGEgbGVhZiwgaXQgY2FuIHNlbmQg UkVTViBtZXNzYWdlIHdoZW4gaXQNCj4gcmVjZWl2ZXMgdGhlIFBBVEggbWVzc2FnZS4NCj4gW1RT XTogV2l0aCBSU1ZQLVRFLCBhIFAyTVAgbm9kZSBkaXNjb3ZlcnMgaXTigJlzIGEgbGVhZiB1cG9u IHByb2Nlc3NpbmcgdGhlDQo+IFBBVEggdGhhdCBjb250YWlucyBhIFMyTF9TVUJfTFNQIHdpdGgg YSBtYXRjaGluZyBsb2NhbCBhZGRyZXNzLiBTaW5jZSB0aGUNCj4gUEFUSCBtZXNzYWdlIGlzIHJl YWNoaW5nIHRoZSBub2RlLCBub3QgY2xlYXIgb24gd2hhdCBpcyBvcHRpbWl6YXRpb24gaW4gdGhp cw0KPiBjYXNlLg0KPiANCg0KVGhpbmsgaG93IG1MRFAgd29ya3MuIExhYmVsIG1hcHBpbmcgaXMg c2VudCBmcm9tIGEgbGVhZiB0b3dhcmRzIHRoZSByb290IGFuZCBhIGxlYWYga25vd3MgaXQncyBs ZWFmIGJ5IG90aGVyIG1lYW5zIChub3QgdGhyb3VnaCBtTERQIG1lY2hhbmlzbXMpLiBXYW50IHRv IGFwcGx5IHRoZSBzYW1lIGhlcmUgYXMgYW4gb3B0aW9uLg0KDQo+ID4+IE9uY2UgdGhlIHRyYWZm aWMgaXMgb3V0IG9mIHRoZSByaW5nICBMU1Agb24gUjMsDQo+IFtUU106IEkgdGhpbmsgY2xlYXJl ciBhcyAiT25jZSB0cmFmZmljIGlzIG91dCBvZiB0aGUgQ1cgTFNQIHRvIFIzIi4gDQoNCkxldCBt ZSBxdW90ZSB0aGUgc3Vycm91bmRpbmcgdGV4dCBoZXJlOg0KDQogICBJbiB0aGUgZXZlbnQgb2Yg YSBsaW5rIGZhaWx1cmUgYmV0d2VlbiBSMiBhbmQgUjMsIFIyIHRoZSBQb2ludCBvZg0KICAgTG9j YWwgUmVwYWlyIChQTFIpIHR1bm5lbHMgUDJNUCBMU1AgdHJhZmZpYyBvbiBhIGFudGktY2xvY2t3 aXNlIHJpbmcNCiAgIExTUCB0byBSMyB0aGUgTWVyZ2UgUG9pbnQgKE1QKS4gIE9uY2UgdGhlIHRy YWZmaWMgaXMgb3V0IG9mIHRoZSByaW5nDQogICBMU1Agb24gUjMsIGl0IHVzZXMgdGhlIHJlZ3Vs YXIgUDJNUCBMU1AgdG8gcmVhY2ggUjQuICBTaW1pbGFybHkgaW4NCiAgIHRoZSBldmVudCBvZiBh IG5vZGUgZmFpbHVyZSBSMywgUjIgdGhlIFBMUiB0dW5uZWxzIFAyTVAgTFNQIHRyYWZmaWMNCiAg IHRvIFI0ICh0aGUgTVApLCB3aGljaCBpcyBhbHNvIHRoZSBsZWFmLg0KDQpUaGUgcmluZyBMU1Ag dG8gUjMgdXNlZCB0byB0dW5uZWwgdHJhZmZpYyB3aGVuIFIyLT5SMyBsaW5rIGJyZWFrcyBpcyBh bnRpLWNsb2Nrd2lzZSBub3QgY2xvY2t3aXNlIChDVykuDQoNCj4gQWxzbywgaXQgaXMNCj4gdW5j bGVhciBpZi9ob3cgUExSKDIpIGNhbiBkaXN0aW5ndWlzaCB3aGV0aGVyIHRvIHR1bm5lbCB0cmFm ZmljIG92ZXIgQ1cgTFNQDQo+IHRvIG5vZGUgUjMgb3IgdG8gbm9kZSBSNCAtIGkuZS4gY2FzZSBv ZiBSMyBub2RlIGZhaWx1cmU/DQoNCkEgbm9kZSBuZWVkcyB0byBiZSBhYmxlIHRvIGRldGVybWlu ZSBpZiBhIGZhaWx1cmUgaXMgYSBsaW5rIGZhaWx1cmUgb3Igbm9kZSBmYWlsdXJlLiBPbmNlIGl0 IGtub3dzLCBpdCBrbm93cyBob3cgdG8gdHVubmVsLg0KIA0KPiA+PiBTZWN0aW9uIDM6IEVuZCB0 byBFbmQgVHVubmVscyB3aXRoIFJpbmdzDQo+IFtUU106IGRvIHlvdSBtZWFuIGZ1bGwgbWVzaCBv ZiB0dW5uZWxzIGJldHdlZW4gUEVzPyBUaGUgc3VtbWFyeSBJIGNhbg0KPiBkcmF3IGZyb20gdGhp cyBzbWFsbCBzZWN0aW9uIGlzIHRoYXQgUk1SIChhcyBhbm90aGVyIGZvcm0gb2YgUC10dW5uZWxz KSBpcyBub3QNCj4gaW50cm9kdWNpbmcgYW55IG5ldyByZXF1aXJlbWVudHMsIHJpZ2h0Pw0KDQpJ IG1lYW50IHRoYXQgYW4gZW5kIHRvIGVuZCB0dW5uZWwgY2FuIGdvIHRocm91Z2ggYW4gYXJiaXRy YXJ5IHRvcG9sb2d5LCBwYXJ0IG9mIHdoaWNoIGlzIGEgcmluZyBvciBtdWx0aXBsZSByaW5ncy4N ClJNUiBpcyBub3QgYSBmb3JtIG9mIHR1bm5lbC4gSXQncyBhIHNwZWNpYWwgKHN1Yi0pdG9wb2xv Z3kuDQpSTVIgZG9lcyBub3QgaW50cm9kdWNlIGFueSBuZXcgcmVxdWlyZW1lbnRzLCB0aG91Z2gg eW91IGNvdWxkIG9wdGltaXplIFJTVlAtVEUgUDJNUCB0dW5uZWwgb3ZlciBSTVIsIGFuZCBvcHRp bWl6ZSB0dW5uZWwgcHJvdGVjdGlvbiBmb3IgYm90aCBSU1ZQLVRFIGFuZCBtTERQIFAyTVAgdHVu bmVscy4NCg0KSmVmZnJleQ0KPiANCj4gUmVnYXJkcywNCj4gVGFyZWsNCj4gDQo+IA0KPiDvu79P biAzLzI4LzE5LCA1OjE5IEFNLCAiTG9hIEFuZGVyc3NvbiIgPGxvYUBwaS5udT4gd3JvdGU6DQo+ IA0KPiAgICAgVGFyZWssIEFuZHksIEh1dWIgYW5kIFJhaml2LA0KPiANCj4gICAgIFlvdSBoYXZl IGJlIHNlbGVjdGVkIGFzIE1QTFMtUlQgcmV2aWV3ZXJzIGZvcg0KPiAgICAgZHJhZnQtenpoYW5n LW1wbHMtcm1yLW11bHRpY2FzdC0wMi4NCj4gDQo+ICAgICBOb3RlIHRvIGF1dGhvcnM6IFlvdSBo YXZlIGJlZW4gQ0MnZCBvbiB0aGlzIGVtYWlsIHNvIHRoYXQgeW91IGNhbiBrbm93DQo+ICAgICB0 aGF0IHRoaXMgcmV2aWV3IGlzIGdvaW5nIG9uLiBIb3dldmVyLCBwbGVhc2UgZG8gbm90IHJldmll dyB5b3VyIG93bg0KPiAgICAgZG9jdW1lbnQuDQo+IA0KPiAgICAgUmV2aWV3cyBzaG91bGQgY29t bWVudCBvbiB3aGV0aGVyIHRoZSBkb2N1bWVudCBpcyBjb2hlcmVudCwgaXMgaXQNCj4gICAgIHVz ZWZ1bCAoaWUsIGlzIGl0IGxpa2VseSB0byBiZSBhY3R1YWxseSB1c2VmdWwgaW4gb3BlcmF0aW9u YWwNCj4gICAgIG5ldHdvcmtzKSwgYW5kIGlzIHRoZSBkb2N1bWVudCB0ZWNobmljYWxseSBzb3Vu ZD8gIFdlIGFyZSBpbnRlcmVzdGVkDQo+ICAgICBpbiBrbm93aW5nIHdoZXRoZXIgdGhlIGRvY3Vt ZW50IGlzIHJlYWR5IHRvIGJlIGNvbnNpZGVyZWQgZm9yIFdHDQo+ICAgICBhZG9wdGlvbiAoaWUs IGl0IGRvZXNuJ3QgaGF2ZSB0byBiZSBwZXJmZWN0IGF0IHRoaXMgcG9pbnQsIGJ1dCBzaG91bGQg YmUNCj4gICAgIGEgZ29vZCBzdGFydCkuDQo+IA0KPiAgICAgUmV2aWV3cyBzaG91bGQgYmUgc2Vu dCB0byB0aGUgZG9jdW1lbnQgYXV0aG9ycywgV0cgY28tY2hhaXJzIGFuZA0KPiAgICAgV0cgc2Vj cmV0YXJ5LCBhbmQgQ0MnZCB0byB0aGUgTVBMUyBXRyBlbWFpbCBsaXN0LiBJZiBuZWNlc3Nhcnks IGNvbW1lbnRzDQo+ICAgICBtYXkgYmUgc2VudCBwcml2YXRlbHkgdG8gb25seSB0aGUgV0cgY2hh aXJzLg0KPiANCj4gICAgIElmIHlvdSBoYXZlIHRlY2huaWNhbCBjb21tZW50cyB5b3Ugc2hvdWxk IHRyeSB0byBiZSBleHBsaWNpdCBhYm91dCB3aGF0DQo+ICAgICAqcmVhbGx5KiBuZWVkIHRvIGJl IHJlc29sdmVkIGJlZm9yZSBhZG9wdGluZyBpdCBhcyBhIHdvcmtpbmcgZ3JvdXANCj4gICAgIGRv Y3VtZW50LCBhbmQgd2hhdCBjYW4gd2FpdCB1bnRpbCB0aGUgZG9jdW1lbnQgaXMgYSB3b3JraW5n IGdyb3VwDQo+ICAgICBkb2N1bWVudCBhbmQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHRoZSByZXZp c2lvbiBjb250cm9sLg0KPiANCj4gICAgIEFyZSB5b3UgYWJsZSB0byByZXZpZXcgdGhpcyBkcmFm dCBieSBBcHJpbCAxMiwgMjAxOT8gUGxlYXNlIHJlc3BvbmQgaW4gYQ0KPiAgICAgdGltZWx5IGZh c2hpb24uDQo+IA0KPiANCj4gICAgIFRoYW5rcywgTG9hDQo+ICAgICAoYXMgTVBMUyBXRyBjaGFp cikNCj4gICAgIC0tDQo+IA0KPiANCj4gICAgIExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAg ICAgICAgICBlbWFpbDogbG9hQHBpLm51DQo+ICAgICBTZW5pb3IgTVBMUyBFeHBlcnQNCj4gICAg IEJyb256ZSBEcmFnb24gQ29uc3VsdGluZyAgICAgICAgICAgICBwaG9uZTogKzQ2IDczOSA4MSAy MSA2NA0KPiANCg== From nobody Thu Apr 11 03:51:15 2019 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 A641F120195; Thu, 11 Apr 2019 03:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.015 X-Spam-Level: X-Spam-Status: No, score=-1.015 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_DISPTO=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 G5bEUZ-i7vLg; Thu, 11 Apr 2019 03:51:12 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 E2F6912011D; Thu, 11 Apr 2019 03:51:11 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id w3so4772286edu.10; Thu, 11 Apr 2019 03:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:cc:references:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=HyVQryLgmV0LuKfBf7ai+gcqjMYGgLcZP8gHlVqYQiQ=; b=Qba6FMRHNZvajUm4dSzuOOM8ObQ6y80n98bIMenOWlKVwNfJGtsRI64WNNF/zX/Uhl P6NUHpJvh11V7T5zgWAAqJ1yI1nREhPK9NEdLuzpPvQ6c/jmVjWXvXuGU2QSgc9b8zHM tEmJwsEcU88RGZkqAeLQdjVeGJTx5kTX2feu5SDMT+W6LlqrpDSAAXYKZ8A2tRmzOaO1 BPk52GcZlOTrAfao20XvQSH6REu9NzwnxJ5S6XC9gFICysZ+a5oDPAyYvHIuhS7r6FSE DVqBELwuqKHuQnpshwlR10VAMzqwWc8Bbh3Uzdiof1AhZNCysdJ0ltgJVtCCEWFPD50p Jh3g== 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:to:cc:references:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=HyVQryLgmV0LuKfBf7ai+gcqjMYGgLcZP8gHlVqYQiQ=; b=cnaZihjJHRpDo8CfYPU4HogKfx4jpQraRiYRTfNxLmoTdcaT7Ij6atQWILapmgxD1m H9mt0GLVngYGVabx0CtD6+i2euBwEKrOzA18H/FqdnRXBUrS+M2eD1saBW1tRzIRw9jB 4Lf26KOkQLcH777PaQAdwkIcLuLVM7E9gUWzaC5eRwYyDZE+o0IK0QqLMljfr6UCQ+Iy U+1eOWxKZRWS1F4oHxHms+txoE+tCmN6wUMIhX8Ayw3IdQ+QrM91mzn+ueU1J17+QycO rHPeDgyv8wdFuE1xwtrz/8Pi5n6x9R6scCpueOJrnHhOpaS2CFNPYOs7GJjtOlruFjKn AtfQ== X-Gm-Message-State: APjAAAXTfb/1LADQsyBUjuc9O8XCzJ68Fm6LezjTA+I9LyfXRBzeejnx H01vJfd6jzIc7xw9/8liDMbcg0+U X-Google-Smtp-Source: APXvYqzmo1k2+pmmdas8dcKiDM8mHxt8kJiamaFBnN5AZcjuldT+n55OOPHLixzy1YkDYBrEB2JPsg== X-Received: by 2002:a50:878f:: with SMTP id a15mr30528966eda.196.1554979870234; Thu, 11 Apr 2019 03:51:10 -0700 (PDT) Received: from McAsterix.local ([2a02:a211:8e81:2e00:a8ea:7c58:84f5:e9d8]) by smtp.gmail.com with ESMTPSA id w3sm4310670edq.33.2019.04.11.03.51.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 03:51:09 -0700 (PDT) Reply-To: huubatwork@gmail.com To: "Jeffrey (Zhaohui) Zhang" , "mpls@ietf.org" Cc: "draft-zzhang-mpls-rmr-multicast@ietf.org" , "mpls-chairs@ietf.org" References: <0df832d7-8389-e9dd-95aa-46d8c8d06da5@pi.nu> From: Huub van Helvoort Message-ID: Date: Thu, 11 Apr 2019 12:51:08 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rmr-multicast X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 10:51:14 -0000
Hello Jeffrey,

Please see [hvh-2] below.

Huub,

 

Please see zzh2> below. 


Juniper Internal

From: Huub van Helvoort <huubatwork@gmail.com>
Sent: Monday, April 8, 2019 4:08 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; mpls@ietf.org
Cc: draft-zzhang-mpls-rmr-multicast@ietf.org; mpls-chairs@ietf.org
Subject: Re: MPLS-RT review of draft-zzhang-mpls-rmr-multicast

 

Hello Jeffrey,

 

Please see my response in-line [hvh].

 

Hi Huub,

 

Thank you for your review and comments. Please see zzh> below.

 

 

Non-Juniper

From: Huub van Helvoort <huubatwork@gmail.com>
Sent: Monday, April 8, 2019 5:58 AM
To: mpls@ietf.org
Cc: draft-zzhang-mpls-rmr-multicast@ietf.org; mpls-chairs@ietf.org
Subject: MPLS-RT review of draft-zzhang-mpls-rmr-multicast

 

All,

 

I’ve been selected as an MPLS-RT reviewer for draft-zzhang-mpls-rmr-multicast,
which is currently a candidate for MPLS WG adoption.

 

In the abstract is stated:

   With Resilient MPLS Rings (RMR), although all existing multicast
   procedures and solutions can work as is, there are optimizations that
   could be done for RSVP-TE P2MP tunnel signaling and Fast-ReRouting
   for both mLDP and RSVP-TE P2MP tunnels.

I have carefully read the draft but I could not find any justification
for the optimisation that could be done.

 

Zzh> By “justification", do you mean “need”? I thought the following text provides that:

 

   For a conventionally signaled RSVP-TE P2MP tunnel, an ingress LSR

   discovers leaves and signals one sub-LSP for each leaf.  Even though

   the forwarding state is merged at each hop (i.e, one incoming label

   mapping to multiple outgoing entries), the control plane maintains

   individual sub-LSP state.  This leads to lots of redundant state on

   routers close to the ingress.

[hvh] "lots of state" - can you be more specific? is the redundancy 10% or 90% ?

Zzh2> Depending on how many leaves you have. With traditional RSVP-TE P2MP, there is one sub-LSP to each leaf. If you have 20 leaves, the saving is 95% (I mean you only need to maintain 5% of state compared to traditional way). If you have 10 leaves, the saving is 90%. I don’t think the draft needs to quantify it.

[hvh-2] the draft should mention it because it may be a reason to apply the
optimization or not.

[hvh-2] if a leave is deleted, added, or changed all leaves will be notified and will
have to process the notification.

Zzh> Or do you mean “why” the optimization COULD be done? The key is that this is a ring, and:

 

   … As the PATH message passes along the ring, the leaves

   send RESV messages, but only one RESV message reaches the tunnel

   ingress.

[hvh] can you explain why only one RESV message reaches the tunnel ingress?

Zzh2> Because only one PATH message is sent, and the RESV state gets merged accordingly along the way.

[hvh-2] the merging requires processing resources.

 Zzh> If you mean “how” it is done, I thought the following describes it:

 

   … With RMR, this can be optimized such

   that only a single LSP is signaled, with all the leaves listed in the

   PATH message.  As the PATH message passes along the ring, the leaves

   send RESV messages, but only one RESV message reaches the tunnel

   ingress.

 

   The ingress LSR may also send PATH messages in both directions, so

   that the tunnel is set up in such a way that minimum delay is

   incurred for traffic to reach all leaves.  Alternatively, the ingress

   may send PATH message only in one direction for best bandwidth

   utilization.  For example, a leaf D is three hops away from the

   ingress A in clockwise direction (A,B,C,D) and four hops away in the

   other direction (A,E,F,G,D), but G is also a leaf so it may be better

   to just send the PATH message in the anticlockwise direction.

 

   Each router establishes forwarding state accordingly.  Transit

   routers switches traffic towards downstream.  A transit router could

   also be a leaf router and in that case it does "drop and continue" -

   sends traffic off the ring and switches traffic downstream.



2.1.  Tunnel Protection and FRR

 

   Each node on a ring signals two counter-rotating MP2P RSVP-TE LSPs to

   itself.  As these LSPs are self-signaled after the discovery of the

   ring, they can be used to protect P2MP LSPs on ring.  So neither mLDP

   nor RSVP-TE has to setup a separate P2P bypass LSPs for link and node

   protection.

[hvh]  This is clear.


I also did not find any indication how this optimisation has to be
deployed. Do all the nodes in the ring, or in the network have to
support this optimisation before it becomes effective.

 

Zzh> The context is RMR – Resilient MPLS Ring. All routers on the ring need to support RMR and the multicast optimization for this to be effective. I can make that clear.

[hvh] OK. Thanks.


 I think these issues have to be documented before this draft can

be adopted as WG draft.

 

Zzh> Besides explicitly stating that all routers on the ring need to support the RSVP-TE P2MP optimization for it to be effective, please advise further how the first issue can be better documented.

[hvh] when you use the word "optimize" I expect an indication of
the effect of the optimization on performance, or used resources.

 

Zzh2> I see. The optimization is on (simpler) procedures and (less) resources. I don’t think we need to quantify it.

[hvh-2] I would like to know why I should deploy this "optimisation",
and maybe others would like to know too.

Zzh2> I will update the draft to point out that all routers on the ring needs to support the optimization – please let me know if that is enough.

Zzh2> Thanks!

Zzh2> Jeffrey

Best regards, Huub.


-- 
================================================================
Always remember that you are unique...just like everyone else...
From nobody Thu Apr 11 09:32:41 2019 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 D97A71204FC; Thu, 11 Apr 2019 09:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnqHt5_wdWLv; Thu, 11 Apr 2019 09:32:36 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B60C1202EF; Thu, 11 Apr 2019 09:32:33 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 44g64v4VtTz2085; Thu, 11 Apr 2019 18:32:31 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 44g64v14RdzDq7T; Thu, 11 Apr 2019 18:32:31 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup (10.114.31.59) by OPEXCAUBM21.corporate.adroot.infra.ftgroup (10.114.13.29) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 11 Apr 2019 18:32:31 +0200 Received: from [10.193.71.81] (10.168.234.6) by OPEXCLILM43.corporate.adroot.infra.ftgroup (10.114.31.59) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 11 Apr 2019 18:32:30 +0200 From: Organization: Orange To: "rtg-ads@ietf.org" CC: "rtg-dir@ietf.org" , , Message-ID: <25527_1555000351_5CAF6C1F_25527_187_1_c344649c-bea5-5d0e-3b76-2bd28be6d226@orange.com> Date: Thu, 11 Apr 2019 18:32:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [10.168.234.6] Archived-At: Subject: [mpls] RtgDir Review: draft-ietf-mpls-ri-rsvp-frr-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 16:32:39 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-ri-rsvp-frr-05 Reviewer: Julien Meuric Review Date: April 10, 2019 Intended Status: Proposed Standard *Summary:* I have some minor concerns about this document that I think should be resolved before publication. *Comments:* The document is well written and self consistent. The clear problem statement and the solution's "spirit" description make the detailed behavior convenient to follow. The main issue is about the use of 2119 language: only 4 MUSTs are used (2 of them being similar), far too many SHOULDs. *Major Issues:* No major issues found. *Minor Issues:* Unless I missed an assumption somewhere, I think that, for a Standards Track document, many of the existing SHOULDs should actually be MUSTs. It is a bit odd to read a document trying to be exhaustive about the possible situations and backward compatibility consideration (nice work!) while only requiring optional behaviors. *Nits:* ------ Global --- - Two nits are repeated along the full document and need to be fixed:   * Most of the time, PATH and RESV messages are fully capitalized while PathErr, PathTear, ResvTear... are not. Replacing them by Path/Resv would bring consistency.   * When it comes to nodes or messages names, many definite/indefinite articles (the/a) are missing. I have spotted some of them but got lazy... ------ Header --- - Was RFC 8370 considered to be added to the updated document list? The specification is clearly about combining RFC 4090 and 8370. - s/Refresh Interval Independent/Refresh-Interval Independent/ ------ Abstract --- - s/LSP related states/LSP-related states/  [x2] - LSP is not expanded on 1st use (only in introduction), it may be worth to expand earlier. - s/fast reroute (FRR)/Fast ReRoute (FRR)/ - s/Refresh-interval/Refresh-Interval/  [for consistency] ------ 1. Introduction --- - s/label switched path (LSP)/Label Switched Path (LSP)/ - s/Standard RSVP/Base RSVP/  [x2] - OLD    eliminate facility backup protection    dependency on refresh timeouts for stale state cleanup including the    cleanup for facility backup protection.   NEW    eliminate facility backup protection    dependency on refresh timeouts for stale state cleanup. ------ 2. Terminology --- - The terms Nhop and NNhop, extensively used, are missing. - Adding "B-SFRR-Ready" may be considered. - The link between "Merge Point" and "MP" is only implicit: MP and PLR deserve to be added as defined terms. - s/Link-protecting/Link-Protecting/ - s/Node-protecting/Node-Protecting/ ------ 3. Problem Description --- - s/Figure 1, consider/Figure 1, let us consider/ - s/Also assume/Also let us assume/ - s/A is the Point of Local Repair (PLR) and C is Node Protecting Merge Point (NP-MP)/A is the PLR and C is the NP-MP/ - s/D is the Link Protecting Merge Point (LP-MP)/D is the LP-MP/ - s/are refreshed has failed/are refreshed, has failed/ - s/send tear down message/send a tear down message/ - s/as a Merge Point/as an MP/ - s/receive PathTear/receive a PathTear/ - Sentences #2 and #3 in the bullet at the top of page 7 seem to duplicate the bullet at the bottom of page 6. This need to be skimmed (I personally prefer the wording of the 2nd bullet over the 1st one, including s/send PathTear/send a PathTear/). ------ 4. Solution Aspects --- - s/send tear down message/send a tear down message/  [x2] ------ 4.1. --- - s/RFC 4090/[RFC4090]/  [x4, excluding section title] ------ 4.2. --- - s/RFC 4090/[RFC4090]/ - OLD       a LP-bypass LSP to Nhop node avoiding only the link that       protected LSP takes to reach Nhop   NEW       an LP-bypass LSP to the Nhop node avoiding only the link that       the protected LSP takes to reach the Nhop. - OLD       a LP-bypass LSP to Nhop node avoiding the link that       protected LSP takes to reach Nhop   NEW       an LP-bypass LSP to the Nhop node avoiding the link that       the protected LSP takes to reach the Nhop. - s/RFC 8370/[RFC8370]/ - OLD      included RRO object carried in RESV message.      If the MP has not included Node-ID sub-object in RESV RRO    NEW      included in the RRO object carried in the Resv message.      If the MP has not included a Node-ID sub-object in the Resv RRO - s/PATH message/Path message/  [x2] - s/in CAPABILITY object/in the CAPABILITY object/  [x2] - OLD     then the PLR SHOULD include B-SFRR-Ready Extended Association object and triggers PATH message   NEW     then [I-D.ietf-mpls-summary-frr-rsvpte] applies: the PLR SHOULD include a B-SFRR-Ready Extended Association object and triggers a Path message - s/PATH message/Path message/ - s/ordering rules object/object ordering rules/ - s/RFC 4090/[RFC4090]/ - s/RFC 8370/[RFC8370]/ - s/sub-object in the RRO object carried in the RESV message/sub-object of the RRO object carried in the Resv message/ - s/included Node-ID sub-object in the RRO object carried in PATH message/included a Node-ID sub-object in the RRO object carried in the Path message/ - s/The node should determine whether the incoming PATH messages contains B-SFRR-Ready/A node receiving Path messages should determine whether they contain a B-SFRR-Ready/ - s/followed by implementations supporting/followed by the implementations supporting/ - s/"Remote" state on MP/"Remote" State on MP/ - OLD     The "remote" state is identical to the protected LSP path state except for the difference in RSVP_HOP object.   NEW     The only difference between the "remote" path state and the LSP path state is in the RSVP_HOP object. - s/in "remote" Path state/in the "remote" path state/ - s/MP.../The MP.../  [x4] - s/Node signaling/The node signaling/ - s/a PATH with/a Path message with/ - s/in PATH RRO/in the Path RRO/ - s/receives PathTear/receives a PathTear message - s/on the Ingress or created from a PATH message from/on the ingress or created by a Path message from/ - s/from PLR/from the PLR/ - s/called "Remote PathTear"/called "Remote" PathTear/ ------ 4.3. --- - s/Immediate node failures/Node failures/ - s/SHOULD send Conditional PathTear/SHOULD send a "Conditional PathTear" downstream/ - s/Node-ID signaling/The Node-ID signaling/ - s/MP receives normal or "Remote" PathTear for PSB/The MP receives a normal or "Remote" PathTear for its PSB/  [x3] - s/MP receives ResvTear RSB/The MP receives a ResvTear for its RSB/  [x3] - s/Remote Node-ID/The remote Node-ID/  [x2] - s/Receiving Conditional PathTear/Receiving a Conditional PathTear/ - s/Figure 1, assume/Figure 1, we assume/ - s/PATH/Path/  [x5] - s/MP receives normal or "Remote" PathTear for PSB/The MP receives a normal or "Remote" PathTear for its PSB/  [x2] - s/MP receives ResvTear RSB/The MP receives a ResvTear for its RSB/  [x2] ------ 4.4. --- - s/Conditional Path Tear/Conditional PathTear/  [x3] - s/Ingress has/The ingress has/ - s/and PathTear is not received/and no PathTear is received/ - Section 4.4.2:   * need "a/the" before most (conditional/normal) PathTears   * s/included B-SFRR-Ready Extended Association/included the B-SFRR-Ready Extended Association/   * s/PATH/a Path message/   * should consider upgrading some SHOULDs into MUST. - s/CONDITIONS object/CONDITIONS Object/ - s/called as "CONDITIONS" object that/called "CONDITIONS" object, that/ - "Length, Class, C-type, M bit" would better be followed  by ":" and drop the trailing carriage return (like the Terminology section). - s/If M-bit is set/If the M bit is set/  [x2] - s/processed based on the condition if the receiver router is a Merge Point or not./processed according to the receiver router role, i.e. if it is an MP or not./ - s/as normal PathTear message./as a normal PathTear message./ - The M bit is newly defined: is there any reason not to specify it using MUSTs? ------ 4.5. --- - s/the Ingress wants/the ingress wants/ - s/in "remote" PathTear message/in the "Remote" PathTear message/ - s/Consider node C in example topology (Figure 1) has/Let us consider that node C, in the example topology (Figure 1), has/ - s/sends normal PathTear/send a normal PathTear/ - s/Assume B/Let us assume that B/ - s/send "remote" PathTear/sends a "Remote" PathTear/ - s/deletes PSB and RSB states/deletes the PSB and RSB states/ - s/the remote PathTear and delete PSB and RSB states/the "Remote" PathTear and delete the PSB and RSB states/ - s/a router that/a PLR that/ - s/in RESV message, and if the RRO change indicates that/in the Resv message indicating that/ - s/send "Remote" PathTear/send a "Remote" PathTear/ - s/assume/let us assume/ - s/NP-MP for A/NP-MP for PLR A/ - s/trigger RESV/trigger a Resv/ - s/in RESV/in the Resv/ - s/the RESV with/the Resv with/ - s/send "Remote" PathTear/send a "Remote" PathTear/ - s/send normal PathTear/send a normal PathTear/ - s/both PSB and RSB states corresponding/both the PSB and the RSB states corresponding/ - s/Phop Link failure/Phop Link Failure/ - s/send normal PathTear and delete both PSB and RSB states corresponding/send a normal PathTear and delete both the PSB and the RSB states corresponding/ - s/send normal PathTear and delete PSB and RSB states corresponding/send a normal PathTear and delete the PSB and RSB states corresponding/ - s/Consider B-C/Let us consider that B-C/ - s/send PathErr or ResvTear/send a PathErr nor a ResvTear/ - s/because backup LSP/because the backup LSP/ - s/send normal PathTear/send a normal PathTear/ - s/on receiving PathTear/when receiving a PathTear/ - s/reject backup LSP PATH and send PathErr/reject the backup LSP Path and send a PathErr/ ------ 4.6. --- - s/have been proposed in/have been defined in/ - s/and remote PathTear/and "Remote" PathTear/ - s/should support/need to support/  [unless moving to 2119 language] - s/in CAPABILITY object/in the CAPABILITY object/ - s/initiate remote Node-ID/initiate a remote Node-ID/ - s/with NNhop/with its NNhop/ - s/set RI-RSVP flag in CAPABILITY object/set the RI-RSVP flag in the CAPABILITY object/ - s/that NNhop/that the NNhop/ - s/PPhop/the PPhop/  [x3] - s/in PATH/in its Path messages/ - s/set RI-RSVP flag in CAPABILITY object/set the RI-RSVP flag in the CAPABILITY object/ - s/for backward compatibility/for Backward Compatibility/ - s/in TIME_VALUES object carried in PATH to default short refresh default value/in the TIME_VALUES object carried in the Path message to a default short refresh value/ - s/in TIME_VALUES object carried in PATH to a short refresh default value/in the TIME_VALUES object carried in the Path message to a default short refresh value/ - s/send remote PathTear or/send any "Remote" PathTear nor/ - s/trigger PATH/trigger a Path message./ - s/send Conditional PathTear/send a Conditional PathTear/ - s/in TIME_VALUES object carried in RESV to default short refresh default value/in the TIME_VALUES object carried in the Resv message to a default short refresh value/ - s/in TIME_VALUES object carried in PATH to default value/in the TIME_VALUES object carried in the *Resv* message to a default value/ - s/and PPhop node/and the PPhop node/ - s/in TIME_VALUES object carried in RESV to default value/in the TIME_VALUES object carried in the Resv message to a default value/ - To be consistent with 4.6.2.1, the last paragraph of section 4.6.2.2. should NOT start with a bullet. ------ Cheers, Julien _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Thu Apr 11 12:59:54 2019 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 E3B821201D2; Thu, 11 Apr 2019 12:59:52 -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 ToptP9XUsR6R; Thu, 11 Apr 2019 12:59:50 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 63FA712015A; Thu, 11 Apr 2019 12:59:50 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id s81so4259557qke.13; Thu, 11 Apr 2019 12:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=mi7qIoJhkyMcGvfRFVkPHvkhxo4ZdAuTUD7noQpGXyU=; b=VYw3azlSczbW7dt1+RpQH2PU3FtrBmdZwzg1/SEHBFnjSaL6QZVxCI8Tjk+ICVUNgc 7SHQaqg2s3/CLQxhugP/19rDmMhimxxUa+d+moCzBq6co+KNvlla75O2ILKDLjZ3eStG EU56VQEVwYUL16AoYNaIq7ZHDhdTnDvLw/th2M/q3fAGtT9zCBmQCXFnzQ2zikfhYntu BnBl79w1Q9IwlGMtzh/GO9bhCuHpgVQ+rcK6OYDh73mdGtGZUIzM6CUWm+I228roZddS Vv+sMbDrjyW/z7xXGTp7rYuPOlB/1NJSE0Png14pxlznXTej7DhJ4udd2RnCxJiuoz5D R3qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=mi7qIoJhkyMcGvfRFVkPHvkhxo4ZdAuTUD7noQpGXyU=; b=HtPZtgL2nuY9ctIy0lAa/3EzWZlneR+35En14jiz7rjI2pHpr2sRwuiY22KHjH7jN/ 8PZhOPTsdjzcMjZSEUNEZCXTecq2wXnzhz4Woqa0Zyo8EzEHqltx1Gc/SzRFcicz6px+ 3riK0MrrORwW20LNkrGpAjTz70Q1CyEvm9+GjPRiZ5bXSmqvt9vHDwh0PnMEXnAj4Idg 9v0PVd+KvLlhttVTQzfd87QqGxtIoHQI1zTpoVyFDh3brGZN3TcmVtjxcKD2Ba4E3uLi LwfNkXDkpIihvH/fV9wpGYy3aUlNxVrkh953IdlJxXOtf1nezN0tFbkIks9/8g/svj4s FnoQ== X-Gm-Message-State: APjAAAWBK9vgot1w5ONKG00JLQz/WdCF2TDHigdmcJIr1Hbe8GVaLA5A Bo3uX9J+4qgIRhC07nE8woQ= X-Google-Smtp-Source: APXvYqx50I8E0qV7N6j4irtYhMEwnbiyJ28wrJ0tNbmSCdnswCU+4KCPlQT16sWlXJB+N8pYHQCbAw== X-Received: by 2002:a37:9186:: with SMTP id t128mr39268285qkd.326.1555012789231; Thu, 11 Apr 2019 12:59:49 -0700 (PDT) Received: from BN8PR06MB6289.namprd06.prod.outlook.com ([52.96.29.13]) by smtp.gmail.com with ESMTPSA id v8sm25519201qtc.69.2019.04.11.12.59.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 12:59:48 -0700 (PDT) From: Tarek Saad To: "Jeffrey (Zhaohui) Zhang" , "draft-zzhang-mpls-rmr-multicast@ietf.org" CC: "mpls-chairs@ietf.org" , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-zzhang-mpls-rmr-multicast Thread-Index: ATVjYWU3vXyEqIW2kXE8E4lNxAjcHTA3QUM2MEQyMDK8FqPUug== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Thu, 11 Apr 2019 19:59:48 +0000 Message-ID: References: <0df832d7-8389-e9dd-95aa-46d8c8d06da5@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rmr-multicast X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 19:59:53 -0000 SGV5IEplZmZyZXksDQoNClNlZSBpbmxpbmUuLg0KDQrvu79PbiA0LzEwLzE5LCA5OjEzIFBNLCAi SmVmZnJleSAoWmhhb2h1aSkgWmhhbmciIDx6emhhbmdAanVuaXBlci5uZXQ+IHdyb3RlOg0KDQog ICAgSGkgVGFyZWssDQogICAgDQogICAgVGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgY29tbWVu dHMuIFBsZWFzZSBzZWUgbXkgcmVzcG9uc2VzIGJlbG93Lg0KICAgIA0KICAgICAgICA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgPiBGcm9tOiBUYXJlayBTYWFkIDx0c2FhZC5uZXRA Z21haWwuY29tPg0KICAgID4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMCwgMjAxOSAzOjI0IFBN DQogICAgPiBUbzogZHJhZnQtenpoYW5nLW1wbHMtcm1yLW11bHRpY2FzdEBpZXRmLm9yZw0KICAg ID4gQ2M6IG1wbHMtY2hhaXJzQGlldGYub3JnOyBtcGxzQGlldGYub3JnDQogICAgPiBTdWJqZWN0 OiBSZTogTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQtenpoYW5nLW1wbHMtcm1yLW11bHRpY2FzdA0K ICAgID4gDQogICAgPiBIaSBhbGwsDQogICAgPiANCiAgICA+IEnigJl2ZSBiZWVuIHNlbGVjdGVk IGFzIGFuIE1QTFMtUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQgdGhhdCBpcyB1bmRlcmdvaW5n DQogICAgPiBXRyBhZG9wdGlvbi4NCiAgICA+IEJlbG93IGFyZSBteSBjb21tZW50cy4NCiAgICA+ IA0KICAgID4gVGhlIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIGRlc2NyaWJlIGhpZ2gtbGV2ZWwg cmVxdWlyZW1lbnRzIGZvciBtdWx0aWNhc3QNCiAgICA+IG92ZXIgUk1SIHJpbmdzIGFuZCBkb2N1 bWVudCBjb3ZlcnMgc3BlY2lmaWNzIHRoYXQgYXJlIG5vdCBkZXBlbmRlbnQgb24NCiAgICA+IHRo ZSBzaWduYWxpbmcgcHJvdG9jb2wgdXNlZCB0byBzZXR1cCB0aGUgTS9QMk1QIExTUCByaW5ncy4N CiAgICANCiAgICBJdCBkb2VzIG5vdCBkZXNjcmliZSByZXF1aXJlbWVudHMuIFJhdGhlciwgaXQg cG9pbnRzIG91dCB0aGF0IG11bHRpY2FzdCBjYW4gd29yayBhcyBpcywgb3IgY2FuIGJlIG9wdGlt aXplZC4NCiAgICANCiAgICA+IC0gSSBzdGlsbCBmb3VuZCwgaG93ZXZlciwgaW5zdGFuY2VzIHdo ZXJlIGl0J3MgdHJ5aW5nIHRvIGRlc2NyaWJlIHByb3RvY29sDQogICAgPiBzcGVjaWZpYyBzaWdu YWxpbmcgZGV0YWlscw0KICAgID4gLSBJTU8sIHRoaXMgc2hvdWxkIGJlIGRlZmVycmVkIHRvIHRo ZSBvdGhlciBSTVIgcHJvdG9jb2wgc3BlY2lmaWMgZG9jdW1lbnRzLg0KICAgIA0KICAgIFNlY29u ZCAyIGRlc2NyaWJlcyBhdCBhIGhpZ2ggbGV2ZWwgaG93IFJTVlAtVEUgUDJNUCB0dW5uZWwgY2Fu IGJlIG9wdGltaXplZCB3aXRoIFJNUiwgYnV0IGRvZXMgcmVmZXIgdG8gW0ktRC56emhhbmctdGVh cy1ybXItcnN2cC1wMm1wXS4gSSBjb3VsZCByZW1vdmUgdGhlIG1ham9yaXR5IG9mIHRoZSB0ZXh0 IGluIHNlY3Rpb24gYW5kIHNpbXBseSBwb2ludCBvdXQgdGhhdCBpdCBjb3VsZCBiZSBvcHRpbWl6 ZWQuDQpbVFNdOiBPSywgYnV0IHdvdWxkIHRoaW5rIHlvdSB3YW50IHRvIGRlZmluZSB0aG9zZSBp biB0aGUgb3RoZXIgZHJhZnQuLiBvdGhlcndpc2UsIGl0J3MgaGFyZCB0byBrZWVwIHRoZSBjb250 ZW50IGluIHN5bmMgaW4gMiBzZXBhcmF0ZSBkb2N1bWVudHMuDQogICAgDQogICAgPiAtIElkZWFs bHksIHNob3VsZCBjb25zaWRlciBpbmNvcnBvcmF0aW5nIHRoaXMgZG9jdW1lbnQgYXMgYSBzZWN0 aW9uIGludG8gdGhlDQogICAgPiBtYWluIFJNUiBoaWdoLWxldmVsIGRvY3VtZW50IElEOiBkcmFm dC1pZXRmLW1wbHMtcm1yLiBXYXMgdGhpcyBjb25zaWRlcmVkPw0KICAgIA0KICAgIExpa2UgaW4g bWFueSBvdGhlciBjYXNlcywgYSB0ZWNobm9sb2d5IG1heSBiZSBmaXJzdCBzcGVjaWZpZWQgb25s eSBmb3IgdW5pY2FzdCBpbml0aWFsbHkgYW5kIHRoZW4gYWRkIG11bHRpY2FzdC4gSW4gdGhpcyBj YXNlLCB3ZSBkb24ndCB3YW50IHRvIGRlbGF5IHRoZSB1bmljYXN0IHBpZWNlLg0KW1RTXTogT0ss IGJ1dCBnaXZlbiBub3QgaW50cm9kdWNpbmcgYW55IG5ldyByZXF0cyBhbmQgdGhhdCBzaWduYWxp bmcgb3B0aW1pemF0aW9ucyAoaWYgYW55KSBhcmUgZGVmZXJyZWQgdG8gb3RoZXIgZG9jdW1lbnRz LCBzdGlsbCBjb25jZXJuZWQ/IEknbGwgbGVhdmUgaXQgdXAgdG8geW91L1dHLg0KICAgIA0KICAg ID4gDQogICAgPiA+PiAgIFRoaXMgbGVhZHMgdG8gbG90cyBvZiByZWR1bmRhbnQgc3RhdGUgb24g cm91dGVycyBjbG9zZSB0byB0aGUgaW5ncmVzcy4NCiAgICA+ID4+ICAgV2l0aCBSTVIsIHRoaXMg Y2FuIGJlIG9wdGltaXplZCBzdWNoDQogICAgPiA+PiAgIHRoYXQgb25seSBhIHNpbmdsZSBMU1Ag aXMgc2lnbmFsZWQsIHdpdGggYWxsIHRoZSBsZWF2ZXMgbGlzdGVkIGluIHRoZSBQQVRIDQogICAg PiBtZXNzYWdlLg0KICAgID4gW1RTXTogSSB0aGluayBhIHNpbmdsZSBzdWItTFNQIHN0YXRlIHN0 aWxsIG5lZWRzIHRvIGJlIG1haW50YWluZWQsIHJlZ2FyZGxlc3MgaWYNCiAgICA+IHRoZXkgYXJl IHNpZ25hbGVkIGluIGEgc2luZ2xlIG9yIG11bHRpcGxlIFBBVEggbWVzc2FnZXMuIFRoaXMgaXMg bmVlZGVkIHNvIGENCiAgICA+IGxlYWYgY2FuIGdyYWZ0ZWQgb3IgcHJ1bmVkIHdpdGhvdXQgYWZm ZWN0aW5nIGV4aXN0aW5nIGxlYWZzLg0KICAgIA0KICAgIERvIHlvdSBtZWFuIGEgInNlcGFyYXRl IHN1Yi1MU1Agc3RhdGUgc3RpbGwgbmVlZCB0byBiZSBtYWludGFpbmVkIGZvciBlYWNoIGxlYWYi Pw0KICAgIEkgZG9uJ3QgdGhpbmsgdGhhdCdzIG5lZWRlZCB0byBncmFmdC9wcnVuZSBhIGxlYWYg LSBqdXN0IGNvbXBhcmUgdG8gaG93IG1MRFAgd29ya3MuDQoNCltUU106IGNsYXNzaWMgUDJNUCBS U1ZQLVRFIExTUHMgYXJlIGluZ3Jlc3MgZHJpdmVuLi4gdGhlIHByb3Zpc2lvbmluZy9ncmFmdC9w cnVuZSBpcyBkcml2ZW4gYnkgdGhlIGluZ3Jlc3MgTEVSIChwb3NzaWJseSB0cmlnZ2VyZWQgYnkg b3ZlcmxheSBhdXRvLWRpc2NvdmVyeSByb3V0ZSBsZWFybnQgYXQgaW5ncmVzcykuIEkgYW0gbm90 IGNsZWFyLCBpbiB0aGUgY2FzZSwgaG93IGluZ3Jlc3MgY2FuIHRyaWdnZXIgdGhlIGdyYWZ0L3By dW5lIG9wZXJhdGlvbiBvbiBhIHNpbmdsZSBzdWItTFNQIHdpdGhvdXQgaW1wYWN0aW5nIHRoZSBv dGhlcnMuDQoNCiAgICA+IE5vdGUsIFJGQzQ4NzUgYWxyZWFkeSBhbGxvd3MgZm9yIHNpZ25hbGlu ZyBtdWx0aXBsZSBzdWItTFNQKHMpIGluIGEgc2luZ2xlDQogICAgPiBQQVRIIG1lc3NhZ2UgKHNl ZSByZmM0ODc1IHNlY3Rpb24gNS4yLjIpIC0gc28gbm90IGNsZWFyIG9mIHRoZSBuZXcNCiAgICA+ IG9wdGltaXphdGlvbnMgbWVudGlvbmVkIGhlcmUuDQogICAgDQogICAgVGhlIG9wdGltaXphdGlv biBoZXJlIGlzIHRoYXQgb25seSBhIHNpbmdsZSBzdWItTFNQIGlzIG5lZWRlZC4NCltUU106IHN0 aWxsIGxpdHRsZSBjb25mdXNlZC4gQW4gUzJMX1NVQl9MU1Agb2JqZWN0IGlkZW50aWZpZXMgYSBw YXJ0aWN1bGFyIFMyTCBzdWItTFNQLiAgVGhlICBTMkxfU1VCX0xTUCBvYmplY3QgaGFzIGEgc2lu Z2xlIGRlc3RpbmF0aW9uIGFkZHJlc3MgKHRoZSBsZWFmKS4uIEFyZSB5b3UgcHJvcG9zaW5nIGNv bmZpZ3VyaW5nIGFueWNhc3QgYWRkcmVzcyAocGVyIHAybXAtdGUgdHJlZSkgaW4gUzJMX1NVQl9M U1AgdG8gaWRlbnRpZnkgYWxsIHRoZSBub2RlcyBvZiBhIHJpbmc/IFBsZWFzZSBjbGFyaWZ5Lg0K DQogICAgPiANCiAgICA+IFNlY3Rpb24gMjoNCiAgICA+ID4+IGluZ3Jlc3MgQSBpbiBjbG9ja3dp c2UgZGlyZWN0aW9uIChBLEIsQyxEKSBhbmQgZm91ciBob3BzIGF3YXkgaW4gdGhlLi4uLg0KICAg ID4gSSBjb3VsZCBub3QgZmluZCB0aGUgZmlndXJlIHRoYXQgc2hvd3MgdGhvc2Ugbm9kZXM/IElN TywgdGhpcyBoaWdoLWxldmVsDQogICAgPiBkZXNjcmlwdGlvbiBjYW4gcmVmcmFpbiBmcm9tIGRl c2NyaWJpbmcgc2lnbmFsaW5nIHByb3RvY29sIHNwZWNpZmljIGRldGFpbHMuDQogICAgDQogICAg SSBkaWQgbm90IGluY2x1ZGUgYSBmaWd1cmUsIHRoaW5raW5nIHRoYXQgdGhlIChBLEIsQyxEKSBj bG9ja3dpc2UgYW5kIChBLEUsRixHLEQpICBhbnRpY2xvY2t3aXNlIHRleHQgd291bGQgYmUgY2xl YXIgZW5vdWdoLiBJIGNhbiBlaXRoZXIgYWRkIGEgZmlndXJlIG9yIHJlbW92ZSBtb3N0IG9mIHRo ZSB0ZXh0IGFzIG1lbnRpb25lZCBlYXJsaWVyLg0KW1RTXTogc3RpbGwgaGVscGZ1bCB0byBiZSB0 aGVyZS4NCiAgICANCiAgICA+IA0KICAgID4gPj4gICBUaGUgUEFUSCBtZXNzYWdlIGRvZXMgbm90 IG5lZWQgdG8gbGlzdCBhbGwgbGVhdmVzLiAgQXMgbG9uZyBhcyBhIGxlYWYNCiAgICA+IHNvbWVo b3cgZGV0ZXJtaW5lcyB0aGF0IGl0IGlzIGEgbGVhZiwgaXQgY2FuIHNlbmQgUkVTViBtZXNzYWdl IHdoZW4gaXQNCiAgICA+IHJlY2VpdmVzIHRoZSBQQVRIIG1lc3NhZ2UuDQogICAgPiBbVFNdOiBX aXRoIFJTVlAtVEUsIGEgUDJNUCBub2RlIGRpc2NvdmVycyBpdOKAmXMgYSBsZWFmIHVwb24gcHJv Y2Vzc2luZyB0aGUNCiAgICA+IFBBVEggdGhhdCBjb250YWlucyBhIFMyTF9TVUJfTFNQIHdpdGgg YSBtYXRjaGluZyBsb2NhbCBhZGRyZXNzLiBTaW5jZSB0aGUNCiAgICA+IFBBVEggbWVzc2FnZSBp cyByZWFjaGluZyB0aGUgbm9kZSwgbm90IGNsZWFyIG9uIHdoYXQgaXMgb3B0aW1pemF0aW9uIGlu IHRoaXMNCiAgICA+IGNhc2UuDQogICAgPiANCiAgICANCiAgICBUaGluayBob3cgbUxEUCB3b3Jr cy4gTGFiZWwgbWFwcGluZyBpcyBzZW50IGZyb20gYSBsZWFmIHRvd2FyZHMgdGhlIHJvb3QgYW5k IGEgbGVhZiBrbm93cyBpdCdzIGxlYWYgYnkgb3RoZXIgbWVhbnMgKG5vdCB0aHJvdWdoIG1MRFAg bWVjaGFuaXNtcykuIFdhbnQgdG8gYXBwbHkgdGhlIHNhbWUgaGVyZSBhcyBhbiBvcHRpb24uDQpb VFNdOiBZZXMsIGJ1dCBvbmUga2V5IGRpZmZlcmVuY2UgYmV0d2VlbiBtTERQIGFuZCBSU1ZQLVRF IGlzIHRoYXQgdGhlIGxhdHRlciBpcyBpbmdyZXNzIGRyaXZlbiB3aGlsZSB0aGUgZm9ybWVyIGlz IHByZWZpeCAoZS5nIFMsRykgZHJpdmVuLi4gRm9yIGNsYXNzaWMgUDJNUCBSU1ZQLVRFLCB0aGUg Z3JhZnQvcHJ1bmUgaXMgY29udHJvbGxlZCBieSBpbmdyZXNzLiBJZiB5b3UncmUgcGxhbm5pbmcg dG8gY2hhbmdlIHRoaXMsIEkgdGhpbmsgaXQgd291bGQgYmUgd29ydGggbW9yZSBoaWdobGlnaHRp bmcvY2xhcmlmeWluZy4NCiAgICANCiAgICA+ID4+IE9uY2UgdGhlIHRyYWZmaWMgaXMgb3V0IG9m IHRoZSByaW5nICBMU1Agb24gUjMsDQogICAgPiBbVFNdOiBJIHRoaW5rIGNsZWFyZXIgYXMgIk9u Y2UgdHJhZmZpYyBpcyBvdXQgb2YgdGhlIENXIExTUCB0byBSMyIuIA0KICAgIA0KICAgIExldCBt ZSBxdW90ZSB0aGUgc3Vycm91bmRpbmcgdGV4dCBoZXJlOg0KICAgIA0KICAgICAgIEluIHRoZSBl dmVudCBvZiBhIGxpbmsgZmFpbHVyZSBiZXR3ZWVuIFIyIGFuZCBSMywgUjIgdGhlIFBvaW50IG9m DQogICAgICAgTG9jYWwgUmVwYWlyIChQTFIpIHR1bm5lbHMgUDJNUCBMU1AgdHJhZmZpYyBvbiBh IGFudGktY2xvY2t3aXNlIHJpbmcNCiAgICAgICBMU1AgdG8gUjMgdGhlIE1lcmdlIFBvaW50IChN UCkuICBPbmNlIHRoZSB0cmFmZmljIGlzIG91dCBvZiB0aGUgcmluZw0KICAgICAgIExTUCBvbiBS MywgaXQgdXNlcyB0aGUgcmVndWxhciBQMk1QIExTUCB0byByZWFjaCBSNC4gIFNpbWlsYXJseSBp bg0KICAgICAgIHRoZSBldmVudCBvZiBhIG5vZGUgZmFpbHVyZSBSMywgUjIgdGhlIFBMUiB0dW5u ZWxzIFAyTVAgTFNQIHRyYWZmaWMNCiAgICAgICB0byBSNCAodGhlIE1QKSwgd2hpY2ggaXMgYWxz byB0aGUgbGVhZi4NCiAgICANCiAgICBUaGUgcmluZyBMU1AgdG8gUjMgdXNlZCB0byB0dW5uZWwg dHJhZmZpYyB3aGVuIFIyLT5SMyBsaW5rIGJyZWFrcyBpcyBhbnRpLWNsb2Nrd2lzZSBub3QgY2xv Y2t3aXNlIChDVykuDQpbVFNdOiBNeSBiYWQsIEkgcmVhZCAiQ1ciIGFzIGNvdW50ZXIgY2xvY2st d2lzZSBfXyAtLSB3aGlsZSB5b3UgcHJvYmFibHkgcmVmZXIgdG8gaXQgYXMgQUMgKGFudGktY2xv Y2t3aXNlKS4gSW4gZWl0aGVyIGNhc2UsIGl0J3MgZ29vZCB0byByZWZlciB0byBpdCBleHBsaWNp dGx5IGFzIHRoZSBBQyBMU1AgdG8gUjMuDQogICAgDQogICAgPiBBbHNvLCBpdCBpcw0KICAgID4g dW5jbGVhciBpZi9ob3cgUExSKDIpIGNhbiBkaXN0aW5ndWlzaCB3aGV0aGVyIHRvIHR1bm5lbCB0 cmFmZmljIG92ZXIgQ1cgTFNQDQogICAgPiB0byBub2RlIFIzIG9yIHRvIG5vZGUgUjQgLSBpLmUu IGNhc2Ugb2YgUjMgbm9kZSBmYWlsdXJlPw0KICAgIA0KICAgIEEgbm9kZSBuZWVkcyB0byBiZSBh YmxlIHRvIGRldGVybWluZSBpZiBhIGZhaWx1cmUgaXMgYSBsaW5rIGZhaWx1cmUgb3Igbm9kZSBm YWlsdXJlLiBPbmNlIGl0IGtub3dzLCBpdCBrbm93cyBob3cgdG8gdHVubmVsLg0KW1RTXTogeWVz LCBjYW4gaW1hZ2luZSBpdCdzIG5vdCBxdWl0ZSBzdHJhaWdodCBmb3J3YXJkIHRvIGRvIHNvLi4N Cg0KICAgID4gPj4gU2VjdGlvbiAzOiBFbmQgdG8gRW5kIFR1bm5lbHMgd2l0aCBSaW5ncw0KICAg ID4gW1RTXTogZG8geW91IG1lYW4gZnVsbCBtZXNoIG9mIHR1bm5lbHMgYmV0d2VlbiBQRXM/IFRo ZSBzdW1tYXJ5IEkgY2FuDQogICAgPiBkcmF3IGZyb20gdGhpcyBzbWFsbCBzZWN0aW9uIGlzIHRo YXQgUk1SIChhcyBhbm90aGVyIGZvcm0gb2YgUC10dW5uZWxzKSBpcyBub3QNCiAgICA+IGludHJv ZHVjaW5nIGFueSBuZXcgcmVxdWlyZW1lbnRzLCByaWdodD8NCiAgICANCiAgICBJIG1lYW50IHRo YXQgYW4gZW5kIHRvIGVuZCB0dW5uZWwgY2FuIGdvIHRocm91Z2ggYW4gYXJiaXRyYXJ5IHRvcG9s b2d5LCBwYXJ0IG9mIHdoaWNoIGlzIGEgcmluZyBvciBtdWx0aXBsZSByaW5ncy4NCiAgICBSTVIg aXMgbm90IGEgZm9ybSBvZiB0dW5uZWwuIEl0J3MgYSBzcGVjaWFsIChzdWItKXRvcG9sb2d5Lg0K ICAgIFJNUiBkb2VzIG5vdCBpbnRyb2R1Y2UgYW55IG5ldyByZXF1aXJlbWVudHMsIHRob3VnaCB5 b3UgY291bGQgb3B0aW1pemUgUlNWUC1URSBQMk1QIHR1bm5lbCBvdmVyIFJNUiwgYW5kIG9wdGlt aXplIHR1bm5lbCBwcm90ZWN0aW9uIGZvciBib3RoIFJTVlAtVEUgYW5kIG1MRFAgUDJNUCB0dW5u ZWxzLg0KW1RTXTogZ29vZCB0byBrbm93LiBJIHN0aWxsIGJlbGlldmUgaWYgeW91J3JlIGdvaW5n IHRvIHRhbGsgYWJvdXQgKGUuZy4pIFJTVlAtVEUgb3B0aW1pemFydGlvbnMsIHlvdSdyZSBiZXR0 ZXIgb2ZmIGRvaW5nIHNvIGluIHRoZSBSU1ZQLVRFIFJNUiBkcmFmdC4gSSdkIGV4cGVjdCBSTVIg dG9wb2xvZ3kgY29uc2lkZXJhdGlvbnMgb24gdG8gUDJNUCBvciBNUDJNUCBMU1AocykgdG8gYmUg ZGlzY3Vzc2VkIGhlcmUuDQoNClJlZ2FyZHMsDQpUYXJlaw0KICAgIA0KICAgIEplZmZyZXkNCiAg ICA+IA0KICAgID4gUmVnYXJkcywNCiAgICA+IFRhcmVrDQogICAgPiANCiAgICA+IA0KICAgID4g 77u/T24gMy8yOC8xOSwgNToxOSBBTSwgIkxvYSBBbmRlcnNzb24iIDxsb2FAcGkubnU+IHdyb3Rl Og0KICAgID4gDQogICAgPiAgICAgVGFyZWssIEFuZHksIEh1dWIgYW5kIFJhaml2LA0KICAgID4g DQogICAgPiAgICAgWW91IGhhdmUgYmUgc2VsZWN0ZWQgYXMgTVBMUy1SVCByZXZpZXdlcnMgZm9y DQogICAgPiAgICAgZHJhZnQtenpoYW5nLW1wbHMtcm1yLW11bHRpY2FzdC0wMi4NCiAgICA+IA0K ICAgID4gICAgIE5vdGUgdG8gYXV0aG9yczogWW91IGhhdmUgYmVlbiBDQydkIG9uIHRoaXMgZW1h aWwgc28gdGhhdCB5b3UgY2FuIGtub3cNCiAgICA+ICAgICB0aGF0IHRoaXMgcmV2aWV3IGlzIGdv aW5nIG9uLiBIb3dldmVyLCBwbGVhc2UgZG8gbm90IHJldmlldyB5b3VyIG93bg0KICAgID4gICAg IGRvY3VtZW50Lg0KICAgID4gDQogICAgPiAgICAgUmV2aWV3cyBzaG91bGQgY29tbWVudCBvbiB3 aGV0aGVyIHRoZSBkb2N1bWVudCBpcyBjb2hlcmVudCwgaXMgaXQNCiAgICA+ICAgICB1c2VmdWwg KGllLCBpcyBpdCBsaWtlbHkgdG8gYmUgYWN0dWFsbHkgdXNlZnVsIGluIG9wZXJhdGlvbmFsDQog ICAgPiAgICAgbmV0d29ya3MpLCBhbmQgaXMgdGhlIGRvY3VtZW50IHRlY2huaWNhbGx5IHNvdW5k PyAgV2UgYXJlIGludGVyZXN0ZWQNCiAgICA+ICAgICBpbiBrbm93aW5nIHdoZXRoZXIgdGhlIGRv Y3VtZW50IGlzIHJlYWR5IHRvIGJlIGNvbnNpZGVyZWQgZm9yIFdHDQogICAgPiAgICAgYWRvcHRp b24gKGllLCBpdCBkb2Vzbid0IGhhdmUgdG8gYmUgcGVyZmVjdCBhdCB0aGlzIHBvaW50LCBidXQg c2hvdWxkIGJlDQogICAgPiAgICAgYSBnb29kIHN0YXJ0KS4NCiAgICA+IA0KICAgID4gICAgIFJl dmlld3Mgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIGRvY3VtZW50IGF1dGhvcnMsIFdHIGNvLWNoYWly cyBhbmQNCiAgICA+ICAgICBXRyBzZWNyZXRhcnksIGFuZCBDQydkIHRvIHRoZSBNUExTIFdHIGVt YWlsIGxpc3QuIElmIG5lY2Vzc2FyeSwgY29tbWVudHMNCiAgICA+ICAgICBtYXkgYmUgc2VudCBw cml2YXRlbHkgdG8gb25seSB0aGUgV0cgY2hhaXJzLg0KICAgID4gDQogICAgPiAgICAgSWYgeW91 IGhhdmUgdGVjaG5pY2FsIGNvbW1lbnRzIHlvdSBzaG91bGQgdHJ5IHRvIGJlIGV4cGxpY2l0IGFi b3V0IHdoYXQNCiAgICA+ICAgICAqcmVhbGx5KiBuZWVkIHRvIGJlIHJlc29sdmVkIGJlZm9yZSBh ZG9wdGluZyBpdCBhcyBhIHdvcmtpbmcgZ3JvdXANCiAgICA+ICAgICBkb2N1bWVudCwgYW5kIHdo YXQgY2FuIHdhaXQgdW50aWwgdGhlIGRvY3VtZW50IGlzIGEgd29ya2luZyBncm91cA0KICAgID4g ICAgIGRvY3VtZW50IGFuZCB0aGUgd29ya2luZyBncm91cCBoYXMgdGhlIHJldmlzaW9uIGNvbnRy b2wuDQogICAgPiANCiAgICA+ICAgICBBcmUgeW91IGFibGUgdG8gcmV2aWV3IHRoaXMgZHJhZnQg YnkgQXByaWwgMTIsIDIwMTk/IFBsZWFzZSByZXNwb25kIGluIGENCiAgICA+ICAgICB0aW1lbHkg ZmFzaGlvbi4NCiAgICA+IA0KICAgID4gDQogICAgPiAgICAgVGhhbmtzLCBMb2ENCiAgICA+ICAg ICAoYXMgTVBMUyBXRyBjaGFpcikNCiAgICA+ICAgICAtLQ0KICAgID4gDQogICAgPiANCiAgICA+ ICAgICBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBwaS5u dQ0KICAgID4gICAgIFNlbmlvciBNUExTIEV4cGVydA0KICAgID4gICAgIEJyb256ZSBEcmFnb24g Q29uc3VsdGluZyAgICAgICAgICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KICAgID4gDQog ICAgDQo= From nobody Fri Apr 12 05:01:09 2019 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 7AA6D1202AC for ; Fri, 12 Apr 2019 05:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WymqUnR3bGGs for ; Fri, 12 Apr 2019 05:01:06 -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 000B91201AF for ; Fri, 12 Apr 2019 05:01:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 64089B808B3; Fri, 12 Apr 2019 05:01:00 -0700 (PDT) To: rajiva@cisco.com, cpignata@cisco.com, skraza@cisco.com, vishwas@ionosnetworks.com, rajiv.papneja@huawei.com, db3546@att.com, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, loa@pi.nu, n.leymann@telekom.de X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ramakrishnadtv@gmail.com, mpls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190412120100.64089B808B3@rfc-editor.org> Date: Fri, 12 Apr 2019 05:01:00 -0700 (PDT) Archived-At: Subject: [mpls] [Editorial Errata Reported] RFC7552 (5690) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 12:01:08 -0000 The following errata report has been submitted for RFC7552, "Updates to LDP for IPv6". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5690 -------------------------------------- Type: Editorial Reported by: Ramakrishna Rao DTV Section: 6.1.1 Original Text ------------- Dual-Stack capability: TLV code point (Ox0701) Corrected Text -------------- Dual-Stack capability: TLV code point (0x0701) Notes ----- Instead of "0", "O" is used. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7552 (draft-ietf-mpls-ldp-ipv6-17) -------------------------------------- Title : Updates to LDP for IPv6 Publication Date : June 2015 Author(s) : R. Asati, C. Pignataro, K. Raza, V. Manral, R. Papneja Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Sat Apr 13 09:13:05 2019 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 AF3F712077A; Sat, 13 Apr 2019 09:12:55 -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] 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 bUqV9nVaLs-R; Sat, 13 Apr 2019 09:12:53 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 835E0120784; Sat, 13 Apr 2019 09:12:52 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3DGCoHY008999; Sat, 13 Apr 2019 17:12:50 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8CE9F2203B; Sat, 13 Apr 2019 17:12:50 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 771792203A; Sat, 13 Apr 2019 17:12:50 +0100 (BST) Received: from LAPTOPK7AS653V ([87.114.253.143]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3DGCnZ6007839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 Apr 2019 17:12:49 +0100 Reply-To: From: "Adrian Farrel" To: "'Mirja Kuehlewind'" Cc: "=?utf-8?Q?'Mirja_K=C3=BChlewind_via_Datatracker?= =?utf-8?Q?'?=" , "'The IESG'" , , , , References: <155238798836.13888.12133834062700877951.idtracker@ietfa.amsl.com> <001601d4d8d4$2808d1c0$781a7540$@olddog.co.uk> <35AA21D8-14B0-4AF3-A46C-A0349B7697FD@kuehlewind.net> <01ba01d4d99e$eade89e0$c09b9da0$@olddog.co.uk> In-Reply-To: <01ba01d4d99e$eade89e0$c09b9da0$@olddog.co.uk> Date: Sat, 13 Apr 2019 17:12:48 +0100 Organization: Old Dog Consulting Message-ID: <07ac01d4f213$bd8e5870$38ab0950$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQFAhuvuBzGCp3DgpBA+VBQ9KaQwWAH98EEQAV9smssCTdfKAac1vdSA X-Originating-IP: 87.114.253.143 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24550.001 X-TM-AS-Result: No--18.178-10.0-31-10 X-imss-scan-details: No--18.178-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24550.001 X-TMASE-Result: 10--18.177700-10.000000 X-TMASE-MatchedRID: dL10VBB8yofxIbpQ8BhdbFt3XMydUaMXLi2dwKiMR9zoN8DSoota+V6y p3EumDgAUzY1l1iGPWoG6mTN8w5BdCo5l3eEOvf4M8ORI7N4NZYZKp0SZ4P+dRSX1u8BLtZAf/b TCoZRptLnjmT3vqmhOTmv3FUjxYfb+dVjQNaxOrfx5KZMlKYS/aCjvIRDW3XL7ZuNmL4Rc2cHam +XwtBHJZbTSn0tZbEPxQLjVhHavMRPTVZStLvd9aEtILqFekmXecvjbu/xDjpQvOmOsSGiOn2pM 3AyIoP6jSdD+01MNLeOFODziXK8yuZjHoPEX7J1x0PDBzN98K438FNTll9lEu0wjaPq2nvfzuet 2h7oDk6xMDN1c6KuVwWrcvH5RNpBo+j4/L5PWT6WLCkl1lq7BxeKvIXZmbwIJcnDRagjAEYHLwG BIqXN8WaCsIMzyrAtp7VeNu6PRVSKV2xHgiv1d01Wvi92YKnOLJXjpJzQSNM52X8YwVUEW6NHQr uNJthYuAdGWKB0A5Lbu2Nc/AXe5nKKXnQ8W+xG/1aBDnIV4ikIjen4m7yaquXZ6Ej4+VCNo8WMk QWv6iWhMIDkR/KfwP306Q4zhC4D3QfwsVk0UbtuRXh7bFKB7qcesiNhzfvi/2dqCfCt3yyhSyta VO0PrTIBl1e0jGZnYDttQUGqHZU= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?mpls-sr-over-ip-03=3A_=28with_DISCUSS=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 16:12:56 -0000 Hi Mirja, Sorry to be a long time on this. It looks like your concerns around the various OSPF and ISIS drafts has = thrown up a "challenge". One of the references (draft-ietf-isis-encapsulation-cap) is missing in = action, and seems to have been abandoned. This will necessitate some work on the draft to abstract the mechanisms = described into general terms and avoid the need to reference at least = this one draft, and maybe all four of the IGP drafts. Thanks for your patience. Adrian -----Original Message----- From: Adrian Farrel =20 Sent: 13 March 2019 13:16 To: 'Mirja Kuehlewind' Cc: 'Mirja K=C3=BChlewind via Datatracker' ; 'The = IESG' ; mpls@ietf.org; loa@pi.nu; mpls-chairs@ietf.org; = draft-ietf-mpls-sr-over-ip@ietf.org Subject: RE: Mirja K=C3=BChlewind's Discuss on = draft-ietf-mpls-sr-over-ip-03: (with DISCUSS) Thanks Mirja, >>> 1) Given section 3.1, the following drafts all seems that they >>> should be normative references: ietf-isis-encapsulation-cap, >>> ietf-ospf-encapsulation-cap, ietf-ospf-segment-routing-extensions, >>> ietf-isis-segment-routing-extensions >>=20 >> Well, that wasn't the intention. It is meant to be an example of >> how the forwarding entries are constructed. >>=20 >> As it says at the top of Section 3... >> Note that the examples in >> Section 3.1 and Section 3.2 assume that OSPF or ISIS is enabled: in >> fact, other mechanisms of discovery and advertisement could be used >> including other routing protocols (such as BGP) or a central >> controller. >>=20 >> We could be more explicit in section 3.1 so that, for example... >>=20 >> OLD >> o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. >> Router E is SR-MPLS capable, so it advertises an SRGB as = described >> in [I-D.ietf-ospf-segment-routing-extensions] and >> [I-D.ietf-isis-segment-routing-extensions]. >> NEW >> o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. >> Router E is SR-MPLS capable, so it advertises an SRGB to the = other >> SR-MPLS capable routers. If an IGP is in use then Router E = behaves >> as described in [I-D.ietf-ospf-segment-routing-extensions] and >> [I-D.ietf-isis-segment-routing-extensions], but other mechanisms >> Could be applied. >> END >>=20 >> We'd need to make similar changes throughout the section. >>=20 >> Would such changes be enough for you? > > It still sounds to me that these document are basically a must read=20 > to understand the full picture. Do you think it would be a problem > or the wrong thing to make these reference normative? > > However, your wording change makes it definitely more clear that > this is only one example. If the wg and responsible ADs think, = it=E2=80=99s > the right thing to do to leave the reference informative, I will clear > my discuss. I was worried about the rate of progress of SR documents. There has been = a tendency for them to travel a little slowly. It looks like these documents have all now progressed far enough, but = they are caught up in a deadly cluster of missing references (cluster = 340). We'll have a look through the cluster to see how dangerous it is = and make normative references where we can. >>> 2) Sec 3.2.3 on IP Header fields should refer to RFC6040 for the ECN >>> field and eventually RFC2983 for DSCP. >>=20 >> That's good. Thanks. It gives us... >>=20 >> When encapsulating an = MPLS >> packet in UDP, the resulting packet is further = encapsulated in >> IP for transmission. IPv4 or IPv6 may be used according to = the >> capabilities of the network. The address fields are set as >> described in . The other IP = header >> fields (such as the ECN field , = the DSCP=20 >> code point , or IPv6 Flow Label) = on each >> UDP-encapsulated segment SHOULD be configurable according = to the >> operator's policy: they may be copied from the header = of the >> incoming packet; they may be promoted from the header of = the >> payload packet; they may be set according to instructions >> programmed to be associated with the SID; or they may be >> configured dependent on the outgoing interface and = payload. > > Yes, thanks! Perfect. It's in my working copy. Best, Adrian From nobody Sat Apr 13 09:49:24 2019 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 57AA3120676; Sat, 13 Apr 2019 09:49:22 -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] 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 nsdRfxfPm0S5; Sat, 13 Apr 2019 09:49:20 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 526391200F5; Sat, 13 Apr 2019 09:49:20 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3DGnG6g027896; Sat, 13 Apr 2019 17:49:16 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8F0E122044; Sat, 13 Apr 2019 17:49:16 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id 799C522042; Sat, 13 Apr 2019 17:49:16 +0100 (BST) Received: from LAPTOPK7AS653V ([87.114.253.143]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3DGnFSi028138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 Apr 2019 17:49:15 +0100 Reply-To: From: "Adrian Farrel" To: "'Alvaro Retana'" , "'The IESG'" Cc: , "'Loa Andersson'" , , References: <155252870218.24914.13341927320393340552.idtracker@ietfa.amsl.com> In-Reply-To: <155252870218.24914.13341927320393340552.idtracker@ietfa.amsl.com> Date: Sat, 13 Apr 2019 17:49:15 +0100 Organization: Old Dog Consulting Message-ID: <07b401d4f218$d49023a0$7db06ae0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGXr/5JRm+SoBSwKycFVDyv9ALddqa0z/Tw X-Originating-IP: 87.114.253.143 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24550.001 X-TM-AS-Result: No--5.496-10.0-31-10 X-imss-scan-details: No--5.496-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24550.001 X-TMASE-Result: 10--5.495900-10.000000 X-TMASE-MatchedRID: cgbqQT5W8hfxIbpQ8BhdbJmug812qIbzVBDQSDMig9GqvcIF1TcLYCeK 8+lGYU8UFNXAjAP3O4o+0G1eh1ykD0sATHIcfVTRp9ciXoJ/pWsHmzHO3TfA+FAoBBK61BhcSlW s6X1Si4mrBL59TOiLbn/niArZKPBwS62nMBX/dwPmAId+2bAQwn0tCKdnhB58ZYJ9vPJ1vSC0TA yiX6xiQg1fA1QHegDv3QfwsVk0UbuGrPnef/I+epJQyIkwSP3Zg28sBolPzhD4LEGyHrJt77n0o wcZZgNx6gsmHm5e1+w= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] Alvaro Retana's Discuss on draft-ietf-mpls-sr-over-ip-03: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 16:49:22 -0000 Hi Alvaro, More on your other Discuss points later, but... > (3) A very, very late IPR declaration came in after the IETF LC = started. I > didn't find a thread where the WG was made aware of it. > > https://datatracker.ietf.org/ipr/3439/ This was not a comfortable situation. On 11/8, Xiaohu said in an email to the MPLS list... > I'm not aware of any IPR related to this draft. > > Best regards=20 > Xiaohu On 1/23 the IPR disclosure you cite was made and indicates Xiaohu as the = inventor. I have not read the patent and make no judgement about whether it is = relevant to the draft. Anyway... This IPR was brought to the attention of the WG by the disclosure email = on 2/28 and again by your Discuss email on 3/14. Do you now consider that enough opportunity for discussion has happened? Can we close that part of your Discuss? Thanks, Adrian From nobody Sat Apr 13 10:29:44 2019 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 693111202E5; Sat, 13 Apr 2019 10:29:43 -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] 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 ufObBo8obtAo; Sat, 13 Apr 2019 10:29:41 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 63585120072; Sat, 13 Apr 2019 10:29:41 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3DHTb6I006317; Sat, 13 Apr 2019 18:29:37 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 880432203B; Sat, 13 Apr 2019 18:29:37 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id 720DE2203A; Sat, 13 Apr 2019 18:29:37 +0100 (BST) Received: from LAPTOPK7AS653V ([87.114.253.143]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3DHTaOp009344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 Apr 2019 18:29:36 +0100 Reply-To: From: "Adrian Farrel" To: "'Alvaro Retana'" , "'The IESG'" Cc: , "'Loa Andersson'" , , Date: Sat, 13 Apr 2019 18:29:35 +0100 Organization: Old Dog Consulting Message-ID: <07cb01d4f21e$77887800$66996800$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AdTyHlm4BhpszzzJTAyRz6KjfvYBgQ== X-Originating-IP: 87.114.253.143 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24550.001 X-TM-AS-Result: No--15.629-10.0-31-10 X-imss-scan-details: No--15.629-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24550.001 X-TMASE-Result: 10--15.629100-10.000000 X-TMASE-MatchedRID: 8+bhjh9TQnHxIbpQ8BhdbJmug812qIbzC/ExpXrHizwzFWOYrWw6A7y+ AbgLgbEp1ZwcxAra+aa65eNqioKhhBSZwLQuUqmCM8ORI7N4NZZMkOX0UoduuRmy1DfGOok3ZVh gLjSOksYBEAo173VscTWls7ybKDg4otcND2Gb6hRH4a2iJdV4MYnsgRUxNfnHnNgWxWMgxzLIP2 ZkzYGAidLoqdbfb7hikrvm8EJ4+WexpgqXoiq0QaSkqjfmd3aeOhJ9m53n4aCVvypVes2MRYMdL BQl5wHaIou7tFEkkkcGMk4xUJf2CjurH0qx1kBY7TLIvnWov9HyVbjbSjLWDGsxtqQk3w55A5He 1kDS+OLnzlXMYw4XMAGLeSok4rrZU6baA36eiazEQdG7H66TyH4gKq42LRYkcjCQtM0L3jnI530 Zhtdq2hHxNiejHmDwtdOUTC6mzEd+3BndfXUhXQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] Alvaro Retana's Comments on draft-ietf-mpls-sr-over-ip-03: X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 17:29:43 -0000 Hi Alvaro, Again punting on your Discuss for a moment. > COMMENT: > > Thank you for writing this document! > > In general, the use of terminology (defined in rfc8402 and elsewhere) > needs to be cleaned up throughout the document. That's a fine aspiration. Could you give us some pointers to terms that = are used uncleanly? > (1) [nit] From the Abstract: "SR-MPLS could be leveraged...while = preserving > backward compatibility with SR-MPLS." I'm sure you want to say = something > related to making no changes to SR-MPLS for this application...the use = of > backwards compatibility with itself just sounds strange. The = Introduction has > similar text, but it does go on to clarify a little. OK. Abstract text becomes... SR-MPLS can be leveraged to realize a source routing mechanism across MPLS, IPv4, and IPv6 = data planes by using an MPLS label stack as a source routing = instruction set while making no changes to SR-MPLS specifications and interworking = with SR-MPLS implementations. Similar tweak to the Introduction. > (2) [nit] =C2=A73.1: "the FIB can be used to tell a router how to = process packets"=20 > The FIB is generally in the router, so no need to tell it anything. = ;-) Maybe: > "the FIB can be used by the router to process packets". OK. Changed to: Once constructed, the FIB can be used by a router to tell it how = to process packets. > (3) =C2=A73.2: "Not all of the nodes in an SR-MPLS domain are SR-MPLS = capable." By > definition, all nodes in an SR domain participate in the source-based = routing > model [rfc8402]. I think that you meant to say that not all nodes in = the > network (or maybe just the domain) are SR-MPLS capable. The definition of "SR Domain" is a good subject for debate. "Participating in the source-based routing model" means what? A transit node in an SRv6 domain routes packets using the IGP to the = current DA in the header. Such nodes do not need to be SRH-capable or = SRH-aware. But I think they are within the domain. A similar discussion has been going on in 6man with respect to the = phrase "All intra SR Domain packets are of the SR Domain" in = draft-ietf-6man-segment-routing-header-17.txt > Note that the SR domain in the networks in Figure 1, for example, = includes both > the SR-MPLS networks at both sides and the tunneled portion. If you = mean for > that picture to represent 3 different SR domains, then please don't = use > "SR-MPLS domain" to describe what is happening in the IP network = portion. I think your comments are harsh. The term "domain" is not used in that = context. In fact, the term "domain" is not used until section 3. Maybe we could completely not use the term. But it seems (to me) to be a = good term to describe nodes on the path from SR source to SR = destination. > (4) =C2=A73.2: "There are six types of node in an SR-MPLS domain..." = Again, I think > you mean to point at the types of nodes in the network and not in the = SR domain. Nope, the text is accurate and deliberate. The six subsections that = follow describe the cases. All of the node types are within the SR domain (that is, between entry = point where encapsulation happens and exit point where decapsulation = happens). > (5) Security Considerations: Please also point at the considerations = in > rfc8402. Yes. Thanks, Adrian From nobody Sat Apr 13 12:50:24 2019 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 3D67D1203A2; Sat, 13 Apr 2019 12:50:16 -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] 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 kgJjGVGsp_e0; Sat, 13 Apr 2019 12:50:12 -0700 (PDT) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 56EB61202F2; Sat, 13 Apr 2019 12:50:12 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3DJo9Hv006855; Sat, 13 Apr 2019 20:50:10 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 99A6422044; Sat, 13 Apr 2019 20:50:09 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id 8393A22042; Sat, 13 Apr 2019 20:50:09 +0100 (BST) Received: from LAPTOPK7AS653V ([87.114.253.143]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3DJo83L028538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 Apr 2019 20:50:08 +0100 Reply-To: From: "Adrian Farrel" To: "'Benjamin Kaduk'" , Cc: , "'The IESG'" Date: Sat, 13 Apr 2019 20:50:07 +0100 Organization: Old Dog Consulting Message-ID: <07cc01d4f232$19436200$4bca2600$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AdTyIkGL4bsz+3RtSiarnhplnAa5Ng== X-Originating-IP: 87.114.253.143 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24550.002 X-TM-AS-Result: No--16.281-10.0-31-10 X-imss-scan-details: No--16.281-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24550.002 X-TMASE-Result: 10--16.280900-10.000000 X-TMASE-MatchedRID: XafQxseY2BoLd3u89FoqUZmug812qIbzC/ExpXrHizy638ZUY6gSd/GA iqxUbVpalN97Rx3ziGkAfGY5KENAhOmf0V7i7SoMolVO7uyOCDUgdghl533NdYKwF4K/wIz99wE vJvmkUrZdnfNxgbE/Zw7mOhsG9JpUOwJSwPuUvbj0hv/rD7WVZECrr/LkAQ46DYbe/PyX8gQURF 2cIQ7hcZvH8UKvlupfidz3ryKftw8ClT9RFJraecNrWpY804TGNACnndLvXweYu+v96IY4Tt/ib zOMUcg2XAY54E2Tx51lcWVdM5CEMQO2nHhxFhexHcQQBuf4ZFuRTsUaQmAtTjnZfxjBVQRbxQYV VjebBCE1YeXXh0xpWxQp8ap2a9NZvylTzztjYIgQ9/tMNQ4airtq3FNsoMQgM+4wo+7JxdBm+j6 YVbX2YOIGh+KPQfE0sG4G1TxvZZLwUuSygkLx9G/+RwWenb0Y4+ZcrqvCDkH7n73d09vr96m11H O/zcONVCA6qXPQB5xwXiSHLpm02733Y9Ezbie2LUfH1TEwaN2dCQesAegqplmmz7LVVfOp/ETkY c6icX0tv4bG8VuxbtpsXYEExKt7qeLiikTqc4NNI82n17+7UxkqnRJng/51gkyVL6QwZtxBWFCS 0LqYKt3gkgJTGa/hbUmUYHgFEq3XldNKzKPlvdxajlW+zwxCQPCWRE0Lo8IjymkPL84cPyNUTvp /GarBldeVwPvfm995dxppeT1H0KQ4hjf3OSHYHbQ2AJWl6yAsCc2iFTIxreouc5Rcf1B0mLlqwL L7MYFix9AhUO1oWKCTBomMVJl39x0Dj5eS6pueAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8MyrfP9 j+C1SAHAopEd76vpOiwLjXkOhk5dcoEVYSV+mArtSHRWknv59L2ZbvsAmTDvPYbfxY8rw== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [mpls] Ben's Comments on draft-ietf-mpls-sr-over-ip X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 19:50:16 -0000 Hi Ben, Thanks for your very detailed comments on this draft. Quite a lot to = chew on. > Thanks for this clearly-written document! I do have several > suggestions for improvements, and note many places where IS-IS and = OSPF > seem to be described as normative references would, in the vein of > Mirja's DISCUSS. I think it is possible to adjust the document to = keep > those as informative references, but the changes might be pretty > intrusive. I'm going to come back to Mirja's Discuss (and part of Alvaro's Discuss) = when I have some more clarity about how the LSR working group is = advancing the relevant drafts. > I'm a little confused about what exactly the new protocol specified = here > is -- there seems to be a lot of "use these existing technologies > together in the following way" going on, that may be screening the > actual new bits from prominence. The only thing that comes to mind is > the requirement to use the explicit null label when the last label has > PHP and is going over the tunnel, which is admittedly important = behavior > to have! (To be clear, the implication is that a document consisting > solely of "glue these existing pieces together" could well be = published > as Informational, though does not strictly speaking need to be.) I think the same way. It *could* have been Informational, but Standards = Track felt better in this case as it is telling people how make an = operational system out of the existing building blocks. > It might also be helpful to have a reference to RFC 4023 for the plain > MPLS-in-IP encapsulation, even just to contrast it to the MPLS-in-UDP > (RFC 7510) that we do use. (This reader did not discern why the RFC > 4023 encapsulation was unpreferred.) Oh, right. The short answer is "for the same reasons that 7510 unpreffered = MPLS-in-IP" which was largely load balancing through an entropy = indicator. Will add a short note. > Section-by-section comments follow. > > Abstract > > SR-MPLS > could be leveraged to realize a source routing mechanism across = MPLS, > IPv4, and IPv6 data planes by using an MPLS label stack as a source > routing instruction set while preserving backward compatibility with > SR-MPLS. > > Is this really saying "SR-MPLS could be leveraged ... while preserving > compatibility with SR-MPLS"? Fixed per Alvaro's comments. > Section 1 (Introduction) >=20 > Similarly to the above: Ditto > Section 2 > > o If encoding of entropy ([RFC6790] is desired, IP tunneling > mechanisms that allow encoding of entropy, such as MPLS-in-UDP > encapsulation [RFC7510] where the source port of the UDP header = is > > I think it was already noted, but this language reads a little oddly, > and it might be better as "If injection of additional entropy into the > flow is needed". Just buffed up that text a bit. > Section 3.1 > > Consider router A that receives a labeled packet with top label L(E) > that corresponds to the prefix-SID SID(E) of prefix P(E) advertised > by router E. Suppose the i-th next-hop router (termed NHi) along = the > shortest path from router A toward SID(E) is not SR-MPLS capable > while both routers A and E are SR-MPLS capable. [...] > > Do we ever actually use the fact that it is specifically the i-th = router > that is SR-MPLS-incapable, or just need to know that at least one = router > on the path is deficient in that way? It is just a name for that router. It is mentioned again on the last line of section 3.1 > o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. > Router E is SR-MPLS capable, so it advertises an SRGB as = described > in [I-D.ietf-ospf-segment-routing-extensions] and > [I-D.ietf-isis-segment-routing-extensions]. > > I see the first sentence was added in discussion with another = reviewer; > I wonder if the text would flow better if the order of the sentences = was > swapped (particularly since this is the very first "processing step", > and that declarative sentence does not describe any processing > actions). I'll work something out. The "as described" had confused a previous = reader because it seemed to suggest that the SRGB was defined in those = drafts. > o When Router E advertises the prefix-SID SID(E) of prefix P(E) it > MUST also advertise the encapsulation endpoint and the tunnel type > of any tunnel used to reach E. It does this using the mechanisms > described in [I-D.ietf-isis-encapsulation-cap] or > [I-D.ietf-ospf-encapsulation-cap]. > > This "it does this" still is implying that IS-IS and OSPF are the only > ways this can be done, which (AIUI) is not the intention. (Similarly > for the next bullet point's sub-bullets.) s/it does this/it can do this/ > * If router E is running ISIS and advertises the ISIS > capabilities TLV (TLV 242) [RFC7981], it MUST set the "router- > > nit: 7981 seems to call this the "ISIS Router CAPABILITY TLV"; I don't > know if the usage here has since become conventional. s/ies/y/ > o Router A programs the FIB entry for prefix P(E) corresponding to > the SID(E) as follows: > > Keeping with the theme, this is a declarative statement of procedure, > and the following sub-bullets only cover OSPF and ISIS. It would need > to be a statement of requirements for behavior/functionality in order = to > keep them from being normative references. > > Once constructed, the FIB can be used to tell a router how to = process > packets. It encapsulates the packets according to the encapsulation > advertised in [I-D.ietf-isis-encapsulation-cap] or > [I-D.ietf-ospf-encapsulation-cap]. Then it sends the packets = towards > the next hop NHi. > > Oh, finally, "NHi" appears again. But are we actually forwarding > towards the SR-MPLS-incapable router specifically, or just generically > to the immediate next hop (which may or may not be NHi)? I told you so =F0=9F=98=89 It really means NHi. The previous hop does the encapsulation and then = forwards *towards* (i.e., out of the interface pointing at NHi) but not = with the DA set to NHi. > Also, I'll note that we introduced this list with "the following > processing steps apply [for A wanting to send a packet towards E]", = but > most of the procedures therein involve things that E has to do to > advertise the information that A will need in order to make the > encapsulation, which feels like somewhat mismatched language. In = short, > this list of points doesn't tell me much about what specifically *A* > does with this packet -- the last point handles what to do with the = top > label, but I guess we defer to the encapsulation scheme for the gory > details (which is probably fine, but maybe the language could be = tidied > up to mention something about "using the appropriate mechanism for the > selected tunnel type (e.g., IP)"). I'm going to call upon your "which is probably fine". > packets. It encapsulates the packets according to the encapsulation > advertised in [I-D.ietf-isis-encapsulation-cap] or > [I-D.ietf-ospf-encapsulation-cap]. Then it sends the packets = towards > > nit: advertised *using the mechanisms in* Ack > Section 3.2 > > [RFC7510] specifies an IP-based encapsulation for MPLS, i.e., MPLS- > in-UDP. This approach is applicable where IP-based encapsulation = for > MPLS is required and further fine-grained load balancing of MPLS > packets over IP networks over Equal-Cost Multipath (ECMP) and/or = Link > Aggregation Groups (LAGs) is also required. This section provides > details about the forwarding procedure when when UDP encapsulation = is > adopted for SR-MPLS over IP. > > (side note) Presumably this is just my lack of background showing, but > this text seems to assume that the UDP encapsulation is the only way = to > do SR-MPLS over IP, with no discussion of RFC 4023. This section is certainly limited to the UDP choice. Actually, we can add "Other encapsulation and tunnelling mechanisms can = be applied using similar techniques, but for clarity this section uses = UDP encapsulation as the exemplar." > Nodes that are SR-MPLS capable can process SR-MPLS packets. Not all > of the nodes in an SR-MPLS domain are SR-MPLS capable. Some nodes > may be "legacy routers" that cannot handle SR-MPLS packets but can > forward IP packets. An SR-MPLS-capable node MAY advertise its > capabilities using the IGP as described in Section 3. There are six > types of node in an SR-MPLS domain: > > (side note) Similarly, we only talk about SR-MPLS and IP routers here; > is there some intermediate "MPLS but not SR-MPLS" category or similar? Ah, a good question. MPLS routers are automatically able to forward SR-MPLS packets. So, if = they lack SR capabilities they still participate seamlessly. And, in cast, if you had a sea of MPLS routers, you wouldn't need any = encapsulation at all. > Also, the top-level Section 3 is just introductory text and doesn't > really describe much of anything, and if we are considering this to > refer to Section 3 and subsections, it then becomes self-referential. I think it applies to 3.2. > Section 3.2.1 > > Routers A, E, G, and H > advertise their Segment Routing related information via IS-IS or > OSPF. > > [still declarative] Still fixing =F0=9F=98=8A > To handle this, when a router (here it is router G) pops the final > SR-MPLS label, it inserts an explicit null label [RFC3032] before > encapsulating the packet in an MPLS-over-UDP tunnel toward router H > and sending it out. That is, router G pops the top label, discovers > it has reached the bottom of stack, pushes an explicit null label, > and then encapsulates the MPLS packet in a UDP tunnel to router H. > > This seems like a critical functional behavior that is not specific to > the usage of IS-IS or OSPF. Agreed. Covered by previous fix. > Section 3.2.3 > > For instance, in the example as described in Figure 4, assume F = is > now an SR-MPLS-capable transit node while all the other > assumptions keep unchanged, since F is not identified by a SID in > the stack and an MPLS-over-UDP tunnel is preferred to an MPLS LSP > according to local policies, router E would replace the current > top label with an MPLS-over-UDP tunnel toward router G and send = it > out. > > (nit: There's a comma splice before "since F".) Ack > This description is a little sparse, and seems to assume the reader > knows that, all else being equal, with E, F, and G all being > MPLS-capable, the segment from E to G would transit native MPLS, = absent > the indicated local policy. Since this is explicitly the thing we are > contrasting against, it's probably good style to mention the behavior > explicitly, too. OK. "Good style" is our watchword. > IP Header Fields: When encapsulating an MPLS packet in UDP, the > resulting packet is further encapsulated in IP for transmission. > IPv4 or IPv6 may be used according to the capabilities of the > network. The address fields are set as described in Section 2. > > (Does Section 2 say how to set the source address?) Sure does. The tunnel selected MUST have its remote end point (destination) address equal to the address of the next SR-MPLS capable node along the path (i.e., the egress of the active node segment). > Entropy and ECMP: When encapsulating an MPLS packet with an IP > tunnel header that is capable of encoding entropy (such as > [RFC7510]), the corresponding entropy field (the source port in > case UDP tunnel) MAY be filled with an entropy value that is > > nit: "in the case of a UDP tunnel" Ack > Section 5 > > [I'm going to comment on basically every line here; sorry to be so > nitpicky.] I'm going to cross-check. If you have left a line uncommented I will = demand a refund. If only we had written more lines. > The security consideration of [RFC8354] and [RFC7510] apply. DTLS > > RFC 8354's security considerations are, for practical purposes, empty. > Perhaps a direct reference to 5095 would be more appropriate. > (The RFC 7510 security considerations are of course quite relevant and > helpful.) Yes, let's have... The security consideration of [RFC8354] (which redirects the reader to = [RFC5095]) and [RFC7510] apply ...since 8354 remains the more "relevant" reference. > [RFC6347] SHOULD be used where security is needed on an MPLS-SR-over- > UDP segment. > > I think you need to give some indication of when that might be the = case, > e.g., if the IP segment crosses the public Internet or some other > untrusted environment. I guess that is a good example. I'm worried that it may limit the = imagination of the reader. I'm going to use "including when" in place of "e.g., if" > It is difficult for an attacker to pass a raw MPLS encoded packet > into a network and operators have considerable experience at > excluding such packets at the network boundaries. > > This is describing an expected/desired state (hopefully also the = current > state!) but not why that should be or what the consequences of failing > to achieve that state are. I'm happy to contribute some text, but = this > seems like a generic MPLS consideration and I hope there is an > already-published reference that could be used instead. Well, I'll add a reference to 5920, but I don't think that completely = covers it. This is the equivalent of an ACL to prevent IP-in-IP intrusion, but = essentially says don't let MPLS emerge from an IP tunnel in the network. = Everyone does it, not sure it is documented anywhere. That gives us... It is difficult for an attacker to pass a raw MPLS encoded packet into a network and operators have considerable experience at = excluding such packets at the network boundaries, for example by excluding = all MPLS packets that are revealed as payload of IP tunnels. Further = discussion of MPLS security is found in [RFC5920]. > It is easy for an ingress node to detect any attempt to smuggle an = IP > packet into the network since it would see that the UDP destination > port was set to MPLS. SR packets not having a destination address > > Easy, sure, if you know to look for it. Where is that requirement > mandated? We don't mandate against self-harm. But I add... , and such filtering SHOULD be applied > terminating in the network would be transparently carried and would > pose no security risk to the network under consideration. > > I'm not sure I see how the second sentence relates to the first; is = this > just trying to say that SR-MPLS is transparent to traffic flowing over > such a network? There would still be generic capacity risks, of = course, > though maybe we don't need to be so specific -- "pose no different > security risk than any other traffic" would be plenty. OK > Where control plane techniques are used (as described in Section 3), > it is important that these protocols are adequately secured for the > environment in which they are run. > > What does "adequately secured" mean? Is there a best-practices > document, or security considerations for the control protocols in > question that cover this? Is the needed property that "any packets > interpreted as MPLS must be originated from authorized network devices > within the administrative domain (or group of such domains), with no > ability for attackers to inject such traffic inside the domain and > blocking at the boundary"? When different administrative domains are > joined together, what are the counterparty risks? OK, these are not MPLS packets, they are control plane packets. The injection of MPLS packets was where we were a few comments further = up. "Adequately secured" is indeed a wide scope. I think 5920 is our base = reference for all MPLS control plane security issues. But perhaps 6862 as well. Best, Adrian From nobody Sat Apr 13 12:52:56 2019 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 0B8411203A2; Sat, 13 Apr 2019 12:52:54 -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] 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 bZpzJFqxjSWN; Sat, 13 Apr 2019 12:52:52 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 4934C1202F2; Sat, 13 Apr 2019 12:52:52 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3DJqobJ006430; Sat, 13 Apr 2019 20:52:50 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 59A1C2203B; Sat, 13 Apr 2019 20:52:50 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 443992203A; Sat, 13 Apr 2019 20:52:50 +0100 (BST) Received: from LAPTOPK7AS653V ([87.114.253.143]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3DJqmWx024326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 Apr 2019 20:52:49 +0100 Reply-To: From: "Adrian Farrel" To: "'Martin Vigoureux'" , Cc: , "'The IESG'" Date: Sat, 13 Apr 2019 20:52:48 +0100 Organization: Old Dog Consulting Message-ID: <07cd01d4f232$7947c420$6bd74c60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AdTyMikx/26R/sqxTDa3K+VNEw3Nuw== X-Originating-IP: 87.114.253.143 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24550.002 X-TM-AS-Result: No--3.591-10.0-31-10 X-imss-scan-details: No--3.591-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24550.002 X-TMASE-Result: 10--3.590800-10.000000 X-TMASE-MatchedRID: ATarjMjlP6tCMOF2vSwLTAPZZctd3P4BC/ExpXrHizz1hG9r+PlJDDe5 +TJUtSXthmzuGr8BHoGyT0R384dbTWResrHRY7dKngIgpj8eDcC063Wh9WVqgoou5V2iHBf13n8 eBZjGmUzkwjHXXC/4I7I7zVffJqTzO2uhK2p87zgiWbofkNyBQiRLMPChwgCB9dbaOW83CRWry7 iX+p9SCsQqHltHU9gWh/yQr4rUA+khyumgjE26dT+WrqjKZ1gr X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [mpls] Martin's Comment on draft-ietf-mpls-sr-over-ip X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 19:52:54 -0000 Hi Martin, You wrote... > Maybe I didn't sleep enough and maybe this relates to Alvaro's DISCUSS, but I don't see what, > in 3.1, is specific to the fact that "i-th next-hop router (termed NHi) along the shortest path > from router A toward SID(E) is not SR-MPLS capable" Have you had more sleep yet? I think this is answered in my response to Ben. Thanks, Adrian From nobody Sat Apr 13 13:24:41 2019 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 541FC120105; Sat, 13 Apr 2019 13:24:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <155518707224.14691.11979346852531102561@ietfa.amsl.com> Date: Sat, 13 Apr 2019 13:24:32 -0700 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-sr-over-ip-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 20:24:33 -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 WG of the IETF. Title : SR-MPLS over IP Authors : Xiaohu Xu Stewart Bryant Adrian Farrel Syed Hassan Wim Henderickx Zhenbin Li Filename : draft-ietf-mpls-sr-over-ip-04.txt Pages : 17 Date : 2019-04-13 Abstract: MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source routing paradigm in which the sender of a packet is allowed to partially or completely specify the route the packet takes through the network by imposing stacked MPLS labels on the packet. SR-MPLS can be leveraged to realize a source routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source routing instruction set while making no changes to SR-MPLS specifications and interworking with SR-MPLS implementations. This document describes how SR-MPLS capable routers and IP-only routers can seamlessly co-exist and interoperate through the use of SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in- UDP as defined in RFC 7510. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-sr-over-ip/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-04 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-sr-over-ip-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-sr-over-ip-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 13 13:27:34 2019 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 B2D3F1200D5; Sat, 13 Apr 2019 13:27:31 -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] 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 QbhSgiBmw4Om; Sat, 13 Apr 2019 13:27:30 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 E591F120033; Sat, 13 Apr 2019 13:27:29 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3DKRMgp012867; Sat, 13 Apr 2019 21:27:22 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8F86B22042; Sat, 13 Apr 2019 21:27:22 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id 7A25422048; Sat, 13 Apr 2019 21:27:22 +0100 (BST) Received: from LAPTOPK7AS653V ([87.114.253.143]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3DKRImg013880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 Apr 2019 21:27:19 +0100 Reply-To: From: "Adrian Farrel" To: , "'Mirja Kuehlewind'" , "'Alvaro Retana'" , "'BRUNGARD, DEBORAH A'" Cc: Date: Sat, 13 Apr 2019 21:27:17 +0100 Organization: Old Dog Consulting Message-ID: <07d001d4f237$4c3100f0$e49302d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AdTyNyocqKPRgOsVQ+eXj2iFO0gd6g== X-Originating-IP: 87.114.253.143 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24550.002 X-TM-AS-Result: No--0.599-10.0-31-10 X-imss-scan-details: No--0.599-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24550.002 X-TMASE-Result: 10--0.599000-10.000000 X-TMASE-MatchedRID: VZz6+2A6wprVDAMEwzgZ7Lu9iqQJLR0vTJDl9FKHbrmH8Gp6NIN6goL8 17LE9TTs5rCqjBLF8SfnLQ6DoH8uxsME2BsoiKJMydRN/Yyg4pgk80hXoYXyawVB1XtT2b8hvyQ s1YtVVkjaL/cwuyD9C33J0gEt3fM9GAdnzrnkM485f9Xw/xqKXVsKO+9Zlb5JEpKRTJaKTD0UGm 4zriL0oQtuKBGekqUpnH7sbImOEBQZuizsUGlXTJq741zbhuuL+VpCPMPleXMdSJYKpChx4M02u Kpp7mZ022IClohlakyd7+8m/EmB5dnyNKbWDiQGrYiDMHkHLFHkP2yapUEP3KKWedUMQI938fsC +xPFkxvsNp90fT4EjrAUyUg9ogFt X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [mpls] Recent update : draft-ietf-mpls-sr-over-ip-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 20:27:32 -0000 This new revision addresses the following points... Mirja's second Discuss point References to RFC6040 for the ECN field and RFC2983 for DSCP Alvaro's Comments Tidied language in Abstract and Introduction wrt "backwards compatibility" Cleaned text in 3.1 about usage of FIB Add pointer to RFC 8402 in Security Considerations Spencer's Comment Added paragraph in 3.2.3 on Congestion Control considerations Ben's Comments Lots of little changes per my email A further update will be needed for Mirja's first Discuss point and for Alvaro's Discuss. Thanks, Adrian From nobody Tue Apr 16 10:49:50 2019 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 3EA42120308; Tue, 16 Apr 2019 10:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 zvT6pUqOLnNA; Tue, 16 Apr 2019 10:49:46 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 3304F120226; Tue, 16 Apr 2019 10:49:46 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id k14so24355297qtb.0; Tue, 16 Apr 2019 10:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :accept-language:content-language:mime-version; bh=cdSxBVPW+Bp7an20aC5daxo8N9V5wHw0SalRsGnLjO8=; b=KZFKc5Ydo0qiY3lYiRMRZ3SiW8oiVcAIIbqEDTfDABW96sFXGQB5KV0NHSaK1x2tw+ UXHB2sZFW6jgLKi1VB1Ih6zC+EjTKG7odUMadHyJ754u6ZSrX3Ns1wNB59YKsWdl4aHO Kx19NeiGPo0Vnewp8aW/9MuR3RFLnFnu/b7+Y+bcxNm2mUveQKzQ6V+LMHuaaLSNhkqY s7ixkZZu5Nm6Flm1OEUPWUqmdF39LjUgYQKQn8fBxnGrX25mm+N/Gpf9fKO6eUB1QFUd 15fVcxyzwzV9SrqzVox1VyACOuqc8cbAFwD9KHW0PIywTed81hFWlpMvJCvmqY3hJhFl NOvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:accept-language:content-language:mime-version; bh=cdSxBVPW+Bp7an20aC5daxo8N9V5wHw0SalRsGnLjO8=; b=MGSYYw9NGTsbT1wdBgM1dxNk/zGT8A1581QSGivS6F7/WjrFnmIJdBjiMTOx84hmHm q9Kt7i26pmKrGsoEu+Y0hI0ISxRmkRqoh/THlW7XHuZfiVr8RpJnXjjy8zMiTAxdJO71 OXPzKFtOgD8SmBCmUf9RSOJLNNAqXsKBlkJfg4SJ9iTvphdJqUlrNU9/68kcDaoZhcuj FkAUTA0GAtElhhHMbfA6b/i2WDAeXqsOVqL6F8TlsnVR1jIIPNXfpVitvvQeelNUdRM1 yVxv3iIcsSEW0bZZ5eslN6EptcmbIm35M50y5gXZE2avCFowdOBXQKjl/0TpylE+CHpN 5j3w== X-Gm-Message-State: APjAAAURsiK//3SGIKoZrxGncpQ+eHbeYyUPyPjQDTVJh3h6xXQCDnJF CnTLp0s2lzQRhi1bcYit4nKYu99V X-Google-Smtp-Source: APXvYqznvx+911oxqZCj3u+Pm8FLXZzbW/hSeCZNsdv7wFDfUGDdeVLbJ15qOsAQrp1fAfbhbFUo7g== X-Received: by 2002:ac8:2692:: with SMTP id 18mr66694315qto.343.1555436984815; Tue, 16 Apr 2019 10:49:44 -0700 (PDT) Received: from BN8PR06MB6289.namprd06.prod.outlook.com ([52.96.29.13]) by smtp.gmail.com with ESMTPSA id 6sm33273671qtt.8.2019.04.16.10.49.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Apr 2019 10:49:44 -0700 (PDT) From: Tarek Saad To: "mpls@ietf.org" CC: "mpls-chairs@ietf.org" Thread-Topic: IETF104 MPLS WG session minutes Thread-Index: AQHU9HzF7XOsbZqx+U+onihtBSNd3A== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Tue, 16 Apr 2019 17:49:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_BN8PR06MB628948CAC2879AF493F43F06FC240BN8PR06MB6289namp_" MIME-Version: 1.0 Archived-At: Subject: [mpls] IETF104 MPLS WG session minutes X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 17:49:48 -0000 --_000_BN8PR06MB628948CAC2879AF493F43F06FC240BN8PR06MB6289namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Please find the meeting minutes for the MPLS WG session at IETF 104 in Prag= ue below. Please unicast me for if there updates/corrections needed. https://datatracker.ietf.org/meeting/104/materials/minutes-104-mpls-01 Regards, Tarek and MPLS chairs --_000_BN8PR06MB628948CAC2879AF493F43F06FC240BN8PR06MB6289namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,<= /span>

 

Please find the mee= ting minutes for the MPLS WG session at IETF 104 in Prague below. Please un= icast me for if there updates/corrections needed.

https://datatracker.ietf.org/meeting/104/mat= erials/minutes-104-mpls-01

 

Regards,=

Tarek and MPLS chai= rs

--_000_BN8PR06MB628948CAC2879AF493F43F06FC240BN8PR06MB6289namp_-- From nobody Tue Apr 16 13:57:06 2019 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 59036120627; Tue, 16 Apr 2019 13:56:45 -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.95.0 Auto-Submitted: auto-generated Precedence: bulk Cc: mpls@ietf.org, db3546@att.com, The IESG , mpls-chairs@ietf.org, draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org, rfc-editor@rfc-editor.org, loa@pi.nu Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155544820535.25081.12131466486802638005.idtracker@ietfa.amsl.com> Date: Tue, 16 Apr 2019 13:56:45 -0700 Archived-At: Subject: [mpls] Protocol Action: 'Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces' to Proposed Standard (draft-ietf-mpls-lsp-ping-lag-multipath-08.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 20:56:52 -0000 The IESG has approved the following document: - 'Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces' (draft-ietf-mpls-lsp-ping-lag-multipath-08.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-lag-multipath/ Technical Summary This document defines extensions to the MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. Additionally, a mechanism is defined to enable determination of the capabilities of an LSR supported. Working Group Summary There was solid support for this document within the working group. Document Quality Yes, we know of implementations of this protocol. Personnel Who is the Document Shepherd for this document? Loa Andersson Who is the Responsible Area Director? Deborah Brungard RFC Editor Note Section 3.1 it can send an MPLS each request message/s/it can send an MPLS echo request message Section 3.2 When a responder LSR received/s/When a responder LSR receives From nobody Fri Apr 19 23:23:48 2019 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 4BF51120099; Fri, 19 Apr 2019 23:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ZyKe8gpssYkn; Fri, 19 Apr 2019 23:21:46 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 3761612008B; Fri, 19 Apr 2019 23:21:45 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3K6Lf14026730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 20 Apr 2019 02:21:43 -0400 Date: Sat, 20 Apr 2019 01:21:41 -0500 From: Benjamin Kaduk To: Adrian Farrel Cc: mpls@ietf.org, draft-ietf-mpls-sr-over-ip@ietf.org, "'The IESG'" Message-ID: <20190420062140.GU51586@kduck.mit.edu> References: <07cc01d4f232$19436200$4bca2600$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <07cc01d4f232$19436200$4bca2600$@olddog.co.uk> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [mpls] Ben's Comments on draft-ietf-mpls-sr-over-ip X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 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 Apr 2019 06:21:49 -0000 Hi Adrian, On Sat, Apr 13, 2019 at 08:50:07PM +0100, Adrian Farrel wrote: > Hi Ben, > > Thanks for your very detailed comments on this draft. Quite a lot to chew on. And thank you for the detailed replies. I read them all, but only have further comment on a handful. > > Thanks for this clearly-written document! I do have several > > suggestions for improvements, and note many places where IS-IS and OSPF > > seem to be described as normative references would, in the vein of > > Mirja's DISCUSS. I think it is possible to adjust the document to keep > > those as informative references, but the changes might be pretty > > intrusive. > > I'm going to come back to Mirja's Discuss (and part of Alvaro's Discuss) when I have some more clarity about how the LSR working group is advancing the relevant drafts. > > > I'm a little confused about what exactly the new protocol specified here > > is -- there seems to be a lot of "use these existing technologies > > together in the following way" going on, that may be screening the > > actual new bits from prominence. The only thing that comes to mind is > > the requirement to use the explicit null label when the last label has > > PHP and is going over the tunnel, which is admittedly important behavior > > to have! (To be clear, the implication is that a document consisting > > solely of "glue these existing pieces together" could well be published > > as Informational, though does not strictly speaking need to be.) > > I think the same way. It *could* have been Informational, but Standards Track felt better in this case as it is telling people how make an operational system out of the existing building blocks. > > > It might also be helpful to have a reference to RFC 4023 for the plain > > MPLS-in-IP encapsulation, even just to contrast it to the MPLS-in-UDP > > (RFC 7510) that we do use. (This reader did not discern why the RFC > > 4023 encapsulation was unpreferred.) > > Oh, right. > The short answer is "for the same reasons that 7510 unpreffered MPLS-in-IP" which was largely load balancing through an entropy indicator. > Will add a short note. > > > Section-by-section comments follow. > > > > Abstract > > > > SR-MPLS > > could be leveraged to realize a source routing mechanism across MPLS, > > IPv4, and IPv6 data planes by using an MPLS label stack as a source > > routing instruction set while preserving backward compatibility with > > SR-MPLS. > > > > Is this really saying "SR-MPLS could be leveraged ... while preserving > > compatibility with SR-MPLS"? > > Fixed per Alvaro's comments. > > > Section 1 (Introduction) > > > > Similarly to the above: > > Ditto > > > Section 2 > > > > o If encoding of entropy ([RFC6790] is desired, IP tunneling > > mechanisms that allow encoding of entropy, such as MPLS-in-UDP > > encapsulation [RFC7510] where the source port of the UDP header is > > > > I think it was already noted, but this language reads a little oddly, > > and it might be better as "If injection of additional entropy into the > > flow is needed". > > Just buffed up that text a bit. > > > Section 3.1 > > > > Consider router A that receives a labeled packet with top label L(E) > > that corresponds to the prefix-SID SID(E) of prefix P(E) advertised > > by router E. Suppose the i-th next-hop router (termed NHi) along the > > shortest path from router A toward SID(E) is not SR-MPLS capable > > while both routers A and E are SR-MPLS capable. [...] > > > > Do we ever actually use the fact that it is specifically the i-th router > > that is SR-MPLS-incapable, or just need to know that at least one router > > on the path is deficient in that way? > > It is just a name for that router. > It is mentioned again on the last line of section 3.1 > > > o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. > > Router E is SR-MPLS capable, so it advertises an SRGB as described > > in [I-D.ietf-ospf-segment-routing-extensions] and > > [I-D.ietf-isis-segment-routing-extensions]. > > > > I see the first sentence was added in discussion with another reviewer; > > I wonder if the text would flow better if the order of the sentences was > > swapped (particularly since this is the very first "processing step", > > and that declarative sentence does not describe any processing > > actions). > > I'll work something out. The "as described" had confused a previous reader because it seemed to suggest that the SRGB was defined in those drafts. > > > o When Router E advertises the prefix-SID SID(E) of prefix P(E) it > > MUST also advertise the encapsulation endpoint and the tunnel type > > of any tunnel used to reach E. It does this using the mechanisms > > described in [I-D.ietf-isis-encapsulation-cap] or > > [I-D.ietf-ospf-encapsulation-cap]. > > > > This "it does this" still is implying that IS-IS and OSPF are the only > > ways this can be done, which (AIUI) is not the intention. (Similarly > > for the next bullet point's sub-bullets.) > > s/it does this/it can do this/ > > > * If router E is running ISIS and advertises the ISIS > > capabilities TLV (TLV 242) [RFC7981], it MUST set the "router- > > > > nit: 7981 seems to call this the "ISIS Router CAPABILITY TLV"; I don't > > know if the usage here has since become conventional. > > s/ies/y/ > > > o Router A programs the FIB entry for prefix P(E) corresponding to > > the SID(E) as follows: > > > > Keeping with the theme, this is a declarative statement of procedure, > > and the following sub-bullets only cover OSPF and ISIS. It would need > > to be a statement of requirements for behavior/functionality in order to > > keep them from being normative references. > > > > Once constructed, the FIB can be used to tell a router how to process > > packets. It encapsulates the packets according to the encapsulation > > advertised in [I-D.ietf-isis-encapsulation-cap] or > > [I-D.ietf-ospf-encapsulation-cap]. Then it sends the packets towards > > the next hop NHi. > > > > Oh, finally, "NHi" appears again. But are we actually forwarding > > towards the SR-MPLS-incapable router specifically, or just generically > > to the immediate next hop (which may or may not be NHi)? > > I told you so 😉 > It really means NHi. The previous hop does the encapsulation and then forwards *towards* (i.e., out of the interface pointing at NHi) but not with the DA set to NHi. > > > Also, I'll note that we introduced this list with "the following > > processing steps apply [for A wanting to send a packet towards E]", but > > most of the procedures therein involve things that E has to do to > > advertise the information that A will need in order to make the > > encapsulation, which feels like somewhat mismatched language. In short, > > this list of points doesn't tell me much about what specifically *A* > > does with this packet -- the last point handles what to do with the top > > label, but I guess we defer to the encapsulation scheme for the gory > > details (which is probably fine, but maybe the language could be tidied > > up to mention something about "using the appropriate mechanism for the > > selected tunnel type (e.g., IP)"). > > I'm going to call upon your "which is probably fine". > > > packets. It encapsulates the packets according to the encapsulation > > advertised in [I-D.ietf-isis-encapsulation-cap] or > > [I-D.ietf-ospf-encapsulation-cap]. Then it sends the packets towards > > > > nit: advertised *using the mechanisms in* > > Ack > > > Section 3.2 > > > > [RFC7510] specifies an IP-based encapsulation for MPLS, i.e., MPLS- > > in-UDP. This approach is applicable where IP-based encapsulation for > > MPLS is required and further fine-grained load balancing of MPLS > > packets over IP networks over Equal-Cost Multipath (ECMP) and/or Link > > Aggregation Groups (LAGs) is also required. This section provides > > details about the forwarding procedure when when UDP encapsulation is > > adopted for SR-MPLS over IP. > > > > (side note) Presumably this is just my lack of background showing, but > > this text seems to assume that the UDP encapsulation is the only way to > > do SR-MPLS over IP, with no discussion of RFC 4023. > > This section is certainly limited to the UDP choice. > Actually, we can add "Other encapsulation and tunnelling mechanisms can be applied using similar techniques, but for clarity this section uses UDP encapsulation as the exemplar." > > > Nodes that are SR-MPLS capable can process SR-MPLS packets. Not all > > of the nodes in an SR-MPLS domain are SR-MPLS capable. Some nodes > > may be "legacy routers" that cannot handle SR-MPLS packets but can > > forward IP packets. An SR-MPLS-capable node MAY advertise its > > capabilities using the IGP as described in Section 3. There are six > > types of node in an SR-MPLS domain: > > > > (side note) Similarly, we only talk about SR-MPLS and IP routers here; > > is there some intermediate "MPLS but not SR-MPLS" category or similar? > > Ah, a good question. > MPLS routers are automatically able to forward SR-MPLS packets. So, if they lack SR capabilities they still participate seamlessly. > And, in cast, if you had a sea of MPLS routers, you wouldn't need any encapsulation at all. > > > Also, the top-level Section 3 is just introductory text and doesn't > > really describe much of anything, and if we are considering this to > > refer to Section 3 and subsections, it then becomes self-referential. > > I think it applies to 3.2. > > > Section 3.2.1 > > > > Routers A, E, G, and H > > advertise their Segment Routing related information via IS-IS or > > OSPF. > > > > [still declarative] > > Still fixing 😊 > > > To handle this, when a router (here it is router G) pops the final > > SR-MPLS label, it inserts an explicit null label [RFC3032] before > > encapsulating the packet in an MPLS-over-UDP tunnel toward router H > > and sending it out. That is, router G pops the top label, discovers > > it has reached the bottom of stack, pushes an explicit null label, > > and then encapsulates the MPLS packet in a UDP tunnel to router H. > > > > This seems like a critical functional behavior that is not specific to > > the usage of IS-IS or OSPF. > > Agreed. Covered by previous fix. > > > Section 3.2.3 > > > > For instance, in the example as described in Figure 4, assume F is > > now an SR-MPLS-capable transit node while all the other > > assumptions keep unchanged, since F is not identified by a SID in > > the stack and an MPLS-over-UDP tunnel is preferred to an MPLS LSP > > according to local policies, router E would replace the current > > top label with an MPLS-over-UDP tunnel toward router G and send it > > out. > > > > (nit: There's a comma splice before "since F".) > > Ack > > > This description is a little sparse, and seems to assume the reader > > knows that, all else being equal, with E, F, and G all being > > MPLS-capable, the segment from E to G would transit native MPLS, absent > > the indicated local policy. Since this is explicitly the thing we are > > contrasting against, it's probably good style to mention the behavior > > explicitly, too. > > OK. "Good style" is our watchword. > > > IP Header Fields: When encapsulating an MPLS packet in UDP, the > > resulting packet is further encapsulated in IP for transmission. > > IPv4 or IPv6 may be used according to the capabilities of the > > network. The address fields are set as described in Section 2. > > > > (Does Section 2 say how to set the source address?) > > Sure does. > The tunnel selected MUST have its > remote end point (destination) address equal to the address of the > next SR-MPLS capable node along the path (i.e., the egress of the > active node segment). I might still be missing it. Is the idea that once you've selected a specific tunnel, that naturally will have a record of the source address corresponding to that tunnel? (I only see a literal "remote end point (destination) address" in the quoted text, i.e., "source" or "local" do not appear.) > > Entropy and ECMP: When encapsulating an MPLS packet with an IP > > tunnel header that is capable of encoding entropy (such as > > [RFC7510]), the corresponding entropy field (the source port in > > case UDP tunnel) MAY be filled with an entropy value that is > > > > nit: "in the case of a UDP tunnel" > > Ack > > > Section 5 > > > > [I'm going to comment on basically every line here; sorry to be so > > nitpicky.] > > I'm going to cross-check. If you have left a line uncommented I will demand a refund. > If only we had written more lines. > > > The security consideration of [RFC8354] and [RFC7510] apply. DTLS > > > > RFC 8354's security considerations are, for practical purposes, empty. > > Perhaps a direct reference to 5095 would be more appropriate. > > (The RFC 7510 security considerations are of course quite relevant and > > helpful.) > > Yes, let's have... > The security consideration of [RFC8354] (which redirects the reader to [RFC5095]) and [RFC7510] apply > ...since 8354 remains the more "relevant" reference. > > > [RFC6347] SHOULD be used where security is needed on an MPLS-SR-over- > > UDP segment. > > > > I think you need to give some indication of when that might be the case, > > e.g., if the IP segment crosses the public Internet or some other > > untrusted environment. > > I guess that is a good example. I'm worried that it may limit the imagination of the reader. > > I'm going to use "including when" in place of "e.g., if" I was not intending to suggest that the "e.g." appear in the document, so thank you for this. > > It is difficult for an attacker to pass a raw MPLS encoded packet > > into a network and operators have considerable experience at > > excluding such packets at the network boundaries. > > > > This is describing an expected/desired state (hopefully also the current > > state!) but not why that should be or what the consequences of failing > > to achieve that state are. I'm happy to contribute some text, but this > > seems like a generic MPLS consideration and I hope there is an > > already-published reference that could be used instead. > > Well, I'll add a reference to 5920, but I don't think that completely covers it. > This is the equivalent of an ACL to prevent IP-in-IP intrusion, but essentially says don't let MPLS emerge from an IP tunnel in the network. Everyone does it, not sure it is documented anywhere. > > That gives us... > > It is difficult for an attacker to pass a raw MPLS encoded packet > into a network and operators have considerable experience at excluding > such packets at the network boundaries, for example by excluding all > MPLS packets that are revealed as payload of IP tunnels. Further discussion > of MPLS security is found in [RFC5920]. Thanks. (I was pretty sure everyone does it, but that doesn't always mean that we don't need to say it in the doc, as I'm sure you know...) > > It is easy for an ingress node to detect any attempt to smuggle an IP > > packet into the network since it would see that the UDP destination > > port was set to MPLS. SR packets not having a destination address > > > > Easy, sure, if you know to look for it. Where is that requirement > > mandated? > > We don't mandate against self-harm. > But I add... > , and such filtering SHOULD be applied > > > terminating in the network would be transparently carried and would > > pose no security risk to the network under consideration. > > > > I'm not sure I see how the second sentence relates to the first; is this > > just trying to say that SR-MPLS is transparent to traffic flowing over > > such a network? There would still be generic capacity risks, of course, > > though maybe we don't need to be so specific -- "pose no different > > security risk than any other traffic" would be plenty. > > OK > > > Where control plane techniques are used (as described in Section 3), > > it is important that these protocols are adequately secured for the > > environment in which they are run. > > > > What does "adequately secured" mean? Is there a best-practices > > document, or security considerations for the control protocols in > > question that cover this? Is the needed property that "any packets > > interpreted as MPLS must be originated from authorized network devices > > within the administrative domain (or group of such domains), with no > > ability for attackers to inject such traffic inside the domain and > > blocking at the boundary"? When different administrative domains are > > joined together, what are the counterparty risks? > > OK, these are not MPLS packets, they are control plane packets. > The injection of MPLS packets was where we were a few comments further up. > > "Adequately secured" is indeed a wide scope. I think 5920 is our base reference for all MPLS control plane security issues. > > But perhaps 6862 as well. OK, I trust you to know better than I would. Thanks again, Ben From nobody Tue Apr 23 22:06:42 2019 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 6E0BD120154; Tue, 23 Apr 2019 22:06:41 -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.95.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155608240137.32541.12190334554098278669.idtracker@ietfa.amsl.com> Date: Tue, 23 Apr 2019 22:06:41 -0700 Archived-At: Subject: [mpls] mpls - New Meeting Session Request for IETF 105 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 05:06:41 -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: 2 Length of Session(s): 1.5 Hours, 1 Hour Number of Attendees: 100 Conflicts to Avoid: First Priority: detnet bier pals idr bfd bess spring pce ccamp teas sfc Second Priority: lsr lsvr rtgwg rtgarea i2rs nvo3 People who must be present: Loa Andersson Deborah Brungard Nicolai Leymann Tarek Saad Resources Requested: Special Requests: Please have the 2 sessions back-to-back --------------------------------------------------------- From nobody Sun Apr 28 10:52:24 2019 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 A589F12013C; Sun, 28 Apr 2019 10:52:13 -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] 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 vRqzEVj-69gh; Sun, 28 Apr 2019 10:52:10 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 8C931120133; Sun, 28 Apr 2019 10:52:10 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3SHq8hs022058; Sun, 28 Apr 2019 18:52:08 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0792A2203B; Sun, 28 Apr 2019 18:52:08 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id E64FF2203A; Sun, 28 Apr 2019 18:52:07 +0100 (BST) Received: from LAPTOPK7AS653V ([87.112.228.68]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3SHq1PU026810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 28 Apr 2019 18:52:04 +0100 Reply-To: From: "Adrian Farrel" To: "'Mirja Kuehlewind'" Cc: "'The IESG'" , , , , References: <155238798836.13888.12133834062700877951.idtracker@ietfa.amsl.com> <001601d4d8d4$2808d1c0$781a7540$@olddog.co.uk> <35AA21D8-14B0-4AF3-A46C-A0349B7697FD@kuehlewind.net> <01ba01d4d99e$eade89e0$c09b9da0$@olddog.co.uk> <07ac01d4f213$bd8e5870$38ab0950$@olddog.co.uk> In-Reply-To: <07ac01d4f213$bd8e5870$38ab0950$@olddog.co.uk> Date: Sun, 28 Apr 2019 18:52:00 +0100 Organization: Old Dog Consulting Message-ID: <014401d4fdeb$182978e0$487c6aa0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFAhuvuBzGCp3DgpBA+VBQ9KaQwWAH98EEQAV9smssCTdfKAQHTVUoipz7OVQA= Content-Language: en-gb X-Originating-IP: 87.112.228.68 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24580.001 X-TM-AS-Result: No--17.930-10.0-31-10 X-imss-scan-details: No--17.930-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24580.001 X-TMASE-Result: 10--17.930000-10.000000 X-TMASE-MatchedRID: gTucSmrmRMPxIbpQ8BhdbFPjo7D4SFg4W3Tqgx/NSkragsZM0qVv17E+ hkhRyJ1V+OUof2MfXiwpatfqaFkR8YZMzyqfAL0kM8ORI7N4NZb6Vf9FxCgbYeQydRUvl3QTumO mEoLnrH92CujtLQ88TlfUsDLvDURgCiwghyPO0y6WLCkl1lq7BwO3/A5KGHP/x5B+7qLBJ+yE1R /r5rR1BUeExnThyzu+65F4rchkj9IEyPQwW5BBakcVayrW/N3ULC92/N1OWlm1eX0jEQ9c6m/dC SYQbVMyRaU9joqk/El44tAOfBQ77hoijc5u7FlQW7gz/Gbgpl4XalRvphFgrqq9wgXVNwtgxf6v D0EkW+Rsdoc6ogrCYE9e9pOPpmYxHVikQ9YmLLPH+dlQ+aycmYT+BRRrYvCUikvLPxTKpjgwJdc vGDLYlHYS95eqszr6Y4Iw0OZPviEV5bNTfdsFPHBRIrj8R47FF0R6C/1uGOqgVQtVkAwMvzEnVR xIYv4chi9aPuDGDCImwerKmsiW2YoNrmb7m9Z46vGX8vR+hqj429XtOfGeyg5SzgJNSArLuwhqy c+q/JDbHRNwz4EqnirIptD3BuobhPc4FTJN6V6cnm0v4tsY4zP168+pSrKCMKZRiezcUtP+GQFL LcthDRIS1zqZA+3ZE4T4B4zvjOhNTwBwYO28LxkLyT/TdtjlfS0Ip2eEHnzUHQeTVDUrIlNkM6v OVn5wdB0ntd9Tzp47AFczfjr/7KCf63PnzI+gIpyB/kmwRKFB9TARgT7KwDT7Kh0OK1jilsIPI3 ik7CU= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?mpls-sr-over-ip-03=3A_=28with_DISCUSS=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2019 17:52:14 -0000 Hi Mirja, I have been looking at your Discuss. It seems that at least one of the = referenced documents is hung up in the working group and is some way = from becoming an RFC. We tend not to like to write documents that (appear to) favour one of = the two IGPs, so I am not comfortable with the idea of making one IGP = normative and the other informative. I think the solution here is to = make the whole of section 3.1 just use the IGPs as an example (taking = out 2119 language and making it very clear that "other flooding = mechanisms are available"). I wanted to get your OK on this approach (it sounded from your reply = that you would be OK if the responsible AD was OK). I believe that, per = Alvaro's Discuss, we will also need some generic text to establish the = process divorced from any particular protocol mechanism. Thanks, Adrian -----Original Message----- From: Adrian Farrel =20 Sent: 13 April 2019 17:13 To: 'Mirja Kuehlewind' Cc: 'Mirja K=C3=BChlewind via Datatracker' ; 'The = IESG' ; mpls@ietf.org; loa@pi.nu; mpls-chairs@ietf.org; = draft-ietf-mpls-sr-over-ip@ietf.org Subject: RE: Mirja K=C3=BChlewind's Discuss on = draft-ietf-mpls-sr-over-ip-03: (with DISCUSS) Hi Mirja, Sorry to be a long time on this. It looks like your concerns around the various OSPF and ISIS drafts has = thrown up a "challenge". One of the references (draft-ietf-isis-encapsulation-cap) is missing in = action, and seems to have been abandoned. This will necessitate some work on the draft to abstract the mechanisms = described into general terms and avoid the need to reference at least = this one draft, and maybe all four of the IGP drafts. Thanks for your patience. Adrian -----Original Message----- From: Adrian Farrel =20 Sent: 13 March 2019 13:16 To: 'Mirja Kuehlewind' Cc: 'Mirja K=C3=BChlewind via Datatracker' ; 'The = IESG' ; mpls@ietf.org; loa@pi.nu; mpls-chairs@ietf.org; = draft-ietf-mpls-sr-over-ip@ietf.org Subject: RE: Mirja K=C3=BChlewind's Discuss on = draft-ietf-mpls-sr-over-ip-03: (with DISCUSS) Thanks Mirja, >>> 1) Given section 3.1, the following drafts all seems that they >>> should be normative references: ietf-isis-encapsulation-cap, >>> ietf-ospf-encapsulation-cap, ietf-ospf-segment-routing-extensions, >>> ietf-isis-segment-routing-extensions >>=20 >> Well, that wasn't the intention. It is meant to be an example of >> how the forwarding entries are constructed. >>=20 >> As it says at the top of Section 3... >> Note that the examples in >> Section 3.1 and Section 3.2 assume that OSPF or ISIS is enabled: in >> fact, other mechanisms of discovery and advertisement could be used >> including other routing protocols (such as BGP) or a central >> controller. >>=20 >> We could be more explicit in section 3.1 so that, for example... >>=20 >> OLD >> o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. >> Router E is SR-MPLS capable, so it advertises an SRGB as = described >> in [I-D.ietf-ospf-segment-routing-extensions] and >> [I-D.ietf-isis-segment-routing-extensions]. >> NEW >> o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. >> Router E is SR-MPLS capable, so it advertises an SRGB to the = other >> SR-MPLS capable routers. If an IGP is in use then Router E = behaves >> as described in [I-D.ietf-ospf-segment-routing-extensions] and >> [I-D.ietf-isis-segment-routing-extensions], but other mechanisms >> Could be applied. >> END >>=20 >> We'd need to make similar changes throughout the section. >>=20 >> Would such changes be enough for you? > > It still sounds to me that these document are basically a must read=20 > to understand the full picture. Do you think it would be a problem > or the wrong thing to make these reference normative? > > However, your wording change makes it definitely more clear that > this is only one example. If the wg and responsible ADs think, = it=E2=80=99s > the right thing to do to leave the reference informative, I will clear > my discuss. I was worried about the rate of progress of SR documents. There has been = a tendency for them to travel a little slowly. It looks like these documents have all now progressed far enough, but = they are caught up in a deadly cluster of missing references (cluster = 340). We'll have a look through the cluster to see how dangerous it is = and make normative references where we can. >>> 2) Sec 3.2.3 on IP Header fields should refer to RFC6040 for the ECN >>> field and eventually RFC2983 for DSCP. >>=20 >> That's good. Thanks. It gives us... >>=20 >> When encapsulating an = MPLS >> packet in UDP, the resulting packet is further = encapsulated in >> IP for transmission. IPv4 or IPv6 may be used according to = the >> capabilities of the network. The address fields are set as >> described in . The other IP = header >> fields (such as the ECN field , = the DSCP=20 >> code point , or IPv6 Flow Label) = on each >> UDP-encapsulated segment SHOULD be configurable according = to the >> operator's policy: they may be copied from the header = of the >> incoming packet; they may be promoted from the header of = the >> payload packet; they may be set according to instructions >> programmed to be associated with the SID; or they may be >> configured dependent on the outgoing interface and = payload. > > Yes, thanks! Perfect. It's in my working copy. Best, Adrian From nobody Sun Apr 28 13:38:06 2019 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 8ECA61200FE; Sun, 28 Apr 2019 13:37:57 -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] 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 gUHKKKZg9FOZ; Sun, 28 Apr 2019 13:37:55 -0700 (PDT) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 11E5D120089; Sun, 28 Apr 2019 13:37:54 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3SKblx8015489; Sun, 28 Apr 2019 21:37:52 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 63D972203C; Sun, 28 Apr 2019 21:37:52 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 4EB282203A; Sun, 28 Apr 2019 21:37:52 +0100 (BST) Received: from LAPTOPK7AS653V ([87.112.228.68]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3SKbonw006724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 28 Apr 2019 21:37:51 +0100 Reply-To: From: "Adrian Farrel" To: "'Benjamin Kaduk'" Cc: , , "'The IESG'" References: <07cc01d4f232$19436200$4bca2600$@olddog.co.uk> <20190420062140.GU51586@kduck.mit.edu> In-Reply-To: <20190420062140.GU51586@kduck.mit.edu> Date: Sun, 28 Apr 2019 21:37:50 +0100 Organization: Old Dog Consulting Message-ID: <016701d4fe02$3fd3c5a0$bf7b50e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJM5a1+ZtGjTh+JuRSQYSOhF4nciwIvuO3FpVCOHeA= Content-Language: en-gb X-Originating-IP: 87.112.228.68 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24580.002 X-TM-AS-Result: No--2.342-10.0-31-10 X-imss-scan-details: No--2.342-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24580.002 X-TMASE-Result: 10--2.341700-10.000000 X-TMASE-MatchedRID: oTBA/+sdKabxIbpQ8BhdbPHkpkyUphL9f6/Md8Lb2l+IDxaki6CTmOaN 0ZrIlpD2EIySkWAxpKpbr1chLToaD3XZ29PKwetsnhHKNOYbLL6vzXNI4No01UJqedX9vt/Ztx6 Lm/haEDwFpt9nAr6Q+a4Wv5s6vlQf3XkI6jWXY3StxpVfAE2l79ZKsq3DGpalT8iIY3QZ4pdb2X fqc6ksXxvMVWzt3AmLBRxbqCB9WeuqPs53eDBzubu9iqQJLR0vfS0Ip2eEHnwa2S8rkvtFcbDsz p3K5gqDjoczmuoPCq0CoGxQy/O2vkjZ2E8SUSL4gYmiyD2ka/xPyvIHDhMoIGTwbNFDoDdu/K+z LM5d+O9Acpvv65tU9VH8LIbsffKLGJPB7neDaqsl4nVYwIRGQa1+3JijYrAOMqmhG/M0o4/0MHw zu2JowBZt/2+KOWzz X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] Ben's Comments on draft-ietf-mpls-sr-over-ip X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2019 20:37:58 -0000 Hey Ben, >>> IP Header Fields: When encapsulating an MPLS packet in UDP, the >>> resulting packet is further encapsulated in IP for = transmission. >>> IPv4 or IPv6 may be used according to the capabilities of the >>> network. The address fields are set as described in Section 2. >>> >>> (Does Section 2 say how to set the source address?) >>=20 >> Sure does. >> The tunnel selected MUST have its >> remote end point (destination) address equal to the address of = the >> next SR-MPLS capable node along the path (i.e., the egress of = the >> active node segment). > > I might still be missing it. Is the idea that once you've selected a > specific tunnel, that naturally will have a record of the source = address > corresponding to that tunnel? (I only see a literal "remote end point > (destination) address" in the quoted text, i.e., "source" or "local" = do not > appear.) Sorry, I completely missed "source" in your question. Stupid of me. That needs clarifying in the document, you're quite right. The source address is set to an address of the encapsulating node. 7510 = gives further advice when the UDP zero-checksum mode is used.=20 This will show up in the next revision. Best, Adrian From nobody Tue Apr 30 00:54:58 2019 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 401E6120048; Tue, 30 Apr 2019 00:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-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] 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 YQfZl7IX7K0O; Tue, 30 Apr 2019 00:54:54 -0700 (PDT) Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (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 A5786120072; Tue, 30 Apr 2019 00:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1556610894; x=1588146894; h=from:to:cc:subject:date:message-id:mime-version; bh=GHsdGbRonJ1npdF9svgUyZw/Zjjb/Ws6BpRIvyIcDbA=; b=q6Kk7K7Fxd7dy8k92umkbBFxkzArlGFR6X2JaYd77eGdQjQMQmQzvLk0 sk72+DqsIwqrrC8nGfM8yLo026jEGsmt9yh0YltO3ynGEHdFB77JGU/iW PuHbnPVU3c6tJihQuGs3KnkbzfpHAFJEqJKVPh5+HbwdPI8/vO3PvulLe SO/IpiS/ATZZ4nV6iMdVx0lu8+Mn3VPYXlMMY5Lhk5C8HQMwFzPDsLNu/ lAo5N2d4xfLXFmzYsFwHgjIWNaMpibn2xLYMU9Ibg+H+wYihG9gHgcxog nHFVFRpvO9eCiV2EIHRGQ0NiUl8UumCV1BdvBbpiOtrKErx7MKzF9Dhyc w==; Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Apr 2019 09:54:47 +0200 X-IronPort-AV: E=Sophos;i="5.60,412,1549926000"; d="scan'208,217";a="277263793" X-MGA-submission: =?us-ascii?q?MDE4oelOkvvJCSrF41pQCjyZZ4ZdbvgL8mcWGM?= =?us-ascii?q?EAiVpukqMKBWlgocQR/r6LiZf1/dkrqc0bPzqkCVQQxU4glx9TOF+96C?= =?us-ascii?q?6gfBpaJS9dzN4FXWvblUnEZJQ7FCItpUUNW/EnqfLxNlubrOQyVfYXS3?= =?us-ascii?q?70R1pf6+1i8UbuSCakju+//Q=3D=3D?= Received: from he105715.emea1.cds.t-internal.com ([10.169.118.51]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/AES256-SHA; 30 Apr 2019 09:54:45 +0200 Received: from HE105665.EMEA1.cds.t-internal.com (10.169.118.62) by HE105715.emea1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Apr 2019 09:54:44 +0200 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE105665.EMEA1.cds.t-internal.com (10.169.118.62) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 30 Apr 2019 09:54:44 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.22) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Apr 2019 09:54:41 +0200 Received: from LEJPR01MB0377.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.20) by LEJPR01MB0380.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.15; Tue, 30 Apr 2019 07:54:44 +0000 Received: from LEJPR01MB0377.DEUPRD01.PROD.OUTLOOK.DE ([fe80::8093:9d6c:1465:3f1]) by LEJPR01MB0377.DEUPRD01.PROD.OUTLOOK.DE ([fe80::8093:9d6c:1465:3f1%3]) with mapi id 15.20.1835.018; Tue, 30 Apr 2019 07:54:44 +0000 From: To: CC: , Thread-Topic: IPR poll on draft-andersson-mpls-spl-terminology Thread-Index: AdT/KBRWbMXkJrtiSc613nUQk1T3SQ== Date: Tue, 30 Apr 2019 07:54:44 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=N.Leymann@telekom.de; x-originating-ip: [164.19.4.223] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4efd8129-b6cf-4482-c4bc-08d6cd411bc7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:LEJPR01MB0380; x-ms-traffictypediagnostic: LEJPR01MB0380: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(376002)(366004)(346002)(39860400002)(189003)(199004)(4326008)(74482002)(14454004)(66556008)(450100002)(66946007)(73956011)(68736007)(76116006)(478600001)(26005)(3846002)(790700001)(6116002)(71200400001)(53936002)(71190400001)(66476007)(256004)(72206003)(55016002)(86362001)(486006)(2906002)(66446008)(64756008)(186003)(9686003)(476003)(19627235002)(54896002)(6306002)(7696005)(52396003)(33656002)(54906003)(5660300002)(66066001)(81166006)(81156014)(97736004)(8676002)(102836004)(1730700003)(8936002)(2351001)(75402003)(5640700003)(7736002)(2501003)(316002)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:LEJPR01MB0380; H:LEJPR01MB0377.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: pKX/hWXvJm6nUyZKcyNGwahH8Ce7yiYZL25f5KgFovfYjwoZChG7brG4eZUdJRIxfBNfVelCNZcnNPXXHWGDfoY1GGwcAn5ZDzXROuTbXzehw87ty0ido9z4SMSpiGEDZR2MBovGZxrltyWpk57NIV+GQV1T/HnlgxsT5lrJ1sySdv+j4WbTKt0r4uBQEWZQoMMyRiftAoXTtfd7kcRhW88Jr9nlwmnotHOVgIzbAG7SUNkVuTcMVjW4HmfC0NpjFhhxXx1XuyVfgA6JGwLaXA97/qiLkhBzlvA2/iUtj1vGWnnqrHVMpHfZjh6FzjzssARwociUWwWs7Mc3SiW57xdRwfCaMFTXM5v6npPBD3HhnYmaj3g/S5EbYhvnKZAhLXBUbG7LRtdvkqEcBYUusEji/ZMApCgvDzDlclDKjQg= Content-Type: multipart/alternative; boundary="_000_LEJPR01MB0377E6C42A8591652A038006983A0LEJPR01MB0377DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4efd8129-b6cf-4482-c4bc-08d6cd411bc7 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2019 07:54:44.1548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0380 X-OriginatorOrg: telekom.de Archived-At: Subject: [mpls] IPR poll on draft-andersson-mpls-spl-terminology X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 07:54:57 -0000 --_000_LEJPR01MB0377E6C42A8591652A038006983A0LEJPR01MB0377DEUP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group, authors, We have started to prepare draft-andersson-mpls-spl-terminology for working= group adoption, prior to the WGAP we need to do an IPR poll. This mail starts this IPR poll. Are you aware of any IPR that applies to draft-andersson-mpls-spl-terminolo= gy? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). There no IPR disclosures against draft-andersson-mpls-spl-terminology. If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. *Th= e 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 con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Regards Nic --_000_LEJPR01MB0377E6C42A8591652A038006983A0LEJPR01MB0377DEUP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Working Group, authors,=

 

We have started to prepare d= raft-andersson-mpls-spl-terminology for working group adoption, prior to th= e WGAP we need to do an IPR poll.

 

This mail starts this IPR po= ll.

 

Are you aware of any IPR tha= t applies to draft-andersson-mpls-spl-terminology?

 

If so, has this IPR been dis= closed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 537= 8 for more details).

 

There no IPR disclosures aga= inst draft-andersson-mpls-spl-terminology.

 

If you are listed as a docum= ent author or contributor please respond to this email regardless of whethe= r 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 em= ail list but are not listed as an author or contributor, then please explic= itly respond only if you are aware of any IPR that has not yet been disclos= ed in conformance with IETF rules.

 

Regards

 

Nic

 

--_000_LEJPR01MB0377E6C42A8591652A038006983A0LEJPR01MB0377DEUP_-- From nobody Tue Apr 30 01:34:41 2019 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 22F0C120232; Tue, 30 Apr 2019 01:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-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, 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 WO7Mah2WYXsr; Tue, 30 Apr 2019 01:34:37 -0700 (PDT) Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (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 ECDC8120226; Tue, 30 Apr 2019 01:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1556613277; x=1588149277; h=from:to:cc:subject:date:message-id:mime-version; bh=w5EdLPCgkd/uDfSoeZ9Rk/WG6SGOy54wMDiVkoOyXLk=; b=Kfnut1XUIzzJsmA+JmU/99pm2Y2bwCpbgddxd6dOUOtBdfj0SlLzVZjQ HXFwTVYlqNBiSvjWesG5ohGQzv5rLcWptu233Urdfz4LjXQv3z78FSF0i SZc/JPskVy5ifeKpB0gxECBlk0nUfsAnogpCjf5HN3R11dwQ6sZd1F/bH ryAyaQa9xJBxU+pCvGqutNrPmu6OVDbJO0MA5cHiMohlsNYFTY9SgaBDU JXLko6IHuon9D9x4t9mOMNuzXwVpV8vRH1oXUlTvuhu/0b6fDT//wCiaS cFJz8A3xLbfAilgTtV3stIgsoiFG07mRiPynSul+dUEO9rya+K/DIUBMi g==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Apr 2019 10:34:33 +0200 X-MGA-submission: =?us-ascii?q?MDEyqtVUqW6pxcjBNVeoawZJjX6F7990HC6/HG?= =?us-ascii?q?oY9/QPHTkMHMu7RPuTUmyhPDp2SXNoeWKWNUoOSbtTQk/hMFX2ewCtIc?= =?us-ascii?q?ECQYmH3J14ZgQ8x7KCS0BfOmhUyF9+9wdVbwHDwH/nEGDWUa4yLmMajn?= =?us-ascii?q?fy3GqxS1SCf5k40/qACkA4zg=3D=3D?= Received: from he199745.emea1.cds.t-internal.com ([10.169.119.53]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 30 Apr 2019 10:33:32 +0200 Received: from HE105651.EMEA1.cds.t-internal.com (10.169.119.62) by HE199745.emea1.cds.t-internal.com (10.169.119.53) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Apr 2019 10:33:32 +0200 Received: from HE104163.emea1.cds.t-internal.com (10.171.40.38) by HE105651.EMEA1.cds.t-internal.com (10.169.119.62) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 30 Apr 2019 10:33:31 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.19) by O365mail05.telekom.de (172.30.0.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Apr 2019 10:33:32 +0200 Received: from LEJPR01MB0377.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.20) by LEJPR01MB0377.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.15; Tue, 30 Apr 2019 08:33:31 +0000 Received: from LEJPR01MB0377.DEUPRD01.PROD.OUTLOOK.DE ([fe80::8093:9d6c:1465:3f1]) by LEJPR01MB0377.DEUPRD01.PROD.OUTLOOK.DE ([fe80::8093:9d6c:1465:3f1%3]) with mapi id 15.20.1835.018; Tue, 30 Apr 2019 08:33:31 +0000 From: To: , CC: Thread-Topic: Working Group Last Call on draft-ietf-mpls-summary-frr-rsvpte Thread-Index: AdT+bwgaLxlixEv3RLuInt5op2U5Cg== Date: Tue, 30 Apr 2019 08:33:31 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=N.Leymann@telekom.de; x-originating-ip: [164.19.4.223] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7291a374-82f5-4dab-8d14-08d6cd4686bb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:LEJPR01MB0377; x-ms-traffictypediagnostic: LEJPR01MB0377: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39860400002)(396003)(366004)(346002)(376002)(136003)(189003)(199004)(97736004)(4743002)(64756008)(66476007)(450100002)(7736002)(102836004)(186003)(2501003)(26005)(4326008)(86362001)(68736007)(66066001)(76116006)(66446008)(66556008)(790700001)(4744005)(66946007)(3846002)(74482002)(6116002)(71200400001)(73956011)(71190400001)(8676002)(81166006)(19627235002)(256004)(72206003)(81156014)(9686003)(55016002)(6306002)(14454004)(316002)(33656002)(236005)(110136005)(486006)(75402003)(53936002)(52396003)(5660300002)(478600001)(2906002)(7696005)(8936002)(54896002)(476003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEJPR01MB0377; H:LEJPR01MB0377.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: sbtbK3T6N1xZivbQk4bEYodNNlxmjozhDLr85/fhMpE/MZocucviO3O1V74GpSaqlSInygT17SbuxCUA2dGZend57cMaP489zGX7jbto2n/ojWv1I483drjGS3bVztqkpDX6+O+1EgH9H8zEn5P9JWycLvGtsY/Mcxr58tVH3YTJDKdwFvAs/aepHQgV2/Tozk6ji5FHaWfLaDnQynFjz33L4eyU5k5Pe76Ms+Bq7l927lwfj+o2db2x8klelx97bKUpTcdzia2WpLXfcHSIvZsuTxQigsDIVjrf8V9VgBzm/+9GtroKlIAwAZz2EkqftW6sky+9ZISeEkOl2qiVk5IFX3yDSL+1fjgWw3Xgi/ri3OzWud9tlXAo8vX8KvE0AOC3E+n6AYTIYAba/e+jQ8pjlTsufh9Swquj3MW8i1U= Content-Type: multipart/alternative; boundary="_000_LEJPR01MB0377540FAEC1EE9448740E78983A0LEJPR01MB0377DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7291a374-82f5-4dab-8d14-08d6cd4686bb X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2019 08:33:31.0406 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0377 X-OriginatorOrg: telekom.de Archived-At: Subject: [mpls] Working Group Last Call on draft-ietf-mpls-summary-frr-rsvpte X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 08:34:40 -0000 --_000_LEJPR01MB0377540FAEC1EE9448740E78983A0LEJPR01MB0377DEUP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group, This mail initiates the two weeks working group last call on draft-ietf-mpl= s-summary-frr-rsvpte which is considered mature and ready for a final worki= ng group review. Please read this document if you haven't read the most recent version yet, = and send your comments to the mpls wg mailing list (mpls@ietf.org), not later than 17th of May. There is one IPR disclosure against draft-ietf-mpls-summary-frr-rsvpte This working group last call ends May 17th, 2019 (there is at least in some= countries a public holiday this week, therefore the call is a bit longer t= han usual). Best regards Nic --_000_LEJPR01MB0377540FAEC1EE9448740E78983A0LEJPR01MB0377DEUP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Working Group,

 

This mail initiates the two = weeks working group last call on draft-ietf-mpls-summary-frr-rsvpte which= is considered mature and ready for a final working group review.

 

Please read this document if= you haven't read the most recent version yet, and send your comments to th= e mpls wg mailing list (mpls@ietf.org), not later than 17th of May.

 

There is one IPR disclosure = against draft-ietf-mpls-summary-frr-rsvpte

 

This working group last call= ends May 17th, 2019 (there is at least in some countries a public holiday = this week, therefore the call is a bit longer than usual).

 

Best regards

 

Nic

--_000_LEJPR01MB0377540FAEC1EE9448740E78983A0LEJPR01MB0377DEUP_-- From nobody Tue Apr 30 03:11:12 2019 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 A9308120296; Tue, 30 Apr 2019 03:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 90YmkUKPrLwt; Tue, 30 Apr 2019 03:11:09 -0700 (PDT) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 1B33B12028A; Tue, 30 Apr 2019 03:11:08 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3UAB58W015505; Tue, 30 Apr 2019 11:11:05 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8207822042; Tue, 30 Apr 2019 11:11:05 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 761272204C; Tue, 30 Apr 2019 11:11:05 +0100 (BST) Received: from LAPTOPK7AS653V ([87.112.228.68]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x3UAB4Lp027018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Apr 2019 11:11:04 +0100 Reply-To: From: "Adrian Farrel" To: , Cc: , References: In-Reply-To: Date: Tue, 30 Apr 2019 11:11:02 +0100 Organization: Old Dog Consulting Message-ID: <029701d4ff3d$04ab2540$0e016fc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0298_01D4FF45.666F8D40" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI0GyTttIk2XH6Lg35SnnfbtNGbIKWWQn9g Content-Language: en-gb X-Originating-IP: 87.112.228.68 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24582.006 X-TM-AS-Result: No--24.847-10.0-31-10 X-imss-scan-details: No--24.847-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24582.006 X-TMASE-Result: 10--24.847400-10.000000 X-TMASE-MatchedRID: gzVbiXtWD9vxIbpQ8BhdbGzBijri5+RVbv16+gil4jdoYDoakaUh1MWg mIw8xvFebrgUJ4CnqHiqEjHR8FX3BS3F56OiNwp/b8JTZf0kEzvqe8CwJZFGUZTVN3FiLkyog0T HjI2jZEVUNb4KGOm2sCw8LAwMBGLbnPecQ/hKOMCprpImTnz4to7vhl9PIBCwCVuEXtlNqcvuc/ n71nc6DRuHs1ba36aMzhZguZB9diZzjLovRKWwwu9VsdrlGzy3Q6/DFZugyt27/NQTVI1I+cbK+ pu0ZYwRBHVm0xh58VY8LuP+bOkMWt3jF2fVcPdzDB+ErBr0bANar2Wff4KSIaUXswX/xrIS1BoO 0FXL0sjuDNx+Tk7mC2JdCNPFSfXrp3Cwl7p83YsSDAzxRL+lMZkShYcLpGH9BL+V9lD389FL/hr /YMmS/27Wbor+4y0FrlH1qheKYcDBp2db7m7iUQ6w00GeWBFafS0Ip2eEHnyvXSmSdlcYmsnjLT A/UDoAHwAqApZ40aHQqQhSw0x2VOJGF26G8SWypfzLa08EuFD1SgS9RingR8pZgmM1KlIW5o7av otHrRM7kJjgLtPKdqID+lQLXr0x X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] IPR poll on draft-andersson-mpls-spl-terminology X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 10:11:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0298_01D4FF45.666F8D40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Nic, I am not aware of any IPR applicable to this document. Thanks, Adrian From: N.Leymann@telekom.de Sent: 30 April 2019 08:55 To: mpls@ietf.org Cc: draft-andersson-mpls-spl-terminology@ietf.org; mpls-chairs@ietf.org Subject: IPR poll on draft-andersson-mpls-spl-terminology Working Group, authors, We have started to prepare draft-andersson-mpls-spl-terminology for working group adoption, prior to the WGAP we need to do an IPR poll. This mail starts this IPR poll. Are you aware of any IPR that applies to draft-andersson-mpls-spl-terminology? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There no IPR disclosures against draft-andersson-mpls-spl-terminology. 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. Regards Nic ------=_NextPart_000_0298_01D4FF45.666F8D40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Nic,

 

I am not = aware of any IPR applicable to this document.

 

Thanks,

Adrian

 

From: N.Leymann@telekom.de = <N.Leymann@telekom.de>
Sent: 30 April 2019 = 08:55
To: mpls@ietf.org
Cc: = draft-andersson-mpls-spl-terminology@ietf.org; = mpls-chairs@ietf.org
Subject: IPR poll on = draft-andersson-mpls-spl-terminology

 

Working Group, authors,

 

We have started to prepare = draft-andersson-mpls-spl-terminology for working group adoption, prior = to the WGAP we need to do an IPR poll.

 

This mail starts this IPR = poll.

 

Are you aware of any IPR that applies to = draft-andersson-mpls-spl-terminology?

 

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

 

There no IPR disclosures against = draft-andersson-mpls-spl-terminology.

 

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.

 

Regards

 

Nic

 

------=_NextPart_000_0298_01D4FF45.666F8D40-- From nobody Tue Apr 30 04:17:15 2019 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 044A8120104; Tue, 30 Apr 2019 04:17:14 -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, 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 ylR8mg2YdgBm; Tue, 30 Apr 2019 04:17:11 -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 58250120006; Tue, 30 Apr 2019 04:17:11 -0700 (PDT) Received: from [192.168.1.8] (unknown [119.94.164.49]) (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 C738933F5AF; Tue, 30 Apr 2019 13:17:06 +0200 (CEST) To: adrian@olddog.co.uk, N.Leymann@telekom.de, mpls@ietf.org Cc: draft-andersson-mpls-spl-terminology@ietf.org, mpls-chairs@ietf.org References: <029701d4ff3d$04ab2540$0e016fc0$@olddog.co.uk> From: Loa Andersson Message-ID: <2f83860d-fd52-8f70-052b-7602f5488da9@pi.nu> Date: Tue, 30 Apr 2019 19:16:19 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <029701d4ff3d$04ab2540$0e016fc0$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] IPR poll on draft-andersson-mpls-spl-terminology X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 11:17:14 -0000 Nic, I'm not aware of any IPR applicable to this ID. /Loa On 2019-04-30 18:11, Adrian Farrel wrote: > Hi Nic, > > I am not aware of any IPR applicable to this document. > > Thanks, > > Adrian > > *From:*N.Leymann@telekom.de > *Sent:* 30 April 2019 08:55 > *To:* mpls@ietf.org > *Cc:* draft-andersson-mpls-spl-terminology@ietf.org; mpls-chairs@ietf.org > *Subject:* IPR poll on draft-andersson-mpls-spl-terminology > > Working Group, authors, > > We have started to prepare draft-andersson-mpls-spl-terminology for > working group adoption, prior to the WGAP we need to do an IPR poll. > > This mail starts this IPR poll. > > Are you aware of any IPR that applies to > draft-andersson-mpls-spl-terminology? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > There no IPR disclosures against draft-andersson-mpls-spl-terminology. > > 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. > > Regards > > Nic > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Tue Apr 30 06:51:37 2019 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 BC1F7120077; Tue, 30 Apr 2019 06:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, 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=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 BU0pLjhBaLo8; Tue, 30 Apr 2019 06:51:34 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 5826912001B; Tue, 30 Apr 2019 06:51:34 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3UDdpEF019632; Tue, 30 Apr 2019 06:51:31 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=x+vbwaP9uHMVh5AD47Dpd/mcNrZfZz8oShQAsNMylIs=; b=1+WN7jYuP/qfGGZr7wO7POjTGp91PzkWMowgqp5Mhkqiq2XI2QjOY0hBLm8PVmWOI2NE tn5Sgy32EuXXk03rKZO3is8HDgmOpOH3wm7eT7funyfdINaznssMuY9pGkKRMWuWYX5k D88Oai6Jjq+KWOXdKh1Pfd+oVJdaFEXAlyXXGIAmOFmgts8XORX1t0RGMx9IIaRWzGMz auqTbvueLM5AwlEj5ysW1jhvGHreavPUwxSSLw7SX4n7FwjCZGZusFs2TCMN3YwgC4K2 pcAGlFc4AyJuNL7gnD6J/ptQ+Q9Dps4qFNzUuajNP5H/dnY9PLSUarG6vs3QiuwLLYht jA== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp2055.outbound.protection.outlook.com [104.47.41.55]) by mx0b-00273201.pphosted.com with ESMTP id 2s6kn8gcfa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 30 Apr 2019 06:51:30 -0700 Received: from BYAPR05MB4565.namprd05.prod.outlook.com (52.135.204.10) by BYAPR05MB6694.namprd05.prod.outlook.com (20.178.235.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.10; Tue, 30 Apr 2019 13:51:28 +0000 Received: from BYAPR05MB4565.namprd05.prod.outlook.com ([fe80::79c3:e30:c40:d505]) by BYAPR05MB4565.namprd05.prod.outlook.com ([fe80::79c3:e30:c40:d505%5]) with mapi id 15.20.1856.008; Tue, 30 Apr 2019 13:51:28 +0000 From: Kireeti Kompella To: "N.Leymann@telekom.de" CC: "mpls@ietf.org" , "draft-andersson-mpls-spl-terminology@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: IPR poll on draft-andersson-mpls-spl-terminology Thread-Index: AdT/KBRWbMXkJrtiSc613nUQk1T3SQAM7rD4 Date: Tue, 30 Apr 2019 13:51:28 +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: [74.121.221.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5f6163e3-7fe3-43f0-8d37-08d6cd72f1bd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB6694; x-ms-traffictypediagnostic: BYAPR05MB6694: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(366004)(39860400002)(136003)(189003)(199004)(6436002)(229853002)(6486002)(14454004)(97736004)(478600001)(316002)(2906002)(25786009)(4326008)(54906003)(19627235002)(76176011)(54896002)(99286004)(6916009)(7736002)(86362001)(33656002)(6512007)(53936002)(6246003)(236005)(102836004)(256004)(2351001)(6506007)(53546011)(186003)(26005)(66066001)(11346002)(68736007)(5660300002)(82746002)(446003)(64756008)(83716004)(2616005)(476003)(71200400001)(486006)(6116002)(790700001)(66556008)(71190400001)(3846002)(2501003)(8676002)(5640700003)(36756003)(81166006)(73956011)(81156014)(66946007)(66476007)(76116006)(91956017)(66446008)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB6694; H:BYAPR05MB4565.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QKPfa/IWXUXr3NEUjcExJIOW6L/iALxEDb0t/+xcL3jCoyG6kkayaaosEr3qDoAap2moYrf27p75iApPWaTBVYBxeYanVXKDsCkZtoIgT5hLwAcE3t5R044J0sS+cNZUIR98oRPtEn5qYTj1FDFRQ5v1IIpcWc36hlJyB8gHG3gh+jkoZUD2RWyvG/XbXTN4gCWeBLIUGuQ3xpj4crmRI0zcwUV8aGhv6NQ5fK5WBxF797y9ZqBi0zl/ll+qcJM1JdxgPjdLSKiHMAamyE+guyRWQdc9Go2sMFvWa8VnPtilk4NC9w/AQJ7Useyv/AQbc0IbS7YpaqYFpQUx8X7UEkYdEh2oiVKvq/vWe+8j3J60UsE3rIBqjNubolfZKS9lGxheKa6x7MLh1NYEJrfjSijpXmZY4K6DiAeP4vHeGEU= Content-Type: multipart/alternative; boundary="_000_ADE3D449529A4C3C9B4FFBFCDA3D96AEjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 5f6163e3-7fe3-43f0-8d37-08d6cd72f1bd X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2019 13:51:28.4261 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6694 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-30_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=786 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904300088 Archived-At: Subject: Re: [mpls] IPR poll on draft-andersson-mpls-spl-terminology X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 13:51:36 -0000 --_000_ADE3D449529A4C3C9B4FFBFCDA3D96AEjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IGF3YXJlIG9mIGFueSB1bmRpc2Nsb3NlZCBJUFIgcmVsZXZhbnQgdG8gdGhpcyBkcmFmdC4N Cg0KS2lyZWV0aQ0KDQpPbiBBcHIgMzAsIDIwMTksIGF0IDAzOjU1LCAiTi5MZXltYW5uQHRlbGVr b20uZGU8bWFpbHRvOk4uTGV5bWFubkB0ZWxla29tLmRlPiIgPE4uTGV5bWFubkB0ZWxla29tLmRl PG1haWx0bzpOLkxleW1hbm5AdGVsZWtvbS5kZT4+IHdyb3RlOg0KDQoNCldvcmtpbmcgR3JvdXAs IGF1dGhvcnMsDQoNCg0KDQpXZSBoYXZlIHN0YXJ0ZWQgdG8gcHJlcGFyZSBkcmFmdC1hbmRlcnNz b24tbXBscy1zcGwtdGVybWlub2xvZ3kgZm9yIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24sIHByaW9y IHRvIHRoZSBXR0FQIHdlIG5lZWQgdG8gZG8gYW4gSVBSIHBvbGwuDQoNCg0KDQpUaGlzIG1haWwg c3RhcnRzIHRoaXMgSVBSIHBvbGwuDQoNCg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhh dCBhcHBsaWVzIHRvIGRyYWZ0LWFuZGVyc3Nvbi1tcGxzLXNwbC10ZXJtaW5vbG9neT8NCg0KDQoN CklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElF VEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3Jl IGRldGFpbHMpLg0KDQoNCg0KVGhlcmUgbm8gSVBSIGRpc2Nsb3N1cmVzIGFnYWluc3QgZHJhZnQt YW5kZXJzc29uLW1wbHMtc3BsLXRlcm1pbm9sb2d5Lg0KDQoNCg0KSWYgeW91IGFyZSBsaXN0ZWQg YXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhp cyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55 IHJlbGV2YW50IElQUi4gKlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBNUExT IFdHIG1haWxpbmcgbGlzdC4qIFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBu ZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1 dGhvciBhbmQgY29udHJpYnV0b3IuDQoNCg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBNUExTIFdHIGVt YWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwg dGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZiBh bnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0 aCBJRVRGIHJ1bGVzLg0KDQoNCg0KUmVnYXJkcw0KDQoNCg0KTmljDQoNCg== --_000_ADE3D449529A4C3C9B4FFBFCDA3D96AEjunipernet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpO b3QgYXdhcmUgb2YgYW55IHVuZGlzY2xvc2VkIElQUiByZWxldmFudCB0byB0aGlzIGRyYWZ0LiZu YnNwOzxicj4NCjxicj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSIgZGlyPSJsdHIiPktp cmVldGk8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCk9uIEFwciAzMCwgMjAxOSwgYXQgMDM6 NTUsICZxdW90OzxhIGhyZWY9Im1haWx0bzpOLkxleW1hbm5AdGVsZWtvbS5kZSI+Ti5MZXltYW5u QHRlbGVrb20uZGU8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Ti5MZXltYW5uQHRlbGVr b20uZGUiPk4uTGV5bWFubkB0ZWxla29tLmRlPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9k aXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPg0KPG1ldGEgbmFt ZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVt KSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBk aXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiTnVyIFRleHQgWmNobiI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2Ux Nw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5OdXJUZXh0WmNobg0K CXttc28tc3R5bGUtbmFtZToiTnVyIFRleHQgWmNobiI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJOdXIgVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+V29ya2luZyBHcm91cCwg YXV0aG9ycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPldlIGhhdmUgc3RhcnRlZCB0byBwcmVw YXJlIGRyYWZ0LWFuZGVyc3Nvbi1tcGxzLXNwbC10ZXJtaW5vbG9neSBmb3Igd29ya2luZyBncm91 cCBhZG9wdGlvbiwgcHJpb3IgdG8gdGhlIFdHQVAgd2UgbmVlZCB0byBkbyBhbiBJUFIgcG9sbC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgbWFpbCBzdGFydHMgdGhpcyBJUFIgcG9sbC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFw cGxpZXMgdG8gZHJhZnQtYW5kZXJzc29uLW1wbHMtc3BsLXRlcm1pbm9sb2d5PzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+SWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21w bGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5k IDUzNzggZm9yIG1vcmUgZGV0YWlscykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGVyZSBu byBJUFIgZGlzY2xvc3VyZXMgYWdhaW5zdCBkcmFmdC1hbmRlcnNzb24tbXBscy1zcGwtdGVybWlu b2xvZ3kuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRv Y3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWls IHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZh bnQgSVBSLiAqVGhlIHJlc3BvbnNlIG5lZWRzIHRvIGJlIHNlbnQgdG8gdGhlIE1QTFMgV0cgbWFp bGluZyBsaXN0LiogVGhlIGRvY3VtZW50DQogd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBz dGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3Ig YW5kIGNvbnRyaWJ1dG9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SWYgeW91IGFyZSBvbiB0 aGUgTVBMUyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3Ig Y29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBh cmUgYXdhcmUgb2YgYW55IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNv bmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2Fy ZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5pYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_ADE3D449529A4C3C9B4FFBFCDA3D96AEjunipernet_-- From nobody Tue Apr 30 22:27:03 2019 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 0396A1200C5; Tue, 30 Apr 2019 22:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWk3y9k8KXpl; Tue, 30 Apr 2019 22:26:53 -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 5F77B12001E; Tue, 30 Apr 2019 22:26:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 980EFB81E03; Tue, 30 Apr 2019 22:26:41 -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 Content-type: text/plain; charset=UTF-8 Message-Id: <20190501052641.980EFB81E03@rfc-editor.org> Date: Tue, 30 Apr 2019 22:26:41 -0700 (PDT) Archived-At: Subject: [mpls] =?utf-8?q?RFC_8577_on_Signaling_RSVP-TE_Tunnels_on_a_Shar?= =?utf-8?q?ed_MPLS_Forwarding_Plane?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 05:26:55 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8577 Title: Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane Author: H. Sitaraman, V. Beeram, T. Parikh, T. Saad Status: Standards Track Stream: IETF Date: April 2019 Mailbox: harish.ietf@gmail.com, vbeeram@juniper.net, tejal.parikh@verizon.com, tsaad.net@gmail.com Pages: 24 Characters: 50113 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-rsvp-shared-labels-09.txt URL: https://www.rfc-editor.org/info/rfc8577 DOI: 10.17487/RFC8577 As the scale of MPLS RSVP-TE networks has grown, the number of Label Switched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in the amount of control-plane state information. However, those changes have had no effect on the number of labels that a transit Label Switching Router (LSR) has to support in the forwarding plane. That number is governed by the number of LSPs transiting or terminated at the LSR and is directly related to the total LSP state in the control plane. This document defines a mechanism to prevent the maximum size of the label space limit on an LSR from being a constraint to control-plane scaling on that node. It introduces the notion of preinstalled 'per-TE link labels' that can be shared by MPLS RSVP-TE LSPs that traverse these TE links. This approach significantly reduces the forwarding-plane state required to support a large number of LSPs. This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing (SR) MPLS forwarding plane. 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