Hi Ketan, Pls see inline with “Changwang>” tag.
Thanks, Changwang 发件人: Ketan Talaulikar <[email protected]> 发送时间: 2025年11月25日 20:41 收件人: linchangwang (RD) <[email protected]>; Srivastava, Mukul <[email protected]> 抄送: The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] 主题: Re: [GROW] Ketan Talaulikar's Discuss on draft-ietf-grow-bmp-bgp-rib-stats-16: (with DISCUSS) Hi Changwang/Mukul/co-authors, Thanks for posting the updated version 16. It addresses all of my comments and one of the discussion points. There are two discussion points that remain open. Let us focus on the first one. The updated definitions of the terms are not very helpful and seem more confusing to me. 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. 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). Changwang> I believe both approaches are necessary. This document involves statistical counting based on method b). In practice, whenever a prefix has multiple paths, other counting methods also face terminology definition issues. Let me elaborate on your previous example as follows: Received two multipath routes for prefix (x/y) from peer-A1, Received one prefix (x/y) each from peer-A2, peer-A3, and peer-A4, Sent three multipath routes to peer-B. +------------------------------------+ | | Peer-A1(add-path，2) | Adj-RIB-In <----------------------------Peer-A2, Peer-A3, Peer-A4 | | | | x/y via BGP NH1 (path-A1-1)(best) | | via BGP NH2 (path-A1-2)(multipath - say ecmp) | | via BGP NH3 (path-A2)(backup) | | via BGP NH4 (path-A3)(valid but not best/multipath/backup) | | via BGP NH5 (path-A4)(invalid - for whatsoever reason) | \/ | RIB<-----------------Loc-RIB | | | x/y via BGP NH1 (path-A1-1)(best) | | via BGP NH2 (path-A1-2)(multipath - say ecmp) | | via BGP NH3 (path-A2)(backup) | \/ | | Adj-RIB-Out ---------------------------->Peer-B(add-path) | | | x/y via BGP NH1 (path-A1-1)(best) | via BGP NH2 (path-A1-2)(multipath - say ecmp) | via BGP NH3 (path-A2)(backup) | | +-----------------------------------+ Regarding the example above, for existing stats types such as RFC8671 Type 14 (Number of routes in pre-policy Adj-RIB-Out), the following two ambiguities exist: 1. If we choose option a), its value should be 1, indicating that 1 Route should be sent to Peer-B before policy application. Subsequently, if we are interested in the 3 paths, we may need to create a stats type for paths (Number of paths in pre-policy Adj-RIB-Out). 1. If we choose option b), its value should be 3, indicating that 3 Paths should be sent to Peer-B before policy application. In this case, the Adj-RIB-Out should contain 3 Paths. If we are interested in the number of prefixes being sent, we may later need to create a stat for prefixes (Number of prefixes in pre-policy Adj-RIB-Out). In my opinion, the "Number of routes" in RFC7854, RFC8671, and RFC9069 refers to a set of prefixes containing different paths, where each route represents one path. 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. The point that I am trying to make is that the definition of terms and the stats type are clear and cover the scenario of multiple paths. Thanks, Ketan On Tue, Nov 25, 2025 at 5:58 PM Ketan Talaulikar via Datatracker <[email protected]<mailto:[email protected]>> wrote: Ketan Talaulikar has entered the following ballot position for draft-ietf-grow-bmp-bgp-rib-stats-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-bgp-rib-stats/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to the authors and the WG for this document. Note: this ballot has been updated for v16 of the document. The previous number of points is retained. Points that have been addressed are deleted. Please find below certain points that I would like to discuss. <discuss-1> Semantics of routes, paths, primary, and backup. Section 2 of this document says: Primary route: A route to a prefix that is considered the best route by the BGP decision process [RFC4271] and actively used for forwarding traffic to that prefix. Backup route: A backup route is eligible for route selection, but it is not selected as the primary route and is also installed in the Loc-RIB. It is not used until all primary routes become unreachable. Backup routes are used for fast convergence in the event of failures. Consider an BGP route for destination prefix x/y is a 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 whatsover reason) This is a single route. The best/multipath/backup/valid/invalid/etc are qualifiers of its paths. Except for two stats that refer to paths (stale and suppressed), everything is referring to routes. I would like to discuss the semantics of route vs path. It seems to me like some of the stats are for paths and not routes. In general, I think the use of the terms primary/backup which are related to forwarding plane aspects can be confusing. Instead, perhaps using terms that are more suitable for BGP Loc-RIB would be better? I've suggested some of them above for consideration. Also refer to draft-ietf-grow-bmp-path-marking-tlv - the terms of stats should be aligned across the BMP documents? Furthermore, there is a wrong assumption that backup paths are only activated when all primary paths are down. This is very much implementation dependent. Some implementations have a 1:1 provisioning of primary/backup - where the backup would get used when its specific primary goes down - this draws on the FRR notion in the forwarding planes. Refer to the definition in draft-ietf-grow-bmp-path-marking-tlv These clarifications have implications on several of the stats as they are defined currently. <discuss-2> Section 3 has the following text and Section 4 introduces a table that brings up an interesting aspect. "This section defines different statistics type for Adj-RIB-In and Adj-RIB-Out monitoring type. Some of these statistics are also applicable to Loc-RIB; refer to Section 4 for more details." For types 24 through 28, they are applicable for both Adj-RIB-In and Loc-RIB. How does one know what is being reported? Can this be clarified? Seems like this is the first document introducing such overloaded types but I don't find the reason why this is being done. There is also a sort of duplication for same stat being both global as well as per afi/safi - is there any guidance on whether only one of them needs to be supported (this way avoiding the race conditions and discrepancies in their totaling)? It is important to clarify these aspects if this is going to set a precedent/guidance for other similar stats in BMP in future documents? _______________________________________________ GROW mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
