> On Mar 12, 2026, at 03:10, Aseem Choudhary (asechoud) 
> <[email protected]> wrote:
> 
> "For Statistics Report message (regardless of whether it can get AFI/SAFI or 
> not), since it may be a periodic message with low load, and different 
> statistics may have some correlation. So it SHOULD always be carried over the 
> control channel to maintain better atomicity of all statistics."
> I believe, the control channel is defined as a single bidirectional Stream 0 
> for the entire BMPoQUIC connection, and there is only one control channel, 
> shared across all peers.
> 
> If so, will not it reintroduces serialization bottlenecks? e.g. If a router 
> has 500 BGP peers each sending periodic Statistics Reports, all of them are 
> serialized on Stream 0. A large burst of stats from many peers could back up 
> the control channel, potentially delaying Peer Up/Down notifications and 
> Initiation/Termination messages. 
> 

I agree with this assessment.  In general, the control channel should contain 
information primarily to help understand data that is sent across other 
streams.  Since stream creation is already an asynchronous activity, it's 
important to not congestion the control channel.

Somewhat different than the underlying requirements for serializing BGP data, 
statistics are quite amenable to being streamed independently.  For heavily 
threaded QUIC and BMP implementations, this also may permit individual threads 
to provide their summaries on different streams.

That said... there's a general desire for some level of association for 
statistics vs. their data.  As an example, if your rib-in/out statistics 
significantly were out of sync on a separate stream from the data being 
serialized for that peer/afi/safi, it muddles things even more significantly 
than they are today.  As an example, if your afi/safi rib-in/out counter is 
interleaved in a periodic fashion (typical implementation), and you have a 
backlog of route mirroring messages, it's difficult to tell where you're 
converging to.

It's fine for these things to be loosely coupled, but it becomes important to 
understand the operational significance when they are.

-- Jeff

_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to