BGP ACCEPT_OWN Community AttributeAT&T200 S. Laurel AvenueMiddletownNJ07748United Statesuttaro@att.comSproute Networksmpradosh@yahoo.comCisco Systems111 Wood Avenue SouthIselinNJ08830United Statesdjsmith@cisco.comMirantis Inc.615 National Ave. #100Mountain ViewCA94043United Statesrobert@raszuk.netJuniper Networks1194 N. Mathilda Ave.SunnyvaleCA94089United Statesjgs@juniper.netUnder 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.In certain scenarios, a BGP speaker may maintain multiple VRFs
. 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.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 , 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 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.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.This memo defines ACCEPT_OWN, a new well-known BGP community in the First
Come First Served 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 .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:Processing of the ACCEPT_OWN community is enabled by
configuration.The route in question carries the ACCEPT_OWN community.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.The route in question is targeted to one or more destination
VRFs on the router (as determined by inspecting the Route
Target(s)).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.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.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 . The router SHOULD still apply
the propagation rules detailed in .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.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 (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.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.This approach may also be relevant in other scenarios where a
BGP speaker maintains multiple routing contexts using an approach
different from that of , 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.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 .IANA has assigned the value 0xFFFF0001 in the "BGP Well-known Communities"
registry for the ACCEPT_OWN community.
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:
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 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.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.