idnits 2.17.1 draft-ietf-idr-bgp-enhanced-route-refresh-05.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 9, 2013) is 3785 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR K. Patel 3 Internet-Draft E. Chen 4 Intended status: Standards Track B. Venkatachalapathy 5 Expires: June 12, 2014 Cisco Systems 6 December 9, 2013 8 Enhanced Route Refresh Capability for BGP-4 9 draft-ietf-idr-bgp-enhanced-route-refresh-05.txt 11 Abstract 13 In this document we enhance the existing BGP route refresh mechanisms 14 to provide for the demarcation of the beginning and the ending of a 15 route refresh. The enhancement can be used to facilitate correction 16 of BGP RIB inconsistencies in a non-disruptive manner. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on June 12, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 54 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 2 55 3.1. Enhanced Route Refresh Capability . . . . . . . . . . . . 2 56 3.2. Subtypes for ROUTE-REFRESH Message . . . . . . . . . . . 3 57 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 62 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 It is sometimes necessary to perform routing consistency validations 68 such as checking for possible missing withdraws between BGP speakers 69 [RFC4271]. Currently such validations typically involve off-line, 70 manual operations which can be tedious and time consuming. 72 In this document we enhance the existing BGP route refresh mechanisms 73 [RFC2918] to provide for the demarcation of the beginning and the 74 ending of a route refresh (which refers to the complete re- 75 advertisement of the Adj-RIB-Out to a peer, subject to routing 76 policies). The enhancement can be used to facilitate on-line, non- 77 disruptive consistency validation of BGP routing updates. 79 2. Requirements Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 83 be interpreted as described in [RFC2119] only when they appear in all 84 upper case. They may also appear in lower or mixed case as English 85 words, without any normative meaning. 87 3. Protocol Extensions 89 The BGP protocol extensions introduced in this document include the 90 definition of a new BGP capability, named "Enhanced Route Refresh 91 Capability", and the specification of the message subtypes for the 92 ROUTE-REFRESH message. 94 3.1. Enhanced Route Refresh Capability 95 The "Enhanced Route Refresh Capability" is a new BGP capability 96 [RFC5492]. IANA has assigned a Capability Code of 70 for this 97 capability . The Capability Length field of this capability is zero. 99 By advertising this capability to a peer, a BGP speaker conveys to 100 the peer that the speaker supports the message subtypes for the 101 ROUTE-REFRESH message and the related procedures described in this 102 document. 104 3.2. Subtypes for ROUTE-REFRESH Message 106 The "Reserved" field of the ROUTE-REFRESH message specified in 107 [RFC2918] is re-defined as the "Message Subtype" with the following 108 values: 110 0 - Normal route refresh request [RFC2918] 111 with/without ORF [RFC5291] 112 1 - Demarcation of the beginning of a route refresh operation. 113 Also known as a "BoRR message" or just a "BoRR". 114 2 - Demarcation of the ending of a route refresh operation. 115 Also known as a "EoRR message" or just a "EoRR". 117 The remaining values of the message subtypes are reserved for future 118 use. The use of the new message subtypes is described in the 119 Operations section. 121 4. Operation 123 A BGP speaker that supports the message subtypes for the ROUTE- 124 REFRESH message and the related procedures SHOULD advertise the 125 "Enhanced Route Refresh Capability". 127 The following procedures are applicable only if a BGP speaker has 128 received the "Enhanced Route Refresh Capability" from a peer. 130 Before the speaker starts a route refresh that is either initiated 131 locally, or in response to a "normal route refresh request" from the 132 peer, the speaker MUST send a BoRR message. After the speaker 133 completes the re-advertisement of the entire Adj-RIB-Out to the peer, 134 it MUST send an EoRR message. 136 Conceptually the "entire Adj-RIB-Out" for a peer in this section 137 refers to all the route entries in the "Adj-RIB-Out" for the peer at 138 the start of the route refresh operation. These route entries 139 comprise of both, the reachability as well as unreachability 140 information. When a route entry in the "ADJ-RIB-Out" changes, only 141 the modified route entry needs to be advertised. 143 In processing a ROUTE-REFRESH message from a peer, the BGP speaker 144 MUST examine the "message subtype" field of the message and take the 145 appropriate actions. The message processing rules for ROUTE-REFRESH 146 message with subtype of 0 are described in [RFC2918] and [RFC5291]. 147 A BGP speaker can receive a BoRR message from a peer at anytime, 148 either as a result of a peer responding to a ROUTE-REFESH message, or 149 as a result of a peer unilaterally initiating a route refresh. When 150 a BGP speaker receives a BoRR message from a peer, it MUST mark all 151 the routes with the given from that peer as stale. As it 152 receives routes from its peer's subsequent Adj-RIB-Out re- 153 advertisement, these replace any corresponding stale routes. When a 154 BGP speaker receives an EoRR message from a peer, it MUST immediately 155 remove any routes from the peer that are still marked as stale for 156 that . Such purged routes MAY be logged for future 157 analysis. 159 An implementation MAY impose a locally configurable upper bound on 160 how long it would retain any stale routes. Once the upper bound is 161 reached, the implementation MAY remove any routes from the peer that 162 are still marked as stale for that without waiting for an 163 EoRR message. 165 5. Error Handling 167 This document defines a new NOTIFICATION error code: 169 Error Code Symbolic Name 171 TBD ROUTE-REFRESH Message Error 173 The following error subcodes are defined as well: 175 Subcode Symbolic Name 177 1 Invalid Message Length 179 The error handling specified in this section is applicable only when 180 a BGP speaker has received the "Enhanced Route Refresh Capability" 181 from a peer. 183 When the BGP speaker detects an error while processing a ROUTE- 184 REFRESH message with a non-zero "Message Subtype" field, it MUST send 185 a NOTIFICATION message with Error Code "ROUTE-REFRESH Message Error". 186 The Data field of the NOTIFICATION message MUST contain the complete 187 ROUTE-REFRESH message. 189 If the length, excluding the fixed-size message header, of the ROUTE- 190 REFRESH message with Message Subtype 1 and 2 is not 4, then the error 191 subcode is set to "Invalid Message Length". 193 When the BGP speaker receives a ROUTE-REFRESH message with an invalid 194 Subtype, it SHOULD log an error and ignore the received ROUTE-REFRESH 195 message. 197 6. IANA Considerations 199 This document defines the Enhanced Route Refresh Capability for BGP. 200 The Capability Code 70 has been assigned by the IANA. This document 201 also defines two new subcodes for the Route Refresh message. They 202 need to be registered with the IANA. We request IANA to create a new 203 registry for the Route Refresh message subcodes as follows: 205 Under "Border Gateway Protocol (BGP) Parameters": 206 Registry: "BGP Route Refresh Subcodes" 207 Reference: [draft-ietf-idr-bgp-enhanced-refresh-05.txt] 208 Registration Procedure(s): Values 0-127 Standards Action, values 209 128-254 First Come, First Served, Value 255 reserved 211 Value Code Reference 212 0 Route-Refresh [RFC2918], [RFC5291] 213 1 BoRR [draft-ietf-idr-bgp-enhanced-refresh-05.txt] 214 2 EoRR [draft-ietf-idr-bgp-enhanced-refresh-05.txt] 215 255 Reserved 217 In addition, this document defines an NOTIFICATION error code and 218 several error subcodes for the ROUTE-REFRESH message. The 219 NOTIFICATION error code need to be registered with the IANA. We 220 request IANA to create a new registry for the error subcodes as 221 follows: 223 Under "BGP Error Subcodes": 224 Registry: "BGP ROUTE-REFRESH Message Error subcodes" 225 Reference: [draft-ietf-idr-bgp-enhanced-refresh-05.txt] 226 Registration Procedure(s): Values 0-127 Standards Action, values 227 128-255 First Come, First Served 229 Value Code Reference 230 0 Reserved 231 1 Invalid Message Length [draft-ietf-idr-bgp-enhanced-refresh-05.txt] 233 7. Security Considerations 235 This extension to BGP does not change the underlying security issues. 237 8. Acknowledgements 239 The authors would like to thank Pedro Marques, Pradosh Mohapatra, 240 Robert Raszuk, Pranav Mehta, and Shyam Sethuram, Bruno Decraene, 241 Martin Djernaes, Jeff haas, Ilya Varlashkin, Rob Shakir, Paul Jakma, 242 Jie Dong, Qing Zeng, Albert Tian, and Jakob Heitz for their review 243 and comments. The authors would like to thank John Scudder for the 244 review and contribution to this document. 246 9. Normative References 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, March 1997. 251 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 252 September 2000. 254 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 255 Protocol 4 (BGP-4)", RFC 4271, January 2006. 257 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 258 Capability for BGP-4", RFC 5291, August 2008. 260 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 261 with BGP-4", RFC 5492, February 2009. 263 Authors' Addresses 265 Keyur Patel 266 Cisco Systems 267 170 W. Tasman Drive 268 San Jose, CA 95124 95134 269 USA 271 Email: keyupate@cisco.com 273 Enke Chen 274 Cisco Systems 275 170 W. Tasman Drive 276 San Jose, CA 95124 95134 277 USA 279 Email: enkechen@cisco.com 280 Balaji Venkatachalapathy 281 Cisco Systems 282 170 W. Tasman Drive 283 San Jose, CA 95124 95134 284 USA 286 Email: bvenkata@cisco.com