idnits 2.17.1 draft-zeng-idr-one-time-prefix-orf-03.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 are used as one-time filters and 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 (October 22, 2012) is 4175 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) == Outdated reference: A later version (-10) exists of draft-ietf-idr-bgp-enhanced-route-refresh-02 == Outdated reference: A later version (-19) exists of draft-ietf-idr-error-handling-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Zeng 3 Internet-Draft 4 Intended status: Standards Track J. Dong 5 Expires: April 25, 2013 Huawei Technologies 6 J. Heitz 7 Ericsson Inc. 8 K. Patel 9 Cisco Systems 10 R. Shakir 11 BT 12 Z. Huang 13 China Telecom 14 October 22, 2012 16 One-time Address-Prefix Based Outbound Route Filter for BGP-4 17 draft-zeng-idr-one-time-prefix-orf-03 19 Abstract 21 This document defines a new Outbound Router Filter (ORF) type for 22 BGP, termed "One-time Address Prefix Outbound Route Filter", which 23 would allow a BGP speaker to send to its BGP peer a route refresh 24 request with a set of address-prefix-based filters to make the peer 25 send only the specific routes matching the filters to the speaker. 26 This ORF-type enables a BGP speaker to re-advertise some specific 27 routes without the need of advertising the whole Adj-RIB-Out of a 28 specific address family, which makes the route recovery and trouble 29 shooting operation more efficient and also reduces the impact on 30 network stability. This filter does not change the outbound route 31 filters or policies on the BGP peer and should only be used for one- 32 time route filtering. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119]. 40 Status of this Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on April 25, 2013. 57 Copyright Notice 59 Copyright (c) 2012 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. One-time Address Prefix ORF-Type . . . . . . . . . . . . . . . 5 76 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 82 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 85 1. Introduction 87 The Outbound Route Filtering Capability defined in [RFC5291] provides 88 a mechanism for a BGP speaker to send to its BGP peer a set of 89 Outbound Route Filters (ORFs) that can be used by its peer to filter 90 its outbound routing updates to the speaker. 92 In some scenarios, BGP speaker only needs to retrieve some specific 93 routes from its peer if the routes are possibly lost or contain some 94 problematic attributes for some reason, but sending ROUTE-REFRESH 95 message [RFC2918] will lead to the peer re-advertising its whole Adj- 96 RIB-Out. Such large numbers of updates include a lot of unnecessary 97 route updates which may make trouble shooting operation (such as 98 packets tracking) more difficult, and is a waste of the processing 99 resources and network bandwidth. With the increase of IPv6 100 deployment, this problem could be more significant. Even configured 101 with ORF mechanism as defined in [RFC5291], on receipt of a ROUTE- 102 REFRESH message, the peer will re-advertise all the routes matching 103 the current outbound route filters, i.e., the whole Adj-Rib-Out for 104 this BGP speaker. Since in this case the BGP speaker does not want 105 to change the outbound route filters on its peer, this problem cannot 106 be solved by existing ORF mechanism. 108 This document defines a new Outbound Router Filter (ORF) type for 109 BGP, termed "One-time Address Prefix Outbound Route Filter", which 110 would allow a BGP speaker to send to its BGP peer a route refresh 111 request with a set of address-prefix-based filters to make the peer 112 send only the specific routes matching these filters to the speaker. 113 This new ORF-type enables a BGP speaker to re-advertise some specific 114 routes without the need of advertising the whole Adj-RIB-Out of a 115 particular address family, which makes the route recovery and trouble 116 shooting operation (such as packet tracking) more efficient and also 117 reduces the impact on network stability. This filter does not change 118 the outbound route filters or policies on the BGP peer and should 119 only be used for one-time route filtering. 121 Consider the following scenario: In an Inter-AS environment, ASBR-A 122 received a malformed UPDATE from ASBR-B and treated it as withdraw 123 according to [I-D.ietf-idr-error-handling]. While such event would 124 be locally logged and the operators may be notified, it is important 125 for ASBR-A to try to recover these routes as soon as possible since 126 the routes which are treated as withdraw may impact some critical 127 services. A good method is to ask the peering ASBR-B to re-advertise 128 such routes with some back off mechanism. One-time Prefix ORF is a 129 low impact way to achieve this. 131 2. One-time Address Prefix ORF-Type 133 This document defines a new ORF type: One-time Address Prefix ORF. 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 format of One-time Address Prefix ORF-Type entry is the same as 145 the encoding of Address Prefix ORF in [RFC5292], with the specific 146 fields defined as follows: 148 Since the semantics of this new ORF-Type is always "one-time 149 filtering" and has no impact on the existing ORFs, the Action field 150 MUST be ignored. 152 The matching rules of the One-time Address Prefix ORF are the same as 153 defined in Address-Prefix-Based ORF [RFC5292]. 155 The ORF entries of this type are used as one-time filters and MUST 156 not change any previously installed ORF entry on the receiving 157 speaker. 159 3. Operation 161 The capability negotiation of 162 MUST NOT delay the advertisement of routes with this AFI/SAFI. 164 The received One-time Address Prefix ORF entries SHOULD only be used 165 for one-time route filtering and MUST NOT be saved locally. The 166 received One-time Address Prefix ORF entries MUST NOT modify the 167 outbound route filters on the receiving speaker (either locally 168 configured or received from the sending speaker through ORF). 170 On receipt of ROUTE-REFRESH message with One-time Address Prefix ORF 171 entries, the receiving speaker SHOULD re-advertise to the sending 172 speaker the routes from the Adj-RIB-Out associated with the sending 173 speaker which pass the entries carried in the One-time Address Prefix 174 ORF as well as the locally saved ORFs (if any) received from the 175 sending speaker. 177 Since different processing orders may lead to different results, the 178 One-time ORFs and the regular ORFs SHOULD not be encoded in one 179 ROUTE-REFRESH message. 181 During the period when the receiving speaker is sending updates to 182 satisfy the One-time ORF request, it may experience other routing 183 activity that will require it to send updates unrelated to the One- 184 time ORF request. It is permitted to send these updates before it 185 has completed sending the One-time ORF related updates. 187 Similarly, if a route that passes the One-time ORF has already been 188 sent and the receiving speaker experiences routing activity that 189 changes this route and the receiving speaker has not yet sent all 190 routes to satisfy the One-time ORF request, it is permitted to send 191 the changed route immediately. 193 Details about how to interoperate when both One-time ORF Capability 194 and the Enhanced Route Refresh Capability as described in 195 [I-D.ietf-idr-bgp-enhanced-route-refresh] are enabled will be 196 discussed in a future version. 198 4. IANA Considerations 200 This document specifies a new Outbound Route Filtering (ORF) type, 201 One-time Address-Prefix ORF. The value of the ORF-type needs to be 202 assigned by the IANA. 204 5. Security Considerations 206 This extension to BGP does not change the underlying security issues 207 in [RFC4271]. 209 6. Acknowledgements 211 The authors would like to thank Enke Chen, Susan Hares, Haibo Wang, 212 Jiawei Dong, Yaqun Xiao and Mach Chen for their valuable suggestions 213 and comments to this document. 215 7. References 217 7.1. Normative References 219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, March 1997. 222 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 223 September 2000. 225 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 226 Protocol 4 (BGP-4)", RFC 4271, January 2006. 228 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 229 Capability for BGP-4", RFC 5291, August 2008. 231 [RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound 232 Route Filter for BGP-4", RFC 5292, August 2008. 234 7.2. Informative References 236 [I-D.ietf-idr-bgp-enhanced-route-refresh] 237 Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced 238 Route Refresh Capability for BGP-4", 239 draft-ietf-idr-bgp-enhanced-route-refresh-02 (work in 240 progress), June 2012. 242 [I-D.ietf-idr-error-handling] 243 Scudder, J., Chen, E., Mohapatra, P., and K. Patel, 244 "Revised Error Handling for BGP UPDATE Messages", 245 draft-ietf-idr-error-handling-02 (work in progress), 246 June 2012. 248 Authors' Addresses 250 Qing Zeng 251 Beijing 252 China 254 Email: zengqqqq@gmail.com 256 Jie Dong 257 Huawei Technologies 258 Huawei Building, No.156 Beiqing Rd 259 Beijing 100095 260 China 262 Email: jie.dong@huawei.com 263 Jakob Heitz 264 Ericsson Inc. 265 100 Headquarters Drive 266 San Jose, CA 95134 267 USA 269 Email: jakob.heitz@ericsson.com 271 Keyur Patel 272 Cisco Systems 273 170 W. Tasman Drive 274 San Jose, CA 95134 275 USA 277 Email: keyupate@cisco.com 279 Rob Shakir 280 BT 281 London 282 UK 284 Email: rob.shakir@bt.com 286 ZhiLan Huang 287 China Telecom 288 109 West Zhongshan Ave 289 Guangzhou 510630 290 China 292 Email: huangzl@gsta.com