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

From: Jeffrey Haas <[email-masked]>
Date: Thu, 4 Oct 2018 15:40:52 -0400

On Mon, Sep 17, 2018 at 12:59:58PM -0700, [email-masked] 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

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Thu, 4 Oct 2018 23:42:34 +0000

On 10/4/18, 12:41 PM, "GROW on behalf of Jeffrey Haas" <[email-masked] on behalf of [email-masked]> wrote:

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

    

<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

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 11 Oct 2018 16:49:37 -0400

Tim,

On Thu, Oct 04, 2018 at 11:42:34PM +0000, Tim Evens (tievens) wrote:
> 	In other words, the Adj-RIB-Out Pre-Policy is exactly what would

This sentence really should go into the draft since it makes it much clearer
what you're intending.

> 	shouldn’t change this as that would be based on the peering configuration.

So, offering some concrete examples:

Example 1:
- Destination D is the active route.
- Destination D would not be eligible for advertisement to an internal peer
  because it'd loop.
- best-external is configured.
- Backup path B the best external path is advertised.

So, in this situation, you expect B to be advertised sans export policy
being applied as the pre-policy route?

Example 2:
- Add-paths is enabled.
- Destination D1 is the active route.  D2..Dn are add-paths eligible backup
  paths.
- Post-policy, D1..Dn are advertised.

In this situation, what is advertised in pre-policy?

> 	of this via the OPEN messages in PEER UP and (b) consider configuration. 

FWIW, I find this point clear.

-- Jeff

---

From: Zhuangshunwan <[email-masked]>
Date: Fri, 12 Oct 2018 01:44:29 +0000

Inline with [Shunwan]

Thanks,
Shunwan

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Friday, October 12, 2018 4:50 AM
To: Tim Evens (tievens) <[email-masked]>
Cc: [email-masked]
Subject: Re: [GROW] bmp rib-out pre-policy questions (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-02.txt)

Tim,

> 	be advertised had there been no egress policy applied. This is

This sentence really should go into the draft since it makes it much clearer what you're intending.

Example 1:

So, in this situation, you expect B to be advertised sans export policy being applied as the pre-policy route?
[Shunwan] IMO, best-external should be considered as one of the egress policies, so path B cannot exist in the pre-policy route set.

Example 2:
- Add-paths is enabled.

In this situation, what is advertised in pre-policy?
[Shunwan] Add-paths knob is also considered as one of the egress policies, so only destination D1 is advertised in pre-policy in this case.

My 2 cents.

-- Jeff

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