Re: [mpls] [Technical Errata Reported] RFC5884 (5085)

[Loa Andersson <[e-mail]>]

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 <[e-mail] <mailto:[e-mail]>>
> Date: Wednesday, October 4, 2017 at 7:26 PM
> To: "Les Ginsberg (ginsberg)" <[e-mail] 
> <mailto:[e-mail]>>
> Cc: Kireeti Kompella <[e-mail] <mailto:[e-mail]>>, 
> Mach Chen <[e-mail] <mailto:[e-mail]>>, "Carlos 
> Pignataro (cpignata)" <[e-mail] <mailto:[e-mail]>>, 
> Tom Nadeau <[e-mail] <mailto:[e-mail]>>, 
> "[e-mail] <mailto:[e-mail]>" <[e-mail] 
> <mailto:[e-mail]>>, Alia Atlas <[e-mail] 
> <mailto:[e-mail]>>, Reshad <[e-mail] 
> <mailto:[e-mail]>>, "[e-mail] 
> <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> 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) 
> <[e-mail] <mailto:[e-mail]>> 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:[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* Wednesday, October 04, 2017 12:06 PM
>     *To:* Les Ginsberg (ginsberg) <[e-mail]
>     <mailto:[e-mail]>>; Mach Chen <[e-mail]
>     <mailto:[e-mail]>>; Carlos Pignataro (cpignata)
>     <[e-mail] <mailto:[e-mail]>>; Greg Mirsky
>     <[e-mail] <mailto:[e-mail]>>
>     *Cc:* Tom Nadeau <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>; Alia Atlas <[e-mail]
>     <mailto:[e-mail]>>; Reshad Rahman (rrahman)
>     <[e-mail] <mailto:[e-mail]>>; rtg-bfd@ietf. org
>     <[e-mail] <mailto:[e-mail]>>; Kireeti Kompella
>     <[e-mail] <mailto:[e-mail]>>
>     *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)" <[e-mail]
>     <mailto:[e-mail]>>
>     *Date: *Tuesday, August 15, 2017 at 05:16
>     *To: *Mach Chen <[e-mail]
>     <mailto:[e-mail]>>, "Carlos Pignataro (cpignata)"
>     <[e-mail] <mailto:[e-mail]>>, Greg Mirsky
>     <[e-mail] <mailto:[e-mail]>>
>     *Cc: *Tom Nadeau <[e-mail]
>     <mailto:[e-mail]>>, "[e-mail]
>     <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>,
>     Kireeti Kompella <[e-mail] <mailto:[e-mail]>>,
>     Alia Atlas <[e-mail] <mailto:[e-mail]>>, "Reshad
>     Rahman (rrahman)" <[e-mail] <mailto:[e-mail]>>,
>     "rtg-bfd@ietf. org <mailto:rtg-bfd@ietf.%20org>" <[e-mail]
>     <mailto:[e-mail]>>
>     *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:[e-mail]
>     <mailto:[e-mail]>] *On Behalf Of *Mach Chen
>     *Sent:* Tuesday, August 15, 2017 12:56 AM
>     *To:* Carlos Pignataro (cpignata); Greg Mirsky
>     *Cc:* Tom Nadeau; [e-mail] <mailto:[e-mail]>; Kireeti
>     Kompella ([e-mail] <mailto:[e-mail]>); 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:[e-mail]
>     <mailto:[e-mail]>] *On Behalf Of *Carlos Pignataro
>     (cpignata)
>     *Sent:* Tuesday, August 15, 2017 8:17 AM
>     *To:* Greg Mirsky <[e-mail] <mailto:[e-mail]>>
>     *Cc:* Tom Nadeau <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>; Kireeti Kompella ([e-mail]
>     <mailto:[e-mail]>) <[e-mail]
>     <mailto:[e-mail]>>; Alia Atlas <[e-mail]
>     <mailto:[e-mail]>>; Reshad Rahman (rrahman)
>     <[e-mail] <mailto:[e-mail]>>; rtg-bfd@ietf. org
>     <[e-mail] <mailto:[e-mail]>>
>     *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 <[e-mail]
>     <mailto:[e-mail]>> 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)
>         <[e-mail] <mailto:[e-mail]>> wrote:____
> 
>             Jeff, WG, ____
> 
>             ____
> 
>             I believe there is one additional consideration — please see
>             inline.____
> 
>             ____
> 
>                 On Aug 11, 2017, at 1:39 PM, Jeffrey Haas
>                 <[e-mail] <mailto:[e-mail]>> 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, [e-mail] <mailto:[e-mail]>
> 
>             /“Sometimes I use big words that I do not fully understand,
>             to make myself sound more photosynthesis."/____
> 
>             ____
> 
>         ____
> 
> 

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert
Huawei Technologies (consultant)     phone: [phone]