idnits 2.17.1 draft-xu-grow-bmp-route-policy-attr-trace-03.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. == 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: 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 (November 04, 2019) is 1636 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 585, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 590, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-grow-bmp-local-rib-05 Summary: 1 error (**), 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 T. Graf 5 Expires: May 7, 2020 Swisscom 6 Y. Gu 7 S. Zhuang 8 Z. Li 9 Huawei 10 November 04, 2019 12 BGP Route Policy and Attribute Trace Using BMP 13 draft-xu-grow-bmp-route-policy-attr-trace-03 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 May 7, 2020. 50 Copyright Notice 52 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . 11 79 3. Implementation Considerations . . . . . . . . . . . . . . . . 12 80 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 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 | Route Distinguisher | 177 +---------------------------------------------------------------+ 178 | Prefix length | 179 +---------------------------------------------------------------+ 180 | Prefix | 181 +---------------------------------------------------------------+ 182 | Route Origin | 183 +---------------------------------------------------------------+ 184 | Event count | 185 +---------------------------------------------------------------+ 186 | Total event length | 187 +---------------------------------------------------------------+ 188 | 1st Event | 189 +---------------------------------------------------------------+ 190 | 2nd Event | 191 +---------------------------------------------------------------+ 192 ~ ~ 193 + ...... + 194 ~ ~ 195 +---------------------------------------------------------------+ 196 | Last Event | 197 +---------------------------------------------------------------+ 199 Figure 1: Route Policy and Attribute Trace Message format 201 o Route Distinguisher (8 Bytes): indicates the route distinguisher 202 (RD) related to the route. 204 o Prefix Length (1 Byte): indicates the length of the prefix. 206 o Prefix (Variable): indicates the monitored prefix, with the length 207 defined by Prefix Length field. 209 o Route Origin (4 Bytes): indicates the BGP router ID where this 210 route is learned from. If the route is locally generated, this 211 field is zero filled. 213 o Event Count (1 Byte): indicates the total number of policy 214 processing event recorded in this message. 216 o Total event length (2 Byte): indicates the total length of the 217 following fields including all events, where the total number is 218 indicated by the Event Count field. 220 o 1 ~ Last event: indicates each event, stacked one by one in order 221 of time. The event format is further defined as follows. 223 +---------------------------------------------------------------+ 224 | Single event length | 225 +---------------------------------------------------------------+ 226 | Event index | 227 +---------------------------------------------------------------+ 228 | Timestamp(seconds) | 229 +---------------------------------------------------------------+ 230 | Timestamp(microseconds) | 231 +---------------------------------------------------------------+ 232 | Path Identifier | 233 +---------------------------------------------------------------+ 234 | AFI | 235 +---------------------------------------------------------------+ 236 | SAFI | 237 +---------------------------------------------------------------+ 238 | VRF/Table TLV | 239 +---------------------------------------------------------------+ 240 | Policy TLV | 241 +---------------------------------------------------------------+ 242 | Pre Policy Attribute TLV | 243 +---------------------------------------------------------------+ 244 | Post Policy Attribute TLV | 245 +---------------------------------------------------------------+ 246 | String TLV | 247 +---------------------------------------------------------------+ 249 Figure 2: Event format 251 o Single event length (2 Byte): indicates the total length of a 252 single policy process event, including the following fields that 253 belong to this event. 255 o Event index (1 Byte): indicates the sequence number of this event, 256 staring from 1 and increases by 1 for each event recorded in 257 order. 259 o Timestamp (8 Bytes): indicates the time when the policy of this 260 event starts execution, expressed in seconds and microseconds 261 since midnight (zero hour), January 1, 1970 (UTC). 263 o Path Identifier (4 Bytes): used to distinguish multiple BGP paths 264 for the same prefix. If there's no path ID, this field is zero 265 filled. 267 o AFI (2 Bytes)/SAFI (1 Byte): indicates the AFI/SAFI of the route. 269 o VRF/Table TLV (Variable): indicates the VRFinformation of the 270 route. The format of the VRF/Table TLV is further defined in 271 Figure 3. The VRF/Table TLV is optional. 273 o Policy TLV (Variable): indicates the ID of the route policy of 274 this event, which is user specific or vendor specific, which can 275 be used for mapping to the actual policy content. The policy 276 content data retrieval is out of the scope of this document. The 277 format of the Policy ID TLV is further defined in Figure 4. The 278 Policy ID TLV is optional. 280 o Pre-policy Attribute TLV (Variable): include the BGP route 281 attributes before the policy is executed. The format of the Pre- 282 policy Attribute TLV is further defined in Figure 4. The Pre- 283 policy Attribute TLV is optional. 285 o Post-policy Attribute TLV (Variable): include the BGP route 286 attributes after the policy is executed. The format of the Post- 287 policy Attribute TLV is further defined in Figure 5. The Post- 288 policy Attribute TLV is optional. 290 o String TLV (Variable): leaves for future extension. The String 291 TLV is optional. 293 2.3.1. VRF/Table TLV 295 0 1 2 3 296 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 297 +-------------------------------+-------------------------------+ 298 | Type = TBD1 | Length | 299 +-------------------------------+-------------------------------+ 300 | VRF/Table ID | 301 +---------------------------------------------------------------+ 302 ~ VRF/Table Name ~ 303 | | 304 +---------------------------------------------------------------+ 306 Figure 3: VRF/Table TLV 308 o Type = TBD1 (2 Byte): VRF/Table TLV. 310 o Length (2 Byte): indicates the length of the VRF/Table name field. 312 o VRF/Table ID (4 Bytes): indicates the VRF or table ID of this 313 route. 315 o VRF/Table name (Variable): indicates the VRF or table name of this 316 route in the format of ASCII string. The string size MUST be 317 within the range of 1 to 255 bytes. 319 2.3.2. Policy TLV 321 0 1 2 3 322 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 323 +-------------------------------+-------------------------------+ 324 | Type = TBD2 | Length | 325 +---------------+-------------------------------+---------------+ 326 |M|P|D| Res. | Policy Count | Policy Class. | 327 +---------------+---------------+---------------+---------------+ 328 | Peer Router ID | 329 +---------------------------------------------------------------+ 330 | Peer AS | 331 +---------------------------------------------------------------+ 332 ~ ~ 333 + 1st Policy +---------------+ 334 | |C|R| Res. | 335 +---------------------------------------------------------------+ 336 ~ ~ 337 + + 338 ~ ~ 339 +---------------------------------------------------------------+ 340 ~ ~ 341 + Last Policy +---------------+ 342 | |C|R| Res. | 343 +---------------------------------------------------------------+ 345 Figure 4: Policy TLV 347 o Type = TBD2 (2 Byte): Policy TLV. 349 o Length (2 Byte): indicates the length of the Policy Value field 350 that follows it. The Policy value field includes the reserved 351 Flag Byte, Policy Count field, Policy Classification field, Peer 352 Router ID field, Peer AS field, and each Policy field. 354 o Flag Byte (1 Byte): the M bit (the left most bit) indicates if the 355 route in this event is matched (once or multiple times) or not by 356 any policies. "0" means no match and "1" means else wise. When 357 the M bit is set to "0", the Post Policy Attribute TLV SHALL not 358 be included in the Message. The P bit (the second left bit) 359 indicates if the matched result is Permit or Deny. "0" means Deny, 360 and "1" means Permit. When the M bit is set to "0", any value of 361 the P bit SHOULD be ignored. When the P bit is set to "0", the 362 Post Policy Attribute TLV SHALL not be included in the Message. 364 The D bit (the third left bit) indicates if there exists any 365 difference between the pre-policy attributes and the post policy 366 attributes. "0" means no difference, and "1" means difference 367 exists. When the D bit is set to "0", the Post Policy Attribute 368 TLV SHALL not be included in the Message. 370 o Policy Count (1 Byte): indicates the number of policies (in the 371 format of Policy name + Item ID) carried in this event. 373 o Policy Classification (1 Byte): indicates the category of the 374 policy. Currently 8 policy categories are defined: "00000000" 375 indicates the Inbound policy; "00000001" indicates the Outbound 376 policy; "00000010" indicating the Multi-protocol Redistribute 377 policy (including routes import from other protocols, like ISIS/ 378 OSPF and static routes), "00000011" indicates the Cross-VRF 379 Redistribute policy (route import between VRF and global table and 380 between VRFs); "00000100" indicates VRF Import policy (e.g., an 381 IPv4 route within a VRF transformed from a VPNv4 route), 382 "00000101" indicates VRF Export policy (e.g., a VPNv4 route 383 transformed from an IPv4 route within an VRF); "00000110" 384 indicates the Network policy (BGP network installment and 385 advertisement), "00000111" indicates the Aggregation policy; 386 "00001000" indicating the Route Withdraw (triggered by BGP Update 387 or local actions, e.g., route aggregation). Specifications 388 regarding each category can be included in the String TLV. For 389 the route update, i.e., route creation and withdrawal, that is not 390 processed by any route policy, the Policy Category field is set 391 per the route update point. In addition, the Policy ID field in 392 the Policy ID TLV SHOULD be set to 0. 394 o 396 +---------------------------------------+ 397 | Value |Policy Classification | 398 +---------------------------------------+ 399 | 00000000 | Inbound policy | 400 | 00000001 | Outbound policy | 401 | 00000010 | Multi-protocol Redistribute| 402 | 00000011 | Cross-VRF Redistribute | 403 | 00000100 | VRF import | 404 00000101 | VRF export | 405 | 00000110 | Network | 406 | 00000111 | Aggregation | 407 | 00001000 | Route Withdraw | 408 +----------+----------------------------+ 410 Table 1: Policy Classification 412 o Peer Router ID (4 Bytes): indicates the BGP Router ID where this 413 policy is configured under. This field is used in combination 414 with the Policy Classification field. If the Policy 415 Classification field is set to "00000000", meaning Inbound policy, 416 then this field is set to the BGP router ID where the route is 417 received from; if the Policy Classification field is set to 418 "00000001", meaning Outbound policy, then this field is set to the 419 BGP router ID where the route is distributed to; If the Policy 420 Direction field is set to any other values, then this field is set 421 to all zeros. 423 o Peer AS (4 Bytes): indicates the AS number of the BGP Peer that 424 defined the Peer ID field. 426 o 1st ~ Last Policy (Variable): indicates the Policy name and the 427 Item ID of each policy match. 429 o Flag Byte (1 Byte): the C bit (left most bit) indicates if the 430 next subsequent policy has chaining relationship to the current 431 policy. "1" means it's chaining relationship and "0" means else 432 wise. For the flag byte following the Last Policy field, the C 433 bit SHALL be set to "0". The R bit (second left bit) indicates if 434 the next subsequent policy has recursion to the current policy. 435 "1" means it's recursion and "0" means else wise. For the flag 436 byte following the Last Policy field, the R bit SHALL be set to 437 "0". 439 0 1 2 3 440 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 441 +-------------------------------+-------------------------------+ 442 | Policy Name Length | 443 +-------------------------------+-------------------------------+ 444 ~ Policy Name ~ 445 | | 446 +---------------------------------------------------------------+ 447 | Policy Item ID | 448 +---------------------------------------------------------------+ 450 Figure 5: Policy field format 452 The Policy field consists of the Policy Name (Variable) and the 453 Policy Item ID (4 Bytes). The Policy Name and Policy Item ID fields 454 are in the format of ASCII string. The length of Policy Name is 455 indicated by the Policy Name Length (2 Bytes) field. 457 2.3.3. Pre Policy Attribute TLV 459 0 1 2 3 460 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 461 +-------------------------------+-------------------------------+ 462 | Type = TBD3 | Length | 463 +-------------------------------+-------------------------------+ 464 ~ Pre Policy/Attribute sub TLVs ~ 465 + + 466 +---------------------------------------------------------------+ 468 Figure 6: Pre Policy Attribute TLV 470 o Type = TBD3 (2 Byte): Pre Policy Attribute TLV. 472 o Pre Policy Attribute length (2 Byte): indicates the total length 473 of the following Pre Policy Attribute sub TLVs. 475 o Pre Policy Attribute sub TLVs (Variable): include the BGP route 476 attributes before the policy is executed. 478 2.3.4. Post Policy Attribute TLV 480 0 1 2 3 481 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 482 +-------------------------------+-------------------------------+ 483 | Type = TBD4 | Length | 484 +-------------------------------+-------------------------------+ 485 ~ Post Policy/Attribute sub TLVs ~ 486 + + 487 +---------------------------------------------------------------+ 489 Figure 7: Post Policy Attribute TLV 491 o Type = TBD4 (2 Byte): Pre Policy Attribute TLV. 493 o Pre Policy Attribute length (2 Byte): indicates the total length 494 of the following Pre Policy Attribute sub TLVs. 496 o Pre Policy Attribute sub TLVs (Variable): include the BGP route 497 attributes before the policy is executed. 499 2.3.5. String TLV 500 0 1 2 3 501 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 502 +-------------------------------+-------------------------------+ 503 | Type = TBD5 | Length | 504 +-------------------------------+-------------------------------+ 505 ~ Value ~ 506 + + 507 +---------------------------------------------------------------+ 509 Figure 8: String TLV 511 o Type = TBD5 (2 Byte): String TLV. 513 o Length (2 Byte): indicates the length of the following value 514 field. 516 o Value (Variable): the textual expression of user-specific 517 information in ASCII format. 519 One or more Optional String TLVs can be used. An example of using 520 the String TLV is expressing the route policy xpath information 521 instead of using the Policy TLV. 523 3. Implementation Considerations 525 Considering the data amount of monitoring the route and policy trace 526 of all routes from all BMP clients, users MAY trigger the monitoring 527 at any user-specific time. Users MAY configure locally at the BMP 528 client to monitor only user-specific routes or all the routes. In 529 addition, users MAY configure locally at the BMP client whether to 530 report the TLVs that are optional according to their own 531 requirements, i.e., the Pre Policy Attribute TLV, Post Policy 532 Attribute TLV, Policy ID TLV, and Optional TLV. 534 Successive recored events from one device MAY be encapsulated in one 535 Route Policy and Attribute Trace Message or multiple Route Policy and 536 Attribute Trace Messages per the user configuration. 538 4. Acknowledgments 540 TBD. 542 5. IANA Considerations 544 This document defines the following new BMP Message type 545 (Section 2.1). 547 o Type = TBD: Route Policy and Attribute Trace Message. 549 This document defines the following new TLV types for the Route 550 Policy and Attribute Trace Message (Section 2.3). 552 o Type = TBD1 (2 Byte): VRF/Table TLV. 554 o Type = TBD2 (2 Byte): Policy TLV. 556 o Type = TBD3 (2 Byte): Pre Policy Attribute TLV. 558 o Type = TBD4 (2 Byte): Pre Policy Attribute TLV. 560 o Type = TBD5 (2 Byte): String TLV. 562 6. Security Considerations 564 TBD. 566 7. Normative References 568 [I-D.ietf-grow-bmp-adj-rib-out] 569 Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S. 570 Zhuang, "Support for Adj-RIB-Out in BGP Monitoring 571 Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-07 (work 572 in progress), August 2019. 574 [I-D.ietf-grow-bmp-local-rib] 575 Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente, 576 "Support for Local RIB in BGP Monitoring Protocol (BMP)", 577 draft-ietf-grow-bmp-local-rib-05 (work in progress), 578 August 2019. 580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 581 Requirement Levels", BCP 14, RFC 2119, 582 DOI 10.17487/RFC2119, March 1997, 583 . 585 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 586 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 587 DOI 10.17487/RFC4271, January 2006, 588 . 590 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 591 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 592 2009, . 594 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 595 Monitoring Protocol (BMP)", RFC 7854, 596 DOI 10.17487/RFC7854, June 2016, 597 . 599 Authors' Addresses 601 Feng Xu 602 Tencent 603 Guangzhou 604 China 606 Email: oliverxu@tencent.com 608 Thomas Graf 609 Swisscom 610 Binzring 17 611 Zuerich 8045 612 Switzerland 614 Email: thomas.graf@swisscom.com 616 Yunan Gu 617 Huawei 618 Huawei Bld., No.156 Beiqing Rd. 619 Beijing 100095 620 China 622 Email: guyunan@huawei.com 624 Shunwan Zhuang 625 Huawei 626 Huawei Bld., No.156 Beiqing Rd. 627 Beijing 100095 628 China 630 Email: zhuangshunwan@huawei.com 631 Zhenbin Li 632 Huawei 633 Huawei Bld., No.156 Beiqing Rd. 634 Beijing 100095 635 China 637 Email: lizhenbin@huawei.com