idnits 2.17.00 (12 Aug 2021) /tmp/idnits13609/draft-raszuk-idr-bgp-pr-05.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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 31, 2016) is 2174 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) == Unused Reference: 'RFC4223' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 433, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4223 == Outdated reference: A later version (-02) exists of draft-litkowski-idr-bgp-timestamp-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group R. Raszuk, Ed. 3 Internet-Draft Bloomberg LP 4 Intended status: Standards Track R. White 5 Expires: December 2, 2016 Ericsson 6 J. Dong 7 Huawei Technologies 8 May 31, 2016 10 BGP Path Record Attribute 11 draft-raszuk-idr-bgp-pr-05 13 Abstract 15 The BGP protocol contains number of built in mechanisms which records 16 information about the routers which have processed a specific piece 17 of reachability information critical to insuring only loop free paths 18 are chosen by the protocol. For instance, the AS_PATH, CLUSTER_LIST 19 and ORIGINATOR_ID attributes carry information designed to insure 20 permanent routing loops are not formed in the path chosen towards a 21 particular destination. However, there are no provisions to record 22 other useful information along the path, metadata about the routers 23 through which reachability information has passed which can be 24 helpful to the operator in order to enhance end to end visibility of 25 the BGP control plane. 27 In order to solve this problem this document proposes a new single 28 BGP attribute designed as an generic and extensible container to 29 carry number of new optional information corresponding to the BGP 30 speakers given BGP advertisement (or withdraw) message traverses. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 2, 2016. 55 Copyright Notice 57 Copyright (c) 2016 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 3 74 2.1. BGP Path Record Attribute . . . . . . . . . . . . . . . . 3 75 2.2. BGP Per Hop TLV . . . . . . . . . . . . . . . . . . . . . 4 76 2.2.1. Host Name sub-TLV . . . . . . . . . . . . . . . . . . 6 77 2.2.2. Time Stamp sub-TLV . . . . . . . . . . . . . . . . . 6 78 2.2.3. Next hop record sub-TLV . . . . . . . . . . . . . . . 6 79 2.2.4. Path count sub-TLV . . . . . . . . . . . . . . . . . 7 80 2.2.5. Origin Validation sub-TLV . . . . . . . . . . . . . . 7 81 2.2.6. Geo-location sub-TLV . . . . . . . . . . . . . . . . 7 82 2.2.7. BGP System Load sub-TLV . . . . . . . . . . . . . . . 8 83 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 4. Deployment considerations . . . . . . . . . . . . . . . . . . 9 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 86 6. Security considerations . . . . . . . . . . . . . . . . . . . 10 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 89 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 90 8.2. Informative References . . . . . . . . . . . . . . . . . 10 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 93 1. Introduction 95 The ability to record various information from the midpoints through 96 which given control plane information traverses seems would be a 97 useful tool in number of control plane protocols. For some use cases 98 such information is critical and mandatory for correct operation 99 while in other use cases this information could be used for further 100 processing on or off line. 102 Recently there have been two proposals discussing the need to carry 103 opaque operational data in BGP Attributes proposed for such purposes. 104 As it seems that there can be many more types of such data it will be 105 more efficient to define a single TLV based placeholder to carry all 106 optional hop parameters along the path given BGP prefix traverses in 107 the network. 109 To facilitate the transport of information that may be used within a 110 BGP network, but is generally opaque to BGP processes, this document 111 proposes the definition of new a BGP attribute called the BGP Path 112 Record Attribute which can be used to to carry such new optional 113 information. This attribute is formatted to allow the inclusion of 114 information of significance only to the local network operator 115 (within the autonomous system). 117 2. Protocol Extensions 119 This document describes a new BGP attribute known as BGP Path Record 120 Attribute which includes a new TLV and a number of sub-TLVs which can 121 be used to carry new types of information. Several types of 122 information are defined in this document, and several others have 123 been defined in other drafts but included here, as well. The TLV is 124 designed for easy extensibility as well as to accomodate the addition 125 of information by each BGP speaker through within a path. 127 The TLVs are appended by each participating BGP speaker in the order 128 in which the BGP speaker handles the data; hence the order of the 129 TLVs and sub-TLVs MUST NOT be changed in local storage or when 130 transmitted between BGP speakers. 132 The sub-TLVs on the other hand allow for very easy definition of new 133 types of data which may be required to be carried both within this 134 document as well as by new subsequent documents. 136 2.1. BGP Path Record Attribute 138 The BGP Path Record attribute is a new BGP optional transitive 139 attribute. The attribute type code for the Path Record attribute is 140 to be assigned by IANA. The value field of the Path Record attribute 141 is defined as a set of one or more Path Record TLVs along with their 142 sub-TLVs. 144 2.2. BGP Per Hop TLV 146 The BGP Per Hop TLV is defined as follows: 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | TYPE | LENGTH | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | BGP ROUTER ID | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | AS NUMBER | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | FLAGS | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 ~ sub-TLVs ~ 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 Figure 1: BGP Per Hop Type 1 TLV 164 TYPE: Two octets encoding the Path Record TLV Type. Each distinct 165 type of Path record TLV is assigned a unique identifier as noted in 166 this draft. Further identifiers should be assigned through the 167 creation of a new IANA registry and be assigned on a "first come 168 first served" basis. Type 1 TLV is called BGP Hop TLV 170 LENGTH: Two octets encoding the length in octets of the Path Record 171 TLV, excluding the type and length fields. The Length is encoded as 172 an unsigned binary integer. 174 BGP ROUTER ID (4 octets): 4 octet BGP router ID assigned to a given 175 BGP speaker processing prefix with path containing BGP Path Record 176 Attribute. 178 AS NUMBER (4 octets): 4 octet AS number or zero padded 2 octet AS 179 number of the autonomous system BGP Hop belongs to. 181 FLAGS: Number of boolean flags describing BGP Hop basic 182 characteristics. The following flags are defined for BGP Hop TLV: 184 Bit 0: 186 NH - Next Hop - Values: 0 - next hop not set; 1 - next hop set 187 Bit 1: 188 RR - Route Reflector - Values: 0 - not a route reflector; 1 - 189 route reflector 190 Bit 2: 191 RS - Route Server - Values: 0 - not route server; 1 - route 192 server 193 Bit 3: 194 B - Beacon prefix - Values: 0 - not a special beacon prefix; 1 195 - special beacon prefix 196 Bits 4-31: 197 Reserved for future use 199 sub-TLVs: Variable length sub-TLVs describing various information 200 pertaining to the TLV they are nested under. The general format of a 201 sub-TLV is illustrated below: 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | TYPE | LENGTH | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 ~ VALUE ~ 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Figure 2: sub-TLV format 213 TYPE (2 octets): The sub-TLV type used to differentiate information 214 types carried in the context of given TLV. 216 LENGTH (2 octets): The length in octets of the sub-TLV, excluding the 217 type and length fields. The Length is encoded as an unsigned binary 218 integer. 220 VALUE: Variable length field described in the context of each sub- 221 TLV. 223 The following optional sub-TLVs are proposed in this document to be 224 carried under BGP Hop TLV: 226 o Type 1 - Host Name sub-TLV 227 o Type 2 - Time Stamp sub-TLV 228 o Type 3 - Next Hop record sub-TLV 229 o Type 4 - Path Count sub-TLV 230 o Type 5 - Origin Validation sub-TLV 231 o Type 6 - Geo-location sub-TLV 232 o Type 7 - BGP System Load sub-TLV 234 2.2.1. Host Name sub-TLV 236 Type: 237 1 238 Length: 239 Length of sub-TLV in octets. 240 Value: 241 UTF-8 encoded BGP speaker hostname. 242 Description: 243 Useful for enhance display in number of direct or indirect show 244 commands and operational logs. 246 2.2.2. Time Stamp sub-TLV 248 Type: 249 2 250 Length: 251 10 octets 252 Value: 253 8 octets - BGP UPDATE message receive timestamp, 254 1 octet - flags; Bit 0 - T flag (synchronized to external 255 clock) Bits 1-7 - reserved. 256 1 octet - Sync type as described in [RFC5905], 257 Description: 258 For full details of this sub-TLV use case and architecture are 259 described in separate document: 260 [I-D.litkowski-idr-bgp-timestamp] 262 2.2.3. Next hop record sub-TLV 264 Type: 265 3 266 Length: 267 5 octets or 17 octets 268 Flags: 269 Bit 0: Set if next hop is third party next hop Bits 1-7: 270 Reserved 271 Value: 272 IPv4 or IPv6 address of the next hop changed by current BGP Hop 273 Description: 274 For full details of this sub-TLV use case and architecture are 275 described in separate document: 276 [I-D.zhang-idr-nexthop-path-record] 278 2.2.4. Path count sub-TLV 280 Type: 281 4 282 Length: 283 2 octets 284 Value: 285 Integer indicating number of paths present for a given prefix 286 in BGP speaker. 287 Description: 288 Enables easy visibility in validation of expected propagation 289 model for multiple paths of given prefix. Can validate 290 effectiveness of various BGP mechanisms (best-external, bgp 291 diverse path, bgp add-paths etc ...) (TBD .. should we include 292 how many paths are marked as stale ?) 294 2.2.5. Origin Validation sub-TLV 296 Type: 297 5 298 Length: 299 10 octets 300 Value: 301 8 octets - Last time BGP Origin Validation database has been 302 updated. 303 1 octet - flags; Bit 0 - T flag (synchronized to external 304 clock) Bits 1-7 - reserved. 305 1 octet - Sync type as described in [RFC5905], 306 Description: 307 Allows to easily detect issues associated with possible lack of 308 synchronization of Origin Validation local database. 310 2.2.6. Geo-location sub-TLV 312 Type: 313 6 314 Length: 315 16 octets 316 Value: 317 Proposed encoding follows IETF consensus for representation of 318 coordinate based location. 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | LatUnc | Latitude + 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Lat (cont'd) | LongUnc | Longitude + 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Longitude (cont'd) | AType | AltUnc | Altitude + 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Altitude (cont'd) |Ver| Res |Datum| 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 3: Geo-location encoding format 333 Description: 334 Allows to map BGP control plane hops taken by BGP 335 advertisements to two or three dimensional geo location 336 coordinates of participating BGP speakers. Encoding details 337 are described in [RFC6225] (DHCP geo-location options 338 document). 340 2.2.7. BGP System Load sub-TLV 342 Type: 343 7 344 Length: 345 2 octets 346 Value: 347 1 octet - avg last 15 min of CPU utilization in percent by BGP 348 process/thread 349 1 octet - avg last 15 min of BGP process memory use to total 350 available memory use in percent 351 Description: 352 Used as indicator of possible CPU or memory problems of any 353 given participating BGP speaker along the BGP control plane 354 path. To prevent unnecessary churn implementation should only 355 append it upon BGP update generation as well as inserted value 356 should be an avrage over configurable time (default: 15 sec). 358 3. Operation 360 The proposed new BGP Path Record attribute is an opaque entity for 361 BGP operation and as such there is no requirement for any direct 362 modification to BGP operation or BGP state machine based on the 363 information it contains. It is expected that such feedback loop will 364 be performed by operator either by automated or manual process. 366 Operator should be able to allow or deny origination of BGP Path 367 Record attribute or insertion of any TLV or sub-TLV into BGP UPDATE 368 message. It is however recommended that given BGP implementation 369 adds available sub-TLVs to BGP Hop TLV when particular prefix has 370 been received with BGP Path Record Attribute already containing such 371 sub-TLVs. 373 BGP policy should be enhanced to allow for easy filtering of BGP Path 374 Record attribute both on egress as well as ingress eBGP sessions. 376 BGP Path Record attribute can be used within any AFI/SAFI. 378 4. Deployment considerations 380 It needs to be recognized that some sub-TLVs of BGP Hop TLV of BGP 381 Path Record attribute can break update packing. Therefor it is 382 strongly recommended that sub-TLVs type 2, 4, 7 as defined above are 383 to be used only for specific beacon prefixes injected into BGP 384 control plane by operator and flagged with the "B" bit within the 385 originating BGP Hop TLV. 387 Beacon prefixes due to the store-and-forward nature of P2MP BGP 388 distribution for information correctness should be carefully injected 389 and withdrawn from entire network before subsequent injection is to 390 take place again. 392 5. IANA Considerations 394 This document defines a new BGP attribute known as a BGP Path Record 395 Attribute. The code point for a new BGP Path Record attribute has to 396 be assigned by IANA from the BGP Path Attributes registry. 398 This document requests IANA to define and maintain a new registry 399 named: "BGP Path Record Attribute TLV types". The reserved pool of 400 0x0000-0xFFFF has been defined for its allocations. The allocations 401 policy is on a first come first served basis. The recommended 402 allocation of 0x0001 is to be allocated for BGP Hop TLV. 404 This document requests IANA to define and maintain a new registry 405 named: "BGP Hop sub-TLV types". The reserved pool of 0x0000-0xFFFF 406 has been defined for its allocations. The allocations policy is on a 407 first come first served basis. The recommended allocation of first 7 408 sub-TLVs are indicated in section 2.2 titled: BGP Hop TLV. 410 6. Security considerations 412 No new security issues are introduced to the BGP protocol by this 413 specification. 415 7. Acknowledgements 417 Authors would like to acknowledge Stephane Litkowski for his valuable 418 input, review and comments. 420 8. References 422 8.1. Normative References 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, 426 DOI 10.17487/RFC2119, March 1997, 427 . 429 [RFC4223] Savola, P., "Reclassification of RFC 1863 to Historic", 430 RFC 4223, DOI 10.17487/RFC4223, October 2005, 431 . 433 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 434 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 435 DOI 10.17487/RFC4271, January 2006, 436 . 438 8.2. Informative References 440 [I-D.litkowski-idr-bgp-timestamp] 441 Litkowski, S., Patel, K., and J. Haas, "Timestamp support 442 for BGP paths", draft-litkowski-idr-bgp-timestamp-00 (work 443 in progress), July 2014. 445 [I-D.zhang-idr-nexthop-path-record] 446 Li, Z., Zhang, L., and S. Hares, "NEXTHOP_PATH_RECORD 447 ATTIBUTE for BGP", draft-zhang-idr-nexthop-path-record-00 448 (work in progress), July 2014. 450 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 451 "Network Time Protocol Version 4: Protocol and Algorithms 452 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 453 . 455 [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, Ed., 456 "Dynamic Host Configuration Protocol Options for 457 Coordinate-Based Location Configuration Information", 458 RFC 6225, DOI 10.17487/RFC6225, July 2011, 459 . 461 Authors' Addresses 463 Robert Raszuk (editor) 464 Bloomberg LP 465 731 Lexington Ave 466 New York City, NY 10022 467 USA 469 Email: robert@raszuk.net 471 Russ White 472 Ericsson 473 Oak Island, NC 28465 474 USA 476 Email: russw@riw.us 478 Jie Dong 479 Huawei Technologies 480 Huawei Campus, No. 156 Beiqing Rd. 481 Beijing 100095 482 China 484 Email: jie.dong@huawei.com