Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

[Jeffrey Haas <[e-mail]>]

Zahed,


> On Apr 18, 2023, at 8:44 AM, Zaheduzzaman Sarker <[e-mail]> 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 <[e-mail]> 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.

> The caveat in this draft is related to an unexpected number of BFD sessions

In general, BFD scales by the number of sessions along with the associated packet rates.  Operators already must make judgment calls about balancing the ability to quickly detect failures with aggressive timers vs. the number of sessions the device can support.  Thus, this is not new territory operationally.  And similarly, since BFD can negotiate to the least aggressive side of a session (RFC 5880, §6.8.7), a well behaving implementation can simply decide that unsolicited BFD sessions may be limited by: number of sessions, list of acceptable prefixes the sessions come from, and the aggressiveness of the timers based on their desire for slow or fast sessions.

-- Jeff