Hello 王舒鹤, On Thu, Mar 12, 2026 at 11:43:57AM +0800, 王舒鹤 wrote: > 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.
You are right that VRPs can come from multiple sources (e.g. from RTR, from static configuration, and pre-/post-merging of the various sources). One can generate CCR ROAPayloadState hashes per source. A nice aspect about this is that it makes comparing various sources easier! Kind regards, Job _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
