idnits 2.17.00 (12 Aug 2021) /tmp/idnits21832/draft-idr-bgp-route-refresh-options-00.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 (July 08, 2016) is 2143 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 566, but not defined == Missing Reference: 'RFC7752' is mentioned on line 571, but not defined == Missing Reference: 'RFC2119' is mentioned on line 556, but not defined == Missing Reference: 'TBD' is mentioned on line 174, but not defined == Missing Reference: 'RFC4271' is mentioned on line 561, 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: January 09, 2017 Cisco Systems 6 A. Przygienda 7 Juniper Networks 8 July 08, 2016 10 Extension to BGP's Route Refresh Message 11 draft-idr-bgp-route-refresh-options-00.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 January 09, 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 . . . . . . . . . . . . . . . . . . . . 7 90 10. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10 92 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 93 13. Security Considerations . . . . . . . . . . . . . . . . . . . 11 94 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 95 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 15.1. Normative References . . . . . . . . . . . . . . . . . . 12 97 15.2. Information References . . . . . . . . . . . . . . . . . 12 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 to 292 o specify whether the receiving BGP speaker MUST logically OR the 293 attached options or logically AND them. When the flag is clear, 294 the router on the receiving end SHOULD logically AND the options 295 and only refresh routes that match all received options. If the 296 option flag is set, the router SHOULD select routes that match 297 using a logical OR of the options. In any case the set of routes 298 sent between the according BoRR and EoRR MUST contain at least the 299 logically requested set. 301 o indicate that the receiving BGP speaker MUST clear immediately all 302 the received Route Refresh Requests with Options, either pending 303 or being processed. EoRRs MUST NOT be sent. The Refresh ID# on 304 the request is free of restrictions and MUST be set as first 305 number in the sequence number space per [RFC1982]. The C flag 306 MUST NOT be set on BoRR or EoRR messages and CAN be used only with 307 refresh requests. 309 The precise format is indicated below 311 0 1 2 3 4 5 6 7 312 +-+-+-+-+-+-+-+-+ 313 | .... |C|O| R | 314 +-+-+-+-+-+-+-+-+ 316 C Clear pending requests and reset Refresh ID# space. 318 O Use logical OR of attached options 320 R Reserved bits 322 9. Route Refresh Options 324 This draft introduces new options carried within the Route Refresh 325 message as shown in the following figure 327 0 1 2 3 328 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type | Length | Value | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Value (cont'd). | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 The option Type is a 1 octet field that uniquely identifies 337 individual options. The Length is a 2 octet field that contains the 338 length of the option Value field in octets. The option Value is a 339 variable length field that is interpreted according to the value of 340 the option Type field. 342 The following types are being defined in this draft and additional 343 types can be defined subsequently as needed 345 + 1 - Route Type 346 + 2 - NLRI Prefix 347 + 3 - Route Distinguisher Prefix 349 The Route Type option would specify a particular route type that is 350 being requested. This option applies specifically to those AFI/SAFI 351 combinations that support multiple route types, e.g. L2VPN/EVPN and 352 MUST be otherwise ignored. The value field would be the route type 353 specifying which route type was being requested. The length of the 354 option depends on the AFI/SAFI. 356 The NLRI Prefix option would specify a request for all matching 357 address prefixes with their lengths equal to or greater than the 358 specified prefix per AFI/SAFI definitions. The value field would 359 contain the address prefix according to the NLRI specification of the 360 AFI/SAFI contained in the Route Refresh message. For those AFI/SAFI 361 combinations that specify NLRIs containing a type and/or RD, the 362 value field MUST exclude the type and RD and SHOULD only include any 363 remaining NLRI fields. If the requesting speaker expects its peer to 364 also match the type and/or RD, the speaker CAN include the type and 365 RD prefix options accordingly. The length field would contain the 366 length of the value field in bits. 368 The Route Distinguisher prefix option would specify an RD prefix that 369 is being requested for AFs that support it. The receiving BGP 370 speaker would then refresh all routes in the specified AFI/SAFI that 371 matched the requested RDs. The Value field would contain the RD, its 372 length and the mask length of the RD prefix. This option applies 373 specifically to those AFI/SAFI combinations that support route 374 distinguishers and MUST be otherwise ignored. 376 10. Operation 378 A BGP speaker that understands and supports Route Refresh Options 379 SHOULD advertise the Route Refresh Options Capability in its Open 380 message. The following procedures for route refresh are only 381 applicable if the BGP speaker originating the route refresh has 382 received the route refresh options capability and supports it. 384 When originating a Route Refresh message, a BGP speaker SHOULD use 385 and set these options if it wants to restrict the scope of updates 386 being refreshed. The specific options being sent will be set 387 according to the operator's command. 389 When a BGP speaker receives a route refresh message that includes any 390 options, it MUST parse the options and strongly SHOULD use them to 391 filter outgoing NLRIs when refreshing the Adj-RIB-Out to the 392 requesting BGP speaker. 394 If a BGP speaker receives the route refresh message with the message 395 subtype set to BoRR with options as described above, then it needs to 396 process all the included options and MUST mark all matching routes as 397 stale as described in [RFC7313]. 399 If a BGP speaker receives the route refresh message with the message 400 subtype set to EoRR with options as described above, then it needs to 401 process all the included options and delete any remaining stale 402 routes that match the options received with the EoRR as described in 403 [RFC7313]. 405 A BGP speaker responding to a route refresh request MUST set the 406 message subtypes of the BoRR and EoRR messages so that each BoRR 407 message has a matching EoRR message. This means a BoRR message 408 without options SHOULD only be followed eventually by an EoRR message 409 without options. Similarly, a BoRR message with options MUST 410 eventually be followed by an EoRR message with the same options. If 411 BoRR and EoRR message options do not match, the outcome is 412 unpredictable as remaining staled routes pending a refresh may get 413 inadvertently deleted. BGP speakers MUST NOT summarize EoRR messages 414 by combining options in order to allow the requesting BGP speaker to 415 uniquely identify the included sets of routes when concurrent 416 refreshes are originated with overlapping sets of routes. 418 Observe that overlapping refreshes with different options are 419 possible and in such case the according BoRR and EoRR messages are 420 associated by using their Refresh ID#. The BGP speaker responding to 421 the route refresh requests MAY perform the refreshes in parallel. In 422 case of concurrent refreshes overlapping same routes, the responding 423 speaker MUST ensure that the sent advertisements will result in 424 deletion of the omitted routes at the time all EoRRs have been 425 received by the remote speaker or it MUST explicitly advertise 426 withdrawals to correct any anomalies. 428 The BGP speaker requesting a refresh from its peers SHOULD maintain a 429 locally configurable upper bound on how long it will keep matching 430 stale routes once a BoRR has been received. Each subsequent BoRR 431 SHOULD reset this period so that any remaining stale routes are only 432 flushed after the last BoRR has been received in case there are 433 multiple back-to-back refreshes being sent out and the last matching 434 EoRR is never received or arrives too late. This is an 435 implementation specific detail. 437 11. Error Handling 439 The handling of malformed options MUST follow the procedures 440 mentioned in [RFC7606]. This draft obsoletes some of the error 441 handling procedures in [RFC7313] if the Route Refresh Options 442 Capability is sent. In addition, this draft mandates the following 443 behavior at the receiver of the route refresh request upon detection 444 of: 446 Length errors - If the message length minus the fixed-size message 447 header is less than 4, the procedure in [RFC7313] MUST be followed. 448 Also, if the overall length of all the options or any individual 449 option length exceeds the total number of remaining bytes, the same 450 procedure MUST be followed. 452 Option type errors - Any unknown option type CAN be ignored for 453 AND'ed options. In case of OR'ed options the receiving speaker MUST 454 ignore all the options and de-facto treat it as a full AFI/SAFI Adj- 455 RIB-Out refresh. Such event SHOULD be logged in either case to 456 notify the operator. 458 Option value errors - Length errors which cannot be distinguished 459 from value field errors at the receiver are treated the same as value 460 errors. The receiver MUST send a NOTIFICATION message with the Error 461 Code "ROUTE-REFRESH Message Error" and the subcode of Invalid Message 462 Length to the peer. The Data field of the NOTIFICATION message MUST 463 contain the complete ROUTE-REFRESH message. 465 BoRR with unknown Refresh ID# - The receiver MUST discard all pending 466 requests and issue a Route Refresh Request with Options. The options 467 MUST be empty and the clear flag MUST be set to resynchronize the 468 RIBs. "Unknown" means here a BoRR which is not in the interval 470 [ MAX(lowest requested Refresh ID# without BoRR, 471 highest received BoRR+1 respecting [RFC1982]), 473 highest requested Refresh ID# ] 475 EoRR with unknown Refresh ID# - Those SHOULD be ignored and a warning 476 or error MUST be logged. 478 BoRR or EoRR with incorrect options - analogous to BoRR with unknown 479 Refresh ID#. 481 EoRR with known Refresh ID# but without preceding BoRR - analogous to 482 EoRR with unknown Refresh ID#. Observe that this can be caused by the 483 peer expiring last resort timer and reusing the ID# for another 484 request before the EoRR is received. This should be extremely 485 unlikely given the size of the refresh ID space. 487 12. IANA Considerations 489 This draft defines a new route refresh options format for BGP Route 490 Refresh messages. 492 This draft defines a new route refresh capability for BGP Route 493 Refresh messages. We request IANA to record this capability to 494 create a new registry under BGP Capability Codes as follows: 496 +74 Route Refresh Options Capability 498 This draft defines 3 new route refresh message subtypes for BGP Route 499 Refresh messages. We request IANA to record these subtypes to create 500 a new registry under BGP Route Refresh Subcodes as follows: 502 + 3 - Route Refresh with options 503 + 4 - BoRR with options 504 + 5 - EoRR with options 506 13. Security Considerations 508 This extension to BGP does not change the underlying security issues 509 inherent in the existing [RFC7313] and [RFC4271]. 511 14. Acknowledgements 513 The authors would like to thank Anant Utgikar for initial discussions 514 resulting in this work. John Scudder and Jeff Hass provided further 515 comments. 517 15. References 519 15.1. Normative References 521 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 522 DOI 10.17487/RFC1982, August 1996, 523 . 525 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 526 DOI 10.17487/RFC2918, September 2000, 527 . 529 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 530 R., Patel, K., and J. Guichard, "Constrained Route 531 Distribution for Border Gateway Protocol/MultiProtocol 532 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 533 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 534 November 2006, . 536 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 537 Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, 538 August 2008, . 540 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 541 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 542 2009, . 544 [RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced 545 Route Refresh Capability for BGP-4", RFC 7313, DOI 546 10.17487/RFC7313, July 2014, 547 . 549 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 550 Patel, "Revised Error Handling for BGP UPDATE Messages", 551 RFC 7606, DOI 10.17487/RFC7606, August 2015, 552 . 554 15.2. Information References 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 558 RFC2119, March 1997, 559 . 561 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 562 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487 563 /RFC4271, January 2006, 564 . 566 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 567 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 568 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 569 2015, . 571 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 572 S. Ray, "North-Bound Distribution of Link-State and 573 Traffic Engineering (TE) Information Using BGP", RFC 7752, 574 DOI 10.17487/RFC7752, March 2016, 575 . 577 Authors' Addresses 579 Keyur Patel 580 Cisco Systems 581 821 Alder Drive 582 Milpitas, CA 95035 583 USA 585 Email: keyupate@cisco.com 587 Aamod Vyavaharkar 588 Cisco Systems 589 821 Alder Drive 590 Milpitas, CA 95035 591 USA 593 Email: avyavaha@cisco.com 595 Niloofar Fazlollahi 596 Cisco Systems 597 821 Alder Drive 598 Milpitas, CA 95035 599 USA 601 Email: nifazlol@cisco.com 603 Tony Przygienda 604 Juniper Networks 605 1194 N. Mathilda Ave 606 Sunnyvale, CA 94089 607 USA 609 Email: prz@juniper.net