idnits 2.17.00 (12 Aug 2021) /tmp/idnits22207/draft-idr-bgp-route-refresh-options-01.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 18 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2918]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 14, 2016) is 2014 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) == Missing Reference: 'RFC7432' is mentioned on line 586, but not defined == Missing Reference: 'RFC7752' is mentioned on line 591, but not defined == Missing Reference: 'RFC2119' is mentioned on line 576, but not defined == Missing Reference: 'TBD' is mentioned on line 174, but not defined == Missing Reference: 'RFC4271' is mentioned on line 581, but not defined Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Patel 3 Internet-Draft A. Vyavaharkar 4 Intended status: Standards Track N. Fazlollahi 5 Expires: May 18, 2017 Cisco Systems 6 A. Przygienda 7 Juniper Networks 8 November 14, 2016 10 Extension to BGP's Route Refresh Message 11 draft-idr-bgp-route-refresh-options-01.txt 13 Abstract 15 [RFC2918] defines a route refresh capability to be exchanged between 16 BGP speakers. BGP speakers that support this capability are 17 advertising that they can resend the entire BGP Adj-RIB-Out on 18 receipt of a refresh request. By supporting this capability, BGP 19 speakers are more flexible in applying any inbound routing policy 20 changes as they no longer have to store received routes in their 21 unchanged form or reset the session when an inbound routing policy 22 change occurs. The route refresh capability is advertised per AFI, 23 SAFI combination. 25 There are newer AFI, SAFI types that have been introduced to BGP that 26 support a variety of route types (e.g. IPv4/MVPN, L2VPN/EVPN). 27 Currently, there is no way to request a subset of routes in a Route 28 Refresh message for a given AFI, SAFI. This draft defines route 29 refresh capability extensions that help BGP speakers to request a 30 subset of routes for a given address family. This is expected to 31 reduce the amount of update traffic being generated by route refresh 32 requests as well as lessen the burden on the router servicing such 33 requests. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 18, 2017. 51 Copyright Notice 53 Copyright (c) 2016 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 This document may contain material from IETF Documents or IETF 67 Contributions published or made publicly available before November 68 10, 2008. The person(s) controlling the copyright in some of this 69 material may not have granted the IETF Trust the right to allow 70 modifications of such material outside the IETF Standards Process. 71 Without obtaining an adequate license from the person(s) controlling 72 the copyright in such materials, this document may not be modified 73 outside the IETF Standards Process, and derivative works of it may 74 not be created outside the IETF Standards Process, except to format 75 it for publication as an RFC or to translate it into languages other 76 than English. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 1.1. Use Case Examples . . . . . . . . . . . . . . . . . . . . 3 82 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 83 3. Route Refresh Options Capability . . . . . . . . . . . . . . 4 84 4. Route Refresh Sub-Types . . . . . . . . . . . . . . . . . . . 4 85 5. Route Refresh Option format . . . . . . . . . . . . . . . . . 5 86 6. Route Refresh Option Length . . . . . . . . . . . . . . . . . 6 87 7. Route Refresh ID . . . . . . . . . . . . . . . . . . . . . . 6 88 8. Route Refresh Option Flags . . . . . . . . . . . . . . . . . 7 89 9. Route Refresh Options . . . . . . . . . . . . . . . . . . . . 8 90 10. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10 92 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 93 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 94 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 95 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 15.1. Normative References . . . . . . . . . . . . . . . . . . 12 97 15.2. Information References . . . . . . . . . . . . . . . . . 13 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 100 1. Introduction 102 [RFC2918] defines a route refresh capability to be exchanged between 103 BGP speakers. BGP speakers that support this capability are 104 advertising that they can resend the entire BGP Adj-RIB-Out on 105 receipt of a refresh request. By supporting this capability, BGP 106 speakers are more flexible in applying inbound routing policy changes 107 as they no longer have to store copies of received routes in their 108 unchanged form or reset the session when an inbound routing policy 109 change occurs. The route refresh capability is advertised per AFI, 110 SAFI combination. 112 Route refresh allows routers to dynamically request a full Adj-RIB- 113 Out update from their peers when there's an inbound routing policy 114 change. This is useful because routers that mutually support this 115 capability no longer have to flap the peering session or store an 116 extra copy of received routes in their original form. This helps by 117 reducing memory requirements as well as eliminating the unnecessary 118 churn caused by session flaps. [RFC2918] does not define a way for 119 routers to request a subset of the Adj-RIB-Out for a given AFI, SAFI. 121 This draft defines new extensions to route refresh that will allow 122 requesting routers to ask for a subset of the Adj-RIB-Out for a given 123 AFI, SAFI combination. For example, routers could ask for specific 124 route types from those address families that support multiple route 125 types or, they could ask for a specific prefix. 127 As part of the new extensions, this draft combines elements of 128 [RFC7313] and [RFC5291] and adds a new set of options to the route 129 refresh message that will specify filters that can be applied to 130 limit the scope of the refresh being requested. The new option 131 format will apply to all new option types that may be defined moving 132 forward. 134 1.1. Use Case Examples 136 The authors acknowledge that while the extensions being proposed in 137 this draft could potentially be addressed by Route Target Constrain 138 described in [RFC4684] by using route targets to identify desired 139 subset of routes, this proposal includes address families where RT 140 Constrain extension is not supported and avoids the necessity to 141 assign and manage the route targets per desired set of routes. The 142 approach in this draft is intended to be a single-hop refresh only, 143 i.e., propagation of the refreshes in a way similar to RT Constrain 144 routes is NOT intended. 146 Several possible use cases are discernible today: 148 o The capacity to refresh routes of a certain type within an address 149 family is needed, e.g., auto discovery routes within the EVPN AF 150 [RFC7432]. 152 o In VPN scenarios where RT Constrain is not supported or 153 configured, RDs can be used. 155 o In BGP LS [RFC7752] cases a speaker may choose to hold only a 156 subset of routes and depending on configuration request a subset 157 of routes. This document could provide further filters to support 158 those use cases. 160 o On changes in inbound policy, when previously configured filters 161 have been removed, only the according subset of routes may be 162 requested. 164 2. Requirements Language 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [RFC2119]. 170 3. Route Refresh Options Capability 172 A BGP speaker will use the BGP Capabilities Advertisement [RFC5492] 173 to advertise the Route Refresh Options Capability to its peers. This 174 new capability will be advertised using the Capability code [TBD] 175 with a capability length of 0. 177 By advertising the Route Refresh Options Capability to a peer, a BGP 178 speaker indicates that it is capable of receiving and processing the 179 route refresh options described below. This new capability can be 180 advertised along with the Enhanced Route Refresh Capability described 181 in [RFC7313]. However, if the Route Refresh Options Capability has 182 been negotiated by both sides of the BGP session, then it will 183 override the Enhanced Route Refresh Capability. 185 4. Route Refresh Sub-Types 187 [RFC7313] defines route refresh BGP message sub-types that utilize 188 the "Reserved" field of the Route Refresh message originally defined 189 in [RFC2918]. Currently, there are three sub-types defined and this 190 draft proposes three additional sub-types which will be used to 191 indicate a Route Refresh message that includes options before any ORF 192 field of the Route Refresh message as well as BoRR and EoRR Route 193 Refresh messages with options. 195 0 - Normal route refresh request [RFC2918] 196 with/without Outbound Route Filtering (ORF) [RFC5291] 197 1 - Demarcation of the beginning of a route refresh 198 (BoRR) operation 199 2 - Demarcation of the ending of a route refresh 200 (EoRR) operation 201 + 3 - Route Refresh request with options and optional 202 ORF [RFC5291] 203 + 4 - BoRR with options 204 + 5 - EoRR with options 205 255 - Reserved 207 When the Route Refresh Options Capability has been negotiated by both 208 sides of a BGP session, both peers MUST use message types 3, 4 and 5. 209 The requesting speaker MUST use the refresh ID for all refresh 210 requests including those without any options, i.e., requests for the 211 full BGP Adj-RIB-Out. 213 The Route Refresh Request Message with options will now be formatted 214 as shown below 216 0 1 2 3 217 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | A F I | Res. | S A F I | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Total Option Length | Refresh ID# | Flags | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | One or more Route Refresh Options | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 5. Route Refresh Option format 228 [RFC2918] defines the route refresh BGP message that includes only 229 the AFI, SAFI of the routes being requested. This draft proposes 230 extending the basic message by including options that will indicate 231 to the remote BGP speaker that a subset of the entire Adj-RIB-Out is 232 being requested. The remote BGP speaker will select routes that 233 match the specified options and the flag settings. 235 As described in the previous section, the options will be added to 236 the Route Refresh message before the ORF field of the message. 237 Outbound Route Filtering is described in [RFC5291]. The options will 238 assume the following format 239 0 1 2 3 240 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Length Of Options Field | Refresh ID# | Flags | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | One or more Route Refresh Options | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 6. Route Refresh Option Length 249 The Option Length field will occupy the two octets immediately 250 following the Route Refresh message containing the AFI, SAFI and sub- 251 type. The purpose of this field is to allow the BGP speaker to 252 calculate the length of any attached ORF fields by subtracting the 253 Option Length from the Route Refresh message length. 255 7. Route Refresh ID 257 The Refresh ID field will occupy twelve bits following the Route 258 Refresh Options Length. It is a value assigned by the requesting BGP 259 speaker. It MUST be a strictly monotonically increasing number per 260 peer AFI and SAFI and will be comparable using the calculations 261 standardized in [RFC1982]. The purpose of this field is to allow the 262 requesting BGP speaker to correlate concurrent, overlapping refresh 263 requests and ultimately delete correct stale routes. The Refresh ID 264 MUST be reflected in the BoRR and EoRR messages sent by the BGP 265 speaker servicing the refresh request. 267 A Refresh ID value MUST NOT be reused until an EoRR with this ID has 268 been received by the requesting speaker or the last resort time has 269 expired. The behavior is unspecified otherwise. More specifically, 270 defining the interval [ LID, HID ] by the values 272 LID = MAX(lowest requested Refresh ID# without BoRR, 273 lowest received BoRR without EoRR) 275 and 277 HID = highest requested Refresh ID# 279 the requesting speaker MUST only use values V where V > LID and V > 280 HID under [RFC1982]. 282 Value of 0 SHOULD NOT be used as Refresh ID. 284 The sending speaker MUST NOT reorder the BoRR messages on sending in 285 case it received multiple requests, i.e., the BoRRs MUST follow in 286 the same sequence as the requested Route Refresh IDs. 288 8. Route Refresh Option Flags 290 This draft defines route refresh option flags 292 o C - to indicate that the receiving BGP speaker MUST clear 293 immediately all the received Route Refresh Requests with Options, 294 either pending or being processed. EoRRs MUST NOT be sent. The 295 Refresh ID# on the request is free of restrictions and MUST be set 296 as first number in the sequence number space per [RFC1982]. The C 297 flag MUST NOT be set on BoRR or EoRR messages and CAN be used only 298 with refresh requests. 300 o O - to specify whether the receiving BGP speaker MUST logically OR 301 the attached options or logically AND them. When the flag is 302 clear, the router on the receiving end SHOULD logically AND the 303 options and only refresh routes that match all received options. 304 If the option flag is set, the router SHOULD select routes that 305 match using a logical OR of the options. In any case the set of 306 routes sent between the according BoRR and EoRR MUST contain at 307 least the logically requested set. 309 o S - to indicate a refresh is being spontaneously originated by the 310 BGP speaker. The receiving BGP speaker MUST immediately clear all 311 their pending Route Refresh requests with the sending peer. The 312 Refresh ID# on the request MUST be set as the most distant number 313 in the sequence number space as defined in [RFC1982] effectively 314 ensuring that the receiving speaker can safely flush pending 315 requests and restart the sequence numbering. 317 The precise format is indicated below 319 0 1 2 3 4 5 6 7 320 +-+-+-+-+-+-+-+-+ 321 | .... |C|O|S|R| 322 +-+-+-+-+-+-+-+-+ 324 C Clear pending requests and reset Refresh ID# space. 326 O Use logical OR of attached options 328 S Synchronize sequence numbers 330 R Reserved bit 332 9. Route Refresh Options 334 This draft introduces new options carried within the Route Refresh 335 message as shown in the following figure 337 0 1 2 3 338 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Type | Length | Value | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Value (cont'd). | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 The option Type is a 1 octet field that uniquely identifies 346 individual options. The Length is a 2 octet field that contains the 347 length of the option Value field in octets. The option Value is a 348 variable length field that is interpreted according to the value of 349 the option Type field. 351 The following types are being defined in this draft and additional 352 types can be defined subsequently as needed 354 + 1 - Route Type 355 + 2 - NLRI Prefix 356 + 3 - Route Distinguisher Prefix 358 The Route Type option would specify a particular route type that is 359 being requested. This option applies specifically to those AFI/SAFI 360 combinations that support multiple route types, e.g. L2VPN/EVPN and 361 MUST be otherwise ignored. The value field would be the route type 362 specifying which route type was being requested. The length of the 363 option depends on the AFI/SAFI. 365 The NLRI Prefix option would specify a request for all matching 366 address prefixes with their lengths equal to or greater than the 367 specified prefix per AFI/SAFI definitions. The value field would 368 contain the address prefix according to the NLRI specification of the 369 AFI/SAFI contained in the Route Refresh message. For those AFI/SAFI 370 combinations that specify NLRIs containing a type and/or RD, the 371 value field MUST exclude the type and RD and SHOULD only include any 372 remaining NLRI fields. If the requesting speaker expects its peer to 373 also match the type and/or RD, the speaker CAN include the type and 374 RD prefix options accordingly. The length field would contain the 375 length of the value field in bits. 377 The Route Distinguisher prefix option would specify an RD prefix that 378 is being requested for AFs that support it. The receiving BGP 379 speaker would then refresh all routes in the specified AFI/SAFI that 380 matched the requested RDs. The Value field would contain the RD, its 381 length and the mask length of the RD prefix. This option applies 382 specifically to those AFI/SAFI combinations that support route 383 distinguishers and MUST be otherwise ignored. 385 10. Operation 387 A BGP speaker that understands and supports Route Refresh Options 388 SHOULD advertise the Route Refresh Options Capability in its Open 389 message. The following procedures for route refresh are only 390 applicable if the BGP speaker originating the route refresh has 391 received the route refresh options capability and supports it. 393 When originating a Route Refresh message, a BGP speaker SHOULD use 394 and set these options if it wants to restrict the scope of updates 395 being refreshed. The specific options being sent will be set 396 according to the operator's command. 398 When a BGP speaker receives a route refresh message that includes any 399 options, it MUST parse the options and strongly SHOULD use them to 400 filter outgoing NLRIs when refreshing the Adj-RIB-Out to the 401 requesting BGP speaker. 403 If a BGP speaker receives the route refresh message with the message 404 subtype set to BoRR with options as described above, then it needs to 405 process all the included options and MUST mark all matching routes as 406 stale as described in [RFC7313]. 408 If a BGP speaker receives the route refresh message with the message 409 subtype set to EoRR with options as described above, then it needs to 410 process all the included options and delete any remaining stale 411 routes that match the options received with the EoRR as described in 412 [RFC7313]. 414 A BGP speaker responding to a route refresh request MUST set the 415 message subtypes of the BoRR and EoRR messages so that each BoRR 416 message has a matching EoRR message. This means a BoRR message 417 without options SHOULD only be followed eventually by an EoRR message 418 without options. Similarly, a BoRR message with options MUST 419 eventually be followed by an EoRR message with the same options. If 420 BoRR and EoRR message options do not match, the outcome is 421 unpredictable as remaining staled routes pending a refresh may get 422 inadvertently deleted. BGP speakers MUST NOT summarize EoRR messages 423 by combining options in order to allow the requesting BGP speaker to 424 uniquely identify the included sets of routes when concurrent 425 refreshes are originated with overlapping sets of routes. 427 Observe that overlapping refreshes with different options are 428 possible and in such case the according BoRR and EoRR messages are 429 associated by using their Refresh ID#. The BGP speaker responding to 430 the route refresh requests MAY perform the refreshes in parallel. In 431 case of concurrent refreshes overlapping same routes, the responding 432 speaker MUST ensure that the sent advertisements will result in 433 deletion of the omitted routes at the time all EoRRs have been 434 received by the remote speaker or it MUST explicitly advertise 435 withdrawals to correct any anomalies. 437 The BGP speaker requesting a refresh from its peers SHOULD maintain a 438 locally configurable upper bound on how long it will keep matching 439 stale routes once a BoRR has been received. Each subsequent BoRR 440 SHOULD reset this period so that any remaining stale routes are only 441 flushed after the last BoRR has been received in case there are 442 multiple back-to-back refreshes being sent out and the last matching 443 EoRR is never received or arrives too late. This is an 444 implementation specific detail. 446 A BGP speaker may spontaneously originate a refresh to one or more of 447 its peers depending on operator intervention, or due to a policy or 448 configuration change, etc. In such a case, the speaker MUST refresh 449 the entire Adj-RIB-Out. The speaker MUST also send BoRR/EoRR with 450 the options field with the 'S' flag set and a sequence number which 451 is the most distant from the sequence numbers that are currently in 452 use as per [RFC1982]. On receiving BoRR/EoRR with options and the 453 'S' flag set, the BGP speaker MUST discard any pending route 454 refreshes it has originated to the remote peer and treat the incoming 455 refresh as a full Adj-RIB-Out refresh. The receiving peer MUST also 456 reset the refresh ID space and start using the one in the incoming 457 message. 459 11. Error Handling 460 The handling of malformed options MUST follow the procedures 461 mentioned in [RFC7606]. This draft obsoletes some of the error 462 handling procedures in [RFC7313] if the Route Refresh Options 463 Capability is sent. In addition, this draft mandates the following 464 behavior at the receiver of the route refresh request upon detection 465 of: 467 Length errors - If the message length minus the fixed-size message 468 header is less than 4, the procedure in [RFC7313] MUST be followed. 469 Also, if the overall length of all the options or any individual 470 option length exceeds the total number of remaining bytes, the same 471 procedure MUST be followed. 473 Option type errors - Any unknown option type CAN be ignored for 474 AND'ed options. In case of OR'ed options the receiving speaker MUST 475 ignore all the options and de-facto treat it as a full AFI/SAFI Adj- 476 RIB-Out refresh. Such event SHOULD be logged in either case to 477 notify the operator. 479 Option value errors - Length errors which cannot be distinguished 480 from value field errors at the receiver are treated the same as value 481 errors. The receiver MUST send a NOTIFICATION message with the Error 482 Code "ROUTE-REFRESH Message Error" and the subcode of Invalid Message 483 Length to the peer. The Data field of the NOTIFICATION message MUST 484 contain the complete ROUTE-REFRESH message. 486 BoRR with unknown Refresh ID# - The receiver MUST discard all pending 487 requests and issue a Route Refresh Request with Options. The options 488 MUST be empty and the clear flag MUST be set to resynchronize the 489 RIBs. "Unknown" means here a BoRR which is not in the interval 491 [ MAX(lowest requested Refresh ID# without BoRR, 492 highest received BoRR+1 respecting [RFC1982]), 493 highest requested Refresh ID# ] 495 EoRR with unknown Refresh ID# - Those SHOULD be ignored and a warning 496 or error MUST be logged. 498 BoRR or EoRR with incorrect options - analogous to BoRR with unknown 499 Refresh ID#. 501 EoRR with known Refresh ID# but without preceding BoRR - analogous to 502 EoRR with unknown Refresh ID#. Observe that this can be caused by the 503 peer expiring last resort timer and reusing the ID# for another 504 request before the EoRR is received. This should be extremely 505 unlikely given the size of the refresh ID space. 507 12. IANA Considerations 509 This draft defines a new route refresh options format for BGP Route 510 Refresh messages. 512 This draft defines a new route refresh capability for BGP Route 513 Refresh messages. We request IANA to record this capability to 514 create a new registry under BGP Capability Codes as follows: 516 +74 Route Refresh Options Capability 518 This draft defines 3 new route refresh message subtypes for BGP Route 519 Refresh messages. We request IANA to record these subtypes to create 520 a new registry under BGP Route Refresh Subcodes as follows: 522 + 3 - Route Refresh with options 523 + 4 - BoRR with options 524 + 5 - EoRR with options 526 13. Security Considerations 528 This extension to BGP does not change the underlying security issues 529 inherent in the existing [RFC7313] and [RFC4271]. 531 14. Acknowledgements 533 The authors would like to thank Anant Utgikar for initial discussions 534 resulting in this work. John Scudder and Jeff Hass provided further 535 comments. 537 15. References 539 15.1. Normative References 541 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 542 DOI 10.17487/RFC1982, August 1996, 543 . 545 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 546 DOI 10.17487/RFC2918, September 2000, 547 . 549 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 550 R., Patel, K., and J. Guichard, "Constrained Route 551 Distribution for Border Gateway Protocol/MultiProtocol 552 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 553 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 554 November 2006, . 556 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 557 Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, 558 August 2008, . 560 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 561 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 562 2009, . 564 [RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced 565 Route Refresh Capability for BGP-4", RFC 7313, DOI 566 10.17487/RFC7313, July 2014, 567 . 569 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 570 Patel, "Revised Error Handling for BGP UPDATE Messages", 571 RFC 7606, DOI 10.17487/RFC7606, August 2015, 572 . 574 15.2. Information References 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 578 RFC2119, March 1997, 579 . 581 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 582 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487 583 /RFC4271, January 2006, 584 . 586 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 587 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 588 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 589 2015, . 591 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 592 S. Ray, "North-Bound Distribution of Link-State and 593 Traffic Engineering (TE) Information Using BGP", RFC 7752, 594 DOI 10.17487/RFC7752, March 2016, 595 . 597 Authors' Addresses 598 Keyur Patel 599 Cisco Systems 600 821 Alder Drive 601 Milpitas, CA 95035 602 USA 604 Email: keyupate@cisco.com 606 Aamod Vyavaharkar 607 Cisco Systems 608 821 Alder Drive 609 Milpitas, CA 95035 610 USA 612 Email: avyavaha@cisco.com 614 Niloofar Fazlollahi 615 Cisco Systems 616 821 Alder Drive 617 Milpitas, CA 95035 618 USA 620 Email: nifazlol@cisco.com 622 Tony Przygienda 623 Juniper Networks 624 1194 N. Mathilda Ave 625 Sunnyvale, CA 94089 626 USA 628 Email: prz@juniper.net