Hi Jakob, All ack. Perfect. Thanks
Regards, Thomas -----Original Message----- From: Jakob Heitz (jheitz) <jhe...@cisco.com> Sent: Thursday, March 11, 2021 3:17 AM To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com>; 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? For the router, it's not about the time, its about the buffer space. Configure the buffer space allowed to buffer incoming updates during the down time. If the buffer runs out, new sesssion. Regards, Jakob. -----Original Message----- From: thomas.g...@swisscom.com <thomas.g...@swisscom.com> Sent: Wednesday, March 10, 2021 6:56 AM To: Jakob Heitz (jheitz) <jhe...@cisco.com>; 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? Hi Jakob and Job, Ack on all. I would define 60 seconds to be default and configurable. Best wishes Thomas -----Original Message----- From: Jakob Heitz (jheitz) <jhe...@cisco.com> Sent: Wednesday, March 10, 2021 1:12 PM 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? 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
