Hi All, I have been following the discussion regarding my DISCUSS points on draft-ietf-grow-bmp-bgp-rib-stats-16.
Regarding Discuss-1 (Route vs. Path Semantics) I agree with the suggestion to move types 24 and 25 (Primary/Backup route counts) from this document to draft-ietf-grow-bmp-path-marking-tlv. This will allow the Working Group to fully deliberate the semantics of "route" vs. "path," especially concerning Add-Paths and multipath aspects. Assuming this is the chosen path: 1. Do Types 26, 27, and 28, which also refer to a path, also need to be moved to the path-marking document for consistency? 2. For clarity across all BMP stats, does the document confirm that "route" is functionally equivalent to "prefix/destination"? My interpretation of existing stats suggests this is the case. Addressing the removal of 24/25 (and potentially 26-28) would resolve my discuss-1 ballot point. Regarding Discuss-2 (Statistic Scope and Clarity) Regarding discuss-2, I agree that establishing general guidance for BMP evolution is a broader WG issue. Focusing solely on this document, the following points need clarification: a) Statistic View Clarity: Do all statistic descriptions accurately indicate the view (Adj-RIB-In, Adj-RIB-Out, Loc-RIB)? The document is sometimes ambiguous. Specifically, Types 22, 23, and 26 through 34 do not explicitly state Adj-RIB-In, and Types 38, 39, and 40 do not explicitly state Adj-RIB-Out. The descriptions should reflect the scope since the Section 4 table is not being registered with IANA. b) Loc-RIB Scoping: Types 26, 27, 28, 31, and 32 are applicable to the Loc-RIB. Should new, dedicated stat types be defined for the Loc-RIB view to maintain consistency with previous RFC conventions, or should the existing type descriptions be updated to capture the Loc-RIB view as well explicitly? c) Global vs. Per-AFI/SAFI Types: Are both global and per-AFI/SAFI types defined for all applicable statistics? Why are some types (e.g., 26, 27, 28) defined as per-AFI/SAFI only, without an accompanying global type? Addressing these specific points and making necessary updates would resolve my discuss-2 ballot point, which, in my view, would make the document ready for publication. Thanks, Ketan On Sun, Nov 30, 2025 at 12:09 AM Srivastava, Mukul <[email protected]> wrote: > >>>> 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]
