Re: [Idr] WG Adoption call for draft-spaghetti-idr-bgp-sendholdtimer-09 (2/28/2023 to 3/14/2023)

[Nick Hilliard <[e-mail]>]

So the thing is that SendHoldTimer is a last resort timer, which is 
triggered when the control plane is wedged to the point that it's 
obviously broken.

You'd need to ask the authors about what sort of value they would be 
happy to see as a min value. Personally, I don't see why an operator 
should be forced into accepting 1h as a minimum if they feel that there 
is a problem which could be triggered sooner.  I'd suggest that if a 
local host detects that a session has been wedged for 15m, then it would 
be fair to assume it's dead. Even 15m makes debugging twice as slow as a 
minimum 8m timer.

The other thing is that a recommended value is not the same as a minimum 
value.  Maybe the following approach would work:

1. SendHoldTimer MUST be strictly greater than 2x HoldTimer 
[explanation: this is the timer of last resort]

2. SendHoldTimer MUST be >= 10m [explanation: wedged for 10m probably 
means that there is a control plane problem, but gives the operator the 
ability to drop this value for debugging purposes if they need to do this]

3. default value for SendHoldTimer of 20m [explanation: 2x 
MinSendHoldTimer provide a more conservative default]

There are no magic numbers here.

Nick

Robert Raszuk wrote on 07/03/2023 11:16:
> Hi Nick,
> 
> Great - so would co-authors be ok to add MUST to the draft that MIN 
> value of SendHoldTimer  should be 60 minutes ?
> 
> If so I think it would clear any of my concerns.
> 
> Thx,
> R.
> 
> 
> 
> On Tue, Mar 7, 2023 at 12:11 PM Nick Hilliard <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Mikael Abrahamsson wrote on 07/03/2023 10:09:
>      > On Tue, 7 Mar 2023, Robert Raszuk wrote:
>      >> But we discussed this ... If network is stable and you are only
>     putting
>      >> keepalives say every 60 sec it will be hours before the socket
>     buffer
>      >> get's
>      >> filled and you get first notification about it to local BGP process.
>      >>
>      >> How is the solution presented in this draft helpful ?
>      >
>      > Our network (which has had this happen to us) sends data all the
>     time,
>      > and even if it takes hours it's still better than the alternative
>     of not
>      > detecting it at all.
> 
>     this draft is about unsticking connections which have been jammed for
>     time periods longer than hours [bgpzombies], and it's normal for BGP
>     session uptime to be measured in months rather than hours. For example,
>     here's the output of an entirely unremarkable dfz leaf router:
> 
>      > Neighbor      V           AS MsgRcvd MsgSent   TblVer  InQ OutQ
>     Up/Down  State/PfxRcd
>      > 185.x.x.a     4         zzzz  226429  218447 1698392790    0    0
>     9w6d            2
>      > 185.x.x.b     4         zzzz 1230618  591626 1698392790    0    0
>     26w6d       10543
>      > 185.x.x.c     4         zzzz  247092  103288 1698392790    0    0
>     4w4d        10543
>      > 185.x.x.d     4         zzzz  643980  670503 1698392790    0    0
>     30w3d           0
>      > 185.x.x.e     4         zzzz 23580593  525601 1698392790    0   
>     0 23w6d      906760
>      > 185.x.x.f     4         zzzz  363536  376941 1698392790    0    0
>     17w1d          25
> 
>     Nick
>