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

[Robert Raszuk <[e-mail]>]

Hi Gert,

> Doesn't change the problem ("need to detect this") or the
> consequences to the FSM ("do something on detection").

Hmmm if we would do it at TCP level (with all pros and cons) how
would we need to change a single thing in BGP FSM ?

Thx,
R


On Tue, Mar 7, 2023 at 11:26 AM Gert Doering <[e-mail]> wrote:

> Hi,
>
> On Tue, Mar 07, 2023 at 10:20:41AM +0100, Robert Raszuk wrote:
> > > This draft is trying to detect that the receiver isn't reading from the
> > > socket but still sending valid BGP keepalives etc.
> >
> > 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 ?
>
> This seems to be a somewhat far fetched argument to make USER_TIMEOUT
> look like a nicer solution, and maybe it is, for that particular edge
> case.  But this is not a relevant situation - the problem at hand is
> "a real network with normal BGP update activity can not send updates
> to a neighbour because said neighbour got stuck".  Having no updates
> to send "for hours" is not a typical scenario.
>
> Shorter: the draft will not solve unrelated problems.
>
>
> In the end it does not really matter *how* the situation is detected -
> if the underlying operating system provides USER_TIMEOUT, it's a nice
> shortcut for the BGP daemon developer to use that as a signal, instead
> of implementing the send queue monitoring itself.  Doesn't change the
> problem ("need to detect this") or the consequences to the FSM ("do
> something on detection").
>
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael
> Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: [phone]         USt-IdNr.: DE813185279
>