Hi, Ketan: What I want to know is that where to encapsulate the LLS Data Block if the router uses OSPFv3 Extended LSAs to establish the adjacency?
Best Regards Aijun Wang China Telecom From: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of Ketan Talaulikar Sent: Friday, January 28, 2022 12:56 PM To: Aijun Wang <wangai...@tsinghua.org.cn> Cc: lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Acee Lindem (acee) <a...@cisco.com>; Albert Fu <af...@bloomberg.net> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04 Hi Aijun, This document proposes changes to the adjacency establishment procedures and the use of LLS for negotiations. As such, it is independent of OSPFv3 Extended LSAs. Please let us know if you believe otherwise. Thanks, Ketan On Fri, Jan 28, 2022 at 8:29 AM Aijun Wang <wangai...@tsinghua.org.cn <mailto:wangai...@tsinghua.org.cn> > wrote: Hi, Albert: Want to how to accomplish this aim when router conforms to RFC8362? Best Regards Aijun Wang China Telecom From: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> <lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> > On Behalf Of Albert Fu (BLOOMBERG/ 120 PARK) Sent: Friday, January 28, 2022 4:25 AM To: a...@cisco.com <mailto:a...@cisco.com> ; lsr@ietf.org <mailto:lsr@ietf.org> Cc: draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org <mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04 I support this draft, as one of the authors, as well as a BFD user, and hope it becomes a standard. This draft addresses an issue that we have encountered in our production network, hence we have been actively working with our vendors. Most people deploy BFD with OSPF (or any routing protocols) to enable fast failure detection. This is to ensure that routing/forwarding path is diverted as soon as a connectivity issue is detected. OSPF BFD strict mode ensures this, in that it requires that the BFD session to be established before OSPF adjacency will be allowed to be established, thus ensuring that routing/forwarding will not use the path without a working BFD adjacency. Without this standard, as per most current default OSPF BFD deployment, OSPF adjacency is established without BFD. OSPF adjacency then triggers the BFD session to be established. If a "break-in-middle" issue occurred (where last mile interface status remains up) before BFD session comes up, we would lose the fast failure detection capability. This situation will require lengthy OSPF protocol timeout to detect such failure, resulting in traffic being black-holed for extended period. We have a large network consisting of several thousand links throughout the world, and have seen this issue several times that had impacted production traffic negatively. As mentioned in a previous email, we have successfully tested this feature on the Juniper MX (JUNOS 19.4) and also Cisco ASR9k (XR 7.3.2) platforms. Thanks Albert Fu Bloomberg From: a...@cisco.com <mailto:a...@cisco.com> At: 01/27/22 12:08:36 UTC-5:00 To: lsr@ietf.org <mailto:lsr@ietf.org> Cc: draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org <mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org> Subject: Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04 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
