idnits 2.17.1 draft-frs-bgp-operational-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 == 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 (June 30, 2011) is 4684 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: 'RFC2119' is defined on line 819, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 828, but no explicit reference was found in the text == Unused Reference: 'I-D.jasinska-ix-bgp-route-server' is defined on line 845, but no explicit reference was found in the text == Unused Reference: 'I-D.nalawade-bgp-inform' is defined on line 851, but no explicit reference was found in the text == Unused Reference: 'I-D.nalawade-bgp-soft-notify' is defined on line 856, but no explicit reference was found in the text == Unused Reference: 'I-D.retana-bgp-security-state-diagnostic' is defined on line 866, 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 871, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) == Outdated reference: A later version (-03) exists of draft-jasinska-ix-bgp-route-server-02 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group D. Freedman 3 Internet-Draft Claranet 4 Intended status: Standards Track R. Raszuk 5 Expires: January 1, 2012 Cisco Systems 6 R. Shakir 7 C&W 8 June 30, 2011 10 BGP OPERATIONAL Message 11 draft-frs-bgp-operational-message-00 13 Abstract 15 The BGP Version 4 routing protocol (RFC4271) is now used in many 16 ways, crossing boundaries of administrative and technical 17 responsibility. 19 The protocol lacks an operational messaging plane which could be 20 utilised to diagnose, troubleshoot and inform upon various conditions 21 across these boundaries, securely, during protocol operation, without 22 disruption. 24 This document proposes a new BGP message type, the OPERATIONAL 25 message, which can be used to effect such a messaging plane for use 26 both between and within Autonomous Systems. 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 January 1, 2012. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. BGP OPERATIONAL message . . . . . . . . . . . . . . . . . . . 5 65 3.1. BGP OPERATIONAL message capability . . . . . . . . . . . . 5 66 3.2. BGP OPERATIONAL message encoding . . . . . . . . . . . . . 5 67 3.3. PRI Format . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.4. BGP OPERATIONAL message TLVs . . . . . . . . . . . . . . . 9 69 3.4.1. ADVISE TLVs . . . . . . . . . . . . . . . . . . . . . 9 70 3.4.2. STATE TLVs . . . . . . . . . . . . . . . . . . . . . . 10 71 3.4.3. DUMP TLVs . . . . . . . . . . . . . . . . . . . . . . 11 72 3.4.4. CONTROL TLVs . . . . . . . . . . . . . . . . . . . . . 13 73 4. On the use of STATE and DUMP TLVs . . . . . . . . . . . . . . 16 74 5. On the use of ADVISE TLVs . . . . . . . . . . . . . . . . . . 17 75 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 19 76 7. Security considerations . . . . . . . . . . . . . . . . . . . 20 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 84 1. Introduction 86 In this document, a new BGP message type, the OPERATIONAL message is 87 defined, creating a communication channel over which messages can be 88 passed, using a series of contained TLV elements. 90 The messages can be human readable, for the attention of device 91 operators or machine readable, in order to provide simple self test 92 routines, which can be exchanged between BGP speakers. 94 A number of TLV elements will be assigned to provide for these 95 message types, along with TLV elements to assist with description of 96 the message data, such as describing precisely BGP prefixes and 97 encapsulating BGP UPDATE messages to be sent back for inspection in 98 order to troubleshoot session malfunctions. 100 The use of OPERATIONAL messages will be negotiated by BGP Capability 101 [RFC5492], since the messages are in-band with the BGP session, they 102 can be assumed to either be authenticated as originating directly 103 from the BGP neighbor. 105 The goal of this document is to provide a simple, extensible 106 framework within which new messaging and diagnostic requirements can 107 live. 109 2. Applications 111 The authors would like to propose three main applications which BGP 112 OPERATIONAL TLVs are designed to address. New TLVs can be easily 113 added to enhance further current applications or to propose new 114 applications. 116 The set of TLVs is organised in the following four functional groups 117 comprising the three applications and some control messaging: 119 o ADVISE TLVs, designed to convey human readable information to be 120 passed, cross boundary to operators, to inform them of past or 121 upcoming error conditions, or provide other relevant, in-band 122 operational information. The "Advisory Demand Message" ADM 123 (Section 3.4.1.1) is an example of this. 125 o STATE TLVs, designed to carry information about BGP state across 126 BGP neighbors, including both per-neighbor and global counters. 128 o DUMP TLVs, designed to describe or encapsulate data to assist in 129 realtime or post-mortem diagnostics, such as structured 130 representations of affected prefixes / NLRI and encapsulated raw 131 UPDATE messages for inspection. 133 o CONTROL TLVs, designed to facilitate control messaging such as 134 replies to requests which can not be satisfied. 136 Means concerning the reporting of information carried by these TLVs, 137 either in reply or request processing are implementation specific but 138 could include methods such as SYSLOG. 140 3. BGP OPERATIONAL message 142 3.1. BGP OPERATIONAL message capability 144 A BGP speaker that is willing to exchange BGP OPERATIONAL Messages 145 with a neighbor should advertise the new OPERATIONAL Message 146 Capability to the neighbor using BGP Capabilities advertisement 147 [RFC5492] . A BGP speaker may send an OPERATIONAL message to its 148 neighbor only if it has received the OPERATIONAL message capability 149 from them. 151 The Capability Code for this capability is specified in the IANA 152 Considerations section of this document. 154 The Capability Length field of this capability is 2 octets. 156 +------------------------------+ 157 | Capability Code (1 octet) | 158 +------------------------------+ 159 | Capability Length (1 octet) | 160 +------------------------------+ 162 OPERATIONAL message BGP Capability Format 164 3.2. BGP OPERATIONAL message encoding 166 The BGP message as defined [RFC4271] consists of a fixed-size header 167 followed by two octet length field and one octet of type value. The 168 RFC limits the maximum message size to 4096 octets. As one of the 169 applications of BGP OPERATIONAL message (through the MUD 170 (Section 3.4.3.3) message) is to be able to carry an entire, 171 potentially malformed BGP UPDATE, this specification mandates that 172 when the neighbor has negotiated the BGP OPERATIONAL message 173 capability, any further BGP message which may be subject enclosure 174 within a BGP OPERATIONAL message must be sent with the maximum size 175 reduced to accommodate for the potential need of additional wrapping 176 header size requirements. This is applicable to both the current BGP 177 maximum message size limit or for any future modifications. 179 For the purpose of the OPERATIONAL message information encoding we 180 will use one or more Type-Length-Value containers where each TLV will 181 have 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 (2 octets) | Length (2 octets) | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Variable size TLV value | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 OPERATIONAL message TLV Format 193 TYPE: 2 octet value indicating the TLV type 195 LENGTH: 2 octet value indicating the TLV length in octets 197 VALUE: Variable length value field depending on the type of the TLVs 198 carried. 200 To work around continued BGP churn issues some types of TLVs will 201 need to contain a sequence number to correlate a request with 202 associated replies. The sequence number will consist of 8 octets and 203 will be of the form: (4 octet bgp_router_id) + (local 4 octet 204 number). When the local 4 octet number reaches 0xFFF it should 205 restart from 0x0000. The sequence number is only used if the TLV 206 requires sequencing else it is not included. 208 The typical application scenario for use of the sequence number is 209 for it to be included in a request TLV to be copied into associated 210 reply messages in order to correlate requests with their associated 211 replies. 213 3.3. PRI Format 215 Prefix Reachability Indicators (PRI) are used to represent prefix 216 NLRI and BGP attributes in a request and only prefix NLRI in a 217 response, in this draft. 219 Each PRI is encoded as a 3-tuple of the form whose fields are described below: 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Flags (1 octet) | Payload Type (1 octet) | 226 +---------------------------------------------------------------+ 227 | Payload (Variable) | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 The use and the meaning of these fields are as follows: 232 a) Flags: 233 Four bits indicating NLRI Reachability: 235 aa) R Bit: 236 The R (Reachable) bit, if set represents that the prefixes were 237 deemed reachable in the NLRI, else represents that the prefixes 238 were deemed unreachable. This bit is meaningless in the 239 context of all currently defined requests and can thus only be 240 found in a response. If found in a request an implementation 241 MUST ignore its state. 243 ab) I Bit: 244 The I (Adj-RIB-In) bit, if set in a query, indicates that the 245 requestor wishes for the response to be found in the Adj-RIB-In 246 of the neighbor representing this session, if cleared indicates 247 that the Adj-RIB-In of the neighbor representing this session 248 is not searched. If set in a response, indicates that the Adj- 249 RIB-In of the neighbor representing this session contained this 250 information, if cleared it did not. 252 ac) O Bit: 253 The O (Adj-RIB-Out) bit, if set in a query, indicates that the 254 requestor wishes for the response to be found in the Adj-RIB- 255 Out of the neighbor representing this session, if cleared 256 indicates that the Adj-RIB-Out of the neighbor representing 257 this session is not searched. If set in a response, indicates 258 that the Adj-RIB-Out of the neighbor representing this session 259 contained this information, if cleared it did not. 261 ad) L Bit: 262 The L (Loc-RIB) bit, if set in a query, indicates that the 263 requestor wishes for the response to be found in the BGP Loc 264 RIB of the neighbor, if cleared indicates that the Loc-RIB of 265 the neighbor is not searched. If set in a response, indicates 266 that the Loc-RIB of the neighbor contained this information, if 267 cleared it did not. 269 The rest of the field is reserved for future use. 271 b) Payload Type: 272 This one octet type specifies the type and geometry of the 273 payload. 275 ba) Type 0 - NLRI: 276 The payload contains (perhaps multiple) NLRI, the format of 277 each NLRI is as defined in the base specification of such NLRI 278 appropriate for the AFI/SAFI. 280 bb) Type 1 - Next Hop: 281 The payload contains a Next Hop address, appropriate for the 282 AFI/SAFI. When used in an SSQ (Section 3.4.2.7) message the 283 response is expected to contain prefixes from the selected RIBs 284 which contain this next-hop in their next-hop attribute. 286 bc) Type 2 - AS Number: 287 The payload contains a 16 or 32 bit AS number (as defined in 288 [RFC4893]), when used in an SSQ message the response is 289 expected to contain prefixes from the selected RIBs which 290 contain this AS number in their AS_PATH or AS4_PATH (as 291 appropriate) attributes. 293 bc) Type 3 - Standard Community: 294 The payload contains a standard community (as defined in 295 [RFC1997]), when used in an SSQ message the response is 296 expected to contain prefixes from the selected RIBs which 297 contain this standard community in their communities attribute. 299 bd) Type 4 - Extended Community: 300 The payload contains an extended community (as defined in 301 [RFC4360]), when used in an SSQ message the response is 302 expected to contain prefixes from the selected RIBs which 303 contain this standard community in their extended communities 304 attribute. 306 be) Types 5-65535 - Reserved: 307 Types 5-65535 are reserved for future use. 309 c) Payload: 310 Contains the actual payload, as defined by the payload type, the 311 payload is of variable length, to be calculated from the remaining 312 TLV length. 314 PRI are used for both request and response modes, a response MUST 315 only contain an NLRI (type 0) payload but a request MAY contain 316 payloads specifying a type to search for, an implementation MUST 317 validate all PRI it receives in a request against the type of request 318 which was made. 320 An implementation MUST NOT send a PRI in response with no NLRI (type 321 0) payload, this is considered to be invalid. If the implementation 322 wishes to signal that a request did not yield a any valid results an 323 implementation MAY respond with an NS TLV (Section 3.4.4.2), using 324 the "Not Found" subcode, for example. 326 3.4. BGP OPERATIONAL message TLVs 328 3.4.1. ADVISE TLVs 330 ADVISE TLVs convey human readable information to be passed, cross 331 boundary to operators, to inform them of past or upcoming error 332 conditions, or provide other relevant, in-band operational 333 information. 335 3.4.1.1. Advisory Demand Message (ADM) 337 TYPE: 1 - ADM 339 LENGTH: 3 Octets(AFI+SAFI) + Variable value (up to 2K octets) 341 USE: To carry a message, on demand, comprised of a string of UTF-8 342 characters (up to 2K octets in size), with no null termination. Upon 343 reception, the string SHOULD be reported to the host's administrator. 345 Implementations SHOULD provide their users the ability to transmit a 346 free form text message generated by user input. 348 3.4.1.2. Advisory Static Message (ASM) 350 TYPE: 2 - ASM 352 LENGTH: 3 Octets(AFI+SAFI) + Variable value (up to 2K octets) 354 USE: To carry a message, on demand, comprised of a string of UTF-8 355 characters, with no null termination. Upon reception, the string 356 SHOULD be stored in the BGP neighbor statistics field within the 357 router. The string SHOULD be accessible to the operator by executing 358 CLI commands or any other method (local or remote) to obtain BGP 359 neighbor statistics (e.g. NETCONF, SNMP). 361 The expectation is that the last ASM received from a BGP neighbor 362 will be the message visible to the operator (the most current ASM). 364 Implementations SHOULD provide their users the ability to transmit a 365 free form text message generated by user input. 367 3.4.2. STATE TLVs 369 STATE TLVs reflect, on demand, the internal state of a BGP neighbor 370 as seen from the other neighbor's perspective. 372 3.4.2.1. Reachable Prefix Count Request (RPCQ) 374 TYPE: 3 - RPCQ 376 LENGTH: 3 Octets(AFI+SAFI) + Sequence Number 378 USE: Sent to the neighbor to request that an RPCP (Section 3.4.2.2) 379 message is generated in response. 381 3.4.2.2. Reachable Prefix Count Reply (RPCP) 383 TYPE: 4 - RPCP 385 LENGTH: 3 Octets(AFI+SAFI) + Sequence Number + 4 Octet RX Prefix 386 Counter (RXC) + 4 Octet TX Prefix Counter (TXC) 388 USE: Sent in reply to an RPCQ (Section 3.4.2.1) message from a 389 neighbor, RXC is populated with the number of reachable prefixes 390 accepted from the peer and TXC with the number of prefixes to be 391 transmitted to the peer for the AFI/SAFI. 393 3.4.2.3. Adj-Rib-Out Prefix Count Request (APCQ) 395 TYPE: 5 - APCQ 397 LENGTH: 3 Octets(AFI+SAFI) + Sequence Number 399 USE: Sent to the neighbor to request that an APCP (Section 3.4.2.4) 400 message is generated in response. 402 APCQ can be used as a simple mechanism when an implementation does 403 not permit or support the use of RPCQ. 405 3.4.2.4. Adj-Rib-Out Prefix Count Reply (APCP) 407 TYPE: 6 - APCP 409 LENGTH: 3 Octets(AFI+SAFI) + Sequence Number + 4 Octet TX Prefix 410 Counter (TXC) 412 USE: Sent in reply to an APCQ (Section 3.4.2.3) message from a 413 neighbor, TXC is populated with the number of prefixes held in the 414 Adj-Rib-Out for the neighbor for the AFI/SAFI. 416 3.4.2.5. BGP Loc-Rib Prefix Count Request (LPCQ) 418 TYPE: 7 - LPCQ 420 LENGTH: 3 Octets(AFI+SAFI) + Sequence Number 422 USE: Sent to the peer to request that an LPCP (Section 3.4.2.6) 423 message is generated in response. 425 3.4.2.6. BGP Loc-Rib Prefix Count Reply (LPCP) 427 TYPE: 8 - LPCP 429 LENGTH: 3 Octets(AFI+SAFI) + Sequence Number + 4 Octet Loc-Rib 430 Counter (LC) 432 USE: Sent in reply to an LPCQ (Section 3.4.2.5) message from a 433 neighbor, LC is populated with the number of prefixes held in the 434 entire Loc-Rib for the AFI/SAFI. 436 3.4.2.7. Simple State Request (SSQ) 438 TYPE: 9 - SSQ 440 LENGTH: 3 Octets(AFI+SAFI) + Sequence Number + Single request PRI 441 (Variable) 443 USE: Using a PRI as a request form (See Section 3.3), an 444 implementation can be asked to return information about prefixes 445 found in various RIBs. 447 A single, simple PRI is used in the request, containing a single NLRI 448 or attribute as the PRI payload. RIB response filtering may take 449 place through the setting of the I, O and L bits in the PRI Flags 450 field. 452 An implementation MAY respond to an SSQ TLV in with an SSP (See 453 Section 3.4.3.4) TLV (containing the appropriate data). An 454 implementation MAY also respond to an SSQ with an NS TLV (with the 455 appropriate subcode set) indicating why there will not be an SSP TLV 456 in response. An implementation MAY also not respond at all (See 457 Section 7). 459 3.4.3. DUMP TLVs 461 DUMP TLVs provide data in both structured and unstructured formats in 462 response to events, for use in debugging scenarios. 464 3.4.3.1. Dropped Update Prefixes (DUP) 466 TYPE: 10 - DUP 468 LENGTH: 3 Octets(AFI+SAFI) + Variable number of dropped UPDATE Prefix 469 Reachability Indicators (PRI) (See Section 3.3) 471 USE: To report to a neighbor a structured set of prefix reachability 472 indicators retrievable from the last dropped UPDATE message, sent in 473 response to an UPDATE message which was well formed but not accepted 474 by the neighbor by policy. 476 For example, an UPDATE which was dropped and the rescued NLRI 477 concerned a number of both reachable and unreachable prefixes, the 478 DUP would encapsulate two PRI, one with the R-Bit (reachable) set, 479 housing the rescued reachable NLRI and the other with the R-Bit 480 cleared (unreachable), housing the rescued unreachable NLRI as 481 payload. 483 3.4.3.2. Malformed Update Prefixes (MUP) 485 TYPE: 11 - MUP 487 LENGTH: 3 Octets(AFI+SAFI) + Variable number of dropped update Prefix 488 Reachability Indicators (PRI) (See Section 3.3) due to UPDATE 489 Malformation. 491 USE: To report to a neighbor a structured set of prefix reachability 492 indicators retrievable from the last UPDATE message dropped through 493 malformation, sent in response to an UPDATE message which was not 494 well formed and not accepted by the neighbor, where a NOTIFICATION 495 message was not sent. A MUP TLV may accompany a MUD 496 (Section 3.4.3.3) TLV. 498 See the example from Section 3.4.3.1. 500 3.4.3.3. Malformed Update Dump (MUD) 502 TYPE: 12 - MUD 504 LENGTH: 3 Octets(AFI+SAFI) + Variable length representing retrievable 505 malformed update octet stream. 507 USE: To report to a peer a copy of the last UPDATE message dropped 508 through malformation, sent in response to an UPDATE message which was 509 not well formed and not accepted by the neighbor, where a 510 NOTIFICATION message was not sent. A MUD TLV may accompany a MUP 511 (Section 3.4.3.2) TLV. 513 3.4.3.4. Simple State Response (SSP) 515 TYPE: 13 - SSP 517 LENGTH: 3 Octets(AFI+SAFI) + Sequence Number + Single Response PRI 518 (Variable) 520 USE: Using a PRI as a response form (See Section 3.3), an 521 implementation uses the SSP TLV to return a response to an SSQ (See 522 Section 3.4.2.7) TLV which should contain information about prefixes 523 found in various RIBs. These RIBs should be walked to extract the 524 information according to local policy. 526 A single, simple PRI is used in the response, containing multiple 527 NLRI. The I, O and L bits in the PRI Flags field should be set 528 indicating which RIBs the prefixes were found in. 530 An implementation MAY respond to an SSQ TLV in with an SSP TLV 531 (containing the appropriate data). An implementation MAY also 532 respond to an SSQ with an NS TLV (with the appropriate subcode set) 533 indicating why there will not be an SSP TLV in response. An 534 implementation MAY also not respond at all (See Section 7). 536 If no data is found to satisfy a query which is permitted to be 537 answered, an implementation MAY respond with an NS TLV with the 538 subcode "Not Found" to indicate that no data was found in response to 539 the query. An implementation MUST NOT send a PRI in response with no 540 NLRI payload, this is considered to be invalid. 542 3.4.4. CONTROL TLVs 544 CONTROL TLVs satisfy control mechanism messaging between neighbors, 545 they are used for such functions as to refuse messages and 546 dynamically signal OPERATIONAL capabilities to neighbors during 547 operation. 549 3.4.4.1. Max Permitted (MP) 551 TYPE: 65534 - MP 553 LENGTH: 3 Octets(AFI+SAFI) + 2 Octet Value 555 USE: The Max Permitted TLV is used to signal to the neighbor the 556 maximum number of OPERATIONAL messages that will be accepted in a 557 second of time (see Section 7, Security Considerations), an 558 implementation MUST, on receipt of an MP TLV, ensure that it does not 559 exceed the rate specified in the MP TLV for sending OPERATIONAL 560 messages to the neighbor, for the duration of the session. 562 An implementation MAY send subsequent MP TLVs during the session's 563 lifetime, updating the maximum acceptable rate 565 MP TLVs MAY be rate limited by the receiver as part of OPERATIONAL 566 rate limiting (see Section 7, Security Considerations). 568 3.4.4.2. Not Satisfied (NS) 570 TYPE: 65535 - NS 572 LENGTH: 3 Octets(AFI+SAFI) + Sequence Number + 2 Octet Error Subcode 574 USE: To respond to a query to indicate that the implementation can or 575 will not answer this query. The following subcodes are defined: 577 0x01 - Request TLV Malformed: Used to signal to the neighbor that 578 the request was malformed and will not be processed. A neighbor 579 on receiving this message MAY re-transmit the request but MUST 580 increment the sequence number. Implementations SHOULD ensure that 581 the same request is not retransmitted excessively when repeatedly 582 receiving this Error Subcode in response. 584 0x02 - TLV Unsupported for this neighbor: Used to signal to the 585 neighbor that the request was unsupported and will not be 586 processed. A neighbor on receiving this message MUST NOT 587 retransmit the request for the duration of the session. 589 0x03 - Max query frequency exceeded: Used to signal to the neighbor 590 that the request has exceeded the rate at which the neighbor finds 591 acceptable for the implementation to transmit requests at, see 592 Section 3.4.4.1 (MP TLV) and Section 7 and (Security 593 Considerations) for more information. 595 0x04 - Administratively prohibited: Used to signal to the neighbor 596 that the request was administratively prohibited and will not be 597 processed. A neighbor on receiving this message MUST NOT 598 retransmit the request for the duration of the session. 600 0x05 - Busy: Used to signal to the neighbor that the request will 601 not be replied to, due to lack of resources estimated to satisfy 602 the request. It is suggested that, on receipt of this error 603 subcode a message is logged to inform the operator of this failure 604 as opposed to automatically attempting to re-try the previous 605 query. 607 0x06 - Not Found: Used to signal to the neighbor that the request 608 would have been replied to but does not contain any data (i.e the 609 data was not found). An implementation MUST NOT send a PRI 610 response with no NLRI payload, this is considered to be invalid. 612 NS TLVs MAY be rate limited by the receiver as part of OPERATIONAL 613 rate limiting (see Section 7, Security Considerations). 615 4. On the use of STATE and DUMP TLVs 617 The STATE TLVs use three classes of counters, defined in this 618 document: sent counters (TXC), received counters (RXC) and current 619 table state counters (LC). The table state counters (for example 620 number of BGP RIB entries) are exchanged only for informational 621 purposes and they should not be subject to comparison with any local 622 counter values. 624 Where a query of the neighbor's RXC is required to be correlated, the 625 local TXC coupled with the sequence number SHOULD be stored and used 626 to perform such a correlation. If a discrepancy is detected, an 627 automated or manual Route Refresh message can be triggered (utilising 628 Start_of_Refresh and End_of_Refresh markers) that would allow for 629 purge of any stalled data across two BGP databases. 631 It is important to note that, as BGP is never stable it is expected 632 that the counters will also be subject to continues value change 633 making any comparison of their values questionable. 635 The DUMP TLVs report information back to an operator about messages 636 which were not accepted, from machine-readable rescued UPDATE NLRI to 637 an entire copy of the malformed UPDATE message. These can be used 638 for troubleshooting purposes when such a message is transmitted and 639 the implementation gracefully continues (such as treat-as-withdraw). 641 5. On the use of ADVISE TLVs 643 The BGP routing protocol is used with external as well as internal 644 neighbors to propagate route advertisements. In the case of external 645 BGP sessions, there is typically a demarcation of administrative 646 responsibility between the two entities. While initial configuration 647 and troubleshooting of these sessions is handled via offline means 648 such as email or telephone calls, there is gap when it comes to 649 advising a BGP neighbor of a behaviour that is occurring or will 650 occur momentarily. There is a need for operators to transmit a 651 message to a BGP neighbor to notify them of a variety of types of 652 messages. These messages typically would include those related to a 653 planned or unplanned maintenance action. These ADVISE messages could 654 then be interpreted by the remote party and either parsed via logging 655 mechanisms or viewed by a human on the remote end via the CLI. This 656 capability will improve operator NOC-to-NOC communication by 657 providing a communications medium on an established and trusted BGP 658 session between two autonomous systems. 660 The reason that this method is preferred for NOC-to-NOC 661 communications is that other offline methods do fail for a variety of 662 reasons. Emails to NOC aliases ahead of a planned maintenance may 663 have ignored the mail or may have not of recorded it properly within 664 an internal tracking system. Even if the message was recorded 665 properly, the staff that are on-duty at the time of the maintenance 666 event typically are not the same staff who received the maintenance 667 notice several days prior. In addition, the staff on duty at the 668 time of the event may not even be able to find the recorded event in 669 their internal tracking systems. The end result is that during a 670 planned event, some subset of eBGP peers will respond to a session/ 671 peer down event with additional communications to the operator who is 672 initiating the maintenance action. This can be via telephone or via 673 email, but either way, it may result in a sizeable amount of replies 674 inquiring as to why the session is down. 676 The result of this is that the NOC responsible for initiating the 677 maintenance can be inundated with calls/emails from a variety of 678 parties inquiring as to the status of the BGP session. The NOC 679 initiating the maintenance may have to further inquire with 680 engineering staff (if they are not already aware) to find out the 681 extent of the maintenance and communicate this back to all of the 682 NOCs calling for additional information. The above scenario outlines 683 what is typical in a planned maintenance event. In an unplanned 684 maintenance event (the need for and immediate router upgrade/reload), 685 the number of calls and emails will dramatically increase as more 686 parties are unaware of the event. 688 With the ADVISE TLV set, an operator can transmit an OPERATIONAL 689 message just prior to initiating the maintenance specifying what 690 event will happen, what ticket number this event is associated with 691 and the expected duration of the event. This message would be 692 received by BGP peers and stored in their logs as well as any 693 monitoring system if they have this capability. Now, all of the BGP 694 peers have immediate access to the information about this session, 695 why it went down, what ticket number this is being tracked under and 696 how long they should wait before assuming there is an actual problem. 697 Even smaller networks without the network management capabilities to 698 correlate BGP events and OPERATIONAL messages would typically have an 699 operator login to a router and examine the logs via the CLI. 701 This draft specifies two types of ADVISE TLV, a DEMAND message (ADM) 702 and a STATIC message (ASM), it is anticipated that the DEMAND message 703 will be used to send a message, on demand to the BGP neighbor, to 704 inform them of realtime events. The STATIC message can be used to 705 provide continual, "Sticky" information to the neighbor, such as a 706 contact telephone number or e-mail address should there be a 707 requirement to have continual access to this information. 709 6. Error Handling 711 An implementation MUST NOT send an OPERATIONAL message to a neighbor 712 in response to an erroneous or malformed OPERATIONAL message. Any 713 erroneous or malformed OPERATIONAL message received SHOULD be logged 714 for the attention of the operator and then MAY be discarded. 716 7. Security considerations 718 No new security issues are introduced to the BGP protocol by this 719 specification. 721 Where a request type is not supported or allowed by an implementation 722 for some reason, the implementation MAY send an NS (Section 3.4.4.2) 723 TLV in response, the Error subcode of this TLV SHOULD be set 724 according to the reason that this request will not be responded to. 726 Implementations MUST rate-limit the rate at which they transmit and 727 receive OPERATIONAL messages. Specifically, an implementation MUST 728 NOT allow the handling of OPERATIONAL messages to negatively impact 729 any other functions on a router such as regular BGP message handling 730 or other routing protocols. 732 Although an NS error subcode is provided to indicate that a request 733 was rate-limited, an implementation need not reply to a request at 734 all, this is the suggested course of action when rate-limiting the 735 sending of responses to a neighbor. 737 An implementation MAY send an MP (Section 3.4.4.1) TLV to indicate 738 the maximum rate at which it will accept OPERATIONAL messages from a 739 neighbor, upon receipt of this TLV the sender MUST ensure it does not 740 transmit above this rate for the duration of the session. 742 An implementation, considering a request to be too computationally 743 expensive, MAY reply with the "Busy" NS error subcode to indicate 744 such, though the implementation need not reply to the request. 746 Implementations MUST provide a mechanism for preventing access to 747 information requested by SSR (Section 3.4.2.7) messages for the 748 operator. Implementations SHOULD ensure that responses concerning 749 the Loc-RIB (PRI with L-Bit set or responses which would set the 750 L-Bit) are filtered in the default configuration. 752 8. IANA Considerations 754 IANA is requested to allocate a type code for the OPERATIONAL message 755 from the BGP Message Types registry, as well as requesting a type 756 code for the new OPERATIONAL Message Capability negotiation from BGP 757 Capability Codes registry. 759 This document requests IANA to define and maintain a new registry 760 named: "OPERATIONAL Message Type Values". The allocation policy is 761 on a first come first served basis. 763 This document makes the following assignments for the OPERATIONAL 764 Message Type Values: 766 ADVISE: 768 * Type 1 - Advisory Demand Message (ADM) 770 * Type 2 - Advisory Static Message (ASM) 772 STATE: 774 * Type 3 - Reachable Prefix Count Request (RPCQ) 776 * Type 4 - Reachable Prefix Count Response (RPCP) 778 * Type 5 - Adj-RIB-Out Prefix Count Request (APCQ) 780 * Type 6 - Adj-RIB-Out Prefix Count Response (APCP) 782 * Type 7 - Loc-Rib Prefix Count Request (LPCQ) 784 * Type 8 - Loc-Rib Prefix Count Response (LPCP) 786 * Type 9 - Simple State Request (SSQ) 788 DUMP: 790 * Type 10 - Dropped Update Prefixes (DUP) 792 * Type 11 - Malformed Update Prefixes (MUP) 794 * Type 12 - Malformed Update Dump (MUD) 796 * Type 13 - Simple State Response (SSP) 798 CONTROL: 800 * Type 65534 - Max Permitted (MP) 802 * Type 65535 - Not Satisfied (NS) 804 9. Acknowledgements 806 This memo is based on existing works [I-D.ietf-idr-advisory] and 807 [I-D.raszuk-bgp-diagnostic-message] which describe a number of 808 operational message types documented here. The authors would like to 809 thank Enke Chen, Bruno Decraene, Alton Lo, Tom Scholl, John Scudder 810 and Richard Steenbergen for their valuable input. 812 10. References 814 10.1. Normative References 816 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 817 Communities Attribute", RFC 1997, August 1996. 819 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 820 Requirement Levels", BCP 14, RFC 2119, March 1997. 822 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 823 Protocol 4 (BGP-4)", RFC 4271, January 2006. 825 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 826 Communities Attribute", RFC 4360, February 2006. 828 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 829 "Multiprotocol Extensions for BGP-4", RFC 4760, 830 January 2007. 832 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 833 Number Space", RFC 4893, May 2007. 835 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 836 with BGP-4", RFC 5492, February 2009. 838 10.2. Informative References 840 [I-D.ietf-idr-advisory] 841 Scholl, T., Scudder, J., Steenbergen, R., and D. Freedman, 842 "BGP Advisory Message", draft-ietf-idr-advisory-00 (work 843 in progress), October 2009. 845 [I-D.jasinska-ix-bgp-route-server] 846 Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 847 "Internet Exchange Route Server", 848 draft-jasinska-ix-bgp-route-server-02 (work in progress), 849 March 2011. 851 [I-D.nalawade-bgp-inform] 852 Nalawade, G., Scudder, J., and D. Ward, "BGPv4 INFORM 853 message", draft-nalawade-bgp-inform-02 (work in progress), 854 August 2002. 856 [I-D.nalawade-bgp-soft-notify] 857 Nalawade, G., "BGPv4 Soft-Notification Message", 858 draft-nalawade-bgp-soft-notify-01 (work in progress), 859 July 2005. 861 [I-D.raszuk-bgp-diagnostic-message] 862 Raszuk, R., Chen, E., and B. Decraene, "BGP Diagnostic 863 Message", draft-raszuk-bgp-diagnostic-message-02 (work in 864 progress), March 2011. 866 [I-D.retana-bgp-security-state-diagnostic] 867 Retana, A. and R. Raszuk, "BGP Security State Diagnostic 868 Message", draft-retana-bgp-security-state-diagnostic-00 869 (work in progress), March 2011. 871 [I-D.shakir-idr-ops-reqs-for-bgp-error-handling] 872 Shakir, R., "Operational Requirements for Enhanced Error 873 Handling Behaviour in BGP-4", 874 draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 (work 875 in progress), February 2011. 877 Authors' Addresses 879 David Freedman 880 Claranet 881 London 882 UK 884 Email: david.freedman@uk.clara.net 886 Robert Raszuk 887 Cisco Systems 888 170 West Tasman Drive 889 San Jose, CA 95134 890 US 892 Email: raszuk@cisco.com 894 Rob Shakir 895 Cable&Wireless Worldwide 897 Email: rob.shakir@cw.com