Re: [Idr] Debugging accepted routes from BGP speakers

Robert Raszuk <> Mon, 18 November 2019 09:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38B4F120043 for <>; Mon, 18 Nov 2019 01:50:36 -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 wTcOXfDoflL2 for <>; Mon, 18 Nov 2019 01:50:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D710120018 for <>; Mon, 18 Nov 2019 01:50:34 -0800 (PST)
Received: by with SMTP id n4so19566755qte.2 for <>; Mon, 18 Nov 2019 01:50:34 -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=GJLJTVNzidVaBSTcZka85jgQiw0p0GbScXYkeXXEnzU=; b=Hsg4No+sEfc+X6tdl37raxmIPbQcAy5mRJ0mviY+W8rArZNx7pgyNdp5Q1kSAdMcCk wyxcAPVhGK1FpNnSTPNnyK52hPwBMEsvyxyCE4Tr54Y0F/tv0oC+tA4tSk/rO1XVHv9S 7+1oou4VHgcvjNe18m/o1lh2yL9p5YNtqoiN+/z/ukc/MDgqSpci8HbWdg4cltGymbP1 LPUWfCTWwY3d9N+Yu+1CLUlR45SaRoQ99c85OcgnSZAqOpcx86Xo3AkLO3U0b4/u8Ako SnhZDDrHkRX5ruI467f4XK2Gg5K3sV4p7nyc/RESxLS8KcipLbu9VktDrEAu2jPmAWht rZpw==
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=GJLJTVNzidVaBSTcZka85jgQiw0p0GbScXYkeXXEnzU=; b=WWqaU/JQ+omFgzEDwOSlneRdDO32MLOWSQemfSReqO0WmWdElvc6Geg1u3Q9Cy3tOj sQzrGJ/0j/VVVmYDKHPCdqK+yqssH6UqvjdOXMpBV67qj84aBjgsvXk2mmOBeVHcVEZx 0FHNu+h2HDtM9AaGv9/k59oe5U35yOmcrlBCBRN/0prxKMtVkwnBBdIL8yMN+7imIu0V Lh2yCpvBURa1esjsv2m600/i8GBX3h5KeieX5/0VfK0l+N/Hk/pV7yCaVHAUt9dnnaBI ZDuuseSfPr5vQHOqaeC4rVvdII4i8JJfvYRxyHex+zzgRN9jEo5k2TKNNxWReogUzkQj t/Rg==
X-Gm-Message-State: APjAAAVduZtCAXIT4XCcAIGhPmCIOe7h2pYTyjkeyOG1/3tFKkRlRins MKJ6FwbfrFTDCHKnqCpuyGqOcceP9RtsarM63gTBNk3vc4U=
X-Google-Smtp-Source: APXvYqwkS31+ohBqYS5nZ5cKbqWYr8SvoNznJZnzGI+nzVR/uUGGuvEXDNleM/ut1WGYK+qkNazsf5jJzbHYjS81KIQ=
X-Received: by 2002:ac8:3168:: with SMTP id h37mr26114143qtb.311.1574070633206; Mon, 18 Nov 2019 01:50:33 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Mon, 18 Nov 2019 10:50:24 +0100
Message-ID: <>
To: Job Snijders <>
Cc: Jared Mauch <>, IDR <>
Content-Type: multipart/alternative; boundary="000000000000f1aded05979be0e9"
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:50:36 -0000

Hey Job,

> The latter one is oftentimes easily validated by Internet-wide looking

Hmmmm I must say that IMHO both latter and former could be addressed by
looking-glass. In fact when I read this draft that was my first question -
why not to just look at peer's looking glass ?

So perhaps we should simply issue a BCP to say that each AS should run a
looking glass server holding all paths and declare victory ? And that could
be all GROW WG thing too :)

I already see a bunch of new things we could accomplish in the Internet if
we would have those in place consistently everywhere - at least for each
transit AS.


On Mon, Nov 18, 2019 at 10:39 AM Job Snijders <> wrote:

> 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,
> Job