Hi All,
The authors will work on and share the updated text to review with the WG.
Quickly want to point out that the draft does not bring any new
requirements in BFD for link quality monitoring; the stability issues that
we are discussing are related to BFD sessions going down due to
Hi Robert,
The comparison between the BFD strict-mode of operation proposals for OSPF
and BGP are not directly comparable since their FSMs are different. In
OSPF, the FSM is going to wait indefinitely in Init state until the BFD
session is set up, while that is not the case for BGP and hence BGP
Les,
> On Jan 31, 2022, at 2:47 PM, Les Ginsberg (ginsberg)
> wrote:
> I have not asked for BFD extensions.
> I have stated that “IF” additional functionality is required from BFD that
> the proper place to discuss that is in the BFD WG – and such discussions are
> definitely not in scope of
Hey Albert,
Ok now we are in sync as far as what is the topic.
I think such a delay is very useful and completely in the spirit of OSPF or
ISIS strict-mode operation.
So I do recommend that the draft should discuss it.
The default can be 0 if you think that is the proper value. But the
> I have stated that “IF” additional functionality is required from BFD
No one says so,
[LES:] Good. Can we end this thread then?
[
Les
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Hi Robert,
As mentioned in my previous email, I feel it is better not to specify in the
draft the timer for when OSPF should come up after BFD is up.
The current implementation is for OSPF to come up as soon as BFD is up. A user
can change this behaviour via configuration, to delay when OSPF
> I have stated that “IF” additional functionality is required from BFD
No one says so, It would be not realistic to require for BFD to come up in
a hidden mode, operate for timer X then when timer X expires signal that to
clients. And this is precisely what you are suggesting as a push back.
It
Hi Albert,
On Mon, Jan 31, 2022 at 8:38 PM Albert Fu (BLOOMBERG/ 120 PARK) <
af...@bloomberg.net> wrote:
> Hi Robert,
>
> Do you mean we should make it mandatory in the draft to stipulate a delay
> time between when OSPF should wait for BFD to come up?
>
No.
The timer is for OSPF to bring adj
Jeff –
I appreciate that you have been pulled into reading a very lengthy thread and
then commenting on it – which is a difficult/time consuming thing to do
accurately.
And I certainly welcome your input and agree with your input.
I have not asked for BFD extensions.
I have stated that “IF”
Hi Robert,
Do you mean we should make it mandatory in the draft to stipulate a delay time
between when OSPF should wait for BFD to come up?
I don't know how others feel, but I tend to agree the main author of this
Draft, Ketan, that it is best to leave the delay timer out of this draft.
> what new signal should BFD send to OSPF when this is done?
None. Lack of DOWN signal is enough for OSPF to proceed.
Thx,
R.
On Mon, Jan 31, 2022 at 6:50 PM Les Ginsberg (ginsberg)
wrote:
> Robert –
>
>
>
> The paragraph you quote below has to do with BGP behavior in the event
> “BFD session
Hi Robert,
The BGP BFD hold-time mentioned in the BGP BFD strict mode draft has different
meaning from the holdtime/delay/dampening that has been discussed in this forum
thus far.
The BGP BFD hold-time, as per the BGP BFD draft below, is user configurable,
and is used to bring down the BGP
Robert –
The paragraph you quote below has to do with BGP behavior in the event “BFD
session does not transition to the Up state”.
There is no disagreement about what the protocol (BGP or OSPF) should do in
this case. The point of strict-mode is to “wait-for-BFD”.
You, however, are trying to
Les,
BFD does not have a notion to come up in a hidden way, start testing
the link and only after some defined per client protocol or per interface
peer period signal to the client its "UP" state.
BFD holdtime as defined in RFC5880 is to keep BFD sessions and therefore
data probes down (for
Albert –
We are in full agreement.
Delays in bringing BFD backup after a previous failure may well be warranted in
the break-in-middle scenarios.
I am not convinced this needs to be standardized – seems quite appropriate as
an implementation choice. But if any discussion were to occur in RFCs,
Les & Ketan
> Nowadays, it is also common to see the "break-in-middle" failures. we use
> BFD to detect this sort of failure within sub-second. And to dampen this
> sort of break-in-middle failures, we will need to use BFD
> holdtime/dampening.
>
Another data point to the above and this
Hi Les,
Your scenario below is indeed something we have encountered in our production
network in the non-strict scenario, due to "flapping" links, where routing
protocol could come up before BFD due to "break-in-middle" link issue
(interface stayed up, so routing protocol remained active).
17 matches
Mail list logo
