Hi Jeff, On Wed 8 Apr 2026, 13:00, Jeffrey Haas wrote: > 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.
This was not so much critique with regards to the text (which I appreciate is not in its final form), but more an expression of my fear that if we don't limit all the possible approaches to a certain subset of 'mandatory core concepts', we might scare off implementers on either side of the connection. That's also where my comparison with FS(v2) came in: not with regards to its concepts or mechanisms, but the approach of splitting up the documents into somewhat more bite sized pieces. If I remember correctly, that was partly motivated similarly. But before I'm making this any worse, I'm not advocating to already split things up: if anything I like BMP over QUIC to become a thing, and part of that will be exploring all the options first anyway. > (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. A bi-directional control channel opens up a lot of options. Not sure yet whether I'd be a fan, could be a slippery slope. Though I can see it making a few other proposed ideas, where the unidirectionality forces cumbersome workarounds, a lot more ergonomic. > 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. >From the collecting side of the connection, I think being able to reason about such individual micro-BMP streams (as opposed to the current one big intertwined firehose) is already a win, even before the better performance you described. > > 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...) Agreed. I can imagine a fallback could actually be more of a surprise to the operator rather than a solution. Thanks, luuk _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
