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. On Tue, Sep 25, 2018 at 11:42 AM Nick Hilliard <[email protected]> wrote: > Qing Yang wrote on 25/09/2018 18:34: > > 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. > > 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 >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
