idnits 2.17.1 draft-xu-grow-bmp-route-policy-attr-trace-01.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 13 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 (July 7, 2019) is 1754 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 852, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 857, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-grow-bmp-adj-rib-out-06 == Outdated reference: A later version (-13) exists of draft-ietf-grow-bmp-local-rib-04 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: January 8, 2020 S. Zhuang 6 Z. Li 7 Huawei 8 July 7, 2019 10 BGP Route Policy and Attribute Trace Using BMP 11 draft-xu-grow-bmp-route-policy-attr-trace-01 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 January 8, 2020. 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 2.3.1. VRF/Table Name TLV . . . . . . . . . . . . . . . . . 8 74 2.3.2. Pre Policy Attribute TLV . . . . . . . . . . . . . . 9 75 2.3.3. Post Policy Attribute TLV . . . . . . . . . . . . . . 9 76 2.3.4. Policy ID TLV . . . . . . . . . . . . . . . . . . . . 10 77 2.3.5. Optional TLV . . . . . . . . . . . . . . . . . . . . 11 78 3. Implementation Considerations . . . . . . . . . . . . . . . . 12 79 4. Implementation Example . . . . . . . . . . . . . . . . . . . 12 80 4.1. Route Distribution Tracking . . . . . . . . . . . . . . . 12 81 4.2. Route Leak Detection . . . . . . . . . . . . . . . . . . 16 82 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 85 8. Normative References . . . . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 88 1. Introduction 90 The typical processing procedure after receiving a BGP Update Message 91 at a routing device is as follows: 1. Adding the pre-policy routes 92 into the pre-policy adj-rib-in (if any); 2. Filtering the pre-policy 93 routes through inbound route policies; 3. Selecting the BGP best 94 routes from the post-policy routes; 4. Adding the selected routes 95 into the BGP local-rib; 5-a. Adding the BGP best routes from local- 96 rib to the core routing table manager for selection; 5-b. Filtering 97 the routes from BGP local-rib through outbound route policies w.r.t. 98 per peer or peer groups; 6. Sending the BGP adj-rib-out to the 99 target peer or peer groups. Details may vary by vendors. The BGP 100 Monitoring Protocol (BMP) can be utilized to monitor BGP routes in 101 forms of adj-rib-in, local-rib and adj-rib-out. However, the 102 complete procedure from inbound to outbound policy processing, 103 including other policies, e.g., route redistribution, route selection 104 and so on, is currently unobserved. For example, there are 10 policy 105 items (or nodes) configured under one outbound route policy per a 106 specific peer. By collecting the local-rib and adj-rib-out through 107 BMP, the operator finds that the outbound policy didn't work as 108 expected. However, it's hard to distinguish which one of the 10 109 policy items/nodes is responsible for the failure. 111 1.1. BGP Route Policy and Attribute Trace Overview 113 This document describes a method that records and reports how each 114 policy item/node processes the routes (e.g., changes the route 115 attribute). Each policy item/node processing is called an event 116 thereafter in this document. Compared with conventional BGP rib 117 entry, which consists of prefix/mask, route attributes, e.g., next 118 hop, MED, local preference, AS path, and so on, the event record 119 discussed in this document includes extra information, such as event 120 index, timestamp, policy information, and so on. For example, if a 121 route is processed by 5 policy items/nodes, there can be 5 event 122 records for the same prefix/mask. Each event is numbered in order of 123 time (e.g., the time of policy execution). The policy information 124 includes the policy name and item/node ID/name so that the server/ 125 controller can map to the exact policy either directly from the 126 device or from the configurations collected at the server side. 128 This document defines a new BMP message type to carry the recorded 129 policy and route data. More detailed message format is defined in 130 Section 2. The message is called the BMP Route Policy and Attribute 131 Trace Message thereafter in this document. 133 1.2. Use cases 135 There are cases that a new policy is configured incorrectly, e.g., 136 setting an incorrect community value, or policy placed in incorrect 137 order among other policies. These may result in incorrect route 138 attribute modification, best route selection mistake, or route 139 distribution mistake. With the correlated record of policy and 140 route, the server/controller is able to identify the unexpected route 141 change and its responsible policy. Considering the fact that the BGP 142 route policy impacts not only the route processing within the 143 individual device but also the route distribution to its peers, the 144 route trace data of a single device is always analyzed in correlation 145 with such data collected from its peer devices. 147 Apart from the policy validation application, the route trace data 148 can also be analyzed to discover the route propagation path within 149 the network. With the route's inbound and outbound event records 150 collect from each related device, the server is able to find the 151 propagation path hop by hop. The identified path is helpful for 152 operators to better understand its network, and thus benefitting both 153 network troubleshooting and network planning. 155 2. Extension of BMP for Route Policy and Attribute Trace 157 2.1. Common Header 159 This document defines a new BMP message type to carry the Route 160 Policy and Attribute Trace data. 162 o Type = TBD: Route Policy and Attribute Trace Message 164 The new defined message type is indicated in the Message Type field 165 of the BMP common header. 167 2.2. Per Peer Header 169 The Route Policy and Attribute Trace Message is not per peer based, 170 thus it does not require the Per Peer Header. 172 2.3. Route Policy and Attribute Trace Message 174 The Route Policy and Attribute Trace Message format is defined as 175 follows: 177 +---------------------------------------------------------------+ 178 | Route Distinguisher | 179 +---------------------------------------------------------------+ 180 | Prefix length | 181 +---------------------------------------------------------------+ 182 | Prefix | 183 +---------------------------------------------------------------+ 184 | Previous Hop Length | 185 +---------------------------------------------------------------+ 186 | Previous Hop | 187 +---------------------------------------------------------------+ 188 | Event count | 189 +---------------------------------------------------------------+ 190 | Total event length | 191 +---------------------------------------------------------------+ 192 | 1st Event | 193 +---------------------------------------------------------------+ 194 | 2nd Event | 195 +---------------------------------------------------------------+ 196 ~ ~ 197 + ...... + 198 ~ ~ 199 +---------------------------------------------------------------+ 200 | Last Event | 201 +---------------------------------------------------------------+ 203 Figure 1: Route Policy and Attribute Trace Message format 205 o Route Distinguisher (8 Bytes): indicates the route distinguisher 206 (RD) related to the route. 208 o Prefix Length (1 Byte): indicates the length of the prefix. 210 o Prefix (Variable): indicates the monitored prefix, with the length 211 defined by Prefix Length field. 213 o Previous Hop Length (1 Byte): indicates the length of the 214 following Previous Hop field. If the BGP peer ID of previous hop 215 is IPv4, it is set to 4, and if the BGP peer ID of the previous 216 hop is an IPv6, it is set to 16. 218 o Previous Hop (Variable): indicates the BGP peer ID where this 219 route is learnt from. If the route is locally generated, then 220 field is zero filled. 222 o Event Count (1 Byte): indicates the total number of policy 223 processing event recorded in this message. 225 o Total event length (2 Byte): indicates the total length of the 226 following fields including all events, where the total number is 227 indicated by the Event Count field. 229 o 1 ~ Last event: indicates each event, stacked one by one in order 230 of time. The event format is further defined as follows. 232 +---------------------------------------------------------------+ 233 | Single event length | 234 +---------------------------------------------------------------+ 235 | Event index | 236 +---------------------------------------------------------------+ 237 | Timestamp(seconds) | 238 +---------------------------------------------------------------+ 239 | Timestamp(microseconds) | 240 +---------------------------------------------------------------+ 241 | Policy Classification | 242 +---------------------------------------------------------------+ 243 | Peer ID | 244 +---------------------------------------------------------------+ 245 | Peer AS | 246 +---------------------------------------------------------------+ 247 | Path Identifier | 248 +---------------------------------------------------------------+ 249 | Peer AFI | 250 +---------------------------------------------------------------+ 251 | Peer SAFI | 252 +---------------------------------------------------------------+ 253 | VRF/Table Name TLV | 254 +---------------------------------------------------------------+ 255 | Pre Policy Attribute TLV | 256 +---------------------------------------------------------------+ 257 | Post Policy Attribute TLV | 258 +---------------------------------------------------------------+ 259 | Policy ID TLV | 260 +---------------------------------------------------------------+ 261 | Optional TLV | 262 +---------------------------------------------------------------+ 264 Figure 2: Event format 266 o Single event length (2 Byte): indicates the total length of a 267 single policy process event, including the following fields that 268 belong to this event. 270 o Event index (1 Byte): indicates the sequence number of this event, 271 staring from 1 and increases by 1 for each event recorded in 272 order. 274 o Timestamp (8 Bytes): indicates the time when the policy of this 275 event starts execution, expressed in seconds and microseconds 276 since midnight (zero hour), January 1, 1970 (UTC). 278 o Peer ID (4 Bytes): indicates the BGP Peer ID where this policy is 279 configured under. This field is used in combination with the 280 Policy Direction field. If the Policy Direction field is set to 281 "0000", meaning Inbound policy, then this field is set to the BGP 282 Peer ID where the route is received from; if the Policy Direction 283 field is set to "0001", meaning Outbound policy, then this field 284 is set to the BGP Peer ID where the route is distributed to; If 285 the Policy Direction field is set to "0010", "0010","0100" meaning 286 Redistribution/Network/Aggregation policy, then this field is set 287 to all zeros. 289 o Peer AS (4 Bytes): indicates the AS number of the BGP Peer that 290 defined the Peer ID field. 292 o Policy Classification (1 Byte): indicates the category of the 293 policy. Currently 5 policy categories are defined: "0000" 294 indicating the Inbound policy, "0001" indicating the Outbound 295 policy, "0010" indicating the Redistribution policy (e.g., route 296 import from other sources, like ISIS/OSPF), "0011" indicates the 297 Route Leak policy (route leaking from the global routing table to 298 a VRF or from a VRF to the global routing table, or between VRFs), 299 "0100" indicates the Network policy (BGP network installment and 300 advertisement), "0101" indicating the Aggregation policy. More 301 categories can be defined. 303 o 305 +--------------------------------+ 306 | Value |Policy Classification| 307 +--------------------------------+ 308 | 00000000 | Inbound policy | 309 | 00000001 | Outbound policy | 310 | 00000010 | Redistribution | 311 | 00000011 | Route Leak | 312 | 00000100 | Network | 313 | 00000101 | Aggregation | 314 +----------+---------------------+ 316 Table 1: Policy Classification 318 o Path Identifier (4 Bytes): used to distinguish multiple BGP paths 319 for the same prefix. If there's no path ID, this field is zero 320 filled. 322 o Peer AFI (2 Bytes)/Peer SAFI (1 Byte): indicates the AFI/SAFI of 323 the route. The AFI/SAFI information varies for the same route 324 under different policy processing event. For example, an IPv4 325 Unicast route is received from a CE router at the PE router 326 through eBGP, an RD is attached to this IPv4 Unicast route and 327 making it a VPNv4 route, and then this VPNv4 route is distributed 328 to the RR. During this process, the AFI/SAFI information changes 329 from IPv4 Unicast (1/1) to VPNv4 (1/128) at the inbound policy and 330 outbound policy. 332 o VRF/Table Name TLV (Variable): indicates the VRF name or table 333 name of the route. The format of the VRF/Table Name TLV is 334 further defined in Figure 3. The VRF/Table Name TLV is non- 335 optional. 337 o Pre-policy Attribute TLV (Variable): include the BGP route 338 atttributes before the policy is executed. The format of the Pre- 339 policy Attribute TLV is further defined in Figure 4. The Pre- 340 policy Attribute TLV is optional. 342 o Post-policy Attribute TLV (Variable): include the BGP route 343 atttributes after the policy is executed. The format of the Post- 344 policy Attribute TLV is further defined in Figure 5. The Post- 345 policy Attribute TLV is optional. 347 o Policy ID TLV (Variable): indicates the ID of the route policy of 348 this event, which is user specific or vendor specific, which can 349 be used for mapping to the actual policy content. The policy 350 content data retrieval is out of the scope of this document. The 351 format of the Policy ID TLV is further defined in Figure 6. The 352 Policy ID TLV is optional. 354 o Optional TLV (Variable): leaves for future extension. The 355 Optioanl TLV is optional. 357 2.3.1. VRF/Table Name TLV 359 +-------------------------------+-------------------------------+ 360 | Type = TBD1 | VRF/Table name length | 361 +-------------------------------+-------------------------------+ 362 | VRF/Table name | 363 +---------------------------------------------------------------+ 365 Figure 3: VRF/Table name TLV 367 o Type = TBD1 (2 Byte): indicates the type of VRF/Table name TLV. 369 o VRF/Table name length (2 Byte): indicates the length of the VRF/ 370 Table name field. 372 o VRF/Table name (Variable): indicates the VRF or table name of this 373 route in the format of ASCII string. The string size MUST be 374 within the range of 1 to 255 bytes. The VRF/Table name varies for 375 the same route under different events. For example, an IPv4 376 Unicast route is received from a CE router at the PE router 377 through iBGP, an RD is attached to this IPv4 route (under VRF A) 378 and making it a VPNv4 route, and then this VPNv4 route (under the 379 Global routing table) is distributed to the RR. During the whole 380 process, the VRF/Table name changes from VRF A to the Global 381 routing Table name at the inbound event and outbound event. 383 2.3.2. Pre Policy Attribute TLV 385 +-------------------------------+-------------------------------+ 386 | Type = TBD2 | Pre Policy Attr. length | 387 +-------------------------------+-------------------------------+ 388 | Pre Policy Attribute sub TLVs | 389 +---------------------------------------------------------------+ 391 Figure 4: Pre Policy Attribute TLV 393 o Type = TBD2 (2 Byte): indicates the type of Pre Policy Attribute 394 TLV. 396 o Pre Policy Attribute length (2 Byte): indicates the total length 397 of the following Pre Policy Attribute sub TLVs. 399 o Pre Policy Attribute sub TLVs (Variable): include the BGP route 400 attributes before the policy is executed. 402 2.3.3. Post Policy Attribute TLV 404 +-------------------------------+-------------------------------+ 405 | Type = TBD3 | Post Policy Attr. length | 406 +-------------------------------+-------------------------------+ 407 | Post Policy Attribute sub TLVs | 408 +---------------------------------------------------------------+ 410 Figure 5: Post Policy Attribute TLV 412 o Type = TBD3 (2 Byte): indicates the type of Pre Policy Attribute 413 TLV. 415 o Pre Policy Attribute length (2 Byte): indicates the total length 416 of the following Pre Policy Attribute sub TLVs. 418 o Pre Policy Attribute sub TLVs (Variable): include the BGP route 419 attributes before the policy is executed. 421 2.3.4. Policy ID TLV 423 The Route Policy and Attribute Trace Message is not per peer based, 424 thus it does not require the Per Peer Header. 426 +------------------------+---------------------------+ 427 | Type = TBD4 | Policy ID length | 428 +----------------------------------------------------+ 429 |M| Res. | Policy Count | 430 +----------------------------------------------------+ 431 | 1st Policy |C|R| Res. | 432 +----------------------------------------------------+ 433 ~ | ~ 434 + ... | ... + 435 ~ | ~ 436 +----------------------------------------------------+ 437 | Last Policy |C|R| Res. | 438 +----------------------------------------------------+ 440 Figure 6: Policy ID TLV 442 Considering the chaining and recursion of polices and policy items, 443 the Policy ID TLV is defined as follows. 445 o Type = TBD4 (2 Byte): indicates the type of Policy ID TLV. 447 o Policy ID length (2 Byte): indicates the length of the Policy ID 448 value field that follows it. The Policy ID value field includes 449 the Reserved bits, the Flag bits, Policy Count field, and Policy 450 field. 452 o Flag bit M (1 bit): indicates if the route in this event is 453 matched (once or multiple times) or not by any policies. "0" means 454 no match and "1" means elsewise. The remaining 7 bits are 455 reserved for future extension. 457 o Policy Count (1 Byte): indicates the number of policies (in the 458 format of Policy name + Item ID) carried in this event. 460 o 1st ~ Last Policy (Variable): indicates the Policy name and the 461 Item ID of each policy match. 463 o Flag bit C (1 bit): indicates if the next subsequent policy has 464 chaining relationship to the current policy. "1" means it's 465 chaining relationship and "0" means elsewise. For the flag byte 466 following the Last Policy field, the C bit SHALL be set to "0". 468 o Flag bit R (1 bit): indicates if the next subsequent policy has 469 recursioning relationship to the current policy. "1" means it's 470 recursioning relationship and "0" means elsewise. For the flag 471 byte following the Last Policy field, the R bit SHALL be set to 472 "0". 474 +----------------------------------------+ 475 | Policy Name length | 476 +----------------------------------------+ 477 | Policy Name | 478 +----------------------------------------+ 479 | Item ID length | 480 +----------------------------------------+ 481 | Item ID | 482 +----------------------------------------+ 484 Figure 7: Policy field format 486 The Policy ID field consists of the Route Policy Name and the Route 487 Policy Item ID. The Policy name and Item ID are in the format of 488 ASCII string, the length of both fields are indicated by the Policy 489 Name length (2 Bytes) and Item length (1 Byte) fields, respectively. 491 2.3.5. Optional TLV 493 +-------------------------------+-------------------------------+ 494 | Type = TBD5 | Length | 495 +-------------------------------+-------------------------------+ 496 | Value | 497 +---------------------------------------------------------------+ 499 Figure 8: Optional TLV 501 The Optional TLV remains to be defined. One or more Optional TLV 502 types can be defined. One or more Optional TLVs can be used. 504 One possible way of utilizing the Optional TLV is to define a string 505 Type TLV. The String Type TLV allows flexible textual expression of 506 user-specific information without requiring structural format. Some 507 examples: 509 o The Policy ID TLV is defined as optional, considering that users 510 may don't want detailed information about the policy but only the 511 result and/or the reasons. Using a string type TLV, one may 512 express "Route rejected due to inbound filtering". However, such 513 expression still requires the tracking of policy processing in 514 realtime, it's just another form of tracking representation to the 515 BMP server and the user. 517 o Another possible application is for route leak detection. One may 518 express the business relations as "P2C", "P2P" and so on, with the 519 inbound filtering event or the outbound filtering event. Detailed 520 usage is discussed in Section 4.2. 522 3. Implementation Considerations 524 Considering the data amount of monitoring the route and policy trace 525 of all routes from all BMP clients, users MAY trigger the monitoring 526 at any user-specific time. Users MAY configure locally at the BMP 527 client to monitor only user-specific routes or all the routes. In 528 addition, users MAY configure locally at the BMP client whether to 529 report the TLVs that are optional according to their own 530 requirements, i.e., the Pre Policy Attribute TLV, Post Policy 531 Attribute TLV, Policy ID TLV, and Optional TLV. 533 Successive recored events from one device MAY be encapsulated in one 534 Route Policy and Attribute Trace Message or multiple Route Policy and 535 Attribute Trace Messages per the user configuration. 537 4. Implementation Example 539 4.1. Route Distribution Tracking 540 +----------+ 541 +------>+BMP server+<-------+ 542 | +--+-------+ | 543 + ^ ^ | 544 Event 1,2,3 +-----+ | + 545 + + + Event 9,10,11 546 | Event 4,5 Event 6,7,8 + 547 | + + | 548 | | | | 549 10.1.1.1/32 ****|****|**********|***********|***** 550 +---------> * | | | | AS0* 551 +-----+ * | | +--+--+ | * 552 | CE1 ++eBGP+ * | +--------->+ RR +------+ | * 553 +-----+ | * | | | ++----+ | | * 554 AS1 | * | | | ^ iBGP | | * 555 | * | | ++----+ | 65000:10 | | * 10.1.1.1/32 556 10.1.1.1/32 +----------> PE2 +---+10.1.1.1/32| | * +-----------> 557 +---------> * | | +-----+ | | * +-----+ 558 +-----+ * | | iBGP | | * +eBGP+>+ CE4 | 559 | CE2 ++eBGP+ * | | iBGP 65000:10 + | * | +-----+ 560 +-----+ | * | +65000:10 10.1.1.1/32 | * | AS4 561 AS2 | * | 10.1.1.1/32 + | * | 562 | * ++----+ +--v-++ * | 563 +-----+ +-----> PE1 | | PE3 +------+ +-----+ 564 | CE3 ++eBGP+-----> | | +------+eBGP+>+ CE5 | 565 +-----+ * +-----+ +-----+ * +-----+ 566 10.1.1.1/32 * * 10.1.1.1/32 567 +--------> ************************************** +-----------> 568 AS3 AS5 570 Figure 9: Route Policy and Attribute Trace record implementation example 572 We take the network shown in Figure 9 as an example to show how to 573 use Route Policy and Attribute Trace Messages to recover the 574 footprint of the route propagation. Notice that only basic events 575 required for footprint recovery are illustrated here. Also notice 576 that the event index shown in Figure 9, 10, 11 are for illustration 577 purpose, and may not reflect the actual indexing. 579 Suppose a prefix 10.1.1.1/32 is sent from both CE2 and CE3 to PE1 580 through eBGP peering, PE1 processes the two Update messages through 581 inbound policies. Such procedure is recorded as two events, namely 582 Event 1 and Event 2. Then PE1 selects the route from CE2 as the best 583 route, add it to VRF 1, and then distribute the VPNv4 route to RR. 584 The distribution procedure is recorded by PE1 as Event 3. As an 585 example, the Route Policy and Attribute Trace Message of Event 1, 2, 586 3 is listed as follows. Only fields related to footprint recovery 587 are listed in the message shown below. Specifically, the Previous 588 Hop information is carried in Event 3 when outbounding the route, 589 indicating that the outbounded route is learnt from CE2. The same 590 prefix is sent from CE1 to PE2, added to VRF 1 and then distributed 591 to RR in the form of VPNv4 route. Two events, Event 4 (inbound) and 592 Event 5 (outbound) are recorded by PE2. Now for RR, prefix 593 10.1.1.1/32 is received from both PE1 and PE2 in the form of VPNv4 594 route. RR selects the route from PE1 as the best route, and 595 distribute it to PE3. Three events, Event 6 (PE2 inbound), Event 7 596 (PE1 inbound), Event 8 (PE3 outbound) are recorded in this case. PE3 597 receives the VPNv4 route from RR, adds it to VRF 1 and then 598 distribute the IPv4 route to CE4 and CE5, respectively. Here, three 599 events are recorded, Event 9 (RR inbound), Event 10 (CE4 outbound) 600 and Event 11 (CE5 outbound). 602 +---------------------------------------------------------------+ 603 | RD: 65000:10 | 604 +---------------------------------------------------------------+ 605 | Prefix: 10.1.1.1/32 | 606 +---------------------------------------------------------------+ 607 | Previous hop: CE2 | 608 +---------------------------------------------------------------+ 609 | Event count: 2 | 610 +---------------------------------------------------------------+ 611 | Event 1 | 612 +---------------------------------------------------------------+ 613 | Timestamp 1 | 614 +---------------------------------------------------------------+ 615 | Inbound policy | 616 +---------------------------------------------------------------+ 617 | Peer ID: CE2 | 618 +---------------------------------------------------------------+ 619 | Peer AS: AS2 | 620 +---------------------------------------------------------------+ 621 | Path ID: 0 | 622 +---------------------------------------------------------------+ 623 | AFI/SAFI: IPv4 Unicast | 624 +---------------------------------------------------------------+ 625 | VRF/Table name: VRF 1 | 626 +---------------------------------------------------------------+ 627 | Pre Policy Attributes | 628 +---------------------------------------------------------------+ 629 | Post Policy Attributes | 630 +---------------------------------------------------------------+ 631 | Policy ID: WC1, node 101 | 632 +---------------------------------------------------------------+ 633 | Event 3 | 634 +---------------------------------------------------------------+ 635 | Timestamp 3 | 636 +---------------------------------------------------------------+ 637 | Outbound policy | 638 +---------------------------------------------------------------+ 639 | Peer ID: RR | 640 +---------------------------------------------------------------+ 641 | Peer AS: AS0 | 642 +---------------------------------------------------------------+ 643 | Path ID: 0 | 644 +---------------------------------------------------------------+ 645 | AFI/SAFI: VPNv4 | 646 +---------------------------------------------------------------+ 647 | VRF/Table name: Global/Default | 648 +---------------------------------------------------------------+ 649 | Pre Policy Attributes | 650 +---------------------------------------------------------------+ 651 | Post Policy Attributes | 652 +---------------------------------------------------------------+ 653 | Policy ID: RR1, node 200 | 654 +---------------------------------------------------------------+ 656 Figure 10: Event 1,3 data view 658 +---------------------------------------------------------------+ 659 | RD: 65000:10 | 660 +---------------------------------------------------------------+ 661 | Prefix: 10.1.1.1/32 | 662 +---------------------------------------------------------------+ 663 | Previous hop: CE3 | 664 +---------------------------------------------------------------+ 665 | Event count: 1 | 666 +---------------------------------------------------------------+ 667 | Event 2 | 668 +---------------------------------------------------------------+ 669 | Timestamp 2 | 670 +---------------------------------------------------------------+ 671 | Inbound policy | 672 +---------------------------------------------------------------+ 673 | Peer ID: CE3 | 674 +---------------------------------------------------------------+ 675 | Peer AS: AS3 | 676 +---------------------------------------------------------------+ 677 | Path ID: 0 | 678 +---------------------------------------------------------------+ 679 | AFI/SAFI: IPv4 Unicast | 680 +---------------------------------------------------------------+ 681 | VRF/Table name: VRF 1 | 682 +---------------------------------------------------------------+ 683 | Pre Policy Attributes | 684 +---------------------------------------------------------------+ 685 | Post Policy Attributes | 686 +---------------------------------------------------------------+ 687 | Policy ID: WC1, node 102 | 688 +---------------------------------------------------------------+ 690 Figure 11: Event 2 data view 692 The BMP server can use the collected events to recover the route 693 footprint. The key information required from recovery is the 694 Timestamp of each event, and the Previous Hop of the route. The 695 Timestamp allows the server to identify the order of each event, 696 while the Previous Hop information, combined with the outbound peer 697 information, allows the server to recover the route propagation hop 698 by hop. 700 4.2. Route Leak Detection 702 Reusing Figure 9, the Optional TLV of the RoFT Message can be 703 utilized to carry user-specific strings. We present a route leak 704 detection example here. 706 Suppose, a route leak happens (10.1.1.1/32: AS2 --> AS0 --> AS4). 707 The Bussiness relationships between ASes are shown in Table 2. 709 +----------------+--------------+ 710 | Neighbor ASes | Bussiness | 711 | | Relationship | 712 +-------------------------------+ 713 | AS 1 : AS 0 | P2C | 714 +-------------------------------+ 715 | AS 2 : AS 0 | P2C | 716 +-------------------------------+ 717 | AS 3 : AS 0 | P2C | 718 +-------------------------------+ 719 | AS 0 : AS 4 | C2P | 720 +-------------------------------+ 721 | AS 0 : AS 5 | P2C | 722 +----------------+--------------+ 724 Table 2: Bussiness Relationship 726 To detect the route leak, the BMP server analyzes the events with 727 bussiness relationship information reported from the ingress device 728 and egress device of AS0 (regarding a specific route)). In this 729 example, regarding 10.1.1.1/32, data from PC1 and PE3 are analized. 730 The bussiness relationship can be expressed in strings, such as "P2C" 731 or "P2P". At PE1, when 10.1.1.1/32 is received from CE2 and going 732 through the inbound policy, PE1 uses the Optional TLV (more 733 specifically the String Type TLV) to carry the text "Bussiness 734 Relationship: P2C" in the Inound Policy event. On the other hand, at 735 PE3, when 10.1.1.1/32 goes through the outbound policy and then sent 736 to CE4, PE3 adds the "Bussiness Relationship: P2C", using the 737 Optional TLV, in the Outbound Policy event. More specifically, the 738 format of the above mentioned two events are listed in Figure 12 739 (Event 1) and Figure 13 (Event 10), respecitvely. 741 +---------------------------------------------------------------+ 742 | RD: 65000:10 | 743 +---------------------------------------------------------------+ 744 | Prefix: 10.1.1.1/32 | 745 +---------------------------------------------------------------+ 746 | Previous hop: CE2 | 747 +---------------------------------------------------------------+ 748 | Event count: 1 | 749 +---------------------------------------------------------------+ 750 | Event 1 | 751 +---------------------------------------------------------------+ 752 | Timestamp 1 | 753 +---------------------------------------------------------------+ 754 | Inbound policy | 755 +---------------------------------------------------------------+ 756 | Peer ID: CE2 | 757 +---------------------------------------------------------------+ 758 | Peer AS: AS2 | 759 +---------------------------------------------------------------+ 760 | Path ID: 0 | 761 +---------------------------------------------------------------+ 762 | AFI/SAFI: IPv4 Unicast | 763 +---------------------------------------------------------------+ 764 | VRF/Table name: VRF 1 | 765 +---------------------------------------------------------------+ 766 | Pre Policy Attributes | 767 +---------------------------------------------------------------+ 768 | Post Policy Attributes | 769 +---------------------------------------------------------------+ 770 | Policy ID: WC1, node 101 | 771 +---------------------------------------------------------------+ 772 | Optional TLV: "Bussiness Relationship: P2C" | 773 +---------------------------------------------------------------+ 775 Figure 12: Event 1 data view 777 +---------------------------------------------------------------+ 778 | RD: 65000:10 | 779 +---------------------------------------------------------------+ 780 | Prefix: 10.1.1.1/32 | 781 +---------------------------------------------------------------+ 782 | Previous hop: RR | 783 +---------------------------------------------------------------+ 784 | Event count: 1 | 785 +---------------------------------------------------------------+ 786 | Event 10 | 787 +---------------------------------------------------------------+ 788 | Timestamp 10 | 789 +---------------------------------------------------------------+ 790 | Outbound policy | 791 +---------------------------------------------------------------+ 792 | Peer ID: CE4 | 793 +---------------------------------------------------------------+ 794 | Peer AS: AS4 | 795 +---------------------------------------------------------------+ 796 | Path ID: 0 | 797 +---------------------------------------------------------------+ 798 | AFI/SAFI: IPv4 Unicast | 799 +---------------------------------------------------------------+ 800 | VRF/Table name: VRF 3 | 801 +---------------------------------------------------------------+ 802 | Pre Policy Attributes | 803 +---------------------------------------------------------------+ 804 | Post Policy Attributes | 805 +---------------------------------------------------------------+ 806 | Policy ID: OB1, node 300 | 807 +---------------------------------------------------------------+ 808 | Optional TLV: "Bussiness Relationship: C2P" | 809 +---------------------------------------------------------------+ 811 Figure 13: Event 10 data view 813 The BMP server can use the two Optional TLVs from Event 1 and Event 814 10 to detect the route leak. What's more, the repsonsible 815 configurations are directly shown in the two events, i.e., the 816 Inbound policy at PE1: "Policy ID: WC1, node 101", the Outbound 817 policy at PE3: "Policy ID: OB1, node 300". No need to correlate with 818 other data sources, the user can detect the leak and figure out the 819 root cause. 821 5. Acknowledgements 823 TBD. 825 6. IANA Considerations 827 TBD. 829 7. Security Considerations 831 TBD. 833 8. Normative References 835 [I-D.ietf-grow-bmp-adj-rib-out] 836 Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S. 837 Zhuang, "Support for Adj-RIB-Out in BGP Monitoring 838 Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-06 (work 839 in progress), June 2019. 841 [I-D.ietf-grow-bmp-local-rib] 842 Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente, 843 "Support for Local RIB in BGP Monitoring Protocol (BMP)", 844 draft-ietf-grow-bmp-local-rib-04 (work in progress), June 845 2019. 847 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 848 Requirement Levels", BCP 14, RFC 2119, 849 DOI 10.17487/RFC2119, March 1997, 850 . 852 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 853 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 854 DOI 10.17487/RFC4271, January 2006, 855 . 857 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 858 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 859 2009, . 861 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 862 Monitoring Protocol (BMP)", RFC 7854, 863 DOI 10.17487/RFC7854, June 2016, 864 . 866 Authors' Addresses 868 Feng Xu 869 Tencent 870 Guangzhou 871 China 873 Email: oliverxu@tencent.com 875 Yunan Gu 876 Huawei 877 Huawei Bld., No.156 Beiqing Rd. 878 Beijing 100095 879 China 881 Email: guyunan@huawei.com 883 Shunwan Zhuang 884 Huawei 885 Huawei Bld., No.156 Beiqing Rd. 886 Beijing 100095 887 China 889 Email: zhuangshunwan@huawei.com 891 Zhenbin Li 892 Huawei 893 Huawei Bld., No.156 Beiqing Rd. 894 Beijing 100095 895 China 897 Email: lizhenbin@huawei.com