diff options
Diffstat (limited to 'doc/rfc/rfc7611.txt')
| -rw-r--r-- | doc/rfc/rfc7611.txt | 451 |
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc7611.txt b/doc/rfc/rfc7611.txt new file mode 100644 index 0000000..32c0c10 --- /dev/null +++ b/doc/rfc/rfc7611.txt @@ -0,0 +1,451 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Uttaro +Request for Comments: 7611 AT&T +Category: Standards Track P. Mohapatra +ISSN: 2070-1721 Sproute Networks + D. Smith + Cisco Systems + R. Raszuk + Mirantis Inc. + J. Scudder + Juniper Networks + August 2015 + + + BGP ACCEPT_OWN Community Attribute + +Abstract + + Under certain conditions, it is desirable for a Border Gateway + Protocol (BGP) route reflector to be able to modify the Route Target + (RT) list of a Virtual Private Network (VPN) route that the route + reflector distributes, enabling the route reflector to control how a + route originated within one VPN Routing and Forwarding table (VRF) is + imported into other VRFs. This technique works effectively as long + as the VRF that exports the route is not on the same Provider Edge + (PE) router as the VRF(s) that imports the route. However, due to + the constraints of BGP, it does not work if the two are on the same + PE. This document describes a modification to BGP allowing this + technique to work when the VRFs are on the same PE and to be used in + a standard manner throughout an autonomous system. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7611. + + + + + + + + +Uttaro, et al. Standards Track [Page 1] + +RFC 7611 ACCEPT_OWN August 2015 + + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 2. ACCEPT_OWN Community . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Route Acceptance . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Propagating ACCEPT_OWN between Address Families . . . . . 4 + 2.3. Configuration Control . . . . . . . . . . . . . . . . . . 4 + 3. Decision Process . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 + 5. Other Applications . . . . . . . . . . . . . . . . . . . . . 5 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 + 8.2. Informative References . . . . . . . . . . . . . . . . . 6 + Appendix A. Local Extranet Application (Non-normative) . . . . . 7 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 + +1. Introduction + + In certain scenarios, a BGP speaker may maintain multiple VRFs + [RFC4364]. Under certain conditions, it is desirable for a route + reflector to be able to modify the RT list of a VPN route that the + route reflector distributes, enabling the route reflector to control + how a route originated within one VRF is imported into other VRFs. + Though it is possible to perform such control directly on the + originator, it may be operationally cumbersome in an autonomous + system with a large number of border routers having complex BGP + policies. + + + + + +Uttaro, et al. Standards Track [Page 2] + +RFC 7611 ACCEPT_OWN August 2015 + + + The technique of the route reflector modifying the RT list works + effectively as long as the VRF that exports the route is not on the + same PE as the VRF(s) that imports the route. However, due to + constraints of BGP, it does not work if the two are on the same PE. + This is because, per the BGP specification [RFC4271], a BGP speaker + rejects received prefix advertisements that were originated by + itself. In an autonomous system with route reflectors, the route + reflector attaches the ORIGINATOR_ID attribute to the UPDATE messages + so that if such prefix advertisements reach the originator, the + originator can reject them by simply checking the ORIGINATOR_ID + attribute. The BGP specification also mandates that a route should + not be accepted from a peer when the NEXT_HOP attribute matches the + receiver's own IP address. + + This document proposes a modification to BGP's behavior by defining a + new community [RFC1997] value, in order to allow the technique of RT + list modification by the route reflector to be used in a standard + manner throughout an autonomous system, irrespective of whether or + not the VRFs are on the same or different PEs. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. ACCEPT_OWN Community + + This memo defines ACCEPT_OWN, a new well-known BGP community in the + First Come First Served [RFC5226] range, whose value as assigned by + IANA is 0xFFFF0001. Processing of the ACCEPT_OWN community SHOULD be + controlled by configuration. The functionality SHOULD default to + being disabled, as further specified in Section 2.3. + +2.1. Route Acceptance + + A router MAY accept a route whose ORIGINATOR_ID or NEXT_HOP value + matches that of the receiving speaker if all of the following are + true: + + o Processing of the ACCEPT_OWN community is enabled by + configuration. + + o The route in question carries the ACCEPT_OWN community. + + + + + + + +Uttaro, et al. Standards Track [Page 3] + +RFC 7611 ACCEPT_OWN August 2015 + + + o The route in question originated from a source VRF on the router. + The source VRF is a VRF on the router whose configured Route + Distinguisher is equal to the Route Distinguisher carried in the + route. + + o The route in question is targeted to one or more destination VRFs + on the router (as determined by inspecting the Route Target(s)). + + o At least one destination VRF is different from the source VRF. + + A route MUST NOT ever be accepted back into its source VRF, even if + it carries one or more RTs that match that VRF. + +2.2. Propagating ACCEPT_OWN between Address Families + + The ACCEPT_OWN community controls propagation of routes that can be + associated with a source VRF by inspection of their Route + Distinguisher and with a target VRF by inspection of their Route + Target list (for example, VPN routes with a Subsequent Address Family + Identifier (SAFI) of 128). As such, it SHOULD NOT be attached to any + routes that cannot be associated with a source VRF. This implies + that when propagating routes into a VRF, the ACCEPT_OWN community + SHOULD NOT be propagated. Likewise, if a route carrying the + ACCEPT_OWN community is received in an address family that does not + allow the source VRF to be looked up, the ACCEPT_OWN community MUST + be discarded. An OPTIONAL message may be logged in this case. + +2.3. Configuration Control + + ACCEPT_OWN handling SHOULD be controlled by configuration, and if + controlled by configuration, it MUST default to being disabled. When + ACCEPT_OWN is disabled by configuration (either explicitly or by + default), the router MUST NOT apply the special route acceptance + rules detailed in Section 2.1. The router SHOULD still apply the + propagation rules detailed in Section 2.2. + +3. Decision Process + + If a BGP speaker supports ACCEPT_OWN and is configured for the + extensions defined in this document, the following step is inserted + after the LOCAL_PREF comparison step in the BGP decision process: + + When comparing a pair of routes for a BGP destination, the route + with the ACCEPT_OWN community attached is preferred over the route + that does not have the community. + + + + + + +Uttaro, et al. Standards Track [Page 4] + +RFC 7611 ACCEPT_OWN August 2015 + + + In all other respects, the decision process remains unchanged. This + extra step MUST only be invoked during the best path selection + process of VPN-IP routes [RFC4364] (i.e., it MUST NOT be invoked for + the best path selection of imported IP routes in a VRF). The purpose + of this extra step is to allow the paths advertised by the route + reflector with ACCEPT_OWN community to be selected as best over other + paths that the BGP speaker may have received, hence enabling the + applications ACCEPT_OWN is designed for. + +4. Deployment Considerations + + The ACCEPT_OWN community as described in this document is useful + within a single autonomous system that uses a single layer of route + reflectors. Its use with hierarchical route reflectors would require + further specification and is out of the scope of this document. + Likewise, its use across multiple autonomous systems is out of the + scope of this document. + +5. Other Applications + + This approach may also be relevant in other scenarios where a BGP + speaker maintains multiple routing contexts using an approach + different from that of [RFC4364], as long as the specific approach in + use has the property that the BGP speaker originates and receives + routes within a particular context. In such a case, "VRF" in this + document should be understood to mean whatever construct provides a + routing context in the specific technology under consideration. + Likewise, "Route Distinguisher" should be understood to mean whatever + construct allows a route's originator to associate that route with + its source context, and "Route Target" should be understood to mean + whatever construct allows a route to be targeted for import into a + context other than its source. + +6. Security Considerations + + ACCEPT_OWN as described in this document permits a router's own route + prefix to be advertised to a different VRF on that router. In this + respect, such a route is similar to any other BGP route and shares + the same set of security vulnerabilities and concerns. This + extension does not change the underlying security issues inherent in + BGP VPN [RFC4364]. + +7. IANA Considerations + + IANA has assigned the value 0xFFFF0001 in the "BGP Well-known + Communities" registry for the ACCEPT_OWN community. + + + + + +Uttaro, et al. Standards Track [Page 5] + +RFC 7611 ACCEPT_OWN August 2015 + + +8. References + +8.1. Normative References + + [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities + Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, + <http://www.rfc-editor.org/info/rfc1997>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, + DOI 10.17487/RFC4271, January 2006, + <http://www.rfc-editor.org/info/rfc4271>. + + [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private + Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February + 2006, <http://www.rfc-editor.org/info/rfc4364>. + +8.2. Informative References + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + + + + + + + + + + + + + + + + + + + + + + +Uttaro, et al. Standards Track [Page 6] + +RFC 7611 ACCEPT_OWN August 2015 + + +Appendix A. Local Extranet Application (Non-normative) + + One of the applications for the BGP well-known community described in + this document is auto-configuration of extranets within MPLS VPN + networks. Consider the following topology: + + CE1 --------+ + | + (VRF 1, RD 1, RT 1) + PE1 ................... RR + (VRF 2, RD 2, RT 2) + | + CE2 --------+ + + Figure 1: Extranet Application + + Within this topology, PE1 receives a prefix X from CE1. Prefix X is + installed in VRF 1 and is advertised to the route reflector (RR) with + Route Distinguisher (RD) 1 and Route Target (RT) 1 as configured on + PE1. The requirement is to import prefix X into VRF 2 and advertise + it to CE2 in support of extranet VPN connectivity between CE1/VRF1 + and CE2/VRF2. Current BGP mechanisms for MPLS VPNs [RFC4364] require + changing the import RT value and/or import policy for VRF 2 on PE1. + This is operationally cumbersome in a network with a large number of + border routers having complex BGP policies. + + Alternatively, using the new ACCEPT_OWN community value, the route + reflector can simply re-advertise prefix X back to PE1 with RT 2 + appended. In this way, PE1 will accept prefix X despite its + ORIGINATOR_ID or NEXT_HOP value, import it into VRF 2 as a result of + the presence of RT 2 in the route's Extended Community path + attribute, and then determine the correct adjacency rewrite within + VRF 1 based on the RD value and the prefix. Note that the presence + of RT 1 in the route's Extended Community path attribute will simply + be ignored since RT 1 is associated with the source VRF 1. The same + operation also needs to happen in the reverse direction (VRF 1 + learning a route from VRF 2) to achieve establishment of an extranet + VPN strictly via the route reflector without changing the BGP policy + of PE1 in any way. + + A router performing such an extranet application can accept a route + with its own ORIGINATOR_ID or NEXT_HOP value only if the VRF in which + the router originated the route is different from the VRF in which + the router accepts the re-advertised route. + + + + + + + +Uttaro, et al. Standards Track [Page 7] + +RFC 7611 ACCEPT_OWN August 2015 + + +Acknowledgments + + The authors would like to thank Yakov Rekhter, Jim Guichard, Clarence + Filsfils, John Mullooly, Jeff Haas, Pranav Mehta, and Tamas Mondal + for their valuable comments and suggestions. The decision process + changes were suggested by Pranav Mehta to solve the remote extranet + problem. + +Authors' Addresses + + James Uttaro + AT&T + 200 S. Laurel Avenue + Middletown, NJ 07748 + United States + Email: uttaro@att.com + + + Pradosh Mohapatra + Sproute Networks + Email: mpradosh@yahoo.com + + + David J. Smith + Cisco Systems + 111 Wood Avenue South + Iselin, NJ 08830 + United States + Email: djsmith@cisco.com + + + Robert Raszuk + Mirantis Inc. + 615 National Ave. #100 + Mountain View, CA 94043 + United States + Email: robert@raszuk.net + + + John Scudder + Juniper Networks + 1194 N. Mathilda Ave. + Sunnyvale, CA 94089 + United States + Email: jgs@juniper.net + + + + + + +Uttaro, et al. Standards Track [Page 8] + |