doc: Add RFC documents

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]
+