Ketan,
> On Dec 2, 2025, at 6:25 AM, Ketan Talaulikar <[email protected]> wrote: > > 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. > > KT> Per my reading of RFC4271 (and it is not literal but the essence that I > take from section 3.1), if we are counting "routes" we are counting the > destination/prefix entries and if we are counting paths we are counting the > path attributes received from various peers for those destinations/prefixes. > I note that we didn't have additional paths or multipaths in RFC4271 - there > is one best path. I don't find the mention of "an instance of a route" or > something like that though and please point me to something like that if I've > missed it. (I could swear I've spelled this out in detail before, but yet again...) It's all the way at the top in 1.1. Routes pair destinations with path attributes. For 4271, we only can send a single instance of a destination (it's the key). So, the property I keep coming back to complain about is discussing "route" in the sense that a destination is used in, or NLRI. RFC 7911 is what introduces add-paths. Here, we don't cleanly establish the definition of a path, but we define it by functionality. Multipath completely remains undefined procedurally. And that's sort of perverse considering we are deep in a different thread discussing how link-bandwidth is used to load balance for multipath procedures. :-) There were a few drafts previously that tried to formalize things, but they never progressed. Addressing that strange gap may be appropriate for 4271-bis. The reason I continue to be pedantic in my responses here is that grow has already accidentally created long-standing BGP terminology via BMP. The current 5 logical RIB view isn't a 4271 thing. :-) So, we need to be careful to not let casual use here become another accidental "defined by use" document. For clarity: Destination: The destination in the appropriate address family combination (afi/safi) that a key in a RIB. (This is where we'll likely revisit things for the RIB-key conversation for 4271-bis) NLRI: In practice, the encoding of a destination and potentially other destination-specific attributes in a BGP UPDATE PDU, some of which may be a key in the RIB, some of which are not. The original meaning of "network layer" reachability has degraded over time where we no longer are talking strictly about OSI Layer 3 in the things we carry in BGP. Route: A pairing of a destination and a set of path attributes. Path: An instance of a route received from or sent to a BGP speaker. And while there's more than a little room to argue whether we should be having this discussion in this relatively straight forward bit of BMP, our underlying discussion is tied to the unresolved points of what exactly a given RIB stat is intending to represent in the protocol or the implementation. Unfortunately, clarity for the stats may force us to put some of these definitions in the document if it's otherwise unclear. [The latter portion fo the response covering "we need consistency" is I think understood. However, I think the authors need some closure on terminology to do that.] > > > 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. > > KT> The section titles can be updated. Is "discontinuity" really a thing to > worry about here? My main worry on discontinuous contents is mostly based on seeing what sort of bugs more than one vendor ends up with in the field when we're not careful about such things. So, it's not a primary consideration, but it's absolutely a secondary one. And I don't think there's a good answer if it's agreed to do the split. > > 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. > > KT> I agree. Can we pick such a style in this document and follow it in other > documents? If it were solely my choice, I'd recommend not keeping the aggregate stats as afi/safi 0/0. This is for the reasons posted above. We're only saving a few octets in the PDU to separately encode it. Let's see what other wisdom the WG has based on implementation for the protocol and the consumption of it has to offer. -- Jeff _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
