Robert – Part of the reason this discussion is long is because we continue to discuss things that are out of scope for the draft in question.
There is nothing in RFC 5880 (nor in, what I consider to be even more relevant, RFC 5882) that requires a BFD implementation to signal UP state to a BFD client within a specific time following transition of the BFD state machine to UP . An implementation is free to introduce a delay (as you suggest) before such signaling. By insisting that OSPF has a responsibility in this regard you place the burden on the BFD client – which is architecturally the wrong place to do it. Let’s move this draft forward as it does an excellent job of defining the OSPF behavior necessary to support strict-mode – and that is all it is trying to do and all that it should be doing. If you feel that there are operational considerations regarding the use of BFD that require additional specification, I suggest you ask the BFD WG to take up this work. Les From: Lsr <[email protected]> On Behalf Of Robert Raszuk Sent: Sunday, February 6, 2022 5:11 AM To: Acee Lindem (acee) <[email protected]> Cc: Ketan Talaulikar <[email protected]>; Gyan Mishra <[email protected]>; [email protected] Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04 Hello Acee, I am afraid you completely missed my point. Perhaps this is my fault as in this way too looong email thread I indeed brought additional testing requirements - but never said those need to be part of this draft nor specified in LSR WG. Those were just examples on what can occur in this delta time we are talking about. I am not asking for any additional BFD capabilities at all in respect to this draft. I 100% agree those are out of scope of LSR WG. I am asking to let at least vanilla BFD probing cycle** to occur (at least once) before doing any action on the client side. Doing any action on the client/protocol just because BFD control packets to setup the session got exchanged is a wrong thing to do. When BFD control packets brought the session UP BFD probing did not even occur yet. That's it. Subtle yet extremely important point. ** Cycle == probing frequency x multiplier - basic BFD parameters. Many thx, R. On Sun, Feb 6, 2022 at 1:51 PM Acee Lindem (acee) <[email protected]<mailto:[email protected]>> wrote: 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 <[email protected]<mailto:[email protected]>> Date: Sunday, February 6, 2022 at 6:11 AM To: Gyan Mishra <[email protected]<mailto:[email protected]>> Cc: Acee Lindem <[email protected]<mailto:[email protected]>>, Ketan Talaulikar <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
