idnits 2.17.1 draft-pmohapat-l3vpn-acceptown-community-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 331. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 8, 2008) is 5802 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group James Uttaro 3 Internet Draft AT&T 4 Expiration Date: December 2008 5 Pradosh Mohapatra 6 David J. Smith 7 Cisco Systems, Inc. 9 Robert Raszuk 10 John Scudder 11 Juniper Networks, Inc. 13 June 8, 2008 15 BGP ACCEPT_OWN Well-known Community Attribute 17 draft-pmohapat-l3vpn-acceptown-community-00.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 Under certain conditions it is desirable for a BGP route reflector to 45 be able to modify the Route Target list of a VPN route that is 46 distributed by the route reflector, enabling the route reflector to 47 control how a route originated within one VRF is imported into other 48 VRFs. This technique works effectively as long as the VRF that 49 exports the route is not on the same PE as the VRF(s) that import the 50 route. However, due to the constraints of the BGP protocol, it does 51 not work if the two are on the same PE. 53 This document describes a modification to the BGP protocol allowing 54 this technique to work when the VRFs are on the same PE, allowing the 55 technique to be used in a standard manner throughout an autonomous 56 system. 58 Table of Contents 60 1 Specification of Requirements ...................... 2 61 2 Introduction ....................................... 3 62 3 ACCEPT_OWN Community ............................... 3 63 3.1 Route Acceptance ................................... 4 64 3.2 Propagating ACCEPT_OWN Between Address Families .... 4 65 3.3 Configuration Control .............................. 4 66 4 Deployment Considerations .......................... 5 67 5 Other Applications ................................. 5 68 6 Security Considerations ............................ 5 69 7 IANA Considerations ................................ 5 70 8 Appendix A - Extranet application (non-normative) .. 6 71 9 Acknowledgements ................................... 7 72 10 Normative References ............................... 7 73 11 Authors' Addresses ................................. 7 74 12 Full Copyright Statement ........................... 8 75 13 Intellectual Property .............................. 8 77 1. Specification of Requirements 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 2. Introduction 85 In certain scenarios, a BGP speaker may maintain multiple "VPN 86 Routing and Forwarding tables", or VRFs [RFC4364]. Under certain 87 conditions it is desirable for a route reflector to be able to modify 88 the Route Target (RT) list of a VPN route that is distributed by the 89 route reflector, enabling the route reflector to control how a route 90 originated within one VRF is imported into other VRFs. Though it is 91 possible to perform such policy control directly on the originator, 92 it may be operationally cumbersome in an autonomous system with a 93 large number of border routers having complex BGP 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 well-known community [RFC1997] value, in order to allow the 111 technique of RT list modification by the route reflector to be used 112 in a standard manner throughout an autonomous system, irrespective of 113 whether the VRFs are on the same, or different PEs. 115 3. ACCEPT_OWN Community 117 This memo defines a new well-known BGP community, ACCEPT_OWN, with 118 value 0xFFFFFF05. Processing of the ACCEPT_OWN community SHOULD be 119 controlled by configuration. The functionality SHOULD default to 120 being disabled, as further specified in Section 3.3. 122 3.1. Route Acceptance 124 A router MAY accept a route whose ORIGINATOR_ID or NEXT_HOP value 125 matches that of the receiving speaker if all of the following are 126 true: 128 + Processing of the ACCEPT_OWN community is enabled by 129 configuration. 130 + The route in question carries the ACCEPT_OWN community. 131 + The route in question was originated from a source VRF on the 132 router (as determined by inspecting the Route Distinguisher). 133 + The route in question is targeted to one or more destination VRFs 134 on the router (as determined by inspecting the Route Target(s)). 135 + At least one destination VRF is different from the source VRF. 137 A route MUST never be accepted back into its source VRF, even if it 138 carries one or more Route Targets (RTs) which match that VRF. 140 3.2. Propagating ACCEPT_OWN Between Address Families 142 The ACCEPT_OWN community controls propagation of routes which can be 143 associated with a source VRF by inspection of their Route 144 Distinguisher and with a target VRF by inspection of their Route 145 Target list (for example VPN routes with a SAFI of 128). As such, it 146 SHOULD NOT be attached to any routes which cannot be associated with 147 a source VRF. This implies that when propagating routes into a VRF, 148 the ACCEPT_OWN community should not be propagated. Likewise, if a 149 route carrying the ACCEPT_OWN community is received in an address 150 family which does not allow the source VRF to be looked up, the 151 ACCEPT_OWN community MUST be discarded. An OPTIONAL message may be 152 logged in this case. 154 3.3. Configuration Control 156 ACCEPT_OWN handling SHOULD be controlled by configuration, and SHOULD 157 default to being disabled. When ACCEPT_OWN is disabled by 158 configuration (either explicitly or by default), the router MUST NOT 159 apply the special route acceptance rules detailed in Section 3.1. 160 The router SHOULD still apply the propagation rules detailed in 161 Section 3.2. 163 4. Deployment Considerations 165 The ACCEPT_OWN community as described in this document is useful 166 within a single autonomous system which uses a single layer of route 167 reflectors. Its use with hierarchical route reflectors would require 168 further specification and is out of scope for this document. 169 Likewise, its use across multiple autonomous systems is out of scope 170 for this document. 172 5. Other Applications 174 This approach may also be relevant to other scenarios where a BGP 175 speaker maintains multiple routing contexts using an approach 176 different from that of [RFC4364], as long as the specific approach in 177 use has the property that the BGP speaker originates and receives 178 routes within a particular context. In such a case, "VRF" in this 179 document should be understood to mean whatever construct provides a 180 routing context in the specific technology under consideration. 181 Likewise, "Route Distinguisher" should be understood to mean whatever 182 construct allows a route's originator to associate that route with 183 its source context, and "Route Target" should be understood to mean 184 whatever construct allows a route to be targeted for import into a 185 context other than its source. 187 6. Security Considerations 189 ACCEPT_OWN as described above permits a router's own route prefix to 190 be advertised to a different VRF on that router. In this respect, 191 such a route is similar to any other BGP route and shares the same 192 set of security vulnerabilities and concerns. No new fundamental 193 security issues are introduced by ACCEPT_OWN. 195 7. IANA Considerations 197 This document defines a new well-known community, called ACCEPT_OWN. 198 It is to be assigned value 0xFFFFFF05. 200 8. Appendix A - Extranet application (non-normative) 202 One of the applications for this behavior is auto-configuration of 203 extranets within MPLS VPN networks. Consider the following topology: 205 CE1 --------+ 206 | 207 (VRF 1, RD 1, RT 1) 208 PE1 ................... RR 209 (VRF 2, RD 2, RT 2) 210 | 211 CE2 --------+ 213 Within the above topology, PE1 receives a prefix X from CE1. Prefix X 214 is installed in VRF 1 and is advertised to the route reflector with 215 route distinguisher (RD) 1 and route target (RT) 1 as configured on 216 PE1. The requirement is to import prefix X into VRF 2 and advertise 217 it to CE2 in support of extranet VPN connectivity between CE1/VRF1 218 and CE2/VRF2. Current BGP mechanisms for MPLS VPNs [RFC4364] require 219 changing the import RT value and/or import policy for VRF 2 on PE1. 220 This is operationally cumbersome in a network with a large number of 221 border routers having complex BGP policies. 223 Alternatively, using the new ACCEPT_OWN community value, the route 224 reflector can simply re-advertise prefix X back to PE1 with RT 2 225 appended. In this way, PE1 will accept prefix X despite its 226 ORIGINATOR_ID or NEXT_HOP value, import it into VRF 2 as a result of 227 RT 2, and will then determine the correct adjacency rewrite within 228 VRF 1 based on the RD value (1) and the prefix. Note that the RT 1 229 value originally attached to the route will simply be ignored since 230 associated with the source VRF 1. The same operation needs also to 231 happen in the reverse direction (VRF 1 learning a route from VRF 2) 232 to achieve establishment of an extranet VPN strictly via the route 233 reflector without changing the BGP policy of PE1 in any way. 235 A router performing such an extranet application can accept a route 236 with its own ORIGINATOR_ID or NEXT_HOP value only if the VRF in which 237 the router originated the route is different than the VRF in which 238 the router accepts the re-advertised route. 240 9. Acknowledgements 242 The authors would like to thank Yakov Rekhter, Jim Guichard, Clarence 243 Filsfils, John Mullooly, and Jeff Haas for their valuable comments 244 and suggestions. 246 10. Normative References 248 [RFC4271] Rekhter, Y., Li T., and Hares S.(editors), "A Border 249 Gateway Protocol 4 (BGP-4)," RFC 4271, January 2006. 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels," March 1997. 254 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 255 Attribute", RFC 1997, August 1996. 257 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 258 Networks (VPNs)", RFC 4364, February 2006. 260 11. Authors' Addresses 262 James Uttaro 263 AT&T 264 200 S. Laurel Avenue 265 Middletown, NJ 07748 266 Email: uttaro@att.com 268 Pradosh Mohapatra 269 Cisco Systems, Inc. 270 170 Tasman Drive 271 San Jose, CA 95134 272 Email: pmohapat@cisco.com 274 David J. Smith 275 Cisco Systems, Inc. 276 111 Wood Avenue South 277 Iselin, NJ 08830 278 E-mail: dasmith@cisco.com 279 Robert Raszuk 280 Juniper Networks 281 1194 North Mathilda Avenue 282 Sunnyvale, California 94089 283 USA 284 Email: raszuk@juniper.net 286 John Scudder 287 Juniper Networks 288 1194 North Mathilda Avenue 289 Sunnyvale, California 94089 290 USA 291 Email: jgs@juniper.net 293 12. Full Copyright Statement 295 Copyright (C) The IETF Trust (2008). 297 This document is subject to the rights, licenses and restrictions 298 contained in BCP 78, and except as set forth therein, the authors 299 retain all their rights. 301 This document and the information contained herein are provided on an 302 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 303 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 304 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 305 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 306 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 307 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 309 13. Intellectual Property 311 The IETF takes no position regarding the validity or scope of any 312 Intellectual Property Rights or other rights that might be claimed to 313 pertain to the implementation or use of the technology described in 314 this document or the extent to which any license under such rights 315 might or might not be available; nor does it represent that it has 316 made any independent effort to identify any such rights. Information 317 on the procedures with respect to rights in RFC documents can be 318 found in BCP 78 and BCP 79. 320 Copies of IPR disclosures made to the IETF Secretariat and any 321 assurances of licenses to be made available, or the result of an 322 attempt made to obtain a general license or permission for the use of 323 such proprietary rights by implementers or users of this 324 specification can be obtained from the IETF on-line IPR repository at 325 http://www.ietf.org/ipr. 327 The IETF invites any interested party to bring to its attention any 328 copyrights, patents or patent applications, or other proprietary 329 rights that may cover technology that may be required to implement 330 this standard. Please address the information to the IETF at ietf- 331 ipr@ietf.org.