On 2023-04-18, 17:24, "Jeffrey Haas" <[email protected]> wrote:
Zahed, > On Apr 18, 2023, at 8:44 AM, Zaheduzzaman Sarker > <[email protected]> wrote: > > Hi, > > Thanks for the update. I am afraid I would like to discuss it a bit more so > that we understand better the things we are agreeing to. > > Please see inline responses. > On Thursday, December 15, 2022, 05:39:32 PM EST, Jeffrey Haas > <[email protected]> wrote: >> >> It's also not uncommon for implementations to dyanmically adjust their >> timers based on load within some constraints. When that's not possible, >> BFD traffic that becomes unsustainable causes the BFD sessions to start >> losing packets, which in many cases will cause the session to transition to >> the Down state - and thus back to slow PDU transmission. >> > Ok I see. Thanks for the pointer. So, there is process of scaling down the > number of sessions based of the system load and the way to get there is > observed packet loss. Exactly. See in particular RFC 5880, §6.8.3. Short form: A poll sequence is the protocol machinery to latch into the new negotiated timers. Implementations are not required to do such dynamic negotiation, but many implementations may do this. See, for example, the use of the term "adaptation" in Juniper's manual: https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/topic-map/bfd.html > Here the packet loss is not that harmful if I understand correctly. Packet loss may result in the session going down. The session going down will take the dependent client resource using BFD down as well. I suspect you'd find the critical detail here is that in such circumstances BFD isn't an effective denial-of-service. If it's over-aggressive, it kills itself. Many implementations also provide for features that keep unstable sessions down to avoid repeated flapping. This is an implementation choice. > If again my understanding is not correct, then we need mechanism so that we > don’t reach to a situation where the system takes the hit due to packet loss. > That was not that clear to me. Hopefully this clarifies the situation. Yes, it does thanks.
