idnits 2.17.1 draft-raszuk-aggr-withdraw-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 31. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 444), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 444. ** Found boilerplate matching RFC 3978, Section 5.5 (on line 31), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 4 text on line 468. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 478 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 22 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.5 boilerplate, a section with a similar start was also found: This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 21 has weird spacing: '...t forth there...' == Line 454 has weird spacing: '...for the purpo...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2005) is 6767 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: 'BGP4' is mentioned on line 144, but not defined == Missing Reference: 'BGP-CAP' is mentioned on line 197, but not defined == Missing Reference: 'RFC-2434' is mentioned on line 348, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'RFC2434' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'RFC1771' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'IDR-BGP4' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'RFC2858' is defined on line 368, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 1771 (Obsoleted by RFC 4271) == Outdated reference: A later version (-26) exists of draft-ietf-idr-bgp4-21 -- Obsolete informational reference (is this intentional?): RFC 2858 (Obsoleted by RFC 4760) -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 1700 (Obsoleted by RFC 3232) Summary: 13 errors (**), 0 flaws (~~), 15 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Robert Raszuk 3 Internet Draft Keyur Patel 4 Expiration Date April 2006 Chandra Appanna 5 David Ward 6 Cisco Systems, Inc 8 October 2005 10 BGP Aggregate Withdraw 11 draft-raszuk-aggr-withdraw-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 This document is subject to the rights, licenses and restrictions 21 contained in BCP 78, and except as set forth therein, the authors retain 22 all their rights. 24 This document and the information contained herein 25 are provided on an "AS IS" basis and THE CONTRIBUTOR, THE 26 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 27 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 28 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 29 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 30 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 31 OR FITNESS FOR A PARTICULAR PURPOSE. 33 Internet-Drafts are working documents of the Internet 34 Engineering Task Force (IETF), its areas, and its 35 working groups. Note that other groups may also distribute 36 working documents as Internet-Drafts. Internet-Drafts 37 are draft documents valid for a maximum of six months and 38 may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in 41 progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 Copyright (C) The Internet Society (2005). 51 Abstract 53 This document proposes a scheme that allows a BGP speaker to withdraw 54 multiple NLRIs that share a set of properties more efficiently by 55 just specifying the shared properties among them. 57 1. Introduction 59 This document proposes a scheme that allows a BGP speaker to withdraw 60 multiple NLRIs that share a set of properties more efficiently by 61 just specifying the shared properties among them. 63 One area where this kind of feature is particularly important is 64 2547. The growth and success of 2547 VPN deployments forces operators 65 and vendors to seek much more efficient and scalable mechanisms 66 for vpn prefix management in VPN networks. 68 This draft introduces new BGP attribute called MP_AGGREGATE_WITHDRAW 69 attribute which allows BGP to withdraw multiple NLRIs in a single 70 message thereby reducing significantly the load on routers, number of 71 BGP update messages and convergence time. 73 MP_AGGREGATE_WITHDRAW can also be used to implement Graceful Shutdown 74 functionality to allow rerouting of traffic before the BGP session is 75 down. 77 This mechanism is applicable to and works for any BGP AFI/SAFI. 79 2. Specification of Requirements 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 3. MP_AGGREGATE_WITHDRAW Attribute (Type Code TBD by IANA) 87 This is an optional non-transitive attribute that can be used for the 88 purpose of aggregating multiple unfeasible NLRIs to be removed from 89 service. 91 The attribute is encoded as shown below: 93 +---------------------------------------------------------+ 94 | Address Family Identifier (2 octets) | 95 +---------------------------------------------------------+ 96 | Subsequent Address Family Identifier (1 octet) | 97 +---------------------------------------------------------+ 98 | Flags (2 octets) | 99 +---------------------------------------------------------+ 100 | Total Attribute Length (2 octets) | 101 +---------------------------------------------------------+ 102 | Attributes (variable length) | 103 +---------------------------------------------------------+ 104 | TLVs (optional & variable length) | 105 +---------------------------------------------------------+ 107 The use and the meaning of these fields are as follows: 109 Address Family Identifier: 111 This field carries the identity of the Network Layer protocol 112 associated with the NLRI that follows. Presently defined values 113 for this field are specified in RFC 1700 (see the Address 114 Family Numbers section). 116 Subsequent Address Family Identifier: 118 This field provides additional information about the type of 119 the Network Layer Reachability Information carried in the 120 attribute. 122 Flags: 124 This 2-octet unsigned integer indicates Flags value for the 125 the MP_AGGREGATE_WITHDRAW. The flags are defined as: 127 0x01 Withdraw paths that match all attributes 128 0x02 Withdraw paths that match any one or more attributes 129 0x04 Set to one only when TLVs are present 131 Total Attribute Length: 133 This 2-octet unsigned integer indicates the total length of the 134 Path Attributes field in octets. Its value allows the length of 135 the Network Layer Reachability field to be determined as 136 specified below. 138 A value of 0 indicates that neither the Network Layer Reacha- 139 bility Information field, nor the Path Attribute field is 140 present in this UPDATE message. 142 Attributes: 144 For format description refer to [BGP4]. 146 TLVs: 148 In the case where there is a need to send other information 149 then those carried in BGP attributes to uniquely identify the 150 NLRIs to be withdrawn we define a TLV field. 152 The following TLV format has been defined: 154 Type One octet field set to value of given TLV. 155 Length One octet field that indicates the length of the 156 value portion in octets. 157 Reserved One octet field reserved for future flags 158 Value Description of the value carried in given TLV 160 An UPDATE message that contains the MP_AGGREGATE_WITHDRAW is not 161 required to carry any other path attributes. 163 Only one or zero of TLV value per MP_AGGREGATE_WITHDRAW attribute 164 should be present. If the TLV value is present alone (no attributes) 165 the match should happen on this value alone. 167 4. TLV definitions 169 4.1 Route Distinguisher 171 In the 2547 VPNs [RFC2547] in the MP_AGGREGATE_WITHDRAW there is a 172 need for unique identification of VPN routes to which attached 173 attributes belong to. This is accomplished by distributing route 174 distinguisher in the following tlv encoding: 176 Type: One octet field set to value of 1 177 Length: One octet field set to value of eight 178 Reserved: One octet field reserved (all zeros) 179 Value: Eight octet RD value 181 4.2 TIME_TO_WITHDRAW 183 This time represents a TIME_TO_WITHDRAW. It is has a value 184 field length of 2 octet. This type represents the time after 185 which the forwarding support will be withdrawn for all reachability 186 associated with the MP_AGGREGATE_WITHDRAW and is a value in 187 seconds. 189 Type: One octet field set to value of 1 190 Length: One octet field set to a value of 2 191 Reserved: One octet field reserved (all zeros) 192 Value: 2 octet value representing number of seconds 194 5. MP_AGGREGATE_WITHDRAW Capability 196 The MP_AGGREGATE_WITHDRAW Capability is a new BGP capability 197 [BGP-CAP] that can be used by a BGP speaker to indicate its ability 198 to receive and send aggregated withdraws. 200 This capability is defined as follows: 202 Capability code: TBD by IANA 204 Capability length: variable 206 Capability value: Consists of the one or more of the tuples 207 as follows: 209 +--------------------------------------------------+ 210 | Address Family Identifier (16 bits) | 211 +--------------------------------------------------+ 212 | Subsequent Address Family Identifier (8 bits) | 213 +--------------------------------------------------+ 214 | ... | 215 +--------------------------------------------------+ 216 | Address Family Identifier (16 bits) | 217 +--------------------------------------------------+ 218 | Subsequent Address Family Identifier (8 bits) | 219 +--------------------------------------------------+ 221 Address Family Identifier (AFI): 223 This field carries the identity of the Network Layer protocol 224 for which the Graceful Restart support is advertised. Presently 225 defined values for this field are specified in [RFC1700]. 227 Subsequent Address Family Identifier (SAFI): 229 This field provides additional information about the type of 230 the Network Layer Reachability Information carried in the 231 attribute. Presently defined values for this field are 232 specified in [RFC1700]. 234 6. Aggregate Withdraw Extended Community Attribute 236 Aggregate Withdraw Extended Community is a mandatory non-transitive 237 extended community that can be used for the purpose of uniformed 238 marking closed NLRI groups with common fate sharing. The mandatory 239 requirement comes from a fact that an implementation which supports 240 MP_AGGREGATE_WITHDRAW must also support Aggregate Withdraw Extended 241 Community. 243 Aggregate Withdraw Extended Community attribute is carried in BGP 244 Extended Community Attribute of type code 16. 246 The Aggregate Withdraw Extended Community attribute is encoded as 247 follows: 249 0 1 2 3 250 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type high | Type low | Value | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Value (cont.) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 The value of the high-order octet of the type field for the Marker 258 Community can be 0x43. That indicated first come first served IANA 259 type of assignment, non-transitive, opaque extended community 261 The value of the low-order octet of the type field for this community 262 is .... (TBD). 264 The value is a locally significant 6 octet value assigned by bgp 265 speaker to differentiate the routes based on various operator's 266 depended requirements. It's allocation can be fully algorithmic and 267 automatic or it could be assigned some meaningful structure. Being a 268 locally significant it can be overwritten by any BGP speaker. 270 7. Operation 272 A BGP speaker receiving an update message with MP_AGGREGATE_WITHDRAW 273 does not support MP_AGGREGATE_WITHDRAW capability, it simply ignores 274 the message and logs the warning. 276 The BGP speaker implementing MP_AGGREGATE_WITHDRAW capability and 277 receiving an update message with MP_AGGREGATE_WITHDRAW should remove 278 all the NLRIs (paths) that match the attribute and TLV list specified 279 in the MP_AGGREGATE_WITHDRAW attribute for each AFI/SAFI. The 280 matching of the attributes is further qualified by the operation type 281 specified in the flags field associated with the AFi/SAFI and can be 282 logical AND or OR. 284 The additional TLV value presence is indicated by by the flags field. 285 It's value will always be a logical AND to all other attributes if 286 present. 288 If the the TIME_TO_WITHDRAW is sent in the MP_AGGREGATE_WITHDRAW, it 289 must be interpreted by the receiveing BGP speaker as the minimum duration 290 for which the sending BGP speaker will preserve forwarding of reachability 291 already announced prior to receiving this MP_AGGREGATE_WITHDRAW. 292 The purpose of TIME_TO_WITHDRAW is to allow the implentation of 293 Graceful Shutdown funtionality whereby the receiving BGP speaker is 294 provided a some time to reconverge before the sending BGP speaker is 295 no longer available for forwarding traffic. 297 In the event of an AFI/SAFI being in the MP_AGGREGATE_WITHDRAW 298 attribute that is not supported as per the initial capability 299 negotiation, a BGP Notification message with the notification code 300 set to UNSUPPORTED_AFI_SAFI should be sent and the session should be 301 terminated. 303 8. Deployment Considerations 305 8.1 Sessions to all CEs in a vrf goes down or is being shutdown. 307 Today: All vrf routes are send within MP_UNREACH 309 New: A single message with RD lists all export RTs which were 310 under given vrf is being send. 312 8.2 Sessions to one CE in a vrf goes down or is being shutdown. 314 Today: All routes from a given CE are send within MP_UNREACH 316 New: A single message with marker extended community and 317 optionally an RD under given vrf is being send. 319 8.3 A subset of routes or all routes of given AFI/SAFI marked with a 320 unique community or an attribute 322 Today: It would require to send all route in an MP_UNREACH attribute 324 New: Just one msg with MP_AGGREGATE_WITHDRAW listing this unique 325 attribute would be sufficient 327 8.4 A BGP next hop on NLRIs with a single path goes down 329 Today: It would require to send all routes in an MP_UNREACH attribute 331 New: Just one msg with MP_AGGREGATE_WITHDRAW listing this next hop 332 will be sufficient. 334 9. Security Considerations 336 This extension to BGP does not change the underlying security issues 337 inherent in the existing BGP [RFC2385]. 339 10. Acknowledgments 341 The authors would like to thank Dan Tappan and Shyam Suri for their 342 suggestions and feedback. 344 11.IANA Considerations 346 This document defines new BGP MP_AGGREGATE_WITHDRAW attribute. New 347 attribute code should be introduced using the Standards Action 348 process defined in [RFC-2434]. 350 12. Normative References 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", RFC 2119, March 1997. 355 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an 356 IANA Considerations Section in RFCs", RFC 2434, October 357 1998. 359 13. Informative References 361 [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 362 (BGP-4)", RFC 1771, March 1995. 364 [IDR-BGP4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 365 (BGP-4)", Work in Progress (draft-ietf-idr-bgp4-21.txt), 366 April 2003. 368 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., Katz, D., 369 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000 371 [RFC2547] Rosen, E., Rekhter Y., "BGP/MPLS VPNs", RFC2547, March 1999 373 [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an 374 IANA Considerations Section in RFCs", RFC 2434/BCP 0026, 375 October, 1998. 377 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 378 Signature Option", RFC 2385, August, 1998. 380 [RFC1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, 381 RFC 1700, October 1994. See also: 382 http://www.iana.org/numbers.html. 384 14. Authors' Addresses 386 Robert Raszuk 387 Cisco Systems, Inc. 388 170 West Tasman Dr 389 San Jose, CA 95134 390 raszuk@cisco.com 392 Keyur Patel 393 Cisco Systems, Inc. 394 170 West Tasman Dr 395 San Jose, CA 95134 396 keyupate@cisco.com 398 Chandra Appanna 399 Cisco Systems, Inc. 400 170 West Tasman Dr 401 San Jose, CA 95134 402 achandra@cisco.com 404 David Ward 405 Cisco Systems, Inc. 406 170 West Tasman Dr 407 San Jose, CA 95134 408 wardd@cisco.com 410 15. IPR Notices 412 The IETF takes no position regarding the validity or scope of any 413 intellectual property or other rights that might be claimed to 414 pertain to the implementation or use of the technology described in 415 this document or the extent to which any license under such rights 416 might or might not be available; neither does it represent that it 417 has made any effort to identify any such rights. Information on the 418 IETF's procedures with respect to rights in standards-track and 419 standards-related documentation can be found in BCP-11. Copies of 420 claims of rights made available for publication and any assurances of 421 licenses to be made available, or the result of an attempt made to 422 obtain a general license or permission for the use of such 423 proprietary rights by implementors or users of this specification can 424 be obtained from the IETF Secretariat. 426 The IETF invites any interested party to bring to its attention any 427 copyrights, patents or patent applications, or other proprietary 428 rights which may cover technology that may be required to practice 429 this standard. Please address the information to the IETF Executive 430 Director. 432 16. Terms of Use 434 Cisco has a pending patent which relates to the subject matter of 435 this Internet Draft. If a standard relating to this subject matter 436 is adopted by IETF and any claims of any issued Cisco patents are 437 necessary for practicing this standard, any party will be able to 438 obtain a license from Cisco to use any such patent claims under 439 openly specified, reasonable, non-discriminatory terms to implement 440 and fully comply with the standard. 442 17. Full Copyright Notice 444 Copyright (C) The Internet Society (2005). All Rights Reserved. 446 This document and translations of it may be copied and furnished to 447 others, and derivative works that comment on or otherwise explain it 448 or assist in its implmentation may be prepared, copied, published and 449 distributed, in whole or in part, without restriction of any kind, 450 provided that the above copyright notice and this paragraph are 451 included on all such copies and derivative works. However, this 452 document itself may not be modified in any way, such as by removing 453 the copyright notice or references to the Internet Society or other 454 Internet organizations, except as needed for the purpose of 455 developing Internet standards in which case the procedures for 456 copyrights defined in the Internet Standards process must be 457 followed, or as required to translate it into languages other than 458 English. 460 The limited permissions granted above are perpetual and will not be 461 revoked by the Internet Society or its successors or assigns. 463 This document and the information contained herein is provided on an 464 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 465 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 466 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 467 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 468 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.