Re: [Idr] Debugging accepted routes from BGP speakers

Robert Raszuk <robert@raszuk.net> Tue, 19 November 2019 18:43 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 2999B120BE9 for <idr@ietfa.amsl.com>; Tue, 19 Nov 2019 10:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 S-M0FRL6Rjw3 for <idr@ietfa.amsl.com>; Tue, 19 Nov 2019 10:43:29 -0800 (PST)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 A37C5120BE6 for <idr@ietf.org>; Tue, 19 Nov 2019 10:43:29 -0800 (PST)
Received: by mail-qt1-x82b.google.com with SMTP id t8so25795165qtc.6 for <idr@ietf.org>; Tue, 19 Nov 2019 10:43:29 -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=T21v3o5Ksqy/d8qlmiYFdC3pZlOUPRO7I4E5ef5sGbk=; b=T4xyAZKNIPmb/vmqlWZNtoOoY2asSjKC3CYMZ7QWoW/TwwL6fpcbcA+bNlHg+buoM8 UlYXMvRG4V0BsdVAekXgtaOsfGfFcKfseSDvHmpMfLqU4Kg8l1cdaD0T8A8XW6Bsxzqb Z3fm+8Nc1867qfRMo+mLHHhR4hXfBqNepDdLBa3uYioU3RbrtKL8TdxMPc7AJcZZT0+I CLclqutQXHHuBJ9ThKiT0QpTAPiWJBflqw6sAmOVjf+j8gmFaq82vGl+V9nifJrbFtdj TXYwmWdut7/JJFaPXc/HtPxiXNT42QjQhl4/Ms6z3NSXlC9ft37qtytoyblOM7OFVSWF hAhA==
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=T21v3o5Ksqy/d8qlmiYFdC3pZlOUPRO7I4E5ef5sGbk=; b=tnT5VGA7CQOQC64ZtNLylkFtuH0n9G3HUj/BngMKvIU1jo+iQJB607vRSKsgc7L2qI Q9nJnS5rYJ7TKKXflaxChTs3aZ92qdzKdFOXErwABqqPXwiXH68V59+WRqCyaxR9vlWE kPrqr2rWbG/p4tFQ+dCLzlJl9epN4B4uBFZvM24d0JlQVestswLiJLJcP/HvaT0o+IHp RqGF08LbK1o0KZ/MqQJ0CI2pswl8mHC2KXRu5ONiy1m8+N2dSoAGvxTsFVXiDlEHZ3w9 qnRbd8/inyl6BzGxIN/+1gDdM/Ue6RdAw6ZfRqIfcl/x3gx/G10Z/IxSiF9/cIbRxFDD tLIA==
X-Gm-Message-State: APjAAAVFnvlBRPOwaGeYjVU2kt6aWg+pl2krCdb9b980SQ7/5vO1eg2d UEJsNeF251qPs1zoVgIO3RJH/m0i99BbuFGgFw2uFw==
X-Google-Smtp-Source: APXvYqx1fSM9dpjU6p4SJulthWTmFNGFKr+fazl4Ib5zd9jL+meq0lsuy+rrEW/neGOlA/08F9XV9tfGDkftyDV8Njc=
X-Received: by 2002:ac8:721a:: with SMTP id a26mr33905805qtp.208.1574189008420; Tue, 19 Nov 2019 10:43:28 -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> <CAOj+MMETtqBw5cRLna=eSVa5ezXeR=NjeT_q5JQVhAyVruziTw@mail.gmail.com> <CACWOCC-8yPsr8qXMD2cUTjkKEc1cnTG+6vA1tfQtQ6n248rrJA@mail.gmail.com> <MWHPR11MB18075F3AD772326EE90E39A0C04C0@MWHPR11MB1807.namprd11.prod.outlook.com> <CAOj+MMGFW63-ks04fiL2gQLuajM0oicveCabH5=D-z1Gqy0XmQ@mail.gmail.com> <MWHPR11MB1807746910ACB5CE536014CCC04C0@MWHPR11MB1807.namprd11.prod.outlook.com>
In-Reply-To: <MWHPR11MB1807746910ACB5CE536014CCC04C0@MWHPR11MB1807.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 19 Nov 2019 19:43:18 +0100
Message-ID: <CAOj+MMEQwfOy0W9DLUrQcBGYW0qABQp5+gwcL2=PtwRcvaYAYg@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Cc: Job Snijders <job@instituut.net>, IDR <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a967020597b77083"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/wJtQNjZgyOGsPN_mDyeupHEQ37g>
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: Tue, 19 Nov 2019 18:43:32 -0000

Hi Jakob,

> Easy fixed. Do next-hop-unchanged on an echo path.

