Re: [GROW] bmp rib-out pre-policy questions (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-02.txt)

["Tim Evens (tievens)" <[e-mail]>]

On 10/4/18, 12:41 PM, "GROW on behalf of Jeffrey Haas" <[e-mail] on behalf of [e-mail]> wrote:
    
    :   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?

<Tim> No, it's related to how some prefixes will be advertised while others will
	not, caused by peering type not egress policies. For example, IBGP excludes  
	routes depending on reflector configuration.  This text is trying to articulate
	to keep it simple and consider prefixes as candidates for Pre-Policy based
	on the peer configuration.  If using RR-client, then include reflected
	routes, but if not, then don't include those in the pre-policy.  Post-Policy
	is supposed to represent the egress policy filtered/modified NLRI's/attributes.
	This is to support policy assurance/validation (diff of pre vs post)
 	If Adj-RIB-Out Pre-Policy included all local-rib candidate routes without
	regard to peering type, then a compare/diff of pre to post policy RIB's
	would render several routes missing, but are not missing/dropped by the
	egress policy.  This leaves a gap in knowing why those routes are missing. 
	Instead of trying to complicate it, the Adj-RIB-Out Pre-Policy should
	represent the routes that would actually be advertised sans an egress
	policy. In other words, the Adj-RIB-Out Pre-Policy is exactly what would
	be advertised had there been no egress policy applied. This is
	peer specific.
    
    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
    
<Tim> Adj-RIB-Out Pre-Policy should be the routes that would be advertised had
	there been no egress policy applied.  The question of best, add-paths, ...
	shouldn’t change this as that would be based on the peering configuration.
	There are some folks that are having a hard time with understanding how
	we take peering configuration into account, but IMO, we (a) can get some
	of this via the OPEN messages in PEER UP and (b) consider configuration. 
	No network (or system for that matter) is managed or monitored by a single
	method of collection. I fully expect and plan that we will be using
	netconf/restconf/gNMI/whatever to correlate configuration to operational
	 state/monitored data via BMP, similar to ipfix.  I do not
	believe we need to complicate BMP to include configuration as we
	have better means to obtain that. I consider the OPEN messages in PEER UP
	operational (not config) as they are a way for us to discover the
	session parameters and capabilities advertised.  It is important that we do
	have a clear method to correlate the two datasets together.
	For example, BMP peer X == Configuration Peer X.

    
    -- Jeff