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 <hayabusa...@gmail.com> 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= > 40cisco....@dmarc.ietf.org> 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 <rob...@raszuk.net> >> *Date: *Thursday, February 10, 2022 at 10:57 AM >> *To: *Acee Lindem <a...@cisco.com> >> *Cc: *"lsr@ietf.org" <lsr@ietf.org>, " >> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" < >> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org> >> *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= >> 40cisco....@dmarc.ietf.org> 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 <lsr-boun...@ietf.org> on behalf of "Acee Lindem (acee)" >> <acee=40cisco....@dmarc.ietf.org> >> *Date: *Thursday, January 27, 2022 at 12:09 PM >> *To: *"lsr@ietf.org" <lsr@ietf.org> >> *Cc: *"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" < >> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org> >> *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 >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
