I support WG Adoption of this draft. This is a real world problem that has existed with BFD that operators have to deal with where OSPF adjacency comes up before BFD session establishes resulting in cases where the link may have L1 issues or maybe a dirty link or poor link quality resulting in BFD session establishment followed by BFD immediately taking down the link. With BFD tight timers with client protocol registered ends up further exacerbating the issue with link flaps resulting in IGP instability.
This draft mirrors the ISIS block solution in RFC 6213 ISIS BFD enabled TLV. This issue exists with BGP as well where the protocol registered with BFD bootstrapped per RFC 5882 comes up before BFD resulting in instability. I believe this gap still exists for BGP. When BFD comes up it performs link integrity test before session establishment to detect dirty errored link does not come Up. RFC 5880 BFD 3-way session establishment and does the link integrity and quality test by sending the BFD control packets to validate bi-directional forwarding liveliness detection over any media. The case mentioned in this draft where the link is dirty, MTU issues or forwarding plane issues exist that cause BFD not to establish resulting in the use of default protocol timers and slow convergence is a major issue for operators being solved with this draft as well as mentioned above where BFD does come up after the IGP is just as bad if not worse if the link is a dirty errored link resulting in flapping link. The main point here as I mentioned is that BFD must validate the link integrity before routing protocol comes Up, so that routing protocol does not come Up on a dirty errored link, so the blocking of the adjacency capabilities solution here nicely solves the issue. In this thread it has been mentioned maybe a CLI timer knob as far as implementation for delay knob makes sense. I would like to note that one workaround used by operators is using RFC 7130 BFD over bundle member called “BOB” or per link BFD, and in that case control protocol is in fact blocked and BFD comes up first. This is a workaround used putting even individual single links in a bundle to present the issue from happening. I would like to note that RFC 5882 Generic Application of BFD does state that if all neighbors support BFD then the registered control protocol being bootstrapped should be blocked from coming up until BFD session is established. Only in case where all neighbors on a LAN do not have BFD enabled, blocking the control protocol from coming Up would prevent the control protocol from coming Up on neighbors that don’t have BFD enabled. So the way I read it implementations following BFD RFC 5882 should have been blocking OSPF or ISIS protocol from coming Up before BFD comes up w/o having to require a specification for the explicit block. Apparently most all vendors implementations did not follow RFC 5882 it appears with this regard and thus now the requirement for operators for this important draft. I think this implementation discrepancy happened due to normative language SHOULD Block and not MUST Block is the problem. RFC 5882 excerpt below: 4.1 <https://datatracker.ietf.org/doc/html/rfc5882#section-4.1>. Adjacency Establishment If the session state on either the local or remote system (if known) is AdminDown, BFD has been administratively disabled, and the establishment of a control protocol adjacency MUST be allowed. BFD sessions are typically bootstrapped by the control protocol, using the mechanism (discovery, configuration) used by the control protocol to find neighbors. Note that it is possible in some failure scenarios for the network to be in a state such that the control protocol is capable of coming up, but the BFD session cannot be established, and, more particularly, data cannot be forwarded. To avoid this situation, it would be beneficial not to allow the control protocol to establish a neighbor adjacency. However, this would preclude the operation of the control protocol in an environment in which not all systems support BFD. Therefore, the establishment of control protocol adjacencies SHOULD be blocked if both systems are willing to establish a BFD session but a BFD session cannot be established. One method for determining that both systems are willing to establish a BFD session is if the control protocol carries explicit signaling of this fact. If there is no explicit signaling, the willingness to establish a BFD session may be determined by means outside the scope of this specification. If it is believed that the neighboring system does not support BFD, the establishment of a control protocol adjacency SHOULD NOT be blocked. Few comments on the draft below: Bottom of Introduction This document specifies the OSPF protocol extensions using link-local signaling (LLS) [RFC5613 <https://datatracker.ietf.org/doc/html/rfc5613>] for a router to indicate to its neighbor the willingness to establish its adjacency using the strict-mode for BFD. It also introduces an extension for OSPFv3 link-local signaling of the interface IPv4 address when used for an IPv4 address-family (AF) instance to enable discovery of the IPv4 addresses for BFD session setup. Gyan> Could you also introduce extension for IPV6 AF for discovery of IPv6 address? Section 3 Local Interface IPv4 address TLV Gyan> Should we also have a LLS Data block B bit section for Local Interface IPv6 address TLV Section 4 Procedure In this state, a Hello packet has recently been received from the neighbor. However, bidirectional communication has not yet been established with the neighbor (i.e., the router itself did not appear in the neighbor's Hello packet). BFD session establishment with the neighbor is requested, if not already completed (e.g., in the event of transition from 2-way state). Neighbors in Init state or higher will be listed in the Hello packets associated with the interface if they either have a corresponding BFD session established or have not advertised strict-mode for BFD in the Hello packet LLS Extended Options and Flags. Gyan> What do you mean by “ e.g., in the event of transition from 2-way state) I would think OSPF is blocked and so then after BFD is established then OSPF initialized but this sounds like OSPF maybe in two way state when BFD establishes which means OSPF is not blocked from forming adjacency. Confusing. So this would be a LAN mix mode where not all nodes have BFD enabled maybe want to mention to make it clear. An implementation MUST NOT wait for BFD session establishment in Init state unless strict-mode for BFD is enabled on the router and the specific neighbor indicates strict-mode for BFD capability via its Hello LLS options. When BFD is enabled, but the strict-mode for operation has not be signaled by both neighbors, then an implementation SHOULD start the BFD session establishment only in 2-Way state or higher state. This makes it possible for an OSPF router to support BFD operation in both strict-mode and normal mode across different interfaces or even different neighbors on the same multi-access interface. Gyan> So in the LAN case RFC 5882 OSPF should not be blocked with LLS data block. So I think that is what you are trying to say that BFD can come up after OSPF is Up I see you mention 2-way but not fully Up. How would you stagger it allow BFD to come up in parallel to ospf still coming to Full state. Nit OLD When BFD is enabled on an interface over which we already have an existing OSPF adjacency, it would result in the router setting the B-bit in its subsequent Hello packets. If the adjacency is already up (i.e., in its terminal state of Full or 2-way with non-DR routers on a multi-access interface) with a neighbor that also supports strict-mode for BFD, then an implementation SHOULD NOT bring this Gyan> 2-way is not terminal state even for DROther routers NEW When BFD is enabled on an interface over which we already have an existing OSPF adjacency, it would result in the router setting the B-bit in its subsequent Hello packets. If the adjacency is already up (i.e., in its terminal state of Full/DR Full/BDR or Full/DROther routers on a multi-access interface) with a neighbor that also supports strict-mode for BFD, then an implementation SHOULD NOT bring this Section 4.1 OSPFv3 IPv4 address family specifics Gyan> Why would you not have also OSPFV3 IPv6 address family specifics Kind Regards Gyan On Sat, Jan 29, 2022 at 9:28 PM 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 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 > -- <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
