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)]

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

 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

 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
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] WG Adoption Call: draft-scudder-grow-bmp-registries-change 2018.09.25-2018.10.09

[Serpil Bayraktar (serpil)]

+1 Support

Serpil

From: GROW  on behalf of Job Snijders 
Date: Tuesday, September 25, 2018 at 9:04 AM
To: Grow Mailing List 
Subject: [GROW] WG Adoption Call: draft-scudder-grow-bmp-registries-change 
2018.09.25-2018.10.09

Dear working group,

Feedback from the working group seems to indicate a preference to follow
regular procedures. So, we will do so!

The author of draft-scudder-grow-bmp-registries-change [1] requested the
chairs to consider issuing a call for working group adoption. Here is
the abstract:

"This document updates RFC 7854, BGP Monitoring Protocol (BMP) by
making a change to the registration procedures for several
registries. Specifically, any BMP registry with a range of
32768-65530 designated "Specification Required" has that range re-
designated as "First Come First Served".

[1]: https://www.ietf.org/id/draft-scudder-grow-bmp-registries-change-00.txt

Please take a moment to read and evaluate the document and let the
working group know whether you'd like to continue work on this document
as working group or not.

We'll close the call on 2018-10-09

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] A question about RFC7854 stats report

[Tim Evens (tievens)]

Qing, 

I can also provide some input on the draft as there are ones we have been 
wanting to add as a correction to the existing types. 

Thanks,
Tim

On 10/4/18, 12:16 PM, "Jeffrey Haas"  wrote:

Qing,

On Thu, Oct 04, 2018 at 11:28:30AM -0700, Qing Yang wrote:
> Points well taken... NLRIs will be an improvement in terminology over
> prefixes, too?
> 
> And yes, type 8 as it is worded today, is the reason that I think one
> cannot derive the number of prefixes rejected by inbound policy from type 
7
> and 8. So I definitely agree with you that an update to RFC7584 would be
> helpful.

A trivial Internet-Draft, at least once 
draft-scudder-grow-bmp-registries-change
has gone through.  My suggestion is to gather a list of stats you might want
and kick off the draft.

-- Jeff


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Request for early allocation of code points for draft-ietf-grow-bmp-(local-rib|adj-rib-out)

[Tim Evens (tievens)]

Sorry for the dumb question, but should I now submit a formal general request 
to https://www.iana.org/form/protocol-assignment for first come first serve 
allocations?   If so, I can submit that right away.  I'll work with Cisco XE 
folks to correct their hijacked usage of this range.

Thanks,
Tim

On 10/4/18, 1:03 PM, "GROW on behalf of Jeffrey Haas"  wrote:

[Please note that this message covers prior discussion among the BMP
loc-rib/adj-rib-out authors and the grow chairs and ADs.  This is mostly to
make sure we are open in our process.]

There are currently multiple implementations of the BMP adj-rib-out and
loc-rib Internet-Drafts in progress.

As noted in draft-scudder-grow-bmp-registries-change, the registries for BMP
parameters at IANA are a bit restrictive.  That draft is working to address
the long-term issues. 

This e-mail is to note a formal request for RFC 7120 early allocation of the
code points for these documents so that interoperable implementations can be
shipped.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt)

[Nick Hilliard]

Jeffrey Haas wrote on 04/10/2018 20:51:

Based on the primary use case for loc-rib (avoid the need for a parallel BGP
session to your BMP rib-in session), I suspect what's intended is "send the
route that's eligible to be sent to BGP".


probably yes, although this may give an obscure view about what's 
actually happening on devices where the bgp route is inactive due to 
having been learned from a different routing protocol.  Is this 
something that can be flagged?


Nick

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Request for early allocation of code points for draft-ietf-grow-bmp-(local-rib|adj-rib-out)

[Jeffrey Haas]

[Please note that this message covers prior discussion among the BMP
loc-rib/adj-rib-out authors and the grow chairs and ADs.  This is mostly to
make sure we are open in our process.]

There are currently multiple implementations of the BMP adj-rib-out and
loc-rib Internet-Drafts in progress.

As noted in draft-scudder-grow-bmp-registries-change, the registries for BMP
parameters at IANA are a bit restrictive.  That draft is working to address
the long-term issues. 

This e-mail is to note a formal request for RFC 7120 early allocation of the
code points for these documents so that interoperable implementations can be
shipped.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt)

