Hi Mukul,
Thanks for all the work so far, some brief thoughts inline: On Wed 8 Apr 2026, 19:27, Srivastava, Mukul wrote: > On Implementation Complexity: > > I agree that the multiple stream options create complexity both at producer > (routers) and consumer (collector) side. > > We could consider: > > 1. > Designating one option as the baseline/MUST implement (for example the > simplest: single stream or peer stream). > 2. > > 3. > Moving the more complex options (per-AFI/SAFI, function + control streams) to > SHOULD or MAY. > 4. > > 5. Adding clearer guidance on when each approach makes sense operationally > > This would give implementers a clear starting point while preserving > flexibility for those who need it. Happy to (help) experiment, from the collecting perspective. Perhaps we'll find one of the options to be clearly superior for everyone, otherwise an approach like you describe might be sensible. Let's find out. > On Debugging/Wireshark: > > Wireshark does support QUIC stream analysis when you have the TLS keys, but > it's admittedly more complex than TCP pcaps. We could add a brief note in > operational considerations about debugging best practices. I'll dive into this and see how far I get. Maybe the wiki is a good place to collect experiences and perhaps even share data, at some point? If I manage to persuade my wireshark to show me something, I'll make a start there. > I agree on both of your points about route mirroring and fallback behavior. > > 1. > Route Mirroring: Keeping it simple makes sense, especially for > troubleshooting scenarios. For example, we'll can update section 4.3 to > consistently send route mirroring on the common stream (stream 0) regardless > of whether AFI/SAFI can be extracted. > 2. > > 3. > Fallback Behavior: Also agree - keeping it simple is better. We should > clarify that the fallback is only for initial connection establishment. If a > QUIC connection fails mid-stream, the monitored router should attempt to > re-establish a new QUIC connection, not fall back to TCP. > > Thanks > > Mukul Thanks, luuk _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
