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

From: Kireeti Kompella <[email-masked]>
Date: Wed, 4 Oct 2017 19:06:15 +0000

Hi Les,

Just to be sure, you’re suggesting

  1.  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 ….”)
  2.  Move this sentence to after the BFD stuff.
  3.  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)" <[email-masked]>
Date: Tuesday, August 15, 2017 at 05:16
To: Mach Chen <[email-masked]>, "Carlos Pignataro (cpignata)" <[email-masked]>, Greg Mirsky <[email-masked]>
Cc: Tom Nadeau <[email-masked]>, "[email-masked]" <[email-masked]>, Kireeti Kompella <[email-masked]>, Alia Atlas <[email-masked]>, "Reshad Rahman (rrahman)" <[email-masked]>, "rtg-bfd@ietf. org" <[email-masked]>
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:[email-masked]] On Behalf Of Mach Chen
Sent: Tuesday, August 15, 2017 12:56 AM
To: Carlos Pignataro (cpignata); Greg Mirsky
Cc: Tom Nadeau; [email-masked]; Kireeti Kompella ([email-masked]); 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:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Tuesday, August 15, 2017 8:17 AM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: Tom Nadeau <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kireeti Kompella ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; Alia Atlas <[email-masked]<mailto:[email-masked]>>; Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>>; rtg-bfd@ietf. org <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> 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) <[email-masked]<mailto:[email-masked]>> wrote:
Jeff, WG,

I believe there is one additional consideration — please see inline.

On Aug 11, 2017, at 1:39 PM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> 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, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 4 Oct 2017 19:47:55 +0000

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:[email-masked]]
Sent: Wednesday, October 04, 2017 12:06 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; Mach Chen <[email-masked]>; Carlos Pignataro (cpignata) <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: Tom Nadeau <[email-masked]>; [email-masked]; Alia Atlas <[email-masked]>; Reshad Rahman (rrahman) <[email-masked]>; rtg-bfd@ietf. org <[email-masked]>; Kireeti Kompella <[email-masked]>
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.)

Kireeti.

From: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 15, 2017 at 05:16
To: Mach Chen <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: Tom Nadeau <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Kireeti Kompella <[email-masked]<mailto:[email-masked]>>, Alia Atlas <[email-masked]<mailto:[email-masked]>>, "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>, "rtg-bfd@ietf. org<mailto:rtg-bfd@ietf.%20org>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Technical Errata Reported] RFC5884 (5085)

<new text start>

    Les

Cc: Tom Nadeau; [email-masked]<mailto:[email-masked]>; Kireeti Kompella ([email-masked]<mailto:[email-masked]>); Alia Atlas; Reshad Rahman (rrahman); rtg-bfd@ietf. org

Hi all,

I’d suggest:

Original Text
-------------

NEW:

Best regards,
Mach

Greg,

Sent from my iPad

Regards,
Greg

Original Text
-------------

Corrected Text
--------------

Notes
-----

More below.

My opinion follows:

In section 6 -

---

Thanks,

-- Jeff

