Re: [Idr] BGP autodiscovery design team

Robert Raszuk <> Thu, 05 December 2019 23:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58F1112020A for <>; Thu, 5 Dec 2019 15:25:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 dWKyzLOTXHUq for <>; Thu, 5 Dec 2019 15:25:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 683411201A3 for <>; Thu, 5 Dec 2019 15:25:00 -0800 (PST)
Received: by with SMTP id 38so5225580qtb.13 for <>; Thu, 05 Dec 2019 15:25:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rJTc4eXNI7faxVuxwY9kyqUwJzsxLHeExUTxt4HGjzA=; b=LXoTvC04aJGsckkbDrJ0PCxHl0UCadiq2WWGknRGUSvaywFDCIkDQMxnmltT41HA/o WTNKtDYiqlEWElBueW7Obt+E/KdLfgEEpBHE8BJ48LXTtH7HJ1DXcki2WIlTkYfE01Wp SIqJ1zn5Lux55B6+9KrLJMVtEaJfvQGIp35HbCpsk3cA6AF9wTn9djIMfmaR4qZIY3mB ngPCng+GepsEA72IaE8g2zBkQhjvqeQLg67Cm+NXiLXCcikQ5t82V0H1rQYxPvgoe55v eI3iXLW/PjydG+n/Mkz5wttrFocapWKI40qrTL5CedpfwCYVurvLWK+87Po6cazJCuGN 1AVA==
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=rJTc4eXNI7faxVuxwY9kyqUwJzsxLHeExUTxt4HGjzA=; b=gLaOb6yzODzn607XvYrOl4pQlKABwYe4XOEVHmBQxxIVsuCvJUkw3NeBzPGYjeIwZZ C64I09wl4tw6b3QRLdu+zg0YXG4qGMhKGfZjAyigs9uM9LPp2W/kFeFKckRrteRtfShR l0WnFliqJyGIAz+65DVVUxk7MEOTWvfOYJR42VYb8vMdiQ0OkQiJdg0nw/1E9h2V1312 gTsfPy3Jp05MCYLrwWzgWhBmg7RKf6eK59gACIhwu0vXve1IKoG+Mb89MYXsfq0tSjaM E0K/UQ+LzPWpwHytS699Zr1WtIkfhL+fXbVpgozf+/ThIq8QLBlUCjRq0dXHYe80oKex SbwA==
X-Gm-Message-State: APjAAAVLx+Lust3H2snNGnDXl2yxiRMaGFEYS6pZvAWGYoEfM58bxvx4 Gmi2EGIctpsdaA0X2pB8sU4uZwaI5upAek2OixzHcA==
X-Google-Smtp-Source: APXvYqyR3USYZvL/cii3mndDue/W/xS2YJyv0wUxaAtGScMaMoiO7KsNG7yeGuQKleKUqyPIJL32uiytRndNR2BemYA=
X-Received: by 2002:aed:2b62:: with SMTP id p89mr10242823qtd.208.1575588299385; Thu, 05 Dec 2019 15:24:59 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Fri, 6 Dec 2019 00:24:51 +0100
Message-ID: <>
To: Randy Bush <>
Cc: "UTTARO, JAMES" <>, idr wg <>
Content-Type: multipart/alternative; boundary="000000000000e5c46d0598fd3c25"
Archived-At: <>
Subject: Re: [Idr] BGP autodiscovery design team
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: Thu, 05 Dec 2019 23:25:02 -0000

> imiho, if we agreed to constrain solutions to the absolute minimal
> mechanism, we might be able to cover a significant subset of clos,
> ibgp, inter-provider, and ixp.

We have a very different set of possible tools and solutions to setup BGP
peering in Clos fabric as compared with BGP neighbor discovery for IBGP
mesh or IXP.

With that perhaps we could consider if for nothing else then for simplicity
to separate those two quite orthogonal tasks.

As noted for the latter we do have a pretty mature candidate solution on
the table. For the former I think there is a lot of experience we could
leverage from IGPs.

I am not aware that there is a requirement to automate
Inter-provider peering in any dimension.

Many thx.

On Thu, Dec 5, 2019 at 11:43 PM Randy Bush <> wrote:

> > I agree with Roberts’ point. Prior to crafting or selecting a draft as
> > the basis for a proposal the design team should clearly articulate the
> > scope, use cases and requirements that need to be addressed. IMO
> > stating that in an informational RFC is a good way to ensure that all
> > stakeholders are in agreement as to what the eventual
> > specification/draft addresses, and as important does not address.
> while i am tempted to agree with you, i see it from a different vector.
> imiho, if we agreed to constrain solutions to the absolute minimal
> mechanism, we might be able to cover a significant subset of clos, ibgp,
> inter-provider, and ixp.
> if we do not constrain to the minimial mechanism, we will make a complex
> and disgusting mess of boiling the ocean on {pick any one of the above}.
> i think it was tony hoare who said something such as
>    there are two kinds of standards,
>      - the intersection of what everybody *must* have
>      - the union of what everybody thinks they could want
> randy
> _______________________________________________
> Idr mailing list