Changwang, Thanks for addressing the issues I raised in -13. I've reviewed the diff in -14 and see that you've updated your text to cover my comments.
The one minor suggest I have further related to the changes -13 to -14 are related type types 33 and 34: : Type = 33: Number of routes currently rejected due to exceeding the maximum AS_PATH length. : Type = 34: Number of routes currently in per-AFI/SAFI rejected due to exceeding the maximum AS_PATH length. I would suggest the text read "exceeding the locally configured maximum AS_PATH length". This is the text used elsewhere in the document, and reflects that this maximum is not being imposed by the BGP protocol. -- Jeff > On Nov 14, 2025, at 7:28 AM, linchangwang <[email protected]> wrote: > > 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]
