Points well taken... NLRIs will be an improvement in terminology over prefixes, too?
And yes, type 8 as it is worded today, is the reason that I think one cannot derive the number of prefixes rejected by inbound policy from type 7 and 8. So I definitely agree with you that an update to RFC7584 would be helpful. If I wasn't clear earlier, I think my suggestion was also to define a (potentially super) set of stat types, that *might *be useful in different scenarios, and vendors can choose to implement subset based on their interest and whatever architectural restrictions; but once implemented, the behavior and meaning would have to be uniform (e.g., there should not be a deviation of type 8 whether it means number of post-policy or locRib). Thanks for all the followup and replies! Qing On Wed, Oct 3, 2018 at 11:53 PM Tim Evens (tievens) <[email protected]> wrote: > Hi Qing, > > > > It's not really an "update" count, it's NLRI. I currently consider the > rejected prefixes counter as the number of times NLRI's have been rejected > by inbound policy, not a count of distinct prefixes rejected as it pertains > the current RIB. It's not a count of updates either as a BGP update > contains multiple NLRI's.. This counter is a way to indicate that some or > all the NLRI's in a given BGP update were rejected. > > > > For example: > > Single BGP UPDATE has 5 NLRI's, 2 NLRI's are rejected due to policy. > > > > Prefix and route, IMO, needs to be clarified that it's not just a prefix… > It's an NLRI. Currently, only types 9 and 10 are AFI/SAFI aware… This > should mean that all other counts are global to the peer across the address > families. For example, a peer with bgp-ls and ipv4 unicast should have > types 0, 1, 2, 7, 8, and 12 values that include combined NLRI' counts. > > > > When counting NRLI's we should be using AFI/SAFI aware stats as it's > misleading and becomes less useful when multiple address families are > enabled on the peer. > > > > Type 8 and 10 are labeled as Loc-RIB but many have treated them as > Post-RIB. https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-02 > indicates the use of Loc-RIB for "local rib." > > > > The statistic types are per-peer. This means that we could get a stat > report for pre and post policy (e.g. stat type 7) counts/gauges. > > > > IMO, it would be great to update RFC7854 statistic reporting section to > clear up the multiple confusions around statistic reporting. > > > > Thanks, > > Tim > > > > On 10/3/18, 3:03 PM, "GROW on behalf of Qing Yang" <[email protected] > on behalf of [email protected]> wrote: > > > > 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
