idnits 2.17.1 draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 27, 2012) is 4138 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760) == Outdated reference: A later version (-13) exists of draft-ietf-grow-bgp-gshut-04 == Outdated reference: A later version (-17) exists of draft-ietf-grow-bmp-07 == Outdated reference: A later version (-10) exists of draft-ietf-idr-bgp-enhanced-route-refresh-03 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Shakir 3 Internet-Draft BT 4 Intended status: Informational December 27, 2012 5 Expires: June 30, 2013 7 Operational Requirements for Enhanced Error Handling Behaviour in BGP-4 8 draft-ietf-grow-ops-reqs-for-bgp-error-handling-06 10 Abstract 12 BGP is utilised as a key intra- and inter-autonomous system routing 13 protocol in modern IP networks. The failure modes, as defined by the 14 original protocol standards, are based on a number of assumptions 15 around the impact of session failure. Numerous incidents both in the 16 global Internet routing table and within service provider networks 17 have been caused by strict handling of a single invalid UPDATE 18 message causing large-scale failures in one or more autonomous 19 systems. 21 This memo describes the current use of BGP within service provider 22 networks, and outlines a set of requirements for further work to 23 enhance the mechanisms available to a BGP implementation when 24 erroneous data is detected. Whilst this document does not provide 25 specification of any standard, it is intended as an overview of a set 26 of enhancements to BGP to improve the protocol's robustness to suit 27 its current deployment. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 30, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 64 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Role of BGP-4 in Service Provider Networks . . . . . . . . 4 66 3. Critical and Non-Critical Errors . . . . . . . . . . . . . . . 7 67 4. Error Handling for Non-Critical Errors . . . . . . . . . . . . 9 68 4.1. NLRI-level Error Handling Requirements . . . . . . . . . . 9 69 4.2. Recovering RIB Consistency following NLRI-level Error 70 Handling . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5. Error Handling for Critical Errors . . . . . . . . . . . . . . 12 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 77 9.2. Informational References . . . . . . . . . . . . . . . . . 17 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 1. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 2. Problem Statement 88 BGP has become a key intra- and inter-domain routing protocol, 89 deployed within both the Internet and private networks. The 90 increased reliance on the protocol has resulted in increased demand 91 for robustness - with the error handling behaviour defined in 92 [RFC4271] having been shown to have caused numerous incidents within 93 live network deployments. This document provides an overview of the 94 current deployment cases for BGP-4, and define a set of requirements 95 (from the perspective of a network operator) for enhancing error 96 handling within the protocol. 98 2.1. Role of BGP-4 in Service Provider Networks 100 BGP was designed as an inter-autonomous system (AS) routing protocol. 101 Many of the error handling mechanisms within the protocol are defined 102 in order to be guarantee consistency, and correctness of information 103 between two neighbouring speakers. The assumption is made that each 104 AS operates with many adjacencies, each propagating a relatively 105 small amount of routing information. Through focusing on information 106 consistency, the protocol specification prefers failure of an 107 individual routing adjacency to maintaining reachability to all NLRI 108 received from a particular neighbour, with the expectation that 109 alternate, less direct, paths can be selected where a failure occurs. 110 The assumptions of the nature of BGP deployments resulted in the 111 specification made in [RFC4271] whereby the receipt of an erroneous 112 UPDATE message is reacted to by sending a NOTIFICATION message, and 113 tearing down the adjacency with the remote speaker from whom the 114 error was observed. 116 Historically, a network would deploy an interior gateway protocol 117 (IGP) to carry infrastructure and customer routes, and utilise an 118 external gateway protocol (EGP) such as BGP to propagate routes to 119 other autonomous systems. However, BGP's deployments have evolved 120 with the growth of IP-based services. To ensure route convergence 121 within an AS is within acceptable time bounds the amount of 122 information within the IGP has been minimised (typically to only 123 infrastructure routes). iBGP is then utilised to carry both internal, 124 customer and external routes within an AS. As such, this has 125 resulted in BGP having become an IGP, with traditional IGPs providing 126 only reachability between nodes within the AS for packet forwarding 127 and to establish iBGP sessions. This change in role within the 128 overall architecture of an AS has resulted in an increased robustness 129 requirement for BGP, with the expectation of a similar level of 130 robustness to that of an IGP being set. The loss of an iBGP session 131 can result in significant levels of unreachability internally to an 132 AS, especially since there are typically limited (when compared to 133 the Internet) signalling and forwarding paths available. 135 In parallel with this change of deployment, the volume and nature of 136 the information carried within BGP has also changed. BGP has become 137 the ubiquitous means through which service information can be 138 propagated between devices. For instance, being utilised to carry 139 IP/MPLS service information such as Layer 3 IP VPN routes [RFC4364] , 140 and Layer 2 Virtual Private LAN Service device membership [RFC4761]. 141 Since these extensions to the protocol allow signalling of multiple 142 services (represented by address families within BGP), and multiple 143 customer topologies (i.e., subsets of routes within each address 144 family) via the BGP protocol, the impact of session failure is 145 increased. The tear down of a single BGP session can result in a 146 complete outage to all customer services signalled via the session, 147 even where the triggering event is related to only one service or 148 topology being carried - reflecting a disproportional impact to all 149 other services and routing topologies. 151 The convergence of services to IP, and BGP's changing deployment has 152 resulted in a significant growth in the volume of routing information 153 carried in the protocol. In numerous networks, the RIB size of 154 individual BGP speakers can be of the order of millions of paths. 155 Particularly large RIBs are observed at BGP speakers performing 156 aggregation and border roles (such as ASBR, or route reflector 157 hierarchies). This increased volume of routes results not only in a 158 significant number of services being impacted during a protocol 159 failure, but also increases the time to recovery after re- 160 establishing a BGP session. The time taken to learn, compute and 161 distribute new paths increases the impact of failures on services 162 carried by the network - adding further weight to the requirement to 163 avoid failures, or limit the extent of their impact. Furthermore, 164 the impact of individual session failures is increased due to the 165 existence of a relatively small number of highly-critical BGP 166 sessions within Internet and multi-service network deployments. 167 These sessions propagate a high-proportion of the reachability 168 information - for instance, providing an Internet AS with the global 169 routing table from upstream providers, or connecting IP/MPLS Provider 170 Edge devices to route reflector hierarchies from which they are 171 signalled reachability for services connected elsewhere within the 172 routing domain. In both cases, the failure of these sessions can 173 result in a significant outage to customer services. 175 For the current deployments of BGP, the behaviour described in 176 [RFC4271] related to handling errors in UPDATE messages is 177 suboptimal, and results in significant disruption to services in 178 modern network deployments. This document defines a set of 179 requirements for protocol developments, and revisions to [RFC4271] to 180 address these concerns through a set of generalised definitions. It 181 should be noted that the scope of these requirements is limited to 182 the handling of UPDATE messages as, at the time of writing, there is 183 no operational requirement to amend the means by which error handling 184 in session establishment, or liveliness detection are performed. 186 3. Critical and Non-Critical Errors 188 As described in Section 2.1, the error handling behaviour described 189 in [RFC4271] is applied at a per-session level, affecting all NLRI 190 signalled via the adjacency on which an erroneous message is 191 observed. In order to reduce the impact of error handling to those 192 NLRI affected by an erroneous UPDATE, a BGP speaker MUST limit the 193 error handling mechanisms implemented to those NLRI contained within 194 an erroneous UPDATE message where it is possible to do so. Clearly, 195 some errors within the formation of BGP UPDATE messages may result in 196 it being impossible to reliably extract NLRI from the received 197 message, and hence the same error handling procedures may not apply. 198 There is therefore a requirement to classify errors based on their 199 impact to the BGP UPDATE message, hence messages whereby the NLRI 200 attribute cannot be extracted or parsed are referred to throughout 201 this document as Critical errors. These Critical errors are limited 202 to: 204 o UPDATE Message Length errors - where the specified UPDATE message 205 length is inconsistent with the sum of the Total Path Attribute 206 and Withdrawn Routes length. These errors relate to message 207 packing or framing, and result in cases whereby the NLRI attribute 208 cannot be correctly extracted from the message. 210 o Errors parsing the NLRI attribute of an UPDATE message - where the 211 contents of the IPv4 Unicast Advertised or Withdrawn Routes 212 attributes, or multi-protocol BGP NLRI attributes (MP_REACH_NLRI 213 and/or MP_UNREACH_NLRI as defined in [RFC2858]), cannot be 214 successfully parsed. 216 In the case of Critical errors is expected that error handling is 217 applied at a session level as per Section 5 of this document. 219 All errors whereby the contained NLRI can be extracted, are referred 220 to as Non-Critical. It is expected that the following cases fall 221 within this category: 223 o Zero or invalid length errors in path attributes, excluding those 224 containing NLRI, or where the length of all path attributes 225 contained within the UPDATE does not correspond to the total path 226 attribute length. 228 o Messages where invalid data or flags are contained in a path 229 attribute that does not relate to the NLRI. 231 o UPDATE messages missing mandatory attributes, unrecognised non- 232 optional attributes, or those that contain duplicate or invalid 233 attributes (be they unsupported, or unexpected). 235 o Those messages where the NEXT_HOP, the MP_REACH_NLRI next-hop 236 values are missing, zero-length, or invalid for the relevant 237 address family. 239 For these Non-Critical errors, the NLRI-targeted error handling 240 requirements described in Section 4 should be followed. 242 In order to maximise the number of cases whereby the NLRI attributes 243 can be reliably extracted from a received message, where a BGP 244 speaker supports multi-protocol extensions, the MP_REACH_NLRI and 245 MP_UNREACH_NLRI attributes SHOULD be utilised for all address 246 families (including IPv4 Unicast) and these attributes should be the 247 first attribute contained within the UPDATE message. 249 Where attributes are introduced by future extensions to the BGP 250 protocol the error handling behaviour applied MUST be assumed that 251 applied to Non-Critical errors, unless otherwise specified within the 252 per-extension memo, or the attribute relates directly to carrying 253 NLRI. Authors of future BGP extensions SHOULD specify the error 254 handling behaviour required for new attributes in terms of the 255 classification into a Critical or Non-Critical error on a per- 256 attribute error basis. 258 4. Error Handling for Non-Critical Errors 260 4.1. NLRI-level Error Handling Requirements 262 When a Non-Critical error is detected within an UPDATE message a BGP 263 speaker MUST NOT send a NOTIFICATION message to the remote neighbour. 264 Instead, the NLRI contained within the message MUST be considered as 265 no longer viable until they are updated by a subsequent UPDATE 266 message, thus treating the NLRI as withdrawn as per the treat-as- 267 withdraw mechanism described in [I-D.chen-ebgp-error-handling]. 269 Network operators SHOULD recognise that where such behaviour is 270 implemented black-holing or looping of traffic may occur in the 271 period between the NLRI being treated as withdrawn, and subsequent 272 updates, dependent upon the routing topology. It SHOULD be noted 273 that such periods of RIB inconsistency (where one speaker has 274 advertised a prefix, which has been treated as withdrawn by the 275 receiving speaker) may be relatively long lived, based on situations 276 such as an erroneous implementation at the receiver, or the error 277 occurring within an optional, transitive attribute not examined by 278 the advertising device. In order to allow operators to select 279 sessions on which this risk of inconsistency is acceptable, an 280 implementation SHOULD provide means by which NLRI-level error 281 handling for Non-Critical errors can be disabled on a per-session 282 basis. 284 Since the Non-Critical error handling required within this section 285 results in no NOTIFICATION message being transmitted, the fact that 286 an error has occurred and hence there may be inconsistency between 287 the local and remote BGP speaker MUST be flagged to the network 288 operator through standard operational interfaces (e.g., SNMP, 289 syslog). The information highlighted MUST include the NLRI 290 identified to be contained within the error message, and SHOULD 291 contain a exact copy of the received message for further analysis. 293 In order that the operator of the BGP speaker from whom an erroneous 294 UPDATE message has been advertised is aware of the fact that some 295 NLRI advertised to the remote speaker have been considered withdrawn 296 due to being contained within an erroneous UPDATE, a BGP speaker 297 SHOULD support mechanisms to report the occurrence of Non-Critical 298 error handling to the remote speaker. The receiving speaker SHOULD 299 transmit the NLRI contained within the erroneous message to the 300 advertising speaker. An exact copy of the received UPDATE message 301 SHOULD also be sent. 303 The exchange of information related to events occurring as a result 304 of BGP messages is not currently supported by any extension to the 305 protocol. Clearly, where the two speakers reside within the same 306 administrative domain, shared logging infrastructure can be utilised 307 to identify the root cause of errors, however, in many cases 308 neighbouring BGP speakers reside within separate administrative 309 domains (e.g., are ASBRs for Internet or private networks). In this 310 case, mechanisms allowing transmission in-band to the BGP session 311 SHOULD be utilised (e.g., the OPERATIONAL message described in 312 [I-D.ietf-idr-operational-message]). Such an in-band channel is 313 preferred based on the BGP session representing a pre-established 314 trusted channel which is related to a specific BGP-speaking device 315 within a network. It is expected that the overall system scalability 316 of a BGP speaker is improved through utilising the existing channel, 317 rather than incurring overhead for maintaining many additional 318 logging-specific protocol sessions for relatively infrequent 319 messaging events when errors occur. However, the extensions 320 providing such a channel MUST consider their impact to base BGP 321 protocol functions such as the transmission of UPDATE or KEEPALIVE 322 messages, and SHOULD limit the volume of messaging to direct 323 reactions to Non-Critical errors occurring. These considerations 324 SHOULD be made in order to ensure that no compromise is made to the 325 security, scalability and robustness of BGP. Where additional BGP 326 monitoring information that is not suitable to be carried in-band is 327 required, out-of-band mechanisms such as the BMP protocol described 328 in [I-D.ietf-grow-bmp] could be utilised to provide further 329 information relating to erroneous messages. 331 4.2. Recovering RIB Consistency following NLRI-level Error Handling 333 Following NLRI being treated as withdrawn due to Non-Critical error 334 handling, inconsistencies exist between the Adj-RIB-Out of the 335 advertising BGP speaker, and the Adj-RIB-In of the receiving device. 336 These inconsistencies may result in forwarding loops or blackholing 337 of traffic in some routing topologies. In order to ensure that such 338 cases can be recovered from a means by which a validation and 339 recovery of consistency can be achieved SHOULD be provided to an 340 operator. This function may be provided through enhancing the ROUTE- 341 REFRESH [RFC2918] mechanism to add means to identify the beginning 342 and end of a replay of the entire Adj-RIB-Out of the advertising 343 speaker (as per the suggestion in 344 [I-D.ietf-idr-bgp-enhanced-route-refresh]). 346 As Non-Critical error handling is localised to the NLRI contained 347 within the erroneous UPDATE message, a targeted recovery mechanism 348 MAY be provided allowing a speaker to request re-advertisement of a 349 particular subset of the Adj-RIB-Out. Where such targeted refresh 350 functions are available, they SHOULD be preferred to mechanisms 351 requesting re-advertisement of the whole Adj-RIB-Out based on their 352 more limited use of CPU and network resources. 354 A BGP speaker may automatically trigger recovery mechanisms such as 355 those described in this section following the receipt of an erroneous 356 UPDATE message identified as Non-Critical to expedite recovery. It 357 should be noted that if automatic recovery mechanisms trigger only 358 re-advertisement of an identical erroneous message, they are likely 359 to be ineffective. Additionally, where the best-path to be 360 advertised by remote speaker changes, this will be advertised 361 directly, without a requirement for a request from the receiver. 362 However, in some cases, RIB consistency recovery mechanisms may 363 prompt alternate UPDATE message packing, and hence allow quicker 364 recovery. Where such mechanisms are implemented, mechanisms focused 365 to smaller sets of NLRI SHOULD be preferred over those requesting the 366 entire RIB. In addition, such mechanisms SHOULD have dampening 367 mechanisms to ensure that their impact to computational and network 368 resources is limited. 370 5. Error Handling for Critical Errors 372 Where an UPDATE message containing a Critical error is received, 373 since the NLRI cannot be extracted, error handling mechanisms must be 374 applied at the per-session level. In order to limit the impact to 375 network operation, these session-level mechanisms MUST be applied in 376 a manner which allows the paths NLRI received from the remote speaker 377 to continue to be utilised for forwarding during the session reset 378 and re-establishment. It is envisaged that this requirement may be 379 met through extension of the BGP Graceful Restart mechanism 380 ([RFC4724]) to be triggered by NOTIFICATION messages indicating the 381 occurrence of a Critical error. Such an extension allows a restart 382 of the TCP and BGP sessions between two speakers, in a similar manner 383 to the current session restart behaviour triggered by a NOTIFICATION 384 message. In order to maximise the level of re-initialisation which 385 occurs during such a restart triggered by a Critical error, BGP 386 speakers MAY re-initialise memory structures related to the 387 Adj-RIB-In and Adj-RIB-Out associated with the session on which the 388 erroneous UPDATE was observed. 390 Where such a restart event occurs, the continued liveliness of the 391 remote device MAY be verified by BGP KEEPALIVE packets or other OAM 392 functions such as Bidirectional Forwarding Detection ([RFC5880]). In 393 cases where the observed Critical BGP error is indicative of a wider 394 device failure of the remote speaker, it is expected that a BGP 395 sessions will not re-establish correctly. Each BGP speaker SHOULD 396 maintain a limited time window in which session restart is expected 397 in order to mitigate this possibility. 399 When a Critical error occurs, the network operator MUST be made aware 400 of its occurrence through local logging mechanisms (e.g., SNMP traps 401 or syslog). The BGP speaker receiving an UPDATE message identified 402 as a Critical error MUST log its occurrence and a copy of the UPDATE 403 message. Where a inter-device messaging mechanism is implemented (as 404 discussed in Section Section 4.1) a copy of the erroneous UPDATE 405 message SHOULD be transmitted to the remote speaker. Both BGP 406 speakers MUST indicate to an operator the cause of a session restart 407 was a Critical error in an UPDATE message. 409 Since repeated critical errors (and session restarts) may have an 410 impact in overall device scaling if the failure condition is not 411 resolved by session restart, a BGP speaker MAY choose to revert to 412 the session tear down behaviour described in the base BGP 413 specification. This reversion SHOULD only be utilised after a number 414 of attempts which SHOULD be controllable by the network operator. 415 Where a session is shut down, the implementation MAY utilise a back- 416 off from session restart attempts (as per the IdleHoldTimer described 417 in the BGP FSM [RFC4271]). Where reversion to tearing down the BGP 418 session is performed, a speaker SHOULD limit the impact of 419 withdrawing prefixes from downstream speakers where possible. It is 420 envisaged that this can be achieved by utilising a mechanism such as 421 the BGP Graceful Shutdown procedure as described in 422 [I-D.ietf-grow-bgp-gshut]. 424 6. IANA Considerations 426 This memo includes no request to IANA. 428 7. Security Considerations 430 The requirements outlined in this document provide mechanisms which 431 limit the overall impact of the response to an error in a BGP UPDATE 432 message. This is of benefit to the security of a BGP speaker. 433 Without these mechanisms, where erroneous UPDATE messages relating to 434 a single NLRI entry can be propagated to a BGP speaker, all other 435 NLRI carried via the same session are affected by the resulting 436 session tear-down. This may result in an AS being isolated from 437 particular routing domains (such as the Internet) should an UPDATE 438 message be propagated via targeted specific paths. It is envisaged 439 by reducing the impact of the reaction of the receiving speaker to 440 these messages, the isolation can be constrained to specific sets of 441 NLRI, or a specific topology. 443 A number of the mechanisms meeting the requirements specified within 444 the document (particularly those relating to operational monitoring) 445 may raise further security concerns. Such concerns will be addressed 446 during the specification of these mechanisms. 448 8. Acknowledgements 450 The author would like to thank the following network operators for 451 their insight, and valuable input into defining the requirements for 452 a variety of deployments of the BGP protocol: Shane Amante, Bruno 453 Decraene, Rob Evans, David Freedman, Wes George, Tom Hodgson, Sven 454 Huster, Jonathan Newton, Neil McRae, Thomas Mangin, Tom Scholl and 455 Ilya Varlashkin. 457 In addition, many thanks are extended to Jeff Haas, Wim Hendrickx, 458 Tony Li, Alton Lo, Keyur Patel, John Scudder, Adam Simpson and Robert 459 Raszuk for their expertise relating to implementations of the BGP 460 protocol. 462 9. References 464 9.1. Normative References 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, March 1997. 469 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 470 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 472 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 473 September 2000. 475 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 476 Protocol 4 (BGP-4)", RFC 4271, January 2006. 478 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 479 Networks (VPNs)", RFC 4364, February 2006. 481 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 482 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 483 January 2007. 485 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 486 (VPLS) Using BGP for Auto-Discovery and Signaling", 487 RFC 4761, January 2007. 489 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 490 (BFD)", RFC 5880, June 2010. 492 9.2. Informational References 494 [I-D.chen-ebgp-error-handling] 495 Chen, E., Mohapatra, P., and K. Patel, "Revised Error 496 Handling for BGP Updates from External Neighbors", 497 draft-chen-ebgp-error-handling-01 (work in progress), 498 September 2011. 500 [I-D.ietf-grow-bgp-gshut] 501 Francois, P., Decraene, B., Pelsser, C., Patel, K., and C. 502 Filsfils, "Graceful BGP session shutdown", 503 draft-ietf-grow-bgp-gshut-04 (work in progress), 504 October 2012. 506 [I-D.ietf-grow-bmp] 507 Scudder, J., Fernando, R., and S. Stuart, "BGP Monitoring 508 Protocol", draft-ietf-grow-bmp-07 (work in progress), 509 October 2012. 511 [I-D.ietf-idr-bgp-enhanced-route-refresh] 512 Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced 513 Route Refresh Capability for BGP-4", 514 draft-ietf-idr-bgp-enhanced-route-refresh-03 (work in 515 progress), December 2012. 517 [I-D.ietf-idr-operational-message] 518 Freedman, D., Raszuk, R., and R. Shakir, "BGP OPERATIONAL 519 Message", draft-ietf-idr-operational-message-00 (work in 520 progress), March 2012. 522 Author's Address 524 Rob Shakir 525 BT 526 pp C3L, BT Centre 527 81, Newgate Street 528 London EC1A 7AJ 529 UK 531 Email: rob.shakir@bt.com 532 URI: http://www.bt.com/