Hi Jeff, Thank you for your detailed review and valuable comments on draft-liu-grow-bmp-over-quic-03. They are greatly appreciated.
We have addressed all your comments inline with [Changwang] and incorporated the updates in version draft-liu-grow-bmp-over-quic-04. Link: https://datatracker.ietf.org/doc/draft-liu-grow-bmp-over-quic/04/ Diff: https://author-tools.ietf.org/iddiff?url1=draft-liu-grow-bmp-over-quic-03&url2=draft-liu-grow-bmp-over-quic-04&difftype=--html Thanks, Changwang 发件人: Jeffrey Haas <[email protected]> 发送时间: 2025年11月7日 3:34 收件人: [email protected]; [email protected] 主题: BMP over quic - statistics Authors, The multi-stream procedures in -03 are much improved. Thanks. I'd recommend that you always establish the control stream. This avoids ambiguity about stream zero. In the case of BGP over QUIC, the motivation for different frame types is that the control channel has need to be the back-channel for unidirectional function channels in some cases. [Changwang] Thank you for your suggestion. The latest version has been modified to default to creating stream 0, as detailed below: 1.Regarding section 4.2 in the document, "Per-Peer Stream": BMP messages for each peer are definitely in the same stream. Since SR messages are peer-based, each peer's SR messages are also independently in the same stream. Therefore, in the per-peer stream approach, adding a separate stream 0 may require additional processing, such as resending peer-up messages in stream 0, which could lead to message redundancy. Hence, the latest document has been revised to default to using stream 0 to convey messages for all peers. 2.Regarding section 4.3 in the document, "Per-AFI/SAFI Stream": Stream 0 is created by default as a common channel for conveying Route Mirror and Stat Report messages. 3.Regarding section 4.4 in the document, "Function Streams with Control Stream": Stream 0 serves as the control channel, and Stat Report messages are conveyed through the control channel. What's the motivation for the sequence number? [Changwang] is to ensure a one-to-one correspondence between control messages and their response messages, guaranteeing the sequentiality of responses to the same control message. For statistics, while there's text suggesting that per-afi/safi statistics might be sent on the per-afi/safi streams, I'd suggest that these stay on the control channel. The motivation for this is trying to get better atomicity of the BMP-wide statistics vs. the per-afi/safi ones. When split, you have a greater chance to confuse things like total message counters and the more granular ones in time. I outright admit that there's nothing in the protocol that requires that statistics be gathered in atomic snapshots. However, there's not a lot of motivation for applications that can do so to not do it. But even such atomic state snapshots can lose temporal coherency if you serialize them over different streams where the messages show up at differenet times depending on queues. [Changwang] In the latest version, the changes have been made according to your suggestion. Statistics messages belonging to the same peer can now be sent together within the same stream. -- Jeff ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出的个人或群组。 禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。 如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
