Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT)

Mach Chen <mach.chen@huawei.com> Tue, 02 April 2019 02:42 UTC

Return-Path: <mach.chen@huawei.com>
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 <mach.chen@huawei.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
CC: "mpls@ietf.org" <mpls@ietf.org>, The IESG <iesg@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "draft-ietf-mpls-lsp-ping-lag-multipath@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, 02 Apr 2019 02:42:23 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE29298896E@dggeml510-mbx.china.huawei.com>
References: <155208210011.3264.12148702952456660789.idtracker@ietfa.amsl.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2928FABB2@dggeml510-mbx.china.huawei.com> <CAMMESswBNuY2y6dQsdy=zL6k8kpYG3CJ4N5oEwtZgBTAnLpTDg@mail.gmail.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2928FD2A8@dggeml510-mbx.china.huawei.com> <CAMMESszK8ozAXBVy3PDY2A8Ymb3jF7NuBR6gvQ8xLbpS1a+WEw@mail.gmail.com>
In-Reply-To: <CAMMESszK8ozAXBVy3PDY2A8Ymb3jF7NuBR6gvQ8xLbpS1a+WEw@mail.gmail.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: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29298896Edggeml510mbxchi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/2FJC4zMzARE25XMer7wJiSXhiIU>
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 <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2019 02:42:34 -0000

Hi Alvaro,

Thanks for your suggestion!

Please see my reply inline(with Mach 1)…

From: Alvaro Retana [mailto:aretana.ietf@gmail.com]
Sent: Monday, April 01, 2019 11:15 PM
To: Mach Chen <mach.chen@huawei.com>
Cc: mpls@ietf.org; The IESG <iesg@ietf.org>; mpls-chairs@ietf.org; draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org
Subject: RE: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT)

On March 14, 2019 at 2:33:44 AM, Mach Chen (mach.chen@huawei.com<mailto:mach.chen@huawei.com>) wrote:

Mach:

...
> (2) §6: "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." 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 §3 and §3.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…. 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 §6 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…



[Mach 1] To align with the TLV definition as defined in RFC8209 (e.g., Downstream Detailed Mapping TLV, it has the same situation as this “LSR Capability TLV”), it defines as:
3.4<https://tools.ietf.org/html/rfc8029#section-3.4>.  Downstream Detailed Mapping TLV
   The Downstream Detailed Mapping object is a TLV that MAY be included
   in an MPLS echo request message.

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 “Downstream Detailed Mapping TLV” does,  :

   This document defines a new TLV (RFC8029, Section 3) which is

   referred to as the "LSR Capability TLV.  It MAY be included…

And the IANA section will be updated as:

“The IANA is requested to assign new value TBD1 (from the range 4-16383) for LSR Capability TLV from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry.”

Thanks ,

Mach



Thanks!

Alvaro.