Re: [Idr] Debugging accepted routes from BGP speakers

Jared Mauch <jared@puck.nether.net> Mon, 18 November 2019 09:47 UTC

Return-Path: <jared@puck.nether.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 9AACE120043 for <idr@ietfa.amsl.com>; Mon, 18 Nov 2019 01:47:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 kEsXs1RBxkPr for <idr@ietfa.amsl.com>; Mon, 18 Nov 2019 01:47:41 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF3D120018 for <idr@ietf.org>; Mon, 18 Nov 2019 01:47:41 -0800 (PST)
Received: from [31.133.159.107] (dhcp-9f6b.meeting.ietf.org [31.133.159.107]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 215DF540172; Mon, 18 Nov 2019 04:47:38 -0500 (EST)
Content-Type: multipart/alternative; boundary=Apple-Mail-06C8580D-B0D0-40CE-81E2-36BB21E3AB67
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <CAOj+MMGOT4jyAaaiQ6PngdNFSGx3BrmS6wU+-Pg1Oow16wRYZA@mail.gmail.com>
Date: Mon, 18 Nov 2019 17:47:35 +0800
Cc: IDR <idr@ietf.org>
Message-Id: <D5758D37-000F-426A-8005-361C722F32A7@puck.nether.net>
References: <CAOj+MMGOT4jyAaaiQ6PngdNFSGx3BrmS6wU+-Pg1Oow16wRYZA@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (17B102)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/dnZ52KH6ijx7ruJcZyWTYEeWx2w>
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:47:44 -0000

There are varying desires from operators. It may be as simple as a count to the list of accepted or rejected NLRI. 

If you look at the text the desire is to know is this path eligible for selection. That is accepted. 

Sent from my iCar

> On Nov 18, 2019, at 5:28 PM, Robert Raszuk <robert@raszuk.net> wrote:
> 
> 
> Hi Jared,
> 
> 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 ? 
> 
> 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 ? 
> 
> Thx,
> Robert.
> 
> 
> 
> 
> 
>> On Mon, Nov 18, 2019 at 9:54 AM Jared Mauch <jared@puck.nether.net> 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:            https://www.ietf.org/internet-drafts/draft-mauch-bgp-accepted-00.txt
>> > Status:         https://datatracker.ietf.org/doc/draft-mauch-bgp-accepted/
>> > Htmlized:       https://tools.ietf.org/html/draft-mauch-bgp-accepted-00
>> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-mauch-bgp-accepted
>> > 
>> > Abstract:
>> >   This document defines a method to receive accepted and rejected NLRI
>> >   over a BGP peering session.
>> 
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr