Hi Jeff,
Thank you for your thoughtful feedback!
We fully agree that BMP should not become a catch-all for every protocol state
tangentially related to BGP. Your concern about BMP's responsibility scope is
correct.
However, to clarify our intent: the goal of this draft is to describe the
overall requirements for monitoring how RPKI data affects routing decisions on
the router, not to replicate RTR protocol operational monitoring. We see a
clear division of responsibility:
- YANG / streaming telemetry: RTR session management, protocol version
negotiation, cache server health, sync sequence numbers — i.e., the operational
state of the RTR protocol itself.
- BMP (in this draft): what RPKI data has the router acquired (from any
source), what validation rules are in effect, how each route is validated, and
how validation outcomes change route selection — i.e., the impact on BGP
routing.
Actually, in our latest draft, we already moved from "monitor RTR connections"
in the former version to
the more abstract "monitor RPKI data sources," which covers RTR,iBGP, eBGP, and
static configuration uniformly. The per-source information we propose to report
(data count, sync status, error counts) is intentionally kept at a summary
level — just enough for a BMP consumer to know whether the router's RPKI data
is current and complete, without delving into RTR protocol internals such as
session negotiation, PDU-level exchanges, or cache server certificate details.
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.
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.
Best regards,
Shuhe Wang
-----原始邮件-----
发件人:"Jeffrey Haas" <[email protected]>
发送时间:2026-03-09 03:26:49 (星期一)
收件人: [email protected], "[email protected]" <[email protected]>
主题: [GROW] draft-wang-grow-bmp-rpki-mon-reqs
Authors,
I apologize if this is a repeat of a prior comment I have given as I am
sometimes forgetful.
In your requirements section, you list:
"Monitor extensible RPKI data transport from various sources to routers,
including through RPKI-to-Router Protocol (RTR) [RFC8210], BGP [RFC4271], or
static configurations;"
I believe there is significant good value in monitoring related BGP state from
external interactions like policy and RPKI within BMP. We are seeing that
within the recent TLV and related drafts as part of WG feedback.
However, I have concerns for the more general requirement that other protocol
states such as RPKI-RTR itself get coverage in BMP. At the most general level,
this eventually turns into pressure for BMP to carry everything BGP-related. :-)
There is an operational need to monitor the RPKI-RTR itself. You are likely
aware of various efforts to provide YANG modeling for RPKI_RTR and also related
streaming telemetry for state covered by similar models. I would suggest that
the details of the RPKI-RTR protocol itself should be excluded from your
requirements.
-- Jeff
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