—

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 4 Oct 2017 16:26:23 -0700

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) <[email-masked]
> 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
>
>
>
> 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:[email-masked]]
> *Sent:* Wednesday, October 04, 2017 12:06 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>; Mach Chen <
> [email-masked]>; Carlos Pignataro (cpignata) <[email-masked]>;
> Greg Mirsky <[email-masked]>
> *Cc:* Tom Nadeau <[email-masked]>; [email-masked]; Alia Atlas <
> [email-masked]>; Reshad Rahman (rrahman) <[email-masked]>;
> rtg-bfd@ietf. org <[email-masked]>; Kireeti Kompella <
> [email-masked]>
> *Subject:* Re: [Technical Errata Reported] RFC5884 (5085)
>
>
>
> Hi Les,
>
>
>
> 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 ….”)
>
> 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 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)" <[email-masked]>
> *Date: *Tuesday, August 15, 2017 at 05:16
> *To: *Mach Chen <[email-masked]>, "Carlos Pignataro (cpignata)" <
> [email-masked]>, Greg Mirsky <[email-masked]>
> *Cc: *Tom Nadeau <[email-masked]>, "[email-masked]" <[email-masked]>,
> Kireeti Kompella <[email-masked]>, Alia Atlas <[email-masked]>,
> "Reshad Rahman (rrahman)" <[email-masked]>, "rtg-bfd@ietf. org" <
> [email-masked]>
> *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.
>
>
>
> 1)Second paragraph of Section 6 goes back and forth between discussing BFD
> Control packets, then Echo Reply, then BFD Control Packets
>
>
>
>    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.
>
>
>
> *<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:[email-masked]
> <[email-masked]>] *On Behalf Of *Mach Chen
> *Sent:* Tuesday, August 15, 2017 12:56 AM
> *To:* Carlos Pignataro (cpignata); Greg Mirsky
> *Cc:* Tom Nadeau; [email-masked]; Kireeti Kompella ([email-masked]);
> 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
> -------------
> *From:* Rtg-bfd [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Carlos Pignataro (cpignata)
> *Sent:* Tuesday, August 15, 2017 8:17 AM
> *To:* Greg Mirsky <[email-masked]>
> *Cc:* Tom Nadeau <[email-masked]>; [email-masked]; Kireeti
> Kompella ([email-masked]) <[email-masked]>; Alia Atlas <
> [email-masked]>; Reshad Rahman (rrahman) <[email-masked]>;
> rtg-bfd@ietf. org <[email-masked]>
> *Subject:* Re: [Technical Errata Reported] RFC5884 (5085)
>
>
>
> Greg,
>
>
>
> 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!!
>
> On Aug 14, 2017, at 2:12 PM, Greg Mirsky <[email-masked]> 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) <
> [email-masked]> wrote:
>
> Jeff, WG,
>
>
>
> On Aug 11, 2017, at 1:39 PM, Jeffrey Haas <[email-masked]> wrote:
>
>
>
> 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.
>
>
>
> 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 -
>
> 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.
>
>
>
>
> 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
>
> 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, [email-masked]
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
>
>
>
>
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 4 Oct 2017 23:52:22 +0000

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."

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 4, 2017 at 7:26 PM
To: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Cc: Kireeti Kompella <[email-masked]<mailto:[email-masked]>>, Mach Chen <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, Tom Nadeau <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Alia Atlas <[email-masked]<mailto:[email-masked]>>, Reshad <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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) <[email-masked]<mailto:[email-masked]>> wrote:
Kireeti –

I am fine with changing

To

   Les

From: Kireeti Kompella [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, October 04, 2017 12:06 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Mach Chen <[email-masked]<mailto:[email-masked]>>; Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: Tom Nadeau <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Alia Atlas <[email-masked]<mailto:[email-masked]>>; Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>>; rtg-bfd@ietf. org <[email-masked]<mailto:[email-masked]>>; Kireeti Kompella <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)

Hi Les,

Kireeti.

<new text start>

    Les

Hi all,

I’d suggest:

Original Text
-------------

NEW:

Best regards,
Mach

Greg,

Sent from my iPad

Regards,
Greg

Original Text
-------------

Corrected Text
--------------

Notes
-----

More below.

My opinion follows:

In section 6 -

---

Thanks,

-- Jeff

—

---

From: Loa Andersson <[email-masked]>
Date: Fri, 6 Oct 2017 09:36:49 +0200

All,

