Hi,
I support the draft. A quick question:
Should it describe the applicability of the mechanism over OSPF virtual
links and unnumbered interfaces? With virtual links, one would have to
establish a multi-hop BFD session, so it is slightly different from a BFD
operational standpoint. For e.g,
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
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
Hi Les,
That timer and its consistency on both ends clearly belongs to OSPF not to
> BFD.
>
> *[LES:] I disagree. The definition of UP state belongs to the BFD
> protocol/implementation.*
>
> *If you don’t want BFD clients (like OSPF) to react “too quickly” then
> build additional config/logic
Robert -
From: Robert Raszuk
Sent: Saturday, January 29, 2022 12:20 PM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem (acee) ; Ketan Talaulikar
; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert
Fu ; lsr
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
Hi Les,
> Discussion of how to make BFD failure detection more robust belongs in
the BFD WG
> If you do not want the BFD session to come back up too quickly after a
failure
Nothing I suggested is related to any of the above.
Let me perhaps provide a very simple example.
BFD being used is
Robert –
It is good that you take an active interest in this technology – but I think
the suggestions you are making should not be targeted at IGP use of BFD.
Discussion of how to make BFD failure detection more robust belongs in the BFD
WG – and – as you know – that WG has taken an interest
Acee,
> I don’t anyone has implemented the later capability. This MTU test
> extension could be added in a separate draft if there were a strong
> requirement.
>
I think you are mixing an example of what BFD could be doing to make sure
the link is fine with the delay timer allowing it to do
Hi Robert,
From: Robert Raszuk
Date: Saturday, January 29, 2022 at 2:25 PM
To: Acee Lindem
Cc: Ketan Talaulikar , lsr ,
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org"
, Albert Fu
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
Hi Acee,
Can you suggest text which with you’d be happy? I’m sure the authors would
> add you to the acknowledgements.
>
Actually instead of suggesting any new text I would suggest to delete the
two below sentences and it will be fine:
*"In certain other scenarios, a degraded or poor quality
Speaking as Document Shepherd:
Hi Robert,
From: Robert Raszuk
Date: Saturday, January 29, 2022 at 11:15 AM
To: Ketan Talaulikar
Cc: lsr , "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org"
, Albert Fu
, Acee Lindem
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
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
Hi Albert,
> [AF] This draft ensures that BFD can be used to detect failure quickly
> when there is a complete path failure between the nodes. You are right that
> there are many other types of failure that BFD cannot detect.
>
> Indeed, but the draft says otherwise. I think that needs to be
Hi Robert,
Thanks for your comment. Please see my response inline.
From: rob...@raszuk.net At: 01/29/22 11:14:59 UTC-5:00To: ketant.i...@gmail.com
Cc: Albert Fu (BLOOMBERG/ 120 PARK ) , lsr@ietf.org,
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org, acee=40cisco@dmarc.ietf.org
Subject: Re:
Hi Ketan and all,
I support this draft - it is a useful addition.
There are two elements which I would suggest to adjust in the text before
publication.
*#1 Overpromise*
Even below you say:
> Since there is a issue with forwarding *(which is what BFD detects)*
and in the text we see:
"In
Hi Aijun,
Please check inline below.
On Sat, Jan 29, 2022 at 2:15 PM Aijun Wang
wrote:
> 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)?
>
KT> No. Those are
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
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
wrote:
> Hi, Ketan:
>
> For the Broadcast/NMBA
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
19 matches
Mail list logo
