Thank you very much for replying! It will be good if 4.8. Stats Reports of RFC7854 clarifies it. Because this section does not explicitly say that the AFI/SAFI aware stats TLV can be included multiple times in one BMP Stats Reports message.
Thanks, Shunwan From: Tim Evens (tievens) [mailto:[email protected]] Sent: Tuesday, October 09, 2018 12:35 AM To: Zhuangshunwan <[email protected]>; Qing Yang <[email protected]>; Jeffrey Haas <[email protected]> Cc: [email protected] Subject: Re: [GROW] A question about RFC7854 stats report I don't see that RFC7854 specifically identifies that stat types cannot repeat. IMO, the RFC text suggests singular value, not an array of AFI/SAFI/VALUE entries. Thanks, Tim On 10/8/18, 4:22 AM, "Zhuangshunwan" <[email protected]<mailto:[email protected]>> wrote: Hi forks, Regarding AFI/SAFI aware stats, e.g. Type 9 defined in RFC7854： : o Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In. The : value is structured as: 2-byte Address Family Identifier (AFI), : 1-byte Subsequent Address Family Identifier (SAFI), followed by a : 64-bit Gauge. Question: When counting NLRIs for multiple address families being enabled on the same peer, we have 2 possible choices: 1) In a BMP Stats Reports message, carrying only one Type-9-TLV, and the Value field contains multiple (AFI, SAFI, 64-bit Gauge) triples; 2) In a BMP Stats Reports message, carrying multiple Type-9-TLVs, and each Type-9-TLV carrying one (AFI, SAFI, 64-bit Gauge) triplet. Which one should we follow? Thanks, Shunwan From: GROW [mailto:[email protected]] On Behalf Of Tim Evens (tievens) Sent: Thursday, October 04, 2018 2:54 PM To: Qing Yang <[email protected]<mailto:[email protected]>>; Jeffrey Haas <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [GROW] A question about RFC7854 stats report 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]<mailto:[email protected]> on behalf of [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>> wrote: > > > > > >> On Sep 25, 2018, at 2:53 PM, Qing Yang > >> <[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? > > > > 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
