Automatic Route Target Filtering for legacy PEs Sproute Networksmpradosh@yahoo.comCisco Systems170 W. Tasman DriveSan JoseCA95134USAasreekan@cisco.comArrcus Inckeyurpat@yahoo.comCisco Systems170 W. Tasman DriveSan JoseCA95134USAbpithaw@cisco.comArista Networks5470 Great America ParkwaySanta ClaraCA95054USAaltonlo@aristanetworks.comThis document describes a simple procedure that allows "legacy"
BGP speakers to exchange route target membership information in
BGP without using mechanisms specified
in . The intention of the proposed
technique is to help in partial deployment scenarios and is not
meant to replace . provides a powerful and general
means for BGP speakers to exchange and propagate Route Target
reachability information and constrain VPN route distribution to
achieve high scale. However, it requires that all the BGP
speakers in the network are upgraded to support this
functionality. For example, in a network with route reflectors
(RR), if one PE client in the cluster doesn't support constrained
distribution, the cluster degenerates into storing and processing
all the VPN routes. The route reflectors need to request and
store all the network routes since they do not receive route
target membership information from the legacy PEs. The RR will
also generate all those routes to the legacy PEs and the legacy
PEs will end up filtering the routes and store the subset of VPN
routes that are of interest.This document specifies a mechanism for such legacy PE devices
using existing configuration and toolset to provide similar
benefits as . At the same time, it
is backward-compatible with the procedures defined
in . It also allows graceful
upgrade of the legacy router to be
capable.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.The basic idea is to make use of VPN unicast route exchange from
the legacy PEs to a new BGP speaker (e.g. an RR) to signal RT
membership. The legacy PEs announce a set of "special" routes
with mapped RTs to the RR along with a standard community (defined
in this document). The presence of the community triggers the RR
to extract the RTs and build RT membership information.The following simple steps are performed on the legacy PE
device:
Collect the "import route targets" of all the configured
customer VRFs. Let's call this set 'IRTS'.Create a special "route-filter VRF" with a route
distinguisher(RD) that's configured with the same value across
the network for all legacy PE devices. Note: the equivalence
of the RD value is for optimization - the operator may choose
to use different values.Originate one or more routes in this VRF and attach a subset
of 'IRTS' as "translated route-target extended communities"
with each route so as to evenly distribute the RTs (and to make
sure they can fit into one BGP UPDATE message). Collectively,
the union of the "translated route-target extended communities"
of all these routes is equal to the set 'IRTS'. The translated
RTs are attached as export route-targets for the routes
originated in the route-filter VRF.The translation of the IRTs is necessary in order to refrain
from importing "route-filter" VRF routes into VPN VRFs that
would import the same route-targets. The translation of the
IRTS is done as follows. For a given IRT, the equivalent
translated RT (TRT) is constructed by means of swapping the
value of the high- order octet of the Type field for the IRT
(as defined in ).
As an example, if IRT R= 65500:12244(hex:
0x0002ffdc00002fd4), equivalent route-filter TRT:
255.220.0.0:12244(hex: 0x0102ffdc00002fd4). One shortcoming of
the translation mechanism is a possible collision between IRTs
and TRTs if the network has been configured with RTs of
multiple higher order octet types (2-byte AS, IP address, and
4-byte AS). It is expected that such a configuration is rare
in practice.As an alternative to the translation of the IRTS, the subset
of the 'IRTS' can be attached as-is (without swapping the type
field as described earlier) as "export route-target extended
communities" with each route so as to evenly distribute the RTs
(and to make sure they can fit into one BGP UPDATE message).
In this case, the IRT subsets can be attached in outbound
policy to avoid the route-filter VRFs from being imported into
VPN VRFs. Also in this case, the route-filter VRF routes must
be tagged with a different special community (from that
associated with the translated RTs) as described
in so that the receiving BGP
speaker can distinguish the two cases.The routes are marked with NO_ADVERTISE and NO_EXPORT
well-known communities as well as the appropriate new community
that's defined in this
document . Note that there is
no specific provision made to disallow configuration of
subsequent route policies that can potentially alter the set of
communities attached to "route-filter" VRF routes. The
protocol behavior in such a case is undefined and the use of
those policy statements is discouraged.Upon receiving the "route-filter" routes, the BGP speaker does
its usual processing to store them in its local RIB. It
recognizes them as route-filter routes based on the association
of the new standard community as defined in this document. If
required (as indicated by the community value), it translates the
attached route-target extended communities (TRT) to equivalent
import route-targets (IRT). Finally it creates the route-target
filter list for each legacy client by collecting the entire set
of route targets. From this point onwards, the behavior is
similar to that defined in . The
RR does not propagate the routes further because of their
association with NO_ADVERTISE community. Also the VPN EoR that
is sent by the legacy PE should also be used as an indication
that the legacy PE is done sending the route-filter information
as per the procedures defined in
for implementing a EoR mechanism to signal the completion of
initial RT membership exchange.The RR MAY also translate the received extended communities
from legacy clients into route target membership NLRIs as if it
had received those NLRIs from the client itself. This is useful
for further propagation of the NLRIs to rest of the network to
create RT membership flooding graph. When the route_filter
routes are received with same RD (from all legacy PE speakers),
processing of the paths to generate equivalent NLRIs becomes
fairly easy.This memo defines four BGP communities that are attached to BGP
UPDATE messages at the legacy PE devices and processed by the
route reflectors as defined above. They are as follows:
In the absence of (or lack of support of) AF specific communities
(ROUTE_FILTER_v6, ROUTE_FILTER_TRANSLATED_v6), the ROUTE_FILTER_v4
or ROUTE_FILTER_TRANSLATED_v4 MAY be treated by an implementation
as a default VPN route-filter community to build a combination VPN
filter for all VPN AFs (VPNv4, VPNv6) present on the RR. This is
in accordance with the procedures
in to build combination
route-filters for VPN AFs and AF specific route-filters defined
in . If
this is the case, then subsequent receipt of any "route-filter"
routes with AF specific communities (ROUTE_FILTER_v6,
ROUTE_FILTER_TRANSLATED_v6) will override the default filters sent
with ROUTE_FILTER_v4 or ROUTE_FILTER_TRANSLATED_v4 for the VPNv6
AFI when support for the AF specific communities exists. Suggested
values for ROUTE_FILTER_v4 and ROUTE_FILTER_TRANSLATED_v4 are
0xFFFF0002 (65535:2) and 0xFFFF0003 (65535:3) respectivelyWhen both the legacy PE and the RR support extended community
based Outbound Route Filtering as
in this may
be used as a alternate solution for the legacy PE to signal RT
membership information, in order to realize the same benefits
as . Also extended community ORF
can be used amongst the RRs in lieu
of to realize similar benefits.Significant contributions were made by Stephane Litkowski, Luis
M Tomotaki and James Uttaro which the authors would like to
acknowledge.The authors would like to thank Rob Shakir for his review and
comments.IANA shall assign new code points from BGP first-come
first-serve communities for the four communities as listed
in .There are no additional security risks introduced by this
design.