Re: [Idr] Debugging accepted routes from BGP speakers

Job Snijders <> Mon, 18 November 2019 09:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6184A1208A9 for <>; Mon, 18 Nov 2019 01:39:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 q_TSzvDI-Hjq for <>; Mon, 18 Nov 2019 01:39:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16E4A120018 for <>; Mon, 18 Nov 2019 01:39:47 -0800 (PST)
Received: by with SMTP id 14so14671115oir.12 for <>; Mon, 18 Nov 2019 01:39:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9aof7JhasmTwRppCpdRj/D0l/IKpHetmV5SZ8Ds+gcQ=; b=vOGJTDnZpVqTVC1KPj7bQzxuyWcIkV4ZK/VJmOlqgBkHaV89TNK7yqtN1XWaoxexKb u0FD85eBv43KiiYxiDaKurEi5IdTuGZDBp7ZzohMqrJHZjiHch9QB2S7+TnHCDJN1aHL 9cOGgAaj55cWvmIH4ccYmN+yOQDhYsNtUl19udxZjRSNG/I87YVH2AQDfWjFrB2wfxBH LNde3ItdwsYIONqnf+NgQRj4xiRbOF/pkV7/5JJqYDVa3AzkQ19NjWGNFQ9MHBaXO0xr WoIwkAmjaPdfaN81eZRsHTi+srAss3LsCD3/SuECHEtBeXAjyhcKy4+NC9vcWkbsJmpG E+yQ==
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=9aof7JhasmTwRppCpdRj/D0l/IKpHetmV5SZ8Ds+gcQ=; b=FskExuE3kb4tXUCo/5Qlxjg7wwjx8x6ejfJL+Z1DJB24H5IvY+NUkoFKKe/dYbuTAX Z2YRwCnQgaZofz/zSty/zRhPStwlDOt/0+q3TVlvghBpVTaW30dEwdquBwahOj4BksKl xY+Y9ERKuNx9WW+B6G/gKHZ7I22HCg/8TmzmnkEcRVXBYmFccyPB2cBjnEM6M76AY+Mp kTDBCE9gJv7FTYRFnBLKwV2AYCQojuF7/otcn1alh6IKDjoaum3YSGb9ao063kgY6vaZ VRTiqCDOwreUPKSVWlS1zXAt0teC/VowV33PCK4VpEBThvRbEQYPnAHkr2BGkf5vHgwB LZBQ==
X-Gm-Message-State: APjAAAWWVRyGOj4XsnN653cpWUIFnPZPIXEfl0YzCp7QZH+9BAYeKCX7 sOUs/pW+qHSbpVMfVb4qXpd8Q0VdpkpUL9DBY6WgrA==
X-Google-Smtp-Source: APXvYqzsCJbyf/SK5CsMCI1sS+AdySJH1Ut8MPKUeGZYmJEe0SKKQbn0ZFnNKqsyWq2+/ectuhaI2sa9ctO/cWFGaTs=
X-Received: by 2002:aca:dd0a:: with SMTP id u10mr19813813oig.130.1574069986009; Mon, 18 Nov 2019 01:39:46 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Job Snijders <>
Date: Mon, 18 Nov 2019 09:39:34 +0000
Message-ID: <>
To: Robert Raszuk <>
Cc: Jared Mauch <>, IDR <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Idr] Debugging accepted routes from BGP speakers
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: Mon, 18 Nov 2019 09:39:50 -0000

Dear Robert,

On Mon, Nov 18, 2019 at 9:28 AM Robert Raszuk <> wrote:
> As you know what you are asking for has been covered by previous work and even IDR WG document:
> So as you are defining new BGP message anyway I take there are two options:
> *A*  You think  that what we specified in operational message is too much
> *B* You think that we will never need more information to be exchanged in an informational manner between eBGP peers
> If *A* would you think that clearly making all of those "additional information" as optional would fix the problem and we could proceed with the IDR WG draft in terms of asking for implementation ?

You raise good points, I'll park this architectural question for
broader discussion on where we as a group want to go.

> As to your document - few questions/observations:
> * new message likely will require new capability.
> * "Unknown IANA Considerations" is a new one :)

Yup, that is plumbing that needs to happen. We'll get a revision out
to address these points so a more complete proposal is on the table.

> * How much does it help to know that peer's ASBR accepted your prefix but it got filtered on egress of peering AS ?

In Internet routing operations, the common occurrence of the debugging
action we are trying to optimize is "are you accepting my route" and
much rarer "are you exporting it in the right places". While the
latter question is interesting, I don't see answering that question as
important as the first one. The latter one is oftentimes easily
validated by Internet-wide looking glasses, where as the first
instance has a stronger dependency on the adjacent network providing
(public) looking glass services.

> * What is the definition of rejected ? Dropped by policy ? Not eligible for best path ? Not inserted into RIB as better AD is there ? Marked badly by origin validation ?

Yes, good point, this should be clarified. The intention here is at
least "rejected by policy" and "failed to pass origin validation check
(which is a variant of 'rejected by policy'). However, it would be
good to hear more feedback on whether routes that are not considered
in the best path selection process due to an incorrect NEXT_HOP (or
AS_PATH loop, or whatever) should be communicated back as part of this
feature or not

Kind regards,