idnits 2.17.1 draft-raszuk-bgp-diagnostic-message-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 429 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 (March 9, 2011) is 4797 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 639, but not defined == Unused Reference: 'RFC2119' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 724, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 727, but no explicit reference was found in the text == Unused Reference: 'I-D.retana-bgp-security-state-diagnostic' is defined on line 732, but no explicit reference was found in the text == Unused Reference: 'I-D.shakir-idr-ops-reqs-for-bgp-error-handling' is defined on line 737, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 9 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: September 10, 2011 B. Decraene 6 France Telecom 7 March 9, 2011 9 BGP Diagnostic Message 10 draft-raszuk-bgp-diagnostic-message-01 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 September 10, 2011. 45 Copyright Notice 47 Copyright (c) 2011 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 . . . . . . . . . 14 73 3.2.7. Exchange of installed Route Target filters . . . . . . 15 74 3.2.8. Errors and warnings detected when validating BGP 75 paths and prefixes . . . . . . . . . . . . . . . . . . 16 76 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 5. Capability negotiation . . . . . . . . . . . . . . . . . . . . 17 78 6. Security considerations . . . . . . . . . . . . . . . . . . . 18 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 80 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 86 1. Introduction 88 In this document we will first define a new diagnostic communication 89 channel in the form of new BGP message then construct the set of 90 basic message encoding to be used for simple diagnostic self test 91 routines periodically exchanged between BGP speakers. We will also 92 define set of other TLVs which can be very useful in precise 93 description of prefixes affected by various cases of BGP session 94 malfunctions. 96 The goal of this document is to provide the background which will in 97 turn allow for very easy extensibility once new needs and new BGP 98 diagnostic ideas surface. 100 2. Applications 102 Authors would like to propose four main applications which BGP 103 Diagnostic TLVs are designed to address. New TLVs can be easily 104 added to enhance further current applications or to propose new 105 applications. 107 The set of TLVs is organized in the following application groups: 109 General TLVs used for operational purposes of the described 110 mechanism. 112 Set of TLVs designed to carry information about BGP state across 113 BGP peers that include per neighbor counters and global counters. 114 There are two modes this functionality can be used - on demand by 115 explicit query as well as periodic in an automated mode. The 116 scope of messages is to be able to operate both on the iBGP as 117 well as eBGP boundaries. It is in the control of the operator to 118 decide which set of information would be send to a given set of 119 peers. 121 Messages which operate in an automated push mode (as long as peer 122 negotiated listen capability for them) and are designed to inform 123 BGP peer on the list of impacted NLRIs which were received along 124 with malformed attribute or within malformed update message. 126 Following recommendation from MP-BGP4 RFC4760 next group of 127 messages are used to indicate which AFI/SAFIs were disabled for 128 any further processing by BGP peer due to detection of an 129 incorrect attribute present in the BGP Update message. 131 In number of troubleshooting efforts in real networks it is often 132 very helpful to verify state of a given prefix in the neighboring 133 router's BGP database. This is particularly useful on the EBGP 134 boundaries where there is no CLI/SNMP access to the router. 135 Authors define a new way of query peer's BGP for the state of 136 particular prefix. 138 Last set of messages is an attempt to allow for intra-domain 139 better analysis of the BGP best path selection tie break 140 decisions. 142 3. BGP diagnostic message 144 When defining any self test tool the critical element is to find a 145 right separation balance between the test object and testing 146 instruments. 148 For the vast majority of real BGP issues found in the life production 149 networks authors believe that the right balance is the definition of 150 new BGP message which could be exchanged along with any negotiated 151 AFI/SAFI between those BGP speakers which will during initial OPEN 152 message exchange new BGP diagnostic message capability. 154 The two extreme alternatives which were considered were the 155 definition of new BGP attribute which may inherit and share potential 156 issues of given BGP address family it is designed to diagnose and on 157 the other extreme to build a separate and independent network 158 diagnostic protocol. The use of BGP message seems to provide 159 sufficient isolation from any service address family and is much 160 easier to deploy then enabling an entire new intra and inter-domain 161 protocol. Another very important issue with using any other protocol 162 for detection of potential differences of BGP databases state is lack 163 of synchronization with BGP UPDATE messages. This alone in the 164 continuously churning BGP environment would not allow for any 165 benefit. 167 3.1. BGP DIAGNOSTIC Message Encoding 169 BGP message as defined in RFC 4271 consists of a fixed-size header 170 followed by two octet length field and one octet of type value. RFC 171 4271 limits maximum message size to 4096 octets. As one of the 172 applications of BGP Diagnostic message is to be able to carry entire 173 potentially malformed BGP message this specification extends the 174 maximum size of BGP Diagnostic message to be always 128 octets bigger 175 then any other BGP Message. Considering the current RFC 4271 maximum 176 BGP message size to be 4096 octets maximum size of BGP diagnostic 177 message would be 4224 octets. 179 For the purpose of diagnostic message information encoding we will 180 use one or more Type-Length-Value containers where each TLV will have 181 the following format: 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type | Length | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Variable size TLV value | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 1: DIAGNOSTIC message TLV Format 193 Type - 2 octet value indicating the TLV type 194 Length - 2 octet value indicating the TLV length in octets 195 Value - Variable length value field depending on the type of 196 the TLVs carried. 198 To work around continued BGP churn issue some types of TLVs will need 199 to contain a sequence number to correlate request with associated to 200 it replies. The sequence number will consist of 8 octets and will be 201 of form: 4 octet bgp_router_id + local 4 octet number. When local 4 202 octet number reaches 0xFFFF it should restart from 0x0000. 204 Typical application scenario for use of sequence number is to include 205 it in the diagnostic request message and during reply to copy it into 206 reply messages triggered by such request message. 208 3.2. BGP DIAGNOSTIC Message TLVs 210 This document defines the following diagnostic TLV types: 212 * Operational TLVs 214 * BGP database counters exchange 216 * Diagnostics for encoding errors in BGP messages 218 * AFI/SAFI signaling when malformed update 220 * Prefix specific BGP debugging 222 * Intra-domain bgp decision monitoring 223 * Exchange of Route Target filters 225 * Errors and warnings detected when validating BGP paths and prefixes 227 3.2.1. Operational TLVs 229 Type 1 - Diagnostic Message Periodic Request 230 Length - 2 octets - variable value 232 Value (N x 2 octets): 233 TLV type - 2 octets 235 Use: To indicate the request to periodically receive listed TLV 236 information. TLV type of 0xFFFF indicates request to receive 237 all available diagnostic TLVs from the peer. 239 Type 2 - Max frequency permitted 240 Length - 2 octets - variable value 242 Value (N x 4 octets): 243 TLV type - 2 octets 244 Frequency value in seconds two octets 0..65535 246 Special values: 247 0 - never send given diagnostic TLV 248 65535 - no TLV inter-gap minimum set 250 Use: To indicate in seconds the maximum frequency given TLV 251 may be periodically sent to the bgp speaker 253 Type 3 - Diagnostic Message Query 254 Length - 2 octets - variable value 255 Sequence number - 8 octets 257 Value (N x 2 octets): 258 TLV type - 2 octets 260 Use: To interactively (during debugging/troubleshooting) request 261 to receive listed TLV information. TLV type of 0xFFFF 262 indicates request to receive all available diagnostic TLVs 263 from the peer. TLV of type 0x0000 indicates request to 264 receive a list of all enabled and available diagnostic 265 TLV types from the peer towards querying BGP speaker. The 266 support of this TLV type is mandatory. 268 Type 4 - Counter's reset request 269 Length - 2 octets - variable value 271 Value (N x 2 octets): 272 TLV type - 2 octets - List of TLVs subject to counter's reset. 274 Use: To request rest of per neighbor counters of a given TLV 275 type. TLV type of 0xFFFF indicates request to zero all 276 per neighbor counters. 278 Type 5 - Not supported TLV reply 279 Length - 2 octets - variable value 281 Value (N x 3 octets): 282 TLV type - 2 octets - TLV that is not supported by the peer 283 but where part of TLV Request or TLV Query message 284 Error Code - 1 octet - Error code 286 Error codes: 288 0x01 - Wrong TLV value 289 0x02 - TLV not supported for this peer 290 0x03 - Max query frequency exceeded 291 0x04 - Administratively disabled 293 Use: To indicate to the peer that the TLV he has requeste 294 either in TLV Request or in TLV Query message is not 295 supported. The support of this TLV type is mandatory. 297 Type 6 - Enabled and supported TLV types 298 Length - 2 octets - variable value 300 Value (N x 2 octets): 301 TLV type - 2 octets - TLV that is enabled and supported 302 by the peer 304 Use: To indicate to the peer that the enclosed list of TLVs 305 can be requested either in TLV Request or in TLV Query 306 messages. The support of this TLV type is mandatory. 308 3.2.2. BGP database counters exchange 310 Type 7 - Number of Reachable Prefixes Transmitted/Received 311 Length - 2 octets - variable value 312 Sequence number - 8 octets 314 Value (N x 11 octets): 315 AFI/SAFI - 3 octets 316 Number of prefixes transmitted - 4 octets 317 Number of prefixes received - 4 octets 319 Use: To indicate number of reachable prefixes exchanged for 320 a given AFI/SAFI between two bgp speakers. This message 321 can be sent only based on the remote query Type 3 which 322 contains the query sequence number to be placed in the 323 reply. 325 Type 8 - Number of prefixes in BGP_RIB_Out 326 Length - 2 octets - variable value 328 Value (N x 7 octets): 329 AFI/SAFI - 3 octets 330 Number of prefixes 4 octets 332 Use: To indicate number of prefixes kept in BGP_RIB_Out between 333 bgp speakers for a given AFI/SAFI between two bgp speakers. 335 Type 9 - Number of paths in BGP_RIB_Out 336 Length - 2 octets - variable value 338 Value (N x 6 octets): 339 AFI/SAFI - 3 octets 340 Number of paths 4 octets 342 Use: To indicate number of paths kept in BGP_RIB_Out between bgp 343 speakers for a given AFI/SAFI between two bgp speakers. 345 Type 10 - Number of prefixes present in BGP_RIB 346 Length - 2 octets - variable value 348 Value (N x 6 octets): 349 AFI/SAFI - 3 octets 350 Number of prefixes 4 octets 352 Use: To indicate number of prefixes kept in BGP RIB for a given 353 AFI/SAFI. 355 Type 11 - Number of paths present in BGP_RIB 356 Length - 2 octets - variable value 358 Value (N x 7 octets): 359 AFI/SAFI - 3 octets 360 Number of prefixes 4 octets 362 Use: To indicate number of paths kept in BGP RIB for a given 363 AFI/SAFI. 365 3.2.3. Diagnostics for encoding errors in BGP messages 367 Type 12 - Reachable prefixes present in dropped attribute UPDATE msg 368 Length - 2 octets - variable value 370 Value (N octets): 371 AFI/SAFI - 3 octets 372 1 .. M - List of prefixes 374 Use: To list reachable prefixes present in the update message 375 where optional transitive attribute with partial bit set 376 was malformed and has been removed from the update message. 377 Prefix encoding should follow given AFI/SAFI definition. 379 Type 13 - Unreachable prefixes present in dropped attribute UPDATE msg 380 Length - 2 octets - variable value 382 Value (N octets): 383 AFI/SAFI - 3 octets 384 1 .. M - List of prefixes 386 Use: To list unreachable prefixes present in the update message 387 where optional transitive attribute with partial bit set 388 was malformed and has been removed from the update message. 389 Prefix encoding should follow given AFI/SAFI definition. 391 Type 14 - Reachable prefixes present in malformed UPDATE msg 392 Length - 2 octets - variable value 394 Value (N octets): 395 AFI/SAFI - 3 octets 396 1 .. M - List of prefixes 398 Use: To list reachable prefixes present in the malformed update 399 message which were subject to "treat-as-withdraw" behaviour. 400 Prefix encoding should follow given AFI/SAFI definition. 402 Type 15 - Entire malformed update message enclosure 403 Length - 2 octets - variable value 404 Sequence number - 8 octets 406 Value: 407 Malformed message 409 Use: Propagate the malformed message to the peer upon it's 410 request or at the event of error detection. That includes 411 propagation of messages which had malformed attribute, 412 unparsable content or any other abnormal encoding. If more 413 then a single message has been determined as malformed the 414 subsequent replies will contain the same sequence number 415 and should not be treated as an override. 417 3.2.4. AFI/SAFI signaling when malformed update 419 Type 16 - List of ignored AFI/SAFIs by the peer over given session 420 Length - 2 octets - variable value 422 Value (N octets): 423 1..M AFI/SAFI - 3 octets each 425 Use: To list those AFI/SAFIs which were detected to be malformed 426 by the peer and while session is up were transitioned to 427 IGNORE state. 429 Such case is inline with Multiprotocol Extensions 430 RFC 4760 as per it's section 7 Error Handling: 432 "For the duration of the BGP session over which the UPDATE 433 message was received, the speaker then SHOULD ignore all 434 the subsequent routes with that AFI/SAFI received over 435 that session". 437 3.2.5. Prefix specific BGP debugging 439 Type 17 - Prefix specific BGP query 440 Length - 2 octets - variable value 442 Value (N octets): 443 AFI/SAFI - 3 octets 444 Prefix under query 445 Prefix mask (optional) 447 Use: To query peer for the status of prefix under examination. 448 When prefix mask is present the request is for exact match. 449 When prefix mask is not present the request is for the 450 longest match. Prefix encoding should follow given AFI/SAFI 451 definition. 453 Type 18 - Prefix specific BGP response 454 Length - 2 octets - variable value 456 Value (N octets): 457 AFI/SAFI - 3 octets 458 Prefix under query 459 Prefix mask (optional) 460 Prefix status (1 octet) 462 Status: 463 0x01 - prefix not found in BGP table 464 0x02 - prefix in BGP table and active (in FIB) 465 0x03 - prefix in BGP table and not-active (not in FIB) 466 0x04 - administratively disabled 468 Use: To inform peer querying about the status of particular 469 prefix status. Prefix encoding should follow given AFI/SAFI 470 definition. 472 Type 19 - BGP attribute based prefix query 473 Length - 2 octets - variable value 475 Value (N octets): 476 AFI/SAFI - 3 octets 477 Query Parameters - 1 octet 478 BGP Attribute TLV 480 Defined Query Parameters: 481 Bit 0 - value 0 - Exact match 482 Bit 0 - value 1 - Partial match 484 Use: To query peer for the list of prefixes which paths contain 485 given BGP attribute. BGP attribute encoding should follow 486 given attribute's specification. 488 Type 20 - BGP attribute based prefix reply 489 Length - 2 octets - variable value 491 Value (N octets): 492 AFI/SAFI - 3 octets 493 Query Parameters - 1 octet 494 1 .. M - List of prefixes 496 Defined Query Parameters: 497 Bit 0 - value 0 - Exact match 498 Bit 0 - value 1 - Partial match 500 Use: To inform bgp peer about presence of set of prefixes 501 which contain with exact or partial match the BGP 502 Attribute as specified in the query. Prefix encoding 503 should follow given AFI/SAFI definition. 505 3.2.6. Intra-domain bgp decision monitoring 507 Type 21 - Number of IGP metric best path tie breaks executed 508 Length - 2 octets - variable value 510 Value (N x 7 octets): 511 AFI/SAFI - 3 octets 512 Number of tie breaks 4 octets 514 Use: To indicate number of prefixes with their best path selected 515 by tie break of IGP metric to their BGP next hop distance 516 step of BGP best path selection algorithm. 518 Type 22 - Number of BGP best path tie breaks in each selection step 519 Length - 2 octets - variable value 521 Value (N x 7 octets): 522 AFI/SAFI - 3 octets 523 Best path selection step N - Number of tie breaks 4 octets 525 Use: To indicate number of cases where in BGP best path selection 526 algorithm given step has been used as a tie break during 527 overall best path selection process for a given prefix. 529 3.2.7. Exchange of installed Route Target filters 531 Type 23 - Request for reception of route target filters 532 installed towards given peer by RFC4684 533 Length - 2 octets - variable value 534 Sequence number - 8 octets 536 Value (N x 7 octets): 537 AFI/SAFI - 3 octets 538 BGP Router ID of the peer - 4 octets 540 Use: To request reception of full table of route target 541 fiters installed towards listed BGP peer for a requested 542 AFI/SAFI. Single request may contain multiple pairs of 543 AFI/SAFIs and/or BGP Router IDs. 545 Type 24 - Reply containing all route target filters installed 546 towards given peer 547 Length - 2 octets - variable value 548 Sequence number - 8 octets 550 Value (7 + N * 12 or 24 octets): 551 AFI/SAFI - 3 octets 552 BGP Router ID of the peer - 4 octets 553 List of route targets - each 12 or 24 octets 555 Use: Allows for troubleshooting purposes to share list of 556 route targets installed for a given AFI/SAFI towards 557 indicated BGP peer. In the event that RT filtering 558 table size will not fit in single BGP Diagnostic 559 Message reply the subsequent reply should include 560 the same sequence number. 562 3.2.8. Errors and warnings detected when validating BGP paths and 563 prefixes 565 Type 25 - INVALID prefixes detected while performing BGP 566 Origin Validation [pmohapat-sidr-pfx-validate] 567 Length - 2 octets - variable value 569 Value (N octets): 570 AFI/SAFI - 3 octets 571 1 .. M - List of prefixes 573 Use: To signal set of prefixes received from a peer which 574 during inbound BGP Origin Validation were found and 575 considered INVALID as [pmohapat-sidr-pfx-validate] 576 definition. Prefix encoding should follow given AFI/SAFI 577 definition. 579 4. Operation 581 BGP implementation which supports DIAGNOSTIC message can support all 582 or subset of defined diagnostic types. The range of supported TLV 583 types will be signaled in the new BGP capability message during BGP 584 connection establishment phase. 586 The operation of this extension can be realized on a pool/query based 587 or push based principles. An implementation may provide, a timer to 588 periodically send selected Diagnostic types TLVs to the peer or to 589 the management station. 591 Similarly BGP peer may periodically or by manual cli request the 592 reception of selected or all of the defined diagnostic TLV types. 594 The received values are then compared against local counters. When 595 discrepancy is found operator is alarmed and further analysis should 596 follow. The repair actions is out of scope of this document. 598 Example: 600 Under some situations when determined that the discrepancy is 601 detected an automated or manual Route Refresh message can be 602 triggered with it's extension for Start_of_Refresh and End_of_Refresh 603 markers . That would allow for purge of any stalled data across two 604 BGP databases. 606 An important point which needs to be discussed is the exchange of 607 counter's values in light of continued BGP churn presence. As BGP is 608 never stable it is expected that any sort of described counters will 609 also be subject to continues value change making any comparison of 610 their values questionable. 612 There are three classes of counters defined in this document: sent 613 counters, received counters and current table state counters. 615 Only "sent" counters can be used for not correlated comparison and 616 problem detection between any two BGP speakers. They are not subject 617 to BGP churn issue due to the fact that DIAGNOSTIC messages would be 618 exchanged inline with BGP UPDATE messages on a given session. An 619 implementation must be able to freeze the received counters when 620 comparing or displaying the received "sent" counters from BGP peer. 622 Received counters send in the Diagnostic messages are only meaningful 623 in the context of explicit request trigger situation generated by the 624 BGP speaker. BGP speaker should stop transmitting any BGP message of 625 a given AFI/SAFI or freeze corresponding counter after sending 626 diagnostic message request to the peer and before reception of actual 627 diagnostic message reply. In order to correlate diagnostic message 628 requests with associated replies use of build in sequence numbers is 629 provided. 631 Table state counters (for example number of BGP RIB entries) are 632 exchanged only for informational reasons and they should not be 633 subject to comparison with any local counter values. 635 5. Capability negotiation 637 A BGP speaker that is willing to send or receive the BGP DIAGNOSTIC 638 Messages from its peer should advertise the new DIAGNOSTIC Messages 639 Capability to the peer using BGP Capabilities advertisement [BGP- 640 CAP]. A BGP speaker may send a DIAGNOSTIC message to its peer only 641 if it has received the DIAGNOSTIC message capability from its peer. 643 The Capability Code for this capability is specified in the IANA 644 Considerations section of this document. 646 The Capability Length field of this capability is 2 octets. The 647 Capability Value field consists of reserved flags field. 649 +------------------------------+ 650 | Capability Code (1 octet) | 651 +------------------------------+ 652 | Capability Length (1 octet) | 653 +------------------------------+ 654 | Flags (2 octets) | 655 +------------------------------+ 657 Figure 2: DIAGNOSTIC message BGP Capability Format 659 6. Security considerations 661 No new security issues are introduced to the BGP protocol by this 662 specification. 664 7. IANA Considerations 666 IANA is requested to allocate a type code for the DIAGNOSTIC message 667 from the BGP Message Types registry, as well as requesting a type 668 code for the new Diagnostic Message Capability negotiation from BGP 669 Capability Codes registry. 671 This document requests IANA to define and maintain a new registry 672 named: "DIAGNOSTIC Message Type Values". The reserved types are: 673 0x0000 0xFFFF. The allocation policy is on a first come first served 674 basis. 676 This document makes the following assignments for the DIAGNOSTIC 677 Message Type Values: 679 Type 1 - Diagnostic Message TLV(s) Request 680 Type 2 - Max frequency permitted 681 Type 3 - Diagnostic Message TLV(s) Query 682 Type 4 - Counter's reset request 683 Type 5 - Not supported TLV 684 Type 6 - Enabled and supported TLV types 686 Type 7 - Number of Reachable Prefixes Transmitted/Received 687 Type 8 - Number of prefixes in BGP_RIB_Out 688 Type 9 - Number of paths in BGP_RIB_Out 689 Type 10 - Number of prefixes present in BGP_RIB 690 Type 11 - Number of paths present in BGP_RIB 692 Type 12 - Reachable prefixes present in dropped attribute message 693 Type 13 - Unreachable prefixes present in dropped attribute message 694 Type 14 - Reachable prefixes present in malformed UPDATE message 695 Type 15 - Entire malformed update message enclosure 697 Type 16 - List of ignored AFI/SAFIs by the peer over given session 699 Type 17 - Prefix specific BGP query 700 Type 18 - Prefix specific BGP response 701 Type 19 - BGP attribute based prefix query 702 Type 20 - BGP attribute based prefix reply 704 Type 21 - Number of IGP metric best path tie breaks executed 705 Type 22 - Number of BGP best path tie breaks in each selection step 707 Type 23 - Request for reception of route target filters 708 Type 24 - Reply containing all route target filters installed 710 Type 25 - 65534 Free for future allocation. 711 Type 65535 - Reserved 713 8. Acknowledgments 715 Authors would like to thank Alton Lo for his valuable input. 717 9. References 719 9.1. Normative References 721 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 722 Requirement Levels", BCP 14, RFC 2119, March 1997. 724 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 725 Protocol 4 (BGP-4)", RFC 4271, January 2006. 727 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 728 with BGP-4", RFC 5492, February 2009. 730 9.2. Informative References 732 [I-D.retana-bgp-security-state-diagnostic] 733 Retana, A. and R. Raszuk, "BGP Security State Diagnostic 734 Message", draft-retana-bgp-security-state-diagnostic-00 735 (work in progress), March 2011. 737 [I-D.shakir-idr-ops-reqs-for-bgp-error-handling] 738 Shakir, R., "Operational Requirements for Enhanced Error 739 Handling Behaviour in BGP-4", 740 draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 (work 741 in progress), February 2011. 743 Authors' Addresses 745 Robert Raszuk 746 Cisco Systems 747 170 West Tasman Drive 748 San Jose, CA 95134 749 US 751 Email: raszuk@cisco.com 753 Enke Chen 754 Cisco Systems 755 170 West Tasman Drive 756 San Jose, CA 95134 757 US 759 Email: enkechen@cisco.com 761 Bruno Decraene 762 France Telecom 763 38-40 rue du General Leclerc 764 Issi Moulineaux cedex 9 92794 765 France 767 Email: bruno.decraene@orange-ftgroup.com