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 in such problems e.g.,
MTU.
In regards to “dampening” = which I think is the relevant term for the timer
related suggestions you are making - this also does not belong in the IGP. If
you do not want the BFD session to come back up too quickly after a failure,
the proper place to put timers is either at the interface layer or in the BFD
implementation.
I am familiar with implementations which apply this timer at the protocol level
(AKA BFD client in this context) and this is done precisely because the
protocol does NOT have the functionality being defined in this draft. Once you
have implemented “wait-for-BFD” logic as defined in this draft you do not need
additional delay timers in the protocol.
I don’t think the suggestions you are making belong in this document.
Les
From: Lsr <lsr-boun...@ietf.org> On Behalf Of Robert Raszuk
Sent: Saturday, January 29, 2022 11:25 AM
To: Acee Lindem (acee) <a...@cisco.com>
Cc: Ketan Talaulikar <ketant.i...@gmail.com>;
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu <af...@bloomberg.net>;
lsr <lsr@ietf.org>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-ospf-bfd-strict-mode-04
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 link will allow OSPF
adjacency formation to succeed
but the BFD session establishment will fail or the BFD session will flap. In
this case, traffic that gets
forwarded over such a link may experience packet drops while the failure of the
BFD session establishment
would not enable fast routing convergence if the link were to go down or flap."
This could be described but I don’t think it should be normative. This begs the
question as to why a hold down timer is not a part of the BFD protocol itself.
There is one - BFD calls it multiplier.
But the timer I am suggesting is not related to BFD operation, but to OSPF
(and/or ISIS). It is not about BFD sessions being UP or DOWN. It is about
allowing BFD for more testing (with various parameters (for example increasing
test packet size in some discrete steps) before OSPF is happy to bring the adj.
up.
Thx,
R.
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
