Hi, Ketan: I recommend that in Broadcast/NBMA network, the BFD session is bootstrapped after the DR/BDR election(but before the OSPF adjacency establishment). That is, only the BFD session between DRother and DR/BDR is checked. This can avoid many useless BFD sessions between DRothers and also accomplish your goal to assure the reliable OSPF adjacency establishment.
Aijun Wang China Telecom > 在 2022年2月8日，22:34，Ketan Talaulikar <ketant.i...@gmail.com> 写道： > > > Hi Aijun, > > The primary purpose of BFD session monitoring between two DROther routers is > for fast detection so fast-reroute mechanisms can be triggered locally. This > is the normal case. If such BFD sessions are not there, then there is a gap > between the time when either the DR detects that a DROther router is down and > then updates & floods its network LSA OR when the DRother routers learn the > same after the dead interval. Neither of them meet the typical requirements > of fast-reroute. > > There is a corner case where the DR has connectivity to the DRother routers > but the connectivity between the DRother routers is broken (e.g. consider an > emulated VPLS deployment). In such cases, the network LSA which provides the > topology input for SPF will not reflect any change, but the adjacency between > the DRother routers will remain down. However, OSPF on LAN depends on the > mutuality of connections between routers for the DR mechanism to work > effectively. Strict mode doesn't make much difference here. > > Thanks, > Ketan > > >> On Mon, Feb 7, 2022 at 6:32 AM Aijun Wang <wangai...@tsinghua.org.cn> wrote: >> Hi, Ketan: >> >> >> >> From: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of Ketan >> Talaulikar >> Sent: Monday, January 31, 2022 1:13 AM >> To: Aijun Wang <wangai...@tsinghua.org.cn> >> Cc: lsr <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, >> >> >> >> There is a need for a BFD session to be established between neighboring >> routers which directly forward data between them to ensure reachability >> between them. That is my understanding of various implementations and >> deployments at operators. This is independent of the strict mode of >> operation. >> >> [WAJ] What is the action when the BFD session between the DRothers is not >> BROUGHT UP or DOWN then? >> >> >> >> Perhaps you have a different requirement for "optimization of BFD sessions >> on multi-access networks"? If so, it would be clearer if you could put that >> requirement/proposal together as a draft for the WG to review. Also, that >> would be in any way independent of this specification since what you are >> referring to is the base use of BFD by OSPF. >> >> >> >> Thanks, >> >> Ketan >> >> >> >> >> >> On Sun, Jan 30, 2022 at 7:58 AM Aijun Wang <wangai...@tsinghua.org.cn> wrote: >> >> Hi, Acee and Ketan: >> >> No, I don’t want to change the NBMA/Broadcast in OSPF to P2MP mode. >> >> What I want to express is that you brought up the full mesh BFD sessions >> among the routers within such network type. Is it necessary to bring some of >> them(the BFD sessions between DRothers) to DOWN after the OSPF adjacency are >> established between the DRother and DR/BDR router? >> >> If the BFD session is bootstrapped after the OSPF adjacency is established, >> there will be no such extra/useless BFD sessions >> >> Aijun Wang >> >> China Telecom >> >> >> >> >> On Jan 30, 2022, at 02:45, Acee Lindem (acee) <a...@cisco.com> wrote: >> >> >> >> Speaking as WG member: >> >> >> >> Hi Aijun, >> >> If you want a per-neighbor state and route, you have to use P2MP. This scope >> of this draft isn’t to try and make NBMA/Broadcast model something that it >> is not. This is should be common knowledge and the draft needn’t address it. >> Those of us who remember ATM emulated LANs (which were not always >> symmetrically reliable) will recall using P2MP on an inherently multi-access >> network. >> >> Acee >> >> >> >> From: Aijun Wang <wangai...@tsinghua.org.cn> >> Date: Saturday, January 29, 2022 at 3:46 AM >> To: 'Ketan Talaulikar' <ketant.i...@gmail.com> >> Cc: "lsr@ietf.org" <lsr@ietf.org>, >> "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" >> <draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>, 'Albert Fu' >> <af...@bloomberg.net>, 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 >> >> >> >> Hi, Ketan: >> >> OK, then back to my original question: >> >> If one of the BFD session(between DRothers) is DOWN, will it bring DOWN the >> OSPF adjacency(between the DRother and DR/BDR)? >> >> If not, then the traffic between these DRothers will be lost; If yes, it >> seems strange, because the BFD session between the DRother and DR/BDR may be >> still UP. >> >> I think here there are some mismatch between the BFD sessions and the OSPF >> adjacency in Broadcast/NBMA network, then some clarification for the >> procedures are needed. >> >> >> >> >> >> Best Regards >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> From: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of Ketan >> Talaulikar >> Sent: Saturday, January 29, 2022 4:22 PM >> To: Aijun Wang <wangai...@tsinghua.org.cn> >> Cc: lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu >> <af...@bloomberg.net>; Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org> >> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - >> draft-ietf-lsr-ospf-bfd-strict-mode-04 >> >> >> >> Hi Aijun, >> >> >> >> The choice of the term "adjacency" was not accurate in my previous response >> to you. I meant "neighborship". >> >> >> >> That said, the substance of my response still remains the same. >> >> >> >> Thanks, >> >> Ketan >> >> >> >> >> >> On Sat, Jan 29, 2022 at 1:42 PM Aijun Wang <wangai...@tsinghua.org.cn> wrote: >> >> Hi, Ketan: >> >> For the Broadcast/NMBA network type, if you establish BFD sessions >> before the DR/BDR selection, then there will be full mesh BFD sessions >> within the routers on such media type? >> >> Instead of establishing the BFD sessions with DR/BDR only, the same as the >> OSPF adjacency relationship? If so, if one of the BFD session that not with >> the DR/BDR is DOWN, what’s the action then? >> >> >> >> KT> I think there is perhaps a misunderstanding of the purpose of BFD use >> with OSPF. Perhaps a careful reading of RFC5882 would help? In short, BFD is >> used to verify bidirectional connectivity between neighbors to ensure data >> may be forwarded between them. OSPF adjacency is built between every router >> in a LAN since they can directly forward packets between themselves. >> >> [WAJ] In Broadcast/NBMA network, OSPF adjacency is built only between the >> routers and DR/BDR. >> >> >> >> Thanks, >> >> Ketan >> >> >> >> >> >> >> >> Best Regards >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> From: Ketan Talaulikar <ketant.i...@gmail.com> >> Sent: Saturday, January 29, 2022 11:13 AM >> To: Aijun Wang <wangai...@tsinghua.org.cn> >> Cc: Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org>; lsr@ietf.org; >> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; 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, >> >> >> >> Please check inline below. >> >> >> >> >> >> On Sat, Jan 29, 2022 at 7:38 AM Aijun Wang <wangai...@tsinghua.org.cn> wrote: >> >> Hi, Acee: >> >> >> >> Yes. Then I think the sentence in >> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode#section-2 >> as the following should be relaxed: >> >> “A router MUST include the LLS block with the LLS Type 1 Extended >> >> Options and Flags TLV with the B-bit set in its Hello and DD packets >> >> when strict-mode for BFD is enabled on the link.” >> >> It seems that there is no use for such information being included in the DD >> packets. >> >> >> >> KT> Since LLS is present in both Hello and DD packets, not including the B >> bit in DD packets will result in a different LLS options being seen in Hello >> and DD. This can trigger the change in LLS option logic unnecessarily. >> Hence, to keep things simple and consistent (and this should be for >> technically all LLS options), it makes sense to include them in both Hello >> and DD packets. >> >> >> >> >> >> And, one more question to the Authors of this draft: >> >> What’s the procedures for the interaction of BFD session and OSPF adjacency >> establishment in the Broadcast/NBMA network type interface, which is >> involved the DR/BDR election procedures? The BFD session establishment >> should be after the DR/BDR election? >> >> Should the procedures in section 4 be updated to cover such scenario? >> >> >> >> KT> The procedures in Sec 4 update the transition to INIT state in the OSPF >> Neighbor FSM. This happens before DR election and is independent of the type >> of network/link - applies also to Broadcast/NMBA. The main goal of this >> proposal is to first verify BFD session establishment and only then trigger >> OSPF adjacency procedures. Doing DR election before BFD session does not >> serve the purpose. >> >> >> >> Thanks, >> >> Ketan >> >> >> >> >> >> >> >> >> >> Best Regards >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> From: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of Acee Lindem >> (acee) >> Sent: Friday, January 28, 2022 8:30 PM >> To: Aijun Wang <wangai...@tsinghua.org.cn>; 'Ketan Talaulikar' >> <ketant.i...@gmail.com> >> Cc: lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; '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, >> >> >> >> From: Aijun Wang <wangai...@tsinghua.org.cn> >> Date: Friday, January 28, 2022 at 1:41 AM >> To: 'Ketan Talaulikar' <ketant.i...@gmail.com> >> Cc: "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>, '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, Ketan: >> >> >> >> I know. According to the description of RFC 5613, the LLS Data Block is only >> attached at the OSPF hello and DD packets. >> >> >> >> If you read section 4 of the draft, you’ll see that the strict mode behavior >> is based on the LLS block in OSPF Hello packets. >> >> >> >> Thanks, >> Acee >> >> >> >> >> >> From: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of Aijun Wang >> Sent: Friday, January 28, 2022 2:02 PM >> To: 'Ketan Talaulikar' <ketant.i...@gmail.com> >> 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, 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> 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 11th, >> 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
