>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 _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
