--- 1/draft-ietf-grow-ops-reqs-for-bgp-error-handling-00.txt 2011-06-28 13:15:39.000000000 +0200 +++ 2/draft-ietf-grow-ops-reqs-for-bgp-error-handling-01.txt 2011-06-28 13:15:39.000000000 +0200 @@ -1,18 +1,18 @@ Internet Engineering Task Force R. Shakir Internet-Draft C&W -Intended status: Informational April 15, 2011 -Expires: October 17, 2011 +Intended status: Informational June 28, 2011 +Expires: December 30, 2011 Operational Requirements for Enhanced Error Handling Behaviour in BGP-4 - draft-ietf-grow-ops-reqs-for-bgp-error-handling-00 + draft-ietf-grow-ops-reqs-for-bgp-error-handling-01 Abstract BGP-4 is utilised as a key intra- and inter-Autonomous System routing protocol in modern IP networks. The failure modes as defined by the original protocol standards are based on a number of assumptions around the impact of session failure. Numerous incidents both in the global Internet routing table and within Service Provider networks have been caused by strict handling of a single invalid UPDATE message causing large-scale failures in one or more Autonomous @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 17, 2011. + This Internet-Draft will expire on December 30, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -57,44 +57,45 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Role of BGP-4 in Service Provider Networks . . . . . . . . 3 1.2. Overview of Operator Requirements for BGP-4 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Avoiding use of NOTIFICATION . . . . . . . . . . . . . . . . . 6 - 3. Recovering RIB Consistency . . . . . . . . . . . . . . . . . . 8 - 4. Reducing the Impact of Session Reset . . . . . . . . . . . . . 10 - 5. Operational Toolset for Monitoring BGP . . . . . . . . . . . . 12 - 6. Operational Complexities Introduced by Altering RFC4271 . . . 14 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 - 10.2. Informational References . . . . . . . . . . . . . . . . . 21 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 2. Errors within BGP-4 UPDATE Messages . . . . . . . . . . . . . 6 + 3. Avoiding use of NOTIFICATION . . . . . . . . . . . . . . . . . 8 + 4. Recovering RIB Consistency . . . . . . . . . . . . . . . . . . 10 + 5. Reducing the Impact of Session Reset . . . . . . . . . . . . . 12 + 6. Operational Toolset for Monitoring BGP . . . . . . . . . . . . 14 + 7. Operational Complexities Introduced by Altering RFC4271 . . . 18 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 + 11.2. Informational References . . . . . . . . . . . . . . . . . 25 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction Where BGP-4 [RFC4271] is deployed in the Internet and Service Provider networks, numerous incidents have been recorded due to the manner in which [RFC4271] specifies errors in routing information should be handled. Whilst the behaviour defined in the existing standards retains utility, the deployments of the protocol have changed within modern networks, resulting in significantly different demands for protocol robustness. Whilst a number of Internet Drafts have been written to begin to enhance the behaviour of BGP-4 in terms - of the handling of erroneous messages, this draft intends to define a + of the handling of erroneous messages, this memo intends to define a set of requirements for ongoing work. These requirements are considered from the perspective of a Network Operator, and hence this draft does not intend to define the protocol mechanisms by which such error handling behaviour is to be implemented. 1.1. Role of BGP-4 in Service Provider Networks BGP was designed as an inter-Autonomous System (AS) routing protocol and hence many of the error handling mechanisms within the protocol specification are designed to be conducive to this role. In general, @@ -202,21 +203,90 @@ is extremely limited - where further modifications to this behaviour are to be made, complexity is likely to be added. Thus, to ensure that BGP-4 is manageable, there are requirements for mechanisms by which the protocol can be examined and monitored. This document describes each of these requirements in further depth, along with an overview of means by which they are expected to be achieved. In addition, the mechanism by which the enhancements meeting these requirements are to interact is discussed. -2. Avoiding use of NOTIFICATION +2. Errors within BGP-4 UPDATE Messages + + Both through analysis of incidents occurring with the Internet DFZ, + and multi-service environments utilising BGP-4 to signal service or + routing information, a number of different classes of errors within + BGP-4 UPDATE messages have been observed. In order to consider the + applicability of enhanced error handling mechanisms, it is possible + to divide these errors into a number of sub-classes, particularly + focusing around the location of the error within the UPDATE message. + + Where an UPDATE message is considered invalid by a BGP speaker due to + an error within a path attribute that is not the NLRI (where the + definition of NLRI includes reachability information encoded in the + MP_REACH_NLRI and MP_UNREACH_NLRI attributes as specified in + [RFC4760]) it is a requirement of any enhanced error handling + mechanism to handle the error in a manner focused on the NLRI + contained within the message. Since in this case, the message + received from the remote peer is syntactically valid, it is + considered that such an UPDATE is indicative of erroneous data within + a path attribute - as such, it cannot be assumed that the BGP speaker + from whom the message was received is directly responsible for the + erroneous information - and hence affecting all NLRI received via a + specific session is disproportionate. + + Two further error cases exist within UPDATE messages, both of which + are related to the mechanisms that are applicable to messages + received where some difficulty exists in parsing the entire BGP + message. The two cases concern those cases where a valid NLRI + attribute can be extracted, and those where such an attribute is not + able to be parsed. In these cases, errors in the packing of + attributes within a BGP message may have occurred. Such errors are + likely indicative of an error specifically caused by the remote BGP + speaker. It is, however, desirable to an operator that such errors + are handled without affecting all NLRI across a BGP session. As + such, there is a key requirement to maximise the number of cases in + which it is possible to extract NLRI from a BGP UPDATE message. To + this end, it is required that where possible the MP_REACH and + MP_UNREACH attributes are utilised for encoding all NLRI (including + IPv4 Unicast), and that this attribute is included as the first + attribute of a BGP UPDATE message (as originally recommended in + [I-D.chen-ebgp-error-handling]). Such a change to the order of + inclusion of this attribute maximises the number of cases in which + NLRI can be extracted from an UPDATE. Where this is possible, it is + again required that the error handling mechanisms utilised should be + directly applied to the NLRI included in the UPDATE. + + For all cases whereby NLRI can be obtained from an UPDATE message, it + is expected that the requirements outlined in Section 3 should be + considered by any enhancement to the BGP-4 protocol. + + In the case that it is not possible to completely parse the NLRI + attribute from the UPDATE message received from a peer, it is + extremely likely that this is indicative of a serious error with + either the process of attribute packing, or buffer usage on the + remote BGP speaker. In this case, clearly, it is not possible to + apply any error handling mechanism that is limited to a specific set + of NLRI, since an implementation has no knowledge of the NLRI + included within the UPDATE message. In addition, such errors are + considered to be relatively fundamental to the operation of a BGP + implementation, and hence may indicate a case whereby significant + system errors have occurred. The current BGP-4 standard results in a + BGP speaker restarting a session with the remote BGP speaker. + However where such an error does occur, it is required that a + graceful mechanism is utilised to provide a lower impact to network + operation. The requirements for enhancements of this nature to BGP-4 + are outlined in Section 5, with the requirements outlined therein + focused on providing a means by which system integrity can be + restored whilst allowing for continued network operation. + +3. Avoiding use of NOTIFICATION The error handling behaviour defined in RFC4271 is problematic due to the limited options that are available to an implementation. When an erroneous BGP message is received, at the current time, the implementation must either ignore the error, or send a NOTIFICATION message, after which it is mandatory to terminate the BGP session. It is apparent that this requirement is at odds with that of protocol robustness. There is significant complexity to this requirement. The mechanism @@ -274,38 +344,38 @@ It is considered that, if extended to cover iBGP, the mechanisms described in [I-D.chen-ebgp-error-handling] and [I-D.ietf-idr-optional-transitive] provide a means to avoid the transmission of a NOTIFICATION to a remote BGP speaker based on a single erroneous message, where at all possible, and hence meet this requirement. The failure cases whereby NLRI cannot be extracted from the UPDATE message represent a case whereby the receiving system cannot handle the error gracefully based on this mechanism. -3. Recovering RIB Consistency +4. Recovering RIB Consistency - The recommendations described in Section 2 may result in the RIB for + The recommendations described in Section 3 may result in the RIB for a topology within an AS being inconsistent across the AS' internal routers. Alternatively, where such mechanisms are deployed at an AS boundary, interconnects between two ASes may be inconsistent with each other. There are therefore risks of traffic blackholing, due to missing routing information, or forwarding loops. Whilst this is deemed an acceptable compromise in the short term, clearly, it is suboptimal. Therefore, a requirement exists to provide mechanisms by which a BGP speaker is able to recover the consistency of the Adj- RIB-In for a particular neighbour. It is envisaged that during such routing inconsistencies, the local BGP speaker is aware that some routing information was not able to be processed - due to the fact that an UPDATE message was not parsed correctly. If the 'treat-as-withdraw' mechanism described within - Section 2 is utilised, it is also possible for the local BGP speaker + Section 3 is utilised, it is also possible for the local BGP speaker to have determined the set of NLRI for which an erroneous UPDATE message was received. In this scenario, by utilising targeted mechanisms to re-request the specific NLRI that was unreachable, this routing information can be re-transmitted from the remote BGP speaker. Such a request requires extension to the existing BGP-4 protocol, in terms of specific UPDATE generation filters with a transient lifetime. It is envisaged that the work within [I-D.zeng-one-time-prefix-orf] provides a mechanism allowing targeted elements of the Adj-RIB-In for a BGP neighbour to be recovered. @@ -331,42 +401,42 @@ mechanisms are utilised. It is not advisable that a transitive filter and advertisement mechanism is triggered by all error handling events due to the load this is likely to place on the neighbour receiving such a request. Where this BGP speaker is a relatively centralised device - a route reflector (as described by [RFC4456]) for example - the act of generation of UPDATE messages with such frequency is likely to cause disproportionate load. It is therefore an operational requirement of such mechanisms that means of request dampening be required by any such extension. -4. Reducing the Impact of Session Reset +5. Reducing the Impact of Session Reset Even where protocol enhancements allow errors in the BGP-4 protocol to cease to trigger NOTIFICATION messages, and hence reset a BGP session, it is clear that some error conditions may not be exited. In particular, errors due to existing state, or memory structures, associated with a specific BGP session will not be handled. It is therefore important to consider how these error conditions are currently handled by the protocol. It should be noted that the following discussion and analysis considers only those NOTIFICATION messages generated in response to errors in UPDATE messages (as defined by Section 6.3 in [RFC4271]). The existing NOTIFICATION behaviour triggers a reset of all elements of the BGP-4 session, as described in Section 6 of [RFC4271]. It is expected that session teardown requires an implementation to re- initialise all structures and state required for session maintenance. Clearly, there is some utility to this requirement, as error conditions in BGP are, in general, exited from. However, this definition is responsible for the forwarding outages within networks utilising BGP for route propagation when each error is experienced. - The requirement described in Section 2 is intended to reduce the + The requirement described in Section 3 is intended to reduce the cases whereby a NOTIFICATION is required, however, any mechanism implemented as a response to this requirement by definition cannot provide a session reset to the extent of that achieved by the current behaviour. In order to address this, there is a requirement for a means by which a BGP speaker can signal that an unhandled error condition in an UPDATE message occurred - requiring a session reset - yet also continue to utilise the paths advertised by the neighbour that are currently in use within the RIB. In this case, the Adj-RIB-In @@ -404,21 +474,21 @@ forwarding and control plane is common in many devices, as well as process separation for software-based devices - corruption of a specific protocol daemon does not necessarily imply forwarding is affected. Indeed, where forwarding behaviour of a device is affected, it is envisaged that a failure detection mechanism (be it Bidirectional Forwarding Detection, or indeed BGP KEEPALIVE packets) will detect such a failure in almost all cases, with the symptomatic behaviour of such a failure being an invalid UPDATE message in very few other cases. -5. Operational Toolset for Monitoring BGP +6. Operational Toolset for Monitoring BGP A significant complexity that is introduced through the requirements defined in this document is that of monitoring BGP session status for an operator. Although the existing error handling behaviour causes a disproportionate failure, session failure is extremely visible to most operational personnel within a Network Operator due to both existing definitions of SNMP trap mechanisms for BGP, along with the forwarding impact typically caused by such a failure. By introducing mechanisms by which errors of this nature are not as visible, this is no longer the case. There is a requirement that where subsets of the @@ -444,44 +514,131 @@ including the information as to the set of NLRI that were considered invalid. Whilst with some mechanisms this is achieved by default (for example, One-Time Prefix ORF [I-D.zeng-one-time-prefix-orf] (Outbound Route Filtering) will transmit the set of prefixes that are required), the operator requirement is to know which prefixes may have been unreachable in all cases. It is envisaged that an extension to meet this requirement will allow for such information to be transmitted between peers, and hence logged. Such a mechanism may provide further utility as a either a diagnostic, or logging toolset. - It should be noted that numerous work items within the IETF exist at - the time of writing that begin to solve this requirement. Within the - IDR working group both [I-D.raszuk-bgp-diagnostic-message] and - [I-D.ietf-idr-advisory] provide mechanisms by which such information - can be propagated in-band to an existing BGP session. Transmitting - such diagnostic information in-band is considered the optimal means - by which to propagate details of errors present in UPDATE messages, - due to the fact that no additional protocols (and hence security and - trust concerns) must be configured between two Autonomous Systems - (where the errors occur at an AS boundary), and the load on each BGP - speaker is increased only due to an additional capability, rather - than an additional code base, and protocol. Clearly, any mechanism - implemented in-band to a BGP session is required to be relatively - lightweight, since the information provided over the session is an - enhancement to the operational visibility of the protocol, and should - not disrupt core protocol operations. Other, out-of-band, mechanisms - - such as that proposed in [I-D.ietf-grow-bmp] are likely to provide - mechanisms by which further insight into BGP operation can be - achieved. The fact that such a protocol is implemented independently - of the BGP protocol results in further flexibility to provide - detailed protocol data, without introducing further complexity to the - BGP protocol itself. + As such, it is possible to divide the messages that are required in + order to provide further visibility into BGP for an operator. Such a + division can be made both due to the required means of message + transmission, alongside the criticality of each request. -6. Operational Complexities Introduced by Altering RFC4271 + o Messages required to replace NOTIFICATION - In cases where the + error handling mechanisms defined by [RFC4271] currently result in + a NOTIFICATION message being generated, a number of the + requirements detailed within this document result this message + being suppressed. Despite this change, the error condition's + occurrence is still of interest to an operator, since some form of + invalid data has been received on a session in order to provide + both monitoring and troubleshooting capabilities. It therefore + considered that an implementation must generate a message both + locally, and transmitted to the remote peer, based on the such a + condition. Where such a message is transmitted to the remote + peer, it is considered that the BGP session via which the + erroneous UPDATE message was received as transport to the remote + peer. The information transmitted in such a message should be + minimised to allow identification of the paths which were + considered erroneous (i.e. restricting the information to that + which is directly relevant to a network operator in the case of an + error condition occurring). Any delay to convergence on the + session in question is considered to be acceptable, given the + suboptimal nature of the reception of invalid routing information + via a BGP session. Further concerns regarding such a mechanism + relate to the load generated on the BGP speaker in question, + however, it must be considered that in the case of an erroneous + UPDATE being received, and the 'treat-as-withdraw' mechanism being + utilised, where the erroneous path is removed from the Loc-RIB, + there is likely to be a requirement to generate UPDATE messages + withdrawing the prefix from all further BGP speakers to which the + prefix is advertised. The load generated by the generation of + such UPDATEs is likely to be much greater than that of + transmitting error information via a logging message type back to + the speaker from which it was received. It is envisaged that + light-weight BGP message-based signalling mechanisms such as + [I-D.ietf-idr-advisory] provide a suitable means to satisfy this + requirement. + + o Additional Diagnostic Capabilities for BGP - In a number of cases, + there is an operational requirement to further debug erroneous BGP + UPDATE messages, along with the particulars of the state of a BGP + speaker. For instance, where an invalid BGP UPDATE message is + transmitted between two BGP speakers, the exact format of the + UPDATE message is of interest to an operator, as this information + provides a clear indication of an message considered to be + erroneous by the BGP speaker to which it was transmitted. In this + case, it is considered of great utility that the entire UPDATE + message is transmitted back to the advertising speaker, in order + to allow for further debugging to occur. Whilst such information + is particularly useful to an operator, it clearly provides + information that is not key to protocol operation - for this + reason, it is expected that some of the concerns regarding the + additional complexity, and load that a BGP speaker is subjected to + is not acceptable. For this reason, it is required that where + mechanisms are developed to support this requirement, messages of + this nature can be supported both within an existing BGP session, + and via a dedicated separate session, be it BGP carrying messages + such as DIAGNOSTIC [I-D.raszuk-bgp-diagnostic-message] or ADVISORY + [I-D.ietf-idr-advisory] or a dedicated monitoring protocol akin to + BMP described in [I-D.ietf-grow-bmp]. + + Whilst the operational requirement for such monitoring tools to allow + for visibility into BGP is clearly agreed upon, the means by which + such messages are transmitted between two BGP speakers is likely to + be dependent upon both the positions of the speakers in question (for + instances, the requirements for such a protocol may differ where a + session is between two ASBRs under separate administration). The + introduction of additional message types to the BGP protocol clearly + introduces further complexity - and leaves room for further + implementation and standardisation errors that may compromise the + robustness of the BGP protocol. In addition, the queuing and + scheduling of these BGP messages must be interleaved with the + transmission of the key protocol messages - such as KEEPALIVE and + UPDATE packets. It is therefore a concern that should a large number + of messages specifically for operational visibility be transmitted, + this will delay the transmission of UPDATE packets, and hence + adversely affect the end-to-end convergence time for NLRI carried + within BGP. The operational requirement for why messages are + advantageous to be in-band to a protocol should also be considered. + In particular, it should be noted that where such information is to + be transmitted between administrative boundaries a BGP session + represents an existing channel exists between the two ASes. This + channel is considered to be secure insofar as the routing + information, and requests sent via the session are considered to come + from a trusted source. Since error information relates to both a + particular attachment, and is key to ensuring that such a session is + operating as expected, it is considered of great operational benefit + that this information is transmitted over this channel. In addition, + the overall system scalability is improved by such in-band + transmission. It is expected that erroneous information resulting in + the 'treat-as-withdraw' mechanism being utilised is relatively + infrequently transmitted between two peers (when compared to the + frequency of UPDATE messages transmission). The impact of including + an additional BGP message type for such operational visibility is + relatively small from a resource utilisation perspective - additional + processing overhead is only experienced when such a message is + received. Where a separate session is maintained, particular network + elements within a service provider topology may require hundreds, or + thousands, of additional sessions for the transmission of this + information. Such an resource consumption overhead is likely to be + unacceptable to some network operators. + + For the reasons explained above, it is expected that mechanisms + specified to meet the requirements for event visibility consider the + relative impacts of additional monitoring sessions, or message + inclusion in band to BGP in order not to compromise the security, + scalability and robustness of the BGP-4 protocol. + +7. Operational Complexities Introduced by Altering RFC4271 The existing NOTIFICATION and subsequent teardown of a BGP session upon encountering an error has the advantage that a consistent approach to error handling is required of all implementations of the BGP-4 protocol. This is of operational advantage, as it provides a clear expectation of the behaviour of the protocol. The requirements defined herein add further complexity to the error-handling within BGP, and hence are liable to compromise the existing deterministic protocol behaviour. It is therefore deemed that there is a further requirement to provide a clear method by which an erroneous UPDATE @@ -494,33 +651,33 @@ BGP implementations), where some of the mechanisms referenced are unsupported. This adds further barriers to a standard definition of the BGP-4 error handling behaviour. In general, the approach considered ideal upon encountering an erroneous UPDATE message can be divided into two cases - those where the NLRI can be determined from the message, and those where it cannot be. The latter case is the simpler of the two. In this case, there is a requirement for the implementation to reset the BGP session, utilising the reduced-impact approach, described in - Section 4. In the case where the remote BGP speaker is in a + Section 5. In the case where the remote BGP speaker is in a transient error condition related to specific peer data structures, or state, a single instance of this behaviour is likely to exit the error condition. In the case of implementation errors, it is possible that the BGP session in question may enter a continuous loop of being reset, with a partial RIB being held by one or more of the BGP speakers due to an non-deterministic order of UPDATE propagation. It is therefore a requirement that within this reduced-impact procedure any subsequent UPDATE messages that would result in further session resets are ignored. Whilst this results in a condition where an undetermined amount of the RIB is inconsistent, partial reachability is maintained. In this case, the operational toolsets - discussed in Section 5 is likely to provide mechanisms by which this + discussed in Section 6 is likely to provide mechanisms by which this condition can be brought to the attention of the relevant operators. This requirement to accept a partial RIB, which results in potential invalid traffic forwarding is a direct result of the deployments of BGP-4, as described in Section 1.1. The case where NLRI can be determined from an erroneous UPDATE provides further complexities. In this case, a BGP speaker is aware of the sub-set of the RIB which have been identified as being contained within invalid UPDATE messages. This allows a local BGP speaker to re-request single prefixes, utilising a mechanism such as @@ -540,21 +697,21 @@ number of specific requests transmitted to be defined. 2. Where a specific refresh mechanism is not available, a peer should re-request the entire RIB. Again, there is a requirement to limit the number of complete RIB requests that should be sent via an implementation, in order to provide a bound both on the expected level of load a device may experience, and on the time for which the RIB may be inconsistent. 3. Finally, a session reset should be performed, as per the reduced- - impact NOTIFICATION requirement defined in Section 4. At this + impact NOTIFICATION requirement defined in Section 5. At this point, a similar challenge to that discussed above exists, should the error condition persist. In this case, as defined above, there is a requirement to ignore those UPDATE messages that continue to be erroneous. It is envisaged that where limits are required, these will be defined on a per memo-basis, or within a further revision of the requirements described herein. Whilst the approach described above provides a standard means by @@ -569,54 +726,55 @@ the number of error handling events sourced towards a particular neighbour. It is expected that such rate limiting, or event suppression is achieved on a per-session basis, where state information is already held, rather than on a per-prefix basis as it is envisaged that such behaviour presents significant scaling problems, and introduces further state requirements for an implementation of the protocol. It is recommended that where a flag indicative of erroneous behaviour is implemented, the state of such a value is maintained independently of session establishment. -7. IANA Considerations +8. IANA Considerations This memo includes no request to IANA. -8. Security Considerations +9. Security Considerations The requirements outlined in this document provide mechanisms by which erroneous BGP messages may be responded to with limited impact to forwarding operation. This is of benefit to the security of a BGP speaker in general. Where UPDATE messages may have been propagated by a single malicious Autonomous System or router within a network (or the Internet default free zone - DFZ), which are then propagated to all devices within the same routing domain, all other NLRI available over the same session become unreachable. This mechanism may provide means by which an Autonomous System can be isolated from required routing domains (such as the Internet), should the relevant UPDATE messages be propagated via specific paths. By reducing the impact of such failures, it is envisaged that this possibility may be constrained to a specific set of NLRI, or a specific topology. Some mechanisms meeting the requirements specified in this document, - particularly those within Section 5 may provide further security + particularly those within Section 6 may provide further security concerns, however, it is envisaged that these are addressed in per- enhancement memos. -9. Acknowledgements +10. Acknowledgements - The author would like to thank Rob Evans, David Freedman, Tom - Hodgson, Sven Huster, Jonathan Newton, Neil McRae, Thomas Mangin, Tom - Scholl and Ilya Varlashkin for their review and valuable feedback. + The author would like to thank Shane Amante, Bruno Decraene, Rob + Evans, David Freedman, Tom Hodgson, Sven Huster, Jonathan Newton, + Neil McRae, Thomas Mangin, Tom Scholl and Ilya Varlashkin for their + review and valuable feedback. -10. References +11. References -10.1. Normative References +11.1. Normative References [I-D.chen-ebgp-error-handling] Chen, E., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP Updates from External Neighbors", draft-chen-ebgp-error-handling-00 (work in progress), September 2010. [I-D.ietf-grow-bmp] Scudder, J., Fernando, R., and S. Stuart, "BGP Monitoring Protocol", draft-ietf-grow-bmp-05 (work in progress), @@ -660,26 +818,32 @@ Networks (VPNs)", RFC 4364, February 2006. [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006. [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January 2007. + [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, + "Multiprotocol Extensions for BGP-4", RFC 4760, + January 2007. + [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, February 2009. -10.2. Informational References +11.2. Informational References [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. Author's Address Rob Shakir Cable&Wireless Worldwide + London + UK - Email: rob.shakir@cw.com + Email: rjs@cw.net URI: http://www.cw.com/