I've seen this session resumption technique in the '90s. BMP is a one-way protocol. The BMP server sends nothing. Thus adding this is a significant rework of BMP. On the router, it will require remembering all the withdraws that occurred in the BMP serial number window, so that window will need to be limited. If the window exceeds its maximum, then it would still be a hard reset. If we do this, I advocate for a 64 bit serial number.
Regards, Jakob. -----Original Message----- From: GROW <grow-boun...@ietf.org> On Behalf Of Job Snijders Sent: Tuesday, March 9, 2021 4:26 AM To: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org Subject: [GROW] is TCP the right layer for BMP session resumption? Dear group, Yesterday we had the pleasure to hear a report from Thomas Graf on new BMP work. The https://datatracker.ietf.org/doc/html/draft-tppy-bmp-seamless-session-00 document outlines a concept to allow BMP clients to resume 'an existing' session with the BMP server, reducing the need to re-transmit information the client 'already knows'. I informally polled some people with the question 'thoughts on TCP_FAST_OPEN? It was brought to my attention a userspace server daemon is not aware whether a TCP connection was set up with FAST_OPEN or not. Furthermore, TCP_FAST_OPEN's primary use case appears to be to reduce the burden of TCP Three-way handshake on 'short-lived' connections, and was *not* designed for general purpose 'session resumption'. RFC 7413 appears to suggest TCP_FAST_OPEN can be used to jam a 'small' message (like a HTTP 302 response to a GET request) into the SYN-ACK, whereas BMP Session Resumption is not about 'a quick and small reply', but rather "previously there was lots of data, are you aware of that previous data? By the way, what will follow next is lots and lots of more data!". TCP_FAST_OPEN appears a poor fit for the objective of BMP Seamless Session Resumption. If not TCP_FAST_OPEN, then what? ================================ Perhaps inspiration can be taken from RFC 6810's RPKI-To-Router (RTR) protocol which leverages a "Session ID" and "Serial Number" to allow efficient (even transport-protocol agnostic!) session resumption. This same style of session resumption mechanism can also be found in the RPKI Repository Delta Protocol (RRDP). Perhaps BMP would benefit from a similar resumption mechanism to reduce the burden on servers & clients? I welcome insights and feedback from the working group. Kind regards, Job _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
