Hi Jeff, Thank you for your review. We appreciate your thoughtful comments and suggestions.
Your comments have been addressed in latest version. Link: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-bgp-rib-stats/14/ Diff: https://author-tools.ietf.org/iddiff?url1=draft-ietf-grow-bmp-bgp-rib-stats-13&url2=draft-ietf-grow-bmp-bgp-rib-stats-14&difftype=--html Pls check and let us know if there are any further comments. Thanks, Changwang 发件人: Jeffrey Haas <[email protected]> 发送时间: 2025年11月6日 5:33 收件人: [email protected] 主题: [GROW] Re: I-D Action: draft-ietf-grow-bmp-bgp-rib-stats-13.txt Here's a few review comments vs. -13. Much of this commentary is caused by the iteration as part of recent review. :-) General: s/AS-PATH/AS_PATH/ Section 2 - terminology: Most of the headache here is created by a desire to repeat terminology defined elsewhere and minimize the variations. "Pre-policy adj-rib-in". As written, this definition is confusing. What I think the intent of this sentence was intended to do was to say "we're using the 7854 pre-policy adj-rib-in terminology consistently in this document." If so, perhaps say that? Adj-Rib-Out: Refer to RFC 4271 for this. Forward reference to 8671 just bounces you back there. :-) A note on primary path: RFC 4271 never named the resulting adj-rib-in instance that is selected by the decision process. Much like how BMP has defined the logical 5 layer pre/post model that is now heavily used by other BGP elements, like the YANG modules, I believe you're also picking the terminology we may need to pick up in 4271-bis. However, there's definitional inconsistencies with how 4271 talks about the selected path: : 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. For load balancing purposes, a prefix can have more than one : primary route. For load balancing purposes (undefined in 4271), we're not ever selecting more than one route, nor does 4271 talk about installation of multiple nexthops. Clearly real routers do this. Since the "load balancing" element isn't used in this draft, perhaps just dorp the load balancing sentence? : Backup route: A backup route is also installed in the Loc-RIB, but it is not : used until all primary routes become unreachable. Backup routes are used for : fast convergence in the event of failures. 4271 doesn't have a sense of backup paths. It's not clear to me from the document what the intent of this item is. Are these paths that are eligible for route selection that are not the primary path? Section 3.1: : Type = 18: (64-bit Gauge) Current number of routes in pre-policy Adj-RIB-In : [RFC7854]. This gauge is similar to stats type 7 defined in [RFC7854] and : makes it explicitly for the pre-policy Adj-RIB-In. When the monitoring : station supports both type 7 and type 18, the monitored router MUST send : only one of these types. Avoiding sending both of these is a good idea. However, doesn't this cause backward compatibility issues for clients that may be consuming type 7 in whatever context it was using? If so, perhaps comment that this deprecates type 7 and that type 7 SHOULD NOT be sent. This might cause this draft to update RFC 7854. Type 19, ditto. Type 29+, "threshold". The 4271 text clarifies that this is an upper bound on routes accepted. A bit of clarifying text about this threshold's relationship to that configured upper bound would be helpful. Types 35..37 covering RPKI elements: These are fine. We'll be wanting stats long term for ASPA and OTC over time. A route may fail RPKI validation for more than one reason as we add such stats. A prior reviewer commented on "when can you do math on these stats to add up to something". A valid operational consideration might be that these RPKI statistics will only ever be subsets vs. the total number of invalidated routes. This would simply be a bit of RPKI specific text vs. the same stuff in the new ops considerations section. Type 39: Again, we need to talk about provisioned length of the as-path. The wording here is slightly awkward, but I suspect the RFC Editor will help here. Section 5 - operational considerations : The default configuration SHOULD disable reporting for new gauges, with : implementations allowed to provide a configuration mechanism to enable them. So... why is default off? Why do we want to make operators engage in an ever increasing confetti of knobs to turn stuff on? These things are, if we're periodically reporting them in the minutes apart range a trivial amount of data per monitored router. If anything, there's a need for a general consideration like "implementations SHOULD provide a mechanism to select subsets of collected and reported statistics. This mechanism SHOULD be able to be configured on a per-monitored router basis." : Operators SHOULD enable only necessary statistics to reduce memory and CPU : overhead. And similarly, if this is intended to justify the previous off, I'm curious why we need to really say this. The per-router overhead for this state is small. CPU overhead is non-existant if the state isn't monitored. I'd urge the ops reviewers to simply let this item be deleted. -- Jeff On Mon, Nov 03, 2025 at 06:12:26AM -0800, [email protected] wrote: > Internet-Draft draft-ietf-grow-bmp-bgp-rib-stats-13.txt is now > available. It is a work item of the Global Routing Operations (GROW) WG of > the IETF. > > Title: Advanced BGP Monitoring Protocol (BMP) Statistics Types > Authors: Mukul Srivastava > Yisong Liu > Changwang Lin > Jinming Li > Name: draft-ietf-grow-bmp-bgp-rib-stats-13.txt > Pages: 15 > Dates: 2025-11-03 > > Abstract: > > RFC 7854 defines different BGP Monitoring Protocol (BMP) statistics > message types to observe events that occur on a monitored router. > This document defines new statistics type to monitor BMP Adj-RIB-In > and Adj-RIB-Out Routing Information Bases (RIBs). > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-bgp-rib-stats/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-bgp-rib-stat > s-13 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-grow-bmp-bgp-rib- > stats-13 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > GROW mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [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]
