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 protected]> wrote: > > >> On Sep 25, 2018, at 2:53 PM, Qing Yang <[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? > > 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 >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
