Re: Debugging accepted routes from BGP speakers

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) <[email protected]>
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 <[email protected]>
> *Sent:* Tuesday, November 19, 2019 1:18 AM
> *To:* Jakob Heitz (jheitz) <[email protected]>
> *Cc:* Job Snijders <[email protected]>; IDR <[email protected]>
> *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) <[email protected]>
> 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 <[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