idnits 2.17.1 draft-hsmit-bmp-extensible-routemon-msgs-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 date (July 18, 2018) is 2108 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GROW Working Group H. Smit, Ed. 3 Internet-Draft Nokia 4 Intended status: Standards Track July 18, 2018 5 Expires: January 19, 2019 7 BMP Extensible Route-Monitoring Messages 8 draft-hsmit-bmp-extensible-routemon-msgs-00 10 Abstract 12 The BGP Monitoring Protocol (BMP) is defined in RFC7854. Most of the 13 types of messages in BMP are extensible via the mechanism of TLVs. 14 However, the most important type of message, the route-monitoring 15 message, has a fixed format. 17 This document proposes a relatively small change to the format of BMP 18 route-monitoring messages. The new format of route-monitoring 19 messages is no longer fixed-format, but tlv-encoded. This document 20 also proposes to split the route-monitoring message-type into 3 new 21 message-types. For Adj-RIB-In, Adj-RIB-Out and Loc-RIB. 23 This document proposes two types of TLVs to be used in this new 24 format. A TLV to report the BGP update message itself. And a flags- 25 field TLV, to report state of the reported routes. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [1]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 19, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Limitations of the current route-monitoring message format . 3 69 3. Proposed changes . . . . . . . . . . . . . . . . . . . . . . 4 70 4. New Message-types . . . . . . . . . . . . . . . . . . . . . . 5 71 5. TLV-encoding . . . . . . . . . . . . . . . . . . . . . . . . 5 72 6. BGP Update Message TLV . . . . . . . . . . . . . . . . . . . 6 73 7. Flags-field TLV . . . . . . . . . . . . . . . . . . . . . . . 6 74 7.1. Two flags per piece of state . . . . . . . . . . . . . . 6 75 7.2. Proposed flags in the flag-field TLV . . . . . . . . . . 7 76 7.3. Reporting state in the flags-field TLV that is already 77 known . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 8. Example of layout of a tlv-encoded BMP route-monitoring 79 message . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 82 11. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 9 83 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 86 13.2. Informative References . . . . . . . . . . . . . . . . . 9 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 89 1. Introduction 91 The BGP Monitoring Protocol (BMP) is defined in RFC 7854 [2]. One of 92 the message-types is the Route-Monitoring message. The route- 93 monitoring message consists of: 95 o generic bmp header 97 o per-peer bmp header 98 o a full BGP update message 100 This means that route-monitoring messages have a fixed format. This 101 brings some limitations to the BMP protocol regarding extensibility. 102 Many protocols use a tlv-encoding for the format of their messages. 103 IS-IS is a prime example. But also BGP itself uses a form of tlv- 104 encoding, namely when encoding path-attributes. 106 BMP also uses TLVs, but not for all message. Initiation, 107 termination, peer-up and peer-down messages all use tlv-encoding. 108 Stats-messages consists of counters, where those counters are tlv- 109 encoded. But the route-monitoring messages are not tlv-encoded. 110 This document proposes a new format for BMP Adj-RIB-In route- 111 monitoring messages, which uses tlv-encoding. 113 There are currently two other proposals to enhance BMP. The original 114 BMP specification in RFC7854 defines how a router can report incoming 115 BGP routes (Adj-RIB-In) to a BMP collector. One draft describes a 116 new proposal how to report outgoing routes (Adj-RIB-Out) [4]. A 117 second draft proposes how to report routes that are in BGP's own RIB 118 (Loc-RIB) [3]. This document proposes to use 2 more new message- 119 types to report these Adj-RIB-Out and Loc-RIB routes. 121 This document does not propose any changes to BMP messages other than 122 route-monitoring messages. 124 2. Limitations of the current route-monitoring message format 126 There are a few short-comings with the current format of Route- 127 Monitoring messages. These short-comings also apply to the new 128 formats proposed in the Adj-RIB-Out and Loc-RIB drafts. 130 1) The format of route-monitoring message is fixed. This prevents 131 us from adding more information to each reported route. This 132 extra information can be simple state in the form of a simple bit. 133 Examples of this are whether a route: 135 * route has passed a policy or filter or not, 137 * route has won BGP's best path selection for that NLRI or not 139 * route is installed in the global routing table or not 141 * route has a valid next-hop or not 142 More elaborate state can also be reported together with the route 143 itself. E.g.: 145 * if a route was rejected because of a policy or filter, BMP 146 could report why the route was rejected. E.g. it could report 147 the policy's name or identifier, and the line-number or entry- 148 number that caused the route to be rejected. 150 * if a route did not win best-path selection, BMP could report 151 why it didn't win. E.g. this route had a longer as-path, a 152 lower local-preference, or it lost because the IGP cost to the 153 next-hop is higher. 155 2) Some state of a route is reported in BMP's per-peer header. 156 One would expect that the per-peer header would hold state about 157 the peer itself. E.g. whether the peer's ip-address is IPv4 or 158 IPv6. Not how a BGP update-message is encoded (with 4-byte ASNs) 159 or whether the attributes of a route are pre-policy or post- 160 policy. But the real limitation is that the per-peer header has 161 only 8 bits in its flags-field. There is only a limited amount of 162 state we can store in those 8 bits. And half of them are used up 163 already. 165 3) The route-monitoring message is overloaded. We use it for 166 routes from the Adj-RIB-In, Adj-RIB-Out and Loc-RIB. E.g. to 167 determine that a route-monitoring message holds a route in the 168 Loc-RIB, the peer-type in the per-peer header is set to a special 169 value (TBD), and a number of fields are set blank. This means 170 that the BMP collector now knows which route is in the BGP-Loc- 171 RIB, but it still doesn't know where that route came from. 172 Putting all three different types of routes in the same message- 173 type will make it harder to deal with them, when these types of 174 routes require different treatment. 176 3. Proposed changes 178 1) Define a new tlv-based encoding for route-monitoring messages. 179 This means that the encoding is not backwards compatible with the old 180 fixed-format encoding. Therefor we need to define a new message- 181 type. 183 2) When we are defining a new message-type for Adj-RIB-In messages, 184 we can just as well define 3 different message-types: one for Adj- 185 RIB-In messages, one for Adj-RIB-Out messages, and one for Loc-RIB 186 messages. 188 3) There must be a TLV that holds the original content of a route- 189 monitoring message: namely the original BGP update message itself. 191 4) This document proposes another new TLV, namely the flags-field 192 TLV. The flags-field TLV consists of a variable number of bits, 193 where each bit represents some state of that route. The flags-field 194 TLV is variable in length. Therefor we can add state in the future, 195 almost indefinitely. 197 4. New Message-types 199 We need 3 new message-types. For Adj-RIB-In, Adj-RIB-Out and Loc-RIB 200 routes. The old route-monitoring message (type 0) can be deprecated 201 over time. The new values are TBD. But obvious values would be 7 202 (Adj-RIB-In), 8 (Adj-RIB-Out) and 9 (Loc-RIB). 204 In the mean time, BMP collectors can accept all 4 message-types. 205 When they receive an old route-monitoring message, they know the 206 content consists of just a BGP update message. So they can parse the 207 message. When a BMP collector receives one of the new 3 message- 208 types, they know the message body consists of TLVs, and they can 209 parse those. Therefor BMP collectors do not require any 210 configuration to deal with routers that do and do not support the new 211 tlv-encoding. Routers will need a configuration options, so that 212 providers can configure their routers to send only type 0 route- 213 monitoring messages to old collectors that do not understand the tlv- 214 encoding (yet). 216 5. TLV-encoding 218 The Adj-RIB-In, Adj-RIB-Out and Loc-RIB route-monitoring messages use 219 tlv-encoding as defined in RFC7854. This means that the body of the 220 route-monitoring message consists of one or more TLVs. A TLV 221 consists of: 223 o 2 octets of TLV-type, 225 o 2 octets of TLV-length, 227 o 0 or more octets of TLV value. 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Type (2 octets) | Length (2 octets) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Value (variable, between, 0 and 65535 octets) | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Figure 1 238 TLVs in the body of a route-monitoring message MAY be sent in any 239 order. At least one TLV MUST be present in the body of the message. 240 Preferably the BGP update message TLV. Sending a flags-field TLV is 241 highly recommended (SHOULD). 243 6. BGP Update Message TLV 245 TLV-type is TBD. Suggest value is 1. 247 The content of the BGP update message TLV is simply a full BGP update 248 message. The content of this TLV should be the same as when a router 249 would send the BGP update message in the old non-tlv-encoded format, 250 as in route-monitoring messages of type 0. The length of the BGP 251 message in the BGP header should be the same as the length of the TLV 252 in the TLV-length field. 254 7. Flags-field TLV 256 TLV-type is TBD. Suggested value is 2. 258 The length of this TLV is 0 more bytes. A BMP collector MUST be 259 prepared to receive a flags-field TLV with any length. When a BMP 260 collector receives more bits in the flags-field TLV than it knows the 261 definition of, it can ignore the additional bits. 263 The flags-field TLV is used in both Adj-RIB-In, Adj-RIB-Out and Loc- 264 RIB messages. The flags keep their meaning between message-types. 265 If a flag does not have any practical meaning for the message-type, 266 it should be ignored. An example of this are the pre-policy and 267 post-policy flags for the Loc-RIB routes. 269 7.1. Two flags per piece of state 271 For most state, the flags-field TLV has 2 bits. One bit to state if 272 something is true, and another bit to state that something is not 273 true. E.g. there are 2 flags to state that a route has won the BGP 274 best-path selection. The reason for this is that when we have 2 275 bits, a router can report a state when it knows that state. Or it 276 can decide to not report that state. E.g. because it doesn't know 277 the state (yet). Suppose a router reports an Adj-RIB-In route after 278 it received that route, but before it has ran best-path computation. 279 The 2 flags for best-route can be set to 0. Later, after BGP has run 280 best-path computation for that NLRI, the router can report a Loc-RIB 281 message to the collector, and set one of the two flags indicating 282 whether a route won best-path or not. 284 Having 2 bits per state has the advantage that not all routers are 285 required to support all flags. Unsupported state can always be set 286 to zero. It also allows a router to send all state in a single 287 message, if it can do that. E.g. when a router reports Adj-RIB-In 288 routes after it has run best-path computation and after the BGP route 289 was installed in the global routing table, BMP can report all that 290 state in a single message. 292 7.2. Proposed flags in the flag-field TLV 294 1) path-attributes are pre-policy 296 2) path-attributes are post-policy 298 3) route is valid 300 4) route in invalid (e.g. next-hop is unreachable) 302 5) route is accepted by policy 304 6) route is rejected by policy 306 7) route is best BGP route after best-path selection 308 8) route is not best BGP route after best-path selection 310 9) route is installed in global (or VRF's) routing table 312 10) route is not installed in global routing table 314 11) as-path is in 4-byte ASN notation 316 12) unused 318 13) NLRI have path-id (add-paths) 320 14) NLRI do not have path-id (add-paths) 322 15) route in global routing table is used/best 323 16) route in global routing table is not used/not best 325 The exact meaning of each flag needs further discussion. More flags 326 can be added to this document, if necessary. Or added later, as part 327 of future extensions of the BMP protocol. 329 7.3. Reporting state in the flags-field TLV that is already known 331 This document proposes some flags in the flags-field TLV that are not 332 absolutely necessary. E.g. there are 2 flags to indicate whether 333 NLRI in the BGP update message are encoding with a path-id (add- 334 paths). 336 A BMP collector can know this already, when it has kept state from 337 the BGP OPEN messages in the BMP peer-up messages. However, this can 338 have practical limitations. Parsing a BMP message now requires 339 state. It would be nice if BMP messages can be parsed without any 340 priory state. E.g. this would make sniffing BMP packets with tools 341 like tcpdump or WireShark a lot easier. 343 RFC7854 has a single bit to indicate whether a reported route has 344 pre-policy or post-policy attributes with the route. This document 345 proposes to use 2 bits. This way a router can report both pre-policy 346 and post-policy routes in a single BMP message, if the attributes are 347 unchanged by policy. 349 8. Example of layout of a tlv-encoded BMP route-monitoring message 351 A BMP Adj-RIB-In route-monitoring message can look like: 353 o generic bmp header, 6 bytes 355 o per-peer bmp header, 42 bytes 357 o tlv-header, type = BGP update message TLV 359 o tlv-content: bgp update message, including bgp header and marker 361 o tvl-header, type = Flags-field TLV, length is 2 363 o tlv-content: 16 bits of flags 365 o potentially more TLVs, to be defined in future drafts 367 9. Security Considerations 369 This draft has no implications on the security aspect of BMP 371 10. Acknowledgements 373 The author would like to express thanks to Alejandro Ayala and Gunter 374 Van De Velde for their suggestions and comments. 376 11. Contributor Addresses 378 Below is a list of other contributing authors in alphabetical order: 380 Figure 2 382 12. IANA Considerations 384 This document requests three new message-types in BMP. 386 This document creates a new list of TLVs to be used in the three new 387 route-monitoring messages 389 This document defines an extensible TLV, called the Flags-field TLV. 390 New meaning to bits in the Flags-field TLV can be assigned in the 391 future. 393 13. References 395 13.1. Normative References 397 [1] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997, 399 . 401 [2] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 402 Monitoring Protocol (BMP)", RFC 7854, 403 DOI 10.17487/RFC7854, June 2016, 404 . 406 13.2. Informative References 408 [3] Evens, T., Bayraktar, S., and P. Lucente, "Support for 409 Local RIB in BGP Monitoring Protocol (BMP)", February 410 2018. 412 [4] Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S. 413 Zhuang, "Support for Adj-RIB-Out in BGP Monitoring 414 Protocol (BMP)", March 2018. 416 Author's Address 418 Henk Smit (editor) 419 Nokia 420 Antwerp 421 Belgium 423 Email: henk_hw.smit@nokia.com