Thanks everyone for getting the errata to where it is. Working through the thread, I tend to agree that we have a few nits that need to be resolved long-term, but I think the errrata gets us most of the way there for purposes of clarifying the bulk of the behavior. That said, I think we're at a point where getting a -bis done probably makes sense.
- Incorporate the consensus we've distilled down in the errata. - Address lingering items - Most importantly, IMO, get an RFC with a REPLACES/UPDATES into the RFC series. Errata are great for small things, but I don't think they help with things long-term. The immediate question to my mind is who'd be the initial editor for such a -bis. Given that this is an existing document with a few semi-active authors left (Hi, Kireeti!), I think first dibs on such an editor role would go to them. Failing that, we need to select an editor. -- Jeff On Sat, Dec 16, 2017 at 02:48:00PM +0000, Balaji Rajagopalan wrote: > Hi Greg, > > Just responding to this point: > > >> Whether egress LSR must reply is defined by the value of the Reply Mode > >> field and it is absolutely valid to set the field to Do not reply. > > Yes. The revised text points to the base RFC for compliance. So, the sender > of LSP-Ping Echo request can still exercise this option. IOW, the revised > text does not preclude the above option. What needed to be clarified was > that the receiver of the LPS-Ping request message cannot implicitly assume > lack of interest on the sender’s part in receiving a reply, just by the > presence of the discriminator. > > Agree with your point about the RFC & errata not specifying how the sender > should handle mismatch. > > -- > Balaji Rajagopalan > > > > From: Greg Mirsky <gregimir...@gmail.com> > Date: Saturday, 16 December 2017 at 3:33 AM > To: "BRUNGARD, DEBORAH A" <db3...@att.com> > Cc: Kireeti Kompella <kire...@juniper.net>, Balaji Rajagopalan > <bala...@juniper.net>, Jeffrey Haas <jh...@pfrc.org>, "Carlos Pignataro > (cpignata)" <cpign...@cisco.com>, "ginsb...@cisco.com" <ginsb...@cisco.com>, > Thomas Nadeau <tnad...@lucidvision.com>, mpls <m...@ietf.org>, "Reshad Rahman > (rrahman)" <rrah...@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org> > Subject: Re: [Technical Errata Reported] RFC5884 (5085) > > Hi Deborah, et. al, > I agree with the final text though I cannot agree with the Notes where > stating: > Technically, the reply cannot be optional, because the egress needs to report > LSP-Ping verification status to the ingress. > The proposed text recommends to include BFD discriminator in the reply. This > was the intent of the original text. > Whether egress LSR must reply is defined by the value of the Reply Mode field > and it is absolutely valid to set the field to Do not reply. As for inclusion > of BFD discriminator in the reply message, I believe, that RFC 5884 and the > Errata leave an open question of ingress LSR action upon receiving the reply > with BFD discriminator allocated by the egress. We had started discussion in > Singapore during the presentation of draft-mirsky-mpls-bfd-bootstrap-clarify. > Doing RFC5884bis may be the better option rather than multiplicity of Erratas. > > Best regards, > Greg > > On Fri, Dec 15, 2017 at 2:50 PM, BRUNGARD, DEBORAH A > <db3...@att.com<mailto:db3...@att.com>> wrote: > Hi Kireeti, > > Other than doing a revised RFC, this is the (only) way to correct an error, > then when the RFC is revised, all the errata need to be included/reviewed. > > As for implementers, the current Errata is shown as a hyperlink next to the > RFC number. Hopefully, an implementer (and all users) check this. > > Thanks for responding😊 I’ll interpret silence of the others over this past > month as agreement and make the changes. > > Deborah > > > From: Kireeti Kompella > [mailto:kire...@juniper.net<mailto:kire...@juniper.net>] > Sent: Wednesday, December 13, 2017 3:54 PM > To: BRUNGARD, DEBORAH A <db3...@att.com<mailto:db3...@att.com>> > Cc: Balaji Rajagopalan <bala...@juniper.net<mailto:bala...@juniper.net>>; > Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>; Jeffrey > Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>>; Carlos Pignataro (cpignata) > <cpign...@cisco.com<mailto:cpign...@cisco.com>>; > ginsb...@cisco.com<mailto:ginsb...@cisco.com>; Thomas Nadeau > <tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>>; mpls > <m...@ietf.org<mailto:m...@ietf.org>>; Reshad Rahman (rrahman) > <rrah...@cisco.com<mailto:rrah...@cisco.com>>; > rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org> > > Subject: Re: [Technical Errata Reported] RFC5884 (5085) > > Hi Deborah, > > I’m fine with Balaji’s proposal. > > As I said, I’m fine with an erratum, but I leave it to the iesg/rfc editor > which would be more effective from the point of view of ensuring that future > implementations follow this change. > Kireeti > > On Dec 12, 2017, at 22:57, BRUNGARD, DEBORAH A > <db3...@att.com<mailto:db3...@att.com>> wrote: > Hi, > > I’ve not seen a reply to Balaji’s proposal? It’s a slight tweak to Les’s on > 10/4. > > I agree we can do this as an Errata. I can fix the proposal in Errata 5085, > just need agreement on what you want to do. > > Deborah > > > From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Balaji Rajagopalan > Sent: Tuesday, November 07, 2017 8:00 AM > To: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>; > Kireeti Kompella <kire...@juniper.net<mailto:kire...@juniper.net>>; Jeffrey > Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>>; Carlos Pignataro (cpignata) > <cpign...@cisco.com<mailto:cpign...@cisco.com>>; > ginsb...@cisco.com<mailto:ginsb...@cisco.com> > Cc: Thomas Nadeau <tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>>; > mpls <m...@ietf.org<mailto:m...@ietf.org>>; Reshad Rahman (rrahman) > <rrah...@cisco.com<mailto:rrah...@cisco.com>>; > rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org> > Subject: Re: [mpls] [Technical Errata Reported] RFC5884 (5085) > > Hi, > > From the discussions, I could list down four changes: > > - Explicitly state compliance to RFC 8029 > - Re-arrange the text so LSP-Ping description follows BFD > - Remove the redundant comma > - Explicitly mention that LSP-Ping reply optionally carries a > discriminator. This was the key change I wanted to propose. Section 6.1 does > not state whether the discriminator in the LSP-Ping reply is mandatory or > optional. Section 6 has ambiguity in the text, which the proposed text seeks > to address. > > The following text replaces the last two paragraphs of section 6: > > <begin> > > 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 processes the LSP Ping Echo request message in accordance with > the procedures defined in [RFC 8029]. The LSP Ping Echo reply message > generated by the egress LSR MAY carry the local discriminator assigned by it > for the BFD session, as specified in section 6.1. > > <end> > > -- > Balaji Rajagopalan > > > > From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> > Date: Saturday, 9 September 2017 at 3:16 AM > To: Balaji Rajagopalan <bala...@juniper.net<mailto:bala...@juniper.net>> > Cc: Mach Chen <mach.c...@huawei.com<mailto:mach.c...@huawei.com>>, "Carlos > Pignataro (cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, > Jeffrey Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>>, Kireeti Kompella > <kire...@juniper.net<mailto:kire...@juniper.net>>, Thomas Nadeau > <tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>>, > "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" > <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>, "Reshad Rahman (rrahman)" > <rrah...@cisco.com<mailto:rrah...@cisco.com>>, Alia Atlas > <akat...@gmail.com<mailto:akat...@gmail.com>> > Subject: Re: [Technical Errata Reported] RFC5884 (5085) > > Hi Balaj, > I think that we need help from WG chairs to find the best way to handle this > case. The original Errata that triggered this very helpful discussion propsed > the following new 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. > Your new proposal is very much different: > The egress LSR MUST follow the procedures described in [RFC4379] in > processing the LSP Ping request. The LSP Ping reply generated by the egress > MAY carry the local discriminator assigned by it for the BFD session. > I agree with latter but think that text proposed by Les goes further in > clarifying bootstrapping of BFD session. Perhaps the question is not only in > improving the 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. > but making the whole RFC 5884 clearer by drafting 5884bis. I 'd propose two > questions to continue the discussion: > > * would 5884bis recommend use of particular Reply mode in echo request > with BFD Discriminator TLV; > * whether echo reply includes BFD Discriminator it the Reply mode is set > to one of values that commands to send the reply. > To the first I propose to consider that the ingress LER SHOULD set Reply mode > to No reply. And to the second that the ingress LER SHOULD NOT include BFD > Discriminator TLV when sending echo reply to the BFD session bootstrapping > LSP ping. > > Regards, > Greg > > On Tue, Sep 5, 2017 at 6:06 AM, Balaji Rajagopalan > <bala...@juniper.net<mailto:bala...@juniper.net>> wrote: > Hi Greg, > > While all the issues you bring up are valid, the change I had proposed merely > makes a minor correction to improve textual clarity. There was no attempt to > alter the protocol in any way. > > I think both the following aspects are non-trivial, and are beyond the scope > of errata. Perhaps, these issues are better addressed in a “-bis”. > > - Removal of BFD-disc from the LSP-Ping reply. I defer to Kireeti & > other authors of the RFC to comment/decide whether BFD-disc can be removed > from the reply. > - Rules to specify handling of mismatch between BFD-disc in the > LSP-Ping reply & the BFD session > > -- > Balaji Rajagopalan > > > From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> > Date: Wednesday, 23 August 2017 at 7:51 AM > To: Balaji Rajagopalan <bala...@juniper.net<mailto:bala...@juniper.net>> > Cc: Mach Chen <mach.c...@huawei.com<mailto:mach.c...@huawei.com>>, "Carlos > Pignataro (cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, > Jeffrey Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>>, Kireeti Kompella > <kire...@juniper.net<mailto:kire...@juniper.net>>, Thomas Nadeau > <tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>>, > "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" > <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>, "Reshad Rahman (rrahman)" > <rrah...@cisco.com<mailto:rrah...@cisco.com>>, Alia Atlas > <akat...@gmail.com<mailto:akat...@gmail.com>> > > Subject: Re: [Technical Errata Reported] RFC5884 (5085) > > Hi Balaji, > I've been thinking about the value of including BFD Discriminator TLV in echo > reply sent by egress. What we'd expect ingress to do upon receiving the > reply? Match to bfd.remoteDiscr? I think that then echo reply must include > the value from the original BFD Discriminator TLV so that ingress uses it to > demux BFD sessions. Or ingress doesn't validate the value in BFD > Discriminator TLV but only that the TLV is included in reply? If we leave > actions of the ingress upon receipt of the reply with BFD Discriminator > underspecified it may result in another set of interoperability issues. > Perhaps the simplest way to avoid that would be to not allow BFD > Discriminator TLV in the reply. > > Regards, > Greg > > On Tue, Aug 22, 2017 at 2:16 AM, Balaji Rajagopalan > <bala...@juniper.net<mailto:bala...@juniper.net>> wrote: > That sounds better. How about the following text? > > The egress LSR MUST follow the procedures described in [RFC4379] in > processing the LSP Ping request. The LSP Ping reply generated by the egress > MAY carry the local discriminator assigned by it for the BFD session. > > -- > Balaji Rajagopalan > > From: Mach Chen <mach.c...@huawei.com<mailto:mach.c...@huawei.com>> > Date: Thursday, 17 August 2017 at 8:45 AM > To: "Carlos Pignataro (cpignata)" > <cpign...@cisco.com<mailto:cpign...@cisco.com>>, Balaji Rajagopalan > <bala...@juniper.net<mailto:bala...@juniper.net>>, Greg Mirsky > <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, Jeffrey Haas > <jh...@pfrc.org<mailto:jh...@pfrc.org>> > Cc: Kireeti Kompella <kire...@juniper.net<mailto:kire...@juniper.net>>, > Thomas Nadeau <tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>>, > "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" > <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>, "Reshad Rahman (rrahman)" > <rrah...@cisco.com<mailto:rrah...@cisco.com>>, Alia Atlas > <akat...@gmail.com<mailto:akat...@gmail.com>> > Subject: RE: [Technical Errata Reported] RFC5884 (5085) > > Indeed, I also like Les’s suggestion! > > Best regards, > Mach > > From: Rtg-bfd > [mailto:rtg-bfd-boun...@ietf.org<mailto:rtg-bfd-boun...@ietf.org>] On Behalf > Of Carlos Pignataro (cpignata) > Sent: Wednesday, August 16, 2017 10:20 PM > To: Balaji Rajagopalan <bala...@juniper.net<mailto:bala...@juniper.net>>; > Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>; Jeffrey > Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>> > Cc: Kireeti Kompella <kire...@juniper.net<mailto:kire...@juniper.net>>; > Thomas Nadeau <tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>>; > rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>; Reshad Rahman (rrahman) > <rrah...@cisco.com<mailto:rrah...@cisco.com>>; Alia Atlas > <akat...@gmail.com<mailto:akat...@gmail.com>> > Subject: Re: [Technical Errata Reported] RFC5884 (5085) > > This sounds like a good summary of the tactical fix. > > (Although, like Les wrote down, saying “MUST follow [LSP-Ping]” is better > than “MUST Send a Reply”) > > As an aside -- When it comes to Interop, I remember also issues around the > UDP Port on the egress BFD Control packet, depending on whether the response > is IP-based vs. over an MPLS LSP. Tracking this down, this was identified at > https://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00447.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_rtg-2Dbfd_current_msg00447.html&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=H6rQa_WisJtG2nGx-kOD0r0EF0bSm7KfoMzouNR6nBI&s=sev9d10du5VFV_jwTtQJYZfbaVnRmHM1mFLGIOAkwUc&e=> > (comments on Sections 6 and 7), and it seems, we may have the right bug but > a wrong fix. > > Thanks, > > -- Carlos. > > From: Rtg-bfd <rtg-bfd-boun...@ietf.org<mailto:rtg-bfd-boun...@ietf.org>> on > behalf of Balaji Rajagopalan <bala...@juniper.net<mailto:bala...@juniper.net>> > Date: Wednesday, August 16, 2017 at 1:23 AM > To: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, Jeff > Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>> > Cc: Kireeti Kompella <kire...@juniper.net<mailto:kire...@juniper.net>>, Tom > Nadeau <tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>>, > "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" > <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>, "Reshad Rahman (rrahman)" > <rrah...@cisco.com<mailto:rrah...@cisco.com>>, Alia Atlas > <akat...@gmail.com<mailto:akat...@gmail.com>> > Subject: Re: [Technical Errata Reported] RFC5884 (5085) > > I’m aware of three different behaviours from three different vendors that I > came across in the course of inter-op: > - Always respond to an LSP-Ping request carrying a BFD disc > - Never send a response to an LSP-Ping request carrying a BFD disc > - Don’t respond to the first LSP-Ping request carrying a BFD disc, > but respond to the subsequent ones > > > This experience leads me to believe that this procedure is NOT > well-understood. So, publication of errata on this issue is necessary. > > As some of the co-authors have clarified in further emails, inclusion of BFD > discriminator in the LSP-Ping request does not change LSP-Ping’s basic > function. So, the egress must send a reply. This is what the erratum > clarifies. > > -- > Balaji Rajagopalan > > > > From: Rtg-bfd <rtg-bfd-boun...@ietf.org<mailto:rtg-bfd-boun...@ietf.org>> on > behalf of Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> > Date: Friday, 11 August 2017 at 11:42 PM > To: Jeffrey Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>> > Cc: Kireeti Kompella <kire...@juniper.net<mailto:kire...@juniper.net>>, > Thomas Nadeau <tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>>, > "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" > <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>, "Reshad Rahman (rrahman)" > <rrah...@cisco.com<mailto:rrah...@cisco.com>>, Alia Atlas > <akat...@gmail.com<mailto:akat...@gmail.com>> > Subject: Re: [Technical Errata Reported] RFC5884 (5085) > > Re-sending to the corrected list (apologies for duplicates). > > Dear All, > I suggest to reject this proposal. The current text is clear and the > mechanics of bootstrapping BFD session over MPLS LSP is well understood - > remote peer MUST start sending BFD control packets first and BFD peer MAY > send Echo Reply with its Local Discriminator as value in BFD Discriminator > TLV. > > Regards, > Greg > > > On Fri, Aug 11, 2017 at 10:39 AM, Jeffrey Haas > <jh...@pfrc.org<mailto: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. > > > > 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. > > 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. > > -- Jeff > > > >
