Re: [Technical Errata Reported] RFC5884 (5085)

Greg Mirsky <gregimirsky@gmail.com> Wed, 04 October 2017 23:26 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D818B1332E1; Wed, 4 Oct 2017 16:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9hSoqwb3RMq; Wed, 4 Oct 2017 16:26:27 -0700 (PDT)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 7079F1332D7; Wed, 4 Oct 2017 16:26:26 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id q132so15101126lfe.5; Wed, 04 Oct 2017 16:26:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7GBNEnTZFMMJU6bFVZKNjL2nSHU17F38RgeiiGuaVms=; b=Tx3mcLcdITZRba8uifcR2d6W5U0JiRC5NsZsBaaxklZlHUkIwX6/PglCpsKl6fqqPK n44sBifKWH0hUTtyv4I2ucPJVdRumujGDzvJdwdKOJxzaPUzqmk8x+F/2RC5d4z+bIvk u/SmpTWdqHWzEm3LpafsV5i626wqaSgCnhVfZWwwMcwHpH/63o8f0gqzTgJDG11rwlnA hBfqdK3HOLN+MpPU2i1X78Mx5+Rm/28b4joBQrBkGOGN7qKpuZ8DFvc27GT0TfzDcQT1 Ui1tGqJUNTs58/RKs0Hk8/uKl/FfKP7jHWgJivh13AccnK6XYGtA78y3KfgHd++xhaGv tbcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7GBNEnTZFMMJU6bFVZKNjL2nSHU17F38RgeiiGuaVms=; b=sUa+09vcmkmvrjPty2J3Kt2Zb53+XwUjytjoo8+2/hMJV1A91FYXpge62WYTBARRbh iHPMc5X5cyDpiWc2vQ6llZZp7Xz32UUZ5TFpOR1mUeAngjNrCmKmie0GoN9dvokhvtf4 FmpYSDxulES1QSWyiBZuP7I/Y7xCyRbSrEhQR3bcVUmx79g3Lw9qjgJ4L9hZGJTksucL td3F0ZYsP7Welq4XQC5/9I9XdDIpJshF5LJi/aP8aqo9hHlO0Q/R9KSjennjJuSHTPuN 2JZ1CxNmAPwFr2ZYDgNs0vIJOVh9rwwlj8zsRSBBqQYpegPJte/Tfs8sL2MLmKbNE061 qrtw==
X-Gm-Message-State: AMCzsaXig/UHJjpomjD6FRp3+z9xI/yyahXXsKeMlgK21Gs6d5nU9LxM K3ztfF5sZITmv6Ii8qrKrG72Pe+er7ISXQJBnvI=
X-Google-Smtp-Source: AOwi7QAoE3kAOwQqcjDrLXOp9zDnEKJOKZeNQ8WZfr0/vtVNZF9PwHYw8rxvlZJCiacPdDogavts5PoAE73z8ZrgduE=
X-Received: by 10.25.29.213 with SMTP id d204mr6096295lfd.47.1507159584426; Wed, 04 Oct 2017 16:26:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.3.10 with HTTP; Wed, 4 Oct 2017 16:26:23 -0700 (PDT)
In-Reply-To: <0cefc1ddee8e4e77b56392095cc8d2d7@XCH-ALN-001.cisco.com>
References: <20170811053550.27303B81263@rfc-editor.org> <20170811173930.GJ24942@pfrc.org> <E2844FE2-9C88-4410-A7A2-7F8AE0567E78@cisco.com> <CA+RyBmU13-Ba2mDROiWtV4Aai_rtZDZ7PzEK0GGgE+ESa9JTNQ@mail.gmail.com> <7501E817-C95E-410A-A91E-080B36B213BE@cisco.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE29187C3DD@dggeml508-mbx.china.huawei.com> <4bb63466962c4957a594e73163329940@XCH-ALN-001.cisco.com> <3D83F334-5ABC-4CD3-AF14-5D4537671D19@juniper.net> <0cefc1ddee8e4e77b56392095cc8d2d7@XCH-ALN-001.cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 4 Oct 2017 16:26:23 -0700
Message-ID: <CA+RyBmV3JN==GY9116hPoKsvWjhRq1_5yArqWBUfx8cEDAvDbQ@mail.gmail.com>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: Kireeti Kompella <kireeti@juniper.net>, Mach Chen <mach.chen@huawei.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, Tom Nadeau <tnadeau@lucidvision.com>, "mpls@ietf.org" <mpls@ietf.org>, Alia Atlas <akatlas@gmail.com>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="001a11401768a65142055ac0efd4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/-cbguE5DmoUio2TYynQSmTwKdHg>
X-Mailman-Approved-At: Wed, 04 Oct 2017 16:53:07 -0700
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Oct 2017 23:26:32 -0000

