Sorry I meant publication. I support publication.
Thanks Gyan On Sun, Jan 30, 2022 at 1:59 AM Gyan Mishra <hayabusa...@gmail.com> wrote: > > 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* > > -- <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
