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

Jeffrey Haas <jhaas@pfrc.org> Fri, 19 March 2021 12:50 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB9A3A12D0 for <idr@ietfa.amsl.com>; Fri, 19 Mar 2021 05:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7D7-7dh1qUP for <idr@ietfa.amsl.com>; Fri, 19 Mar 2021 05:50:02 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F09093A12CF for <idr@ietf.org>; Fri, 19 Mar 2021 05:50:01 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id CB5E51E446; Fri, 19 Mar 2021 09:11:32 -0400 (EDT)
Date: Fri, 19 Mar 2021 09:11:32 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Tony Przygienda <tonysietf@gmail.com>
Cc: idr wg <idr@ietf.org>
Message-ID: <20210319131132.GH29692@pfrc.org>
References: <20210316210203.GC29692@pfrc.org> <20210318191936.GF29692@pfrc.org> <CA+wi2hM6WNrYRCsOvTCSFr3E+_eiE6FPvdxh0A6Oqs6_p3uh2Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+wi2hM6WNrYRCsOvTCSFr3E+_eiE6FPvdxh0A6Oqs6_p3uh2Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/7tlO9KhbRAcany6yBbc3SNOlitM>
Subject: Re: [Idr] BGP Auto-Discovery Protocol State Requirements
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Mar 2021 12:50:04 -0000

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