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 <[email protected]> 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 <[email protected]> > *Sent:* Saturday, January 29, 2022 11:13 AM > *To:* Aijun Wang <[email protected]> > *Cc:* Acee Lindem (acee) <[email protected]>; [email protected]; > [email protected]; Albert Fu < > [email protected]> > *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 <[email protected]> > 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:* [email protected] <[email protected]> *On Behalf Of *Acee > Lindem (acee) > *Sent:* Friday, January 28, 2022 8:30 PM > *To:* Aijun Wang <[email protected]>; 'Ketan Talaulikar' < > [email protected]> > *Cc:* [email protected]; [email protected]; 'Albert > Fu' <[email protected]> > *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 <[email protected]> > *Date: *Friday, January 28, 2022 at 1:41 AM > *To: *'Ketan Talaulikar' <[email protected]> > *Cc: *"[email protected]" <[email protected]>, " > [email protected]" < > [email protected]>, Acee Lindem <[email protected]>, > 'Albert Fu' <[email protected]> > *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:* [email protected] <[email protected]> *On Behalf Of *Aijun > Wang > *Sent:* Friday, January 28, 2022 2:02 PM > *To:* 'Ketan Talaulikar' <[email protected]> > *Cc:* [email protected]; [email protected]; 'Acee > Lindem (acee)' <[email protected]>; 'Albert Fu' <[email protected]> > *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:* [email protected] <[email protected]> *On Behalf Of *Ketan > Talaulikar > *Sent:* Friday, January 28, 2022 12:56 PM > *To:* Aijun Wang <[email protected]> > *Cc:* [email protected]; [email protected]; Acee > Lindem (acee) <[email protected]>; Albert Fu <[email protected]> > *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 <[email protected]> > wrote: > > Hi, Albert: > > > > Want to how to accomplish this aim when router conforms to RFC8362? > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* [email protected] <[email protected]> *On Behalf Of *Albert > Fu (BLOOMBERG/ 120 PARK) > *Sent:* Friday, January 28, 2022 4:25 AM > *To:* [email protected]; [email protected] > *Cc:* [email protected] > *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: [email protected] At: 01/27/22 12:08:36 UTC-5:00 > > To: [email protected] > Cc: [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
