Understood as it only applies to Classical BFD with 3 way handshake which would preclude S-BFD which does not have 3-way handshake and I believe that is why it does not apply.
Once the session is up per RFC 588O the session switches to Demand mode with D bit and initiate Poll sequence P bit and F bit in the control packet. So as Demand mode uses Poll sequence for liveliness detection and not default asynchronous mode it is not applicable. Agreed. Should we state in the unsolicited BFD specification that they are not applicable. Also I believe multihop BFD would be applicable. Should that be stated in the specification. Thanks Gyan On Sun, Feb 20, 2022 at 12:02 PM Reshad Rahman <res...@yahoo.com> wrote: > Hi Gyan, > > As stated below, this document specifies how classical BFD (RFC5880) > sessions can be initiated only by 1 side. This is orthogonal to use of > demand mode or echo mode in BFD (which can be used once the sessions are > up, whether "unsolicited BFD" has been used or not). > > S-BFD has its own procedures for bring-up, and unsolicited BFD only > applies to classical BFD (RFC5880). This is mentioned in the introduction. > > Regards, > Reshad. > > On Sunday, February 13, 2022, 02:59:46 PM EST, 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*
