Re: Debugging accepted routes from BGP speakers

> On Nov 18, 2019, at 4:50 AM, Robert Raszuk <[email protected]> wrote:
> 
> 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 ? 

I may have more than one session with the provider and need to know on a per-session basis.

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

Sure, I’m sure the GROW chairs would welcome a draft.

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

I welcome you to open issues/suggestions (Job poked me about the existing GitHub page we have) here:

https://github.com/bgp/draft-mauch-idr-accepted-prefixes/issues

I can think of several things that people have suggested that I add including:

ack on a per-prefix/update basis
dump list of prefixes accepted
dump list of prefixes rejected
dump just counts of accepted/rejected
or perhaps variants of all of these.  (i also heard “i want to know if it’s the best-path and installed in fib”).

I think when we’re trying to write this, we should be focusing on what is minimally possible to do vs trying to enumerate them all. 

My intent here is to just know “does this pass the policy engine”, not did it win best path, etc.  We (akamai) see our ISP providers not always accept our prefixes but it’s not clear until you’re already in that failure case.  We would like to improve the ability to QA on our routing, which since each LG has a different API makes things often infeasible to scale.

- Jared

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