Hi Robert, I think that much of the additional functionality you are proposing is beyond the scope of the draft and IGP BFD usage today. You could propose all these additional capabilities (e.g., MTU testing and link quality determination beyond what is already in BFD) in a separate draft. Thanks, Acee
From: Robert Raszuk <rob...@raszuk.net> Date: Sunday, February 6, 2022 at 6:11 AM To: Gyan Mishra <hayabusa...@gmail.com> Cc: Acee Lindem <a...@cisco.com>, Ketan Talaulikar <ketant.i...@gmail.com>, "lsr@ietf.org" <lsr@ietf.org> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04 Gyan, > Overall I believe the goal of the strict mode BFD “wait for BFD” is > accomplished > and solve all problems I do not agree with this statement. As currently defined in the posted version of the draft "wait for BFD" means wait for BFD control packets to bring the session up. The session comes up - yet no BFD Echo packets have been exchanged. That in turn triggers OSPF adj. to come up. So we bring OSPF adj UP knowing literally nothing about BFD test results over subject link. If the BFD timer is set to 2 seconds and the multiplier is 3 only in 6 seconds the BFD session could go down and take OSPF adj. down with it which means nothing what this draft aims to accomplish has been achieved. Sure one can argue if this is proper for BFD to signal UP state without at least once exchanging a set of Echo packets - but this is currently not the case in BFD FSM. If you want to "fix" BFD go for it, but for now the delay associated with any client action should be based on how BFD works per definition in RFC5880 and therefore should be specified on the client side. Rgs, Robert. On Sun, Feb 6, 2022 at 8:16 AM Gyan Mishra <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>> wrote: All I have finally caught up with this thread and I agree with Les, Ketan and Albert that the “wait for BFD” goal is accomplished with both the OSPF and BGP draft. There is extra verbiage in BGP draft in case BFD does not come up for BGP to wait. Agreed not applicable to OSPF. I agree with the spirit of Roberts idea of a delay as it would help as far as stability having a “pause” button for degraded links and quality issues, however I do agree with the WG that this is outside of LSRs scope and should really be with BFD or better yet IPPM for link quality monitoring. Overall I believe the goal of the strict mode BFD “wait for BFD” is accomplished and solve all problems except issues related to poor link quality issues. I support both the OSPF and BGP strict mode drafts and I think think this will be a big gain in itself for operators. As mentioned in the OSPF draft section 5 on use of hold down timers, BFD dampening and on ML use of carrier delay and interface dampening can help operators with link quality issues until we are able to make some headway in BFD and IPPM WG. I would be happy to work with Greg and IPPM WGs as a follow up to this thread related to link quality issues. Kind Regards Gyan
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