Hi Kireeti, Les, et. al,
I agree and support the proposed changes, including the most recent
proposed by Kireeti.
If errata report can be used to record the changes - absolutely great.
I hope that the errata report that triggered this discussion will be
processed and marked accordingly.

Regards,
Greg

On Wed, Oct 4, 2017 at 12:47 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com
> wrote:

> Kireeti –
>
>
>
> The text I proposed below (3 paragraph’s worth) is intended to “replace
> current paragraphs 2 and 3 of Section 6”.
>
>
>
> I am fine with changing
>
>
>
>      “The egress LSR follows the procedures defined in [RFC 8029]…”
>
>
>
> To
>
>
>
>      “The egress LSR MUST follow the procedures defined in [RFC 8029]…”
>
>
>
> Mach and Greg should speak for themselves – but I had the impression that
> Mach was agreeable – but Greg I am not so sure about.
>
>
>
>    Les
>
>
>
>
>
> *From:* Kireeti Kompella [mailto:kireeti@juniper.net]
> *Sent:* Wednesday, October 04, 2017 12:06 PM
> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>;; Mach Chen <
> mach.chen@huawei.com>;; Carlos Pignataro (cpignata) <cpignata@cisco.com>;;
> Greg Mirsky <gregimirsky@gmail.com>;
> *Cc:* Tom Nadeau <tnadeau@lucidvision.com>;; mpls@ietf.org; Alia Atlas <
> akatlas@gmail.com>;; Reshad Rahman (rrahman) <rrahman@cisco.com>;;
> rtg-bfd@ietf. org <rtg-bfd@ietf.org>;; Kireeti Kompella <
> kireeti@juniper.net>;
> *Subject:* Re: [Technical Errata Reported] RFC5884 (5085)
>
>
>
> Hi Les,
>
>
>
> Just to be sure, you’re suggesting
>
> a)       Change the sentence “The egress LSR MAY respond … BFD session.”
> to “The egress LSR follows the procedures … reply message.”  (or better
> yet, “The egress LSR MUST follow the procedures ….”)
>
> b)      Move this sentence to after the BFD stuff.
>
> c)       Remove the redundant comma (sigh!  Thought I knew commas.)
>
>
>
> I am fine with all three suggestions.  I think that the main point (the
> source of interop issues) is (a); the other changes definitely improve
> readability, but are not showstoppers (imo).
>
>
>
> I gather from Greg’s latest email (2017/09/08) and Mach’s email below that
> they’re both fine with these changes.  Greg, Mach: speak up if not.
>
>
>
> As for “new interop issues”, the current situation is pretty bad, so let’s
> fix it.
>
>
>
> As to how to implement these changes, I don’t personally care.  It seems
> heavyweight to issue a bis for this, rather than just errata, but I’m happy
> to leave that to the WG chairs to decide.
>
>
>
> Kireeti.
>
>
>
> *From: *"Les Ginsberg (ginsberg)" <ginsberg@cisco.com>;
> *Date: *Tuesday, August 15, 2017 at 05:16
> *To: *Mach Chen <mach.chen@huawei.com>;, "Carlos Pignataro (cpignata)" <
> cpignata@cisco.com>;, Greg Mirsky <gregimirsky@gmail.com>;
> *Cc: *Tom Nadeau <tnadeau@lucidvision.com>;, "mpls@ietf.org"; <mpls@ietf.org>;,
> Kireeti Kompella <kireeti@juniper.net>;, Alia Atlas <akatlas@gmail.com>;,
> "Reshad Rahman (rrahman)" <rrahman@cisco.com>;, "rtg-bfd@ietf. org" <
> rtg-bfd@ietf.org>;
> *Subject: *RE: [Technical Errata Reported] RFC5884 (5085)
>
>
>
> I tend to agree with Mach – and I think what Mach states is also
> reinforcing the point that Carlos has made – which is that echo reply
> procedures are defined by RFC 8029 – not by RFC 5884.
>
>
>
> However, the current text suffers from much more than the ambiguity
> regarding Echo Reply.
>
>
>
> 1)Second paragraph of Section 6 goes back and forth between discussing BFD
> Control packets, then Echo Reply, then BFD Control Packets
>
>
>
> 2)Third paragraph of Section 6 has an inappropriate use of “,” in the
> sentence:
>
>
>
> “The BFD Control packets from the
>
>    ingress to the egress LSR MUST set the local discriminator of the
>
>    egress *LSR, in *the Your Discriminator field.”
>
>
>
> 3)Section 6.1 defines when the BFD Discriminator TLV MUST be sent and when
> it is optional in LSP ping. There is actually no need for Section 6 to say
> anything in this regard.
>
>
>
> I propose revised text below – which is much more extensive in its changes
> than what has been proposed thus far, but I think it is necessary to
> eliminate all ambiguity.
>
> That said, there is no question that the current text is subject to
> multiple interpretations – so any change in text runs the risk of
> introducing new interoperability issues. On balance it is probably
> necessary to take this risk as there is no guarantee that implementations
> are interoperable today, but the WG should still consider this point
> carefully.
>
>
>
> The text below replaces current paragraphs 2 and 3 of Section 6.
>
>
>
> *<new text start>*
>
> *On receipt of the LSP Ping Echo request message, the egress LSR MUST*
>
> *   send a BFD Control packet to the ingress LSR, if the validation of*
>
> *   the FEC in the LSP Ping Echo request message succeeds.  This BFD*
>
> *   Control packet MUST set the Your Discriminator field to the*
>
> *   discriminator received from the ingress LSR in the LSP Ping Echo*
>
> *   request message.    The local discriminator assigned by the egress LSR*
>
> *   MUST be used as the My Discriminator field in the BFD session packets*
>
> *   sent by the egress LSR.*
>
>
>
> *   The ingress LSR follows the procedures in [BFD] to send BFD Control*
>
> *   packets to the egress LSR in response to the BFD Control packets*
>
> *   received from the egress LSR.  The BFD Control packets from the*
>
> *   ingress to the egress LSR MUST set the local discriminator of the*
>
> *   egress LSR in the Your Discriminator field.  The egress LSR*
>
> *   demultiplexes the BFD session based on the received Your*
>
> *   Discriminator field.  As mentioned above, the egress LSR MUST send*
>
> *   Control packets to the ingress LSR with the Your Discriminator field*
>
> *   set to the local discriminator of the ingress LSR.  The ingress LSR*
>
> *   uses this to demultiplex the BFD session.*
>
>
>
> *  The egress LSR follows the procedures defined in [RFC 8029] to
> determine when to respond with an LSP Ping Echo  reply message.*
>
> *<new text end>*
>
>
>
>     Les
>
>
>
>
>
> *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org
> <rtg-bfd-bounces@ietf.org>] *On Behalf Of *Mach Chen
> *Sent:* Tuesday, August 15, 2017 12:56 AM
> *To:* Carlos Pignataro (cpignata); Greg Mirsky
> *Cc:* Tom Nadeau; mpls@ietf.org; Kireeti Kompella (kireeti@juniper.net);
> Alia Atlas; Reshad Rahman (rrahman); rtg-bfd@ietf. org
> *Subject:* RE: [Technical Errata Reported] RFC5884 (5085)
>
>
>
> Hi all,
>
>
>
> IMHO, the point is not about whether the Echo Reply is optional for a
> normal LSP Ping, where the echo reply is totally controlled by the reply
> mode.
>
>
>
> For RFC5884, since the reply mode is not specified, based on the current
> text, it can be interpreted as the following two ways:
>
> 1)      it implies a new “mode” introduced, it’s actually a “special” LSP
> Ping,  the process is just as what is currently described in the RFC: an
> Echo Reply is OPTINAL, whether and when to send Echo Reply is up to the
> egress LSR, and the Ingress LSR should not assume an Echo reply will be
> returned;
>
> 2)      the echo reply is still controlled by the reply mode, and given
> that there is a “Do not reply” mode, the current text seems right, but not
> that clear.
>
>
>
> I incline to think way (2) is more nature, if so,  the proposed “Corrected
> Text” may not work if the Sender set the reply mode to “Do not reply”.
>
>
>
> I’d suggest:
>
>
>
> Original Text
> -------------
> The egress LSR MAY respond with an LSP Ping Echo
> reply message that carries the local discriminator assigned by it for
> the BFD session.
>
>
>
> NEW:
>
> The egress LSR MAY respond with an LSP Ping Echo
> reply message that carries the local discriminator assigned by it for
> the BFD session. Whether to send an LSP Ping Echo reply message is
>
> determined by the reply mode carried the received Echo request message.
>
>
>
> Best regards,
>
> Mach
>
>
>
> *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org
> <rtg-bfd-bounces@ietf.org>] *On Behalf Of *Carlos Pignataro (cpignata)
> *Sent:* Tuesday, August 15, 2017 8:17 AM
> *To:* Greg Mirsky <gregimirsky@gmail.com>;
> *Cc:* Tom Nadeau <tnadeau@lucidvision.com>;; mpls@ietf.org; Kireeti
> Kompella (kireeti@juniper.net) <kireeti@juniper.net>;; Alia Atlas <
> akatlas@gmail.com>;; Reshad Rahman (rrahman) <rrahman@cisco.com>;;
> rtg-bfd@ietf. org <rtg-bfd@ietf.org>;
> *Subject:* Re: [Technical Errata Reported] RFC5884 (5085)
>
>
>
> Greg,
>
>
>
> This is my final email on this topic, since the arguments are now just
> silly and not technically constructive.
>
>
>
> 1. It's not about understanding English. It's about understanding specs!
> The "(if any)" that you quote means there are situations in which there's
> no echo reply. As I already explained to you, that's for example the case
> with Reply-mode: No-reply. However, the "(if any)" does not mean an Echo
> Reply is OPTIONAL. !! Or that you choose when a reply is not sent!!
>
> 2. RFC 8029 obsoleted 4379. But to my recollection, nothing changed
> relevant to this Errata.
>
>
>
> BFD for MPLS could have updated LSP ping behavior -- it just didn't.
>
>
> Sent from my iPad
>
>
> On Aug 14, 2017, at 2:12 PM, Greg Mirsky <gregimirsky@gmail.com>; wrote:
>
> Hi Carlos,
>
> thank you for sharing your view on how LSP Echo request with BFD
> Discriminator used to bootstrap a BFD session over MPLS LSP. I'm surprised
> that you refer to RFC 8029 as normative reference when commenting on RFC
> 5884. But even if we look into RFC 8029, it still has the same texts I've
> quoted in the previous note that suggest that echo reply is optional.
> Consider one of them "The Sender's Handle is filled in by the sender and
> returned unchanged by the receiver in the echo reply (if any)." Though
> English is my third language, I interpret "if any" in that sentence as
> clear indication that the echo reply may not be sent ever.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Aug 11, 2017 at 7:45 PM, Carlos Pignataro (cpignata) <
> cpignata@cisco.com>; wrote:
>
> Jeff, WG,
>
>
>
> I believe there is one additional consideration — please see inline.
>
>
>
> On Aug 11, 2017, at 1:39 PM, Jeffrey Haas <jhaas@pfrc.org>; wrote:
>
>
>
> [Note that I have adjusted the addresses in the headers to try to catch the
> RFC authors' current accounts.]
>
>
> The 5884 interop issue keeps bubbling up.  Balaji submitted an errata,
> which
> provides us with a good place to start technical discussion.
>
> Please note I also spent some time off-list discussing this errata with
> Balaji.
>
>
> On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:
>
> Section: 6
>
> Original Text
> -------------
> The egress LSR MAY respond with an LSP Ping Echo
> reply message that carries the local discriminator assigned by it for
> the BFD session.
>
> Corrected Text
> --------------
> The egress LSR MUST respond with an LSP Ping Echo reply message that
> MAY carry the local discriminator assigned by it for the BFD session.
>
>
> Notes
> -----
> It is not clear from the original text which of the following is optional:
>  -  The egress MUST send a reply, but the discriminator in the reply is
> optional
>  -  The reply itself is optional
>
> Technically, the reply cannot be optional, because the egress needs to
> report LSP-Ping verification status to the ingress.
>
>
>
> This is correct — but even more so, technically, it is not up to RFC 5884
> to define when an LSP-Ping reply is optional or not.
>
>
>
> That’s’ up to https://tools.ietf.org/html/rfc8029#section-4.4
>
>
>
> Lacking a Reply Mode set to "Do not reply" (https://tools.ietf.org/html/
> rfc8029#page-12) the RFC 8029 procedures dictate a response be sent,
> independent of whether the RFC 5884 procedures use that information or not.
>
>
>
> More below.
>
>
>
>
> The proposed text recommends to include BFD discriminator in the reply.
> This was the intent of the original text.
>
>
> My opinion follows:
>
> In section 6 -
>
> :    On receipt of the LSP Ping Echo request message, the egress LSR MUST
> :    send a BFD Control packet to the ingress LSR, if the validation of
> :    the FEC in the LSP Ping Echo request message succeeds.  This BFD
> :    Control packet MUST set the Your Discriminator field to the
> :    discriminator received from the ingress LSR in the LSP Ping Echo
> :    request message.  The egress LSR MAY respond with an LSP Ping Echo
> :    reply message that carries the local discriminator assigned by it for
> :    the BFD session.  The local discriminator assigned by the egress LSR
> :    MUST be used as the My Discriminator field in the BFD session packets
> :    sent by the egress LSR.
>
> In the text above, I consider it quite clear that the receipt of the BFD
> packet contains sufficient state to bring up the BFD session.  The receipt
> of the same Discriminator in the LSP Ping Echo Reply is optional.
>
> This makes sense partially because the reply may be dropped and we want the
> BFD session to come up as fast as possible.
>
>
>
> Yes, especially because the first sentence says that the egress sending a
> BFD Control packet implies FEC validation passed. However,
> https://tools.ietf.org/html/rfc8029#section-4.4 does more than FEC
> validation.
>
>
>
>
> The point of contention appears to be what to do if we *never* get such
> replies.  It's worth pointing out additional text in RFC 5884, section 3.2.
>
> :    Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
> :    detection:
> :
> :       i) LSP Ping is used for bootstrapping the BFD session as described
> :          later in this document.
> :
> :      ii) BFD is used to exchange fault detection (i.e., BFD session)
> :          packets at the required detection interval.
> :
> :     iii) LSP Ping is used to periodically verify the control plane
> :          against the data plane by ensuring that the LSP is mapped to
> :          the same FEC, at the egress, as the ingress.
>
> iii above reminds us that the LSP may be torn down because LSP Ping fails.
> Thus, it seems problematic that we do not get a reply ever.
>
> However, with the BFD session in the Up state, we have information proving
> that the LSP is up.  Thus we have contradictory intent.
>
> ---
>
> My opinion is that the MAY in the RFC 5884 procedures is intended to have
> the BFD session come up by the most expedient means.  I do not believe the
> likely intent was to say "don't send Echo Reply".  Among other things, that
> seems contrary to the intent of the general LSP Ping procedures.
>
> Having given my personal observations, we now get to the business of the
> Working Group: Debating intent and related text.
>
>
>
> My individual opinion is that, as written, RFC 5884 cannot mean any other
> thing that “ The egress LSR MUST respond with an LSP Ping Echo reply
> message that
>
> MAY carry the local discriminator assigned by it for the BFD session”.
>
>
>
> In other words, I support this errata.
>
>
>
> This is because RFC 5884 did not update RFC 4379’s procedures. And thus a
> response is needed based on 8029 irregardless of whether 5884 uses it.
>
>
>
> That said, it is debatable whether that LSP Ping response is useful or
> not. If it is not sent, it does not comply to 8029. But if the WG wants for
> it to be not send, a new spec is needed.
>
>
>
> Thanks,
>
>
>
> -- Jeff
>
>
>
> —
>
> Carlos Pignataro, carlos@cisco.com
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
>
>
>
>
>