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>
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 <lsr-boun...@ietf.org> *On Behalf Of *Albert
> Fu (BLOOMBERG/ 120 PARK)
> *Sent:* Friday, January 28, 2022 4:25 AM
> *To:* a...@cisco.com; lsr@ietf.org
> *Cc:* 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 At: 01/27/22 12:08:36 UTC-5:00
>
> To: lsr@ietf.org
> Cc: 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 11
> th, 20222. Also, review comments are certainly welcome.
>
> Thanks,
> Acee
>
>
>
>
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to