It we deem it to be really useful to have an accurate tracking of number of rejected prefixes, which I can imagine, then it is fine that this will require the retainment of rejected advertisements; in other words, if it is configured to discard, you cannot supply this stats. Which argues for an additional. My request in my last email, the last line, was essentially, if we head towards that (i.e, add a new type to denote this, then the original type 0), for backward compatibility, properly should be renamed to indicate 'update' as versus 'prefixes', to be accurate..
On Wed, Oct 3, 2018 at 2:02 PM Jeffrey Haas <[email protected]> wrote: > 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 <qyang= > [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
