idnits 2.17.1 draft-ietf-idr-legacy-rtc-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 : ---------------------------------------------------------------------------- ** There are 15 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC4684]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (October 02, 2013) is 3853 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: 'RFC4271' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 371, but no explicit reference was found in the text Summary: 2 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 P. Mohapatra 3 Internet-Draft Cumulus Networks 4 Intended status: Standards Track A. Sreekantiah 5 Expires: April 05, 2014 K. Patel 6 B. Pithawala 7 Cisco Systems 8 A. Lo 9 Arista Networks 10 October 02, 2013 12 Automatic Route Target Filtering for legacy PEs 13 draft-ietf-idr-legacy-rtc-02.txt 15 Abstract 17 This document describes a simple procedure that allows "legacy" BGP 18 speakers to exchange route target membership information in BGP 19 without using mechanisms specified in [RFC4684]. The intention of 20 the proposed technique is to help in partial deployment scenarios and 21 is not meant to replace [RFC4684]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 05, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 71 2. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Detailed Operation . . . . . . . . . . . . . . . . . . . . . 3 73 3.1. Legacy PE Behavior . . . . . . . . . . . . . . . . . . . 3 74 3.2. RR Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.2.1. Generating Route Target Membership NLRIs for the 76 legacy PE clients . . . . . . . . . . . . . . . . . . 6 77 4. ROUTE_FILTER Community . . . . . . . . . . . . . . . . . . . 7 78 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 79 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 80 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 85 10.2. Informational References . . . . . . . . . . . . . . . . 9 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 88 1. Introduction 90 [RFC4684] provides a powerful and general means for BGP speakers to 91 exchange and propagate Route Target reachability information and 92 constrain VPN route distribution to achieve high scale. However, it 93 requires that all the BGP speakers in the network are upgraded to 94 support this functionality. For example, in a network with route 95 reflectors (RR), if one PE client in the cluster doesn't support 96 constrained distribution, the cluster degenerates into storing and 97 processing all the VPN routes. The route reflectors need to request 98 and store all the network routes since they do not receive route 99 target membership information from the legacy PEs. The RR will also 100 generate all those routes to the legacy PEs and the legacy PEs will 101 end up filtering the routes and store the subset of VPN routes that 102 are of interest. 104 This document specifies a mechanism for such legacy PE devices using 105 existing configuration and toolset to provide similar benefits as 106 [RFC4684]. At the same time, it is backward-compatible with the 107 procedures defined in [RFC4684]. It also allows graceful upgrade of 108 the legacy router to be [RFC4684] capable. 110 1.1. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 2. Basic Idea 118 The basic idea is to make use of VPN unicast route exchange from the 119 legacy PEs to a new BGP speaker (e.g. an RR) to signal RT 120 membership. The legacy PEs announce a set of "special" routes with 121 mapped RTs to the RR along with a standard community (defined in this 122 document). The presence of the community triggers the RR to extract 123 the RTs and build RT membership information. 125 3. Detailed Operation 127 3.1. Legacy PE Behavior 129 The following simple steps are performed on the legacy PE device: 131 o Collect the "import route targets" of all the configured customer 132 VRFs. Let's call this set 'IRTS'. 134 o Create a special "route-filter VRF" with a route distinguisher(RD) 135 that's configured with the same value across the network for all 136 legacy PE devices. Note: the equivalence of the RD value is for 137 optimization - the operator may choose to use different values. 139 o Originate one or more routes in this VRF and attach a subset of 140 'IRTS' as "translated route-target extended communities" with each 141 route so as to evenly distribute the RTs (and to make sure they 142 can fit into one BGP UPDATE message). Collectively, the union of 143 the "translated route-target extended communities" of all these 144 routes is equal to the set 'IRTS'. The translated RTs are 145 attached as export route-targets for the routes originated in the 146 route-filter VRF. 148 o The translation of the IRTs is necessary in order to refrain from 149 importing "route-filter" VRF routes into VPN VRFs that would 150 import the same route-targets. The translation of the IRTS is 151 done as follows. For a given IRT, the equivalent translated RT 152 (TRT) is constructed by means of swapping the value of the high- 153 order octet of the Type field for the IRT (as defined in 154 [RFC4360]). 156 0 1 157 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | 0x00 | 0x02 | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 |2B AS | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 |Local Admin(high) | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 |Local Admin(low) | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 ^ 168 | 169 v 170 0 1 171 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | 0x01 | 0x02 | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 |2B AS => IP(high) | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 |Local Admin(high) => IP(low) | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 |Local Admin(low) => Local Admin| 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 0 1 183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | 0x01 | 0x02 | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 |IP(high) | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 |IP(low) | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 |Local Admin | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 ^ 194 | 195 v 196 0 1 197 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | 0x02 | 0x02 | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 |IP(high) => 4B AS(high) | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 |IP(low) => 4B AS(low) | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 |Local Admin => Local Admin | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 0 1 209 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | 0x02 | 0x02 | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 |4B AS(high) | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 |4B AS(low) | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 |Local Admin | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 ^ 220 | 221 v 222 0 1 223 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | 0x00 | 0x02 | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 |4B AS(high) => 2B AS | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 |4B AS(low) => Local Admin(high)| 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 |Local Admin => Local Admin(low)| 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 As an example, if IRT R= 65500:12244(hex: 0x0002ffdc00002fd4), 235 equivalent route-filter TRT: 255.220.0.0:12244(hex: 237 0x0102ffdc00002fd4). One shortcoming of the translation mechanism 238 is a possible collision between IRTs and TRTs if the network has 239 been configured with RTs of multiple higher order octet types 240 (2-byte AS, IP address, and 4-byte AS). It is expected that such 241 a configuration is rare in practice. 243 o As an alternative to the translation of the IRTS, the subset of 244 the 'IRTS' can be attached as-is (without swapping the type field 245 as described earlier) as "export route-target extended 246 communities" with each route so as to evenly distribute the RTs 247 (and to make sure they can fit into one BGP UPDATE message). In 248 this case, the IRT subsets can be attached in outbound policy to 249 avoid the route-filter VRFs from being imported into VPN VRFs. 250 Also in this case, the route-filter VRF routes must be tagged with 251 a different special community (from that associated with the 252 translated RTs) as described in Section 4 so that the receiving 253 BGP speaker can distinguish the two cases. 255 o The routes are marked with NO_ADVERTISE and NO_EXPORT well-known 256 communities as well as the appropriate new community that's 257 defined in this document Section 4. Note that there is no 258 specific provision made to disallow configuration of subsequent 259 route policies that can potentially alter the set of communities 260 attached to "route-filter" VRF routes. The protocol behavior in 261 such a case is undefined and the use of those policy statements is 262 discouraged. 264 3.2. RR Behavior 266 Upon receiving the "route-filter" routes, the BGP speaker does its 267 usual processing to store them in its local RIB. It recognizes them 268 as route-filter routes based on the association of the new standard 269 community as defined in this document. If required (as indicated by 270 the community value), it translates the attached route-target 271 extended communities (TRT) to equivalent import route-targets (IRT). 272 Finally it creates the route-target filter list for each legacy 273 client by collecting the entire set of route targets. From this 274 point onwards, the behavior is similar to that defined in [RFC4684]. 275 The RR does not propagate the routes further because of their 276 association with NO_ADVERTISE community. Also the VPN EoR that is 277 sent by the legacy PE should also be used as an indication that the 278 legacy PE is done sending the route-filter information as per the 279 procedures defined in [RFC4684] for implementing a EoR mechanism to 280 signal the completion of initial RT membership exchange. 282 3.2.1. Generating Route Target Membership NLRIs for the legacy PE 283 clients 285 The RR MAY also translate the received extended communities from 286 legacy clients into route target membership NLRIs as if it had 287 received those NLRIs from the client itself. This is useful for 288 further propagation of the NLRIs to rest of the network to create RT 289 membership flooding graph. When the route_filter routes are received 290 with same RD (from all legacy PE speakers), processing of the paths 291 to generate equivalent NLRIs becomes fairly easy. 293 4. ROUTE_FILTER Community 295 This memo defines four BGP communities that are attached to BGP 296 UPDATE messages at the legacy PE devices and processed by the route 297 reflectors as defined above. They are as follows: 299 +----------------------------+--------------------------------------+ 300 | Community | Meaning | 301 +----------------------------+--------------------------------------+ 302 | ROUTE_FILTER_v4 | RTs are attached as-is for VPNv4 | 303 | | route filtering | 304 | ... | ... | 305 | ROUTE_FILTER_v6 | RTs are attached as-is for VPNv6 | 306 | | route filtering | 307 | ... | ... | 308 | ROUTE_FILTER_TRANSLATED_v4 | Translated RTs are attached for | 309 | | VPNv4 route filtering | 310 | ... | ... | 311 | ROUTE_FILTER_TRANSLATED_v6 | Translated RTs are attached for | 312 | | VPNv6 route filtering | 313 +----------------------------+--------------------------------------+ 315 In the absence of (or lack of support of) AF specific communities 316 (ROUTE_FILTER_v6, ROUTE_FILTER_TRANSLATED_v6), the ROUTE_FILTER_v4 or 317 ROUTE_FILTER_TRANSLATED_v4 MAY be treated by an implementation as a 318 default VPN route-filter community to build a combination VPN filter 319 for all VPN AFs (VPNv4, VPNv6) present on the RR. This is in 320 accordance with the procedures in [RFC4684] to build combination 321 route-filters for VPN AFs and AF specific route-filters defined in 322 [I-D.keyur-bgp-af-specific-rt-constrain]. If this is the case, then 323 subsequent receipt of any "route-filter" routes with AF specific 324 communities (ROUTE_FILTER_v6, ROUTE_FILTER_TRANSLATED_v6) will 325 override the default filters sent with ROUTE_FILTER_v4 or 326 ROUTE_FILTER_TRANSLATED_v4 for the VPNv6 AFI when support for the AF 327 specific communities exists. 329 5. Deployment Considerations 331 When both the legacy PE and the RR support extended community based 332 Outbound Route Filtering as in [I-D.chen-bgp-ext-community-orf] this 333 may be used as a alternate solution for the legacy PE to signal RT 334 membership information, in order to realize the same benefits as 335 [RFC4684]. Also extended community ORF can be used amongst the RRs 336 in lieu of [RFC4684] to realize similar benefits. 338 6. Contributors 340 Significant contributions were made by Stephane Litkowski, Luis M 341 Tomotaki and James Uttaro which the authors would like to 342 acknowledge. 344 7. Acknowledgments 346 The authors would like to thank Rob Shakir for his review and 347 comments. 349 8. IANA Considerations 351 IANA shall assign new code points from BGP first-come first-serve 352 communities for the four communities as listed in Section 4. 354 9. Security Considerations 356 There are no additional security risks introduced by this design. 358 10. References 360 10.1. Normative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, March 1997. 365 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 366 Protocol 4 (BGP-4)", RFC 4271, January 2006. 368 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 369 Communities Attribute", RFC 4360, February 2006. 371 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 372 Networks (VPNs)", RFC 4364, February 2006. 374 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 375 R., Patel, K., and J. Guichard, "Constrained Route 376 Distribution for Border Gateway Protocol/MultiProtocol 377 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 378 Private Networks (VPNs)", RFC 4684, November 2006. 380 10.2. Informational References 382 [I-D.chen-bgp-ext-community-orf] 383 Chen, E., Lo, A., and K. Patel, "Extended Community Based 384 Outbound Route Filter for BGP-4", draft-chen-bgp-ext- 385 community-orf-02 (work in progress), December 2011. 387 [I-D.keyur-bgp-af-specific-rt-constrain] 388 Patel, K., Raszuk, R., Djernaes, M., Dong, J., and M. 389 Chen, "IPv6 AF Extensions for Route Target Distribution", 390 draft-keyur-bgp-af-specific-rt-constrain-01 (work in 391 progress), March 2011. 393 Authors' Addresses 395 Pradosh Mohapatra 396 Cumulus Networks 398 Email: mpradosh@yahoo.com 400 Arjun Sreekantiah 401 Cisco Systems 402 170 W. Tasman Drive 403 San Jose, CA 95134 404 USA 406 Email: asreekan@cisco.com 408 Keyur Patel 409 Cisco Systems 410 170 W. Tasman Drive 411 San Jose, CA 95134 412 USA 414 Email: keyupate@cisco.com 415 Burjiz Pithawala 416 Cisco Systems 417 170 W. Tasman Drive 418 San Jose, CA 95134 419 USA 421 Email: bpithaw@cisco.com 423 Alton Lo 424 Arista Networks 425 5470 Great America Parkway 426 Santa Clara, CA 95054 427 USA 429 Email: altonlo@aristanetworks.com