Luuk, > On Apr 8, 2026, at 10:05, Luuk Hendriks <[email protected]> wrote: > > 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.
I think this is more a symptom of the document not yet reaching design maturity. If you have opinions, I suspect the authors would be happy to get text. (For my part, I'm chasing getting other drafts updated so haven't the time to spend on this myself at the moment.) The general idea most BGP-like features will want out of QUIC streams will be a reduction of head of line blocking for its data. For BGP, we also get the benefit of splitting the address families so that framing errors on one family don't have to take down the full session. BMP has a overlapping consideration, but there's no clean way in core BMP to deal with a reset. For BMP on QUIC, a receiver of a malformed message could unilaterally close the stream but it'd be unclear for the sender on how to behave. Such discussions will likely drive the behavior for the control channel for this use case and push BMP out of full write-only mode. Once things are in order, my expectation is a client will: get initiation and other messages related to what is covered by that stream ... and it's just a stream of the usual stuff. Basically just a micro-BMP session. Not broadly discussed is how much streams will help the various use cases. QUIC has the possibility of feeding the pipe faster than TCP. At the consumer level, the use case for eating BMP data will drive portions of the use case. For example, if you're doing SDN style operations using BMP, being able to avoid the head of line blocking for subsets of the data make a stream appealing. However, at the sending side, things get more complicated. If it's a single piece of software feeding the streams, pushing harder at multiple pipes doesn't necessarily help. If it's threads, perhaps it does. If it's an implementation where the transport is shared across multiple components, possibly also helpful. But mostly, I expect that structural separation becomes motivated by prioritization. > 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. BMP has already started having the "filtering" conversation. Much like prioritization, that could be a motivating factor. I don't think the parallel to FSv2 is quite right. This is more a question of "you have a more interesting transport - how does that help?" FSv2 analogy would be more "here's how the various BMP extensions are deployed differentially on different kinds of transports. > > - 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. I think fallback is probably not the best idea. BMP is a provisioned mechanism in the various implementations I'm familiar with. You either know the endpoint can accept BMP - or not. The same is likely to be true for the transport protocol. (Cue someone doing a URI scheme for BMP...) -- Jeff _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
