Re: [Idr] BGP Auto-Discovery Protocol State Requirements

[Jeffrey Haas <[e-mail]>]

Tony,

On Fri, Mar 19, 2021 at 11:38:54AM +0100, Tony Przygienda wrote:
> Once you go to version number the issue of underlyng transport behavior
> starts to come to the fore. UDP & sometimes L2 can misorder, _badly_, from
> experience. In most extreme cases in virtualized environment I saw UDP
> being buffered & misorderd up to 5 seconds delay. That''s surely extremely
> and until seen bits hard to believe but here you are and you start to look
> once your adjacencies with 3 sec lifetime start to bounce & do _really_
> weird stuff on AF negotiation (since one node talks to the other being 5
> sec in the past ;-)  I debugged that one by establishing a baseline clock
> using reflected numbers in hellos because otherwise none of the logs made
> any sense ;-)

Thankfully, I think that this mechanism is likely to be slow and dumb enough
for misordering to not be too much of a problem.

The intent for BGP auto-configuration is to tell a listener "go peer here".
Truth exists in the actual BGP session.

Stale information means that we're trying with potentially wrong state, but
correcting that in a few seconds would likely be fine.  Changes to session
parameters are likely being done at human time scales, from one
configuration commit to another.

The version is mostly there to say "go try again", and is there in this form
because the BGP Session Paramters are discovered from the BGP session
itself.  It's almost simple enough that a single bit of "I've changed since
last time" would be sufficient, but we know that's not good enough. :-)

-- Jeff