--- 1/draft-ietf-idr-bgp-enhanced-route-refresh-05.txt 2014-02-05 22:14:32.036277667 -0800 +++ 2/draft-ietf-idr-bgp-enhanced-route-refresh-06.txt 2014-02-05 22:14:32.056278154 -0800 @@ -1,19 +1,20 @@ IDR K. Patel Internet-Draft E. Chen -Intended status: Standards Track B. Venkatachalapathy -Expires: June 12, 2014 Cisco Systems - December 9, 2013 +Intended status: Standards Track Cisco Systems +Expires: August 10, 2014 B. Venkatachalapathy + + February 6, 2014 Enhanced Route Refresh Capability for BGP-4 - draft-ietf-idr-bgp-enhanced-route-refresh-05.txt + draft-ietf-idr-bgp-enhanced-route-refresh-06.txt Abstract In this document we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP RIB inconsistencies in a non-disruptive manner. Status of This Memo @@ -23,51 +24,51 @@ 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 June 12, 2014. + This Internet-Draft will expire on August 10, 2014. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + Copyright (c) 2014 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 2 - 3.1. Enhanced Route Refresh Capability . . . . . . . . . . . . 2 + 3.1. Enhanced Route Refresh Capability . . . . . . . . . . . . 3 3.2. Subtypes for ROUTE-REFRESH Message . . . . . . . . . . . 3 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction It is sometimes necessary to perform routing consistency validations such as checking for possible missing withdraws between BGP speakers [RFC4271]. Currently such validations typically involve off-line, manual operations which can be tedious and time consuming. In this document we enhance the existing BGP route refresh mechanisms [RFC2918] to provide for the demarcation of the beginning and the @@ -155,112 +157,123 @@ remove any routes from the peer that are still marked as stale for that . Such purged routes MAY be logged for future analysis. An implementation MAY impose a locally configurable upper bound on how long it would retain any stale routes. Once the upper bound is reached, the implementation MAY remove any routes from the peer that are still marked as stale for that without waiting for an EoRR message. + The following procedures are specified in order to simplify the + interaction with the BGP Graceful Restart [RFC4724]. For a BGP + speaker that supports the BGP Graceful Restart, it MUST NOT send a + BoRR for an AFI/SAFI to a neighbor before it sends the EOR for the + AFI/SAFI to the neighbor. A BGP speaker that has received the + Graceful Restart Capability from its neighbor, MUST ignore any BoRRs + for an AFI/SAFI from the neighbor before the speaker receives the EoR + for the given AFI/SAFI from the neighbor. The BGP speaker SHOULD log + an error of the condition for further analysis. + 5. Error Handling This document defines a new NOTIFICATION error code: Error Code Symbolic Name TBD ROUTE-REFRESH Message Error The following error subcodes are defined as well: Subcode Symbolic Name 1 Invalid Message Length The error handling specified in this section is applicable only when a BGP speaker has received the "Enhanced Route Refresh Capability" from a peer. - When the BGP speaker detects an error while processing a ROUTE- - REFRESH message with a non-zero "Message Subtype" field, it MUST send - a NOTIFICATION message with Error Code "ROUTE-REFRESH Message Error". - The Data field of the NOTIFICATION message MUST contain the complete - ROUTE-REFRESH message. - - If the length, excluding the fixed-size message header, of the ROUTE- - REFRESH message with Message Subtype 1 and 2 is not 4, then the error - subcode is set to "Invalid Message Length". + If the length, excluding the fixed-size message header, of the + received ROUTE-REFRESH message with Message Subtype 1 and 2 is not 4, + then the BGP speaker MUST send a NOTIFICATION message with the Error + Code of "ROUTE-REFRESH Message Error" and the subcode of "Invalid + Message Length". The Data field of the NOTIFICATION message MUST + contain the complete ROUTE-REFRESH message. - When the BGP speaker receives a ROUTE-REFRESH message with an invalid - Subtype, it SHOULD log an error and ignore the received ROUTE-REFRESH - message. + When the BGP speaker receives a ROUTE-REFRESH message with a "Message + Subtype" field other than 0, 1 or 2, it MUST ignore the received + ROUTE-REFRESH message. It SHOULD log an error for further analysis. 6. IANA Considerations This document defines the Enhanced Route Refresh Capability for BGP. The Capability Code 70 has been assigned by the IANA. This document also defines two new subcodes for the Route Refresh message. They need to be registered with the IANA. We request IANA to create a new registry for the Route Refresh message subcodes as follows: Under "Border Gateway Protocol (BGP) Parameters": Registry: "BGP Route Refresh Subcodes" - Reference: [draft-ietf-idr-bgp-enhanced-refresh-05.txt] + Reference: [draft-ietf-idr-bgp-enhanced-refresh-06.txt] Registration Procedure(s): Values 0-127 Standards Action, values 128-254 First Come, First Served, Value 255 reserved Value Code Reference 0 Route-Refresh [RFC2918], [RFC5291] - 1 BoRR [draft-ietf-idr-bgp-enhanced-refresh-05.txt] - 2 EoRR [draft-ietf-idr-bgp-enhanced-refresh-05.txt] + 1 BoRR [draft-ietf-idr-bgp-enhanced-refresh-06.txt] + 2 EoRR [draft-ietf-idr-bgp-enhanced-refresh-06.txt] 255 Reserved In addition, this document defines an NOTIFICATION error code and several error subcodes for the ROUTE-REFRESH message. The NOTIFICATION error code need to be registered with the IANA. We request IANA to create a new registry for the error subcodes as follows: Under "BGP Error Subcodes": Registry: "BGP ROUTE-REFRESH Message Error subcodes" - Reference: [draft-ietf-idr-bgp-enhanced-refresh-05.txt] + Reference: [draft-ietf-idr-bgp-enhanced-refresh-06.txt] Registration Procedure(s): Values 0-127 Standards Action, values 128-255 First Come, First Served Value Code Reference 0 Reserved - 1 Invalid Message Length [draft-ietf-idr-bgp-enhanced-refresh-05.txt] + 1 Invalid Message Length [draft-ietf-idr-bgp-enhanced-refresh-06.txt] 7. Security Considerations This extension to BGP does not change the underlying security issues. 8. Acknowledgements The authors would like to thank Pedro Marques, Pradosh Mohapatra, - Robert Raszuk, Pranav Mehta, and Shyam Sethuram, Bruno Decraene, - Martin Djernaes, Jeff haas, Ilya Varlashkin, Rob Shakir, Paul Jakma, - Jie Dong, Qing Zeng, Albert Tian, and Jakob Heitz for their review - and comments. The authors would like to thank John Scudder for the - review and contribution to this document. + Robert Raszuk, Pranav Mehta, Shyam Sethuram, Bruno Decraene, Martin + Djernaes, Jeff Haas, Ilya Varlashkin, Rob Shakir, Paul Jakma, Jie + Dong, Qing Zeng, Albert Tian, Jakob Heitz and Chris Hall for their + review and comments. The authors would like to thank John Scudder + for the review and contribution to this document. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. + [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. + Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, + January 2007. + [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, August 2008. [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, February 2009. Authors' Addresses Keyur Patel Cisco Systems @@ -270,17 +283,14 @@ Email: keyupate@cisco.com Enke Chen Cisco Systems 170 W. Tasman Drive San Jose, CA 95124 95134 USA Email: enkechen@cisco.com + Balaji Venkatachalapathy - Cisco Systems - 170 W. Tasman Drive - San Jose, CA 95124 95134 - USA - Email: bvenkata@cisco.com + Email: balaji_pv@hotmail.com