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