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

[Zaheduzzaman Sarker <[e-mail]>]

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.

//Zahed


On 2023-03-27, 04:58, "Reshad Rahman" <[e-mail]> wrote:

Zahed, thank you for the review.

On Thursday, December 15, 2022, 05:39:32 PM EST, Jeffrey Haas <[e-mail]> wrote:


Zahed,

[Speaking as chair/shedpherd, not an author.]

On Wed, Dec 14, 2022 at 11:32:46AM -0800, Zaheduzzaman Sarker via Datatracker wrote:
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks for working on this specification.
>
> Thanks to Magnus Westerlund for the TSVART review, based on that review and my
> own read, I am supporting both Lars's and Roman's discuss.
>
> On top of that, as this document claims - "with "unsolicited BFD" there is
> potential risk for excessive resource usage by BFD from "unexpected" remote
> systems". This translates to me as potential injection of huge amount of
> traffic which is lacking a self-regulation mechanism in this specification. To

I suspect it's an unfamiliarity with core RFC 5880 behaviors that's lead you
to that incorrect observation.  BFD sessions negotiate the least aggressive
timer in each direction based on the timers present in each BFD PDU.

See RFC 5880 §6.8.7 for details.

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. Here the packet loss is not that harmful if I understand correctly. 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.


The caveat in this draft is related to an unexpected number of BFD sessions.
Operators, who are already generally aware of BFD session and timer scaling
for their systems, need to plan within the bounds of their deployment.  For
example, if a /24 interface is permitted, it's not unreasonable for 255
sessions to be possible.  If scaling requires fewer to be guaranteed... then
configure that in the ACL.

"If it hurts, don't do that."

> large degrees the traffic volume could have random effects on the routing plane
> and what links are considered up etc. We can hide all these by saying "Deploy
> the feature only in certain "trustworthy" environment"", then I am completely
> missing the definition of "trustworthy" environment". I would like to discuss
> that.

The environment must be under reasonable operational control to satisfy the
scaling of the impacted system.  What words would you prefer to have there
instead?  How would those words change if you want to permit this feature to
be utilized when the operational environment spans multiple entities, such
as at an exchange point (IXP)?

Calling it something else would not resolve the issue until that “something else” is we defined or described. I have no issue with calling it trustworthy when it is described well to that we can understand it, like you attribute it as – “The environment must be under reasonable operational control to satisfy the scaling of the impacted system”. I suggest we put some descriptive text to explain what is makes the environment trustworthy.