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 On Sun, Jan 30, 2022 at 12:54 AM Robert Raszuk <[email protected]> wrote: > Hi Acee, > > Can you suggest text which with you’d be happy? I’m sure the authors would >> add you to the acknowledgements. >> > > Actually instead of suggesting any new text I would suggest to delete the > two below sentences and it will be fine: > > *"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. In this case, traffic that gets * > *forwarded over such a link may experience packet drops while the failure > of the BFD session establishment * > *would not enable fast routing convergence if the link were to go down or > flap."* > > This could be described but I don’t think it should be normative. This >> begs the question as to why a hold down timer is not a part of the BFD >> protocol itself. >> > > There is one - BFD calls it multiplier. > > But the timer I am suggesting is not related to BFD operation, but to OSPF > (and/or ISIS). It is not about BFD sessions being UP or DOWN. It is about > allowing BFD for more testing (with various parameters (for example > increasing test packet size in some discrete steps) before OSPF is happy to > bring the adj. up. > > Thx, > R. > >>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
