idnits 2.17.1 draft-idr-bgp-route-refresh-options-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 is 1 instance 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 (August 29, 2018) is 2039 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 606, but not defined == Missing Reference: 'RFC7752' is mentioned on line 611, but not defined ** Obsolete undefined reference: RFC 7752 (Obsoleted by RFC 9552) == Missing Reference: 'RFC2119' is mentioned on line 596, but not defined == Missing Reference: 'TBD' is mentioned on line 178, but not defined == Missing Reference: 'RFC4271' is mentioned on line 601, but not defined == Missing Reference: 'Wikipedia' is mentioned on line 625, but not defined Summary: 3 errors (**), 0 flaws (~~), 8 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 Arrcus, Inc 4 Intended status: Standards Track A. Vyavaharkar 5 Expires: March 2, 2019 Cisco Systems 6 N. Fazlollahi 7 Unaffiliated 8 A. Przygienda 9 Juniper Networks 10 August 29, 2018 12 Extension to BGP's Route Refresh Message 13 draft-idr-bgp-route-refresh-options-05 15 Abstract 17 [RFC2918] defines a route refresh capability to be exchanged between 18 BGP speakers. BGP speakers that support this capability are 19 advertising that they can resend the entire BGP Adj-RIB-Out on 20 receipt of a refresh request. By supporting this capability, BGP 21 speakers are more flexible in applying any inbound routing policy 22 changes as they no longer have to store received routes in their 23 unchanged form or reset the session when an inbound routing policy 24 change occurs. The route refresh capability is advertised per AFI, 25 SAFI combination. 27 There are newer AFI, SAFI types that have been introduced to BGP that 28 support a variety of route types (e.g. IPv4/MVPN, L2VPN/EVPN). 29 Currently, there is no way to request a subset of routes in a Route 30 Refresh message for a given AFI, SAFI. This draft defines route 31 refresh capability extensions that help BGP speakers to request a 32 subset of routes for a given address family. This is expected to 33 reduce the amount of update traffic being generated by route refresh 34 requests as well as lessen the burden on the router servicing such 35 requests. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on March 2, 2019. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 This document may contain material from IETF Documents or IETF 70 Contributions published or made publicly available before November 71 10, 2008. The person(s) controlling the copyright in some of this 72 material may not have granted the IETF Trust the right to allow 73 modifications of such material outside the IETF Standards Process. 74 Without obtaining an adequate license from the person(s) controlling 75 the copyright in such materials, this document may not be modified 76 outside the IETF Standards Process, and derivative works of it may 77 not be created outside the IETF Standards Process, except to format 78 it for publication as an RFC or to translate it into languages other 79 than English. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 84 1.1. Use Case Examples . . . . . . . . . . . . . . . . . . . . 3 85 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 86 3. Route Refresh Options Capability . . . . . . . . . . . . . . 4 87 4. Route Refresh Sub-Types . . . . . . . . . . . . . . . . . . . 5 88 5. Route Refresh Option format . . . . . . . . . . . . . . . . . 5 89 6. Route Refresh Option Length . . . . . . . . . . . . . . . . . 6 90 7. Route Refresh ID . . . . . . . . . . . . . . . . . . . . . . 6 91 8. Route Refresh Option Flags . . . . . . . . . . . . . . . . . 7 92 9. Route Refresh Options . . . . . . . . . . . . . . . . . . . . 8 93 10. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 94 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 11 95 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 96 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 97 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 98 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 99 15.1. Normative References . . . . . . . . . . . . . . . . . . 12 100 15.2. Information References . . . . . . . . . . . . . . . . . 13 101 Appendix A. Sequence Number Binary Arithmetic . . . . . . . . . 14 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 104 1. Introduction 106 [RFC2918] defines a route refresh capability to be exchanged between 107 BGP speakers. BGP speakers that support this capability are 108 advertising that they can resend the entire BGP Adj-RIB-Out on 109 receipt of a refresh request. By supporting this capability, BGP 110 speakers are more flexible in applying inbound routing policy changes 111 as they no longer have to store copies of received routes in their 112 unchanged form or reset the session when an inbound routing policy 113 change occurs. The route refresh capability is advertised per AFI, 114 SAFI combination. 116 Route refresh allows routers to dynamically request a full Adj-RIB- 117 Out update from their peers when there's an inbound routing policy 118 change. This is useful because routers that mutually support this 119 capability no longer have to flap the peering session or store an 120 extra copy of received routes in their original form. This helps by 121 reducing memory requirements as well as eliminating the unnecessary 122 churn caused by session flaps. [RFC2918] does not define a way for 123 routers to request a subset of the Adj-RIB-Out for a given AFI, SAFI. 125 This draft defines new extensions to route refresh that will allow 126 requesting routers to ask for a subset of the Adj-RIB-Out for a given 127 AFI, SAFI combination. For example, routers could ask for specific 128 route types from those address families that support multiple route 129 types or, they could ask for a specific prefix. 131 As part of the new extensions, this draft combines elements of 132 [RFC7313] and [RFC5291] and adds a new set of options to the route 133 refresh message that will specify filters that can be applied to 134 limit the scope of the refresh being requested. The new option 135 format will apply to all new option types that may be defined moving 136 forward. 138 1.1. Use Case Examples 140 The authors acknowledge that while the extensions being proposed in 141 this draft could potentially be addressed by Route Target Constrain 142 described in [RFC4684] by using route targets to identify desired 143 subset of routes, this proposal includes address families where RT 144 Constrain extension is not supported and avoids the necessity to 145 assign and manage the route targets per desired set of routes. The 146 approach in this draft is intended to be a single-hop refresh only, 147 i.e., propagation of the refreshes in a way similar to RT Constrain 148 routes is NOT intended. 150 Several possible use cases are discernible today: 152 o The capacity to refresh routes of a certain type within an address 153 family is needed, e.g., auto discovery routes within the EVPN AF 154 [RFC7432]. 156 o In VPN scenarios where RT Constrain is not supported or 157 configured, RDs can be used. 159 o In BGP LS [RFC7752] cases a speaker may choose to hold only a 160 subset of routes and depending on configuration request a subset 161 of routes. This document could provide further filters to support 162 those use cases. 164 o On changes in inbound policy, when previously configured filters 165 have been removed, only the according subset of routes may be 166 requested. 168 2. Requirements Language 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 3. Route Refresh Options Capability 176 A BGP speaker will use the BGP Capabilities Advertisement [RFC5492] 177 to advertise the Route Refresh Options Capability to its peers. This 178 new capability will be advertised using the Capability code [TBD] 179 with a capability length of 0. 181 By advertising the Route Refresh Options Capability to a peer, a BGP 182 speaker indicates that it is capable of receiving and processing the 183 route refresh options described below. This new capability can be 184 advertised along with the Enhanced Route Refresh Capability described 185 in [RFC7313]. However, if the Route Refresh Options Capability has 186 been negotiated by both sides of the BGP session, then it will 187 override the Enhanced Route Refresh Capability. 189 4. Route Refresh Sub-Types 191 [RFC7313] defines route refresh BGP message sub-types that utilize 192 the "Reserved" field of the Route Refresh message originally defined 193 in [RFC2918]. Currently, there are three sub-types defined and this 194 draft proposes three additional sub-types which will be used to 195 indicate a Route Refresh message that includes options before any ORF 196 field of the Route Refresh message as well as BoRR and EoRR Route 197 Refresh messages with options. 199 0 - Normal route refresh request [RFC2918] 200 with/without Outbound Route Filtering (ORF) [RFC5291] 201 1 - Demarcation of the beginning of a route refresh 202 (BoRR) operation 203 2 - Demarcation of the ending of a route refresh 204 (EoRR) operation 205 + 3 - Route Refresh request with options and optional 206 ORF [RFC5291] 207 + 4 - BoRR with options 208 + 5 - EoRR with options 209 255 - Reserved 211 When the Route Refresh Options Capability has been negotiated by both 212 sides of a BGP session, both peers MUST use message types 3, 4 and 5. 213 The requesting speaker MUST use the refresh ID for all refresh 214 requests including those without any options, i.e., requests for the 215 full BGP Adj-RIB-Out. 217 The Route Refresh Request Message with options will now be formatted 218 as shown below 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | A F I | Res. | S A F I | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Total Option Length | Refresh ID# | Flags | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | One or more Route Refresh Options | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 5. Route Refresh Option format 232 [RFC2918] defines the route refresh BGP message that includes only 233 the AFI, SAFI of the routes being requested. This draft proposes 234 extending the basic message by including options that will indicate 235 to the remote BGP speaker that a subset of the entire Adj-RIB-Out is 236 being requested. The remote BGP speaker will select routes that 237 match the specified options and the flag settings. 239 As described in the previous section, the options will be added to 240 the Route Refresh message before the ORF field of the message. 241 Outbound Route Filtering is described in [RFC5291]. The options will 242 assume the following format 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Length Of Options Field | Refresh ID# | Flags | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | One or more Route Refresh Options | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 6. Route Refresh Option Length 254 The Option Length field will occupy the two octets immediately 255 following the Route Refresh message containing the AFI, SAFI and sub- 256 type. The purpose of this field is to allow the BGP speaker to 257 calculate the length of any attached ORF fields by subtracting the 258 Option Length from the Route Refresh message length. 260 7. Route Refresh ID 262 The Refresh ID field will occupy twelve bits following the Route 263 Refresh Options Length. It is infeasible to use a wide number like a 264 64-bit unsigned integer since this number must be stored per route 265 entry associated with any peer supporting this feature, at least 266 during the time any refresh is pending. It is a value assigned by 267 the requesting BGP speaker. It MUST be a strictly monotonically 268 increasing number per peer AFI and SAFI using sequence number 269 arithmetic based on two-complements given in Appendix A. It is 270 comparable to the calculations standardized in [RFC1982] but fixes 271 several of its anomalies. The purpose of this field is to allow the 272 requesting BGP speaker to correlate concurrent, overlapping refresh 273 requests and ultimately delete correct stale routes. The Refresh ID 274 MUST be reflected in the BoRR and EoRR messages sent by the BGP 275 speaker servicing the refresh request. 277 A Refresh ID value MUST NOT be reused until an EoRR with this ID has 278 been received by the requesting speaker or the last resort time has 279 expired. The behavior is unspecified otherwise. More specifically, 280 defining the interval [ LID, HID ] by the values 281 LID = MAX(lowest requested Refresh ID# without BoRR, 282 lowest received BoRR without EoRR) 284 and 286 HID = highest requested Refresh ID# 288 the requesting speaker MUST only use values V where V >: LID and V >: 289 HID as defined by the relation given in Appendix A. Beside that, HID 290 =>: LID MUST hold by the same algebra. 292 If no such number V exists, LID must catch up to HID, i.e. no further 293 requests can be issued. To use a 3 bit example in Appendix A, if LID 294 was 1 and HID was 4, we cannot progress to unsigned 5 since 1 ? 5. 295 When LID progresses to unsigned 2 however, we have 5 >: 2 and 5 >: 4 296 and we can choose a V. 298 Value of 0 MUST NEVER be used as Refresh ID and is considered an 299 "invalid" ID. 301 The sending speaker MUST NOT reorder the BoRR messages on sending in 302 case it received multiple requests, i.e., the BoRRs MUST follow in 303 the same sequence as the requested Route Refresh IDs. 305 8. Route Refresh Option Flags 307 This draft defines several route refresh option flags: 309 o 'O'-bit specifies whether the receiving BGP speaker MUST logically 310 OR the attached options or logically AND them (in case of the bit 311 being clear). When the flag is clear, the router on the receiving 312 end SHOULD logically AND the options and only refresh routes that 313 match all received options. If the option flag is set, the router 314 SHOULD select routes that match using a logical OR of the options. 315 In any case the set of routes sent between the according BoRR and 316 EoRR MUST contain at least the logically requested set. 318 o 'C' bit indicates that the receiving BGP speaker MUST clear 319 immediately all the received Route Refresh Requests with Options, 320 either pending or being processed. EoRRs MUST NOT be sent. The 321 Refresh ID# on the request MUST be set as the (in unsigned terms) 322 next possible number L for which LID >: L and HID >: L per 323 Appendix A or in other words we "wrap around the sequence number 324 space" on reset. The C flag MUST NOT be set on BoRR or EoRR 325 messages and CAN be used only with refresh requests. 327 o by 'S' bit indicate a refresh is being spontaneously originated by 328 the BGP speaker which received requests and has them pending. The 329 receiving BGP speaker MUST immediately clear all their pending 330 Route Refresh requests with the sending peer. The Refresh ID# on 331 the request MUST be set as the the largest unsigned number L for 332 which LID >: L and HID >: L. When this flag is set, the receiving 333 BGP speaker MUST use this sequence number for its next request. 334 To use example from Appendix A, if the peer received LID 4 and HID 335 5 (i.e. it didn't send BoRR for 4 yet but received request for 5 336 already) it will reset the sequence number to 1 by those rules. 337 Now, if there is a request with 6 in flight, it will be seen as 1 338 >: 6 when arriving. 340 The precise format is indicated below 342 0 1 2 3 4 5 6 7 343 +-+-+-+-+-+-+-+-+ 344 | .... |C|O|S|R| 345 +-+-+-+-+-+-+-+-+ 347 C Clear pending requests and reset Refresh ID# space. 349 O Use logical OR of attached options 351 S Synchronize sequence numbers 353 R Reserved bit 355 9. Route Refresh Options 357 This draft introduces new options carried within the Route Refresh 358 message as shown in the following figure 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Type | Length | Value | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Value (cont'd). | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 The option Type is a 1 octet field that uniquely identifies 369 individual options. The Length is a 2 octet field that contains the 370 length of the option Value field in octets. The option Value is a 371 variable length field that is interpreted according to the value of 372 the option Type field. 374 The following types are being defined in this draft and additional 375 types can be defined subsequently as needed 377 + 1 - Route Type 378 + 2 - NLRI Prefix 379 + 3 - Route Distinguisher Prefix 381 The Route Type option would specify a particular route type that is 382 being requested. This option applies specifically to those AFI/SAFI 383 combinations that support multiple route types, e.g. L2VPN/EVPN and 384 MUST be otherwise ignored. The value field would be the route type 385 specifying which route type was being requested. The length of the 386 option depends on the AFI/SAFI. 388 The NLRI Prefix option would specify a request for all matching 389 address prefixes with their lengths equal to or greater than the 390 specified prefix per AFI/SAFI definitions. The value field would 391 contain the address prefix according to the NLRI specification of the 392 AFI/SAFI contained in the Route Refresh message. For those AFI/SAFI 393 combinations that specify NLRIs containing a type and/or RD, the 394 value field MUST exclude the type and RD and SHOULD only include any 395 remaining NLRI fields. If the requesting speaker expects its peer to 396 also match the type and/or RD, the speaker CAN include the type and 397 RD prefix options accordingly. The length field would contain the 398 length of the value field in bits. 400 The Route Distinguisher prefix option would specify an RD prefix that 401 is being requested for AFs that support it. The receiving BGP 402 speaker would then refresh all routes in the specified AFI/SAFI that 403 matched the requested RDs. The Value field would contain the RD, its 404 length and the mask length of the RD prefix. This option applies 405 specifically to those AFI/SAFI combinations that support route 406 distinguishers and MUST be otherwise ignored. 408 10. Operation 410 A BGP speaker that understands and supports Route Refresh Options 411 SHOULD advertise the Route Refresh Options Capability in its Open 412 message. The following procedures for route refresh are only 413 applicable if the BGP speaker originating the route refresh has 414 received the route refresh options capability and supports it. 416 When originating a Route Refresh message, a BGP speaker SHOULD use 417 and set these options if it wants to restrict the scope of updates 418 being refreshed. The specific options being sent will be set 419 according to the operator's command. 421 When a BGP speaker receives a route refresh message that includes any 422 options, it MUST parse the options and strongly SHOULD use them to 423 filter outgoing NLRIs when refreshing the Adj-RIB-Out to the 424 requesting BGP speaker. 426 If a BGP speaker receives the route refresh message with the message 427 subtype set to BoRR with options as described above, then it needs to 428 process all the included options and MUST mark all matching routes as 429 stale as described in [RFC7313]. 431 If a BGP speaker receives the route refresh message with the message 432 subtype set to EoRR with options as described above, then it needs to 433 process all the included options and delete any remaining stale 434 routes that match the options received with the EoRR as described in 435 [RFC7313]. 437 A BGP speaker responding to a route refresh request MUST set the 438 message subtypes of the BoRR and EoRR messages so that each BoRR 439 message has a matching EoRR message. This means a BoRR message 440 without options SHOULD only be followed eventually by an EoRR message 441 without options. Similarly, a BoRR message with options MUST 442 eventually be followed by an EoRR message with the same options. If 443 BoRR and EoRR message options do not match, the outcome is 444 unpredictable as remaining staled routes pending a refresh may get 445 inadvertently deleted. BGP speakers MUST NOT summarize EoRR messages 446 by combining options in order to allow the requesting BGP speaker to 447 uniquely identify the included sets of routes when concurrent 448 refreshes are originated with overlapping sets of routes. 450 Observe that overlapping refreshes with different options are 451 possible and in such case the according BoRR and EoRR messages are 452 associated by using their Refresh ID#. The BGP speaker responding to 453 the route refresh requests MAY perform the refreshes in parallel. In 454 case of concurrent refreshes overlapping same routes, the responding 455 speaker MUST ensure that the sent advertisements will result in 456 deletion of the omitted routes at the time all EoRRs have been 457 received by the remote speaker or it MUST explicitly advertise 458 withdrawals to correct any anomalies. 460 The BGP speaker requesting a refresh from its peers SHOULD maintain a 461 locally configurable upper bound on how long it will keep matching 462 stale routes once a BoRR has been received. Each subsequent BoRR 463 SHOULD reset this period so that any remaining stale routes are only 464 flushed after the last BoRR has been received in case there are 465 multiple back-to-back refreshes being sent out and the last matching 466 EoRR is never received or arrives too late. This is an 467 implementation specific detail. 469 A BGP speaker may spontaneously originate a refresh to one or more of 470 its peers depending on operator intervention, or due to a policy or 471 configuration change, etc. In such a case, the speaker MUST refresh 472 the entire Adj-RIB-Out. The speaker MUST also send BoRR/EoRR with the 473 options field with the 'S' flag set and a sequence number which lies 474 outside the range of the sequence numbers that are currently in use 475 with the receiving BGP speaker. 477 11. Error Handling 479 The handling of malformed options MUST follow the procedures 480 mentioned in [RFC7606]. This draft obsoletes some of the error 481 handling procedures in [RFC7313] if the Route Refresh Options 482 Capability is sent. In addition, this draft mandates the following 483 behavior at the receiver of the route refresh request upon detection 484 of: 486 Length errors - If the message length minus the fixed-size message 487 header is less than 4, the procedure in [RFC7313] MUST be followed. 488 Also, if the overall length of all the options or any individual 489 option length exceeds the total number of remaining bytes, the same 490 procedure MUST be followed. 492 Option type errors - Any unknown option type CAN be ignored for 493 AND'ed options. In case of OR'ed options the receiving speaker MUST 494 ignore all the options and de-facto treat it as a full AFI/SAFI Adj- 495 RIB-Out refresh. Such event SHOULD be logged in either case to 496 notify the operator. 498 Option value errors - Length errors which cannot be distinguished 499 from value field errors at the receiver are treated the same as value 500 errors. The receiver MUST send a NOTIFICATION message with the Error 501 Code "ROUTE-REFRESH Message Error" and the subcode of Invalid Message 502 Length to the peer. The Data field of the NOTIFICATION message MUST 503 contain the complete ROUTE-REFRESH message. 505 BoRR with "unknown" or "invalid" Refresh ID# - The receiver MUST 506 discard all pending requests and issue a Route Refresh Request with 507 Options. The options MUST be empty and the clear flag MUST be set to 508 resynchronize the RIBs. "Unknown" means here a BoRR which is not in 509 the interval 511 [ MAX(lowest requested Refresh ID# without BoRR, 512 highest received BoRR+1 respecting sequence number arithmetic), 513 highest requested Refresh ID# ] 515 EoRR with unknown Refresh ID# - Those SHOULD be ignored and a warning 516 or error MUST be logged. 518 BoRR or EoRR with incorrect options - analogous to BoRR with unknown 519 Refresh ID#. 521 EoRR with known Refresh ID# but without preceding BoRR - analogous to 522 EoRR with unknown Refresh ID#. Observe that this can be caused by the 523 peer expiring last resort timer and reusing the ID# for another 524 request before the EoRR is received. This should be extremely 525 unlikely given the size of the refresh ID space. 527 12. IANA Considerations 529 This draft defines a new route refresh options format for BGP Route 530 Refresh messages. 532 This draft defines a new route refresh capability for BGP Route 533 Refresh messages. We request IANA to record this capability to 534 create a new registry under BGP Capability Codes as follows: 536 +74 Route Refresh Options Capability 538 This draft defines 3 new route refresh message subtypes for BGP Route 539 Refresh messages. We request IANA to record these subtypes to create 540 a new registry under BGP Route Refresh Subcodes as follows: 542 + 3 - Route Refresh with options 543 + 4 - BoRR with options 544 + 5 - EoRR with options 546 13. Security Considerations 548 This extension to BGP does not change the underlying security issues 549 inherent in the existing [RFC7313] and [RFC4271]. 551 14. Acknowledgements 553 The authors would like to thank Anant Utgikar for initial discussions 554 resulting in this work. John Scudder and Jeff Hass provided further 555 comments. 557 15. References 559 15.1. Normative References 561 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 562 DOI 10.17487/RFC1982, August 1996, 563 . 565 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 566 DOI 10.17487/RFC2918, September 2000, 567 . 569 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 570 R., Patel, K., and J. Guichard, "Constrained Route 571 Distribution for Border Gateway Protocol/MultiProtocol 572 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 573 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 574 November 2006, . 576 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 577 Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, 578 August 2008, . 580 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 581 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 582 2009, . 584 [RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced 585 Route Refresh Capability for BGP-4", RFC 7313, 586 DOI 10.17487/RFC7313, July 2014, 587 . 589 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 590 Patel, "Revised Error Handling for BGP UPDATE Messages", 591 RFC 7606, DOI 10.17487/RFC7606, August 2015, 592 . 594 15.2. Information References 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, 599 . 601 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 602 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 603 DOI 10.17487/RFC4271, January 2006, 604 . 606 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 607 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 608 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 609 2015, . 611 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 612 S. Ray, "North-Bound Distribution of Link-State and 613 Traffic Engineering (TE) Information Using BGP", RFC 7752, 614 DOI 10.17487/RFC7752, March 2016, 615 . 617 [Wikipedia] 618 Wikipedia, 619 "https://en.wikipedia.org/wiki/Serial_number_arithmetic", 620 2016. 622 Appendix A. Sequence Number Binary Arithmetic 624 The only reasonably reference to a cleaner than [RFC1982] sequence 625 number solution is given in [Wikipedia]. It basically converts the 626 problem into two complement's arithmetic. Assuming a straight two 627 complement's substractions on the bit-width of the sequence number 628 the according >: and =: relations are defined as: 630 U_1, U_2 are 12-bits aligned unsigned version number 632 D_f is ( U_1 - U_2 ) interpreted as two complement signed 12-bits 633 D_b is ( U_2 - U_1 ) interpreted as two complement signed 12-bits 635 U_1 >: U_2 IIF D_f > 0 AND D_b < 0 636 U_1 =: U_2 IIF D_f = 0 638 The >: relationsship is symmetric but not transitive. Observe that 639 this leaves the case of the numbers having maximum two complement 640 distance, e.g. ( 0 and 0x800 ) undefined in our 12-bits case since 641 D_f and D_b are both -0x7ff. 643 A simple example of the relationship in case of 3-bit arithmetic 644 follows as table indicating D_f/D_b values and then the relationship 645 of U_1 to U_2: 647 U2 / U1 0 1 2 3 4 5 6 7 648 0 +/+ +/- +/- +/- -/- -/+ -/+ -/+ 649 1 -/+ +/+ +/- +/- +/- -/- -/+ -/+ 650 2 -/+ -/+ +/+ +/- +/- +/- -/- -/+ 651 3 -/+ -/+ -/+ +/+ +/- +/- +/- -/- 652 4 -/- -/+ -/+ -/+ +/+ +/- +/- +/- 653 5 +/- -/- -/+ -/+ -/+ +/+ +/- +/- 654 6 +/- +/- -/- -/+ -/+ -/+ +/+ +/- 655 7 +/- +/- +/- -/- -/+ -/+ -/+ +/+ 657 U2 / U1 0 1 2 3 4 5 6 7 658 0 = > > > ? < < < 659 1 < = > > > ? < < 660 2 < < = > > > ? < 661 3 < < < = > > > ? 662 4 ? < < < = > > > 663 5 > ? < < < = > > 664 6 > > ? < < < = > 665 7 > > > ? < < < = 667 Authors' Addresses 669 Keyur Patel 670 Arrcus, Inc 671 USA 673 Email: keyur@arrcus.com 675 Aamod Vyavaharkar 676 Cisco Systems 677 821 Alder Drive 678 Milpitas, CA 95035 679 USA 681 Email: avyavaha@cisco.com 683 Niloofar Fazlollahi 684 Unaffiliated 685 USA 687 Email: Niloofar_fazlollahi@yahoo.com 689 Tony Przygienda 690 Juniper Networks 691 1194 N. Mathilda Ave 692 Sunnyvale, CA 94089 693 USA 695 Email: prz@juniper.net