Ketan, As usual, we're tripping upon the definitions we all grew up with in routing for some of these things.
> On Nov 25, 2025, at 7:41 AM, Ketan Talaulikar <[email protected]> wrote: > > Let us step back and look at the following example that I've provided in my > ballot (with 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 whatsoever reason) > > Lets focus on the LocRIB view for simplicity since the stats type 24 and 25 > apply to it. To me, x/y is a route - i.e., above is a single route. However, > it has multiple paths associated with it, each with its characteristics. The RFC 4271 definition of a route is pasted here: Route A unit of information that pairs a set of destinations with the attributes of a path to those destinations. The set of destinations are systems whose IP addresses are contained in one IP address prefix carried in the Network Layer Reachability Information (NLRI) field of an UPDATE message. The path is the information reported in the path attributes field of the same UPDATE message. So, in terms of 4271, your x/y is a destination. 4271 also uses NLRI: Network Layer Reachability Information: This variable length field contains a list of IP address prefixes.[...] So, destinations are also IP prefixes from a 4271 perspective. A "path" has no RFC 4271 meaning. Colloquially, a "path" is an route from a set of routes. RFC 7911 reinforces that somewhat in terms of terminology but also by procedure. In terms of impacts on statistics we care about for BGP, the question becomes whether the statistic is tied to a given destination, a destination that is learned from a peer/installed in loc rib/sent to a peer, or additional instances of the same (add-paths). Note: I continue to object to the semantic in the draft that loc-rib contains multiple routes. 4271 picks one. Implementations of BGP may install multiple routes (including multiple paths for the same destination) into its ROUTING TABLE, but not into LocRib. The fact that some implementations effectively implement their LocRib view in a routing table is what is causing some of this semantic conflation. > > So, my question to the authors and the WG (especially the operators) is what > are the statistics of interest for their monitoring. > > a) If counting routes, then x/y will get accounted as 1 against both primary > and backup because it has both those paths. > b) if counting paths, then x/y will count towards 2 primary paths (path1 and > path2) and will count 1 towards backup paths (path3). > > If the WG is able to agree and converge on the semantics, then we can work on > the text for the terms to be used and their definitions as a follow-on. Note we still quibble over the terminology. I agree that the semantic of the counter can be clear and we can nudge the terminology for it. WIth specific regard to the two stats under discussion: "Type = 24: (64-bit Gauge) Current Number of routes in per-AFI/SAFI selected as primary route. The value is structured as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge." The semantics are unclear because of the imprecise definition of a Primary route vs. LocRib entry. It'd be helpful if the authors clarify what is the distinction between primary and LocRib. "Type = 25: (64-bit Gauge) Current Number of routes in per-AFI/SAFI selected as a backup route. The value is structured as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge." Similarly, the distinction of backups- which probably is clarified by defining primary. :-) -- Jeff _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
