Excellent!
Many Thanks Gyan On Sun, Feb 13, 2022 at 3:19 PM Robert Raszuk <[email protected]> wrote: > Gyan, > > The OSPF draft you quote does not make any assumptions nor restrictions on > how BFD session itself is setup. > > So yes procedures described in draft-ietf-bfd-unsolicited could be used as > a way to bring up BFD session between peers. > > Rgs, > R. > > > On Sun, Feb 13, 2022 at 9:05 PM Gyan Mishra <[email protected]> wrote: > >> >> 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* >> >> -- <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
