Re: [Idr] Debugging accepted routes from BGP speakers

[Job Snijders <[e-mail]>]

Dear Robert,

On Mon, Nov 18, 2019 at 9:28 AM Robert Raszuk <[e-mail]> 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