Re: [GROW] is TCP the right layer for BMP session resumption?

Hi Tim, Many thanks for the feedback and input. Much appreciated. My apology for late reply. In section 5 of draft-tppy-bmp-seamless-session https://tools.ietf.org/html/draft-tppy-bmp-seamless-session-00#section-5 The BMP session lifecycle (not to be confused with TCP session lifecycle) is

Re: [GROW] is TCP the right layer for BMP session resumption?

The use of UDP vs TCP is use-case specific. For example, are you logging and don't care if you miss messages or are you maintaining RIB states for applications like SDN? In terms of accurate logging (ordered regardless of timestamp) and maintaining state… TCP is required otherwise we

Re: [GROW] is TCP the right layer for BMP session resumption?

Hi Jakob, * When processes abort unexpectedly, loss must be assumed unless data integrity can be specifically proven. Absolutely. We need to distinguish between application and transport. At transport we do have sequence numbers and integrity on transport is ensured. On BMP application

Re: [GROW] is TCP the right layer for BMP session resumption?

With draft-tppy-bmp-seamless-session, if TCP session is re-established within the timeout value and buffer is not full, no message lost occurs This is a leap of faith. How can you be sure that the receiver has not lost any messages, even if the TCP session ends in FIN? When processes abort

Re: [GROW] is TCP the right layer for BMP session resumption?

Hi Thomas, Yes, it's clear. Regards, Haibo -- 王海波 Wang Haibo Mobile: +86-13621091983 Email: rainsword.w...@huawei.com 发件人：Thomas.Graf 收件人：Wanghaibo (Rainsword) ;robert ;jtk 抄 送：grow 时 间：2021-03-11

Re: [GROW] is TCP the right layer for BMP session resumption?

Hi Haibo, * Now we want to keep the BMP session active even the TCP session is closed, I think it means the BMP session state separate from the TCP session. For the BMP session closing it is delayed. Yes. * And in this scenario, we don't know whether the last message is sent to the

Re: [GROW] is TCP the right layer for BMP session resumption?

Hi Jakob, All ack. Perfect. Thanks Regards, Thomas -Original Message- From: Jakob Heitz (jheitz) Sent: Thursday, March 11, 2021 3:17 AM To: Graf Thomas, INI-NET-TCZ-ZH1 ; job=40fastly@dmarc.ietf.org Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org Subject: RE: [GROW]

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 Sent: Wednesday, March 10,

Re: [GROW] is TCP the right layer for BMP session resumption?

Hi Tomas, According to the RFC7854, the BMP session is closely bound to the TCP session. So the BMP session will end when TCP is closed. Now we want to keep the BMP session active even the TCP session is closed, I think it means the BMP session state separate from the TCP

Re: [GROW] is TCP the right layer for BMP session resumption?

Hi Haibo, Quite the contrary. draft-tppy-bmp-seamless-session is not about the separation of the transport session from the BMP session. It is about to delay the termination of the BMP session when transport session is closed and introducing a mechanism to re-establish the BMP session. The

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) Sent: Wednesday, March 10, 2021 1:12 PM To: Job Snijders Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org Subject: RE:

Re: [GROW] is TCP the right layer for BMP session resumption?

Hi Jakob, Thats clear. Apology. I was not precise enough. I would prefer the reliability to be solved on application layer than on transport layer since in a large scale BMP data collection, multiple daemons collect the BMP messages and failover among can occur. Best wishes Thomas From:

Re: [GROW] is TCP the right layer for BMP session resumption?

Hi Jakob, Ack on all. The difference between sequence numbers in TCP transport and BMP application is clear. What I wondered if you could describe a bit more what benefit we would gain with BMP sequence numbers. At which point within the BMP client application loss technically could occur.

Re: [GROW] is TCP the right layer for BMP session resumption?

A primary use-case of the BMP data is to provide information to a route collector/optimizer to determine what feasible paths may be sent to a router by these offline computational systems. This requires a reliable transport where messages are delivered in order. I understand others may be

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 Sent: Wednesday, March 10, 2021 1:04 AM To: Jakob Heitz (jheitz)

Re: [GROW] is TCP the right layer for BMP session resumption?

Hi Tomas, I think the main problem is how to separate the BMP session with the transport session. Even we choose a stateless transport, we also need to use some mechanism to ensure the message is succeed send to the sever, e.g., use sequence number in BMP RM message. Regards, Haibo

Re: [GROW] is TCP the right layer for BMP session resumption?

sed ´s/sensible/sensitive´ In pt_BR both words are "Sensível", and what defines the real meaning is the phrase context. Same with Safety and Security, both are "segurança" in pt_BR. Dã... Sorry! Em qua., 10 de mar. de 2021 às 07:16, Douglas Fischer < fischerdoug...@gmail.com> escreveu: > I'm

Re: [GROW] is TCP the right layer for BMP session resumption?

I'm not sure about what I'm going to say... But. BMP would transfer sensible data. Then some cryptographic layer would be recommended/necessary. Considering that, following on this approach of "fast connection", will not have time/space to negotiate some crypto on those fast reconnections. So I

Re: [GROW] is TCP the right layer for BMP session resumption?

On Wed, Mar 10, 2021 at 03:08:34AM +, 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

Re: [GROW] is TCP the right layer for BMP session resumption?

QUIC is not stateless. BMP over QUIC is not BMP over UDP. BMP requires reliable transfer. The state to provide reliability must exist somewhere. If not in TCP (or QUIC), then in the app. Regards, Jakob. From: GROW On Behalf Of thomas.g...@swisscom.com Sent: Tuesday, March 9, 2021 10:21 PM To:

Re: [GROW] is TCP the right layer for BMP session resumption?

TCP sequence numbers are for TCP only. It would be nice if TCP were to acknowledge received data only after all application layers have fully processed it. However, TCP sequence numbers are only for TCP. The application cannot acknowledge full processing of received data back to TCP through the

Re: [GROW] is TCP the right layer for BMP session resumption?

Hi John and Robert, Speaking as a network operator. I absolutely agree on your thoughts that a stateless transport would be preferred over a stateful. Best wishes Thomas From: GROW On Behalf Of Robert Raszuk Sent: Tuesday, March 9, 2021 10:38 PM To: John Kristoff Cc: grow@ietf.org

Re: [GROW] is TCP the right layer for BMP session resumption?

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

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

Re: [GROW] is TCP the right layer for BMP session resumption?

On Tue, Mar 09, 2021 at 08:44:18PM +, 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

Re: [GROW] is TCP the right layer for BMP session resumption?

I second John's comment with a bit more optimism. As gRPC over QUIC is becoming a reality and de-facto messaging standard there is going to be hardly any choice for any router's vendor to resist to implement it. Best, R. On Tue, Mar 9, 2021 at 9:57 PM John Kristoff wrote: > On Tue, 9 Mar

Re: [GROW] is TCP the right layer for BMP session resumption?

On Tue, 9 Mar 2021 20:44:18 + "Jakob Heitz \(jheitz\)" wrote: > I've seen this session resumption technique in the '90s. > BMP is a one-way protocol. The BMP server sends nothing. I kind of wish my BMP router monitor was able to transport data over UDP to the listening station like syslog

Re: [GROW] is TCP the right layer for BMP session resumption?

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

[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