Subject: [GROW] A question about RFC7854 stats report

From: Qing Yang <[email-masked]>
Date: Tue, 25 Sep 2018 10:34:21 -0700

RFC7854 specifies the following as a counter in the stats report:

   o  Stat Type = 0: (32-bit *Counter*) Number of prefixes rejected by
      inbound policy.

Does anyone know the reason why this is a counter as versus a gauge?

Notice for all other types, when the 'number of prefixes/routes' is
involved (type 7, 8, 9, 10), they are all defined as gauge, which can
increment or decrement, and makes sense to me, as this indicates a current
state. It is a counter when number of updates or withdrawal is involved,
which again makes sense, because that can only increment.

If this is truly by design, can someone enlighten how should we increment
it on switch/router, how should the station interpret it? From my
perspective, not being able to decrement this would render it not as useful
in many scenarios.

Thanks,
Qing @ Arista

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 25 Sep 2018 19:42:24 +0100

Qing Yang wrote on 25/09/2018 18:34:
> increment or decrement, and makes sense to me, as this indicates a 
> current state. It is a counter when number of updates or withdrawal is 
> involved, which again makes sense, because that can only increment.

These are two different things.  Stat type = 0 is the number of negative 
policy matches for incoming prefixes.  You're counting the number of 
rejections so it's a counter.

On the other hand, stat types 7, 8, 9 and 10 all measure the number of 
prefixes in various RIB types.  This needs to be a gauge because it 
could increase or decrease.

Nick

---

From: Qing Yang <[email-masked]>
Date: Tue, 25 Sep 2018 11:53:43 -0700

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?

I probably can see one case that might benefit from the counter design. In
the above case, if a policy change results the other 5 to be denied, maybe
one should increment it (but I'm still not sure you can differentiate the
case that in this case, 5 new denied, but 5 previously denied gets
accepted; versus, all 10 denied).

So basically my argument is, as the wording suggests, this 'Number of
prefixes rejected by inbound policy' can increment or decrement, with the
change of policy.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 25 Sep 2018 16:27:24 -0400

> 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: Tue, 25 Sep 2018 13:36:24 -0700

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. 

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

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 25 Sep 2018 21:45:33 +0100

Qing Yang wrote on 25/09/2018 19:53:
> entity: the incoming *updates*, and the policy itself. Let us say, you 
> 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 were measuring ingress packets on an interface with an 
access-lit, how would you handle it?  You'd definitely have a counter on 
the interface, and possibly a second hardware counter on the ACL.

The interface quantity would definitely be a counter.  You could make a 
passable argument that the ACL counter could be implemented as a gauge 
which would normally increase monotonically, except where it was 
reconfigured when you could make the argument that the gauge could be 
reset to zero by default.  Although honestly, I'd prefer an explicit 
"clear counter" command in that situation.  The BMP situation is largely 
equivalent to this.

Nick