I don't think the above will be sufficient the way it is expected to work.
If you still want to stick it into existing AFI/SAFI and send it on the
same session the only feasible option I could see is to actually send all
paths back with ADD-PATHs on the eBGP.

However I am not sure if we would want to go there.

I am suggesting to resurrect BGP Operational Message IDR WG draft and do
this properly. At least now we seems to be having some operational support
:).

Best,
R.

PS. And I agree with the other part of your comments. But as Jared & Job
explained this is not about data plane ... this is just to make sure my
path was accepted to your BGP.







On Tue, Nov 19, 2019 at 7:29 PM Jakob Heitz (jheitz) <jheitz@cisco.com>
wrote:

> Robert,
>
>
>
> You are right about the echoed path being a different path.
>
> I forgot that ebgp does next-hop-self, so the receiver of the
>
> echo cannot be sure it is his own echo.
>
>
>
> Easy fixed. Do next-hop-unchanged on an echo path.
>
>
>
> Another fix would be to add a community.
>
> However, that would be harder to implement.
>
> Ease of implementation is important if you want your
>
> feature implemented.
>
>
>
> The draft mentions nothing about backup.
>
> I do remember some years ago, Ignas asked for this kind of feedback,
>
> so he could know whether he should install a backup on the sender end.
>
> Suppose R1 sends a route to R2. If R2 accepts the route,
>
> R1 would like to install a backup in its FIB. Since FIB space
>
> is precious, R1 does not want to install a backup if R2 does not
>
> use R1's route.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Tuesday, November 19, 2019 1:18 AM
> *To:* Jakob Heitz (jheitz) <jheitz@cisco.com>
> *Cc:* Job Snijders <job@instituut.net>et>; IDR <idr@ietf.org>
> *Subject:* Re: [Idr] Debugging accepted routes from BGP speakers
>
>
>
> Hey Jakob,
>
>
>
> But this is not what is being asked here.
>
>
>
> There is need to validated if routes received on *specific* eBGP session
> were accepted by bgp inbound policy.
>
>
>
> What you suggesting is also quite useful but IMO 100% orthogonal to the
> topic.
>
>
>
> Reason being that in your scenario router would advertise the best path to
> a peer back which may not be local eBGP route. Worse I may have N eBGP
> session to a given peer's ASBR and I would like to make sure all of my
> paths has passed his policy.
>
>
>
> Moreover as Jared said he is not so much concern of overall
> reachability validation. He is concerned when his most preferred path goes
> down does his peer has backup path(s) to him.
>
>
>
> Kind regards,
>
> R.
>
>
>
> On Tue, Nov 19, 2019 at 6:19 AM Jakob Heitz (jheitz) <jheitz@cisco.com>
> wrote:
>
> In https://tools.ietf.org/html/rfc4271#section-9.1.2
> the AS loop is broken at the receiver.
> Nowhere does it say that the sender must break the AS loop.
> Split horizon filtering is a common practice, but nowhere
> is it mandated. At least I could not find it.
>
> If the receiver of your route were to send you back its
> best path, even if it's your route, then you have your
> information.
>
> We could invent an address-family specific capability
> to indicate that you wish your route to be echoed back.
>
> Regards,
> Jakob.
>
> -----Original Message-----
> From: Idr <idr-bounces@ietf.org> On Behalf Of Job Snijders
> Sent: Monday, November 18, 2019 3:00 AM
> To: Robert Raszuk <robert@raszuk.net>
> Cc: IDR <idr@ietf.org>
> Subject: Re: [Idr] Debugging accepted routes from BGP speakers
>
> On Mon, Nov 18, 2019 at 9:50 AM Robert Raszuk <robert@raszuk.net> wrote:
> > > 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 ?
>
> Many networks unfortunately do not make BGP Looking Glasses available,
> nor is there any standardized interface/method/design/approach for BGP
> Looking Glasses. So solely relying on Looking Glasses for this
> functionality has proven to be insufficient.
>
> > 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 :)
>
> That is an interesting idea, but in my mind not the exclusive viable
> solution.
>
> > 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.
>
> Agreed - it would be a nicer world. Through the MANRS initiative I've
> pitched the idea to provide more encouragement for networks to provide
> looking glasses to the public, but arguably their availability is not
> ubiquitous.
>
> Another observation is that in the "IP Transit Carrier" segment of the
> market we see BGP Looking Glasses from time to time, but we rarely see
> similar functionality offered by Cloud/CDN providers. Perhaps the
> latter category is not interested in running & maintaining looking
> glasses, or perhaps there are other constraints that prevent them from
> exposing this information via suchs tools. My hope is that by creating
> a feedback mechanism in BGP we create more opportunity to share
> debugging information specific to EBGP sessions between different
> orgs.
>
> Kind regards,
>
> Job
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>