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

[Enke Chen <[e-mail]>]

Hi, Brian:

Isn't the holdtimer already per-neighbor based?

Regards,  -- Enke

On Fri, Apr 23, 2021 at 11:51 AM Brian Dickson <
[e-mail]> wrote:

>
>
> 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
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=ecQzdLStIaoAFzguVP-QtyJpUCwi8K4lXMCt2ey-mZE&s=GquAlygyileCKhzvo6AEjoKhUu6R2Z3sSmft31rxH9s&e=>
>>
>