Qing Yang wrote on 25/09/2018 19:53:
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 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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
