Hi Yisong, and Authors of draft-ietf-grow-bmp-over-quic,
Thank you !
This email has inputs/suggestions for Question 2, the multi-stream type TLV.
I shall firm up on Question 1 (stream-local error handling) in a
separate/subsequent email, thought its related and I tried my best to detail
out only #2 here.
Please correct anything I mis-interpreted from your literature 😊
As we all know, the premise is that the monitoring station needs to know what
each stream carries.
And just to avoid any confusion, in this email, "scope” refers to the peers
(Peer Stream) and/or the AFI/SAFI (Per-AFI/SAFI Stream) that a stream carries.
I propose "STREAM DESCRIPTOR TLV”, A new Information TLV, registered in the BMP
Initiation Message TLVs registry .
*
The router sends it in the Initiation message that Section 4.1 already requires
as the first message on each stream.
The structure of the Value fields can be (open to further inputs):
*
Selection (1 octet): single-stream, Peer Stream, Per-AFI/SAFI Stream, or
Function Streams.
*
Kind/Type (1 octet): the role of the stream within the selection, for example
peer-set stream, common stream, or AFI/SAFI stream.
*
Stream Index (2 octets) and Stream Count (2 octets): this is stream i of N (For
example, 2nd stream out of total 100). Count 0 means streams are created on
demand.
*
Epoch (4 octets): 0 when the stream is first created. The router adds 1 each
time it creates a new stream for the same scope after a stream failure. This
can be leveraged for covering the gap as in question 1
*
AFI (2 octets) and SAFI (1 octet): present only for AFI/SAFI streams.
Important part of the solution is that peers are not listed in the TLV.
Section 4.2 mentions that the peer-to-stream mapping follows configuration, and
configuration can change.
Hence, we can narrow it to the stream on which its Peer Up message is sent:
*
The station learns the peers of each stream from the Peer Up messages.
*
An optional (explicit) list of peers can be added if agreeable to all
Following are open questions for backward compatibility,
boundary-condition-handling (guardrails):
1.
Unrecognized TLV type:
*
the draft should mention that the station ignores a TLV type it does not
recognize.
*
BMP messages carry their own peer and type information, so the station can
process them without the TLV.
2.
Scope mismatch.
*
if a message arrives on a stream whose declared scope does not match it (for
example a Route Monitoring message for another AFI/SAFI), the station processes
the message and records the mismatch.
3.
Function Streams.
*
Section 4.1 requires an Initiation message on each stream in the Peer Stream
and Per-AFI/SAFI selections.
*
Sections 4.1 and 4.4 seems to require it only on the control channel in the
Function Streams selection. If that is right, the descriptor of a function
channel needs another carrier, for example a Peer Up Information TLV on the
control channel that names the function channel. Open to discussion on which
one is preferred here?
4.
Stream Count.
*
In the Peer Stream selection, a configured stream that never opens should be
considered the same as a stream whose peers send no messages.
*
Stream Count lets the station detect the missing stream.
Let me know your thoughts on above while the response to other query is on its
way.
If it crowds the existing email chain, we can always spawn-off as you mentioned.
Best Regards,
Saumya
From: Yisong Liu <[email protected]>
Date: Friday, 30 October 2026 at 9:27 AM
To: Dikshit <[email protected]>; Dikshit, Saumya
<[email protected]>; grow <[email protected]>
Cc: draft-ietf-grow-bmp- <[email protected]>
Subject: Re:Re: [GROW] Fw:New Version Notification
fordraft-ietf-grow-bmp-over-quic-01.txt
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 I'm
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<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-grow-bmp-over-quic-01.txt__;!!NpxR!mdkLpOvneOpSrSe9IZiAUAdinYRgMLRSkOY_Qs-SNrFi0PvKHZ45I1GpuHQtWn6fnhWWLKWtkZNQNvfTNMCNOHQa$>
Status:
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-over-quic/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-over-quic/__;!!NpxR!mdkLpOvneOpSrSe9IZiAUAdinYRgMLRSkOY_Qs-SNrFi0PvKHZ45I1GpuHQtWn6fnhWWLKWtkZNQNvfTNI-BskKJ$>
HTMLized:
https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-over-quic<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-over-quic__;!!NpxR!mdkLpOvneOpSrSe9IZiAUAdinYRgMLRSkOY_Qs-SNrFi0PvKHZ45I1GpuHQtWn6fnhWWLKWtkZNQNvfTNFncrI8A$>
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-grow-bmp-over-quic-01<https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-grow-bmp-over-quic-01__;!!NpxR!mdkLpOvneOpSrSe9IZiAUAdinYRgMLRSkOY_Qs-SNrFi0PvKHZ45I1GpuHQtWn6fnhWWLKWtkZNQNvfTNHSIXM71$>
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]
