Re: [Technical Errata Reported] RFC5884 (5085)

Loa Andersson <loa@pi.nu> Fri, 06 October 2017 07:36 UTC

Return-Path: <loa@pi.nu>
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 285CC1344D6; Fri, 6 Oct 2017 00:36:58 -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 QBfLL1ZbDqQc; Fri, 6 Oct 2017 00:36:53 -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 72DCB1344D8; Fri, 6 Oct 2017 00:36:52 -0700 (PDT)
Received: from [192.168.0.2] (c213-89-111-155.bredband.comhem.se [213.89.111.155]) (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 0FA58180155A; Fri, 6 Oct 2017 09:36:51 +0200 (CEST)
Subject: Re: [Technical Errata Reported] RFC5884 (5085)
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, Greg Mirsky <gregimirsky@gmail.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "mpls@ietf.org" <mpls@ietf.org>, Kireeti Kompella <kireeti@juniper.net>, Alia Atlas <akatlas@gmail.com>, Tom Nadeau <tnadeau@lucidvision.com>, "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>
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> <CA+RyBmV3JN==GY9116hPoKsvWjhRq1_5yArqWBUfx8cEDAvDbQ@mail.gmail.com> <D5FAEC68.318D55%rrahman@cisco.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <be6698a0-117f-568c-d295-3cfe48063b9d@pi.nu>
Date: Fri, 6 Oct 2017 09:36:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <D5FAEC68.318D55%rrahman@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/NrKQQpH6B1XlJW3z1gPuj5qiS6Q>
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: Fri, 06 Oct 2017 07:36:58 -0000

All,

On 2017-10-05 01:52, Reshad Rahman (rrahman) wrote:
> Regarding Kireeti’s point below, I also think errata would be best. Jeff?
> 
> "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."____
> 
This is best handled as an errata.

Also, it is a national holiday in China, Mach won't be able to respond
until early next week.

/Loa
> 
> 
> From: Greg Mirsky <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
> Date: Wednesday, October 4, 2017 at 7:26 PM
> To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com 
> <mailto:ginsberg@cisco.com>>
> Cc: Kireeti Kompella <kireeti@juniper.net <mailto:kireeti@juniper.net>>, 
> Mach Chen <mach.chen@huawei.com <mailto:mach.chen@huawei.com>>, "Carlos 
> Pignataro (cpignata)" <cpignata@cisco.com <mailto:cpignata@cisco.com>>, 
> Tom Nadeau <tnadeau@lucidvision.com <mailto:tnadeau@lucidvision.com>>, 
> "mpls@ietf.org <mailto:mpls@ietf.org>" <mpls@ietf.org 
> <mailto:mpls@ietf.org>>, Alia Atlas <akatlas@gmail.com 
> <mailto:akatlas@gmail.com>>, Reshad <rrahman@cisco.com 
> <mailto:rrahman@cisco.com>>, "rtg-bfd@ietf.org 
> <mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org <mailto:rtg-bfd@ietf.org>>
> Subject: Re: [Technical Errata Reported] RFC5884 (5085)
> 
> 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 <mailto: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
>     <mailto:kireeti@juniper.net>]
>     *Sent:* Wednesday, October 04, 2017 12:06 PM
>     *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com
>     <mailto:ginsberg@cisco.com>>; Mach Chen <mach.chen@huawei.com
>     <mailto:mach.chen@huawei.com>>; Carlos Pignataro (cpignata)
>     <cpignata@cisco.com <mailto:cpignata@cisco.com>>; Greg Mirsky
>     <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
>     *Cc:* Tom Nadeau <tnadeau@lucidvision.com
>     <mailto:tnadeau@lucidvision.com>>; mpls@ietf.org
>     <mailto:mpls@ietf.org>; Alia Atlas <akatlas@gmail.com
>     <mailto:akatlas@gmail.com>>; Reshad Rahman (rrahman)
>     <rrahman@cisco.com <mailto:rrahman@cisco.com>>; rtg-bfd@ietf. org
>     <rtg-bfd@ietf.org <mailto:rtg-bfd@ietf.org>>; Kireeti Kompella
>     <kireeti@juniper.net <mailto: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
>     <mailto:ginsberg@cisco.com>>
>     *Date: *Tuesday, August 15, 2017 at 05:16
>     *To: *Mach Chen <mach.chen@huawei.com
>     <mailto:mach.chen@huawei.com>>, "Carlos Pignataro (cpignata)"
>     <cpignata@cisco.com <mailto:cpignata@cisco.com>>, Greg Mirsky
>     <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
>     *Cc: *Tom Nadeau <tnadeau@lucidvision.com
>     <mailto:tnadeau@lucidvision.com>>, "mpls@ietf.org
>     <mailto:mpls@ietf.org>" <mpls@ietf.org <mailto:mpls@ietf.org>>,
>     Kireeti Kompella <kireeti@juniper.net <mailto:kireeti@juniper.net>>,
>     Alia Atlas <akatlas@gmail.com <mailto:akatlas@gmail.com>>, "Reshad
>     Rahman (rrahman)" <rrahman@cisco.com <mailto:rrahman@cisco.com>>,
>     "rtg-bfd@ietf. org <mailto:rtg-bfd@ietf.%20org>" <rtg-bfd@ietf.org
>     <mailto: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
>     <mailto: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 <mailto:mpls@ietf.org>; Kireeti
>     Kompella (kireeti@juniper.net <mailto: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
>     <mailto: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 <mailto:gregimirsky@gmail.com>>
>     *Cc:* Tom Nadeau <tnadeau@lucidvision.com
>     <mailto:tnadeau@lucidvision.com>>; mpls@ietf.org
>     <mailto:mpls@ietf.org>; Kireeti Kompella (kireeti@juniper.net
>     <mailto:kireeti@juniper.net>) <kireeti@juniper.net
>     <mailto:kireeti@juniper.net>>; Alia Atlas <akatlas@gmail.com
>     <mailto:akatlas@gmail.com>>; Reshad Rahman (rrahman)
>     <rrahman@cisco.com <mailto:rrahman@cisco.com>>; rtg-bfd@ietf. org
>     <rtg-bfd@ietf.org <mailto: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
>     <mailto: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 <mailto: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 <mailto: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
>             <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
>             <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
>             <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 <mailto:carlos@cisco.com>
> 
>             /“Sometimes I use big words that I do not fully understand,
>             to make myself sound more photosynthesis."/____
> 
>             ____
> 
>         ____
> 
> 

-- 


Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert
Huawei Technologies (consultant)     phone: +46 739 81 21 64