Hi Ketan, > It explains the scenario of a noisy link that experiences traffic drops.
The point is that BFD may or may not detect noisy links or links with "degraded or poor quality". There are many failure scenarios - especially brownouts - where BFD will continue to run just fine over a link and where at the same time user data will experience very poor performance. So stating in the RFC that BFD may help to detect such cases is simply very misleading (to say it gently :). And you are stating so exactly in the below sentence: *"In certain other scenarios, a degraded or poor quality link will allow OSPF adjacency formation to succeed* *but the BFD session establishment will fail or the BFD session will flap.* Thx, R. On Sun, Jan 30, 2022 at 6:03 PM Ketan Talaulikar <ketant.i...@gmail.com> wrote: > Hi Robert, > > Thanks for your review and comments. > > This email is in response to your first point "overpromise". > > First, there is no text in the draft that "overpromises" that the strict > mode of operation detects "all forwarding" issues. We are talking about BFD > and its capabilities are well-known. It is not in the scope of this > document to discuss BFD capabilities and shortcomings (e.g. the MTU issue > you describe). > > The draft text that you have asked to remove is important. It explains the > scenario of a noisy link that experiences traffic drops. I am aware of > issues in production networks, where we've had OSPF adjacency flaps > continuously or sporadically due to OSPF adjacency coming up somehow but > then BFD bringing it down. This causes routing churn and service > degradation. This is one of the key drivers for this draft. > > However, welcome any text clarifications/suggestions for improving the > document. > > Thanks, > Ketan > >>
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
