Hi Yisong Liu, Changwang Lin, Thomas Graf, Paolo Lucente Thank you for your work on BMP over QUIC (draft-liu-grow-bmp-over-quic), I think it is very valuable for the future of BMP.
I have a few comments and questions I would like to discuss with you. This might only be a "me problem", but I struggled a bit to understand in Section 4.1 which messages had to be sent over which stream. >From what I understood, currently, each stream must be initialized with a BMP >Initiation message, and any stream can close the entire BMP session with a >Termination message. If this is correct, I think it would be beneficial to say >that as an introduction of 4.1. This would also relieve each mapping >subsection (4.1.X) of specifying that again and again. A tweaked version of this paragraph, which is already in 4.1.3, could probably do the job: > According to [RFC7854], Initiation Message MUST be sent as the first > message after the BMP session comes up. So it must be ensured that > the Initiation message is the first message sent on each BMP > c̶h̶a̶n̶n̶e̶l̶ stream, meaning that an Initiation message must be sent > first for > every BMP channel establishment. *A Termination message can be sent on > any stream. This terminates the entire BMP session, and closes the QUIC > connection along with all of its opened streams.* If you find the idea interesting, you could maybe also add a paragraph after that, similar to the one about the Peer Down TLVs in 4.1.3, but for a new information TLV that discloses the use/function of a stream (peer stream, AFI/SAFI stream, control stream, stats stream, etc.) in Initiation messages. This could prove useful when analyzing BMP data streams at the collector. In the mapping of Section 4.1.2 "Per-AFI/SAFI Stream without Control Channel", I find this paragraph a bit unclear: > * For Peer up Notification message, it could include open message of one > AFI/SAFI, and it should be carried over corresponding AFI/SAFI stream. I think "stream" should be plural here as a BGP OPEN can contain capabilities for multiple AFI/SAFIs, right? Also, if a BGP peer has capabilities for N AFI/SAFIS, do you open N streams, even if no prefixes were exchanged for those AFI/SAFIs? Do you open streams only for AFI/SAFIs that are in both RX and TX BGP OPENs of the Peer Up message? Still in 4.1.2, I do not understand this consideration, could you please elaborate? To me, BMP is a separate process from BGP and should work with any mapping regardless of the transport used by BGP. > If BGP still uses TCP as the transport protocol, the Per AFI/SAFI > Stream structure can be used selectively. If BGP uses QUIC as the > transport protocol [I-D.draft-retana-idr-bgp-quic], the Per AFI/SAFI > Stream structure MUST be used because of the implementation that > per-AFI/SAFI streams (function channels) are used to carry routing > information in one BGP over QUIC (BoQ) connection. In section 4.1.3, I think the mirroring should stay on its own stream(s). Diluting mirroring messages between RM messages will slow down the processing of those RM messages since mirroring is extremely verbose. Also, mirroring is, in my opinion, more of a debugging tool. Moving it to its own stream(s) might help the debugging process for operators. Another concern in section 4.1.3, to me, is the synchronization of control and functions channels. Closing BGP peer sessions and streams seems straightforward: control channel receives a BMP Peer Down => the related channels are closed. However, I am not sure that opening streams is that simple. Streams work independently and asynchronously in QUIC (right?). So how do I know which peer a function channel is referring to if I have not received the peer up in the control channel yet? Should I just buffer the whole stream of messages (potentially eternally in case of a buggy exporter that forgets to send a Peer Up) until I get a peer up? If this is actually a problem, this could probably be fixed with a sequence number. I believe QUIC provides a sequence number called "offset" at the level of a stream. At the level of a connection, there is the "packet number", but a BMP message might span over multiple QUIC packets, and its increment can be non-monotonic. Maybe a sequence number in the BMP common-header, or in a TLV? I believe that this could be useful for other out-of-order message cases, like receiving a messages after the Termination message has been received and before the QUIC connection is closed. Side question: is the intent of this draft to provide examples and best-practices in terms of mappings? Do you think it should leave the freedom to implementors of BMP exporters to implement any mapping they like for they custom use cases? Best regards, Maxence _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
