Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

From: "Aijun Wang" <[email-masked]>
Date: Mon, 7 Feb 2022 09:01:58 +0800

Hi, Ketan:

From: [email-masked] <[email-masked]> On Behalf Of Ketan Talaulikar
Sent: Monday, January 31, 2022 1:13 AM
To: Aijun Wang <[email-masked]>
Cc: lsr <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>; Albert Fu <[email-masked]>
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 <[email-masked] <mailto:[email-masked]> > 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-masked] <mailto:[email-masked]> > 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-masked] <mailto:[email-masked]> >
Date: Saturday, January 29, 2022 at 3:46 AM
To: 'Ketan Talaulikar' <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, 'Albert Fu' <[email-masked] <mailto:[email-masked]> >, Acee Lindem <[email-masked] <mailto:[email-masked]> >
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-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Ketan Talaulikar
Sent: Saturday, January 29, 2022 4:22 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; Albert Fu <[email-masked] <mailto:[email-masked]> >; Acee Lindem (acee) <acee=[email-masked] <mailto:[email-masked]> >
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-masked] <mailto:[email-masked]> > 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-masked] <mailto:[email-masked]> > 
Sent: Saturday, January 29, 2022 11:13 AM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: Acee Lindem (acee) <acee=[email-masked]>; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; Albert Fu <[email-masked] <mailto:[email-masked]> >
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-masked] <mailto:[email-masked]> > 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-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Acee Lindem (acee)
Sent: Friday, January 28, 2022 8:30 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >; 'Ketan Talaulikar' <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; 'Albert Fu' <[email-masked] <mailto:[email-masked]> >
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-masked] <mailto:[email-masked]> >
Date: Friday, January 28, 2022 at 1:41 AM
To: 'Ketan Talaulikar' <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, Acee Lindem <[email-masked] <mailto:[email-masked]> >, 'Albert Fu' <[email-masked] <mailto:[email-masked]> >
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-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Aijun Wang
Sent: Friday, January 28, 2022 2:02 PM
To: 'Ketan Talaulikar' <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; 'Acee Lindem (acee)' <[email-masked] <mailto:[email-masked]> >; 'Albert Fu' <[email-masked] <mailto:[email-masked]> >
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-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Ketan Talaulikar
Sent: Friday, January 28, 2022 12:56 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; Acee Lindem (acee) <[email-masked] <mailto:[email-masked]> >; Albert Fu <[email-masked] <mailto:[email-masked]> >
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-masked] <mailto:[email-masked]> > wrote:

Hi, Albert:

Want to how to accomplish this aim when router conforms to RFC8362?

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Albert Fu (BLOOMBERG/ 120 PARK)
Sent: Friday, January 28, 2022 4:25 AM
To: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
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-masked] <mailto:[email-masked]>  At: 01/27/22 12:08:36 UTC-5:00

To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
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-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/lsr

---

From: Ketan Talaulikar <[email-masked]>
Date: Tue, 8 Feb 2022 20:03:05 +0530

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 <[email-masked]> wrote:

> Hi, Ketan:
>
>
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *Ketan
> Talaulikar
> *Sent:* Monday, January 31, 2022 1:13 AM
> *To:* Aijun Wang <[email-masked]>
> *Cc:* lsr <[email-masked]>; [email-masked];
> Acee Lindem (acee) <[email-masked]>; Albert Fu <[email-masked]>
> *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 <[email-masked]>
> wrote:
>
> Hi, Acee and Ketan:
>
> 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-masked]> 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-masked]>
> *Date: *Saturday, January 29, 2022 at 3:46 AM
> *To: *'Ketan Talaulikar' <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, 'Albert Fu' <
> [email-masked]>, Acee Lindem <[email-masked]>
> *Subject: *RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi, Ketan:
>
> 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-masked] <[email-masked]> *On Behalf Of *Ketan
> Talaulikar
> *Sent:* Saturday, January 29, 2022 4:22 PM
> *To:* Aijun Wang <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; Albert
> Fu <[email-masked]>; Acee Lindem (acee) <acee=
> [email-masked]>
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi Aijun,
>
>
>
> On Sat, Jan 29, 2022 at 1:42 PM Aijun Wang <[email-masked]>
> 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-masked]>
> *Sent:* Saturday, January 29, 2022 11:13 AM
> *To:* Aijun Wang <[email-masked]>
> *Cc:* Acee Lindem (acee) <acee=[email-masked]>; [email-masked];
> [email-masked]; Albert Fu <
> [email-masked]>
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi Aijun,
>
>
>
> On Sat, Jan 29, 2022 at 7:38 AM Aijun Wang <[email-masked]>
> 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:
>
> 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.
>
>
>
>
>
> 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?
>
> 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-masked] <[email-masked]> *On Behalf Of *Acee
> Lindem (acee)
> *Sent:* Friday, January 28, 2022 8:30 PM
> *To:* Aijun Wang <[email-masked]>; 'Ketan Talaulikar' <
> [email-masked]>
> *Cc:* [email-masked]; [email-masked]; 'Albert
> Fu' <[email-masked]>
> *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-masked]>
> *Date: *Friday, January 28, 2022 at 1:41 AM
> *To: *'Ketan Talaulikar' <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, Acee Lindem <[email-masked]>,
> 'Albert Fu' <[email-masked]>
> *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-masked] <[email-masked]> *On Behalf Of *Aijun
> Wang
> *Sent:* Friday, January 28, 2022 2:02 PM
> *To:* 'Ketan Talaulikar' <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; 'Acee
> Lindem (acee)' <[email-masked]>; 'Albert Fu' <[email-masked]>
> *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-masked] <[email-masked]> *On Behalf Of *Ketan
> Talaulikar
> *Sent:* Friday, January 28, 2022 12:56 PM
> *To:* Aijun Wang <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; Acee
> Lindem (acee) <[email-masked]>; Albert Fu <[email-masked]>
> *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-masked]>
> wrote:
>
> Hi, Albert:
>
>
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *Albert
> Fu (BLOOMBERG/ 120 PARK)
> *Sent:* Friday, January 28, 2022 4:25 AM
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
>
>
> 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-masked] At: 01/27/22 12:08:36 UTC-5:00
>
> To: [email-masked]
> Cc: [email-masked]
> 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
>
>
>
>
>
> [email-masked]

