idnits 2.17.00 (12 Aug 2021) /tmp/idnits63945/draft-ietf-l3vpn-acceptown-community-10.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 -- 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 (June 24, 2015) is 2516 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Uttaro 3 Internet-Draft ATT 4 Intended status: Standards Track P. Mohapatra 5 Expires: December 26, 2015 Sproute Networks 6 D. Smith 7 Cisco Systems 8 R. Raszuk 9 Mirantis Inc. 10 J. Scudder 11 Juniper Networks 12 June 24, 2015 14 BGP ACCEPT_OWN Community Attribute 15 draft-ietf-l3vpn-acceptown-community-10.txt 17 Abstract 19 Under certain conditions it is desirable for a Border Gateway 20 Protocol (BGP) route reflector to be able to modify the Route Target 21 (RT) list of a Virtual Private Network (VPN) route that the route 22 reflector distributes, enabling the route reflector to control how a 23 route originated within one Virtual Routing and Forwarding (VRF) is 24 imported into other VRFs. This technique works effectively as long 25 as the VRF that exports the route is not on the same Provider Edge 26 (PE) router than the VRF(s) that import the route. However, due to 27 the constraints of the BGP protocol, it does not work if the two are 28 on the same PE. This document describes a modification to the BGP 29 protocol allowing this technique to work when the VRFs are on the 30 same PE, and to be used in a standard manner throughout an autonomous 31 system. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 26, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 69 2. ACCEPT_OWN Community . . . . . . . . . . . . . . . . . . . . 3 70 2.1. Route Acceptance . . . . . . . . . . . . . . . . . . . . 3 71 2.2. Propagating ACCEPT_OWN Between Address Families . . . . . 4 72 2.3. Configuration Control . . . . . . . . . . . . . . . . . . 4 73 3. Decision Process . . . . . . . . . . . . . . . . . . . . . . 4 74 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 75 5. Other Applications . . . . . . . . . . . . . . . . . . . . . 5 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 79 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 80 Appendix A. Local Extranet Application (non-normative) . . . . . 6 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 83 1. Introduction 85 In certain scenarios, a BGP speaker may maintain multiple VRFs 86 [RFC4364]. Under certain conditions, it is desirable for a route 87 reflector to be able to modify the RT list of a VPN route that the 88 route reflector distributes, enabling the route reflector to control 89 how a route originated within one VRF is imported into other VRFs. 90 Though it is possible to perform such policy control directly on the 91 originator, it may be operationally cumbersome in an autonomous 92 system with a large number of border routers having complex BGP 93 policies. 95 The technique of the route reflector modifying the RT list works 96 effectively as long as the VRF that exports the route is not on the 97 same PE as the VRF(s) that import the route. However, due to the 98 constraints of the BGP protocol, it does not work if the two are on 99 the same PE. This is because per the BGP specification [RFC4271], a 100 BGP speaker rejects prefix advertisements received that were 101 originated by itself. In an autonomous system with route reflectors, 102 the route reflector attaches the ORIGINATOR_ID attribute to the 103 UPDATE messages so that if such prefix advertisements reach the 104 originator, the originator can reject them by simply checking the 105 ORIGINATOR_ID attribute. The BGP specification also mandates that a 106 route should not be accepted from a peer when the NEXT_HOP attribute 107 matches the receiver's own "IP address". 109 This document proposes a modification to BGP's behavior by defining a 110 new community [RFC1997] value, in order to allow the technique of RT 111 list modification by the route reflector to be used in a standard 112 manner throughout an autonomous system, irrespective of whether the 113 VRFs are on the same, or different PEs. 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 2. ACCEPT_OWN Community 123 This memo defines a new well-known BGP community from the First Come 124 First Served range, ACCEPT_OWN, whose value as assigned by IANA is 125 0xFFFF0001. Processing of the ACCEPT_OWN community SHOULD be 126 controlled by configuration. The functionality SHOULD default to 127 being disabled, as further specified in Section 2.3. 129 2.1. Route Acceptance 131 A router MAY accept a route whose ORIGINATOR_ID or NEXT_HOP value 132 matches that of the receiving speaker if all of the following are 133 true: 135 o Processing of the ACCEPT_OWN community is enabled by 136 configuration. 138 o The route in question carries the ACCEPT_OWN community. 140 o The route in question was originated from a source VRF on the 141 router. The source VRF is a VRF on the router whose configured 142 Route Distinguisher is equal to the Route Distinguisher carried in 143 the route. 145 o The route in question is targeted to one or more destination VRFs 146 on the router (as determined by inspecting the Route Target(s)). 148 o At least one destination VRF is different from the source VRF. 150 A route MUST NOT ever be accepted back into its source VRF, even if 151 it carries one or more RTs which match that VRF. 153 2.2. Propagating ACCEPT_OWN Between Address Families 155 The ACCEPT_OWN community controls propagation of routes which can be 156 associated with a source VRF by inspection of their Route 157 Distinguisher and with a target VRF by inspection of their Route 158 Target list (for example VPN routes with a SAFI of 128). As such, it 159 SHOULD NOT be attached to any routes which cannot be associated with 160 a source VRF. This implies that when propagating routes into a VRF, 161 the ACCEPT_OWN community SHOULD NOT be propagated. Likewise, if a 162 route carrying the ACCEPT_OWN community is received in an address 163 family which does not allow the source VRF to be looked up, the 164 ACCEPT_OWN community MUST be discarded. An OPTIONAL message may be 165 logged in this case. 167 2.3. Configuration Control 169 ACCEPT_OWN handling SHOULD be controlled by configuration, and if 170 controlled by configuration, it MUST default to being disabled. When 171 ACCEPT_OWN is disabled by configuration (either explicitly or by 172 default), the router MUST NOT apply the special route acceptance 173 rules detailed in Section 2.1. The router SHOULD still apply the 174 propagation rules detailed in Section 2.2. 176 3. Decision Process 178 If a BGP speaker supports ACCEPT_OWN and is configured for the 179 extensions defined in this document, the following step is inserted 180 after the LOCAL_PREF comparison step in BGP decision process: 182 When comparing a pair of routes for a BGP destination, the route 183 attached with ACCEPT_OWN community is preferred over the route 184 that does not have the community. 186 In all other respects, the decision process remains unchanged. This 187 extra step MUST only be invoked during the best path selection 188 process of VPN-IP routes [RFC4364] (i.e., it MUST NOT be invoked for 189 the best path selection of "imported" IP routes in a VRF). The 190 purpose of the extra step is to allow the paths advertised by the 191 route reflector with ACCEPT_OWN community to be selected as best over 192 other paths that the BGP speaker may have received, hence enabling 193 the applications ACCEPT_OWN is designed for. 195 4. Deployment Considerations 197 The ACCEPT_OWN community as described in this document is useful 198 within a single autonomous system which uses a single layer of route 199 reflectors. Its use with hierarchical route reflectors would require 200 further specification and is out of scope for this document. 201 Likewise, its use across multiple autonomous systems is out of scope 202 for this document. 204 5. Other Applications 206 This approach may also be relevant to other scenarios where a BGP 207 speaker maintains multiple routing contexts using an approach 208 different from that of [RFC4364], as long as the specific approach in 209 use has the property that the BGP speaker originates and receives 210 routes within a particular context. In such a case, "VRF" in this 211 document should be understood to mean whatever construct provides a 212 routing context in the specific technology under consideration. 213 Likewise, "Route Distinguisher" should be understood to mean whatever 214 construct allows a route's originator to associate that route with 215 its source context, and "Route Target" should be understood to mean 216 whatever construct allows a route to be targeted for import into a 217 context other than its source. 219 6. Security Considerations 221 ACCEPT_OWN as described above permits a router's own route prefix to 222 be advertised to a different VRF on that router. In this respect, 223 such a route is similar to any other BGP route and shares the same 224 set of security vulnerabilities and concerns. This extension does 225 not change the underlying security issues inherent in BGP VPN 226 [RFC4364]. 228 7. IANA Considerations 230 IANA has assigned the value 0xFFFF0001 from BGP well-known 231 communities registry for ACCEPT_OWN community. No additional IANA 232 action is required. 234 8. Acknowledgments 236 The authors would like to thank Yakov Rekhter, Jim Guichard, Clarence 237 Filsfils, John Mullooly, Jeff Haas, Pranav Mehta, and Tamas Mondal 238 for their valuable comments and suggestions. The decision process 239 changes were suggested by Pranav Mehta to solve the remote extranet 240 problem. 242 9. Normative References 244 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 245 Communities Attribute", RFC 1997, August 1996. 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels", BCP 14, RFC 2119, March 1997. 250 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 251 Protocol 4 (BGP-4)", RFC 4271, January 2006. 253 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 254 Networks (VPNs)", RFC 4364, February 2006. 256 Appendix A. Local Extranet Application (non-normative) 258 One of the applications for this behavior is auto-configuration of 259 extranets within MPLS VPN networks. Consider the following topology: 261 CE1 --------+ 262 | 263 (VRF 1, RD 1, RT 1) 264 PE1 ................... RR 265 (VRF 2, RD 2, RT 2) 266 | 267 CE2 --------+ 269 Figure 1: Extranet Application 271 Within the above topology, PE1 receives a prefix X from CE1. Prefix 272 X is installed in VRF 1 and is advertised to the route reflector with 273 route distinguisher (RD) 1 and route target (RT) 1 as configured on 274 PE1. The requirement is to import prefix X into VRF 2 and advertise 275 it to CE2 in support of extranet VPN connectivity between CE1/VRF1 276 and CE2/VRF2. Current BGP mechanisms for MPLS VPNs[RFC4364] require 277 changing the import RT value and/or import policy for VRF 2 on PE1. 278 This is operationally cumbersome in a network with a large number of 279 border routers having complex BGP policies. 281 Alternatively, using the new ACCEPT_OWN community value, the route 282 reflector can simply re-advertise prefix X back to PE1 with RT 2 283 appended. In this way, PE1 will accept prefix X despite its 284 ORIGINATOR_ID or NEXT_HOP value, import it into VRF 2 as a result of 285 RT 2, and will then determine the correct adjacency rewrite within 286 VRF 1 based on the RD value (1) and the prefix. Note that the RT 1 287 value originally attached to the route will simply be ignored since 288 associated with the source VRF 1. The same operation needs also to 289 happen in the reverse direction (VRF 1 learning a route from VRF 2) 290 to achieve establishment of an extranet VPN strictly via the route 291 reflector without changing the BGP policy of PE1 in any way. 293 A router performing such an extranet application can accept a route 294 with its own ORIGINATOR_ID or NEXT_HOP value only if the VRF in which 295 the router originated the route is different than the VRF in which 296 the router accepts the re-advertised route. 298 Authors' Addresses 300 James Uttaro 301 ATT 302 200 S. Laurel Avenue 303 Middletown, NJ 07748 304 USA 306 Email: uttaro@att.com 308 Pradosh Mohapatra 309 Sproute Networks 311 Email: mpradosh@yahoo.com 313 David J. Smith 314 Cisco Systems 315 111 Wood Avenue South 316 Iselin, NJ 08830 317 USA 319 Email: djsmith@cisco.com 321 Robert Raszuk 322 Mirantis Inc. 323 615 National Ave. #100 324 Mt View, CA 94043 325 USA 327 Email: robert@raszuk.net 328 John Scudder 329 Juniper Networks 330 1194 N. Mathilda Ave 331 Sunnyvale, CA 94089 332 USA 334 Email: jgs@juniper.net