On Mon, Sep 17, 2018 at 12:59:58PM -0700, [email protected] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Global Routing Operations WG of the IETF.
> 
>         Title           : Support for Adj-RIB-Out in BGP Monitoring Protocol 
> (BMP)

A few clarification questions, partially motivated by an implementation in
progress:

:   Depending on BGP peering session type (IBGP, IBGP route reflector
:   client, EBGP) the candidate routes that make up the Pre-Policy Adj-
:   RIB-Out do not contain all local-rib routes.  Pre-Policy Adj-RIB-Out
:   conveys only routes that are available based on the peering type.
:   Post-Policy represents the filtered/changed routes from the available

The first one deals with the wording above.  I suspect what is intended to
be said is effectively that the route considered might not be a BGP route?

I think this is motivated by the somewhat sloppy meaning of loc-rib in 
RFC 4271 with respect to non-BGP routes.  Section 9.4 in there tries to
clarify what happens when you want non-BGP information to be injected
(redistribution), but the wording of the Decision Process largely restricts
itself to discussing Adj-Ribs-In.

This isn't a new issue, it generated a lot of noise during 4271's work in IDR.

Where this leads to some interesting ambiguity, and will have impact also in
the loc-rib doc (comments sent separately), is whether we're reporting on
what systems typically consider the "active" route vs. the best bgp route.

The second issue is distinct from the wording above, active or even best
bgp route.  I suspect that what is typically desired for telemetry purposes
is "show me the 'before' view of the route that we're actually advertising
in post-policy".  This may be very distinct from active or best bgp in some
scenarios.  A few examples include:
- best-external feature
- add-paths


-- Jeff

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

Reply via email to