On 2017-10-05 01:52, Reshad Rahman (rrahman) wrote:
> "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 <[email-masked] <mailto:[email-masked]>>
> Cc: Kireeti Kompella <[email-masked] <mailto:[email-masked]>>, 
> Mach Chen <[email-masked] <mailto:[email-masked]>>, "Carlos 
> Pignataro (cpignata)" <[email-masked] <mailto:[email-masked]>>, 
> Tom Nadeau <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, Alia Atlas <[email-masked] 
> <mailto:[email-masked]>>, Reshad <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> On Wed, Oct 4, 2017 at 12:47 PM, Les Ginsberg (ginsberg) 
> <[email-masked] <mailto:[email-masked]>> 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:[email-masked]
>     <mailto:[email-masked]>]
>     *To:* Les Ginsberg (ginsberg) <[email-masked]
>     <mailto:[email-masked]>>; Mach Chen <[email-masked]
>     <mailto:[email-masked]>>; Carlos Pignataro (cpignata)
>     <[email-masked] <mailto:[email-masked]>>; Greg Mirsky
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc:* Tom Nadeau <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>; Alia Atlas <[email-masked]
>     <mailto:[email-masked]>>; Reshad Rahman (rrahman)
>     <[email-masked] <mailto:[email-masked]>>; rtg-bfd@ietf. org
>     <[email-masked] <mailto:[email-masked]>>; Kireeti Kompella
>     <[email-masked] <mailto:[email-masked]>>
>     *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)" <[email-masked]
>     <mailto:[email-masked]>>
>     *To: *Mach Chen <[email-masked]
>     <mailto:[email-masked]>>, "Carlos Pignataro (cpignata)"
>     <[email-masked] <mailto:[email-masked]>>, Greg Mirsky
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc: *Tom Nadeau <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>,
>     Kireeti Kompella <[email-masked] <mailto:[email-masked]>>,
>     Alia Atlas <[email-masked] <mailto:[email-masked]>>, "Reshad
>     Rahman (rrahman)" <[email-masked] <mailto:[email-masked]>>,
>     "rtg-bfd@ietf. org <mailto:rtg-bfd@ietf.%20org>" <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject: *RE: [Technical Errata Reported] RFC5884 (5085)____
> 
>     __ __
> 
>     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.____
> 
>     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:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Mach Chen
>     *Cc:* Tom Nadeau; [email-masked] <mailto:[email-masked]>; Kireeti
>     Kompella ([email-masked] <mailto:[email-masked]>); 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 BFD session.____
>     ____
>     NEW:____
>     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:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Carlos Pignataro
>     (cpignata)
>     *To:* Greg Mirsky <[email-masked] <mailto:[email-masked]>>
>     *Cc:* Tom Nadeau <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>; Kireeti Kompella ([email-masked]
>     <mailto:[email-masked]>) <[email-masked]
>     <mailto:[email-masked]>>; Alia Atlas <[email-masked]
>     <mailto:[email-masked]>>; Reshad Rahman (rrahman)
>     <[email-masked] <mailto:[email-masked]>>; rtg-bfd@ietf. org
>     <[email-masked] <mailto:[email-masked]>>
>     *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. ____
> 
>     ____
> 
>     ____
>     Sent from my iPad____
>     On Aug 14, 2017, at 2:12 PM, Greg Mirsky <[email-masked]
>     <mailto:[email-masked]>> wrote:____
> 
>         Hi Carlos, ____
> 
>         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)
>         <[email-masked] <mailto:[email-masked]>> wrote:____
> 
>             Jeff, WG, ____
> 
>             ____
> 
>             I believe there is one additional consideration — please see
>             inline.____
> 
>             ____
> 
>                 On Aug 11, 2017, at 1:39 PM, Jeffrey Haas
>                 <[email-masked] <mailto:[email-masked]>> wrote:____
> 
>                 ____
> 
>                 On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata
>                 System wrote:____
> 
>                     Section: 6
> 
>                     Original Text
>                     -------------
>                     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 -
> 
>                 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.____
> 
>             ____
> 
> 
>                 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, [email-masked] <mailto:[email-masked]>
> 
>             /“Sometimes I use big words that I do not fully understand,
>             to make myself sound more photosynthesis."/____
> 
>             ____
> 
>         ____
> 
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Huawei Technologies (consultant)     phone: +46 739 81 21 64