I would say 60 seconds or until the client runs out of configured buffer space to save messages that need to be sent to the session once the new session comes up.
Regards, Jakob. -----Original Message----- From: Job Snijders <job=40fastly....@dmarc.ietf.org> Sent: Wednesday, March 10, 2021 1:04 AM 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 Wed, Mar 10, 2021 at 03:08:34AM +0000, Jakob Heitz (jheitz) wrote: > >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. In the 'Sent: Tuesday, March 9, 2021 4:50 PM' email sequence/serial numbers are not required, only a 'session id' (which might remain the same over the lifetime of the BMP client's lifetime). A full 'big bang' restart is achieved by the server disconnecting and allowing reconnection twice, within the 60 second window. When combined with TCP_FAST_OPEN resuming a session requires 2 packets (one each way) and restarting a session requires 4 packets. This way BMP remains a 'read only' protocol, but I admit this is an unconventional approach. Kind regards, Job _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
