Ahh ok .. this is "OSPF virtual link" not an emulated "virtual link" seen as p2p to any routing protocol.
Thx, R. On Fri, Feb 4, 2022 at 7:14 PM Acee Lindem (acee) <a...@cisco.com> wrote: > 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 <rob...@raszuk.net> > *Date: *Friday, February 4, 2022 at 12:48 PM > *To: *Muthu Arul Mozhi Perumal <muthu.a...@gmail.com> > *Cc: *Ketan Talaulikar <ketant.i...@gmail.com>, "lsr@ietf.org" < > lsr@ietf.org>, "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" < > draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>, Acee Lindem <a...@cisco.com > > > *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 < > 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 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 > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
