Hi Reshad, your analysis of the text is absolutely correct. My concern is the possible analysis of the Discriminator by ingress LER and it comparing to My Discriminator of the received BFD control packets. According to the RFC 5884 both must match but because LSP Echo reply does not provide sufficient information the most likely outcome will be - no matching BFD session found and thus the text fails. (Yes, it would be rather naive implementation but ....). Thus I propose to add explicit statement for ingress LER not to use information if received Discriminator TLV in Echo reply.
Regards, Greg On Thu, Mar 22, 2018 at 3:39 PM, Reshad Rahman (rrahman) <[email protected]> wrote: > Hi, > > > > In the BFD meeting yesterday there was discussion about lack of clarity on > what the spec says wrt to the discriminator TLV being sent by the egress > node in the echo reply and that this causes interop issues. From RFC 5884: > > > > The egress LSR MAY respond with an LSP Ping Echo > > reply message that carries the local discriminator assigned by it for > > the BFD session. > > > > In the errata: > > 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. > > So I think it’s clear that this cannot be the discriminator of the ingress > node. I agree that this information is useless but still don’t see how it > can cause any harm, and any implementation which interprets the > discriminator in the echo reply differently is buggy IMHO. > > > > Regards, > > Reshad (hat off). > > > > *From: *Rtg-bfd <[email protected]> on behalf of "Reshad Rahman > (rrahman)" <[email protected]> > *Date: *Tuesday, March 20, 2018 at 5:49 PM > *To: *Greg Mirsky <[email protected]>, "Carlos Pignataro (cpignata)" < > [email protected]> > > *Cc: *"[email protected]" <[email protected]>, "[email protected]" < > [email protected]> > *Subject: *Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd- > bootstrap-clarify-00.txt > > > > Hi, > > > > While I agree that the echo reply is not needed to bootstrap BFD, and that > the BFD Disc TLV is not needed in the reply, doing this doesn’t break > anything. So I don’t see the proposed changes as being necessary. > > > > Does anyone remember why RFC5884 has the echo reply, was it to > potentially save an echo request from egress for bidirectional case? > > > > Also, if we do go ahead with the proposed changes in this draft, we’ll > have to fix this errata <https://www.rfc-editor.org/errata/eid5085>. > > > > Regards, > > Reshad (speaking as individual contributor). > > > > *From: *Rtg-bfd <[email protected]> on behalf of Greg Mirsky < > [email protected]> > *Date: *Friday, October 20, 2017 at 4:19 PM > *To: *"Carlos Pignataro (cpignata)" <[email protected]> > *Cc: *"[email protected]" <[email protected]>, "[email protected]" < > [email protected]> > *Subject: *Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd- > bootstrap-clarify-00.txt > > > > Hi Carlos, > > thank you for taking interest in the proposal, much appreciated. Please > find my notes in-line and tagged GIM>>. > > > > Regards, > > Greg > > > > On Fri, Oct 20, 2017 at 5:54 AM, Carlos Pignataro (cpignata) < > [email protected]> wrote: > > Greg, > > > > This document seems to say “use “Do not Reply” reply mode, and even if you > reply do not use the BFD Disc TLV, because it is not used. > > GIM>> To be precise it says "SHOULD use "Do not Reply" thus preserving > compliance of implementations that do otherwise. > > > > Wouldn’t it be simpler to say “follow RFC 8029, and the ingress does not > care about the BFD Disc TLV in the reply”? This would not suddenly make > uncompliant existing implementations, potentially. > > GIM>> I agree that normative language on handling echo reply is bit > restrictive. My goal is to have good discussion and see what others think.. > > > > Also I wonder if this should be bfd-mpls instead of mpls-bfd, given where > RFC 5884 was advanced. > > GIM>> Probably it should be the way you've suggested. Hope it is not a big > problem for individual draft. > > > > Thanks, > > > > — > Carlos Pignataro, [email protected] > > *“Sometimes I use big words that I do not fully understand, to make myself > sound more photosynthesis."* > > > > On Oct 18, 2017, at 8:50 AM, Greg Mirsky <[email protected]> wrote: > > > > Dear All, > > this new document proposes clarification of two questions brought up in > course of recent discussion of RFC 5884: > > - use of Return mode values in bootstrapping BFD session echo request; > - inclusion of BFD Discriminator TLV in echo response to the > bootstrapping echo request. > > Your comments, questions are always welcome and greatly appreciated. > > > > Regards, > > Greg > > > > ---------- Forwarded message ---------- > From: <[email protected]> > Date: Wed, Oct 18, 2017 at 5:46 AM > Subject: New Version Notification for draft-mirsky-mpls-bfd- > bootstrap-clarify-00.txt > To: Gregory Mirsky <[email protected]>, Yanhua Zhao < > [email protected]> > > > > A new version of I-D, draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt > has been successfully submitted by Greg Mirsky and posted to the > IETF repository. > > Name: draft-mirsky-mpls-bfd-bootstrap-clarify > Revision: 00 > Title: Clarifying Use of LSP Ping to Bootstrap BFD over MPLS LSP > Document date: 2017-10-18 > Group: Individual Submission > Pages: 4 > URL: https://www.ietf.org/internet- > drafts/draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt > Status: https://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd- > bootstrap-clarify/ > Htmlized: https://tools.ietf.org/html/draft-mirsky-mpls-bfd- > bootstrap-clarify-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-mpls- > bfd-bootstrap-clarify-00 > > > Abstract: > This document, if approved, updates RFC 5884 by clarifying procedures > for using MPLS LSP ping to bootstrap Bidirectional Forwarding > Detection (BFD) over MPLS Label Switch Path. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > mpls mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mpls > > > > >
