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]
