Ketan, > On Dec 1, 2025, at 11:37 AM, Ketan Talaulikar <[email protected]> wrote: > > 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.
If so, and if H3C has shipped the code as they note in §9.2, let's make sure the IANA considerations reserves these fields. > > 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. ... and this would be problematic vs. 4271. Can we stop using route in that sense? If the sense is an instance of a route, call it a path and make sure path is cleanly defined. > > 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. The grid in §4 covers scoping appropriately. Is your desire here that the descriptive clauses also have the scoping added to them? The section header covers some of this implicitly. At least part of the criticism is that if we want the scope to be clear, it has to be in : Section 3 and potentially be redundant vs. the section header. Section 4 in the grid, which is a good short cut. Section 8 for IANA, which will probably be used as inputs for things like manageability interfaces. > > 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? The headache is really "what do you do when a given statistic applies to more than one view?" 30,31 for example apply to rib-in as well as loc-rib. Were you arguing to decompose section 3 into another block of "rib-in plus loc-rib?" For this document, that would address the clarity in the section, but at the cost of adding discontinuities in the listing of the assignments in section 3. > > 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 Paolo's comment, picking a designated afi 0/safi 0 as "global" probably would have been nice, but there's now running code covering these things. Covering your broader point, there's always been a bit of a disconnect in management-land as to what to do about aggregate statistics. The total "global" number is the sum of the per-afi-safi - when do we have global vs. not? Examples of where such aggregates cause trouble are "RIB copies/route leaking". This can lead implementations to say "I received X,Y,Z counts of those AFI/SAFI" but have a number of route instances that misalign to X+Y+Z. The answer is likely "pick a style and let's try to be consistent with it henceforth". At the very least we made statistics in BMP cheap so we can learn from experience. -- Jeff _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
