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 protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/grow
