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] <mailto:[email protected]> >
Sent: Saturday, January 29, 2022 11:13 AM
To: Aijun Wang <[email protected] <mailto:[email protected]> >
Cc: Acee Lindem (acee) <[email protected]
<mailto:[email protected]> >; [email protected] <mailto:[email protected]> ;
[email protected]
<mailto:[email protected]> ; Albert Fu
<[email protected] <mailto:[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]
<mailto:[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] <mailto:[email protected]> <[email protected]
<mailto:[email protected]> > On Behalf Of Acee Lindem (acee)
Sent: Friday, January 28, 2022 8:30 PM
To: Aijun Wang <[email protected] <mailto:[email protected]> >;
'Ketan Talaulikar' <[email protected] <mailto:[email protected]> >
Cc: [email protected] <mailto:[email protected]> ;
[email protected]
<mailto:[email protected]> ; 'Albert Fu'
<[email protected] <mailto:[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] <mailto:[email protected]> >
Date: Friday, January 28, 2022 at 1:41 AM
To: 'Ketan Talaulikar' <[email protected] <mailto:[email protected]> >
Cc: "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]>
>, "[email protected]
<mailto:[email protected]> "
<[email protected]
<mailto:[email protected]> >, Acee Lindem
<[email protected] <mailto:[email protected]> >, 'Albert Fu' <[email protected]
<mailto:[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] <mailto:[email protected]> <[email protected]
<mailto:[email protected]> > On Behalf Of Aijun Wang
Sent: Friday, January 28, 2022 2:02 PM
To: 'Ketan Talaulikar' <[email protected] <mailto:[email protected]> >
Cc: [email protected] <mailto:[email protected]> ;
[email protected]
<mailto:[email protected]> ; 'Acee Lindem (acee)'
<[email protected] <mailto:[email protected]> >; 'Albert Fu' <[email protected]
<mailto:[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] <mailto:[email protected]> <[email protected]
<mailto:[email protected]> > On Behalf Of Ketan Talaulikar
Sent: Friday, January 28, 2022 12:56 PM
To: Aijun Wang <[email protected] <mailto:[email protected]> >
Cc: [email protected] <mailto:[email protected]> ;
[email protected]
<mailto:[email protected]> ; Acee Lindem (acee)
<[email protected] <mailto:[email protected]> >; Albert Fu <[email protected]
<mailto:[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]
<mailto:[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] <mailto:[email protected]> <[email protected]
<mailto:[email protected]> > On Behalf Of Albert Fu (BLOOMBERG/ 120 PARK)
Sent: Friday, January 28, 2022 4:25 AM
To: [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]>
Cc: [email protected]
<mailto:[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] <mailto:[email protected]> At: 01/27/22 12:08:36 UTC-5:00
To: [email protected] <mailto:[email protected]>
Cc: [email protected]
<mailto:[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
