Hi all, I've read the -06 version and support adoption. Leveraging the multiple streams within a single QUIC connection will hopefully allow us to untangle things a bit, and see some performance benefits at the same time.
With the current list of options in section 4 (stream per peer, per afi/safi, function+control stream), I can imagine vendors (== the exporting side) are already scratching their heads on how to implement all those things. Presumably some options might be trivial to realise while others might be nearly impossible, depending on overall architecture and code bases. For the collecting side things will be tricky enough as well. Hopefully the document won't become too daunting in that sense, and hopefully we can avoid the situation where we have multiple implementations all supporting a different subset of the options. While typing this, FlowSpec comes to mind. For FlowSpec v2 there is the explicit split between the 'base functionality' and other more fancy things, perhaps we can be inspired by that approach. Continuing on that, though perhaps off topic: when it comes to developing and debugging, I'm wondering how trivial it is to use wireshark for QUIC streams? And to what extent one could replay a simple dump, for testing purposes? The 'just send me a pcap'-approach might become a lot harder while there's probably a lot more to debug. This is not limited to this document or this WG of course, and perhaps already solved and thus a non-issue. Lastly, two things I'd like to discuss once the doc is adopted: - in the per AFI/SAFI stream scenario, for route mirroring, the text currently proposes to try to get the AFI/SAFI from the BGP PDU if it's there, otherwise use the common stream. Assuming route mirroring is used mostly for troubleshooting, I'd propose to keep it as simple as possible and reduce the number of variables: just put it on one and the same stream, don't try to be smart. Possibly you've enabled route mirroring because garbled BGP PDUs are causing issues, then you don't want to figure out what your BMP implementation is adding to the puzzle - in the operational considerations, the text states that when a QUIC stream can not be established, one should fallback to TCP. But what about failure mid-stream? Should we also fallback? Should we try to keep state and somehow get in sync again via TCP? And if yes, should we then just keep on using TCP forever? My first thought would be 'no' to all of these, again keeping things simple, and don't ever do any type of fallback. Thanks, luuk On Fri 27 Mar 2026, 11:17, Job Snijders via Datatracker wrote: > This message starts a grow WG Call for Adoption of: > draft-liu-grow-bmp-over-quic-06 > > This Working Group Call for Adoption ends on 2026-04-10 > > 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. > > Please reply to this message and indicate whether or not you support adoption > of this Internet-Draft by the grow WG. Comments to explain your preference > are greatly appreciated. Please reply to all recipients of this message and > include this message in your response. > > Authors, and WG participants in general, are reminded of the Intellectual > Property Rights (IPR) disclosure obligations described in BCP 79 [2]. > Appropriate IPR disclosures required for full conformance with the provisions > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > Sanctions available for application to violators of IETF IPR Policy can be > found at [3]. > > Thank you. > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-liu-grow-bmp-over-quic/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-liu-grow-bmp-over-quic-06 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-liu-grow-bmp-over-quic-06 > > _______________________________________________ > 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]
