Re: [Idr] Debugging accepted routes from BGP speakers

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF0891201DB for <>; Mon, 18 Nov 2019 01:28:38 -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 U-5hg7z37Dek for <>; Mon, 18 Nov 2019 01:28:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB02E12004F for <>; Mon, 18 Nov 2019 01:28:36 -0800 (PST)
Received: by with SMTP id m16so13754472qki.11 for <>; Mon, 18 Nov 2019 01:28:36 -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=zMJ4wKFcAHguRV3EfboaDKdC+GsMp+d6lGV8xh+OMKU=; b=bvRbEH/Rdki1nLCSUF+HYSwVSPTA5rlOEDlR3xKX7JMH5sxoOwrMZpDxbECW0WHpCQ 4h50/2WWfs/95cMWUrT/498ILSMNMdQ5ihgZ9FeP4V7EKWxyUbFirIlrYRncSbAmLkj4 GJsT0hIHnhcOjs2D3Tp13b7cTWak28FaRvtJPnFWiU6DUirZ0ZiXsNf8Uwmfbs8JVzMJ /vySTFLML+QyUZDEOlQi73yl4Qo9m1saHEdYC9f0ef6vB+2VOixQUXtGGzPzdZHrCdfr nIsiY7iS+NG65xqgoe+Bca4386i3VuI9cVJM+ZRAWulVcojgQIogzMK/UREmDfKPoU/t YAmg==
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=zMJ4wKFcAHguRV3EfboaDKdC+GsMp+d6lGV8xh+OMKU=; b=RaqepA7lCJPrwiEuAaBJ004prTpgy4bEE/TfPWX1ZU+0hw+A/N+cX91CMA/qOLe6C5 VCETrUgcjhgn1UohvAO3iTq6ah46C6B/jMaqh190L5g7aZ9gXah0sZ7fnrdmoNxbn9aD 4kwNByF3H9pN8x/ht2R4lywBk+KJwfb+QyyUwvcII2rKBQxEb1XjnXem/KJSF43+yaai Y/G70JTddUa8ldOa26KPvp5+8cQM/RveRtLsM6tO5dVrClH95QCU1BfOW6iMtLUhk/+T WX39k1wGbBa1POwkj8/eFCtKY1ZHWZnL+214TuWJ1bsy9OjMq/aB/Euk+cn3qbYHUWHn nM9A==
X-Gm-Message-State: APjAAAVfsHNKEFUfI0Ee9mcIMt6M0m4BOHSgDyQ0eG14O3TQrjgyhklo 80AENrI2v3dIC1V1fKvlDIqw04Yx+x7lQU8xBUL5TA==
X-Google-Smtp-Source: APXvYqwnxg6QXTc5+r/zNYUWMqmYEWWD0f2dWhc8J/xQJw3pJQ2ckLsYLKmuEKfLEKDh8wh5aRZYHuBCnTkdq9CKrR0=
X-Received: by 2002:a05:620a:628:: with SMTP id 8mr23193735qkv.465.1574069314960; Mon, 18 Nov 2019 01:28:34 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Mon, 18 Nov 2019 10:28:25 +0100
Message-ID: <>
To: Jared Mauch <>
Cc: IDR <>
Content-Type: multipart/alternative; boundary="0000000000005ed3bb05979b9275"
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:28:39 -0000

Hi Jared,

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 ?

As to your document - few questions/observations:

* new message likely will require new capability.

* "Unknown IANA Considerations" is a new one :)

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

* 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 ?


On Mon, Nov 18, 2019 at 9:54 AM Jared Mauch <> wrote:

> Greetings,
> As a network operator we often don’t know if our ISPs are accepting the
> routes we send to them.  This makes it difficult at times for operators to
> debug things.  This is a first stab at a draft to try and propose a method
> to have the remote device echo back some route counts (and possibly NLRI)
> that were both accepted and rejected by the remote speaker.
> It’s got a few things that I know need to be fixed at minimum, but I
> wanted to share this more broadly now.
> I’m interested in feedback and ready to accept your arrows.
> - Jared
> > URL:
> > Status:
> > Htmlized:
> > Htmlized:
> >
> > Abstract:
> >   This document defines a method to receive accepted and rejected NLRI
> >   over a BGP peering session.
> _______________________________________________
> Idr mailing list