Hi Job and Jeff,
Thanks for both replies, which help us sharpen thoughts on the Stage 1 design. Job: the per-source CCR hash approach maps cleanly to our per-source reporting structure: each RPKI data source gets its own TLV group, so carrying a CCR hash per source is straightforward. Your mention of "pre-/post-merging" raises a question we hadn't considered explicitly: should BMP report the state of each source independently (pre-merge), or the merged result that the router actually uses for validation, or both? Our current thinking is to focus on per-source (pre-merge) reporting, since as Jeff points out, the post-merge state is hard to represent in a universally verifiable way, especially once SLURM enters the picture. Jeff: the SLURM observation is a useful one. If the effective validation dataset is shaped by local SLURM rules, then per-source CCR hashes alone don't tell the full story. This actually connects our Stage 1 (data sources, with per-source hashes) and Stage 2 (policy configuration, which could include SLURM exceptions) . For a monitoring consumer, it would need statistics from both stages to reconstruct what the router is actually validating against. We think this reinforces the necessity to consider SLURM as an important item in Stage 2. Considering the implementation cost of retaining objects for hash computation, we prefer to keep CCR hash as an optional field rather than mandatory, so implementations can adopt it as they are ready. Agreed that use cases will clarify as we get more concrete. So we'll keep refining the draft at requirements-level and let the statistics definitions drive the specifics. Btw: Jeff, it's a pity we won't be able to see you in person at IETF, but looking forwarding to continuing our discussions on the mailing list. Best Regards, Shuhe -----原始邮件----- 发件人:"Jeffrey Haas" <[email protected]> 发送时间:2026-03-12 22:37:01 (星期四) 收件人: 王舒鹤 <[email protected]> 抄送: [email protected] 主题: [GROW] Re: draft-wang-grow-bmp-rpki-mon-reqs Shuhe, On Mar 11, 2026, at 23:43, 王舒鹤 <[email protected]> wrote: Thanks for the CCR pointer — we weren't tracking that draft closely enough and it's clearly relevant. I am also only recently familiar with CCR as well. I think it will be highly relevant to our telemetry story for various RPKI applications. 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. As Job describes in his reply, computing the data over multiple types is possible. For combination mechanisms for authentication, including SLURM, this makes it somewhat more difficult for individual BGP speakers to provide a universally understood CCR hash to provide a sense for consistency. However, reporting the CCR hashes over the various individual inputs may be sufficient. As an example, having the CCR hashes for each RPKI-RTR session provides a good sense at the sender (RPKI cache server) side along with the receiving BGP speaker as to what database has been absorbed and its consistency state. This does, however, require the client to retain all information / objects required for the hash. I suspect the use cases will clarify as the various statistics are proposed. See you at the GROW session. Sadly I will not be present in person, but will be watching remotely. -- Jeff
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
