Speaking as Document Shepherd: Hi Robert,
From: Robert Raszuk <[email protected]> Date: Saturday, January 29, 2022 at 11:15 AM To: Ketan Talaulikar <[email protected]> Cc: lsr <[email protected]>, "[email protected]" <[email protected]>, Albert Fu <[email protected]>, Acee Lindem <[email protected]> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04 Hi Ketan and all, I support this draft - it is a useful addition. There are two elements which I would suggest to adjust in the text before publication. #1 Overpromise Even below you say: > Since there is a issue with forwarding (which is what BFD detects) and in the text we see: "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." Reader may get an impression that if he enables strict mode he is 100% safe. Sure he is safer then before but not 100% safe. Can you suggest text which with you’d be happy? I’m sure the authors would add you to the acknowledgements. Real networks prove that there are classes of failures which BFD can not detect. And Albert knows them too :) For example some emulated circuits can experience periodic drops only at some MTUs and only when link utilization reaches X %. While there is ongoing extension to BFD to fill it with payload I don't think that BFD can be useful to also saturate say in 80% 10G link with probes to test it well before allowing OSPF to be established. #2 Timer What I find missing in the draft is a mutually (between OSPF peers) timer fired after BFD session is up which in OSPF could hold on allowing BFD to do some more testing before declaring adj to be established. I think just bringing OSPF adj immediately after the BFD session is up is not a good thing. Keep in mind that we are bringing the interface up so by applying such a timer we are not dropping packets .. in fact quite the reverse we are making sure user packets would not be dropped. 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. Thanks, Acee Cheers, Robert
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
