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.