---

From: Aijun Wang <[email-masked]>
Date: Tue, 8 Feb 2022 23:15:52 +0800

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 <[email-masked]> 写道：
> 
> 
> 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 Sun, Jan 30, 2022 at 7:58 AM Aijun Wang <[email-masked]> wrote:
>> 
>> Hi, Acee and Ketan:
>> 
>> From: Aijun Wang <[email-masked]>
>> To: 'Ketan Talaulikar' <[email-masked]>
>> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, 'Albert Fu' <[email-masked]>, Acee Lindem <[email-masked]>
>> Cc: [email-masked]; [email-masked]; Albert Fu <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
>> On Sat, Jan 29, 2022 at 1:42 PM Aijun Wang <[email-masked]> wrote:
>> 
>> Hi, Ketan:
>> 
>> From: Ketan Talaulikar <[email-masked]> 
>> Cc: Acee Lindem (acee) <acee=[email-masked]>; [email-masked]; [email-masked]; Albert Fu <[email-masked]>
>> On Sat, Jan 29, 2022 at 7:38 AM Aijun Wang <[email-masked]> wrote:
>> 
>> Hi, Acee:
>> 
>>  
>> 
>> From: [email-masked] <[email-masked]> On Behalf Of Acee Lindem (acee)
>> To: Aijun Wang <[email-masked]>; 'Ketan Talaulikar' <[email-masked]>
>> Cc: [email-masked]; [email-masked]; 'Albert Fu' <[email-masked]>
>> From: Aijun Wang <[email-masked]>
>> To: 'Ketan Talaulikar' <[email-masked]>
>> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Acee Lindem <[email-masked]>, 'Albert Fu' <[email-masked]>
>> From: [email-masked] <[email-masked]> On Behalf Of Aijun Wang
>> To: 'Ketan Talaulikar' <[email-masked]>
>> Cc: [email-masked]; [email-masked]; 'Acee Lindem (acee)' <[email-masked]>; 'Albert Fu' <[email-masked]>
>> Cc: [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>; Albert Fu <[email-masked]>
>> On Fri, Jan 28, 2022 at 8:29 AM Aijun Wang <[email-masked]> wrote:
>> 
>> Hi, Albert:
>> 
>>  
>> 
>> From: [email-masked] <[email-masked]> On Behalf Of Albert Fu (BLOOMBERG/ 120 PARK)
>> To: [email-masked]; [email-masked]

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 10 Feb 2022 14:00:05 +0530

Hi Aijun,

A BFD session and/or neighborship going down between two DRother routers
does not impact the topology since there is no change in the Network LSA
for that LAN advertised by the DR. However, in the common scenario where a
DRother router goes down, a BFD session does help another DRother to detect
this failure and activate its FRR mechanism. Later, when the updated
Network LSA is received from the DR, the router can perform its primary
convergence. That is the use-case/benefit and so I disagree with your
comment that such sessions are useless.

This behavior is also independent of strict-mode.

We seem to be going in circles on this so perhaps we can just agree to
disagree on this point.

Thanks,
Ketan

On Tue, Feb 8, 2022 at 8:46 PM Aijun Wang <[email-masked]> wrote:

> 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
>
> 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
>
>
>> *[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
>>
>>
>>
>>
>>
>> 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
>>
>>
>>
>> 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?
>>
>>
>>
>> *[WAJ] In Broadcast/NBMA network, OSPF adjacency is built only between
>> the routers and DR/BDR.  *
>>
>>
>>
>> Thanks,
>>
>> Ketan
>>
>>
>>
>>
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> 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
>> *Cc:* [email-masked]; [email-masked];
>> [email-masked]>, Acee Lindem <
>> [email-masked]>, 'Albert Fu' <[email-masked]>
>> 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
>>
>>
>>
>> Most people deploy BFD with OSPF (or any routing protocols) to enable
>> fast failure detection. This is to ensure that routing/forwarding path is
>> 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
>>
>>
>>