idnits 2.17.1 draft-tppy-bmp-seamless-session-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 99: '... BMP application MUST behave during TC...' RFC 2119 keyword, line 125: '...lient and server MUST support TCP Fast...' RFC 2119 keyword, line 129: '... server MUST support TCP Fast Open as described in RFC7413 [RFC7413]...' RFC 2119 keyword, line 130: '...f the BMP server MUST distinguish betw...' RFC 2119 keyword, line 159: '... message type, MUST be buffered. At...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1153 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 109, but not defined == Missing Reference: 'RFC8174' is mentioned on line 109, but not defined ** Downref: Normative reference to an Experimental RFC: RFC 7413 == Outdated reference: A later version (-12) exists of draft-cppy-grow-bmp-path-marking-tlv-07 == Outdated reference: A later version (-13) exists of draft-ietf-grow-bmp-local-rib-09 == Outdated reference: A later version (-08) exists of draft-xu-grow-bmp-route-policy-attr-trace-05 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Graf 3 Internet-Draft Swisscom 4 Intended status: Standards Track P. Lucente 5 Expires: August 26, 2021 NTT 6 P. Francois 7 INSA-Lyon 8 Y. Gu 9 Huawei 10 February 22, 2021 12 BMP (BGP Monitoring Protocol) Seamless Session 13 draft-tppy-bmp-seamless-session-00 15 Abstract 17 This document describes an optional BMP session lifecycle extension 18 to prevent data duplication of previously exported messages when TCP 19 session is re-established. It prevents loss of messages between TCP 20 session re-establishments and increase overall BMP scalability. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 26, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. BMP Client and Server Capability . . . . . . . . . . . . . . 3 60 5. Updated BMP Session Lifecycle . . . . . . . . . . . . . . . . 3 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 7. Operational Considerations . . . . . . . . . . . . . . . . . 4 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 With the constant increase of BGP paths, the increase of BMP BGP RIB 69 coverage from RFC8671 [RFC8671] and draft-ietf-grow-bmp-local-rib 70 [I-D.ietf-grow-bmp-local-rib], the addition of new TLVs such as 71 draft-cppy-grow-bmp-path-marking-tlv 72 [I-D.cppy-grow-bmp-path-marking-tlv] and draft-xu-grow-bmp-route- 73 policy-attr-trace [I-D.xu-grow-bmp-route-policy-attr-trace], more BMP 74 messages and BGP contexts, such as peering, route-policy or RIB, are 75 exported from BMP client to server. 77 With each BMP session re-establishment, clients export the initial 78 BGP RIB via BMP route-monitoring messages as described in section 5 79 of RFC7854 [RFC7854]. Regardless if the same messages were already 80 exported in a previous BMP session or not. This leads to data 81 duplication and unnecessary strain of the BMP client and server. 83 In a network most times BMP sessions are re-established within a 84 short period of time due to connectivity interruption between BMP 85 client and server or restart of the BMP server due to maintenance. 86 Even though most BMP client implementations support a BMP buffering 87 mechanism, messages are not buffered across BMP session re- 88 establishment, thus leading to a loss of messages. 90 Therefore, the proposed BMP session lifecycle improvement covers 92 o Brief loss of connectivity between BMP client and server 94 o Seamless Maintenance of BMP server 95 It is based on RFC7413, TCP Fast Open [RFC7413], which allows 96 previously established TCP transport sessions to be re-established 97 more efficiently. 99 This draft describes how the BMP application MUST behave during TCP 100 transport re-establishment period in order to prevent metric loss. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 3. Definitions 112 Brief loss of connectivity between BMP client and server: Describes 113 a period of time, in seconds, starting from the point in time in 114 which the BMP client detects loss of connectivity to the BMP 115 server and tries to re-establish the TCP session. 117 Maintenance of BMP server: Describes a period of time, in seconds, 118 starting from when the BMP server daemon is restarted for 119 maintenance purposes and the BMP client tries to re-establish 120 the TCP session. 122 4. BMP Client and Server Capability 124 To support brief loss of connectivity between BMP client and server, 125 the BMP client and server MUST support TCP Fast Open as described in 126 RFC7413 [RFC7413]. 128 To support seamless maintenance of a BMP server, the BMP client and 129 server MUST support TCP Fast Open as described in RFC7413 [RFC7413] 130 and the restart of the BMP server MUST distinguish between normal and 131 seamless restart, wherever TCP Fast Open cookies are preserved or 132 not. 134 5. Updated BMP Session Lifecycle 136 Section 3 of RFC7413 [RFC7413] describes the TCP Fast Open extension 137 in the initial TCP SYN packet and the cookie handling during initial 138 and subsequent re-establishment of the TCP transport session. 140 Section 3.3 of RFC7854 [RFC7854] describes that the BMP session 141 closes with the TCP session. This behavior is extended with a 142 configurable BMP session timeout. 144 The BMP session timeout starts counting down under the following 145 conditions: 147 o Configured value is bigger than 0 149 o Current TCP session was established with Fast Open extension and 150 cookie has been saved 152 o BMP buffer is not full 154 o TCP session is going to be terminated 156 The default BMP session timeout is 60 seconds. 158 While the time is counting down, all the BMP messages, regardless of 159 message type, MUST be buffered. At this stage, the BMP session is 160 still considered to be alive. 162 When a TCP session is re-established with TCP Fast Open extension and 163 the cookie is identical to the previous TCP session with the same BMP 164 peer, the BMP session remains alive, BMP buffer is exported and 165 normal operation continues. 167 When a TCP session is re-established without TCP Fast Open extension 168 or with TCP Fast Open extension but the cookie is not identical to 169 the previous TCP session with the same BMP peer, the BMP session is 170 considered terminated and starts with a new BMP Initiation message. 172 When a TCP session is not re-established within the configured 173 timeout, then the BMP buffer is discarded and the BMP session is 174 considered terminated. 176 When the BMP buffer is full before the TCP session is re-established, 177 then the BMP buffer is discarded and the BMP session is considered 178 terminated. 180 6. Security Considerations 182 The same security considerations apply as for TCP Fast Open RFC7413 183 [RFC7413]. 185 7. Operational Considerations 187 From the perspective of the BMP server, the TCP Fast Open mechanism 188 is rather transparent since it is entirely handled by the operating 189 system kernel: this also means a BMP Server application can't 190 determine if the TCP session was established with SYN Cookies or 191 without them. 193 Upon terminating the existing BMP session(s), the BMP server should 194 dump to persistent storage the BGP RIBs currently in memory. In 195 terms of encoding, MRT format could be used for the task (ie. draft- 196 petrie-grow-mrt-bmp) 198 At restart, the BMP server should first restore the content of BGP 199 RIBs from persistent storage before accepting any incoming connection 200 from BMP clients. Only once this process is finished, connections 201 can then be accepted again so that messages buffered by BMP clients 202 are applied to the last known BGP RIBs upon termination. 204 8. References 206 8.1. Normative References 208 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 209 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 210 . 212 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 213 Monitoring Protocol (BMP)", RFC 7854, 214 DOI 10.17487/RFC7854, June 2016, 215 . 217 8.2. Informative References 219 [I-D.cppy-grow-bmp-path-marking-tlv] 220 Cardona, C., Lucente, P., Francois, P., Gu, Y., and T. 221 Graf, "BMP Extension for Path Status TLV", draft-cppy- 222 grow-bmp-path-marking-tlv-07 (work in progress), October 223 2020. 225 [I-D.ietf-grow-bmp-local-rib] 226 Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente, 227 "Support for Local RIB in BGP Monitoring Protocol (BMP)", 228 draft-ietf-grow-bmp-local-rib-09 (work in progress), 229 January 2021. 231 [I-D.xu-grow-bmp-route-policy-attr-trace] 232 Xu, F., Graf, T., Gu, Y., Zhuang, S., and Z. Li, "BGP 233 Route Policy and Attribute Trace Using BMP", draft-xu- 234 grow-bmp-route-policy-attr-trace-05 (work in progress), 235 July 2020. 237 [RFC8671] Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S. 238 Zhuang, "Support for Adj-RIB-Out in the BGP Monitoring 239 Protocol (BMP)", RFC 8671, DOI 10.17487/RFC8671, November 240 2019, . 242 Authors' Addresses 244 Thomas Graf 245 Swisscom 246 Binzring 17 247 Zurich 8045 248 Switzerland 250 Email: thomas.graf@swisscom.com 252 Paolo Lucente 253 NTT 254 Siriusdreef 70-72 255 Hoofddorp, WT 2132 256 Netherlands 258 Email: paolo@ntt.net 260 Pierre Francois 261 INSA-Lyon 262 Lyon 263 France 265 Email: Pierre.Francois@insa-lyon.fr 267 Yunan Gu 268 Huawei 269 Huawei Bld., No.156 Beiqing Rd. 270 Beijing 100095 271 China 273 Email: guyunan@huawei.com