idnits 2.17.1 draft-raszuk-bgp-diagnostic-message-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 423 has weird spacing: '...ch case is in...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 17, 2010) is 4937 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) == Missing Reference: 'BGP-CAP' is mentioned on line 583, but not defined == Unused Reference: 'RFC2119' is defined on line 661, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 664, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 667, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group R. Raszuk 3 Internet-Draft E. Chen 4 Intended status: Standards Track Cisco Systems 5 Expires: April 20, 2011 B. Decraene 6 France Telecom 7 October 17, 2010 9 BGP Diagnostic Message 10 draft-raszuk-bgp-diagnostic-message-00 12 Abstract 14 BGP protocol lacks self diagnostic tools which would allow for 15 monitoring and detection of any possible bgp state database 16 differences between BGP_RIB_Out of the sender and BGP_RIB_In of the 17 receiver over BGP peering session. It also lacks of build in 18 mechanism to inform peer about subset of prefixes received over 19 session which experienced some errors and which per protocol 20 specification either resulted in attribute drop or "treat-as- 21 withdraw" action. 23 The intention of this document is to start a new class of work which 24 will make BGP protocol and therefor assuring services constructed 25 with the help of BGP protocol to become much more reliable and 26 robust. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 20, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. BGP diagnostic message . . . . . . . . . . . . . . . . . . . . 4 65 3.1. BGP DIAGNOSTIC Message Encoding . . . . . . . . . . . . . 4 66 3.2. BGP DIAGNOSTIC Message TLVs . . . . . . . . . . . . . . . 5 67 3.2.1. Operational TLVs . . . . . . . . . . . . . . . . . . . 6 68 3.2.2. BGP database counters exchange . . . . . . . . . . . . 9 69 3.2.3. Diagnostics for encoding errors in BGP messages . . . 10 70 3.2.4. AFI/SAFI signaling when malformed update . . . . . . . 12 71 3.2.5. Prefix specific BGP debugging . . . . . . . . . . . . 12 72 3.2.6. Intra-domain bgp decision monitoring . . . . . . . . . 13 73 3.2.7. Exchange of installed Route Target filters . . . . . . 14 74 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 5. Capability negotiation . . . . . . . . . . . . . . . . . . . . 15 76 6. Security considerations . . . . . . . . . . . . . . . . . . . 16 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 79 9. Normative References . . . . . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Introduction 84 In this document we will first define a new diagnostic communication 85 channel in the form of new BGP message then construct the set of 86 basic message encoding to be used for simple diagnostic self test 87 routines periodically exchanged between BGP speakers. We will also 88 define set of other TLVs which can be very useful in precise 89 description of prefixes affected by various cases of BGP session 90 malfunctions. 92 The goal of this document is to provide the background which will in 93 turn allow for very easy extensibility once new needs and new BGP 94 diagnostic ideas surface. 96 2. Applications 98 Authors would like to propose four main applications which BGP 99 Diagnostic TLVs are designed to address. New TLVs can be easily 100 added to enhance further current applications or to propose new 101 applications. 103 The set of TLVs is organized in the following application groups: 105 General TLVs used for operational purposes of the described 106 mechanism. 108 Set of TLVs designed to carry information about BGP state across 109 BGP peers that include per neighbor counters and global counters. 110 There are two modes this functionality can be used - on demand by 111 explicit query as well as periodic in an automated mode. The 112 scope of messages is to be able to operate both on the iBGP as 113 well as eBGP boundaries. It is in the control of the operator to 114 decide which set of information would be send to a given set of 115 peers. 117 Messages which operate in an automated push mode (as long as peer 118 negotiated listen capability for them) and are designed to inform 119 BGP peer on the list of impacted NLRIs which were received along 120 with malformed attribute or within malformed update message. 122 Following recommendation from MP-BGP4 RFC4760 next group of 123 messages are used to indicate which AFI/SAFIs were disabled for 124 any further processing by BGP peer due to detection of an 125 incorrect attribute present in the BGP Update message. 127 In number of troubleshooting efforts in real networks it is often 128 very helpful to verify state of a given prefix in the neighboring 129 router's BGP database. This is particularly useful on the EBGP 130 boundaries where there is no CLI/SNMP access to the router. 131 Authors define a new way of query peer's BGP for the state of 132 particular prefix. 134 Last set of messages is an attempt to allow for intra-domain 135 better analysis of the BGP best path selection tie break 136 decisions. 138 3. BGP diagnostic message 140 When defining any self test tool the critical element is to find a 141 right separation balance between the test object and testing 142 instruments. 144 For the vast majority of real BGP issues found in the life production 145 networks authors believe that the right balance is the definition of 146 new BGP message which could be exchanged along with any negotiated 147 AFI/SAFI between those BGP speakers which will during initial OPEN 148 message exchange new BGP diagnostic message capability. 150 The two extreme alternatives which were considered were the 151 definition of new BGP attribute which may inherit and share potential 152 issues of given BGP address family it is designed to diagnose and on 153 the other extreme to build a separate and independent network 154 diagnostic protocol. The use of BGP message seems to provide 155 sufficient isolation from any service address family and is much 156 easier to deploy then enabling an entire new intra and inter-domain 157 protocol. Another very important issue with using any other protocol 158 for detection of potential differences of BGP databases state is lack 159 of synchronization with BGP UPDATE messages. This alone in the 160 continuously churning BGP environment would not allow for any 161 benefit. 163 3.1. BGP DIAGNOSTIC Message Encoding 165 BGP message as defined in RFC 4271 consists of a fixed-size header 166 followed by two octet length field and one octet of type value. RFC 167 4271 limits maximum message size to 4096 octets. As one of the 168 applications of BGP Diagnostic message is to be able to carry entire 169 potentially malformed BGP message this specification extends the 170 maximum size of BGP Diagnostic message to be always 128 octets bigger 171 then any other BGP Message. Considering the current RFC 4271 maximum 172 BGP message size to be 4096 octets maximum size of BGP diagnostic 173 message would be 4224 octets. 175 For the purpose of diagnostic message information encoding we will 176 use one or more Type-Length-Value containers where each TLV will have 177 the following format: 179 0 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Type | Length | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Variable size TLV value | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Figure 1: DIAGNOSTIC message TLV Format 189 Type - 2 octet value indicating the TLV type 190 Length - 2 octet value indicating the TLV length in octets 191 Value - Variable length value field depending on the type of 192 the TLVs carried. 194 To work around continued BGP churn issue some types of TLVs will need 195 to contain a sequence number to correlate request with associated to 196 it replies. The sequence number will consist of 8 octets and will be 197 of form: 4 octet bgp_router_id + local 4 octet number. When local 4 198 octet number reaches 0xFFFF it should restart from 0x0000. 200 Typical application scenario for use of sequence number is to include 201 it in the diagnostic request message and during reply to copy it into 202 reply messages triggered by such request message. 204 3.2. BGP DIAGNOSTIC Message TLVs 206 This document defines the following diagnostic TLV types: 208 * Operational TLVs 210 * BGP database counters exchange 212 * Diagnostics for encoding errors in BGP messages 214 * AFI/SAFI signaling when malformed update 216 * Prefix specific BGP debugging 218 * Intra-domain bgp decision monitoring 219 * Exchange of Route Target filters 221 3.2.1. Operational TLVs 223 Type 1 - Diagnostic Message Periodic Request 224 Length - 2 octets - variable value 226 Value (N x 2 octets): 227 TLV type - 2 octets 229 Use: To indicate the request to periodically receive listed TLV 230 information. TLV type of 0xFFFF indicates request to receive 231 all available diagnostic TLVs from the peer. 233 Type 2 - Max frequency permitted 234 Length - 2 octets - variable value 236 Value (N x 4 octets): 237 TLV type - 2 octets 238 Frequency value in seconds two octets 0..65535 240 Special values: 241 0 - never send given diagnostic TLV 242 65535 - no TLV inter-gap minimum set 244 Use: To indicate in seconds the maximum frequency given TLV 245 may be periodically sent to the bgp speaker 247 Type 3 - Diagnostic Message Query 248 Length - 2 octets - variable value 249 Sequence number - 8 octets 251 Value (N x 2 octets): 252 TLV type - 2 octets 254 Use: To interactively (during debugging/troubleshooting) request 255 to receive listed TLV information. TLV type of 0xFFFF 256 indicates request to receive all available diagnostic TLVs 257 from the peer. TLV of type 0x0000 indicates request to 258 receive a list of all enabled and available diagnostic 259 TLV types from the peer towards querying BGP speaker. The 260 support of this TLV type is mandatory. 262 Type 4 - Counter's reset request 263 Length - 2 octets - variable value 265 Value (N x 2 octets): 266 TLV type - 2 octets - List of TLVs subject to counter's reset. 268 Use: To request rest of per neighbor counters of a given TLV 269 type. TLV type of 0xFFFF indicates request to zero all 270 per neighbor counters. 272 Type 5 - Not supported TLV reply 273 Length - 2 octets - variable value 275 Value (N x 3 octets): 276 TLV type - 2 octets - TLV that is not supported by the peer 277 but where part of TLV Request or TLV Query message 278 Error Code - 1 octet - Error code 280 Error codes: 282 0x01 - Wrong TLV value 283 0x02 - TLV not supported for this peer 284 0x03 - Max query frequency exceeded 285 0x04 - Administratively disabled 287 Use: To indicate to the peer that the TLV he has requeste 288 either in TLV Request or in TLV Query message is not 289 supported. The support of this TLV type is mandatory. 291 Type 6 - Enabled and supported TLV types 292 Length - 2 octets - variable value 294 Value (N x 2 octets): 295 TLV type - 2 octets - TLV that is enabled and supported 296 by the peer 298 Use: To indicate to the peer that the enclosed list of TLVs 299 can be requested either in TLV Request or in TLV Query 300 messages. The support of this TLV type is mandatory. 302 3.2.2. BGP database counters exchange 304 Type 7 - Number of Reachable Prefixes Transmitted/Received 305 Length - 2 octets - variable value 306 Sequence number - 8 octets 308 Value (N x 11 octets): 309 AFI/SAFI - 3 octets 310 Number of prefixes transmitted - 4 octets 311 Number of prefixes received - 4 octets 313 Use: To indicate number of reachable prefixes exchanged for 314 a given AFI/SAFI between two bgp speakers. This message 315 can be sent only based on the remote query Type 3 which 316 contains the query sequence number to be placed in the 317 reply. 319 Type 8 - Number of prefixes in BGP_RIB_Out 320 Length - 2 octets - variable value 322 Value (N x 7 octets): 323 AFI/SAFI - 3 octets 324 Number of prefixes 4 octets 326 Use: To indicate number of prefixes kept in BGP_RIB_Out between 327 bgp speakers for a given AFI/SAFI between two bgp speakers. 329 Type 9 - Number of paths in BGP_RIB_Out 330 Length - 2 octets - variable value 332 Value (N x 6 octets): 333 AFI/SAFI - 3 octets 334 Number of paths 4 octets 336 Use: To indicate number of paths kept in BGP_RIB_Out between bgp 337 speakers for a given AFI/SAFI between two bgp speakers. 339 Type 10 - Number of prefixes present in BGP_RIB 340 Length - 2 octets - variable value 342 Value (N x 6 octets): 343 AFI/SAFI - 3 octets 344 Number of prefixes 4 octets 346 Use: To indicate number of prefixes kept in BGP RIB for a given 347 AFI/SAFI. 349 Type 11 - Number of paths present in BGP_RIB 350 Length - 2 octets - variable value 352 Value (N x 7 octets): 353 AFI/SAFI - 3 octets 354 Number of prefixes 4 octets 356 Use: To indicate number of paths kept in BGP RIB for a given 357 AFI/SAFI. 359 3.2.3. Diagnostics for encoding errors in BGP messages 361 Type 12 - Reachable prefixes present in dropped attribute UPDATE msg 362 Length - 2 octets - variable value 364 Value (N octets): 365 AFI/SAFI - 3 octets 366 1 .. M - List of prefixes 368 Use: To list reachable prefixes present in the update message 369 where optional transitive attribute with partial bit set 370 was malformed and has been removed from the update message. 371 Prefix encoding should follow given AFI/SAFI definition. 373 Type 13 - Unreachable prefixes present in dropped attribute UPDATE msg 374 Length - 2 octets - variable value 376 Value (N octets): 377 AFI/SAFI - 3 octets 378 1 .. M - List of prefixes 380 Use: To list unreachable prefixes present in the update message 381 where optional transitive attribute with partial bit set 382 was malformed and has been removed from the update message. 383 Prefix encoding should follow given AFI/SAFI definition. 385 Type 14 - Reachable prefixes present in malformed UPDATE msg 386 Length - 2 octets - variable value 388 Value (N octets): 389 AFI/SAFI - 3 octets 390 1 .. M - List of prefixes 392 Use: To list reachable prefixes present in the malformed update 393 message which were subject to "treat-as-withdraw" behaviour. 394 Prefix encoding should follow given AFI/SAFI definition. 396 Type 15 - Entire malformed update message enclosure 397 Length - 2 octets - variable value 398 Sequence number - 8 octets 400 Value: 401 Malformed message 403 Use: Propagate the malformed message to the peer upon it's 404 request or at the event of error detection. That includes 405 propagation of messages which had malformed attribute, 406 unparsable content or any other abnormal encoding. If more 407 then a single message has been determined as malformed the 408 subsequent replies will contain the same sequence number 409 and should not be treated as an override. 411 3.2.4. AFI/SAFI signaling when malformed update 413 Type 16 - List of ignored AFI/SAFIs by the peer over given session 414 Length - 2 octets - variable value 416 Value (N octets): 417 1..M AFI/SAFI - 3 octets each 419 Use: To list those AFI/SAFIs which were detected to be malformed 420 by the peer and while session is up were transitioned to 421 IGNORE state. 423 Such case is inline with Multiprotocol Extensions 424 RFC 4760 as per it's section 7 Error Handling: 426 "For the duration of the BGP session over which the UPDATE 427 message was received, the speaker then SHOULD ignore all 428 the subsequent routes with that AFI/SAFI received over 429 that session". 431 3.2.5. Prefix specific BGP debugging 433 Type 17 - Prefix specific BGP query 434 Length - 2 octets - variable value 436 Value (N octets): 437 AFI/SAFI - 3 octets 438 Prefix under query 439 Prefix mask (optional) 441 Use: To query peer for the status of prefix under examination. 442 When prefix mask is present the request is for exact match. 443 When prefix mask is not present the request is for the 444 longest match. Prefix encoding should follow given AFI/SAFI 445 definition. 447 Type 18 - Prefix specific BGP response 448 Length - 2 octets - variable value 450 Value (N octets): 451 AFI/SAFI - 3 octets 452 Prefix under query 453 Prefix mask (optional) 454 Prefix status (1 octet) 456 Status: 457 0x01 - prefix not found in BGP table 458 0x02 - prefix in BGP table and active (in FIB) 459 0x03 - prefix in BGP table and not-active (not in FIB) 460 0x04 - administratively disabled 462 Use: To inform peer querying about the status of particular 463 prefix status. Prefix encoding should follow given AFI/SAFI 464 definition. 466 3.2.6. Intra-domain bgp decision monitoring 468 Type 19 - Number of IGP metric best path tie breaks executed 469 Length - 2 octets - variable value 471 Value (N x 7 octets): 472 AFI/SAFI - 3 octets 473 Number of tie breaks 4 octets 475 Use: To indicate number of prefixes with their best path selected 476 by tie break of IGP metric to their BGP next hop distance 477 step of BGP best path selection algorithm. 479 Type 20 - Number of BGP best path tie breaks in each selection step 480 Length - 2 octets - variable value 482 Value (N x 7 octets): 483 AFI/SAFI - 3 octets 484 Best path selection step N - Number of tie breaks 4 octets 486 Use: To indicate number of cases where in BGP best path selection 487 algorithm given step has been used as a tie break during 488 overall best path selection process for a given prefix. 490 3.2.7. Exchange of installed Route Target filters 492 Type 21 - Request for reception of route target filters 493 installed towards given peer by RFC4684 494 Length - 2 octets - variable value 495 Sequence number - 8 octets 497 Value (N x 7 octets): 498 AFI/SAFI - 3 octets 499 BGP Router ID of the peer - 4 octets 501 Use: To request reception of full table of route target 502 fiters installed towards listed BGP peer for a requested 503 AFI/SAFI. Single request may contain multiple pairs of 504 AFI/SAFIs and/or BGP Router IDs. 506 Type 22 - Reply containing all route target filters installed 507 towards given peer 508 Length - 2 octets - variable value 509 Sequence number - 8 octets 511 Value (7 + N * 12 or 24 octets): 512 AFI/SAFI - 3 octets 513 BGP Router ID of the peer - 4 octets 514 List of route targets - each 12 or 24 octets 516 Use: Allows for troubleshooting purposes to share list of 517 route targets installed for a given AFI/SAFI towards 518 indicated BGP peer. In the event that RT filtering 519 table size will not fit in single BGP Diagnostic 520 Message reply the subsequent reply should include 521 the same sequence number. 523 4. Operation 525 BGP implementation which supports DIAGNOSTIC message can support all 526 or subset of defined diagnostic types. The range of supported TLV 527 types will be signaled in the new BGP capability message during BGP 528 connection establishment phase. 530 The operation of this extension can be realized on a pool/query based 531 or push based principles. An implementation may provide, a timer to 532 periodically send selected Diagnostic types TLVs to the peer or to 533 the management station. 535 Similarly BGP peer may periodically or by manual cli request the 536 reception of selected or all of the defined diagnostic TLV types. 538 The received values are then compared against local counters. When 539 discrepancy is found operator is alarmed and further analysis should 540 follow. The repair actions is out of scope of this document. 542 Example: 544 Under some situations when determined that the discrepancy is 545 detected an automated or manual Route Refresh message can be 546 triggered with it's extension for Start_of_Refresh and End_of_Refresh 547 markers . That would allow for purge of any stalled data across two 548 BGP databases. 550 An important point which needs to be discussed is the exchange of 551 counter's values in light of continued BGP churn presence. As BGP is 552 never stable it is expected that any sort of described counters will 553 also be subject to continues value change making any comparison of 554 their values questionable. 556 There are three classes of counters defined in this document: sent 557 counters, received counters and current table state counters. 559 Only "sent" counters can be used for not correlated comparison and 560 problem detection between any two BGP speakers. They are not subject 561 to BGP churn issue due to the fact that DIAGNOSTIC messages would be 562 exchanged inline with BGP UPDATE messages on a given session. An 563 implementation must be able to freeze the received counters when 564 comparing or displaying the received "sent" counters from BGP peer. 566 Received counters send in the Diagnostic messages are only meaningful 567 in the context of explicit request trigger situation generated by the 568 BGP speaker. BGP speaker should stop transmitting any BGP message of 569 a given AFI/SAFI or freeze corresponding counter after sending 570 diagnostic message request to the peer and before reception of actual 571 diagnostic message reply. In order to correlate diagnostic message 572 requests with associated replies use of build in sequence numbers is 573 provided. 575 Table state counters (for example number of BGP RIB entries) are 576 exchanged only for informational reasons and they should not be 577 subject to comparison with any local counter values. 579 5. Capability negotiation 581 A BGP speaker that is willing to send or receive the BGP DIAGNOSTIC 582 Messages from its peer should advertise the new DIAGNOSTIC Messages 583 Capability to the peer using BGP Capabilities advertisement [BGP- 584 CAP]. A BGP speaker may send a DIAGNOSTIC message to its peer only 585 if it has received the DIAGNOSTIC message capability from its peer. 587 The Capability Code for this capability is specified in the IANA 588 Considerations section of this document. 590 The Capability Length field of this capability is 2 octets. The 591 Capability Value field consists of reserved flags field. 593 +------------------------------+ 594 | Capability Code (1 octet) | 595 +------------------------------+ 596 | Capability Length (1 octet) | 597 +------------------------------+ 598 | Flags (2 octets) | 599 +------------------------------+ 601 Figure 2: DIAGNOSTIC message BGP Capability Format 603 6. Security considerations 605 No new security issues are introduced to the BGP protocol by this 606 specification. 608 7. IANA Considerations 610 IANA is requested to allocate a type code for the DIAGNOSTIC message 611 from the BGP Message Types registry, as well as requesting a type 612 code for the new Diagnostic Message Capability negotiation from BGP 613 Capability Codes registry. 615 This document requests IANA to define and maintain a new registry 616 named: "DIAGNOSTIC Message Type Values". The reserved types are: 617 0x0000 0xFFFF. The allocation policy is on a first come first served 618 basis. 620 This document makes the following assignments for the DIAGNOSTIC 621 Message Type Values: 623 Type 1 - Diagnostic Message TLV(s) Request 624 Type 2 - Max frequency permitted 625 Type 3 - Diagnostic Message TLV(s) Query 626 Type 4 - Counter's reset request 627 Type 5 - Not supported TLV 628 Type 6 - Enabled and supported TLV types 630 Type 7 - Number of Reachable Prefixes Transmitted/Received 631 Type 8 - Number of prefixes in BGP_RIB_Out 632 Type 9 - Number of paths in BGP_RIB_Out 633 Type 10 - Number of prefixes present in BGP_RIB 634 Type 11 - Number of paths present in BGP_RIB 636 Type 12 - Reachable prefixes present in dropped attribute message 637 Type 13 - Unreachable prefixes present in dropped attribute message 638 Type 14 - Reachable prefixes present in malformed UPDATE message 639 Type 15 - Entire malformed update message enclosure 641 Type 16 - List of ignored AFI/SAFIs by the peer over given session 643 Type 17 - Prefix specific BGP query 644 Type 18 - Prefix specific BGP response 646 Type 19 - Number of IGP metric best path tie breaks executed 647 Type 20 - Number of BGP best path tie breaks in each selection step 649 Type 21 - Request for reception of route target filters 650 Type 22 - Reply containing all route target filters installed 652 Type 23 - 65534 Free for future allocation. 653 Type 65535 - Reserved 655 8. Acknowledgments 657 Authors would like to thank Alton Lo for his valuable input. 659 9. Normative References 661 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 662 Requirement Levels", BCP 14, RFC 2119, March 1997. 664 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 665 Protocol 4 (BGP-4)", RFC 4271, January 2006. 667 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 668 with BGP-4", RFC 5492, February 2009. 670 Authors' Addresses 672 Robert Raszuk 673 Cisco Systems 674 170 West Tasman Drive 675 San Jose, CA 95134 676 US 678 Email: raszuk@cisco.com 680 Enke Chen 681 Cisco Systems 682 170 West Tasman Drive 683 San Jose, CA 95134 684 US 686 Email: enkechen@cisco.com 688 Bruno Decraene 689 France Telecom 690 38-40 rue du General Leclerc 691 Issi Moulineaux cedex 9 92794 692 France 694 Email: bruno.decraene@orange-ftgroup.com