Hi Reshad We discussed OSPF strict mode and that is a change to OSPF to run in strict mode meaning allow BFD to come up before OSPF, and I asked Robert Raszuk on that drafts WGLC and we agreed that unsolicited BFD is not applicable to strict mode.
In theory the thought was with unsolicited BFD to 3rd party next hop that is out of the administrative control or 100s of compute nodes in passive mode and other initiating end is in active mode the idea was that maybe strict mode could apply to the active side but because strict mode has to be applied to both ends it ends up being not applicable. Also point made was that OSPF Strict BFD is a change to OSPF behavior and no change to BFD behavior. So overall not applicable. So I am all set here. Kind Regards Gyan On Sun, Feb 20, 2022 at 12:07 PM Reshad Rahman <res...@yahoo.com> wrote: > Hi Gyan, > > BFD strict mode below specifies how OSPF signals its requirement for BFD > to be up. If you have OSPF at each end, no need for "unsolicited BFD". > > Regards, > Reshad. > > On Sunday, February 13, 2022, 03:03:19 PM EST, Gyan Mishra < > hayabusa...@gmail.com> wrote: > > > > Hi Reshad > > Also I think unsolicited BFD should apply as well to BFD strict mode. > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode > > I will comment on that thread. > > Kind Regards > > Gyan > > On Sun, Feb 13, 2022 at 2:59 PM Gyan Mishra <hayabusa...@gmail.com> wrote: > > > Hi Reshad > > Could this unsolicited BFD concept be applied to S-BFD RFC 7880, 7881, > 7885? > > Also could it be applied to RFC 5880 demand mode? > > I will review through the draft again for any further comments. > > Many Thanks > > Gyan > > > On Sun, Feb 13, 2022 at 12:04 PM Reshad Rahman <res...@yahoo.com> wrote: > > Hi Gyan, > > Apologies for the delay and thanks for the feedback. > > The document is applicable to single-hop and multi-hop. In the next > revision, we will clarify this and extend the YANG model to include > multi-hop. > > The "unsolicited BFD" procedure allows a BFD session to be initiated only > by 1 side. Once that BFD session is up, demand mode may or may not kick in, > just like for RFC5880 BFD. So unsolicited BFD and demand mode are > orthogonal. > > The procedures in this document apply to RFC5880, aka classical, BFD. > S-BFD session bringup is different, requires sharing S-BFD discriminators > etc (as mentioned in the Introduction). > > Wrt which RFCs are updated by this document: we need to add 9127 (or > 9127-bis). > > Regards, > Reshad. > > On Sunday, January 2, 2022, 12:47:22 AM EST, Gyan Mishra < > hayabusa...@gmail.com> wrote: > > > > Dear Authors > > This is a very useful specification for operators. > > Is this draft applicability for single hop, multi hop, demand and S-BFD > sessions. > > Also what RFC’s does this draft update? > > Kind Regards > > Gyan > -- > > <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* > > -- > > <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* > > -- > > <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* > > -- <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*
