Re: [Idr] BGP Message level ACKs

[Robert Raszuk <[e-mail]>]

On Sun, Mar 12, 2023 at 5:57 AM Alejandro Acosta <
[e-mail]> wrote:

> Hello, it can be also added as a new BGP Capability
>
That is 100% correct. I did not spell out all the nitty gritty details
assuming the folks who look at it do understand the implications.

Kind regards,
Robert

On Sun, Mar 12, 2023 at 5:57 AM Alejandro Acosta <
[e-mail]> wrote:

> Hello, it can be also added as a new BGP Capability
>
>
> On 9/3/23 11:58 AM, Robert Raszuk wrote:
>
>
> Well it can not be put in KEEPALIVE thread as by definition it would be
> event triggered not periodic. So hardly would fit that thread.
>
> Cheers,
> R.
>
> On Thu, Mar 9, 2023 at 4:54 PM Tony Przygienda <[e-mail]>
> wrote:
>
>> aha, ok, yeah, and that problem is real as we know ... you should have
>> mentioned it.
>>
>> yes, anything that reflects a token will do fine here ... unless
>> developers optimize and put that processing into the same bgp keepalive
>> thread. Then we are where we started  ;-)
>>
>> -- tony
>>
>>
>> On Thu, Mar 9, 2023 at 4:48 PM Robert Raszuk <[e-mail]> wrote:
>>
>>> Tony,
>>>
>>> > But I lost track frankly WHAT we're solving here with this ACK you
>>> suggest ...
>>>
>>> The reported problem is:
>>>
>>> "The remote peer is not reading my BGP messages while TCP works fine."
>>>
>>> So if a remote peer can ACK that it got messages I send to it (last 10
>>> or last 100 etc ..) it solves the problem as defined. In fact it solves it
>>> better then current proposal of using single side socket buffer full timer.
>>>
>>> I should have not thrown into this UDP as it changes the objective -
>>> from informational nice to have ACK to something much more complicated to
>>> provide transport reliability. That was not the original aim.
>>>
>>> Best,
>>> R.
>>>
>>> PS. If you like lets talk more about it face to face :)
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Mar 9, 2023 at 4:36 PM Tony Przygienda <[e-mail]>
>>> wrote:
>>>
>>>> simple update message "counter" does not change much of anything really
>>>> since the sender has to keep this "counter" on the NLRI at which an update
>>>> was sent to understand which prefixes have been processed by the peer. and
>>>> all very amusing if you start to overlap with newer updates containing the
>>>> newer version of the same prefix. Unless you think of "keeping all the
>>>> updates stored on the outbound until they 'acked" which would be a
>>>> fantastic attack vector by intentional or unintentional slow peers + double
>>>> with the TCP buffering already. With the interesting stuff on top of when
>>>> you give up on the peer if it doesn't ACK in timely manner/at all ...
>>>>
>>>> So, if you want to know what the peer on the other side "processed" you
>>>> will have no other choice but keep per NLRI _something_ and possibly per
>>>> peer (as I explained with lots cleverness you can get away without per peer
>>>> possibly). Unless we're talking unreliable transport under BGP which as I
>>>> said seems to be solving wrong problems in wrong layers. But I lost track
>>>> frankly WHAT we're solving here with this ACK you suggest ...
>>>>
>>>> I still don't understand what "application consuymed the data" _really_
>>>> means in terms of assurances the remote system is giving you in terms of
>>>> forwarding behavior/convergence with other peers/whatever and hence this
>>>> "assurance" seems to be to have no semantics.
>>>>
>>>> So, I chime out. Either this all has no real semantics and possibly
>>>> conflates multiple issues together or I don't grok what it's all about.
>>>>
>>>> motivation for having seq# on enhanced GR draft I get. we do
>>>> mark/sweeping kind of thingies on session re-establish (which GR really is)
>>>> and we have to sync up on versions of state held (as optimization vs.
>>>> re-sending e'thing). And having the other side "confirming" really means
>>>> somethjing, namely FIB/RIB is programmed to this version so no updates are
>>>> needed. It's kind of simplified version of the refresh-options (since it
>>>> basically assumes there is no GR-over-GR or endless updating on sender that
>>>> makes the process never stop?) but it burns basically 8 bits per NLRI as
>>>> well (assuming most likely there is never more than one peer GR'ing either
>>>> or maybe just one version for all peers work, I didn't think that through
>>>> yet). But yeah, no free lunch ...
>>>>
>>>> --- tony
>>>>
>>>> On Thu, Mar 9, 2023 at 9:48 AM Robert Raszuk <[e-mail]> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>> Many thx,
>>>>> Robert.
>>>>>
>>>>>
>>>>> On Thu, Mar 9, 2023 at 8:45 AM Tony Przygienda <[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]>
>>>>>> 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
>>>>>>>
>>>>>>
> _______________________________________________
> Idr mailing [e-mail]://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>