Hi Jeff, Please check inline below for responses with KT2.
On Tue, Dec 2, 2025 at 11:42 PM Jeffrey Haas <[email protected]> wrote: > 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...) > KT2> My apologies for missing that but your summary below is very helpful. > > 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. > KT2> Agree - this is my (and perhaps the general?) understanding as well. There is one wrinkle about Loc-RIB (and the RIB) and how the terms Route and Path are correlated there (factoring multipath and its variants like best/backup) > > 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. > KT2> I agree. > > [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. > KT2> There are multiple ways to go about this and I will leave it to the WG. Just looking for clarity - in this document or the other one - before we send this towards publication. Thanks, Ketan > > -- Jeff > >
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
