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> 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
