Hi Fedor,
Version -05 of the document has been submitted yet but is mostly wrapped
up on GitHub, please see here:
https://github.com/paololucente/draft-ietf-grow-bmp-rel/blob/main/draft-ietf-grow-bmp-rel.txt
I like your proposal, i agree there is a fit and we can certainly add
this as part of -05 if we manage to converge by the cut-off date for
IETF 125.
If you see we have a new Event Type Header, described in section 3.2,
where we differentiate for now among Routing and Health events; the
distinction is mainly functional to the structure of the message, ie.
whether a per-peer header is needed & whether BGP Message TLV is going
to follow. Would you agree your proposal would fit well under the
Routing Event type? For more clarity we could rename it Routing and
Validation Event, that is, except for some optional TLVs related to
validation, i don't see the main structure changing among Routing and
Validation events, ie. Validation not requiring a Per-Peer Header or a
BGP Message TLV.
Another aspect that you did bring up is that you can have a validation
change but the change could be, for example, from valid to invalid but
also from invalid to valid. In other words the "Validation Fail TLV"
naming does not fully capture the extent of what we may want to encode
in REL with regards to validation. Maybe "Validation Fail TLV" should be
renamed "Validation State Change TLV", would you agree? If yes then
would you agree that the optional "RPKI Cache Context TLV" can follow a
"Validation State Change TLV" event?
Paolo
On 21/2/26 19:28, [email protected] wrote:
Dear GROW Working Group,
I've been reviewing draft-ietf-grow-bmp-rel-04 and want to suggest
extending it to RPKI validation use case which is beyond normal
policy-related changes.
After looking at the existing drafts and discussing the idea with a few
community members, I believe this is the right draft to propose this
enhancement.
The draft does a great job supporting validation RPKI Invalids reporting
via Event Reason (Validation Fail) and explicitly mentions usage of
"artificial BGP Update" PDUs in Section 3.5.
I suggest to cover RPKI Cache-triggered state change events in Section 3 :
Events may be generated as a result of re-evaluation not directly tied to the reception of a BGP Update, for example changes in validation state following an RPKI cache serial advance or reset. In such cases the BGP Update PDU carried in the BGP Message TLV may be
artificial and include only the affected NLRI.
RPKI Cache resets or large serial advances can cause large volumes of
validation status changes. Implementations SHOULD apply rate limiting.
I also would like to propose adding a new optional Informational TLV
(RPKI Cache Context TLV) which will carry RTR Session ID and Serial
Number for correlating events with cache updates, plus optional cache
identifier.
The good thing is, that under "RPKI Cache" we already have ROA, ASPA,
BGPSec and other objects, which are relevant to the global RPKI
infrastructure.
Overall, I liked compact and precise structure of current problem
statement in draft-ietf-grow-bmp-rel-04.
Happy to discuss further or provide more clarification if needed.
Best regards,
Fedor Vompe
Software Engineer
Deutsche Telekom
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
