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]
