Hi Robert, There is no tunnel for an OSPF virtual link, the transit area will require leaking of backbone routes without summarization. Also note that the virtual link endpoint could be reachable in the transit area but may not be up. Multi-hop BFD would still be useful for a virtual link. Thanks, Acee
From: Robert Raszuk <[email protected]> Date: Friday, February 4, 2022 at 12:48 PM To: Muthu Arul Mozhi Perumal <[email protected]> Cc: Ketan Talaulikar <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, Acee Lindem <[email protected]> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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) <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
