On Tue, Sep 25, 2018 at 01:36:24PM -0700, Qing Yang wrote: > 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.
So, when your implementation is configured to discard updates, how do you expect things to behave? [mix of top and bottom post preserved for context] -- Jeff > 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
