Muthu, If you are using virtual link why is this still multihop BFD ?
Thx, R. On Fri, Feb 4, 2022 at 6:22 PM Muthu Arul Mozhi Perumal < muthu.a...@gmail.com> wrote: > Hi Ketan, > > Sure, looking forward to the clarification in the draft on multi-hop BFD.. > > Just curious, are there interoperable implementations for OSPF multi-hop > BFD strict mode for virtual links or p2p unnumbered interfaces? > > Regards, > Muthu > > On Fri, Feb 4, 2022 at 5:36 PM Ketan Talaulikar <ketant.i...@gmail.com> > wrote: > >> Hi Muthu, >> >> When we say a "link" here, it is in the context of the OSPF interface and >> neighbor FSM. My understanding is that this term includes virtual links as >> well. As such, we can add some text in the introduction section to clarify >> the same and also put a reference to RFC5883 for BFD multi-hop use for >> VLINKs. >> >> I hope that works for you. >> >> Thanks, >> Ketan >> >> >> On Wed, Feb 2, 2022 at 11:05 AM Muthu Arul Mozhi Perumal < >> muthu.a...@gmail.com> wrote: >> >>> 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 11th, 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 >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
