Hi Robert Would this BFD strict mode apply to unsolicited BFD of which you are author?
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited-03 I think if applicable I think would be a good idea. Many Thanks Gyan On Thu, Feb 10, 2022 at 10:59 AM Acee Lindem (acee) <acee= [email protected]> wrote: > Hi Robert, > > This is great to hear – I thought you wanted to make this required for > implementation as opposed to a recommendation. > > Thanks, > > Acee > > > > *From: *Robert Raszuk <[email protected]> > *Date: *Thursday, February 10, 2022 at 10:57 AM > *To: *Acee Lindem <[email protected]> > *Cc: *"[email protected]" <[email protected]>, " > [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 > > > > Hi Acee, > > > > > There was debate regarding making the delay timer described in section 5 > a normative requirement. > > > > I see added into new version of the draft the following text into section > 5: > > > > The use of OSPF BFD strict- > mode along with mechanisms such as hold-down > *(a delay in the initial OSPF adjacency bringup following BFD session > establishment)* and/or > dampening > *(a delay in the OSPF adjacency bringup following failure detected by > BFD)* may help reduce the frequency of adjacency flaps and > therefore reduce the associated routing churn. > > > > Not sure if this is normative or informative, but it addresses my point. > > > > Thx, > > Robert. > > > > On Thu, Feb 10, 2022 at 4:50 PM Acee Lindem (acee) <acee= > [email protected]> wrote: > > The WG last call has all but ended and we’ve had a lot of support, two > implementations, and some good discussion. Please review the -05 version of > the draft reflecting including changes reflecting this discussion. There > was debate regarding making the delay timer described in section 5 a > normative requirement. The consensus was to not make this a normative part > of the specification. I feel this is the right decision – especially given > that this is new functionality being requested at Working Group Last Call > and implementations accomplish the dampening in vary ways. > > > > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/ > > > > Thanks, > > Acee > > > > *From: *Lsr <[email protected]> on behalf of "Acee Lindem (acee)" > <[email protected]> > *Date: *Thursday, January 27, 2022 at 12:09 PM > *To: *"[email protected]" <[email protected]> > *Cc: *"[email protected]" < > [email protected]> > *Subject: *[Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - > draft-ietf-lsr-ospf-bfd-strict-mode-04 > > > > LSR WG, > > > > This begins a two week last call for the subject draft. Please indicate > your support or objection on this list prior to 12:00 AM UTC on February 11 > th, 20222. Also, review comments are certainly welcome. > > Thanks, > Acee > > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
