Hi Job and Jakob, Many thanks for the good inputs which I consolidated in this reply.
In regards to TFO applicability to the BMP application. During my initial research I was encouraged my section 6 of TFO RFC 7413 https://tools.ietf.org/html/rfc7413#section-6 It is well understood that the original intend of the RFC is two fold: - allow to re-establish a TCP session - performance gain for short-lived connections While the first is the motivation why TFO was chosen in this draft, the second is a welcomed by product where BMP could benefit from. Regarding the TCP_FAST_OPEN cookie handling and the separation between application (BMP) and transport (TCP). The goal of the draft is that both sides, the BMP client and the BMP server can decide wherever the new transport session belongs to the previous BMP session or not. This is done on the BMP client side by either clearing the TCP_FAST_OPEN cookie for transport or not. The BMP client does not need to know the previous value. It needs only to distinguish between establish a new session or re-establish an existing session. Different to the BMP client, the BMP server does the same but instead of clearing the TCP_FAST_OPEN cookie for transport it sets a new, different to the previous, cookie. I like to take your input Job about the TFO applicability to the BMP application and do my due diligence by going to the TCPM working group and get their opinion. I will also do my own research on applications using TFO and for which purpose. I will present then that to the GROW list and the next GROW session. Does that make sense? As you already pointed out the goal can be achieved not only on the TCP transport layer but also on the BMP application layer. There with the drawback that BMP is strictly speaking no longer unidirectional. Here my proposal would be to extend the BMP Initiation Message with another TLV containing the BMP session identifier. I agree that the size should large enough to be unique and I take the input being 64 bit as a proposal. The client set's the BMP session identifier and the server stores it. When a BMP session is established, a new BMP session identifier is set be the client and stored at the BMP server. When the BMP client establishes the BMP session, the server decides wherever to reply with the previously stored value (signaling its state) or 0 (a new session). BMP client acts wherever on exporting its queue or start a new RIB dump depending if BMP session identifier is different to the previous or not. Regarding the input from Jakob that not all the BMP message types should be queued, only BGP withdrawals. This is an interesting proposal I like to follow up and further like to understand it. If I understand correctly, only withdrawals would be queued during the re-establish time window and updates would be locally generated for the re-establish time window once the BMP session is re-established. Correct? Regarding the proposal of sequence numbers. It would imply that the BMP Common Header needs to be extended. Here I like to hear your thoughts why a session identifier is not enough and what benefit a sequence number would bring on the application layer when we already have sequence numbers on the TCP transport session. As you might recall, one of the objectives of the BMP hackathon was to detect loss of BMP messages. Also many thanks to Jeff about the feedback in regards to BGP NSR. I agree that solving the goal on a TCP transport layer would prevent implications onto BGP/BMP application in such condition when BGP process is being restarted. Best wishes Thomas -----Original Message----- From: Jakob Heitz (jheitz) <jhe...@cisco.com> Sent: Wednesday, March 10, 2021 4:09 AM To: Job Snijders <job=40fastly....@dmarc.ietf.org> Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org Subject: RE: [GROW] is TCP the right layer for BMP session resumption? >From the BGP speaker (client) implementation point of view, I would do it like this: The client keeps a ring buffer of data it sent to the server. The bottom of the buffer is at a certain sequence number. As messages are created, that bottom moves up. If the server were to restart, it would send its last received sequence number and session ID. If the buffer still contains the sequence number, then you're in luck, else big bang restart. The content of the buffer could be optimized by retrieving some of the information from the bgp table (adj-rib's are conceptual only) instead of literally storing it. How and if any optimization is done is implementation specific and not part of an RFC. Regards, Jakob. -----Original Message----- From: Job Snijders <job=40fastly....@dmarc.ietf.org> Sent: Tuesday, March 9, 2021 4:50 PM To: Jakob Heitz (jheitz) <jhe...@cisco.com> Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org Subject: Re: [GROW] is TCP the right layer for BMP session resumption? On Tue, Mar 09, 2021 at 08:44:18PM +0000, Jakob Heitz (jheitz) wrote: > BMP is a one-way protocol. The BMP server sends nothing. In the proposal at hand, the BMP server would send a client-specific TCP_FAST_OPEN cookie (on top of TCP ACKs), and possibly eventually a TCP RST, which is slightly more than 'nothing'... :-) As TCP_FAST_OPEN already is a published RFC, existing BMP clients & servers are free and able to opportunistically use TCP Fast Open. For the sake of conversation I'll consider TCP_FAST_OPEN out-of-scope for BMP and GROW in the rest this email. BMP - one way protocol on reliable transport: are successive RSTs a signal? =========================================================================== In a one-way protocol where the recipient essentially is limited to 'TCP ACK' and 'TCP RST' as response options, would it perhaps make sense to outline a BMP protocol where both BMP client and BMP server assume more delibrate intent from the timing of TCP reconnection events? If the BMP client includes a 'session_id' message as its first message towards the BMP server, then when the client loses its connection to the BMP server, it can continue buffering messages destined for that specific BMP server linked to the previously sent 'session_id'. Then, if the BMP client manages to reconnect to the BMP server within 60 seconds, the client will flush all buffered messages associated with the session_id also communicated in prior BMP sessions. However if the BMP server closes the TCP session within that 60 seconds buffer window, a subsequent successful reconnection would result in the BGP client sending a new session_id followed by all 'Peer Up' messages, because the previous BMP session (and buffer) were terminated. The BMP server can immediately disconnect when it receives a BMP session_id it does not recognize (by issuing a TCP RST). When a BMP client receives the 'second' TCP RST within 60 seconds, it can choose to reconnect following an linear backoff model and for the duration of wait periods exceeding 1 minute not bother buffering for 'unreachable' BMP servers. The heuristic is that the BMP client considers the BMP session 'resumed', iff a BMP server doesn't disconnect within 60 seconds. The BMP server can use the session_id as input to its decision process whether to disconnect within 60 seconds or not. Blink once the BMP session survives... blink twice, game over! Kind regards, Job
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
