Re: [Idr] BGP Message level ACKs

[tom petch <[e-mail]>]

From: Idr <[e-mail]> on behalf of Robert Raszuk <[e-mail]>
Sent: 09 March 2023 08:47

Tony,

I think you are looking at this in a different way.

So what you are likely considering is a very fine and detailed sequence number like approach. That's a lot of work indeed to accommodate it into current BGP outbound code - with tons of optimizations.

I on the other hand was just thinking of reusing simple UPDATE message counter per peer. Some (I would say most) implementations I think have it already.

The only sort of open issue is to synchronize the counters or at least clocks. Alternative would be to inject periodically a sequenced BGP MARKER message to tag local counter with remote counter and have the ACKs being MARKER triggered. Quite popular solution in completely asynchronous systems :)

So to spec this out should be pretty straightforward. But again this email is to just probe the topic not volunteer to do it.

<tp>
But ...

If everything is working, well, nothing more needed.

I assume that the idea is that when a Message Level ACK fails to arrive, then the session is taken down.   Which means there must be a mechanism to detect the failure.  Which means a MessageLevelACKTimer.  Which sounds rather like the SendHoldTimer.  The difference would seem to be that the SendHoldTimer works on KEEPALIVE, OPEN, UPDATE whereas this works on UPDATE only but otherwise the logic is much the same.  

The SendHoldTimer is operating at the Message Level and is purely local, whereas a Message Level ACK involves action by the far end.

My objection to the SendHoldTimer is the incompleteness of the specification (e.g. does it include OPEN? the text implies it but then omits it) and the great complexity of attempting to patch it into the FSM.  It could be specified, and specified more simpler IMHO, if it made no reference to the FSM, if it did not attempt to update the FSM (in at least 41 places).

Tom Petch

Many thx,
Robert.


On Thu, Mar 9, 2023 at 8:45 AM Tony Przygienda <[e-mail]<mailto:[e-mail]>> wrote:
The problem is on the sender side. it has to keep track of whether an update has been ack'ed by a peer and that's in simple terms per peer per NLRI (modulo group discussion as usual). It can be tricked into per NLRI only but since NLRIs get packed differently, in different sequence towards different peers a high scale implementation will end up with at least per prefix. This is _very_ expensive, particularly memory wise. Tricks can be played with rollovers like in https://datatracker.ietf.org/doc/draft-idr-bgp-route-refresh-options/ but the logic isn't simple by any means and ultimately any solution may force implementations into structures to support this that are very inefficient for other parts of the implementation.

Generally, shoving reliability of the transport into BGP is basically solving the wrong problem at the wrong layer just like shortcutting BGP to run on a user transport protocol brought nothing but lots of technical debt grief over the years.  Real problem is lack of control session layer that realizes underneath that transport went away and notifies up and/or allows transport for the session to come up again. It's only when a new session needs be established AFAIS that we need state sync which lands us in possibly GR corners or refresh corners again rather than trying to reinvent TCP on top of UDP in BGP by ACKs (I wonder when the first window size proposal starts to come in ;-)

-- tony

On Wed, Mar 8, 2023 at 11:52 PM Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:
Hi Jeff,

A fundamental challenge for bgp implementations is efficiently keeping versioning across peer-groups.*  Some implementations are friendlier to that idea than others, but the inconsistency in the ability to do that is one of the things that prevented this idea from progressing.

I did not mean that it should touch update generation and replication. The ACKs which I had in mind would be operating way above this and simply periodically indicate to the sender that last N number of UPDATE messages got received by remote BGP process.

N-being configured and possibly negotiated on the session bootstrap.

Critical part of this is the time scale. If we are talking about the last 10 min or last 20 min this would not be sufficient for helping to achieve reliable transport, but could be IMO more than sufficient to make sure UPDATE got to remote BGP I/O.

So I am not sure if this is real distraction to the topic. I would rather call it exploration of alternative approaches. Just like punting the "issue" to telemetry ... avoiding need for any BGP code or FSM state machine change needed.

Many thx,
R.

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr