[Note that I'm not an author here] > On Nov 17, 2025, at 6:29 AM, Gunter van de Velde (Nokia) > <[email protected]> wrote:#3# some gauges seem > duplicates from prior existing > 127 * Primary route: A route to a prefix that is considered the best > 128 route by the BGP decision process [RFC4271] and actively used > for > 129 forwarding traffic to that prefix. > > GV> is this accurate? is it not the BGP route that is selected by BGP for > being > forwarded to its peers? There may be ECMP or uECMP routes actively used > > 131 * Backup route: A backup route is eligible for route selection, > but > 132 it is not selected as the primary route and is also installed in > 133 the Loc-RIB. It is not used until all primary routes become > 134 unreachable. Backup routes are used for fast convergence in the > 135 event of failures. > > GV> here is the concept of "all primary routes" used, indicating more as a > single best route. Is this not contradicting the prior bullet point? > > [MS} - I think we need some clarification here and we can update doc if there > is an agreement. > My understanding is that for a given prefix, there can be only one route > marked is active route. ECMP is applicable for forwarding layer only. When > ECMP is present, the active route can have multiple next-hop (ECMP) installed > in FIB to forward the traffic. From this BMP statistics draft POV, to keep > things generic, I would suggest to define a primary route as “A route that is > marked as active by local BGP protocol". Backup path is all paths that are > "not primary route". When we bring in forwarding concepts, things might get > confusing. > > GV2> i think this is serious enough to explicitly document what is considered > as an “primary route”. If implementors need to implement this, then they need > to exectly understand what this means and what to implement. Otherwise we end > up with statistics measuring different properties.
Note that the authors tweaked the text for backup routes partially in response to a similar comment I made in my review for -13. The base BGP specification doesn't name the route selected for loc-rib, nor talk about routes that are eligible or ineligible for selection by a particular name. Primary and backup are reasonable. This was also flagged as part of the RFC 4271 bis work. This wouldn't be the first time that terminology developed as part of BMP was used for standardizing names for BGP abstractions so we're paying close attention this point. :-) > > 137 3. Statistics Definition > > GV> This title seems rather undescriptive. What about calling this section: > > " > RIB monitoring type statistics > " > > 145 * Type = 18: (64-bit Gauge) Current number of routes in pre-policy > 146 Adj-RIB-In. This gauge is similar to stats type 7 defined in > 147 [RFC7854] and makes it explicitly for the pre-policy Adj-RIB-In. > > GV> It is written that this is similar as stats type 7, but when looking at > the > definitions in section 2 it is exactly the same. pre-existing stats type 7 is > exactly the same as the proposed stats type 18. Do we need type 18? > [MS] As mentioned before, this was done based on explicit comment from Paulo > and others. I have mentioned my other thoughts above about this topic. > > GV2> ack As a general comment on this type of change, the ambiguity in the original definition has lead to interoperability issues between different monitored routers and BMP collectors. Thus, the issue is less that the types are not intended to be the same, it's that vendor 1 and vendor 2 came to different conclusions about the monitored statistics for the same counter. Implementations typically work around bugs in this sort of thing on a per-vendor basis. Forcing updates to the normative text for the monitored element is certainly something that could have been pursued. It mostly just leads to additional unhappiness in data consumers. The one piece of possibly missing procedure is using this new code point to deprecate the prior code points it is replacing. BMP currently lacks normative procedures for such deprecation. > > 149 * Type = 19: (64-bit Gauge) Current number of routes in > per-Address > 150 Family Identifier (AFI)/Subsequent Address Family Identifier > 151 (SAFI) pre-policy Adj-RIB-In. This gauge is similar to stats > type > 152 9 defined in Section 4.8 of [RFC7854] and makes it explicitly > for > 153 the pre-policy Adj-RIB-In. The value is structured as: 2-byte > 154 AFI, 1-byte SAFI, followed by a 64-bit Gauge. > > GV> same observation as the prior item. The newly suggested type 19 is exactly > the same as type 9. Do we need this new gauge? GV> what exactly is the > "value"? > Can the structure of the field be more clarified? how how is the field > encoded? > it seems more as a single dimensional 64 bit gauge. > [MS] Same comment as above. The “value” is the “Value —> Stats Data” > mentioned in the BMP statistics message encoding explained above. > > GV2> see my prior response. Some extra text blob in this document will help > reduce confusion Section 3.1, Statistics Format, was added in -15. RFC 7854 was under-specified for this type of format so the clarification is helpful. However, since this is effectively defining normative text that is likely to be used for future documents, I'd encourage the IESG review this section pedantically to make sure it's something they'd be happy to be cited in future documents for definition of stats of this type. Note to the authors: I'd also encourage that you add in text that says that AFI/SAFI statistics can be omitted when not relevant for a given AFI/SAFI. This is to set the expectation that there is no requirement that all AFI/SAFI be present in a stat just because those AFI/SAFI are negotiated for the session. > GV2> When vendors claim support for a proposed standard, they’re expected to > implement and follow all formal procedures in the RFC — meaning they must > comply with every MUST / MUST NOT requirement. The SHOULD / MAY items matter > less for “full support.” > My point was whether this RFC implicitly assumes a minimum set of AFI/SAFI a > vendor must implement to claim compliance. Are some AFI/SAFI less essential > than others? > Maybe the cleanest solution is to state explicitly, as you already hinted, > that compliance applies only to the AFI/SAFI that the BGP peer actually > supports. See my comment above which is relevant. -- Jeff _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
