Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT)
Alvaro Retana <aretana.ietf@gmail.com> Mon, 01 April 2019 15:15 UTC
Return-Path: <aretana.ietf@gmail.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 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 <aretana.ietf@gmail.com>
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2928FD2A8@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>
MIME-Version: 1.0
Date: Mon, 01 Apr 2019 11:15:05 -0400
Message-ID: <CAMMESszK8ozAXBVy3PDY2A8Ymb3jF7NuBR6gvQ8xLbpS1a+WEw@mail.gmail.com>
To: Mach Chen <mach.chen@huawei.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>
Content-Type: multipart/alternative; boundary="0000000000004ad3990585797c7f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/9UVImDkfrtcDcCWJKfDFss-Nvqw>
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: Mon, 01 Apr 2019 15:15:30 -0000
On March 14, 2019 at 2:33:44 AM, Mach Chen (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… Thanks! Alvaro.
- [mpls] Alvaro Retana's No Objection on draft-ietf… Alvaro Retana via Datatracker
- Re: [mpls] Alvaro Retana's No Objection on draft-… Mach Chen
- Re: [mpls] Alvaro Retana's No Objection on draft-… Alvaro Retana
- Re: [mpls] Alvaro Retana's No Objection on draft-… Loa Andersson
- Re: [mpls] Alvaro Retana's No Objection on draft-… Mach Chen
- Re: [mpls] Alvaro Retana's No Objection on draft-… Alvaro Retana
- Re: [mpls] Alvaro Retana's No Objection on draft-… Mach Chen
- Re: [mpls] Alvaro Retana's No Objection on draft-… Alvaro Retana
- Re: [mpls] Alvaro Retana's No Objection on draft-… Mach Chen