All I have finally caught up with this thread and I agree with Les, Ketan and Albert that the “wait for BFD” goal is accomplished with both the OSPF and BGP draft. There is extra verbiage in BGP draft in case BFD does not come up for BGP to wait. Agreed not applicable to OSPF.
I agree with the spirit of Roberts idea of a delay as it would help as far as stability having a “pause” button for degraded links and quality issues, however I do agree with the WG that this is outside of LSRs scope and should really be with BFD or better yet IPPM for link quality monitoring. Overall I believe the goal of the strict mode BFD “wait for BFD” is accomplished and solve all problems except issues related to poor link quality issues. I support both the OSPF and BGP strict mode drafts and I think think this will be a big gain in itself for operators. As mentioned in the OSPF draft section 5 on use of hold down timers, BFD dampening and on ML use of carrier delay and interface dampening can help operators with link quality issues until we are able to make some headway in BFD and IPPM WG. I would be happy to work with Greg and IPPM WGs as a follow up to this thread related to link quality issues. Kind Regards Gyan On Fri, Feb 4, 2022 at 2:13 PM Robert Raszuk <rob...@raszuk.net> wrote: > > 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 > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
