Re: [Idr] Fwd: New Version Notification for draft-spaghetti-idr-bgp-sendholdtimer-05.txt

[heasley <[e-mail]>]

Sun, Jul 31, 2022 at 11:46:12PM +0200, Robert Raszuk:
> >
> > > If the RCV window is 0 how can TCP send anything to the peer including
> > > TCP RST ?
> >
> > the payload of a rst packet can be zero length. also, psh may be set.
> >
> 
> That does not mean that remote peer with receive it and process it.
> Especially if it is hosed.

Even if the remote (stuck) peer does not process the FIN, the local
end will close the session and stop forwarding traffic that direction.
That is an improvement, from an operator's PoV, both for forwarding
errors and local resources.

> > > If the peer is saturated, how good is it to assign a new IANA
> > > error notification code if it can not be sent to the peer ?
> >
> > same as draft-ietf-idr-bfd-subcode: it's to allow the sending side
> > to log the failure in the bgpPeerLastError oid of the relevant bgp
> > mib, which will be visible to monitoring systems.
> >
> 
> Well it is not about bgp peer's error .. it is about our side not able to
> sent much. so if this is just no keepalives it needs to be lot's of them to
> saturate the socket. Otherwise how would BGP know that its socket to the
> peer does not drain ?

The buffer is not necessarily filled by KAs, it can be NLRI.  Technically,
the window could have closed for any reason the peer wishes and might not
have been caused by bgp itself.  Also, the buffer is not necessarily large
and how long it takes to fill is irrelevant.

A different notification allows the operator to differentiate between causes
of session failure, aiding debugging.