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 it is not. Here we need to distinguish between BMP application and BMP session. In a previous message to you I wrote: * 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. At BMP IETF hackathon where we BMP/BGP metric loss. As a tester I believe that first we need to describe the problem space carefully. Than analyze where, at which point, the sequence numbers should be applied. And then validate it with running code. Best wishes Thomas From: Jakob Heitz (jheitz) <jhe...@cisco.com> Sent: Thursday, March 11, 2021 11:29 PM To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com>; rainsword.w...@huawei.com; rob...@raszuk.net; j...@dataplane.org Cc: grow@ietf.org Subject: 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 unexpectedly, loss must be assumed unless data integrity can be specifically proven. Regards, Jakob. From: GROW <grow-boun...@ietf.org<mailto:grow-boun...@ietf.org>> On Behalf Of thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> Sent: Thursday, March 11, 2021 4:59 AM To: rainsword.w...@huawei.com<mailto:rainsword.w...@huawei.com>; rob...@raszuk.net<mailto:rob...@raszuk.net>; j...@dataplane.org<mailto:j...@dataplane.org> Cc: grow@ietf.org<mailto:grow@ietf.org> Subject: 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 server OK or not. No. Without draft-tppy-bmp-seamless-session all BMP messages after TCP transport session closes are lost. 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. If TCP session is re-established outside the timeout value or buffer is full, than BMP session is considered new and initial BMP route-monitoring initial RIB dump starts. Under any circumstances, BMP message lost should occur while BMP session is considered to be up. Even during re-establishment window. Does that make sense now? Best wishes Thomas From: Wanghaibo (Rainsword) <rainsword.w...@huawei.com<mailto:rainsword.w...@huawei.com>> Sent: Thursday, March 11, 2021 3:00 AM To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>>; rob...@raszuk.net<mailto:rob...@raszuk.net>; j...@dataplane.org<mailto:j...@dataplane.org> Cc: grow@ietf.org<mailto:grow@ietf.org> Subject: 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 session. And in this scenario, we don't know whether the last message is sent to the server OK or not. If we don't accept this, we should use a mechanisms like sequence no. to ensure that. But it will cause the BMP more complex. Regards, Haibo From: thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> [mailto:thomas.g...@swisscom.com] Sent: Wednesday, March 10, 2021 11:11 PM To: Wanghaibo (Rainsword) <rainsword.w...@huawei.com<mailto:rainsword.w...@huawei.com>>; rob...@raszuk.net<mailto:rob...@raszuk.net>; j...@dataplane.org<mailto:j...@dataplane.org> Cc: grow@ietf.org<mailto:grow@ietf.org> Subject: 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 authors chose a careful way not to re-invent the wheel. Use existing protocols, change as less as possible on the BMP application and preserve the original goal of BMP to be unidirectional. We believe by keeping the session handling on TCP transport, this goal can be best achieved. We are looking forward from the working group to receive feedback if they feel the same way or if the goal should be addressed rather on the application layer. Best wishes Thomas From: Wanghaibo (Rainsword) <rainsword.w...@huawei.com<mailto:rainsword.w...@huawei.com>> Sent: Wednesday, March 10, 2021 12:48 PM To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>>; rob...@raszuk.net<mailto:rob...@raszuk.net>; j...@dataplane.org<mailto:j...@dataplane.org> Cc: grow@ietf.org<mailto:grow@ietf.org> Subject: 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 From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> Sent: Wednesday, March 10, 2021 2:21 PM To: rob...@raszuk.net<mailto:rob...@raszuk.net>; j...@dataplane.org<mailto:j...@dataplane.org> Cc: grow@ietf.org<mailto:grow@ietf.org> Subject: 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 <grow-boun...@ietf.org<mailto:grow-boun...@ietf.org>> On Behalf Of Robert Raszuk Sent: Tuesday, March 9, 2021 10:38 PM To: John Kristoff <j...@dataplane.org<mailto:j...@dataplane.org>> Cc: grow@ietf.org<mailto:grow@ietf.org> grow@ietf.org<mailto:grow@ietf.org> <grow@ietf.org<mailto:grow@ietf.org>> Subject: 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 <j...@dataplane.org<mailto:j...@dataplane.org>> wrote: On Tue, 9 Mar 2021 20:44:18 +0000 "Jakob Heitz \(jheitz\)" <jheitz=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> 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 and flow data. I would have especially liked this after that time a blocked TCP port and the inability to opena TCP connection once caused my BMP monitor router doing the active open to crash (known and now fixed bug). > Thus adding this is a significant rework of BMP. I assume my desire for UDP above will never happen as a result. Oh well. John _______________________________________________ GROW mailing list GROW@ietf.org<mailto:GROW@ietf.org> https://www.ietf.org/mailman/listinfo/grow<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrow&data=04%7C01%7CThomas.Graf%40swisscom.com%7C6cb61add8d894edc4c6808d8e4dd1fe9%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637510985664476602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dSv5IiC%2BWqR44gCcPlr9%2FrYqnZwOCWQr7wx2%2FXe%2FyKY%3D&reserved=0>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
