Hi Ketan, Thanks for your response..
The draft says: <snip> This document defines the B-bit in the LLS Type 1 Extended Options and Flags field. This bit is defined for the LLS block included in Hello and Database Description (DD) packets and *indicates that BFD is enabled on the link* and that the router requests strict-mode for BFD. </smip> You don't enable multi-hop BFD on a link, instead you enable it b/w two (multi-hop) routers, right? How about replacing it with: indicates that (1) single-hop BFD [RFC5881] is enabled on the link in case of point-to-point (numbered) and LAN interfaces, and (2) multi-hop BFD [RFC5883] is enabled between the neighbors in case of virtual links and point-to-point unnumbered interfaces. Also, add a note at the beginning of the draft that BFD refers to both single-hop and multi-hop BFD when not explicitly specified.. Regards, Muthu On Sun, Jan 30, 2022 at 10:40 PM Ketan Talaulikar <ketant.i...@gmail.com> wrote: > Hi Muthu, > > Thanks for your review and your support. > > Regarding your question, I would like to clarify that this document > doesn't specify BFD operations with OSPF. That was done by RFC5882. Indeed > for virtual links, there would need to be a BFD multi-hop session and the > same would apply to p-t-p unnumbered. > > However, I am not sure what specific applicability or operations need to > be called out for Strict Mode of operations for those links. > > Thanks, > Ketan > > > On Sun, Jan 30, 2022 at 12:52 PM Muthu Arul Mozhi Perumal < > muthu.a...@gmail.com> wrote: > >> Hi, >> >> I support the draft. A quick question: >> Should it describe the applicability of the mechanism over OSPF virtual >> links and unnumbered interfaces? With virtual links, one would have to >> establish a multi-hop BFD session, so it is slightly different from a BFD >> operational standpoint. For e.g, capability to support single-hop BFD may >> not translate to the capability to support multi-hop BFD.. >> >> Regards, >> Muthu >> >> On Thu, Jan 27, 2022 at 10:38 PM Acee Lindem (acee) <acee= >> 40cisco....@dmarc.ietf.org> wrote: >> >>> 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
