Re: Debugging accepted routes from BGP speakers

There are varying desires from operators. It may be as simple as a count to the list of accepted or rejected NLRI. 

If you look at the text the desire is to know is this path eligible for selection. That is accepted. 

Sent from my iCar

> On Nov 18, 2019, at 5:28 PM, Robert Raszuk <[email protected]> wrote:
> 
> 
> Hi Jared,
> 
> 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 ? 
> 
> As to your document - few questions/observations: 
> 
> * new message likely will require new capability. 
> 
> * "Unknown IANA Considerations" is a new one :) 
> 
> * How much does it help to know that peer's ASBR accepted your prefix but it got filtered on egress of peering AS ? 
> 
> * 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 ? 
> 
> Thx,
> Robert.
> 
> 
> 
> 
> 
>> On Mon, Nov 18, 2019 at 9:54 AM Jared Mauch <[email protected]> wrote:
>> Greetings,
>> 
>> As a network operator we often don’t know if our ISPs are accepting the routes we send to them.  This makes it difficult at times for operators to debug things.  This is a first stab at a draft to try and propose a method to have the remote device echo back some route counts (and possibly NLRI) that were both accepted and rejected by the remote speaker.
>> 
>> It’s got a few things that I know need to be fixed at minimum, but I wanted to share this more broadly now.
>> 
>> I’m interested in feedback and ready to accept your arrows.
>> 
>> - Jared
>> 
>> > URL:            https://www.ietf.org/internet-drafts/draft-mauch-bgp-accepted-00.txt
>> > Status:         https://datatracker.ietf.org/doc/draft-mauch-bgp-accepted/
>> > Htmlized:       https://tools.ietf.org/html/draft-mauch-bgp-accepted-00
>> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-mauch-bgp-accepted
>> > 
>> > Abstract:
>> >   This document defines a method to receive accepted and rejected NLRI
>> >   over a BGP peering session.
>> 
>> _______________________________________________
>> Idr mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/idr

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