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 extended with this draft. The BMP session no longer closes with the TCP session. Once the TCP TFO session closes, a BMP session timeout counter starts counting down. If the TCP TFO session is re-established within this time frame, than the BMP session is considered to be "up" during the TCP TFO reestablishment time. The TCP back pressure from BMP monitoring station to the router occurs under congestion. Therefore buffering at the monitored router for the BMP session occurs during normal BMP session lifetime. With draft-tppy-bmp-seamless-session, we make use of this buffer mechanism. Different is that it is being used not only in congestion, but also between re-establishment of the TCP TFO session (not to be confused with the BMP session). As you pointed out, it is important that BMP message type peer_up and peer_down are not being lost during the re-establishment of the TCP TFO session. For that very purpose we described in section 5 that buffering must occur for all BMP message types which is including BMP peer_up, peer_down, statistics, route-mirroring and route-monitoring. I take that as an input to more clearly state that in the draft. Jakob made an interesting input that for BMP buffer optimization purposes only withdrawals of route-monitoring messages should be buffered. I agree that BMP lacks of a mechanism that the monitoring station can request a BMP route-monitoring refresh to the monitored router. I agree as well that if that mechanism would be present, than the BMP session lifecycle should be re-adjusted to disable/enable initial BMP RIB dump with route-monitoring or not. Where I am unsure is wherever it makes sense to implement BMP route-refresh within the BMP session protocol or not. Therefore changing BMP to be a bi-directional protocol. Here I like to get the feedback from the GROW mailing list. If you do see value in BMP route-refresh as well, how granular it should be, and wherever it should be part of the BMP session or not. Best wishes Thomas -----Original Message----- From: Tim Evens (tievens) <tiev...@cisco.com> Sent: Friday, March 12, 2021 10:36 PM To: Graf Thomas, INI-NET-TCZ-ZH1 <thomas.g...@swisscom.com>; Jakob Heitz (jheitz) <jhe...@cisco.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? 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 introduce out-of-order and loss recovery complexities. BGP PDU order is required in order to track changes and to maintain accurate RIB states. While a SEQ number in BMP can help to re-sequence messages, that puts a lot on every BMP receiver/client. For example, BMP receivers will now have to buffer messages and re-sequence them to ensure proper ordering when processing. If buffers are exceeded, what happens to those messages and how would the BMP receiver request those missing messages/pdus? Regardless of how, this adds complexity to both the sender and receiver. IMO, this is not addressing the problem of RIB dumps or picking up where you left off on reconnect. The draft suggests to use TCP_FAST_OPEN, which I believe adds more complexity while not solving the other challenges relating to RIB dumps/refreshes. It doesn't address PEER UP handling on reconnect, how to handle peers that change or are new during the no-connection time, and on how to request a peer refresh when needed. It also doesn't address the buffer exhaustion problem on the sender (router) side. IMO, the sender should be configured using buffer sizes per receiver and not based on time. The amount of time is relative to the number of updates. For example, a refresh to update policies will flood/exhaust buffers quickly in seconds while normal updates may last for minutes without buffer exhaustion. There are at least three problems with RIB dumps/reconnects to be solved: 1) Transient reconnects due to network failures, restarts of receivers, etc. are resulting in unnecessary INITs, RIB dumps, and PEER UPs. A PEER UP normally means that the receiver invalidates all previous RIB entries as it does not know if things were changed/removed during the gap (from last PEER UP/DOWN) period. A RIB dump is expected to refresh the peer RIB upon a PEER UP. IMO, what we need is application level control so the BMP receiver can send a control message to the sender to indicate what's needed per-peer. For example, a receiver restart (new connection) may require a full refresh of PEER UPs and RIB dumps, partial refresh on a subset of peers, only new peers since last reconnect time, and/or no refresh at all for any of the given peers. Unless a refresh/RIB dump is requested or needed, messages should continue where they left off based on buffer allocations (e.g., offsets or similar). IMO, the fast reconnect does not address the set of peers, especially considering the peers that changed during the no-connect period. 2) Regardless of quick restarts or transient network problems, sometimes a RIB dump and PEER UP is not needed. It would be nice to pick up where we left off, if that is possible. This should be per-peer instead of being binary at the session level due chatty peers causing an issue with buffering. This can include use-cases for logging, where the logging process does not actually care for a RIB dump at all. Instead, it only wants new messages starting at BMP receiver connect time (based on peer and afi/safi). 3) BMP receivers (like routers when needing to reapply a policy) sometimes need to get a refresh for a subset of peers. For example, a DB change that results in some peers needing to be added again. Currently, the method to refresh are: a) go to the router and initiate a route-refresh, which is intrusive and requires auth to do this. Not great. b) reset the BMP TCP connection to trigger the router to refresh everything. This is not ideal as there can be hundreds of peers and only a small set needed to be refreshed. IMO, the same solution can be used to solve for all of the above. I would like to see a new BMP message that the receiver sends on initial connect to indicate what's needed. It's important to call out that not all peers (by afi/safi) are equal in terms of buffer exhaustion during connection loss to a receiver. For example, link-state, public/private peering with customers, etc… do not have many updates over several minutes. An all-or-nothing approach based on short-time is not a desired solution (IMO) and leaves many other RIB dump use-cases unaddressed. Thanks, Tim On 3/11/21, 8:45 PM, "GROW" <grow-boun...@ietf.org> wrote: 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 <mailto:grow-boun...@ietf.org> On Behalf Of mailto:thomas.g...@swisscom.com Sent: Thursday, March 11, 2021 4:59 AM To: mailto:rainsword.w...@huawei.com; mailto:rob...@raszuk.net; mailto:j...@dataplane.org Cc: 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) <mailto:rainsword.w...@huawei.com> Sent: Thursday, March 11, 2021 3:00 AM To: Graf Thomas, INI-NET-TCZ-ZH1 <mailto:thomas.g...@swisscom.com>; mailto:rob...@raszuk.net; mailto:j...@dataplane.org Cc: 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: mailto:thomas.g...@swisscom.com [mailto:thomas.g...@swisscom.com] Sent: Wednesday, March 10, 2021 11:11 PM To: Wanghaibo (Rainsword) <mailto:rainsword.w...@huawei.com>; mailto:rob...@raszuk.net; mailto:j...@dataplane.org Cc: 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) <mailto:rainsword.w...@huawei.com> Sent: Wednesday, March 10, 2021 12:48 PM To: Graf Thomas, INI-NET-TCZ-ZH1 <mailto:thomas.g...@swisscom.com>; mailto:rob...@raszuk.net; mailto:j...@dataplane.org Cc: 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 mailto:thomas.g...@swisscom.com Sent: Wednesday, March 10, 2021 2:21 PM To: mailto:rob...@raszuk.net; mailto:j...@dataplane.org Cc: 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 <mailto:grow-boun...@ietf.org> On Behalf Of Robert Raszuk Sent: Tuesday, March 9, 2021 10:38 PM To: John Kristoff <mailto:j...@dataplane.org> Cc: mailto:grow@ietf.org mailto: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 <mailto:j...@dataplane.org> wrote: On Tue, 9 Mar 2021 20:44:18 +0000 "Jakob Heitz \(jheitz\)" <jheitz=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 mailto:GROW@ietf.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrow&data=04%7C01%7CThomas.Graf%40swisscom.com%7C48df4bd0b0554d9b8c1c08d8e59ed35b%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637511817607097850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UMNe3pLj0u1IWLo5SOg%2FmMd%2FMuZW%2FrH0%2FbFWMEemBRU%3D&reserved=0
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
