idnits 2.17.1 draft-xu-grow-bmp-route-policy-attr-trace-04.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 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: o Flag Byte (1 Byte): the M bit (the left most bit) indicates if the route in this event is matched (once or multiple times) or not by any policies. "0" means no match and "1" means else wise. When the M bit is set to "0", the Post Policy Attribute TLV SHALL not be included in the Message. The P bit (the second left bit) indicates if the matched result is Permit or Deny. "0" means Deny, and "1" means Permit. When the M bit is set to "0", any value of the P bit SHOULD be ignored. When the P bit is set to "0", the Post Policy Attribute TLV SHALL not be included in the Message. The D bit (the third left bit) indicates if there exists any difference between the pre-policy attributes and the post policy attributes. "0" means no difference, and "1" means difference exists. When the D bit is set to "0", the Post Policy Attribute TLV SHALL not be included in the Message. -- The document date (January 6, 2020) is 1572 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 603, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 608, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-grow-bmp-local-rib-06 Summary: 1 error (**), 0 flaws (~~), 5 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 T. Graf 5 Expires: July 9, 2020 Swisscom 6 Y. Gu 7 S. Zhuang 8 Z. Li 9 Huawei 10 January 6, 2020 12 BGP Route Policy and Attribute Trace Using BMP 13 draft-xu-grow-bmp-route-policy-attr-trace-04 15 Abstract 17 The generation of BGP adj-rib-in, local-rib or adj-rib-out comes from 18 BGP route exchange and route policy processing. BGP Monitoring 19 Protocol (BMP) provides the monitoring of BGP adj-rib-in [RFC7854], 20 BGP local-rib [I-D.ietf-grow-bmp-local-rib] and BGP adj-rib-out 21 [I-D.ietf-grow-bmp-adj-rib-out]. By monitoring these BGP RIB's the 22 full state of the network is visible, but how route-policies affect 23 the route propagation or changes BGP attributes is still not. This 24 document describes a method of using BMP to record the trace data on 25 how BGP routes are (not) changed under the process of route policies. 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 [RFC2119]. 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 July 9, 2020. 50 Copyright Notice 52 Copyright (c) 2020 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 1.1. BGP Route Policy and Attribute Trace Overview . . . . . . 3 69 1.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Extension of BMP for Route Policy and Attribute Trace . . . . 4 71 2.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 4 72 2.2. Per Peer Header . . . . . . . . . . . . . . . . . . . . . 4 73 2.3. Route Policy and Attribute Trace Message . . . . . . . . 4 74 2.3.1. VRF/Table TLV . . . . . . . . . . . . . . . . . . . . 7 75 2.3.2. Policy TLV . . . . . . . . . . . . . . . . . . . . . 8 76 2.3.3. Pre Policy Attribute TLV . . . . . . . . . . . . . . 11 77 2.3.4. Post Policy Attribute TLV . . . . . . . . . . . . . . 11 78 2.3.5. String TLV . . . . . . . . . . . . . . . . . . . . . 12 79 3. Implementation Considerations . . . . . . . . . . . . . . . . 13 80 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 7. Normative References . . . . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 The typical processing procedure after receiving a BGP Update Message 89 at a routing device is as follows: 1. Adding the pre-policy routes 90 into the pre-policy adj-rib-in (if any); 2. Filtering the pre-policy 91 routes through inbound route policies; 3. Selecting the BGP best 92 routes from the post-policy routes; 4. Adding the selected routes 93 into the BGP local-rib; 5-a. Adding the BGP best routes from local- 94 rib to the core routing table manager for selection; 5-b. Filtering 95 the routes from BGP local-rib through outbound route policies w.r.t. 96 per peer or peer groups; 6. Sending the BGP adj-rib-out to the 97 target peer or peer groups. Details may vary by vendors. The BGP 98 Monitoring Protocol (BMP) can be utilized to monitor BGP routes in 99 forms of adj-rib-in, local-rib and adj-rib-out. However, the 100 complete procedure from inbound to outbound policy processing, 101 including other policies, e.g., route redistribution, route selection 102 and so on, is currently unobserved. For example, there are 10 policy 103 items (or nodes) configured under one outbound route policy per a 104 specific peer. By collecting the local-rib and adj-rib-out through 105 BMP, the operator finds that the outbound policy didn't work as 106 expected. However, it's hard to distinguish which one of the 10 107 policy items/nodes is responsible for the failure. 109 1.1. BGP Route Policy and Attribute Trace Overview 111 This document describes a method that records and reports how each 112 policy item/node processes the routes (e.g., changes the route 113 attribute). Each policy item/node processing is called an event 114 thereafter in this document. Compared with conventional BGP rib 115 entry, which consists of prefix/mask, route attributes, e.g., next 116 hop, MED, local preference, AS path, and so on, the event record 117 discussed in this document includes extra information, such as event 118 index, timestamp, policy information, and so on. For example, if a 119 route is processed by 5 policy items/nodes, there can be 5 event 120 records for the same prefix/mask. Each event is numbered in order of 121 time (e.g., the time of policy execution). The policy information 122 includes the policy name and item/node ID/name so that the server/ 123 controller can map to the exact policy either directly from the 124 device or from the configurations collected at the server side. 126 This document defines a new BMP message type to carry the recorded 127 policy and route data. More detailed message format is defined in 128 Section 2. The message is called the BMP Route Policy and Attribute 129 Trace Message thereafter in this document. 131 1.2. Use cases 133 There are cases that a new policy is configured incorrectly, e.g., 134 setting an incorrect community value, or policy placed in incorrect 135 order among other policies. These may result in incorrect route 136 attribute modification, best route selection mistake, or route 137 distribution mistake. With the correlated record of policy and 138 route, the server/controller is able to identify the unexpected route 139 change and its responsible policy. Considering the fact that the BGP 140 route policy impacts not only the route processing within the 141 individual device but also the route distribution to its peers, the 142 route trace data of a single device is always analyzed in correlation 143 with such data collected from its peer devices. 145 Apart from the policy validation application, the route trace data 146 can also be analyzed to discover the route propagation path within 147 the network. With the route's inbound and outbound event records 148 collect from each related device, the server is able to find the 149 propagation path hop by hop. The identified path is helpful for 150 operators to better understand its network, and thus benefiting both 151 network troubleshooting and network planning. 153 2. Extension of BMP for Route Policy and Attribute Trace 155 2.1. Common Header 157 This document defines a new BMP message type to carry the Route 158 Policy and Attribute Trace data. 160 o Type = TBD: Route Policy and Attribute Trace Message 162 The new defined message type is indicated in the Message Type field 163 of the BMP common header. 165 2.2. Per Peer Header 167 The Route Policy and Attribute Trace Message is not per peer based, 168 thus it does not require the Per Peer Header. 170 2.3. Route Policy and Attribute Trace Message 172 The Route Policy and Attribute Trace Message format is defined as 173 follows: 175 +---------------------------------------------------------------+ 176 |V| Reserved | 177 +---------------------------------------------------------------+ 178 | Route Distinguisher | 179 +---------------------------------------------------------------+ 180 | Prefix length | 181 +---------------------------------------------------------------+ 182 | Prefix | 183 +---------------------------------------------------------------+ 184 | Route Origin | 185 +---------------------------------------------------------------+ 186 | Event count | 187 +---------------------------------------------------------------+ 188 | Total event length | 189 +---------------------------------------------------------------+ 190 | 1st Event | 191 +---------------------------------------------------------------+ 192 | 2nd Event | 193 +---------------------------------------------------------------+ 194 ~ ~ 195 + ...... + 196 ~ ~ 197 +---------------------------------------------------------------+ 198 | Last Event | 199 +---------------------------------------------------------------+ 201 Figure 1: Route Policy and Attribute Trace Message format 203 o Flags (1 Byte): The V flag indicates that the Peer address is an 204 IPv6 address. For IPv4 peers, this is set to 0. 206 o Route Distinguisher (8 Bytes): indicates the route distinguisher 207 (RD) related to the route. 209 o Prefix Length (1 Byte): indicates the length of the prefix. 211 o Prefix (16 Bytes): indicates the monitored prefix, with mask 212 defined by Prefix Length field. It is 4 bytes long if an IPv4 213 address is carried in this field (with the 12 most significant 214 bytes zero-filled) and 16 bytes long if an IPv6 address is carried 215 in this field. 217 o Route Origin (4 Bytes): indicates the BGP router ID where this 218 route is learned from. If the route is locally generated, this 219 field is zero filled. 221 o Event Count (1 Byte): indicates the total number of policy 222 processing event recorded in this message. 224 o Total event length (2 Byte): indicates the total length of the 225 following fields including all events, where the total number is 226 indicated by the Event Count field. 228 o 1 ~ Last event: indicates each event, stacked one by one in order 229 of time. The event format is further defined as follows. 231 +---------------------------------------------------------------+ 232 | Single event length | 233 +---------------------------------------------------------------+ 234 | Event index | 235 +---------------------------------------------------------------+ 236 | Timestamp(seconds) | 237 +---------------------------------------------------------------+ 238 | Timestamp(microseconds) | 239 +---------------------------------------------------------------+ 240 | Path Identifier | 241 +---------------------------------------------------------------+ 242 | AFI | 243 +---------------------------------------------------------------+ 244 | SAFI | 245 +---------------------------------------------------------------+ 246 | VRF/Table TLV | 247 +---------------------------------------------------------------+ 248 | Policy TLV | 249 +---------------------------------------------------------------+ 250 | Pre Policy Attribute TLV | 251 +---------------------------------------------------------------+ 252 | Post Policy Attribute TLV | 253 +---------------------------------------------------------------+ 254 | String TLV | 255 +---------------------------------------------------------------+ 257 Figure 2: Event format 259 o Single event length (2 Byte): indicates the total length of a 260 single policy process event, including the following fields that 261 belong to this event. 263 o Event index (1 Byte): indicates the sequence number of this event, 264 staring from 1 and increases by 1 for each event recorded in 265 order. 267 o Timestamp (8 Bytes): indicates the time when the policy of this 268 event starts execution, expressed in seconds and microseconds 269 since midnight (zero hour), January 1, 1970 (UTC). 271 o Path Identifier (4 Bytes): used to distinguish multiple BGP paths 272 for the same prefix. If there's no path ID, this field is zero 273 filled. 275 o AFI (2 Bytes)/SAFI (1 Byte): indicates the AFI/SAFI of the route. 277 o VRF/Table TLV (Variable): indicates the VRFinformation of the 278 route. The format of the VRF/Table TLV is further defined in 279 Figure 3. The VRF/Table TLV is optional. 281 o Policy TLV (Variable): indicates the ID of the route policy of 282 this event, which is user specific or vendor specific, which can 283 be used for mapping to the actual policy content. The policy 284 content data retrieval is out of the scope of this document. The 285 format of the Policy ID TLV is further defined in Figure 4. The 286 Policy ID TLV is optional. 288 o Pre-policy Attribute TLV (Variable): include the BGP route 289 attributes before the policy is executed. The format of the Pre- 290 policy Attribute TLV is further defined in Figure 4. The Pre- 291 policy Attribute TLV is optional. 293 o Post-policy Attribute TLV (Variable): include the BGP route 294 attributes after the policy is executed. The format of the Post- 295 policy Attribute TLV is further defined in Figure 5. The Post- 296 policy Attribute TLV is optional. 298 o String TLV (Variable): leaves for future extension. The String 299 TLV is optional. 301 2.3.1. VRF/Table TLV 303 0 1 2 3 304 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 305 +-------------------------------+-------------------------------+ 306 | Type = TBD1 | Length | 307 +-------------------------------+-------------------------------+ 308 | VRF/Table ID | 309 +---------------------------------------------------------------+ 310 ~ VRF/Table Name ~ 311 | | 312 +---------------------------------------------------------------+ 314 Figure 3: VRF/Table TLV 316 o Type = TBD1 (2 Byte): VRF/Table TLV. 318 o Length (2 Byte): indicates the length of the VRF/Table name field. 320 o VRF/Table ID (4 Bytes): indicates the VRF or table ID of this 321 route. 323 o VRF/Table name (Variable): indicates the VRF or table name of this 324 route in the format of ASCII string. The string size MUST be 325 within the range of 1 to 255 bytes. 327 2.3.2. Policy TLV 329 0 1 2 3 330 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 331 +-------------------------------+-------------------------------+ 332 | Type = TBD2 | Length | 333 +---------------+-------------------------------+---------------+ 334 |M|P|D| Res. | Policy Count | Policy Class. | 335 +---------------+---------------+---------------+---------------+ 336 ~ Peer Address ~ 337 + + 338 +---------------------------------------------------------------+ 339 | Peer Router ID | 340 +---------------------------------------------------------------+ 341 | Peer AS | 342 +---------------------------------------------------------------+ 343 ~ ~ 344 + 1st Policy +---------------+ 345 | |C|R| Res. | 346 +---------------------------------------------------------------+ 347 ~ . ~ 348 + . + 349 ~ . ~ 350 +---------------------------------------------------------------+ 351 ~ ~ 352 + Last Policy +---------------+ 353 | |C|R| Res. | 354 +---------------------------------------------------------------+ 356 Figure 4: Policy TLV 358 o Type = TBD2 (2 Byte): Policy TLV. 360 o Length (2 Byte): indicates the length of the Policy Value field 361 that follows it. The Policy value field includes the reserved 362 Flag Byte, Policy Count field, Policy Classification field, Peer 363 Router ID field, Peer AS field, and each Policy field. 365 o Flag Byte (1 Byte): the M bit (the left most bit) indicates if the 366 route in this event is matched (once or multiple times) or not by 367 any policies. "0" means no match and "1" means else wise. When 368 the M bit is set to "0", the Post Policy Attribute TLV SHALL not 369 be included in the Message. The P bit (the second left bit) 370 indicates if the matched result is Permit or Deny. "0" means Deny, 371 and "1" means Permit. When the M bit is set to "0", any value of 372 the P bit SHOULD be ignored. When the P bit is set to "0", the 373 Post Policy Attribute TLV SHALL not be included in the Message. 374 The D bit (the third left bit) indicates if there exists any 375 difference between the pre-policy attributes and the post policy 376 attributes. "0" means no difference, and "1" means difference 377 exists. When the D bit is set to "0", the Post Policy Attribute 378 TLV SHALL not be included in the Message. 380 o Policy Count (1 Byte): indicates the number of policies (in the 381 format of Policy name + Item ID) carried in this event. 383 o Policy Classification (1 Byte): indicates the category of the 384 policy. Currently 8 policy categories are defined: "00000000" 385 indicates the Inbound policy; "00000001" indicates the Outbound 386 policy; "00000010" indicating the Multi-protocol Redistribute 387 policy (including routes import from other protocols, like ISIS/ 388 OSPF and static routes), "00000011" indicates the Cross-VRF 389 Redistribute policy (route import between VRF and global table and 390 between VRFs); "00000100" indicates VRF Import policy (e.g., an 391 IPv4 route within a VRF transformed from a VPNv4 route), 392 "00000101" indicates VRF Export policy (e.g., a VPNv4 route 393 transformed from an IPv4 route within an VRF); "00000110" 394 indicates the Network policy (BGP network installment and 395 advertisement), "00000111" indicates the Aggregation policy; 396 "00001000" indicating the Route Withdraw (triggered by BGP Update 397 or local actions, e.g., route aggregation). Specifications 398 regarding each category can be included in the String TLV. For 399 the route update, i.e., route creation and withdrawal, that is not 400 processed by any route policy, the Policy Category field is set 401 per the route update point. In addition, the Policy ID field in 402 the Policy ID TLV SHOULD be set to 0. 404 o 405 +---------------------------------------+ 406 | Value |Policy Classification | 407 +---------------------------------------+ 408 | 00000000 | Inbound policy | 409 | 00000001 | Outbound policy | 410 | 00000010 | Multi-protocol Redistribute| 411 | 00000011 | Cross-VRF Redistribute | 412 | 00000100 | VRF import | 413 00000101 | VRF export | 414 | 00000110 | Network | 415 | 00000111 | Aggregation | 416 | 00001000 | Route Withdraw | 417 +----------+----------------------------+ 419 Table 1: Policy Classification 421 o Peer Address: The remote IP address associated with the TCP 422 session over which the encapsulated PDU was received. It is 4 423 bytes long if an IPv4 address is carried in this field (with the 424 12 most significant bytes zero-filled) and 16 bytes long if an 425 IPv6 address is carried in this field. 427 o Peer Router ID (4 Bytes): indicates the BGP Router ID where this 428 policy is configured under. This field is used in combination 429 with the Policy Classification field. If the Policy 430 Classification field is set to "00000000", meaning Inbound policy, 431 then this field is set to the BGP router ID where the route is 432 received from; if the Policy Classification field is set to 433 "00000001", meaning Outbound policy, then this field is set to the 434 BGP router ID where the route is distributed to; If the Policy 435 Direction field is set to any other values, then this field is set 436 to all zeros. 438 o Peer AS (4 Bytes): indicates the AS number of the BGP Peer that 439 defined the Peer ID field. 441 o 1st ~ Last Policy (Variable): indicates the Policy name and the 442 Item ID of each policy match. 444 o Flag Byte (1 Byte): the C bit (left most bit) indicates if the 445 next subsequent policy has chaining relationship to the current 446 policy. "1" means it's chaining relationship and "0" means else 447 wise. For the flag byte following the Last Policy field, the C 448 bit SHALL be set to "0". The R bit (second left bit) indicates if 449 the next subsequent policy has recursion to the current policy. 450 "1" means it's recursion and "0" means else wise. For the flag 451 byte following the Last Policy field, the R bit SHALL be set to 452 "0". 454 0 1 2 3 455 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 456 +-------------------------------+-------------------------------+ 457 | Policy Name Length | Policy Item ID Length | 458 +-------------------------------+-------------------------------+ 459 ~ Policy Name ~ 460 + + 461 +---------------------------------------------------------------+ 462 ~ Policy Item ID ~ 463 + + 464 +---------------------------------------------------------------+ 466 Figure 5: Policy field format 468 The Policy field consists of the Policy Name (Variable) and the 469 Policy Item ID (Variable). The Policy Name and Policy Item ID fields 470 are in the format of ASCII string. The length of Policy Name is 471 indicated by the Policy Name Length (2 Bytes) field. The length of 472 Policy Item ID is indicated by the Policy Item ID Length (2 Bytes) 473 field. 475 2.3.3. Pre Policy Attribute TLV 477 0 1 2 3 478 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 479 +-------------------------------+-------------------------------+ 480 | Type = TBD3 | Length | 481 +-------------------------------+-------------------------------+ 482 ~ Pre Policy/Attribute sub TLVs ~ 483 + + 484 +---------------------------------------------------------------+ 486 Figure 6: Pre Policy Attribute TLV 488 o Type = TBD3 (2 Byte): Pre Policy Attribute TLV. 490 o Pre Policy Attribute length (2 Byte): indicates the total length 491 of the following Pre Policy Attribute sub TLVs. 493 o Pre Policy Attribute sub TLVs (Variable): include the BGP route 494 attributes before the policy is executed. 496 2.3.4. Post Policy Attribute TLV 497 0 1 2 3 498 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 499 +-------------------------------+-------------------------------+ 500 | Type = TBD4 | Length | 501 +-------------------------------+-------------------------------+ 502 ~ Post Policy/Attribute sub TLVs ~ 503 + + 504 +---------------------------------------------------------------+ 506 Figure 7: Post Policy Attribute TLV 508 o Type = TBD4 (2 Byte): Post Policy Attribute TLV. 510 o Pre Policy Attribute length (2 Byte): indicates the total length 511 of the following Pre Policy Attribute sub TLVs. 513 o Pre Policy Attribute sub TLVs (Variable): include the BGP route 514 attributes before the policy is executed. 516 2.3.5. String TLV 518 0 1 2 3 519 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 520 +-------------------------------+-------------------------------+ 521 | Type = TBD5 | Length | 522 +-------------------------------+-------------------------------+ 523 ~ Value ~ 524 + + 525 +---------------------------------------------------------------+ 527 Figure 8: String TLV 529 o Type = TBD5 (2 Byte): String TLV. 531 o Length (2 Byte): indicates the length of the following value 532 field. 534 o Value (Variable): the textual expression of user-specific 535 information in ASCII format. 537 One or more Optional String TLVs can be used. An example of using 538 the String TLV is expressing the route policy xpath information 539 instead of using the Policy TLV. 541 3. Implementation Considerations 543 Considering the data amount of monitoring the route and policy trace 544 of all routes from all BMP clients, users MAY trigger the monitoring 545 at any user-specific time. Users MAY configure locally at the BMP 546 client to monitor only user-specific routes or all the routes. In 547 addition, users MAY configure locally at the BMP client whether to 548 report the TLVs that are optional according to their own 549 requirements, i.e., the Pre Policy Attribute TLV, Post Policy 550 Attribute TLV, Policy ID TLV, and Optional TLV. 552 Successive recored events from one device MAY be encapsulated in one 553 Route Policy and Attribute Trace Message or multiple Route Policy and 554 Attribute Trace Messages per the user configuration. 556 4. Acknowledgments 558 TBD. 560 5. IANA Considerations 562 This document defines the following new BMP Message type 563 (Section 2.1). 565 o Type = TBD: Route Policy and Attribute Trace Message. 567 This document defines the following new TLV types for the Route 568 Policy and Attribute Trace Message (Section 2.3). 570 o Type = TBD1 (2 Byte): VRF/Table TLV. 572 o Type = TBD2 (2 Byte): Policy TLV. 574 o Type = TBD3 (2 Byte): Pre Policy Attribute TLV. 576 o Type = TBD4 (2 Byte): Pre Policy Attribute TLV. 578 o Type = TBD5 (2 Byte): String TLV. 580 6. Security Considerations 582 TBD. 584 7. Normative References 586 [I-D.ietf-grow-bmp-adj-rib-out] 587 Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S. 588 Zhuang, "Support for Adj-RIB-Out in BGP Monitoring 589 Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-07 (work 590 in progress), August 2019. 592 [I-D.ietf-grow-bmp-local-rib] 593 Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente, 594 "Support for Local RIB in BGP Monitoring Protocol (BMP)", 595 draft-ietf-grow-bmp-local-rib-06 (work in progress), 596 November 2019. 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, 600 DOI 10.17487/RFC2119, March 1997, 601 . 603 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 604 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 605 DOI 10.17487/RFC4271, January 2006, 606 . 608 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 609 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 610 2009, . 612 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 613 Monitoring Protocol (BMP)", RFC 7854, 614 DOI 10.17487/RFC7854, June 2016, 615 . 617 Authors' Addresses 619 Feng Xu 620 Tencent 621 Guangzhou 622 China 624 Email: oliverxu@tencent.com 626 Thomas Graf 627 Swisscom 628 Binzring 17 629 Zuerich 8045 630 Switzerland 632 Email: thomas.graf@swisscom.com 633 Yunan Gu 634 Huawei 635 Huawei Bld., No.156 Beiqing Rd. 636 Beijing 100095 637 China 639 Email: guyunan@huawei.com 641 Shunwan Zhuang 642 Huawei 643 Huawei Bld., No.156 Beiqing Rd. 644 Beijing 100095 645 China 647 Email: zhuangshunwan@huawei.com 649 Zhenbin Li 650 Huawei 651 Huawei Bld., No.156 Beiqing Rd. 652 Beijing 100095 653 China 655 Email: lizhenbin@huawei.com