Re: [Idr] Debugging accepted routes from BGP speakers

Robert Raszuk <robert@raszuk.net> Mon, 18 November 2019 09:50 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B4F120043 for <idr@ietfa.amsl.com>; Mon, 18 Nov 2019 01:50:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTcOXfDoflL2 for <idr@ietfa.amsl.com>; Mon, 18 Nov 2019 01:50:34 -0800 (PST)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D710120018 for <idr@ietf.org>; Mon, 18 Nov 2019 01:50:34 -0800 (PST)
Received: by mail-qt1-x829.google.com with SMTP id n4so19566755qte.2 for <idr@ietf.org>; Mon, 18 Nov 2019 01:50:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; 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; d=1e100.net; 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: <157406668522.14183.13795160095173591028.idtracker@ietfa.amsl.com> <EC0AF47A-D6F3-4903-A597-C0F18520A8B0@puck.nether.net> <CAOj+MMGOT4jyAaaiQ6PngdNFSGx3BrmS6wU+-Pg1Oow16wRYZA@mail.gmail.com> <CACWOCC8yD+fWaSeTkHd+UubzfnxgBbbFXCeuRuzVcmK6VQqKew@mail.gmail.com>
In-Reply-To: <CACWOCC8yD+fWaSeTkHd+UubzfnxgBbbFXCeuRuzVcmK6VQqKew@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 18 Nov 2019 10:50:24 +0100
Message-ID: <CAOj+MMETtqBw5cRLna=eSVa5ezXeR=NjeT_q5JQVhAyVruziTw@mail.gmail.com>
To: Job Snijders <job@instituut.net>
Cc: Jared Mauch <jared@puck.nether.net>, IDR <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f1aded05979be0e9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/I8K9r9olamrGTNZXIKgum3uA8qo>
Subject: Re: [Idr] Debugging accepted routes from BGP speakers
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=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
glasses

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.

Thx,
R.

On Mon, Nov 18, 2019 at 10:39 AM Job Snijders <job@instituut.net>; wrote:

> Dear Robert,
>
> On Mon, Nov 18, 2019 at 9:28 AM Robert Raszuk <robert@raszuk.net>; wrote:
> > As you know what you are asking for has been covered by previous work
> and even IDR WG document:
> > https://tools.ietf.org/html/draft-ietf-idr-operational-message-00
> >
> > 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
>