Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0

[Tony Li <[e-mail]>]

Hi Robert,


> * Is the "unable to send" only possible under Window = 0 ? What if there is a local NIC buffer full and we keep dropping it locally ? If we are going there perhaps we could say "unable to successfully send" meaning send and get an ACK for it ? 


There are many, many reasons why we might not be able to exchange bits. The specifics aren’t particularly relevant. The point is that we’re not able to make progress, so the session is clearly broken.


> * The proposal is about reusing the HOLD TIME value to bring BGP down when you are still receiving keepalives however peer sent ACK for the last segment indicating zero window - is this right ? 


More generally, the proposal is that we apply the HOLD TIME on the transmit side as well as the receive side. If we are not able to transmit for that period of time, the receiver should give up and so should the transmitter. The session is broken, updates cannot flow, and we no longer have (eventual) consistency.


> * What happens if our side is stuck and not able to process subsequent ACKs which potentially increase the window on the peer ? 


Then our side has some kind of bug. But the result is the same: the session is stuck and is not helpful.  Tearing down the session and starting over is probably the best that we can do.


> * Most deployments use BFD to make sure peer is reachable. As BFD is often offloaded from CPU this is not an indication of health of TCP or BGP path. But what if some deployments can not use BFD (say not supported by the peer) ? Then those typically reduce BGP HOLD TIME. Would it not be too fragile in some cases to bring a TCP down in such cases too fast ? Aren't we overloading HOLD TIME value here a bit ? 


The HOLD TIME is already enforced by the receiver.  The only clarification that this makes is that the transmitter should also enforce it.  


> * Assume we bring TCP down ... when does it attempt to go up again ? Are we ok to bring it up only after manual/script action from such a state ? 


That is (and has always been) at the discretion of the implementation. Automatic periodic recovery would be preferable as a means of minimizing managerial overhead.


> * As proposed it seems that the change will affect all AFI/SAFIs using given single TCP session. Even if perhaps all are perfectly healthy and running on separate cores. If each SAFI would run on a separate TCP session this would not have such an impact. 


Creating more TCP sessions is not likely to improve the behavior of a TCP receiver.


> * The change seems applicable to both iBGP and eBGP right ? 


Yes.  It’s fundamental.


> In summary the attempt here is to fix application issues by cutting the transport. Sure half broken transport for whatever reason may not be a good thing to keep in UP state. Especially when redundancy is in place. But my main concerns are that we are only trying to focus on a single low level trigger to detect it. 


The point here is simply a clarification for robustness. If a (half) session is not making progress, then the receiver should terminate the session. With this clarification, we make it explicit that the transmitter may do so as well. The likely scenarios where this would come into play are serious software bugs where the transmitter or receiver is not able to make progress. This could be due to transport issues or infrastructure issues. As you note, trying to continue to work with the session is unlikely to be beneficial.


> Wouldn't per AFI/SAFI heartbeat be a better option to detect if a peer's BGP stack is still up and running fine for all applications ? 


That would add considerable complexity and still not address the stuck transmitter.

Regards,
Tony