Hi Carlos, if the group agrees that I'm overparanoid I'll accept that and forever hold my peace.
Regards, Greg On Thu, Mar 22, 2018, 7:00 PM Carlos Pignataro (cpignata) < [email protected]> wrote: > Hi, Greg, > > > > That, to me, reads like over-specifying. Are you aware of any > implementation attempting to do that? > > > > There’s no text for that comparison – why would an implementation do that? > > > > Thanks, > > > > Carlos. > > > > *From: *Greg Mirsky <[email protected]> > *Date: *Thursday, March 22, 2018 at 12:18 PM > *To: *"Reshad Rahman (rrahman)" <[email protected]> > *Cc: *Carlos Pignataro <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]> > *Subject: *Re: [mpls] New Version Notification for > draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt > > > > 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 > > > > > > >
