Subject: Re: [GROW] A question about RFC7854 stats report

From: Jeffrey Haas <[email-masked]>
Date: Wed, 3 Oct 2018 17:01:59 -0400

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 <[email-masked]> wrote:
> > 
> > 
> >> On Sep 25, 2018, at 2:53 PM, Qing Yang <qyang=[email-masked]> 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
> >

---

From: Qing Yang <[email-masked]>
Date: Wed, 3 Oct 2018 15:02:29 -0700

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 <[email-masked]> 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.
>
> > >> 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
> > >
>

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Thu, 4 Oct 2018 06:53:30 +0000

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" <[email-masked]<mailto:[email-masked]> on behalf of qyang=[email-masked]<mailto:qyang=[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

-- Jeff

> > On Sep 25, 2018, at 1:27 PM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
> >
> >
> >> On Sep 25, 2018, at 2:53 PM, Qing Yang <qyang=[email-masked]<mailto:[email-masked]>> wrote:
> >>

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Thu, 4 Oct 2018 07:15:30 +0000

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" <[email-masked]<mailto:[email-masked]> on behalf of qyang=[email-masked]<mailto:qyang=[email-masked]>> wrote:

---

From: Qing Yang <[email-masked]>
Date: Thu, 4 Oct 2018 11:28:30 -0700

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) <[email-masked]>
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:
>
> 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" <[email-masked]
> on behalf of qyang=[email-masked]> 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
> 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.
>
>
>

---

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

Qing,

> and 8. So I definitely agree with you that an update to RFC7584 would be

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

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Thu, 4 Oct 2018 22:48:15 +0000

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" <[email-masked]> wrote:

    Qing,

    
    -- Jeff

---

From: Zhuangshunwan <[email-masked]>
Date: Mon, 8 Oct 2018 11:11:54 +0000

Hi forks,

Regarding AFI/SAFI aware stats, e.g. Type 9 defined in RFC7854：
: o  Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In.  The
:    value is structured as: 2-byte Address Family Identifier (AFI),
:    1-byte Subsequent Address Family Identifier (SAFI), followed by a
:    64-bit Gauge.

Question:
When counting NLRIs for multiple address families being enabled on the same peer, we have 2 possible choices:
1) In a BMP Stats Reports message, carrying only one Type-9-TLV, and the Value field contains multiple (AFI, SAFI, 64-bit Gauge) triples;
2) In a BMP Stats Reports message, carrying multiple Type-9-TLVs, and each Type-9-TLV carrying one (AFI, SAFI, 64-bit Gauge) triplet.

Which one should we follow?

Thanks,
Shunwan

From: GROW [mailto:[email-masked]] On Behalf Of Tim Evens (tievens)
Sent: Thursday, October 04, 2018 2:54 PM
To: Qing Yang <qyang=[email-masked]>; Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: [GROW] A question about RFC7854 stats report

Hi Qing,

For example:

Thanks,
Tim

-- Jeff

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Mon, 8 Oct 2018 16:34:39 +0000

I don't see that RFC7854 specifically identifies that stat types cannot repeat. IMO, the RFC text suggests singular value, not an array of AFI/SAFI/VALUE entries.

Thanks,
Tim

On 10/8/18, 4:22 AM, "Zhuangshunwan" <[email-masked]<mailto:[email-masked]>> wrote:

Hi forks,

Question:

Thanks,
Shunwan

Hi Qing,

For example:

Thanks,
Tim

-- Jeff

---

From: "Ayala, Alejandro (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 9 Oct 2018 13:06:05 +0000

That is my understanding, singular values using multiple stat type 9 TLVs.
Alex

From: GROW <[email-masked]> On Behalf Of Tim Evens (tievens)
Sent: Monday, October 8, 2018 12:35 PM
To: Zhuangshunwan <[email-masked]>; Qing Yang <qyang=[email-masked]>; Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: [GROW] A question about RFC7854 stats report

Thanks,
Tim

Hi forks,

Question:

Thanks,
Shunwan

From: GROW [mailto:[email-masked]] On Behalf Of Tim Evens (tievens)
Sent: Thursday, October 04, 2018 2:54 PM
To: Qing Yang <qyang=[email-masked]<mailto:qyang=[email-masked]>>; Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [GROW] A question about RFC7854 stats report

Hi Qing,

For example:

Thanks,
Tim

-- Jeff

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 11 Oct 2018 18:03:28 +0000

Thank you very much for replying! It will be good if 4.8.  Stats Reports of RFC7854 clarifies it. Because this section does not explicitly say that the AFI/SAFI aware stats TLV can be included multiple times in one BMP Stats Reports message.

Thanks,
Shunwan

From: Tim Evens (tievens) [mailto:[email-masked]]
Sent: Tuesday, October 09, 2018 12:35 AM
To: Zhuangshunwan <[email-masked]>; Qing Yang <qyang=[email-masked]>; Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: [GROW] A question about RFC7854 stats report

Thanks,
Tim

Hi forks,

Question:

Thanks,
Shunwan

Hi Qing,

For example:

Thanks,
Tim

-- Jeff