Hi Kethan Thank you for answering all my questions. I am all set.
Responses in-line Kind Regards Gyan On Sun, Jan 30, 2022 at 11:48 PM Ketan Talaulikar <[email protected]> wrote: > Hi Gyan, > > Please check inline with KT2. > > > On Mon, Jan 31, 2022 at 1:20 AM Gyan Mishra <[email protected]> wrote: > >> Hi Ketan >> >> Welcome. Responses in-line Gyan2 >> >> Kind Regards >> >> On Sun, Jan 30, 2022 at 12:34 PM Ketan Talaulikar <[email protected]> >> wrote: >> >>> Hi Gyan, >>> >>> Thanks for your review and your comments/feedback. Please check inline >>> below for responses. >>> >>> >>> On Sun, Jan 30, 2022 at 12:29 PM Gyan Mishra <[email protected]> >>> 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. >>>> >>> >>> KT> We have >>> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-bfd-strict-mode/ >>> >>> >> Gyan> Understood to solve this issue for OSPF >> >>> >>>> 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. >>>> >>> >>> KT> Please check Sec 5. The terminology used might differ between >>> implementations. >>> >> >> Gyan> I see mention of BFD dampening for poor link quality issues. >> However if BFD comes Up and establishes that would mean that at the time >> the BFD session is established as control packet were received based on >> interval and timer that the link is in a good state at the time of session >> establishment. The main issue we are solving here is not allowing OSPF to >> come Up on a link with packet forwarding issues. At that point when OSPF >> FSM is initiated and goes to Full state we know the link to be stable as >> BFD was established successfully prior. If a link were in bad shape or >> flapping BFD would not establish and that is the crux of this drafts >> problem statement. So I think to some degree this draft does preclude the >> need for BFD dampening. >> >> >>> 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. >>>> >>> >>> KT> There are implementations that provided knobs for this strict >>> mode-like behavior. The draft specifies the procedures for the same to be >>> standardized for multi-vendor interop and more importantly the ability to >>> signal/negotiate this mode of operation with neighbors. >>> >>> >> Gyan> It maybe good to reference RFC 5882 and state what the BFD >> specification says with regards to blocking IGP from coming up and that >> this draft is following the specification that has been implemented by >> other vendors and now making it standard for interoperability. >> > > KT2> Ack. We will add text for do this in the Introduction section. > Gyan2> Excellent! Thank you > > >> >>>> 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? >>>> >>>> >>> KT> That is not required since we have the IPv6 link-local address that >>> is available for use. >>> >>> >> Gyan> RFC 5613 LLS data block only applies to IPv4 and not IPv6 for >> OSPFV3, Understood. OSPFV3 has the Link Local LSA to signal the B bit to >> block the adjacency from forming so would you still need that B flag update >> to the Link Local LSA to get tbt same IPv4 LLS data block functionality >> > > KT2> LLS is for both OSPFv2 and OSPFv3. The B-bit is common and available > for OSPFv3 protocol instances both IPv4 and IPv6. > Gyan2> Ack. Makes sense > > >> >>>> 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 >>>> >>>> >>> KT> This is not required since the adjacency is either for IPv4 or IPv6 >>> in the case of OSPF in separate protocol instances and not a single >>> adjacency like in the case of ISIS. >>> >> >> Gyan> Understood. OSPF would have separate v4 and v6 adjacency where >> ISIS MT single adjacency. I understand for OSPFv3 IPv4 AFI we need the >> IPv4 address TLV for discovery of neighbor IPv4 address which is not >> needed for IPv6 since we have link local address and link local LSA for the >> discovery. I am still trying to understand how the LLS signaling of the B >> bit would happen for OSPF IPv6 Address family using OSPFV3 or OSPFv3 >> address family instance RFC 5838. Let’s say the interface is not dual >> stacked and it’s IPv6 only how would you block the adjacency from forming? >> > > KT2> I hope the response to your previous comment clarifies this. > > Gyan2> Yes it does, Thanks > >>> >>>> 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) >>>> >>>> >>> KT> We can have OSPF neighbor FSM state transition from 2-way (or >>> greater) to Init state. In those cases, a BFD session may be already >>> established or requested and hence does not need to be initiated. You can >>> put this into the entire neighbor FSM of RFC2328 to get a full picture. >>> >> >> Gyan> The verbiage seems very loose that it’s not clearly saying that >> BFD MUST be established before OSPF FSM is initiated. So you are saying >> that when BFD session is requested so has not even started or the request >> has completed which the way it’s worded the BFD session is clearly not >> established and at the same time - in the event of ospf transition from >> 2-way state to init or Full. Which one. Also if the LLS B bit is set my >> understanding is OSPF has not even started and only after BFD is >> established and the B bit is clear would OSPF initiate. >> > > KT2> I am not sure if I follow. This document specifies the change in the > OSPF Neighbor FSM and it is assumed that the reader understands that well. > We are not going to describe state transitions into and out of Init state. > In short, BFD session establishment for a neighbor is triggered when it > starts in the Init state and the FSM is not allowed to progress further > into the 2way state until the BFD session is established. > > Gyan2> Ack. Thank you for explaining > >>> >>>> >>>> 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. >>>> >>>> >>> KT> We need to be able to interop and be backward compatible. That is >>> the main motivation. Normally, when all routers on a LAN support this spec, >>> they would all likely do strict-mode and not a mix. >>> >>> >> >> Gyan> The main motivation is to fix the problem with OSPF starting before >> BFD to be implemented so that there is backwards compatibility. I think >> you should break out scenarios into P2P and LAN scenario. This is how I >> would reword. >> > > KT2> I am not sure what text and in which section you are suggesting to be > reworded. I do not see the difference in the behavior based on the type of > link when it comes to BFD strict mode. > Gyan2> Below verbiage is reword of section 4 6th paragraph. Here is the original text “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.” > >> >> For Multi-access interfaces when BFD is enabled, but the strict-mode for >> operation has been signaled by multiple but not all 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. >> >> >> >> For interface with P2P subnet when BFD is enabled, but strict-mode for >> operation has been signaled by both neighbors, then an >> implementation SHOULD start the BFD session establishment at init state. >> >> In case one end of P2P link supports Strict mode and the other neighbor >> >> does not then BFD would come up in Normal mode. >> >> >> >> >>>> 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. >>>> >>>> >>> KT> Full state comes after 2-way. >>> >>> >>>> How would you stagger it allow BFD to come up >>>> >>>> in parallel to ospf still coming to Full state. >>>> >>>> >>> KT> I am not sure if I follow this question. In the non-strict mode of >>> operation, the OSPF adjacency can progress to its terminal state (e.g. >>> full) without any dependence on the BFD session establishment. >>> >>> >> Gyan> This was related to the interoperability with devices not >> supporting on LAN with mix of devices. I think if we reword as I stated >> above specifying P2P and LAN scenario that would make it clearer. >> >>> >>>> >>>> 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 >>>> >>> >>> KT> We are talking about the Neighbor FSM State here. >>> >>> >> Gyan> Yes. The verbiage is not clear. Non DR is technically called >> DROther router I believe. Also the DROther router would be in Full state >> and not 2-way, correct? >> > > KT2> This document is talking of OSPF Neighbor FSM state. I don't see the > need to discuss DR-Other or such terminologies in this document. > Gyan2> Ack > > >> >>>> 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 >>>> >>> >>> KT> Could you please check RFC5838 to know more about multi-AF >>> operations for OSPFv3? >>> >> >> Gyan> I understand OSPFv3 MI separate control plane and data plane >> separate v4 and v6 adjacency I would think that as we have link local >> address and link local local LSA we need to still set the B bit flag to >> block the adjacency from forming for v6 control plane. Imagine if no v4 >> and v6 congruency and v6 had to signal the B bit as we cannot rely on v4 >> instance for v6 adjacency since it’s separate adjacencies. Also for IPv6 >> only scenario as well now you have to signal the B bit somehow so that flag >> needs to be specified in the specification. >> > > KT2> I hope my response to a previous comment clarifies this. > Gyan2> Yes it does, Thanks > > Thanks, > Ketan > > > >> >>> Thanks, >>> Ketan >>> >>> >>>> >>>> Kind Regards >>>> >>>> Gyan >>>> >>>> On Sat, Jan 29, 2022 at 9:28 PM Aijun Wang <[email protected]> >>>> 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) <[email protected]> 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 <[email protected]> >>>>> *Date: *Saturday, January 29, 2022 at 3:46 AM >>>>> *To: *'Ketan Talaulikar' <[email protected]> >>>>> *Cc: *"[email protected]" <[email protected]>, " >>>>> [email protected]" < >>>>> [email protected]>, 'Albert Fu' < >>>>> [email protected]>, Acee Lindem <[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: >>>>> >>>>> 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:* [email protected] <[email protected]> *On Behalf Of *Ketan >>>>> Talaulikar >>>>> *Sent:* Saturday, January 29, 2022 4:22 PM >>>>> *To:* Aijun Wang <[email protected]> >>>>> *Cc:* [email protected]; [email protected]; >>>>> Albert Fu <[email protected]>; Acee Lindem (acee) <acee= >>>>> [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, >>>>> >>>>> >>>>> >>>>> 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 11th, 20222. Also, review comments are certainly welcome. >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Lsr mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/lsr >>>>> >>>>> _______________________________________________ >>>>> Lsr mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/lsr >>>>> >>>> -- >>>> >>>> <http://www.verizon.com/> >>>> >>>> *Gyan Mishra* >>>> >>>> *Network Solutions A**rchitect * >>>> >>>> *Email [email protected] <[email protected]>* >>>> >>>> >>>> >>>> *M 301 502-1347* >>>> >>>> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> *Email [email protected] <[email protected]>* >> >> >> >> *M 301 502-1347* >> >> -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
