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

Robert Raszuk <> Fri, 19 March 2021 14:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DBB33A15D5 for <>; Fri, 19 Mar 2021 07:00:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, 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 TyzE1f752mVF for <>; Fri, 19 Mar 2021 07:00:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB8183A15D4 for <>; Fri, 19 Mar 2021 07:00:17 -0700 (PDT)
Received: by with SMTP id 184so12081891ljf.9 for <>; Fri, 19 Mar 2021 07:00:17 -0700 (PDT)
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=+/ipeLJEnOZl29u5anyZGu8Ze7BiXddM3cvHS49O7zo=; b=Y+ie44c1qF1Bgdv9g9SjHeembtLP6FTkbF8MtuOUsL29B3KKleBmAV/A5D86Gr/6Sc QOzIH0xuJGWo1u8OdpomxXvoZsT9UY2q59XB1RA+Z+Zz470j4SZ1g63qQ5/2jOItnxU+ 0SbJU4jK4JhZoW0q8P3BgqVP6eNJD4c5YMH+2NSRouja7JfALODJdVrp43fsxhzS1XBc QDhiDrtqd/O96wS0iw9mI8TE3hRwgzLWkH0Sg/LKz3VfAzPvxOBVDf12MHfe8kS8qQOa /smBTaohNiRBiAv831shs9954W+zh0NHcWWiqVPDULo9kBi+WUxqGJ5yKY/yOIZ6HqhU Tfyw==
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=+/ipeLJEnOZl29u5anyZGu8Ze7BiXddM3cvHS49O7zo=; b=qd3MlhpUM9BjKlR6RpkCOdnqzvOAzBgHZqESRAd/BTPXtAnFBTXZPSMAOLa/A5Hsnq oSwvEPhEE4liA6wERCJ3VMDEj+QrHtdCvUmuJki4Ttj2h/4CvxJpUnFZkVhvBQxEFEL5 7aMudSxxhXkDSdh9kea8osz7QnLksQG+fGeHanz1eWCcc/ae/R5MX586kaEuwJEgP4x6 dgVKSqeKIW0KIEIEg3bZ1FU9c2urZFbqDRPaiMFk75xL7hCQB5Q4Yg0CIaZlGnYrcjVd 1GfS6FkhLaYUfdaLNnVnz26DrvDGtxw3WqwP/RVY91y0AIU0sCy2kn981uFrW1TI9LBQ nsWg==
X-Gm-Message-State: AOAM53290or8/NZZPyxRY0xkyr58k9Du7C2dAjV+Y30FG6U57lboW76c ld9aitNnZ/YR4t7c1QYuOyKlXycKK2YN7WpKNy4DTw==
X-Google-Smtp-Source: ABdhPJxLzLDz9UlDko8/RQcdV726U0HKYACGF6xddfn9wLEju0ioW5ISIE2q3OG9MsMGocrLXZZtXWTP5YjnZJeNRI8=
X-Received: by 2002:a2e:5cc7:: with SMTP id q190mr999901ljb.37.1616162414577; Fri, 19 Mar 2021 07:00:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Fri, 19 Mar 2021 15:00:03 +0100
Message-ID: <>
To: Jeffrey Haas <>
Cc: "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="0000000000009edebe05bde42256"
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 14:00:19 -0000

See inline ...

I think a point lacking in most of the proposals is how they're intending
> the feature to be used.  That's setting a number of conflicting
> expectations
> in the heads of the authors.
> Examples:
> 1. Whatever you plug into this port will be fine, just connect me!
> 2. I'm willing to only connect to peers over ipv6 link local, or some
>    specific family.
> 3. I'm only interested in peers that support specific AFI/SAFI
> 4. I'll only connect to peers that acceptable ASes in this range.
> 5. I only want one peering session with a given router.
> etc.

Most if not all of that can be expressed in the auto peering policy
If needed, operators can define rules managing auto peering and placing
some additional controls on it.

Also part of such a template maybe limiting one side to be passive only.

>  This is generally not a problem for existing BGP speakers because you

> configure what you don't want to use.  But once you introduce
> auto-configuration, you end up with the same problem as hundreds of
> sessions
> that are misconfigured trying to get into your box every X seconds.

If you do not expose port 179 to those 100s of peers no one will ring your
door bell from that side. If you do then it is no different then today ...
anyone can send TCP OPEN on that port which you need to respond to in some

But again is that really a real risk if we scope it for DC use case ?