On 10/4/18, 12:41 PM, "GROW on behalf of Jeffrey Haas" <[email protected]
on behalf of [email protected]> 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
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
