idnits 2.17.1 draft-msri-grow-bmp-compression-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 15, 2019) is 1654 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) == Outdated reference: A later version (-13) exists of draft-ietf-grow-bmp-local-rib-05 == Outdated reference: A later version (-14) exists of draft-ietf-grow-bmp-tlv-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Srivastava 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track P. Lucente 5 Expires: April 17, 2020 NTT 6 October 15, 2019 8 BMP Compression 9 draft-msri-grow-bmp-compression-00 11 Abstract 13 This document provides specification for an optional compressed BMP 14 Feed from a router to BMP station. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 20 "OPTIONAL" in this document are to be interpreted as described in BCP 21 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 22 appear in all capitals, as shown here. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 17, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Starting Compressor Capability . . . . . . . . . . . . . 3 61 2.2. Compression Information TLV . . . . . . . . . . . . . . . 3 62 2.3. Compressed BMP Messages . . . . . . . . . . . . . . . . . 4 63 2.4. Compressor Overflow . . . . . . . . . . . . . . . . . . . 4 64 2.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 4 65 2.6. Processing of Compressed Route Monitoring messages . . . 5 66 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. BMP Compression Information TLV . . . . . . . . . . . . . 5 69 4.2. BMP Compression Route Monitoring message type . . . . . . 5 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 71 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 The BGP Monitoring Protocol (BMP) allows monitoring of Rib-in RFC7854 77 [RFC7854], Loc-Rib,BGP local-rib [I-D.ietf-grow-bmp-local-rib] and 78 Rib-in and Rib-Out monitoring allows pre-policy and post-policy view 79 of the prefix. Thus, for a scaled setup, with all these kinds of 80 monitoring enabled, BMP will get a lot of back pressure in the 81 protocol as it needs to dump a huge data for its monitored peers, 82 through a single socket towards BMP station. BGP update PDU which is 83 part of the BMP Route-monitoring (RM) message is also increasing. It 84 is no more limited to 4K as noted in draft-ietf-idr-bgp-extended- 85 messages-21. Essentially, BMP is heading towards becoming I/O bound 86 monitoring protocol. This document proposes compression of BMP feed 87 towards BMP station. Compression will ease the pressure on TCP 88 socket between a router and BMP station. Such a scheme would be 89 useful if a route can spare some extra CPU for BMP operation. 91 As it must be obvious, this scheme will require compressor mechanism 92 at the BMP speaking router and a decompressor on the BMP station. 93 The compression mechanism used at the BMP speaking is an 94 implementation specific detail and is beyond the scope of this 95 specification. 97 2. Procedures 99 2.1. Starting Compressor Capability 101 BMP compression feature on the router and BMP decompressor feature on 102 the BMP station has to be present at the same time. Enabling 103 compression feature at router end only will lead to incomprehensible 104 data at the BMP station end. Also same technique should be used to 105 compress and decompress the data on wire. Using different technique 106 to compress and decompress would lead to incomprehensible data at the 107 BMP station end. 109 BMP compression feature on the router and BMP decompressor feature on 110 the BMP station can be enabled via configuraton. Once this feature 111 is enabled between router and BMP station, the monitored router 112 should indicate this to the BMP Station using new Compression 113 Information TLV as described in following section. 115 From that point onwards, the router would send the compressed BMP 116 feed towards BMP station. BMP session needs to be bounced every-time 117 this feature is enabled on a current active BMP session. 119 2.2. Compression Information TLV 121 As noted in RFC7854 [RFC7854], the initiation message provides a 122 means for the monitored router to inform the monitoring station of 123 its vendor specific details. It can carry Information TLVs 124 containing information about the monitored router. 126 The monitored router MUST communicate the compression capability to 127 BMP staton using Compression Information TLV described below. 129 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 130 +-------------------------------+-------------------------------+ 131 | Information Type (2 octets) | Length (2 octets) | 132 +-------------------------------+-------------------------------+ 133 | CM | CMINFO | Reserved | 134 +---------------------------------------------------------------+ 136 Figure 1: Compression Information TLV 138 o Type = TDB1 (2 Octets): Compression Information TLV type. 140 o Length (2 Octets): indicates the length of the value field of the 141 Compression Information TLV. The value field further consists of 142 the Compression string. 144 o CM (4 bits): CM indicating DEFLATE compressed format value as 145 specified in RFC1950. 147 o CINFO (4 bits): INFO as specified in RFC1950. Invalid values MUST 148 lead to the capability being ignored. The compressing peer MUST 149 use this value for the parametrization of its algorithm. 151 2.3. Compressed BMP Messages 153 Following rules should be following for achieving BMP feed 154 compression: 156 1. A new message type, Compressed Route Monitoring (CRM), MUST be 157 used. This is to ensure backward compatibility with BMP stations 158 that do not support the compression capability. The message type 159 is same in structure as described by TLV support for BMP Route 160 Monitoring and Peer Down Messages [I-D.ietf-grow-bmp-tlv]. 161 Compression is to be applied only to this message type, all other 162 BMP message types shall not be compressed. 164 2. Compression is applicable to all the payload following the Common 165 Header, described in Section 4.1 of [RFC7854]. This allows to 166 read the total BMP message length, i.e. to perform sanity checks 167 against socket and compressor information. 169 3. Each compressed BMP message MUST be sent as a block, i.e. the 170 decompression MUST be able to yield decompressed results of the 171 without waiting for further compressed updates. This is 172 different from the normally used stream compression mode. 174 4. The compressed message MAY exceed the maximum message size but in 175 such case compressor overflow per Section 2.4 MUST be invoked. 177 2.4. Compressor Overflow 179 This should be handled in same was as described in draft-przygienda- 180 idr-compressed-updates [I-D.przygienda-idr-compressed-updates]. 182 2.5. Error Handling 184 If the decompression on the BMP station fails for any reason, it 185 needs to bring down the BMP session. 187 If the compression on the monitoring router fails for any reason, it 188 is at the discretion of the router to handle it. It may try it few 189 more times. In the worse case it MAY bring down the BMP session 191 2.6. Processing of Compressed Route Monitoring messages 193 A BMP station receiving a compressed message SHOULD process it as 194 follows: 196 1. Decode the BMP Common Header where message length is specified 198 2. Decompress remainder of the Compressed Route Monitoring message 199 and determine the decompressed message size from the decompressor 201 3. Decode the BMP Per-peer header 203 4. Decode the BGP UPDATE PDU header to infer the presence of 204 trailing TLVs 206 5. Decode the BMP message TLVs 208 6. Decode the actual BGP UPDATE PDU 210 3. Acknowledgements 212 TBD. 214 4. IANA Considerations 216 This document requests that IANA assign the following new parameters 217 to the BMP parameters name space. 219 4.1. BMP Compression Information TLV 221 This document defines the BMP Compression Information TLV Header with 222 Type = TBD (Section 2.2). 224 4.2. BMP Compression Route Monitoring message type 226 This document also defines the BMP Compressed Route Monitoring 227 message type with Type = TBD (Section 2.3). 229 5. Security Considerations 231 It is not believed that this document adds any additional security 232 considerations. 234 6. Normative References 236 [I-D.ietf-grow-bmp-local-rib] 237 Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente, 238 "Support for Local RIB in BGP Monitoring Protocol (BMP)", 239 draft-ietf-grow-bmp-local-rib-05 (work in progress), 240 August 2019. 242 [I-D.ietf-grow-bmp-tlv] 243 Lucente, P., Gu, Y., and H. Smit, "TLV support for BMP 244 Route Monitoring and Peer Down Messages", draft-ietf-grow- 245 bmp-tlv-01 (work in progress), October 2019. 247 [I-D.przygienda-idr-compressed-updates] 248 Przygienda, T., Lingala, A., Mate, C., and J. Tantsura, 249 "Compressed BGP Update Message", draft-przygienda-idr- 250 compressed-updates-07 (work in progress), August 2019. 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, 254 DOI 10.17487/RFC2119, March 1997, 255 . 257 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 258 Monitoring Protocol (BMP)", RFC 7854, 259 DOI 10.17487/RFC7854, June 2016, 260 . 262 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 263 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 264 May 2017, . 266 Authors' Addresses 268 Mukul Srivastava 269 Juniper Networks 270 10 Technology Park Drive 271 Westford MA 01886 272 USA 274 Email: msri@juniper.net 276 Paolo Lucente 277 NTT 278 Siriusdreef 70-72 279 Hoofddorp, WT 2132 280 Netherlands 282 Email: paolo@ntt.net