[Jeffrey Haas]

On Mon, Sep 17, 2018 at 01:00:22PM -0700, internet-dra...@ietf.org wrote:
> Title   : Support for Local RIB in BGP Monitoring Protocol 
> (BMP)

This question is motivated by an implementation in-progress:

In section 5, we have the following text:

:   Loc-RIB contains all routes from BGP peers as well as any and all
:   routes redistributed or otherwise locally originated.  In this
:   context, only the BGP instance Loc-RIB is included.  Routes from
:   other routing protocols that have not been redistributed, originated
:   by or into BGP, or received via Adj-RIB-In are not considered.

The second sentence is slightly confusing to me, and perhaps the usual
headache about the definition of loc-rib in RFC 4271, redistribution
(section 9.4 of same) and how other implementations work.

Somewhat colloquially, BGP implementations tend to concern themselves with
distribution of the "active" routes in most cases.  Thus, the routes that
get sent are the ones that are in the Routing Table in the RFC 4271 sense.
While there are scenarios where routes that are not the active route are
sent (e.g. add-paths, best-external, etc.), typically the active route is
sent.  This does interact with policy.

Policy normally will say "redistribute other protocol" in the circumstance
where for a given destination the best route is not BGP, but a BGP route is
present.

So... what exactly is intended by that second sentence?  It seems to read
"only pay attention to BGP routes".  

Based on the primary use case for loc-rib (avoid the need for a parallel BGP
session to your BMP rib-in session), I suspect what's intended is "send the
route that's eligible to be sent to BGP".

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Jeffrey Haas]

On Mon, Sep 17, 2018 at 12:59:58PM -0700, internet-dra...@ietf.org 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
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] A question about RFC7854 stats report

[Jeffrey Haas]

Qing,

On Thu, Oct 04, 2018 at 11:28:30AM -0700, Qing Yang wrote:
> Points well taken... NLRIs will be an improvement in terminology over
> prefixes, too?
> 
> And yes, type 8 as it is worded today, is the reason that I think one
> cannot derive the number of prefixes rejected by inbound policy from type 7
> and 8. So I definitely agree with you that an update to RFC7584 would be
> helpful.

A trivial Internet-Draft, at least once draft-scudder-grow-bmp-registries-change
has gone through.  My suggestion is to gather a list of stats you might want
and kick off the draft.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] A question about RFC7854 stats report

[Qing Yang]

Points well taken... NLRIs will be an improvement in terminology over
prefixes, too?

And yes, type 8 as it is worded today, is the reason that I think one
cannot derive the number of prefixes rejected by inbound policy from type 7
and 8. So I definitely agree with you that an update to RFC7584 would be
helpful.

If I wasn't clear earlier, I think my suggestion was also to define a
(potentially super) set of stat types, that *might *be useful in different
scenarios, and vendors can choose to implement subset based on their
interest and whatever architectural restrictions; but once implemented, the
behavior and meaning would have to be uniform (e.g., there should not be a
deviation of type 8 whether it means number of post-policy or locRib).

Thanks for all the followup and replies!
Qing

On Wed, Oct 3, 2018 at 11:53 PM Tim Evens (tievens) 
wrote:

