Movatterモバイル変換

Internet Engineering Task Force (IETF)                         J. UttaroRequest for Comments: 7611                                          AT&TCategory: Standards Track                                   P. MohapatraISSN: 2070-1721                                         Sproute Networks                                                                D. Smith                                                           Cisco Systems                                                               R. Raszuk                                                           Mirantis Inc.                                                              J. Scudder                                                        Juniper Networks                                                             August 2015BGP ACCEPT_OWN Community AttributeAbstract   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 inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc7611.Uttaro, et al.               Standards Track                    [Page 1]

RFC 7611                       ACCEPT_OWN                    August 2015Copyright Notice   Copyright (c) 2015 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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 Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .21.1.  Requirements Language . . . . . . . . . . . . . . . . . .32.  ACCEPT_OWN Community  . . . . . . . . . . . . . . . . . . . .32.1.  Route Acceptance  . . . . . . . . . . . . . . . . . . . .32.2.  Propagating ACCEPT_OWN between Address Families . . . . .42.3.  Configuration Control . . . . . . . . . . . . . . . . . .43.  Decision Process  . . . . . . . . . . . . . . . . . . . . . .44.  Deployment Considerations . . . . . . . . . . . . . . . . . .55.  Other Applications  . . . . . . . . . . . . . . . . . . . . .56.  Security Considerations . . . . . . . . . . . . . . . . . . .57.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .58.  References  . . . . . . . . . . . . . . . . . . . . . . . . .68.1.  Normative References  . . . . . . . . . . . . . . . . . .68.2.  Informative References  . . . . . . . . . . . . . . . . .6Appendix A.  Local Extranet Application (Non-normative) . . . . .7   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .8   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .81.  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 inRFC 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 inSection 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 inSection 2.1.  The router SHOULD still apply the   propagation rules detailed inSection 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 20158.  References8.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 2015Appendix 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 2015Acknowledgments   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.netUttaro, et al.               Standards Track                    [Page 8]