>>>> i propose that these two stat types are removed from >>>> draft-ietf-grow-bmp-bgp-rib-stats mainly for consistency to >>>> draft-ietf-grow-bmp-path-marking-tlv and to avoid dependencies among the >>>> two documents [MS] I too have suggested that in past. I feel discussions are not converging. I am ok to remove this.
Thanks Mukul From: Paolo Lucente <[email protected]> Date: Saturday, November 29, 2025 at 12:57 PM To: Ketan Talaulikar <[email protected]>, The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [GROW] Re: Ketan Talaulikar's Discuss on draft-ietf-grow-bmp-bgp-rib-stats-16: (with DISCUSS) Hi Ketan, Med, Authors, Following up on the two open discussion points: discuss 1) The only two defined stats that touch the concept of "primary" and "backup" are types 24 and 25; in draft-ietf-grow-bmp-path-marking-tlv path statuses are being defined -- and there is more to it than just primary and backup. Evolving from my previous email, i propose that these two stat types are removed from draft-ietf-grow-bmp-bgp-rib-stats mainly for consistency to draft-ietf-grow-bmp-path-marking-tlv and to avoid dependencies among the two documents; instead we can define stats for all defined path status in the path marking document; this, i guess, would also close this discussion point; discuss 2) On the specific guidance point for future documents, please see https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/grow/6pqYmYyy2V7eVuNHkERiLd5qnrM/__;!!NpxR!jgm75lbeYnBHk5v45dt23ZCzxjHufZIxAs58VQNxugAThMQIUaTHIHZkoF6L-N2G-GmojqZZI9wXgLs$ . Away from the greasy technical details, in short, the BMPv4 document would be a more suitable place than this document where to provide guidance and straighten a few aspects out. Paolo On 25/11/25 21:52, Paolo Lucente wrote: > > Hi Ketan, > > On the two discussion points: > > discuss 1) Complementing answers from Jeff: while it's not the role of > this document or draft-ietf-grow-bmp-path-marking-tlv to make any > definition (ie. route vs path, primary vs backup etc.), we have two > documents that speak about things with a certain degree of affinity: > maybe we can avoid both to use similar terminology independently; we > could explain the terminology in one document > (draft-ietf-grow-bmp-path-marking-tlv would be the place to do that, > IMO) and place a reference in the other and let it re-use the terminology. > > The immediate con that comes to mind is that we introduce a dependency > among a document already in IESG court over one that has still a bit of > mileage to do in the WG (although i think we are almost done with it). > > A further idea could be to lock the two documents up by adding a "path > status" field in relevant stats types defined in > draft-ietf-grow-bmp-bgp-rib-stats referencing the path code points > defined in draft-ietf-grow-bmp-path-marking-tlv; the main con i see is > that - guess we would agree on a static format for stats (see next > point) - it would break auto-parsing of stats in a BMP collector. > > discuss 2) There is a couple of points to unpack: > > BMP messages include a per-peer header where there are peer flags. > Turning and twisting some of these, one can say whether content of the > BMP message belongs to Adj-Rib-In pre/post policy, Adj-Rib-Out pre/post > policy, Loc-Rib. Of course one can't mix-and-match stats for different > vantage points as part of the same Stats message; one Stats message per > covered vantage point is needed -- sub-optimal but this is how BMP > operates today and, especially for periodic messages, maybe good enough. > > On Global vs per-AFI/SAFI messages: where possible i like to favor a > static format, for example every message would be per-AFI/SAFI where if > AFI/SAFI are both set to zero it means it's Global. The pro is that we > would make stats auto-parseable by a collector; the con is that we would > potentially waste 3 bytes per stat TLV -- something we could further > sophisticate, saving auto-parsing, by introducing an innocent bit saying > whether AFI/SAFI will follow or not before the gauge / value. This would > avoid your duplication point, Ketan, and you are right that currently > there is no guidance in this sense -- hence myself throwing some ideas. > > Paolo > > > On 25/11/25 09:27, Ketan Talaulikar via Datatracker wrote: >> Ketan Talaulikar has entered the following ballot position for >> draft-ietf-grow-bmp-bgp-rib-stats-16: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to >> https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NpxR!jgm75lbeYnBHk5v45dt23ZCzxjHufZIxAs58VQNxugAThMQIUaTHIHZkoF6L-N2G-GmojqZZqk7jsQ8$ >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-bgp-rib-stats/__;!!NpxR!jgm75lbeYnBHk5v45dt23ZCzxjHufZIxAs58VQNxugAThMQIUaTHIHZkoF6L-N2G-GmojqZZ3suX7LA$ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Thanks to the authors and the WG for this document. >> >> Note: this ballot has been updated for v16 of the document. The >> previous number >> of points is retained. Points that have been addressed are deleted. >> >> Please find below certain points that I would like to discuss. >> >> <discuss-1> Semantics of routes, paths, primary, and backup. >> >> Section 2 of this document says: >> Primary route: A route to a prefix that is considered the best route >> by the BGP >> decision process [RFC4271] and actively used for forwarding traffic to >> that >> prefix. Backup route: A backup route is eligible for route selection, >> but it is >> not selected as the primary route and is also installed in the >> Loc-RIB. It is >> not used until all primary routes become unreachable. Backup routes >> are used >> for fast convergence in the event of failures. >> >> Consider an BGP route for destination prefix x/y is a multipath: >> x/y via BGP NH1 (path1) (best) >> via BGP NH2 (path2) (multipath - say ECMP) >> via BGP NH3 (path3) (backup) >> via BGP NH4 (path4) (valid but not best/multipath/backup) >> via BGP NH5 (path5) (invalid - for whatsover reason) >> >> This is a single route. The best/multipath/backup/valid/invalid/etc are >> qualifiers of its paths. Except for two stats that refer to paths >> (stale and >> suppressed), everything is referring to routes. I would like to >> discuss the >> semantics of route vs path. It seems to me like some of the stats are >> for paths >> and not routes. >> >> In general, I think the use of the terms primary/backup which are >> related to >> forwarding plane aspects can be confusing. Instead, perhaps using >> terms that >> are more suitable for BGP Loc-RIB would be better? I've suggested some >> of them >> above for consideration. Also refer to >> draft-ietf-grow-bmp-path-marking-tlv - >> the terms of stats should be aligned across the BMP documents? >> >> Furthermore, there is a wrong assumption that backup paths are only >> activated >> when all primary paths are down. This is very much implementation >> dependent. >> Some implementations have a 1:1 provisioning of primary/backup - where >> the >> backup would get used when its specific primary goes down - this draws >> on the >> FRR notion in the forwarding planes. Refer to the definition in >> draft-ietf-grow-bmp-path-marking-tlv >> >> These clarifications have implications on several of the stats as they >> are >> defined currently. >> >> <discuss-2> Section 3 has the following text and Section 4 introduces >> a table >> that brings up an interesting aspect. >> >> "This section defines different statistics type for Adj-RIB-In and >> Adj-RIB-Out >> monitoring type. Some of these statistics are also applicable to >> Loc-RIB; refer >> to Section 4 for more details." >> >> For types 24 through 28, they are applicable for both Adj-RIB-In and >> Loc-RIB. >> How does one know what is being reported? Can this be clarified? Seems >> like >> this is the first document introducing such overloaded types but I >> don't find >> the reason why this is being done. There is also a sort of duplication >> for same >> stat being both global as well as per afi/safi - is there any guidance on >> whether only one of them needs to be supported (this way avoiding the >> race >> conditions and discrepancies in their totaling)? >> >> It is important to clarify these aspects if this is going to set a >> precedent/guidance for other similar stats in BMP in future documents? >> >> >> >> >> >> _______________________________________________ >> GROW mailing list -- [email protected] >> To unsubscribe send an email to [email protected] _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
