Dear WG,
We have just posted the -01 revision of this document. It mainly incorporates comments collected during the WG adoption process. Below is a summary of the main updates in document section order. Main updates in -01 Section 3.2.2: clarified graceful BMP session termination and reconnection behavior after QUIC connection interruption. Section 4.1: added the mandatory single-stream baseline and guidance on the optional multi-stream selections. Section 4.3: Route Mirroring messages are always carried over the common stream (stream 0), regardless of whether AFI/SAFI information can be extracted. Section 6: removed the automatic TCP fallback and added QUIC debugging guidance and an open issue on stream-level error handling. Section 8: added ICMP handling security considerations for long-lived BMPoQUIC connections. Other: added an IPv6 use case, clarified stream numbering and QUIC Stream ID mapping, updated references, and made editorial improvements. Please review the document and let us know if you have any comments or suggestions. We would also like to send the following questions for this document. Look forward to hearing your thoughts. 1) Stream-local error handling The document currently does not define any stream-level error recovery mechanism: if a monitoring station receives a BMP message it cannot parse, it SHOULD terminate the entire BMP session (Section 6). We would like to converge on the behavior of sender and receiver when a single stream is reset (e.g., after a malformed message), including stream identity negotiation and message re-synchronization. This interacts with the future evolution of the control channel and with the equivalent issue in BGP over QUIC (draft-retana-idr-bgp-quic) a shared analysis across both documents may be worthwhile. Questions for the WG: Should a malformed message on one stream be recoverable by resetting only that stream? If so, what stream identity negotiation and re-synchronization mechanism would be needed? 2) Indicating the multi-stream selection in useThe draft defines three optional multi-stream selections (Peer Stream, Per-AFI/SAFI Stream, Function Streams with Control Stream) on top of a mandatory single-stream baseline (Section 4.1). However, the monitoring station currently has no in-band way to know which selection is in use, i.e., what kinds of BMP messages to expect in each stream.One proposal is to expand the information TLV of the Initiation message to carry the multi-stream type: in the Peer Stream and Per-AFI/SAFI selections, the Initiation message sent on each stream would carry its own multi-stream type TLV, while in the Function Streams selection, the Initiation message on the control channel would indicate the selection for the whole connection. We welcome feedback on whether such a TLV should be defined in this document or a future one, and on its exact semantics. Thanks a lot for your review and feedback. Best regards,Yisong on behalf of co-authors ----邮件原文----发件人：internet-drafts <[email protected]>收件人：Changwang Lin <[email protected]>,Mukul Srivastava <[email protected]>,Paolo Lucente <[email protected]>,Thomas Graf <[email protected]>,Yisong Liu <[email protected]>抄 送: (无)发送时间：2026-10-27 20:17:35主题：New Version Notification for draft-ietf-grow-bmp-over-quic-01.txtA new version of Internet-Draft draft-ietf-grow-bmp-over-quic-01.txt has beensuccessfully submitted by Yisong Liu and posted to theIETF repository.Name: draft-ietf-grow-bmp-over-quicRevision: 01Title: Using BMP over QUIC connectionDate: 2026-10-27Group: growPages: 20URL: https://www.ietf.org/archive/id/draft-ietf-grow-bmp-over-quic-01.txtStatus: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-over-quic/HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-over-quicDiff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-grow-bmp-over-quic-01Abstract: The BGP Monitoring Protocol (BMP) provides a convenient interface for obtaining route views by monitoring BGP sessions. BMP operates over TCP and is unidirectional (from client to server). QUIC provides multiple simultaneous streams to carry data in one direction, enabling much better efficiency and performance for both peers, in particular unidirectional streams can provide reverse data protection for the sender. QUIC also provides shorter handshake and includes TLS. This document describes how to use BMP over the QUIC transport protocol, named BMPoQUIC.The IETF Secretariat
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
