Re: [Idr] BGP Message level ACKs

[Tony Przygienda <[e-mail]>]

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]> 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]
> https://www.ietf.org/mailman/listinfo/idr
>