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

[Greg Mirsky <[e-mail]>]

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]
> 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]]
> *Sent:* Wednesday, October 04, 2017 12:06 PM
> *To:* Les Ginsberg (ginsberg) <[e-mail]>; Mach Chen <
> [e-mail]>; Carlos Pignataro (cpignata) <[e-mail]>;
> Greg Mirsky <[e-mail]>
> *Cc:* Tom Nadeau <[e-mail]>; [e-mail]; Alia Atlas <
> [e-mail]>; Reshad Rahman (rrahman) <[e-mail]>;
> rtg-bfd@ietf. org <[e-mail]>; Kireeti Kompella <
> [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]>
> *Date: *Tuesday, August 15, 2017 at 05:16
> *To: *Mach Chen <[e-mail]>, "Carlos Pignataro (cpignata)" <
> [e-mail]>, Greg Mirsky <[e-mail]>
> *Cc: *Tom Nadeau <[e-mail]>, "[e-mail]" <[e-mail]>,
> Kireeti Kompella <[e-mail]>, Alia Atlas <[e-mail]>,
> "Reshad Rahman (rrahman)" <[e-mail]>, "rtg-bfd@ietf. org" <
> [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]
> <[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]; Kireeti Kompella ([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]
> <[e-mail]>] *On Behalf Of *Carlos Pignataro (cpignata)
> *Sent:* Tuesday, August 15, 2017 8:17 AM
> *To:* Greg Mirsky <[e-mail]>
> *Cc:* Tom Nadeau <[e-mail]>; [e-mail]; Kireeti
> Kompella ([e-mail]) <[e-mail]>; Alia Atlas <
> [e-mail]>; Reshad Rahman (rrahman) <[e-mail]>;
> rtg-bfd@ietf. org <[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]> 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]> 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]> 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, [e-mail]
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
>
>
>
>
>