Hi Saumya,
Thanks for the quick feedback, and for the pointers to your nmop draft and the earlier GROW thread. On question 2, I agree the argument is grounded in the same principle, and I39m inclined to move the multi-stream type TLV from the "future extension" wording in Section 4.1 into the next revision of this document. I would welcome your ideas on the solution and text — especially on the TLV value semantics, since in the Peer Stream and Per-AFI/SAFI Stream selections the collector also needs to know which peers / which AFI/SAFI each stream carries, not just the type. On question 1, I agree an explicit signal is preferable to leaving the collector to infer a gap after the fact, and I can see stream-reset proposal and the Events-Suppressed code point as two faces of the same problem. I would be glad to work through the signal and re-synchronization design with you, and to keep the analysis consistent with draft-retana-idr-bgp-quic, which raises the same question. If convenient, feel free to send your concrete ideas to the list, and I think we can take them into the next revision (or a separate thread if that works better for you). Best Regards Yisong ----邮件原文----发件人："Dikshit, Saumya" <[email protected]>收件人：Yisong Liu <[email protected]>,grow <[email protected]>抄 送: draft-ietf-grow-bmp- <[email protected]>发送时间：2026-10-28 16:03:27主题：Re: [GROW] Fw:New Version Notification fordraft-ietf-grow-bmp-over-quic-01.txt Hello Authors of draft-ietf-grow-bmp-over-quic and GROW WG members, Thanks for publishing the new rev. I had few inputs for your two queries based on prior published ietf drafts (in different group: nmop) and also an earlier discussions in GROW itself. So here it is: On question 2, the multi-stream type TLV in the Initiation message. I have another ietf draft in nmop ( draft-dikshit-nmop-telemetry-identifier-scoping ) and the argument presented in it applies directly here: a value cannot be safely interpreted by a consumer until the context it was produced under is declared alongside it, rather than assumed from configuration the consumer may not see. As I write this, a collector has to be told about which specific out of band multi-stream selection a router is using. The TLV you already propose would make that declaration explicit and in band instead. If you think it’s grounded in that same argument, I have few ideas on the solution/textual-insinuations. On question 1, stream-local error recovery. Earlier in the year, a separate thread with subject line "Question on draft-geng-grow-bmp-rel-enhancement," I had proposed an Events-Suppressed code point so a collector is told explicitly when events were dropped, instead of being left to infer a gap after the fact. I firmly believe that resetting one stream without killing the session falls in the same problem bucket: the collector needs an explicit signal that a stream was reset. Attaching the thread and I will more than willing to help work through what the signal and re-synchronization may/would/should matter here. Please let me know your thoughts on above. Best Regards, Saumya From: Yisong Liu <[email protected]> Date: Tuesday, 27 October 2026 at 5:57PM To: grow <[email protected]> Cc: draft-ietf-grow-bmp- <[email protected]> Subject: [GROW] Fw:New Version Notification for draft-ietf-grow-bmp-over-quic-01.txt 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 use The 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.txt A new version of Internet-Draft draft-ietf-grow-bmp-over-quic-01.txt has been successfully submitted by Yisong Liu and posted to the IETF repository. Name: draft-ietf-grow-bmp-over-quic Revision: 01 Title: Using BMP over QUIC connection Date: 2026-10-27 Group: grow Pages: 20 URL: https://www.ietf.org/archive/id/draft-ietf-grow-bmp-over-quic-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-over-quic/ HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-over-quic Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-grow-bmp-over-quic-01 Abstract: 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]
