Hi, I am one of the authors of the path-marking draft.
Initially, the draft's primary goal was to define the TLV independently of the "markings" within. We then decided to have some markings because without them implementations would have a hard time figuring out what to do. This will increase the scope of that document a bit, if the chairs/AD are in sync with that, we can go ahead. Camilo On 1/12/25, 11:37, "Ketan Talaulikar" <[email protected] <mailto:[email protected]>> wrote: 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] <mailto:[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] <mailto:[email protected]>> > *Date: *Saturday, November 29, 2025 at 12:57 PM > *To: *Ketan Talaulikar <[email protected] > <mailto:[email protected]>>, The IESG <[email protected] > <mailto:[email protected]>> > *Cc: *[email protected] > <mailto:[email protected]> < > [email protected] > <mailto:[email protected]>>, [email protected] > <mailto:[email protected]> < > [email protected] <mailto:[email protected]>>, [email protected] > <mailto:[email protected]> <[email protected] <mailto:[email protected]>>, > [email protected] > <mailto:[email protected]> < > [email protected] > <mailto:[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$ > > <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 _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
