idnits 2.17.1 draft-xu-grow-bmp-route-policy-attr-trace-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([I-D.ietf-grow-bmp-local-rib], [RFC7854], [I-D.ietf-grow-bmp-adj-rib-out]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2019) is 1875 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: 'RFC4271' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 486, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-grow-bmp-adj-rib-out-03 == Outdated reference: A later version (-13) exists of draft-ietf-grow-bmp-local-rib-02 Summary: 2 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 F. Xu 3 Internet-Draft Tencent 4 Intended status: Standards Track Y. Gu 5 Expires: September 10, 2019 S. Zhuang 6 Z. Li 7 Huawei 8 March 9, 2019 10 BGP Route Policy and Attribute Trace Using BMP 11 draft-xu-grow-bmp-route-policy-attr-trace-00 13 Abstract 15 The generation of BGP adj-rib-in, local-rib or adj-rib-out comes from 16 BGP protocol communication, and route policy processing. BGP 17 Monitoring Protocol (BMP) provides the monitoring of BGP adj-rib-in 18 [RFC7854], BGP local-rib [I-D.ietf-grow-bmp-local-rib] and BGP adj- 19 rib-out [I-D.ietf-grow-bmp-adj-rib-out]. However, there lacks 20 monitoring of how BGP routes are transformed from adj-rib-in into 21 local-rib and then adj-rib-out (i.e., the BGP route policy processing 22 procedures). This document describes a method of using BMP to trace 23 the change of BGP routes in correlation with responsible route 24 policies. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 10, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. BGP Route Policy and Attribute Trace Overview . . . . . . 3 68 1.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Extension of BMP for Route Policy and Attribute Trace . . . . 4 70 2.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 4 71 2.2. Per Peer Header . . . . . . . . . . . . . . . . . . . . . 4 72 2.3. Route Policy and Attribute Trace Message . . . . . . . . 4 73 3. Implementation Example . . . . . . . . . . . . . . . . . . . 7 74 4. Implementation Considerations . . . . . . . . . . . . . . . . 10 75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 8. Normative References . . . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 The typical processing procedure after receiving a BGP Update Message 84 at a routing device is as follows: 1. Adding the pre-policy routes 85 into the pre-policy adj-rib-in (if any); 2. Filtering the pre-policy 86 routes through inbound route policies; 3. Selecting the BGP best 87 routes from the post-policy routes; 4. Adding the selected routes 88 into the BGP local-rib; 5-a. Adding the BGP best routes from local- 89 rib to the core routing table manager for selection; 5-b. Filtering 90 the routes from BGP local-rib through outbound route policies w.r.t. 91 per peer or peer groups; 6. Sending the BGP adj-rib-out to the 92 target peer or peer groups. Details may vary by vendors. The BGP 93 Monitoring Protocol (BMP) can be utilized to monitor BGP routes in 94 forms of adj-rib-in, local-rib and adj-rib-out. However, the 95 complete procedure from inbound to outbound policy processing, 96 including other policies, e.g., route redistribution, route selection 97 and so on, is currently unobserved. For example, there are 10 policy 98 items (or nodes) configured under one outbound route policy per a 99 specific peer. By collecting the local-rib and adj-rib-out through 100 BMP, the operator finds that the outbound policy didn't work as 101 expected. However, it's hard to distinguish which one of the 10 102 policy items/nodes is responsible for the failure. 104 1.1. BGP Route Policy and Attribute Trace Overview 106 This document describes a method that records and reports how each 107 policy item/node processes the routes (e.g., changes the route 108 attribute). Each policy item/node processing is called an event 109 thereafter in this document. Compared with conventional BGP rib 110 entry, which consists of prefix/mask, route attributes, e.g., next 111 hop, MED, local preference, AS path, and so on, the event record 112 discussed in this document includes extra information, such as event 113 index, timestamp, policy information, and so on. For example, if a 114 route is processed by 5 policy items/nodes, there can be 5 event 115 records for the same prefix/mask. Each event is numbered in order of 116 time (e.g., the time of policy execution). The policy information 117 includes the policy name and item/node ID/name so that the server/ 118 controller can map to the exact policy either directly from the 119 device or from the configurations collected at the server side. 121 This document defines a new BMP message type to carry the recorded 122 policy and route data. More detailed message format is defined in 123 Section 2. The message is called the BMP Route Policy and Attribute 124 Trace Message thereafter in this document. 126 1.2. Use cases 128 There are cases that a new policy is configured incorrectly, e.g., 129 setting an incorrect community value, or policy placed in incorrect 130 order among other policies. These may result in incorrect route 131 attribute modification, best route selection mistake, or route 132 distribution mistake. With the correlated record of policy and 133 route, the server/controller is able to identify the unexpected route 134 change and its responsible policy. Considering the fact that the BGP 135 route policy impacts not only the route processing within the 136 individual device but also the route distribution to its peers, the 137 route trace data of a signle device is always analyzed in correlation 138 with such data collected from its peer devices. 140 Apart from the policy validation application, the route trace data 141 can also be analyzed to discover the route propagation path within 142 the network. With the route's inbound and outbound event records 143 collecte from each related device, the server is able to find the 144 propagation path hop by hop. The identified path is helpful for 145 oeprators to better understand its network, and thus benefitting both 146 network troubleshooting and network planning. 148 2. Extension of BMP for Route Policy and Attribute Trace 150 2.1. Common Header 152 This document defines a new BMP message type to carry the Route 153 Policy and Attribute Trace data. 155 o Type = TBD: Route Policy and Attribute Trace Message 157 The new defined message type is indicated in the Message Type field 158 of the BMP common header. 160 2.2. Per Peer Header 162 The Route Policy and Attribute Trace Message is not per peer based, 163 thus it does not require the Per Peer Header. 165 2.3. Route Policy and Attribute Trace Message 167 The Route Policy and Attribute Trace Message format is defined as 168 follows: 170 +---------------------------------------------------------------+ 171 | Prefix length | 172 +---------------------------------------------------------------+ 173 | Prefix | 174 +---------------------------------------------------------------+ 175 | Route Distinguisher | 176 +---------------------------------------------------------------+ 177 | Previous Hop | 178 +---------------------------------------------------------------+ 179 | Event count | 180 +---------------------------------------------------------------+ 181 | Total event length | 182 +---------------------------------------------------------------+ 183 | Single event length (1st event) | 184 +---------------------------------------------------------------+ 185 | Event index | 186 +---------------------------------------------------------------+ 187 | Timestamp(seconds) | 188 +---------------------------------------------------------------+ 189 | Timestamp(microseconds) | 190 +--------------------------------+------------------------------+ 191 | Policy ID | Policy distinguisher | 192 +--------------------------------+------------------------------+ 193 | Peer ID | 194 +---------------------------------------------------------------+ 195 | Peer AS | 196 +---------------------------------------------------------------+ 197 | Peer VRF/Table name | 198 +--------------------------------+------------------------------+ 199 | Peer AFI | Peer SAFI | 200 +--------------------------------+------------------------------+ 201 | Total attribute length | 202 +---------------------------------------------------------------+ 203 | Attribute TLVs | 204 +---------------------------------------------------------------+ 205 ~ ~ 206 + + 207 ~ ~ 208 +---------------------------------------------------------------+ 209 | Single event length (Last event) | 210 +---------------------------------------------------------------+ 211 ~ ~ 212 + + 213 ~ ~ 214 +---------------------------------------------------------------+ 215 | Attribute TLVs | 216 +---------------------------------------------------------------+ 218 Figure 2: Route Policy and Attribute Trace Message format 220 o Prefix Length (1 Byte): indicates the length of the prefix. 222 o Prefix (Variable): indicates the monitored prefix, with the length 223 defined by Prefix Length field. 225 o Route Distinguisher (8 Bytes): If the route is an IPv4 route, this 226 field is zero- filled. If the peer is a VPNv4 route, it is set to 227 the route distinguisher (RD) of the route. 229 o Previous Hop (4 Bytes): indicates the BGP peer ID where this route 230 is learnt from. If the route is locally generated, then field is 231 set to the local BGP router ID (global or VRF specific). 233 o Event Count (1 Byte): indicates the total number of policy 234 processing event recorded in this message. 236 o Total event lenght (1 Byte): indicates the total length of the 237 following fields including all events, where the total number is 238 indicated by the Event Count field. 240 o Single event lenght (1 Byte): indicates the total length of a 241 single policy process event, including the following fields that 242 belong to this event. 244 o Event index (1 Byte): indicates the sequence number of this event, 245 staring from 1 and increases by 1 for each event recorded in 246 order. 248 o Timestamp (4 Bytes): indicates the time when the policy of this 249 event starts excution, expressed in seconds and microseconds since 250 midnight (zero hour), January 1, 1970 (UTC). 252 o Policy ID (Variable): indicates the ID of the route policy of this 253 event, which is user specific or vendor specific. It consists of 254 the Route Policy Name and the Route Policy Item/Node ID. The 255 Policy name and Item/Node ID is in the format of ASCII string, the 256 length of both fields are indicated by the Policy length and Item/ 257 Node length fields, respectively 259 o 261 +-------------------+--------------------+ 262 | Policy length | Policy name | 263 +----------------------------------------+ 264 | Item/node length| Item/Node ID | 265 +----------------------------------------+ 267 o Policy Distinguisher (4 Bits): indicates the category of the 268 policy. Currently 3 policy categories are defined: "0000" 269 indicating the inbound policy, "0001" indicating the outbound 270 policy, "0010" indicating the redistribution policy. More 271 categories to be defined. 273 o Peer ID (4 Bytes): indicates the BGP Peer ID where this policy is 274 configured under. This field is used in combination with the 275 Policy Direction field. If the Policy Direction field is set to 276 "0000", meaning inbound policy, then this field is set to the BGP 277 Peer ID where the route is received from; if the Policy Direction 278 field is set to "0001", meaning outbound policy, then this field 279 is set to the BGP Peer ID where the route is distributed to; If 280 the Policy Direction field is set to "0010", meaning 281 redistribution policy, then this field is set to the local BGP 282 router ID (global or VRF specific). 284 o Peer AS (4 Bytes): indicates the AS number of the BGP Peer that 285 defined the Peer ID field. 287 o VRF/Table name (Variable): indicates the VRF or table name of this 288 route in the format of ASCII string. The string size MUST be 289 within the range of 1 to 255 bytes. The VRF/Table name 290 information varies for the same route under different policy 291 processing event. For example, an IPv4 route is received from a 292 CE router at the PE router through iGBP, an RD is attached to this 293 IPv4 route (under VRF name A) and making it a VPNv4 route, and 294 then this VPNv4 route (under the Global routing table) is 295 distributed to the RR. During this process, the VRF/Table name 296 information changes from VRF A to the Global routing Table name at 297 the inbound and outbound policy process. 299 o AFI/SAFI (2 Bytes): indicates the AFI/SAFI of the route. The AFI/ 300 SAFI information varies for the same route under different policy 301 processing event. For example, an IPv4 route is received from a 302 CE router at the PE router through iGBP, an RD is attached to this 303 IPv4 route and making it a VPNv4 route, and then this VPNv4 route 304 is distributed to the RR. During this process, the AFI 305 information changes from IPv4 to VPNv4 at the inbound and outbound 306 policy process. 308 o Total attribute length (2 Bytes): indicates the total length of 309 the following route attribute TLVs. 311 o Attribute TLVs: include atttributes that are currently carried in 312 BGP Update messages (e.g., Community, Ext-community, Next Hop, AS 313 path, MED...) and those that are not (to be defined). 315 3. Implementation Example 316 +----------+ 317 +------>+BMP server+<-------+ 318 | +--+-------+ | 319 + ^ ^ | 320 Event 1,2,3 +-----+ | + 321 + + + Event 9,10,11 322 | Event 4,5 Event 6,7,8 + 323 | + + | 324 | | | | 325 10.1.1.1/24 ****|****|**********|***********|***** 326 +---------> * | | | | AS0* 327 +-----+ * | | +--+--+ | * 328 | CE1 ++eBGP+ * | +--------->+ RR +------+ | * 329 +-----+ | * | | | ++----+ | | * 330 AS1 | * | | | ^ iBGP | | * 331 | * | | ++----+ | 65000:10 | | * 10.1.1.1/24 332 10.1.1.1/24 +----------> PE2 +---+10.1.1.1/24| | * +-----------> 333 +---------> * | | +-----+ | | * +-----+ 334 +-----+ * | | iBGP | | * +eBGP+>+ CE4 | 335 | CE2 ++eBGP+ * | | iBGP 65000:10 + | * | +-----+ 336 +-----+ | * | +65000:10 10.1.1.1/24 | * | AS4 337 AS2 | * | 10.1.1.1/24 + | * | 338 | * ++----+ +--v-++ * | 339 +-----+ +-----> PE1 | | PE3 +------+ +-----+ 340 | CE3 ++eBGP+-----> +---------------->+ +------+eBGP+>+ CE5 | 341 +-----+ * +-----+ +-----+ * +-----+ 342 10.1.1.1/24 * * 10.1.1.1/24 343 +--------> ************************************** +-----------> 344 AS3 AS5 346 Figure 3: Route Policy and Attribute Trace record implementation example 348 We take the network shown in Figure 2 as an example to show how to 349 use Route Policy and Attribute Trace Messages to recover the 350 footprint of the route propagation. Notice that only basic events 351 required for footprint recovery are listed here. 353 Suppose a prefix 10.1.1.1/24 is sent from both CE2 and CE3 to PE1 354 through eBGP peering, PE1 processes the two Update messages with 355 inbound policies. Such procedure is recorded as two events, namely 356 Event 1 and Event 2. Then PE1 selects the route from CE2 as the best 357 route, add it to VRF 1, and then distribute the VPNv4 route to RR. 358 The distribution procedure is recorded by PE1 as Event 3. As an 359 example, the Route Policy and Attribute Trace Message of Event 1, 2, 360 3 is listed as follows. Only fields related to footprint recovery 361 are listed in the message shown below. Specifically, the Previous 362 Hop information is carried in Event 3 when outbounding the route, 363 indicating that the outbounded route is learnt from CE2. The same 364 prefix is sent from CE1 to PE2, added to VRF 1 and then distributed 365 to RR in the form of VPNv4 route. Two events, Event 4 (inbound) and 366 Event 5 (outbound) are recorded by PE2. Now for RR, prefix 367 10.1.1.1/24 is received from both PE1 and PE2 in the form of VPNv4 368 route. RR selects the route from CE2 as the best route, and 369 distribute it to PE3. Three events, Event 6 (PE2 inbound), Event 7 370 (PE1 inbound), Event 8 (PE3 outbound) are recorded in this case. PE3 371 receives the VPNv4 route from RR, adds it to VRF 1 and then 372 distribute the IPv4 route to CE4 and CE5, respectively. Here, three 373 events are recorded, Event 9 (RR inbound), Event 10 (CE4 outbound) 374 and Event 11 (CE5 outbound). 376 +---------------------------------------------------------------+ 377 | RD: 65000:10 | 378 +---------------------------------------------------------------+ 379 | Prefix: 10.1.1.1/24 | 380 +---------------------------------------------------------------+ 381 | Event 1 | 382 +---------------------------------------------------------------+ 383 | Timestamp 1 | 384 +--------------------------------+------------------------------+ 385 | Policy ID: WC1, node 101 | Inbound policy | 386 +--------------------------------+------------------------------+ 387 | Peer ID: CE1 | 388 +---------------------------------------------------------------+ 389 | Peer AS: AS1 | 390 +---------------------------------------------------------------+ 391 | VRF/Table name: VRF 1 | 392 +---------------------------------------------------------------+ 393 | AFI: IPv4 | 394 +---------------------------------------------------------------+ 395 | Previous Hop: CE1 | 396 +---------------------------------------------------------------+ 397 | Event 2 | 398 +---------------------------------------------------------------+ 399 | Timestamp 2 | 400 +--------------------------------+------------------------------+ 401 | Policy ID: WC1, node 102 | Inbound policy | 402 +--------------------------------+------------------------------+ 403 | Peer ID: CE2 | 404 +---------------------------------------------------------------+ 405 | Peer AS: AS2 | 406 +---------------------------------------------------------------+ 407 | VRF/Table name: VRF 1 | 408 +---------------------------------------------------------------+ 409 | AFI: IPv4 | 410 +---------------------------------------------------------------+ 411 | Previous Hop: CE2 | 412 +---------------------------------------------------------------+ 413 | Event 3 | 414 +---------------------------------------------------------------+ 415 | Timestamp 3 | 416 +--------------------------------+------------------------------+ 417 | Policy ID: RR1, node 103 | Outbound policy | 418 +--------------------------------+------------------------------+ 419 | Peer ID: RR | 420 +---------------------------------------------------------------+ 421 | Peer AS: AS0 | 422 +---------------------------------------------------------------+ 423 | VRF/Table name: VRF 1 | 424 +---------------------------------------------------------------+ 425 | AFI: VPNv4 | 426 +---------------------------------------------------------------+ 427 | Previous Hop: CE1 | 428 +---------------------------------------------------------------+ 430 Figure 4: Event 1,2,3 data partial view 432 The BMP server can use the collected events to recover the route 433 footprint. The key information required from recovery is the 434 Timestamp of each event, and the Previous Hop of the route. The 435 Timestamp allows the server to identify the order of each event, 436 while the Previous Hop information, combined with the outbound peer 437 information, allows the server to recover the route propagation hop 438 by hop. 440 4. Implementation Considerations 442 Considering the data amount of monitoring the route and policy trace 443 of all routes from all BMP clients, the Route Policy and Attribute 444 Trace monitoring MAY be triggered by user at any user-specific time, 445 and MAY be applied to user-specific routes as well as all routes. 446 Successive recored events from one device MAY be encapsulated in one 447 Route Policy and Attribute Trace Message or multiple Route Policy and 448 Attribute Trace Messages per the user configuration. 450 5. Acknowledgements 452 TBD. 454 6. IANA Considerations 456 TBD. 458 7. Security Considerations 460 TBD. 462 8. Normative References 464 [I-D.ietf-grow-bmp-adj-rib-out] 465 Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S. 466 Zhuang, "Support for Adj-RIB-Out in BGP Monitoring 467 Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-03 (work 468 in progress), December 2018. 470 [I-D.ietf-grow-bmp-local-rib] 471 Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente, 472 "Support for Local RIB in BGP Monitoring Protocol (BMP)", 473 draft-ietf-grow-bmp-local-rib-02 (work in progress), 474 September 2018. 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, 478 DOI 10.17487/RFC2119, March 1997, 479 . 481 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 482 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 483 DOI 10.17487/RFC4271, January 2006, 484 . 486 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 487 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 488 2009, . 490 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 491 Monitoring Protocol (BMP)", RFC 7854, 492 DOI 10.17487/RFC7854, June 2016, 493 . 495 Authors' Addresses 497 Feng Xu 498 Tencent 499 Guangzhou 500 China 502 Email: oliverxu@tencent.com 503 Yunan Gu 504 Huawei 505 Huawei Bld., No.156 Beiqing Rd. 506 Beijing 100095 507 China 509 Email: guyunan@huawei.com 511 Shunwan Zhuang 512 Huawei 513 Huawei Bld., No.156 Beiqing Rd. 514 Beijing 100095 515 China 517 Email: zhuangshunwan@huawei.com 519 Zhenbin Li 520 Huawei 521 Huawei Bld., No.156 Beiqing Rd. 522 Beijing 100095 523 China 525 Email: lizhenbin@huawei.com