Re: Debugging accepted routes from BGP speakers

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 <[email protected]> On Behalf Of Job Snijders
Sent: Monday, November 18, 2019 3:00 AM
To: Robert Raszuk <[email protected]>
Cc: IDR <[email protected]>
Subject: Re: [Idr] Debugging accepted routes from BGP speakers

On Mon, Nov 18, 2019 at 9:50 AM Robert Raszuk <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr