Hi Muthu, We don't use virtual-links nor unnumbered links in our network.
I checked the Junos and XR codes on our lab routers. I found that both do not support BFD over virtual-link. I believe virtual-link is not common, that might explain the lack of feature support. I did test OSPF BFD Strict mode for unnumbered link between Junos and XR. It work as per this draft, in that BFD must be operational before OSPF is allowed to come up. (* btw, you need to configure the hidden knob "backward-compatible-unnumbered-mask" on Junos router in order to interop OSPF unnumbered link with Cisco *). Thanks Albert From: [email protected] At: 02/08/22 09:44:32 UTC-5:00To: Albert Fu (BLOOMBERG/ 120 PARK ) , [email protected] Cc: [email protected], [email protected], [email protected] Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04 Hi Muthu, I don't have the data for BFD strict-mode interop over virtual links. However, p2p unnumbered is commonly deployed and I'll let my co-author clarify on interop. Thanks, Ketan On Fri, Feb 4, 2022 at 10:52 PM Muthu Arul Mozhi Perumal <[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]> 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]> 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]> 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]> 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]> 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] https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
