Re: Debugging accepted routes from BGP speakers

Hey Job,

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

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 :)

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.

Thx,
R.

On Mon, Nov 18, 2019 at 10:39 AM Job Snijders <[email protected]> wrote:

> Dear Robert,
>
> On Mon, Nov 18, 2019 at 9:28 AM Robert Raszuk <[email protected]> wrote:
> > 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 ?
>
> You raise good points, I'll park this architectural question for
> broader discussion on where we as a group want to go.
>
> > As to your document - few questions/observations:
> >
> > * new message likely will require new capability.
> > * "Unknown IANA Considerations" is a new one :)
>
> Yup, that is plumbing that needs to happen. We'll get a revision out
> to address these points so a more complete proposal is on the table.
>
> > * How much does it help to know that peer's ASBR accepted your prefix
> but it got filtered on egress of peering AS ?
>
> In Internet routing operations, the common occurrence of the debugging
> action we are trying to optimize is "are you accepting my route" and
> much rarer "are you exporting it in the right places". While the
> latter question is interesting, I don't see answering that question as
> important as the first one. The latter one is oftentimes easily
> validated by Internet-wide looking glasses, where as the first
> instance has a stronger dependency on the adjacent network providing
> (public) looking glass services.
>
> > * 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 ?
>
> Yes, good point, this should be clarified. The intention here is at
> least "rejected by policy" and "failed to pass origin validation check
> (which is a variant of 'rejected by policy'). However, it would be
> good to hear more feedback on whether routes that are not considered
> in the best path selection process due to an incorrect NEXT_HOP (or
> AS_PATH loop, or whatever) should be communicated back as part of this
> feature or not
>
> Kind regards,
>
> Job
>

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