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) <ginsb...@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:kire...@juniper.net] > *Sent:* Wednesday, October 04, 2017 12:06 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Mach Chen < > mach.c...@huawei.com>; Carlos Pignataro (cpignata) <cpign...@cisco.com>; > Greg Mirsky <gregimir...@gmail.com> > *Cc:* Tom Nadeau <tnad...@lucidvision.com>; m...@ietf.org; Alia Atlas < > akat...@gmail.com>; Reshad Rahman (rrahman) <rrah...@cisco.com>; > rtg-bfd@ietf. org <rtg-bfd@ietf.org>; Kireeti Kompella < > kire...@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)" <ginsb...@cisco.com> > *Date: *Tuesday, August 15, 2017 at 05:16 > *To: *Mach Chen <mach.c...@huawei.com>, "Carlos Pignataro (cpignata)" < > cpign...@cisco.com>, Greg Mirsky <gregimir...@gmail.com> > *Cc: *Tom Nadeau <tnad...@lucidvision.com>, "m...@ietf.org" <m...@ietf.org>, > Kireeti Kompella <kire...@juniper.net>, Alia Atlas <akat...@gmail.com>, > "Reshad Rahman (rrahman)" <rrah...@cisco.com>, "rtg-bfd@ietf. org" < > rtg-bfd@ietf.org> > *Subject: *RE: [Technical Errata Reported] RFC5884 (5085) > > > > I tend to agree with Mach – and I think what Mach states is also > reinforcing the point that Carlos has made – which is that echo reply > procedures are defined by RFC 8029 – not by RFC 5884. > > > > However, the current text suffers from much more than the ambiguity > regarding Echo Reply. > > > > 1)Second paragraph of Section 6 goes back and forth between discussing BFD > Control packets, then Echo Reply, then BFD Control Packets > > > > 2)Third paragraph of Section 6 has an inappropriate use of “,” in the > sentence: > > > > “The BFD Control packets from the > > ingress to the egress LSR MUST set the local discriminator of the > > egress *LSR, in *the Your Discriminator field.” > > > > 3)Section 6.1 defines when the BFD Discriminator TLV MUST be sent and when > it is optional in LSP ping. There is actually no need for Section 6 to say > anything in this regard. > > > > I propose revised text below – which is much more extensive in its changes > than what has been proposed thus far, but I think it is necessary to > eliminate all ambiguity. > > That said, there is no question that the current text is subject to > multiple interpretations – so any change in text runs the risk of > introducing new interoperability issues. On balance it is probably > necessary to take this risk as there is no guarantee that implementations > are interoperable today, but the WG should still consider this point > carefully. > > > > The text below replaces current paragraphs 2 and 3 of Section 6. > > > > *<new text start>* > > *On receipt of the LSP Ping Echo request message, the egress LSR MUST* > > * send a BFD Control packet to the ingress LSR, if the validation of* > > * the FEC in the LSP Ping Echo request message succeeds. This BFD* > > * Control packet MUST set the Your Discriminator field to the* > > * discriminator received from the ingress LSR in the LSP Ping Echo* > > * request message. The local discriminator assigned by the egress LSR* > > * MUST be used as the My Discriminator field in the BFD session packets* > > * sent by the egress LSR.* > > > > * The ingress LSR follows the procedures in [BFD] to send BFD Control* > > * packets to the egress LSR in response to the BFD Control packets* > > * received from the egress LSR. The BFD Control packets from the* > > * ingress to the egress LSR MUST set the local discriminator of the* > > * egress LSR in the Your Discriminator field. The egress LSR* > > * demultiplexes the BFD session based on the received Your* > > * Discriminator field. As mentioned above, the egress LSR MUST send* > > * Control packets to the ingress LSR with the Your Discriminator field* > > * set to the local discriminator of the ingress LSR. The ingress LSR* > > * uses this to demultiplex the BFD session.* > > > > * The egress LSR follows the procedures defined in [RFC 8029] to > determine when to respond with an LSP Ping Echo reply message.* > > *<new text end>* > > > > Les > > > > > > *From:* Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org > <rtg-bfd-boun...@ietf.org>] *On Behalf Of *Mach Chen > *Sent:* Tuesday, August 15, 2017 12:56 AM > *To:* Carlos Pignataro (cpignata); Greg Mirsky > *Cc:* Tom Nadeau; m...@ietf.org; Kireeti Kompella (kire...@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-boun...@ietf.org > <rtg-bfd-boun...@ietf.org>] *On Behalf Of *Carlos Pignataro (cpignata) > *Sent:* Tuesday, August 15, 2017 8:17 AM > *To:* Greg Mirsky <gregimir...@gmail.com> > *Cc:* Tom Nadeau <tnad...@lucidvision.com>; m...@ietf.org; Kireeti > Kompella (kire...@juniper.net) <kire...@juniper.net>; Alia Atlas < > akat...@gmail.com>; Reshad Rahman (rrahman) <rrah...@cisco.com>; > rtg-bfd@ietf. org <rtg-bfd@ietf.org> > *Subject:* Re: [Technical Errata Reported] RFC5884 (5085) > > > > Greg, > > > > This is my final email on this topic, since the arguments are now just > silly and not technically constructive. > > > > 1. It's not about understanding English. It's about understanding specs! > The "(if any)" that you quote means there are situations in which there's > no echo reply. As I already explained to you, that's for example the case > with Reply-mode: No-reply. However, the "(if any)" does not mean an Echo > Reply is OPTIONAL. !! Or that you choose when a reply is not sent!! > > 2. RFC 8029 obsoleted 4379. But to my recollection, nothing changed > relevant to this Errata. > > > > BFD for MPLS could have updated LSP ping behavior -- it just didn't. > > > Sent from my iPad > > > On Aug 14, 2017, at 2:12 PM, Greg Mirsky <gregimir...@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) < > cpign...@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 <jh...@pfrc.org> wrote: > > > > [Note that I have adjusted the addresses in the headers to try to catch the > RFC authors' current accounts.] > > > The 5884 interop issue keeps bubbling up. Balaji submitted an errata, > which > provides us with a good place to start technical discussion. > > Please note I also spent some time off-list discussing this errata with > Balaji. > > > On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote: > > Section: 6 > > Original Text > ------------- > The egress LSR MAY respond with an LSP Ping Echo > reply message that carries the local discriminator assigned by it for > the BFD session. > > Corrected Text > -------------- > The egress LSR MUST respond with an LSP Ping Echo reply message that > MAY carry the local discriminator assigned by it for the BFD session. > > > Notes > ----- > It is not clear from the original text which of the following is optional: > - The egress MUST send a reply, but the discriminator in the reply is > optional > - The reply itself is optional > > Technically, the reply cannot be optional, because the egress needs to > report LSP-Ping verification status to the ingress. > > > > This is correct — but even more so, technically, it is not up to RFC 5884 > to define when an LSP-Ping reply is optional or not. > > > > That’s’ up to https://tools.ietf.org/html/rfc8029#section-4.4 > > > > Lacking a Reply Mode set to "Do not reply" (https://tools.ietf.org/html/ > rfc8029#page-12) the RFC 8029 procedures dictate a response be sent, > independent of whether the RFC 5884 procedures use that information or not. > > > > More below. > > > > > The proposed text recommends to include BFD discriminator in the reply. > This was the intent of the original text. > > > My opinion follows: > > In section 6 - > > : On receipt of the LSP Ping Echo request message, the egress LSR MUST > : send a BFD Control packet to the ingress LSR, if the validation of > : the FEC in the LSP Ping Echo request message succeeds. This BFD > : Control packet MUST set the Your Discriminator field to the > : discriminator received from the ingress LSR in the LSP Ping Echo > : request message. The egress LSR MAY respond with an LSP Ping Echo > : reply message that carries the local discriminator assigned by it for > : the BFD session. The local discriminator assigned by the egress LSR > : MUST be used as the My Discriminator field in the BFD session packets > : sent by the egress LSR. > > In the text above, I consider it quite clear that the receipt of the BFD > packet contains sufficient state to bring up the BFD session. The receipt > of the same Discriminator in the LSP Ping Echo Reply is optional. > > This makes sense partially because the reply may be dropped and we want the > BFD session to come up as fast as possible. > > > > Yes, especially because the first sentence says that the egress sending a > BFD Control packet implies FEC validation passed. However, > https://tools.ietf.org/html/rfc8029#section-4.4 does more than FEC > validation. > > > > > The point of contention appears to be what to do if we *never* get such > replies. It's worth pointing out additional text in RFC 5884, section 3.2. > > : Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault > : detection: > : > : i) LSP Ping is used for bootstrapping the BFD session as described > : later in this document. > : > : ii) BFD is used to exchange fault detection (i.e., BFD session) > : packets at the required detection interval. > : > : iii) LSP Ping is used to periodically verify the control plane > : against the data plane by ensuring that the LSP is mapped to > : the same FEC, at the egress, as the ingress. > > iii above reminds us that the LSP may be torn down because LSP Ping fails. > Thus, it seems problematic that we do not get a reply ever. > > However, with the BFD session in the Up state, we have information proving > that the LSP is up. Thus we have contradictory intent. > > --- > > My opinion is that the MAY in the RFC 5884 procedures is intended to have > the BFD session come up by the most expedient means. I do not believe the > likely intent was to say "don't send Echo Reply". Among other things, that > seems contrary to the intent of the general LSP Ping procedures. > > Having given my personal observations, we now get to the business of the > Working Group: Debating intent and related text. > > > > My individual opinion is that, as written, RFC 5884 cannot mean any other > thing that “ The egress LSR MUST respond with an LSP Ping Echo reply > message that > > MAY carry the local discriminator assigned by it for the BFD session”. > > > > In other words, I support this errata. > > > > This is because RFC 5884 did not update RFC 4379’s procedures. And thus a > response is needed based on 8029 irregardless of whether 5884 uses it. > > > > That said, it is debatable whether that LSP Ping response is useful or > not. If it is not sent, it does not comply to 8029. But if the WG wants for > it to be not send, a new spec is needed. > > > > Thanks, > > > > -- Jeff > > > > — > > Carlos Pignataro, car...@cisco.com > > *“Sometimes I use big words that I do not fully understand, to make myself > sound more photosynthesis."* > > > > > >
