Hi Robert, From: Robert Raszuk <rob...@raszuk.net> Date: Saturday, January 29, 2022 at 2:25 PM To: Acee Lindem <a...@cisco.com> Cc: Ketan Talaulikar <ketant.i...@gmail.com>, lsr <lsr@ietf.org>, "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>, Albert Fu <af...@bloomberg.net> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
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." That would be fine with me but I’ll defer to the authors. 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. I don’t anyone has implemented the later capability. This MTU test extension could be added in a separate draft if there were a strong requirement. Thanks, Acee Thx, R.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
