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) <a...@cisco.com> 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 <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> 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
