Hi Jeff,
Thanks for the CCR pointer — we weren't tracking that draft closely enough and it's clearly relevant. A question on how CCR fits with multiple RPKI data sources: in our investigation of the Huawei NetEngine 8000 router, we found that the router supports acquiring RPKI data not only via RTR, but also from iBGP/eBGP peers and static configuration. We expect such multi-source scenarios to become more common as RPKI deployment grows — for example, during transition periods where operators maintain both RTR cache connections and static overrides, or when upstream providers begin redistributing RPKI-derived information via BGP. In such cases, a single CCR hash (bound to one RTR session) wouldn't fully describe the RPKI data actually used for validation on the router. We're thinking about whether Stage 1 should report per-source identifiers (CCR hash where available, record counts otherwise) alongside some indicator of the combined dataset. I will also keep an eye on if there is any discussion in SIDROPS about CCR's applicability beyond single-cache scenarios. For the interim before CCR matures, your checklist — RTR up/down, DB version, per-session validation status, presence of validation state extended communities — looks like a good baseline. In our future version, we plan to define these as a small set of required TLVs, with CCR hash as an optional field that implementations can adopt when ready. See you at the GROW session. Best Regards, Shuhe -----原始邮件----- 发件人:"Jeffrey Haas" <[email protected]> 发送时间:2026-03-12 04:25:12 (星期四) 收件人: 王舒鹤 <[email protected]> 抄送: "[email protected]" <[email protected]> 主题: Re: [GROW] draft-wang-grow-bmp-rpki-mon-reqs Shuhe Wang, On Mar 10, 2026, at 22:27, 王舒鹤 <[email protected]> wrote: That said, reading your comments, we think the current text in Section 4 still carries more RTR-specific detail than necessary (e.g., RTR protocol version, TCP connection type, cache priority). We plan to refactor this in the next revision to: 1. Define a minimal, source-type-agnostic set of fields ; 2. Make source-type-specific parameters (like RTR version or eBGP AS number) optional extensions; 3. Try to merge message types (currently the number is 5) into less kinds of types. Reducing the data and focusing on BGP route outcomes as the primary use case will be helpful. As you note, there is some room for providing summary data to help correlate how RPKI-RTR state is being used for validation will be helpful for the core BGP data. To provide an example, CCR hash values - when they become commonly implemented - can be helpful for a BMP consumer to know what version of the database is being used to validate the routes. However, CCR will require some time to mature and become commonly available state. https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-ccr-02 Meanwhile, as some of the draft covers, being able to verify that RPKI validation is available and whether it has been done for a given route is an excellent use case. The supporting information to report how that validation was enabled (RPKI-RTR is up, it has X version of the DB, this BGP session is/is not validated, validation extended communities are present) is useful - if we can make the information dense enough. We will present this direction at the upcoming IETF 125 GROW session and would very much welcome your further input there or on the list. I'm looking forward to the presentation. -- Jeff
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
