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

Jeffrey Haas <jhaas@pfrc.org> Fri, 19 March 2021 13:28 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 276423A13AB for <idr@ietfa.amsl.com>; Fri, 19 Mar 2021 06:28:58 -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=unavailable 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 Y-B4y19zkt_S for <idr@ietfa.amsl.com>; Fri, 19 Mar 2021 06:28:55 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 534293A13AC for <idr@ietf.org>; Fri, 19 Mar 2021 06:28:55 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 303221E446; Fri, 19 Mar 2021 09:50:26 -0400 (EDT)
Date: Fri, 19 Mar 2021 09:50:26 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Tony Przygienda <tonysietf@gmail.com>
Cc: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "idr@ietf.org" <idr@ietf.org>
Message-ID: <20210319135025.GK29692@pfrc.org>
References: <20210316210203.GC29692@pfrc.org> <20210318191936.GF29692@pfrc.org> <A288921D-0DB5-413D-B3E9-4DAA9334C5D3@cisco.com> <CA+wi2hNUYkmruBSq4Up4e84H__d48Phxj5TuZXh7wii0QrS3dw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+wi2hNUYkmruBSq4Up4e84H__d48Phxj5TuZXh7wii0QrS3dw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/7EjkmBo3OZYX7EU3YVnpXCaDNTE>
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 13:28:58 -0000

Tony,

On Fri, Mar 19, 2021 at 01:56:27PM +0100, Tony Przygienda wrote:
> I don't see how the "discovery protocol" chosen matters except the
> transport things I mentioned (and fragmentation if you kitchen sink it and
> choosing how simple it is to implement vs. how close to hardware, UDP is
> one point in spectrum, the other taking LLC SNAP type AFAIS ;-).

There's some discussion in the draft about what transport layer we use, and
a few of the headaches.  For BGP auto-discovery, the major implication is
how wide your want your messages to travel.

I won't argue your issues about the headaches in a given layer. 

> the key distinction I see here is whether you go along the philosophy of
> "only minimum to reliably bring session(s) up" (which is already enough,
> BFD, AF mixes, faith sharing and all the stuff IGP does today for BGP are
> non trivial to get right) or "kitchen sink incl. replicating capabilities".

Do you have to bother the BGP speaker to figure out if you want to talk to
them or not?  

If you do, how do you handle retries.

Those questions have to be answered.  You can not like a given mechanism all
you like, but if you want to provide constructive criticism, describe how to
do it better.

> after that you still have to deal with semantics of an "offer". In RIFT
> after pondering that for quite a while and despite Jeffrey pushing for
> independent protocol the whole negotiation of ZTP stuff including levels
> etc has been put onto LIEs (hellos) for the reason that LIEs have timeouts
> on them so it's pretty clear how long something is of importance.

Lifetime is a good point, and one that isn't in the current draft.  Section
3.2 mostly talks about how chatty to be, which might hint a bit about
implicit lifetime.  (E.g. 2-3x the advertising window.  BFD makes that
explicit for reasons you'll likely get to.)

> Obviously, IGPs are much simpler because the lifetime of offer is @ same
> time lifetime of the "session" whereas here the TCP session is kind of
> "floating" around the offers. Thinking of which, the 3-way stuff in IGPs
> has saved our bacon more than once and this discovery protocol should
> probably put that in also deal with stuff like MTU size given that
> mismatching those makes for a bad hair day and there is no IGP now to do
> all the heavy lifting for the mighty BGP to demean itself to run the
> allmighty TCP protocol over it ;-)

The IGPs might get it right if they use padding TLVs, but it was certainly
not baked in up front.

The autoconf considerations draft is intentionally silent on whether the
design MUST have some sort of adjacency.  Some of the proposals are "shout
into the dark" multicast style.  draft-xu-idr-neighbor-autodiscovery
basically replicates LDP state machinery, including a full adjacency.  But
it also discusses impacts on the BGP FSM by tying the fate of the BGP
session to the auto-discovery session.  

MTU mis-matches are definitely a topic of interest elsewhere in IETF.  My
personal opinion is that trying to solve it in auto-discovery is problematic
in a few respects.  The biggest one is that the discovery protocol may run
at a different layer (L2/L3) or different address family than the actual
session.  Even if we did discover an acceptable MTU, most stacks want to
interact with this either through configuring TCP MSS or performing PMTU-D.
Whether you want this stuff to get added to your RFC 4271 style BGP session
setup is where that leads.

-- Jeff