idnits 2.17.1 draft-dong-idr-one-time-ext-community-orf-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The ORF entries of this type would only be used as one-time filters that MUST not change any previously installed ORF entry on the receiving speaker. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Since different processing orders may lead to different results, the One-time-ORFs and the regular ORFs SHOULD not be encoded in one ROUTE-REFRESH message. -- The document date (March 9, 2012) is 4403 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) == Unused Reference: 'RFC2918' is defined on line 270, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 279, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-idr-bgp-enhanced-route-refresh-01 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft Q. Zeng 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 10, 2012 J. Heitz 6 Ericsson Inc. 7 K. Patel 8 Cisco Systems 9 R. Shakir 10 BT 11 March 9, 2012 13 One-time Extended Community Based Outbound Route Filter for BGP-4 14 draft-dong-idr-one-time-ext-community-orf-02 16 Abstract 18 This document defines a new Outbound Router Filter (ORF) type for 19 BGP, termed "One-time Extended Community Outbound Route Filter", 20 which would allow a BGP speaker to send to its BGP peer a route 21 refresh request with a set of extended-community-based filters to 22 make the peer re-advertise only the specific routes matching the 23 filters to the speaker. This ORF-type enables a BGP speaker to 24 refresh some specific routes without requiring its peer to re- 25 advertise the whole Adj-RIB-Out, which makes the route refresh 26 operation more efficient and reduces the impact on network stability. 27 This filter does not change the outbound route filters on BGP peers 28 and should only be used for one-time filtering. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 10, 2012. 53 Copyright Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. One-time Extended Community ORF-Type . . . . . . . . . . . . . 5 72 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 76 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 The Outbound Route Filtering Capability defined in [RFC5291] provides 82 a mechanism for a BGP speaker to send to its BGP peer a set of 83 Outbound Route Filters (ORFs) that can be used by its peer to filter 84 its outbound routing updates to the speaker. 86 During some network operations, a BGP speaker only needs to retrieve 87 some routes with specific extended communities from its peer, but 88 sending plain ROUTE-REFRESH will lead to the peer re-advertising its 89 whole Adj-RIB-Out. Such a large amount of updates includes a lot of 90 unnecessary routes which would result in waste of processing 91 resources and bandwidth. With the increase of IPv6 deployment, this 92 problem could be more significant. Even configured with the ORF 93 mechanism as defined in [RFC5291], on receipt of a ROUTE-REFRESH 94 message, the peer will re-advertise all the routes matching the 95 current outbound route filters, i.e., the whole Adj-Rib-Out for this 96 BGP speaker. Since in this case the BGP speaker does not want to 97 change the outbound route filters on its peer, this requirement 98 cannot be met by the current ORF mechanism. 100 This document defines a new Outbound Router Filter (ORF) type for 101 BGP, termed "One-time Extended Community Outbound Route Filter", 102 which would allow a BGP speaker to send to its BGP peer a route 103 refresh request with a set of Extended Community based filters to 104 make the peer re-advertise only the specific routes matching the 105 filters to the speaker. This ORF-type enables a BGP speaker to 106 retrieve routes with specific Extended Communities without requiring 107 its peer to re-advertise the whole Adj-RIB-Out, which makes such 108 route refresh operation more efficient and also reduces the impact on 109 network stability. This filter does not change the outbound route 110 filters on BGP peers and should only be used for one-time filtering. 112 One use case of one-time Extended Community ORF would be to refresh 113 routes with specific Route Target (RT) Extended Community. For 114 example, on receipt of routes with specific RTs, according to local 115 policies some attributes of the routes may be changed, or some routes 116 may be discarded. When later such local policies are changed or 117 removed, the routes impacted by such policies need to be refreshed 118 and processed according to the new local policies. With the whole 119 Adj-RIB-Out route refresh it would result in a lot of unnecessary 120 routes being re-advertised, and this would be a waste of the 121 processing resource and bandwidth. In this case, one-time Extended 122 Community ORF would be quite useful to request only routes matching 123 specific RTs to be re-advertised. 125 Another use case is network maintenance or verification. During 126 maintenance, it may be revealed that some routes may be incorrect. A 127 refresh of a small segment of the routing table can help to correct 128 those routes without requiring a refresh of the total routing table. 130 2. One-time Extended Community ORF-Type 132 This document defines a new ORF type: One-time Extended Community 133 ORF. Value of this ORF-Type is to be assigned by IANA. 135 In the following description, the sending speaker sends a one-time- 136 ORF request and the receiving speaker receives it and sends back the 137 routes to satisfy the request. 139 As specified in the [RFC5291], an ORF entry is a tuple of the form 140 . An ORF consists of 141 one or more ORF entries that have a common AFI/SAFI and ORF-Type. An 142 ORF is identified by . 144 The ORF entry consists of a single Extended Community, encoded as 145 either 8 octets [RFC4360], or 20 octets [RFC5701]. The encoding of 146 the type-specific part is as below: 148 +------------------------------------------+ 149 | Ext-community Length (1 octet) | 150 +------------------------------------------+ 151 | Ext-community value (8 or 20 octets) | 152 +------------------------------------------+ 154 The "Ext-community Length" field contains length in octets of the 155 extended community in the "Ext-community value" field. 157 Since the semantics of this new ORF-Type is "one-time filtering" and 158 has no impact on existing ORFs, the Action field is irrelevant and 159 MUST be ignored on receipt. 161 The MATCH field of the One-time Extended Community ORF SHOULD be set 162 to PERMIT on the sender and SHOULD be ignored on the receiver. This 163 is the same as defined in Extended-Community ORF 164 [I-D.chen-bgp-ext-community-orf]. 166 The ORF entries of this type would only be used as one-time filters 167 that MUST not change any previously installed ORF entry on the 168 receiving speaker. 170 3. Operations 172 The capability negotiation of MUST NOT delay the advertisement of routes with this AFI/SAFI. 175 The received One-time Extended Community ORF entries SHOULD only be 176 used for one-time route filtering and MUST NOT be saved locally. The 177 received One-time Extended Community ORF entries MUST NOT modify the 178 outbound route filters on the receiving speaker (either locally 179 configured or received from the sending speaker through ORF). 181 On receipt of ROUTE-REFRESH message with One-time Extended Community 182 ORF entries, the receiving speaker SHOULD re-advertise to the sending 183 speaker the routes from the Adj-RIB-Out associated with the sending 184 speaker which pass the entries carried in the One-time Extended 185 Community ORF as well as the locally saved ORFs (if any) received 186 from the sending speaker. 188 Since different processing orders may lead to different results, the 189 One-time-ORFs and the regular ORFs SHOULD not be encoded in one 190 ROUTE-REFRESH message. 192 During the period when the receiving speaker is sending updates to 193 satisfy the One-time-ORF request, it may experience other routing 194 activity that will require it to send updates unrelated to the One- 195 time-ORF request. It is permitted to send these updates before it 196 has completed sending the One-time-ORF related updates. 198 Similarly, if a route that passes the One-time-ORF has already been 199 sent and the receiving speaker experiences routing activity that 200 changes this route and the receiving speaker has not yet sent all 201 routes to satisfy the One-time-ORF request, it is permitted to send 202 the changed route immediately. A withdrawal of the route counts as a 203 valid change. 205 If the receiving speaker has received the Enhanced Route Refresh 206 Capability as described in [I-D.ietf-idr-bgp-enhanced-route-refresh], 207 then it SHALL perform the following additional procedures. 209 It SHALL send a ROUTE-REFRESH message with the subtype to indicate 210 demarcation of the beginning of route refresh (start-of-refresh) 211 before sending routes to satisfy the ORF request and send a ROUTE- 212 REFRESH message with the subtype to indicate demarcation of the 213 ending of route refresh (end-of-refresh) after sending all routes to 214 satisfy the request. 216 As part of the start-of-refresh and end-of-refresh messages, it SHALL 217 include the one-time-ORF rules that it is satisfying with this 218 refresh. The presence of the ORF is indicated in the same way as it 219 is with the normal route refresh as in [RFC5291]: A BGP speaker can 220 distinguish an incoming ROUTE-REFRESH message that carries one or 221 more ORF entries from an incoming plain ROUTE-REFRESH message by 222 using the Message Length field in the BGP message header. 224 As with the procedures without the Enhanced Route Refresh Capability, 225 the receiving speaker is permitted to send updates for routes 226 unrelated to the ORF request before it has sent all updates to 227 satisfy the current ORF request. 229 If a receiving speaker receives a new one-time-ORF request before it 230 has finished completing a previous one, it MAY stop sending routes 231 for the previous ORF request. It MUST NOT send an end-of-refresh for 232 the previous request. If the speaker has received the Enhanced Route 233 Refresh Capability, it SHALL send a start-of-refresh for the new 234 request and start sending updates for it. 236 4. Security Considerations 238 This extension to BGP does not change the underlying security issues 239 in [RFC4271]. 241 5. IANA Considerations 243 This document specifies a new Outbound Route Filtering (ORF) type, 244 One-time Extended Community ORF. The value of the ORF-type needs to 245 be assigned by IANA. 247 6. Acknowledgements 249 The authors would like to thank Robert Raszuk, John Scudder, Susan 250 Hares, Haibo Wang, Jiawei Dong, Yaqun Xiao, Mach Chen for their 251 valuable suggestions and comments to this document. 253 7. Normative References 255 [I-D.chen-bgp-ext-community-orf] 256 Chen, E., Lo, A., and K. Patel, "Extended Community Based 257 Outbound Route Filter for BGP-4", 258 draft-chen-bgp-ext-community-orf-02 (work in progress), 259 December 2011. 261 [I-D.ietf-idr-bgp-enhanced-route-refresh] 262 Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced 263 Route Refresh Capability for BGP-4", 264 draft-ietf-idr-bgp-enhanced-route-refresh-01 (work in 265 progress), December 2011. 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, March 1997. 270 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 271 September 2000. 273 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 274 Protocol 4 (BGP-4)", RFC 4271, January 2006. 276 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 277 Communities Attribute", RFC 4360, February 2006. 279 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 280 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 281 May 2008. 283 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 284 Capability for BGP-4", RFC 5291, August 2008. 286 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 287 Attribute", RFC 5701, November 2009. 289 Authors' Addresses 291 Jie Dong 292 Huawei Technologies 293 Huawei Building, No.3 Xinxi Rd 294 Beijing 100085 295 China 297 Email: jie.dong@huawei.com 299 Qing Zeng 300 Huawei Technologies 301 Huawei Building, No.3 Xinxi Rd 302 Beijing 100085 303 China 305 Email: zengqing@huawei.com 306 Jakob Heitz 307 Ericsson Inc. 308 100 Headquarters Drive 309 San Jose, CA 95134 310 USA 312 Email: jakob.heitz@ericsson.com 314 Keyur Patel 315 Cisco Systems 316 170 W. Tasman Drive 317 San Jose, CA 95134 318 USA 320 Email: keyupate@cisco.com 322 Rob Shakir 323 BT 324 London 325 UK 327 Email: rob.shakir@bt.com