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

Tony Przygienda <> Fri, 19 March 2021 13:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 382AB3A13E6 for <>; Fri, 19 Mar 2021 06:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7vbobFr8oo6Y for <>; Fri, 19 Mar 2021 06:36:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58C243A13DA for <>; Fri, 19 Mar 2021 06:36:45 -0700 (PDT)
Received: by with SMTP id f19so6097419ion.3 for <>; Fri, 19 Mar 2021 06:36:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=63h1w13f2Luk5TgT+y9ufzknCnGZgsvPPD+MNKssmjE=; b=eeFuMTfAh93KeIgGVIFZ7wdw2aefTYnrSds1dqOsRoExBa/V/jjq41Q5OFwI7p7rMP wlhIGiZfOKnBXVaC9ybMI9kjQiIdr6npB97c842I70X1vo2JRycR52DdqxcMZLXUY0Nd +TWxlwkTab/gUE6wsBUFkTKAfiXiOb2H6SaulntpsJAqCcYxxd+MVCUpCB/BfgbTXcwf dEif4xHtGqo3tifhVdq1kaMLnAELvQEz8+55JUIX9eJT+UHgqw8cUu2dBnXupFGkfeMC KWjRTAx2R9j0de7L0nPHS7JccFHr7K7u1eBLztW1fgTYfqEleOfrF1f6lfMwdLQ9rHxP hQjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=63h1w13f2Luk5TgT+y9ufzknCnGZgsvPPD+MNKssmjE=; b=QS0wo8f8jJ0queAVwzQ8Xi/6+idQ04izxOs9T32Fkj7FUiOUNDO7pcMWliNYTccKow 2awk8yX+yomnaWp4mk3LrpnYIFx1PpIJfn6np53XA5F7cAk+yEVeYGo7NKV5ap/BlnRs Z7XDr12OWw+3tpaPn1/bLkOI4WNFweAQaGKBj+u7jy92El1AEt3dErWCZvu4022mTt5u MfIyFMbQnkne1lHoiFqhl0dUM2EyyPXZCNVI2UsJz59jxOt3pSgLUzNYV+3bFQEWBPoM 9yPJJwaVWtsgQQ2BquSCvFjC1MWA+Dtkb01af9ZRK/6qqmamqtfXKKAr9QBQbYWFHpeP LBcQ==
X-Gm-Message-State: AOAM533W6xPpDCFLinudWF4+CItAVR08Y98uVOtJk7Xk3zFhHAojzInN NFEQPNnorabc40pcin+AtS7pu2JbR1mqFl19IZc=
X-Google-Smtp-Source: ABdhPJwmY59M017Wlj6kGTMdXy89DvYNPFG09wCW1ZLB7KjMRmvdU08y+YcRC5y2Ic2brVUx7jYwogivkBJjmmWYagI=
X-Received: by 2002:a02:7419:: with SMTP id o25mr1386209jac.100.1616161004638; Fri, 19 Mar 2021 06:36:44 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Tony Przygienda <>
Date: Fri, 19 Mar 2021 14:36:08 +0100
Message-ID: <>
To: Jeffrey Haas <>
Cc: "Acee Lindem (acee)" <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000094d71b05bde3ceb4"
Archived-At: <>
Subject: Re: [Idr] BGP Auto-Discovery Protocol State Requirements
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Mar 2021 13:36:47 -0000

agreed roughly. I don't have any particular likes or dislikes but observe
that until you get an agreement on whether you use the Occam's razor of
"only and only what gets TCP connected" or not amongst yourself you will
not have an easy time to reach agreement on a specific design

the mtu observation about packets going over different transport than TCP
session is pretty good. On IGPs the padding is bit of a kludge (but in a
sense a good kludge since it checks the "reality" of packets passing), I
would venture that including MTU & other parameters description in the
packet to make sure both sides have acceptable things and with 3-way also
see each other and don't shout two-way only is a better design.

-- tony

On Fri, Mar 19, 2021 at 2:28 PM Jeffrey Haas <> wrote:

> 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