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. 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. Cheers, Robert
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
