Re: [Idr] BoQ

[Tony Przygienda <[e-mail]>]

I mentioned on the mike as well that the "asymmetric" is really "almost
asymmetric only", i.e. keepalives still go both ways to prevent a single AF
F channel being stuck. And the caps have a "nit-picking" table to
differentiate whether they're C or F or mix and stuff for AF can be
negotiated differently. Tedious? yeah. useful? yeah AFAIS. The tedious work
of exception-per-cap-and-so-on is the usual cleanup of a 20 years of merry
mess of just piling in new stuff ;-)

As to ACK'ing TCP, well, you don't have an idea whether stuff is on the
wire, in mbuf or whatever really unless you go and look at windows acks on
the raw TCP frames. Which AFAIK in BGP no'one does except maybe window
shuts. So in a sense you are in the same place with QUIC. magically shows
up on the other side reliably and unless we run out buffers no'one knows
whether the data really is at a moment.

The interesting discussion I have with Jeff is about the "implicit
serialization" (that I think someone mentionted on the mike) that we had
with single session and lost now and implications of that. And lots other
comments like running tls over quic without encrypting whole channel (big
perf hit) and whether "fall back on tcp" even makes sense since that will
generate complex FSMs. And whether the concept of session layer of quic is
useful for bgp here.

interesting work, draft is bit of hodge podge of evolving though but
reading carefully you can kind of figure out what it will ultimately be.

--- tony



On Tue, Jul 25, 2023 at 10:24 AM Robert Raszuk <[e-mail]> wrote:

> Hi Jeff,
>
> Excellent.
>
> One more question ... In today's BGP we do rely on TCP to ack reception of
> datagrams.
>
> If we move to quic and if we endorse session asymmetry (which indeed for
> some SAFIs may be a pretty cool feature) which element in new protocol
> stack would provide ACKs for received data by the peer ?
>
> Many thx,
> R.
>
>
> On Tue, Jul 25, 2023 at 10:18 AM Jeffrey Haas <[e-mail]> wrote:
>
>> Robert, thanks for the questions.  As mentioned at the mic, we have a lot
>> of
>> details to clarify in the draft.  A meeting of the authors last week in
>> particular illustrated we need to develop a clean taxonomy to discuss the
>> PDU communication between two sides to help clarify these procedures.
>>
>> On Tue, Jul 25, 2023 at 09:58:47AM -0700, Robert Raszuk wrote:
>> > Hi Jeff,
>> >
>> > Can you elaborate a bit more on the proposed split of control channel vs
>> > SAFI channel/sessions when we think of BGP over QUIC ?
>> >
>> > The reason I am asking that is after realizing that such split may be
>> ways
>> > more difficult to accomplish without lot's of changes to BGP4.
>>
>> For the most part, not very much.  The high level behavior is that when
>> there is asymmetric communication where a unidirectional stream is
>> expecting
>> a reply of some sort, or a message from the passive side of the stream,
>> the
>> control channel is used and the response is directed to that particular
>> stream.
>>
>> This means that we have mostly boring BGP-4 with an active and a passive
>> side.  The state machine is significantly similar to the BGP-4 one for
>> each
>> of these unidirectional streams, but not 100%.  We will be publishing
>> clarifications to cover the point, but had decided it was better this IETF
>> to start socializing the idea.
>>
>> > Also each SAFI between any two peers can negotiate different set of
>> > capabilities as well as peer with different set of addresses
>> (interfaces vs
>> > loopbacks).
>>
>> That is correct.  It's largely considered a feature at this point.
>>
>> As an example, A->B for ipv4 unicast can signal add-paths and B->A for the
>> same family may not use it.
>>
>> > For keepalives - the same - you mentioned it would run only over control
>> > channel - but this may not be best idea.
>>
>> Sorry if this point was unclear, and its text we need to work on
>> significantl in the document for clarity.  Holdtime, and the associated
>> keepalives, from an active to a passive side is still negotiated.  The
>> expectation is that the timers for the function channels is signifcantly
>> longer than the control channel's hold timer.
>>
>> The motivation is we want to know if a given function channel is "still
>> alive".
>>
>> We will similarly be discussing sendholdtimer considerations for the
>> unidirectional function channels.
>>
>> > Last how about use of BFD ? It seems it would be useful to
>> > consider micro-BFD on  a per SAFI session (if they peer to different
>> set of
>> > endpoints).
>>
>> We've not discussed BFD at this point, but I find it likely that this
>> resembles traditional BFD use for BGP: A single session protects the boq
>> connection.
>>
>> > There are clearly number of benefits, but the less surgery on current
>> BGP
>> > code base is required the better and easier to deploy.
>>
>> This is our intent.
>>
>> -- Jeff
>>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>