--- 1/draft-ietf-grow-ops-reqs-for-bgp-error-handling-01.txt 2011-10-20 11:14:04.754756267 +0200 +++ 2/draft-ietf-grow-ops-reqs-for-bgp-error-handling-02.txt 2011-10-20 11:14:04.802756336 +0200 @@ -1,18 +1,18 @@ Internet Engineering Task Force R. Shakir Internet-Draft C&W -Intended status: Informational June 28, 2011 -Expires: December 30, 2011 +Intended status: Informational October 20, 2011 +Expires: April 22, 2012 Operational Requirements for Enhanced Error Handling Behaviour in BGP-4 - draft-ietf-grow-ops-reqs-for-bgp-error-handling-01 + draft-ietf-grow-ops-reqs-for-bgp-error-handling-02 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 December 30, 2011. + This Internet-Draft will expire on April 22, 2012. 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 @@ -58,32 +58,36 @@ 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. 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 + 2.1. Classifying BGP Errors and Expected Error Handling . . . . 7 + 2.1.1. Critical BGP Errors . . . . . . . . . . . . . . . . . 7 + 2.1.2. Semantic BGP Errors . . . . . . . . . . . . . . . . . 8 + 3. Avoiding use of NOTIFICATION . . . . . . . . . . . . . . . . . 9 + 4. Recovering RIB Consistency . . . . . . . . . . . . . . . . . . 11 + 5. Reducing the Impact of Session Reset . . . . . . . . . . . . . 13 + 6. Operational Toolset for Monitoring BGP . . . . . . . . . . . . 15 + 7. Operational Complexities Introduced by Altering RFC4271 . . . 19 + 7.1. Reducing the Network Impact of Session Teardown . . . . . 21 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 11.2. Informational References . . . . . . . . . . . . . . . . . 25 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 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 @@ -222,24 +226,30 @@ 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. + a path attribute. The impact of the current behaviour defined within + the protocol makes the implication that the BGP speaker from whom the + message is received is now an invalid path for all NLRI announced via + the session - which results in a disproportionate impact to overall + network operation. In particular scenarios (such as networks with + centralised BGP route reflection) such action can result in a loss of + all reachability to a network. In other contexts (such as the + Internet DFZ), it cannot be assumed that the BGP speaker from whom + the UPDATE message is received is directly responsible for the + erroneous information contained within the message. 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 @@ -272,20 +282,84 @@ 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. +2.1. Classifying BGP Errors and Expected Error Handling + + It is clearly of advantage for BGP-4 implementations to utilise a + consistent set of error handling mechanisms for the different types + of errors that are described in Section 2, and provide consistent + nomenclature to refer to them. It is therefore suggested that errors + that are indicative of larger scale failures of a BGP speaker, and + hence require some error handling at the session level are referred + to as 'critical' errors, whilst those errors that are identified + based on incorrect content of one of more attributes of a message are + referred to as 'semantic' errors. + +2.1.1. Critical BGP Errors + + As described in this document, it is of advantage to limit the number + of 'critical' errors that occur within the protocol, therefore, based + on analysis of the processing of BGP UPDATE messages, it is required + that 'critical' error handling behaviour is applied to: + + o UPDATE Message Length errors - whereby the specified overall + UPDATE message length is inconsistent with sum of the Total Path + Attribute and Withdrawn Routes length. In this case, this is + indicative of message packing failure, whereby the NLRI may not be + correctly extracted. + + o Errors Parsing the NLRI attributes of an UPDATE message - where + NLRI is carried in either the IPv4-Unicast Advertised or Withdrawn + routes, or in the MP_REACH_NLRI or MP_UNREACH_NLRI attributes + [RFC2858], it is not possible to target error handling mechanisms + to specific NLRI, and hence session level mechanisms must be + utilised. + + It is expected that those requirements outlined in Section 5 are + utilised to provide session-level handling of those errors identified + as 'critical'. + +2.1.2. Semantic BGP Errors + + Where a BGP message is correctly formed, a number of cases exist + whereby the contents of the UPDATE are not valid - in these cases, + this represents errors that can be identified to affect specific + NLRI. The following cases are expected to be classified a semantic + errors: + + o Zero or invalid length errors in path attributes excluding those + containing NLRI, or where the length of all path attributes + contained within the UPDATE does not correspond to the total path + attributes length. In this case, the NLRI can be correctly + extracted, and hence acted upon. + + o Messages where invalid data or flags are contained in a path + attribute that does not relate to the NLRI. + + o UPDATE messages missing mandatory attributes, unrecognised non- + optional attributes or those that contain duplicate or invalid + attributes (be they unsupported or unexpected). + + o Those messages where the NEXT_HOP, or MP_REACH next-hop values are + missing, length zero, or invalid for the relevant AFI/SAFI. + + In these cases, it is expected that these errors can be handled + gracefully, following the requirements detailed in Section 3 and + Section 4 of this memo. + 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. @@ -357,53 +431,67 @@ 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 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 + In the general case, the consistency of the BGP RIB can be recovered + by re-requesting the entire Adj-RIB-Out of a remote BGP speaker is + re-advertised. A mechanism to achieve this re-advertisement is + defined within the ROUTE-REFRESH specification [RFC2918]. It is + envisaged that by requesting a refresh of all NLRI advertised by a + BGP speaker, any NLRI which has been withdrawn due to being contained + within an invalid UPDATE message is re-learnt. Where a ROUTE REFRESH + is used to directly perform a consistency check between the Adj-RIB- + Out of a remote device, and the Adj-RIB-In of the local BGP speaker, + a demarcation between the ROUTE-REFRESH, and normal UPDATE messages + is required (in order that an "end" of the refresh can be used to + identify any 'stale' NLRI) - [I-D.keyur-bgp-enhanced-route-refresh] + provides a means by which the ROUTE-REFRESH mechanism can be extended + to meet this requirement. + + Whilst re-advertisement of the whole BGP RIB provides a means by + which withdrawn NLRI can be re-advertised, there are some scaling + implications that must be considered. In the case that a ROUTE- + REFRESH is generated, all NLRI must be re-packed into UPDATE messages + and advertised by one speaker on the BGP session, whilst the other + must receive all UPDATE messages, and validate the RIB's consistency. + Clearly, it is advantageous to avoid this work where possible. + + It is envisaged that during routing inconsistencies caused by + utilising the 'treat-as-withdraw' mechanism, 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. + Since this mechanism (as discussed in Section 3) requires the local + BGP speaker to have determined the set of NLRI for which an erroneous + UPDATE message was received, it is possible to use a targeted + mechanisms to re-request the specific NLRI that was contained within + the erroneous UPDATE message. By re-requesting, this provides the + remote BGP speaker an opportunity to re-transmit the NLRI - possibly + providing an opportunity to leverage alternative methods to build the + UPDATE message. 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. - In addition to such cases where specific routing information is known - to be erroneous, the more general case where either a large amount of - the Adj-RIB-In is contained in UPDATE messages subject to treat-as- - withdraw, or the specific prefixes are unknown to the local BGP - speaker must be considered. In this case, there is a requirement for - a BGP speaker to re-request the entire RIB advertised by a remote - neighbour. In this case, where such re-advertisement is required, it - is envisaged that a ROUTE-REFRESH as per the description in [RFC2918] - is utilised. [I-D.keyur-bgp-enhanced-route-refresh] provides a means - by which the ROUTE-REFRESH mechanism can be extended in order to meet - this requirement. - It is of particular note for both means of recovering RIB consistency described that these are effective only when considering transitive errors within an implementation - for instance, should an RFC interpretation error within an implementation be present, regardless of the number of times a specific UPDATE is generated, it is likely - that this error condition will persist. For this reason, there is an + that this error condition will persist (as it may with the existing + behaviour defined by [RFC4271]). For this reason, there is an requirement to consider the means by which such consistency recovery 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. @@ -446,25 +534,29 @@ mechanism described in [RFC4724]. Since the operational requirement in this case is to provide a means to achieve a complete session restart without disrupting the forwarding path of those prefixes in use within a BGP speaker's RIB, it is expected that utilising a procedure similar to the Graceful Restart mechanism meets the error handling requirement. By responding to an error condition (repeated or otherwise) with a message indicating that an error that cannot be handled has occurred, forcing session reset, whilst retaining forwarding information within the RIB allows forwarding to all prefixes within a system's RIB to continue, whilst the session - restarts. By placing a time bound on the restart lifetime, should an - error condition not be transient - for example, should an error have - occurred with the BGP process, rather than a specific of the BGP - session - the remote BGP speaker is still detected as an invalid - device for forwarding. + restarts. It is envisaged that the additional complexity introduced + by the introduction of such a mechanism can be limited by extending + existing BGP messages - one such approach is proposed in + + [I-D.keyupate-idr-bgp-gr-notification]. By placing a time bound on + the restart lifetime, should an error condition not be transient - + for example, should an error have occurred with the BGP process, + rather than a specific of the BGP session - the remote BGP speaker is + still detected as an invalid device for forwarding. It should, however, be noted that a protocol enhancement meeting this requirement is not able to solve all error conditions - however, a complete restart of the BGP and TCP session between two BGP speakers implements an identical recovery mechanism to that which is achieved by the existing behaviour. Where an error condition such as memory or configuration corruption has occurred in a BGP implementation, it is expected that a mechanism meeting this requirement continues to detect this, by means of a bound on time for session restart to occur. Whilst there may be some consideration that packets continue @@ -486,33 +578,34 @@ 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 RIB on a device are no longer reachable from a BGP speaker, or indeed - an AS, that some mechanism to determine the cause is available to an - operator. Whilst, to some extent, this can be solved by mandating a - sub-requirement of each of the aforementioned requirements that a BGP - speaker must log where such errors occur, and are hence handled, this - does not solve all cases. In order to clarify this requirement, the - example of the transmission of an erroneous Optional Transitive - attribute can be considered. Since, by definition, there is no - requirement for all BGP speakers to parse such an attribute, a - receiving router may treat NLRI as withdrawn based on an erroneous - attribute not examined by its neighbour. In this case, the upstream - device or network, propagating the UPDATE, has no visibility of this - error. Operationally, however, it is of interest to the upstream - router operator that such invalid information was propagated. + an AS, that some visibility of this situation, alongside a mechanism + to determine the cause is available to an operator. Whilst, to some + extent, this can be solved by mandating a sub-requirement of each of + the aforementioned requirements that a BGP speaker must log where + such errors occur, and are hence handled, this does not solve all + cases. In order to clarify this requirement, the example of the + transmission of an erroneous Optional Transitive attribute can be + considered. Since, by definition, there is no requirement for all + BGP speakers to parse such an attribute, a receiving router may treat + NLRI as withdrawn based on an erroneous attribute not examined by its + neighbour. In this case, the upstream device or network, propagating + the UPDATE, has no visibility of this error. Operationally, however, + it is of interest to the upstream router operator that such invalid + information was propagated. The requirement for logging of error conditions in transmitted BGP messages, which are visible to only the receiver, cannot be achieved by any existing BGP message, or capability. It is envisaged that each erroneous event should be transmitted to the remote peer - 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 @@ -550,46 +643,47 @@ 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. + light-weight BGP message-based signalling mechanisms such as the + ADVISORY message types detailed in + [I-D.frs-bgp-operational-message] 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]. + such as those defined in [I-D.frs-bgp-operational-message] 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 @@ -726,20 +820,62 @@ 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.1. Reducing the Network Impact of Session Teardown + + In some cases, where repeated erroneous UPDATE messages are received + on a BGP-4 session, it is desirable that a BGP speaker disconnects + completely from the remote peer without performing a restart, in + order to avoid the control-plane overhead of repeated session + establishment, and subsequent reset events. This behaviour may be + required after a per-session flag indicating erroneous behaviour is + set, as discussed in Section 7. The BGP-4 specification presented in + [RFC4271] achieves such a session shutdown by sending a NOTIFICATION + message, however, this has the net result that all downstream BGP + speakers (i.e. those to whom the NLRI carried over the now ceased BGP + session was readvertised) must withdraw this NLRI from their RIB, and + perform a best-path selection if required. In some cases, there may + be no alternate path being available, and hence a period of time for + which no valid BGP route exists. Particularly, this is very likely + to occur where an upstream BGP speaker performs a best-path selection + and advertises only a single path to its neighbours - there is a + requirement for the upstream speaker to perform a best-path + selection, and re-advertise a new set of NLRI before the downstream + system is able to converge to a new path. It should be noted that + where UPDATE messages withdrawing NLRI are not subject to the BGP + session's configured MinRouteAdvertisementInterval (MRAI) [RFC4271], + but re-advertisements are, this may result in a BGP speaker being + without a path for a period up to the MRAI. + + Clearly, it is advantageous to avoid this period of time for which + there may be no reachability for a set of NLRI, especially since the + BGP speaker terminating a particular session is doing so due to a + particular error handling policy. The graceful shutdown mechanism + detailed in [I-D.francois-bgp-gshut] provides a mechanism by which a + BGP speaker is able to signal that a set of NLRI is to be withdrawn, + and hence allow downstream systems to pre-emptively perform a best- + path selection, and hence advertise new reachability information in a + make-before-break manner. + + It is therefore envisaged, that where a session is to be shutdown, + based on a trigger relating to erroneous UPDATE messages being + received (be they repeated or not) that the graceful shutdown + procedure in utilised, so as to reduce the forwarding impact of NLRI + received on the session being withdrawn. + 8. IANA Considerations This memo includes no request to IANA. 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 @@ -753,67 +889,38 @@ 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 6 may provide further security concerns, however, it is envisaged that these are addressed in per- enhancement memos. 10. Acknowledgements - 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. + The author would like to thank the following network operators for + their insight, and valuable input in defining the requirements for a + variety of operational deployments of the BGP-4 protocol; Shane + Amante, Bruno Decraene, Rob Evans, David Freedman, Tom Hodgson, Sven + Huster, Jonathan Newton, Neil McRae, Thomas Mangin, Tom Scholl and + Ilya Varlashkin. + + In addition, many thanks are extended to Jeff Haas, Wim Hendrickx, + Alton Lo, Keyur Patel, John Scudder, Adam Simpson and Robert Raszuk + for their expertise relating to implementations of the BGP-4 + protocol. 11. 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), - December 2010. - - [I-D.ietf-idr-advisory] - Scholl, T., Scudder, J., Steenbergen, R., and D. Freedman, - "BGP Advisory Message", draft-ietf-idr-advisory-00 (work - in progress), October 2009. - - [I-D.ietf-idr-optional-transitive] - Scudder, J. and E. Chen, "Error Handling for Optional - Transitive BGP Attributes", - draft-ietf-idr-optional-transitive-03 (work in progress), - September 2010. - - [I-D.keyur-bgp-enhanced-route-refresh] - Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced - Route Refresh Capability for BGP-4", - draft-keyur-bgp-enhanced-route-refresh-02 (work in - progress), March 2011. - - [I-D.raszuk-bgp-diagnostic-message] - Raszuk, R., Chen, E., and B. Decraene, "BGP Diagnostic - Message", draft-raszuk-bgp-diagnostic-message-02 (work in - progress), March 2011. - - [I-D.zeng-one-time-prefix-orf] - Zeng, Q. and J. Dong, "One-time Address-Prefix Based - Outbound Route Filter for BGP-4", - draft-zeng-one-time-prefix-orf-01 (work in progress), - October 2010. + [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, + "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. @@ -827,20 +934,66 @@ [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. 11.2. Informational 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-01 (work in progress), + September 2011. + + [I-D.francois-bgp-gshut] + Francois, P., Decraene, B., pelsser, c., and C. Filsfils, + "Graceful BGP session shutdown", + draft-francois-bgp-gshut-01 (work in progress), + March 2009. + + [I-D.frs-bgp-operational-message] + Raszuk, R., Shakir, R., and D. Freedman, "BGP OPERATIONAL + Message", draft-frs-bgp-operational-message-00 (work in + progress), July 2011. + + [I-D.ietf-grow-bmp] + Scudder, J., Fernando, R., and S. Stuart, "BGP Monitoring + Protocol", draft-ietf-grow-bmp-05 (work in progress), + December 2010. + + [I-D.ietf-idr-optional-transitive] + Scudder, J. and E. Chen, "Error Handling for Optional + Transitive BGP Attributes", + draft-ietf-idr-optional-transitive-03 (work in progress), + September 2010. + + [I-D.keyupate-idr-bgp-gr-notification] + Patel, K., Fernando, R., Scudder, J., and J. Haas, + "Notification Message support for BGP Graceful Restart", + draft-keyupate-idr-bgp-gr-notification-00 (work in + progress), July 2011. + + [I-D.keyur-bgp-enhanced-route-refresh] + Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced + Route Refresh Capability for BGP-4", + draft-keyur-bgp-enhanced-route-refresh-02 (work in + progress), March 2011. + + [I-D.zeng-one-time-prefix-orf] + Zeng, Q. and J. Dong, "One-time Address-Prefix Based + Outbound Route Filter for BGP-4", + draft-zeng-one-time-prefix-orf-01 (work in progress), + October 2010. + [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