Re: [Idr] draft-spaghetti-idr-bgp-sendholdtimer - Feedback requested

[Brian Dickson <[e-mail]>]

On Fri, Apr 23, 2021 at 10:31 AM Enke Chen <[e-mail]>
wrote:

> Hi, Folks:
>
> The holdtimer already conveys whether the session should be timed out
> sooner or later. It makes sense to tie the new timer with it, perhaps with
> a configurable multiplier. The default could be 1, or 2.
>
>
This is a bad idea (having the only "knob" be a multiplier).

It might be okay for the default to be derived from some multiplier over
the default for holdtimer, but it is not okay for the knob to be ONLY a
multiplier.

Here's why:

A router with a large number of BGP sessions, where those sessions have
different characteristics, such as RTT, loss, bandwidth, etc., are very
likely to behave quite differently.
(There are any number of operational reasons a router might have
connections of this sort, it's really not worth detailing all the reasons,
but some examples would include a router with both local LAN peers
(customers) and satellite peers; peering extension providers over
multi-city links; underprovisioned peer routers; software router peers,
etc.)

The operator should (MUST) have exposed controls to adjust timers on a
per-neighbor basis, and/or per-router basis (when managing large numbers of
routers).

The purpose of this proposal is not met if that level of granularity is
unavailable.

The operator has the ability to understand why individual peering sessions
may be behaving this way, and will need to adjust the parameters on a
per-peer basis.
Fixing a problem for one peer, should not introduce problems for another
peer.

This isn't 1995.

Respectfully,
Brian


> Thanks.   -- Enke
>
> On Fri, Apr 23, 2021 at 5:43 AM Job Snijders <job=
> [e-mail]> wrote:
>
>> Hi Jakob, group,
>>
>> Thanks for the feedback, a -02 has been submitted.
>>
>> On Fri, Apr 23, 2021 at 12:56:40AM +0000, Jakob Heitz (jheitz) wrote:
>> > I propose to add this text:
>> >
>> > It is possible that a BGP speaker presents a TCP zero receive window
>> > after receiving a large batch of updates. Resetting the session to
>> > such a speaker may just repeat the large batch, whereas waiting a little
>> > longer may have given it a chance to recover. The possibility of this
>> > occurrence makes it difficult to determine a good value for the
>> > timer. The default value of the timer is therefore recommended
>> > to be 15 minutes.
>>
>> In this email John Scudder appears to suggest using a separate new
>> timer, and populate the timer with the default HoldTimer value (and the
>> -02 draft attempts to describe exactly that).
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_idr_E5pqxIObPS7e9A2IqIApTHVSfig_&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=bQFpOg20Jvvi5Fdn0FbsPn3umJ_yRN4nNcXfCsfl5ek&s=ic9GqvTL_AVNp--whyEU4xnDPEpswdHPBNt_XoBG99g&e=
>>
>> you propose 15 minutes; so it seems there is some convergent thinking in
>> the group the proposed timers at hand is in the order of 'multiple
>> minutes'.
>>
>> How long should a BGP speaker be willing to buffer on behalf of another
>> BGP speaker's inability to progress message processing?
>>
>> If the oldest message in the queue is a KEEPALIVE message, and its been
>> stuck there for more than HoldTimer, wouldn't we have expected the
>> remote side to have killed the BGP session anyway?
>>
>> Would you mind sharing your thinking on why a default of 15 minutes is
>> better than for example 180 seconds? What do others think?
>>
>> Kind regards,
>>
>> Job
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=bQFpOg20Jvvi5Fdn0FbsPn3umJ_yRN4nNcXfCsfl5ek&s=PHKZKmQoCjqpWGGBhDIpOnAaSlDjeRsLdEPlOwChzyw&e=
>>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>