> Hi Qing,
>
>
>
> It's not really an "update" count, it's NLRI.I currently consider the
> rejected prefixes counter as the number of times NLRI's have been rejected
> by inbound policy, not a count of distinct prefixes rejected as it pertains
> the current RIB.  It's not a count of updates either as a BGP update
> contains multiple NLRI's.. This counter is a way to indicate that some or
> all the NLRI's in a given BGP update were rejected.
>
>
>
> For example:
>
> Single BGP UPDATE has 5 NLRI's, 2 NLRI's are rejected due to policy.
>
>
>
> Prefix and route, IMO, needs to be clarified that it's not just a prefix…
> It's an NLRI.Currently, only types 9 and 10 are AFI/SAFI aware… This
> should mean that all other counts are global to the peer across the address
> families.  For example, a peer with bgp-ls and ipv4 unicast should have
> types 0, 1, 2, 7, 8, and 12 values that include combined NLRI' counts.
>
>
>
> When counting NRLI's we should be using AFI/SAFI aware stats as it's
> misleading and becomes less useful when multiple address families are
> enabled on the peer.
>
>
>
> Type 8 and 10 are labeled as Loc-RIB but many have treated them as
> Post-RIB.  https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-02
> indicates the use of Loc-RIB for "local rib."
>
>
>
> The statistic types are per-peer.  This means that we could get a stat
> report for pre and post policy (e.g. stat type 7) counts/gauges.
>
>
>
> IMO, it would be great to update RFC7854 statistic reporting section to
> clear up the multiple confusions around statistic reporting.
>
>
>
> Thanks,
>
> Tim
>
>
>
> On 10/3/18, 3:03 PM, "GROW on behalf of Qing Yang"  on behalf of qyang=40arista@dmarc.ietf.org> wrote:
>
>
>
> It we deem it to be really useful to have an accurate tracking of number
> of rejected prefixes, which I can imagine, then it is fine that this will
> require the retainment of rejected advertisements; in other words, if it is
> configured to discard, you cannot supply this stats.
>
> Which argues for an additional. My request in my last email, the last
> line, was essentially, if we head towards that (i.e, add a new type to
> denote this, then the original type 0), for backward compatibility,
> properly should be renamed to indicate 'update' as versus 'prefixes', to be
> accurate.
>
>
>
> On Wed, Oct 3, 2018 at 2:02 PM Jeffrey Haas  wrote:
>
> On Tue, Sep 25, 2018 at 01:36:24PM -0700, Qing Yang wrote:
> > Well, I would argue that as an RFC, it should not be tied to a specific
> implementation, particularly if it’s a restriction. For the records, Arista
> implementation has the choice of not discarding such updates.
>
> So, when your implementation is configured to discard updates, how do you
> expect things to behave?
>
> [mix of top and bottom post preserved for context]
>
> -- Jeff
>
> > At a minimum I’d suggest the wording to be changed to ‘updates’ rather
> than prefixes to avoid confusion.
> >
> > > On Sep 25, 2018, at 1:27 PM, Jeffrey Haas  wrote:
> > >
> > >
> > >> On Sep 25, 2018, at 2:53 PM, Qing Yang  40arista@dmarc.ietf.org> wrote:
> > >>
> > >> But the 'rejected prefix due to a policy' really is a function of two
> entity: the incoming updates, and the policy itself. Let us say, you
> receive 10 prefixes from a peer, and the policy is rejecting 5, and you
> show the counter as 5. Later on, you change the policy to accept all,
> without receiving any update, shouldn't the rejected prefix due to policy
> drop to 0 at this point, but then the counter will prevent us from doing
> it, and thus the station would not know from this design?
> > >
> > > If you recall that in many cases in many implementations that rejected
> routes are discarded and no longer in the RIB at all, I suspect being a
> counter makes somewhat more sense to you.
> > >
> > > -- Jeff
> > >
>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] A question about RFC7854 stats report

[Tim Evens (tievens)]

Hi Qing,

Pre-Policy vs Post-Policy stat reports addresses this, but isn't so clear in 
RFC7854.  Compare the Adj-RIB-In gauge for pre-policy to post-policy and we 
have the number of NLRI's (prefixes) that did not make it through the policy.   
While this does indicate the number of prefixes that were "rejected" by policy, 
it does not provide insight into the number times the NLRI's were being 
rejected.  For example, Adj-RIB-In(Pre) minus Ajd-RIB-In(Post) is the gauge 
representing the rejected value…  Unless the policy has changed, this value is 
consistently the same every interval… but in reality, the policy is being 
bombarded by advertisements that are being rejected.  Without a counter for 
this, we can't obtain stats on the advertisements for a given peer.  We need 
both and have both if the implementation implements both pre-policy and 
post-policy stat reports (per-peer header indicates pre vs post).

Thanks,
Tim

  As mentioned in the other thread response, it's not clearly indicated that 
there could be on stat report for pre-policy counts and another for 
post-policy.Problem is that many


On 9/25/18, 11:54 AM, "GROW on behalf of Qing Yang" 
mailto:grow-boun...@ietf.org> on behalf of 
qyang=40arista@dmarc.ietf.org> 
wrote:

But the 'rejected prefix due to a policy' really is a function of two entity: 
the incoming updates, and the policy itself. Let us say, you receive 10 
prefixes from a peer, and the policy is rejecting 5, and you show the counter 
as 5. Later on, you change the policy to accept all, without receiving any 
update, shouldn't the rejected prefix due to policy drop to 0 at this point, 
but then the counter will prevent us from doing it, and thus the station would 
not know from this design?

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow