draft-ietf-idr-legacy-rtc-00.txt   draft-ietf-idr-legacy-rtc-01.txt 
Network Working Group P. Mohapatra Network Working Group P. Mohapatra
Internet-Draft A. Sreekantiah Internet-Draft A. Sreekantiah
Intended status: Standards Track K. Patel Intended status: Standards Track K. Patel
Expires: July 21, 2012 B. Pithawala Expires: September 14, 2013 B. Pithawala
Cisco Systems Cisco Systems
A. Lo A. Lo
Arista Networks Arista Networks
January 18, 2012 March 13, 2013
Automatic Route Target Filtering for legacy PEs Automatic Route Target Filtering for legacy PEs
draft-ietf-idr-legacy-rtc-00 draft-ietf-idr-legacy-rtc-01.txt
Abstract Abstract
This document describes a simple procedure that allows "legacy" BGP This document describes a simple procedure that allows "legacy" BGP
speakers to exchange route target membership information in BGP speakers to exchange route target membership information in BGP
without using mechanisms specified in RFC 4684. The intention of the without using mechanisms specified in [RFC4684]. The intention of
proposed technique is to help in partial deployment scenarios and is the proposed technique is to help in partial deployment scenarios and
not meant to replace RFC 4684. is not meant to replace [RFC4684].
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 21, 2012. This Internet-Draft will expire on September 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 2, line 23
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Detailed Operation . . . . . . . . . . . . . . . . . . . . . . 4 3. Detailed Operation . . . . . . . . . . . . . . . . . . . . . 3
3.1. Legacy PE Behavior . . . . . . . . . . . . . . . . . . . . 4 3.1. Legacy PE Behavior . . . . . . . . . . . . . . . . . . . 3
3.2. RR behavior . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. RR Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Generating Route Target Membership NLRIs for the 3.2.1. Generating Route Target Membership NLRIs for the
legacy PE clients . . . . . . . . . . . . . . . . . . 7 legacy PE clients . . . . . . . . . . . . . . . . . . 6
4. ROUTE_FILTER community . . . . . . . . . . . . . . . . . . . . 8 4. ROUTE_FILTER Community . . . . . . . . . . . . . . . . . . . 6
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. Normative References . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informational References . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
[RFC4684], "Constrained Route Distribution for Border Gateway [RFC4684] provides a powerful and general means for BGP speakers to
Protocol/ MultiProtocol Label Switching (BGP/MPLS) Internet Protocol exchange and propagate Route Target reachability information and
(IP) Virtual Private Networks (VPNs)" provides a powerful and general constrain VPN route distribution to achieve high scale. However, it
means for BGP speakers to exchange and propagate Route Target requires that all the BGP speakers in the network are upgraded to
reachability information and constrain VPN route distribution to support this functionality. For example, in a network with route
achieve high scale. However, it requires that all the BGP speakers reflectors (RR), if one PE client in the cluster doesn't support
in the network are upgraded to support this functionality. For constrained distribution, the cluster degenerates into storing and
example, in a network with route reflectors (RR), if one PE client in processing all the VPN routes. The route reflectors need to request
the cluster doesn't support constrained distribution, the cluster and store all the network routes since they do not receive route
degenerates into storing and processing all the VPN routes. The target membership information from the legacy PEs. The RR will also
route reflectors need to request and store all the network routes generate all those routes to the legacy PEs and the legacy PEs will
since they do not receive route target membership information from end up filtering the routes and store the subset of VPN routes that
the legacy PEs. The RR will also generate all those routes to the are of interest.
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 This document specifies a mechanism for such legacy PE devices using
existing configuration and toolset to provide similar benefits as existing configuration and toolset to provide similar benefits as
[RFC4684]. At the same time, it is backward-compatible with the [RFC4684]. At the same time, it is backward-compatible with the
procedures defined in [RFC4684]. It also allows graceful upgrade of procedures defined in [RFC4684]. It also allows graceful upgrade of
the legacy router to be [RFC4684] capable. the legacy router to be [RFC4684] capable.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Basic Idea 2. Basic Idea
The basic idea is to make use of VPN unicast route exchange from the 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. legacy PEs to a new BGP speaker (e.g. an RR) to signal RT
The legacy PEs announce a set of "special" routes with mapped RTs to membership. The legacy PEs announce a set of "special" routes with
the RR along with a standard community (defined in this document). mapped RTs to the RR along with a standard community (defined in this
The presence of the community triggers the RR to extract the RTs and document). The presence of the community triggers the RR to extract
build RT membership information. the RTs and build RT membership information.
3. Detailed Operation 3. Detailed Operation
3.1. Legacy PE Behavior 3.1. Legacy PE Behavior
The following simple steps are performed on the legacy PE device: The following simple steps are performed on the legacy PE device:
o Collect the "import route targets" of all the configured customer o Collect the "import route targets" of all the configured customer
VRFs. Let's call this set 'IRTS'. VRFs. Let's call this set 'IRTS'.
skipping to change at page 6, line 5 skipping to change at page 4, line 22
route-filter VRF. route-filter VRF.
o The translation of the IRTs is necessary in order to refrain from o The translation of the IRTs is necessary in order to refrain from
importing "route-filter" VRF routes into VPN VRFs that would importing "route-filter" VRF routes into VPN VRFs that would
import the same route-targets. The translation of the IRTS is import the same route-targets. The translation of the IRTS is
done as follows. For a given IRT, the equivalent translated RT done as follows. For a given IRT, the equivalent translated RT
(TRT) is constructed by means of swapping the value of the high- (TRT) is constructed by means of swapping the value of the high-
order octet of the Type field for the IRT (as defined in order octet of the Type field for the IRT (as defined in
[RFC4360]). [RFC4360]).
0 1 0 1 0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x02 | | 0x01 | 0x02 | | 0x00 | 0x02 | | 0x01 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|2B AS | |2B AS => IP(high) | |2B AS | |2B AS => IP(high) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Local Admin(high) | |Local Admin(high) => IP(low) | |Local Admin(high) | |Local Admin(high) => IP(low) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Local Admin(low) | |Local Admin(low) => Local Admin| |Local Admin(low) | |Local Admin(low) => Local Admin|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0x02 | | 0x02 | 0x02 | | 0x01 | 0x02 | | 0x02 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IP(high) | |IP(high) => 4B AS(high) | |IP(high) | |IP(high) => 4B AS(high) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IP(low) | |IP(low) => 4B AS(low) | |IP(low) | |IP(low) => 4B AS(low) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Local Admin | |Local Admin => Local Admin | |Local Admin | |Local Admin => Local Admin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 | 0x02 | | 0x00 | 0x02 | | 0x02 | 0x02 | | 0x00 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|4B AS(high) | |4B AS(high) => 2B AS | |4B AS(high) | |4B AS(high) => 2B AS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|4B AS(low) | |4B AS(low) => Local Admin(high)| |4B AS(low) | |4B AS(low) => Local Admin(high)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Local Admin | |Local Admin => Local Admin(low)| |Local Admin | |Local Admin => Local Admin(low)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As an example, if IRT R= 65500:12244(hex: 0x0002ffdc00002fd4), As an example, if IRT R= 65500:12244(hex: 0x0002ffdc00002fd4),
equivalent route-filter TRT: 255.220.0.0:12244(hex: equivalent route-filter TRT: 255.220.0.0:12244(hex:
0x0102ffdc00002fd4). One shortcoming of the translation mechanism 0x0102ffdc00002fd4). One shortcoming of the translation mechanism
is a possible collision between IRTs and TRTs if the network has is a possible collision between IRTs and TRTs if the network has
been configured with RTs of multiple higher order octet types been configured with RTs of multiple higher order octet types
(2-byte AS, IP address, and 4-byte AS). It is expected that such (2-byte AS, IP address, and 4-byte AS). It is expected that such
a configuration is rare in practice. a configuration is rare in practice.
o As an alternative to the translation of the IRTS, the subset of o As an alternative to the translation of the IRTS, the subset of
skipping to change at page 7, line 21 skipping to change at page 5, line 39
o The routes are marked with NO_ADVERTISE and NO_EXPORT well-known o The routes are marked with NO_ADVERTISE and NO_EXPORT well-known
communities as well as the appropriate new community that's communities as well as the appropriate new community that's
defined in this document Section 4. Note that there is no defined in this document Section 4. Note that there is no
specific provision made to disallow configuration of subsequent specific provision made to disallow configuration of subsequent
route policies that can potentially alter the set of communities route policies that can potentially alter the set of communities
attached to "route-filter" VRF routes. The protocol behavior in attached to "route-filter" VRF routes. The protocol behavior in
such a case is undefined and the use of those policy statements is such a case is undefined and the use of those policy statements is
discouraged. discouraged.
3.2. RR behavior 3.2. RR Behavior
Upon receiving the "route-filter" routes, the BGP speaker does its Upon receiving the "route-filter" routes, the BGP speaker does its
usual processing to store them in its local RIB. It recognizes them usual processing to store them in its local RIB. It recognizes them
as route-filter routes based on the association of the new standard as route-filter routes based on the association of the new standard
community as defined in this document. If required (as indicated by community as defined in this document. If required (as indicated by
the community value), it translates the attached route-target the community value), it translates the attached route-target
extended communities (TRT) to equivalent import route-targets (IRT). extended communities (TRT) to equivalent import route-targets (IRT).
Finally it creates the route-target filter list for each legacy Finally it creates the route-target filter list for each legacy
client by collecting the entire set of route targets. From this client by collecting the entire set of route targets. From this
point onwards, the behavior is similar to that defined in [RFC4684]. point onwards, the behavior is similar to that defined in [RFC4684].
skipping to change at page 8, line 5 skipping to change at page 6, line 23
clients clients
The RR MAY also translate the received extended communities from The RR MAY also translate the received extended communities from
legacy clients into route target membership NLRIs as if it had legacy clients into route target membership NLRIs as if it had
received those NLRIs from the client itself. This is useful for received those NLRIs from the client itself. This is useful for
further propagation of the NLRIs to rest of the network to create RT further propagation of the NLRIs to rest of the network to create RT
membership flooding graph. When the route_filter routes are received membership flooding graph. When the route_filter routes are received
with same RD (from all legacy PE speakers), processing of the paths with same RD (from all legacy PE speakers), processing of the paths
to generate equivalent NLRIs becomes fairly easy. to generate equivalent NLRIs becomes fairly easy.
4. ROUTE_FILTER community 4. ROUTE_FILTER Community
This memo defines four BGP communities that are attached to BGP This memo defines four BGP communities that are attached to BGP
UPDATE messages at the legacy PE devices and processed by the route UPDATE messages at the legacy PE devices and processed by the route
reflectors as defined above. They are as follows: reflectors as defined above. They are as follows:
+----------------------------+--------------------------------------+ +----------------------------+--------------------------------------+
| Community | Meaning | | Community | Meaning |
+----------------------------+--------------------------------------+ +----------------------------+--------------------------------------+
| ROUTE_FILTER_v4 | RTs are attached as-is for VPNv4 | | ROUTE_FILTER_v4 | RTs are attached as-is for VPNv4 |
| | route filtering | | | route filtering |
| ... | ... | | ... | ... |
| ROUTE_FILTER_v6 | RTs are attached as-is for VPNv6 | | ROUTE_FILTER_v6 | RTs are attached as-is for VPNv6 |
| | route filtering | | | route filtering |
| ... | ... | | ... | ... |
| ROUTE_FILTER_TRANSLATED_v4 | Translated RTs are attached for | | ROUTE_FILTER_TRANSLATED_v4 | Translated RTs are attached for |
| | VPNv4 route filtering | | | VPNv4 route filtering |
| ... | ... | | ... | ... |
| ROUTE_FILTER_TRANSLATED_v6 | Translated RTs are attached for | | ROUTE_FILTER_TRANSLATED_v6 | Translated RTs are attached for |
| | VPNv6 route filtering | | | VPNv6 route filtering |
+----------------------------+--------------------------------------+ +----------------------------+--------------------------------------+
In the absence of (or lack of support of) AF specific communities 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_v6, ROUTE_FILTER_TRANSLATED_v6), the ROUTE_FILTER_v4 or
ROUTE_FILTER_TRANSLATED_v4 MAY be treated by an implementation as a ROUTE_FILTER_TRANSLATED_v4 MAY be treated by an implementation as a
default VPN route-filter community to build a combination VPN filter default VPN route-filter community to build a combination VPN filter
for all VPN AFs (VPNv4, VPNv6) present on the RR. This is in for all VPN AFs (VPNv4, VPNv6) present on the RR. This is in
accordance with the procedures in [RFC4684] to build combination accordance with the procedures in [RFC4684] to build combination
route-filters for VPN AFs and AF specific route-filters defined in route-filters for VPN AFs and AF specific route-filters defined in
[I-D.keyur-bgp-af-specific-rt-constrain]. If this is the case, then [I-D.keyur-bgp-af-specific-rt-constrain]. If this is the case, then
subsequent receipt of any "route-filter" routes with AF specific subsequent receipt of any "route-filter" routes with AF specific
communities (ROUTE_FILTER_v6, ROUTE_FILTER_TRANSLATED_v6) will communities (ROUTE_FILTER_v6, ROUTE_FILTER_TRANSLATED_v6) will
override the default filters sent with ROUTE_FILTER_v4 or override the default filters sent with ROUTE_FILTER_v4 or
ROUTE_FILTER_TRANSLATED_v4 for the VPNv6 AFI when support for the AF ROUTE_FILTER_TRANSLATED_v4 for the VPNv6 AFI when support for the AF
specific communities exists. specific communities exists.
5. Deployment Considerations 5. Deployment Considerations
When both the legacy PE and the RR support extended community based When both the legacy PE and the RR support extended community based
Outbound Route Filtering as in Outbound Route Filtering as in [I-D.chen-bgp-ext-community-orf] this
[I-D.draft-chen-bgp-ext-community-orf-00] this may be used as a may be used as a alternate solution for the legacy PE to signal RT
alternate solution for the legacy PE to signal RT membership membership information, in order to realize the same benefits as
information, in order to realize the same benefits as [RFC4684]. [RFC4684]. Also extended community ORF can be used amongst the RRs
Also extended community ORF can be used amongst the RRs in lieu of in lieu of [RFC4684] to realize similar benefits.
[RFC4684] to realize similar benefits.
6. Contributors 6. Contributors
Significant contributions were made by Stephane Litkowski, Luis M Significant contributions were made by Stephane Litkowski, Luis M
Tomotaki and James Uttaro which the authors would like to Tomotaki and James Uttaro which the authors would like to
acknowledge. acknowledge.
7. Acknowledgements 7. Acknowledgments
The authors would like to thank Rob Shakir for his review and The authors would like to thank Rob Shakir for his review and
comments. comments.
8. IANA Considerations 8. IANA Considerations
IANA shall assign new code points from BGP first-come first-serve IANA shall assign new code points from BGP first-come first-serve
communities for the four communities as listed in Section 4. communities for the four communities as listed in Section 4.
9. Security Considerations 9. Security Considerations
None. There are no additional security risks introduced by this design.
10. Normative References
[I-D.chen-bgp-ext-community-orf] 10. References
Chen, E. and Y. Rekhter, "Extended Community Based
Outbound Route Filter for BGP-4",
draft-chen-bgp-ext-community-orf-00 (work in progress),
June 2006.
[I-D.keyur-bgp-af-specific-rt-constrain] 10.1. Normative References
Patel, K., Raszuk, R., Djernaes, M., Dong, J., and M.
Chen, "AFI Specific Route Target Distribution",
draft-keyur-bgp-af-specific-rt-constrain-00 (work in
progress), October 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006. Communities Attribute", RFC 4360, February 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, November 2006. Private Networks (VPNs)", RFC 4684, November 2006.
10.2. Informational References
[I-D.chen-bgp-ext-community-orf]
Chen, E., Lo, A., and K. Patel, "Extended Community Based
Outbound Route Filter for BGP-4", draft-chen-bgp-ext-
community-orf-02 (work in progress), December 2011.
[I-D.keyur-bgp-af-specific-rt-constrain]
Patel, K., Raszuk, R., Djernaes, M., Dong, J., and M.
Chen, "IPv6 AF Extensions for Route Target Distribution",
draft-keyur-bgp-af-specific-rt-constrain-01 (work in
progress), March 2011.
Authors' Addresses Authors' Addresses
Pradosh Mohapatra Pradosh Mohapatra
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: pmohapat@cisco.com Email: pmohapat@cisco.com
 End of changes. 24 change blocks. 
115 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/