draft-ietf-l3vpn-rt-constrain-02.txt   rfc4684.txt 
L3VPN Working Group P. Marques Network Working Group P. Marques
Internet-Draft R. Bonica Request for Comments: 4684 R. Bonica
Expires: December 24, 2005 Juniper Networks Updates: 4364 Juniper Networks
L. Fang Category: Standards Track L. Fang
AT&T
L. Martini L. Martini
R. Raszuk R. Raszuk
K. Patel K. Patel
J. Guichard J. Guichard
Cisco Systems, Inc. Cisco Systems, Inc.
June 22, 2005 November 2006
Constrained VPN Route Distribution
draft-ietf-l3vpn-rt-constrain-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Constrained Route Distribution for
http://www.ietf.org/ietf/1id-abstracts.txt. Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS)
Internet Protcol (IP) Virtual Private Networks (VPNs)
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 24, 2005. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The IETF Trust (2006).
Abstract Abstract
This document defines MP-BGP procedures that allow BGP speakers to This document defines Multi-Protocol BGP (MP-BGP) procedures that
exchange Route Target reachability information. This information can allow BGP speakers to exchange Route Target reachability information.
be used to build a route distribution graph in order to limit the This information can be used to build a route distribution graph in
propagation of VPN NLRI (such as VPN-IPv4, VPN-IPv6 or L2-VPN NLRI) order to limit the propagation of Virtual Private Network (VPN)
between different autonomous systems or distinct clusters of the same Network Layer Reachability Information (NLRI) between different
autonomous system. autonomous systems or distinct clusters of the same autonomous
system. This document updates RFC 4364.
Table of Contents Table of Contents
1. Specification of Requirements . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology ................................................3
3. NLRI Distribution . . . . . . . . . . . . . . . . . . . . . 6 2. Specification of Requirements ...................................4
3.1 Inter-AS VPN Route Distribution . . . . . . . . . . . . . 6 3. NLRI Distribution ...............................................4
3.2 Intra-AS VPN Route Distribution . . . . . . . . . . . . . 7 3.1. Inter-AS VPN Route Distribution ............................4
4. Route Target membership NLRI advertisements . . . . . . . . 10 3.2. Intra-AS VPN Route Distribution ............................6
5. Capability Advertisement . . . . . . . . . . . . . . . . . . 11 4. Route Target Membership NLRI Advertisements .....................8
6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Capability Advertisement ........................................9
7. Deployment Considerations . . . . . . . . . . . . . . . . . 13 6. Operation .......................................................9
8. Security Considerations . . . . . . . . . . . . . . . . . . 14 7. Deployment Considerations ......................................10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations ........................................11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements ...............................................11
10.1 Normative References . . . . . . . . . . . . . . . . . . 16 10. References ....................................................11
10.2 Informative References . . . . . . . . . . . . . . . . . 16 10.1. Normative References .....................................11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References ...................................12
Intellectual Property and Copyright Statements . . . . . . . 19
1. Specification of Requirements
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 [1].
2. Introduction 1. Introduction
In BGP/MPLS IP VPNs, PE routers use Route Target (RT) extended In BGP/MPLS IP VPNs, PE routers use Route Target (RT) extended
communities to control the distribution of routes into VRFs. Within communities to control the distribution of routes into VRFs. Within
a given iBGP mesh, PE routers need only to hold routes marked with a given iBGP mesh, PE routers need only hold routes marked with Route
Route Targets pertaining to VRFs that have local CE attachments. Targets pertaining to VRFs that have local CE attachments.
It is common, however, for an autonomous system to use route It is common, however, for an autonomous system to use route
reflection [2] in order to simplify the process of bringing up a new reflection [2] in order to simplify the process of bringing up a new
PE router in the network and to limit the size of the iBGP peering PE router in the network and to limit the size of the iBGP peering
mesh. mesh.
In such a scenario, as well as when VPNs may have members in more In such a scenario, as well as when VPNs may have members in more
than one autonomous system, the number of routes carried by the than one autonomous system, the number of routes carried by the
inter-cluster or inter-as distribution routers is an important inter-cluster or inter-as distribution routers is an important
consideration. consideration.
In order to limit the VPN routing information that is maintained at a In order to limit the VPN routing information that is maintained at a
given route reflector, RFC2547bis [3] suggests, in section 4.3.3., given route reflector, RFC 4364 [3] suggests, in Section 4.3.3, the
the use of "Cooperative Route Filtering" [4] between route use of "Cooperative Route Filtering" [7] between route reflectors.
reflectors. This proposal extends the RFC2547bis [3] ORF work to This document extends the RFC 4364 [3] Outbound Route Filtering (ORF)
include support for multiple autonomous systems, and asymmetric VPN work to include support for multiple autonomous systems and
topologies such as hub-and-spoke. asymmetric VPN topologies such as hub-and-spoke.
While it would be possible to extend the encoding currently defined Although it would be possible to extend the encoding currently
for the extended-community ORF in order to achieve this purpose, BGP defined for the extended-community ORF in order to achieve this
itself already has all the necessary machinery for dissemination of purpose, BGP itself already has all the necessary machinery for
arbitrary information in a loop free fashion, both within a single dissemination of arbitrary information in a loop-free fashion, both
autonomous system, as well as across multiple autonomous systems. within a single autonomous system, as well as across multiple
autonomous systems.
This document builds on the model described in RFC2547bis [3] and on This document builds on the model described in RFC 4364 [3] and on
concept of cooperative route filtering by adding the ability to the concept of cooperative route filtering by adding the ability to
propagate Route Target membership information between iBGP meshes. propagate Route Target membership information between iBGP meshes.
It is designed to supersede "cooperative route filtering" for VPN It is designed to supersede "cooperative route filtering" for VPN
related applications. related applications.
By using MP-BGP UPDATE messages to propagate Route Target membership By using MP-BGP UPDATE messages to propagate Route Target membership
information it is possible to reuse all this machinery including information, it is possible to reuse all of this machinery, including
route reflection, confederations and inter-as information loop route reflection, confederations, and inter-as information loop
detection. detection.
Received Route Target membership information can then be used to Received Route Target membership information can then be used to
restrict advertisement of VPN NLRI to peers that have advertised restrict advertisement of VPN NLRI to peers that have advertised
their respective Route Targets, effectively building a route their respective Route Targets, effectively building a route
distribution graph. In this model, VPN NLRI routing information distribution graph. In this model, VPN NLRI routing information
flows in the inverse direction of Route Target membership flows in the inverse direction of Route Target membership
information. information.
This mechanism is applicable to any BGP NLRI that controls the This mechanism is applicable to any BGP NLRI that controls the
distribution of routing information based on Route Targets, such as distribution of routing information by using Route Targets, such as
BGP L2VPNs [?] and VPLS [9]. VPLS [9].
Throughout this document, the term NLRI, which originally expands to Throughout this document, the term NLRI, which expands to "Network
"Network Layer Reachability Information" is used to describe routing Layer Reachability Information", is used to describe routing
information carried via MP-BGP updates without any assumption of information carried via MP-BGP updates without any assumption of
semantics. semantics.
An NLRI consisting of {origin-as#, route-target} will be referred to An NLRI consisting of {origin-as#, route-target} will be referred to
as RT membership information for the purpose of the explanation in as RT membership information for the purpose of the explanation in
this document. this document.
1.1. Terminology
This document uses a number of terms and acronyms specific to
Provider-Provisioned VPNs, including those specific to L2VPNs, L3VPNs
and BGP. Definitions for many of these terms may be found in the VPN
terminology document [10]. This section also includes some brief
acronym expansion and terminology to aid the reader.
AFI Address Family Identifier (a BGP address type)
BGP Border Gateway Protocol
BGP/MPLS VPN A Layer 3 VPN implementation based upon BGP and MPLS
CE Customer Edge (router)
iBGP Internal BGP (i.e., a BGP peering session that
connects two routers within an autonomous system)
L2VPN Layer 2 Virtual Private Network
L3VPN Layer 3 Virtual Private Network
MP-BGP MultiProtocol-Border Gateway Protocol
MPLS MultiProtocol Label Switching
NLRI Network Layer Reachability Information
ORF Outbound Route Filtering
PE Provider Edge (router)
RT Route Target (i.e., a BGP extended community that
conditions network layer reachability information with
VPN membership)
SAFI Subsequence Address Family Identifier (a BGP address
sub-type)
VPLS Virtual Private LAN Service
VPN Virtual Private Network
2. Specification of Requirements
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 [1].
3. NLRI Distribution 3. NLRI Distribution
3.1 Inter-AS VPN Route Distribution 3.1. Inter-AS VPN Route Distribution
In order to better understand the problem at hand, it is helpful to In order to better understand the problem at hand, it is helpful to
divide it in its inter-AS and intra-AS components. Figure 1 divide it in to its inter-Autonomous System (AS) and intra-AS
represents an arbitrary graph of autonomous systems (a through j) components. Figure 1 represents an arbitrary graph of autonomous
interconnected in an ad-hoc fashion. The following discussion systems (a through j) interconnected in an ad hoc fashion. The
ignores the complexity of intra-AS route distribution. following discussion ignores the complexity of intra-AS route
distribution.
+----------------------------------+ +----------------------------------+
| +---+ +---+ +---+ | | +---+ +---+ +---+ |
| | a | -- | b | -- | c | | | | a | -- | b | -- | c | |
| +---+ +---+ +---+ | | +---+ +---+ +---+ |
| | | | | | | |
| | | | | | | |
| +---+ +---+ +---+ +---+ | | +---+ +---+ +---+ +---+ |
| | d | -- | e | -- | f | -- | j | | | | d | -- | e | -- | f | -- | j | |
| +---+ +---+ +---+ +---+ | | +---+ +---+ +---+ +---+ |
| / | | | / | |
| / | | | / | |
| +---+ +---+ +---+ | | +---+ +---+ +---+ |
| | g | -- | h | -- | i | | | | g | -- | h | -- | i | |
| +---+ +---+ +---+ | | +---+ +---+ +---+ |
+----------------------------------+ +----------------------------------+
Figure 1: Topology of autonomous systems Figure 1. Topology of autonomous systems
Lets consider the simple case of a VPN with CE attachments in ASes a Let's consider the simple case of a VPN with CE attachments in ASes a
and i using a single Route Target to control VPN route distribution. and i that uses a single Route Target to control VPN route
Ideally we would like to build a flooding graph for the respective distribution. Ideally we would like to build a flooding graph for
VPN routes that would not include nodes (c, g, h, j). Nodes (c, j) the respective VPN routes that would not include nodes (c, g, h, j).
are leafs ASes that do not require this information while nodes (g, Nodes (c, j) are leafs ASes that do not require this information,
h) are not in the shortest inter-as path between (e) and (i) and thus whereas nodes (g, h) are not in the shortest inter-as path between
should be excluded via standard BGP path selection. (e) and (i) and thus should be excluded via standard BGP path
selection.
In order to achieve this we will rely on ASa and ASi generating a In order to achieve this, we will rely on ASa and ASi, generating a
NLRI consisting of {origin-as#, route-target} ( RT membership NLRI consisting of {origin-as#, route-target} ( RT membership
information ). Receipt of such an advertisement by one of the ASes information). Receipt of such an advertisement by one of the ASes in
in the network will signal the need to distribute VPN routes the network will signal the need to distribute VPN routes containing
containing this Route Target community to the peer that advertised this Route Target community to the peer that advertised this route.
this route.
Using RT membership information that includes both route-target and Using RT membership information that includes both route-target and
originator AS number, allows BGP speakers to use standard path originator AS number allows BGP speakers to use standard path
selection rules concerning as-path length (and other policy selection rules concerning as-path length (and other policy
mechanisms) to prune duplicate paths in the RT membership information mechanisms) to prune duplicate paths in the RT membership information
flooding graph, while maintaining the information required to reach flooding graph, while maintaining the information required to reach
all autonomous systems advertising the Route Target. all autonomous systems advertising the Route Target.
In the example above, AS e needs to maintain a path to AS a in order In the example above, AS e needs to maintain a path to AS a in order
to flood VPN routing information originating from AS i and vice- to flood VPN routing information originating from AS i and vice-
versa. It should however, as default policy, prune less preferred versa. It should, however, as default policy, prune less preferred
paths such as the longer path to ASi with as-path (g h i). paths such as the longer path to ASi with as-path (g h i).
Extending the example above to include AS j as a member of the VPN Extending the example above to include AS j as a member of the VPN
distribution graph would cause AS f to advertise 2 RT Membership NLRI distribution graph would cause AS f to advertise 2 RT Membership
to AS e, one containing origin AS i and one containing origin AS j. NLRIs to AS e, one containing origin AS i and one containing origin
While advertising a single path would be sufficient to guarantee that AS j. Although advertising a single path would be sufficient to
VPN information flows to all VPN member ASes, this is not enough for guarantee that VPN information flows to all VPN member ASes, this is
the desired path selection choices. In the example above, assume (f not enough for the desired path selection choices. In the example
j) is selected and advertised. Where that to be the case the above, assume that (f j) is selected and advertised. Were that the
information concerning the path (f i), which is necessary to prune case, the information concerning the path (f i), which is necessary
the arc (e g h i) from the route distribution graph, would be to prune the arc (e g h i) from the route distribution graph, would
missing. be missing.
As with other approaches for building distribution graphs, the As with other approaches for building distribution graphs, the
benefits of this mechanism are directly proportional to how "sparse" benefits of this mechanism are directly proportional to how "sparse"
the VPN membership is. Standard RFC2547 inter-AS behavior can be the VPN membership is. Standard RFC2547 inter-AS behavior can be
seen as a dense-mode approach, to make the analogy with multicast seen as a dense-mode approach, to make the analogy with multicast
routing protocols. routing protocols.
3.2 Intra-AS VPN Route Distribution 3.2. Intra-AS VPN Route Distribution
As indicated above, the inter-AS VPN route distribution graph, for a As indicated above, the inter-AS VPN route distribution graph, for a
given route-target, is constructed by creating a directed arc on the given route-target, is constructed by creating a directed arc on the
inverse direction of received Route Target membership UPDATEs inverse direction of received Route Target membership UPDATEs
containing an NLRI of the form {origin-as#, route-target}. containing an NLRI of the form {origin-as#, route-target}.
Inside the BGP topology of a given autonomous-system, as far as Inside the BGP topology of a given autonomous-system, as far as
external RT membership information is concerned (route-targets where external RT membership information is concerned (route-targets where
the as# is not the local as), it is easy to see that standard BGP the as# is not the local as), it is easy to see that standard BGP
route selection and advertisement rules [5] will allow a transit AS route selection and advertisement rules [4] will allow a transit AS
to create the necessary flooding state. to create the necessary flooding state.
Consider a IPv4 NLRI prefix, sourced by a single AS, which is Consider a IPv4 NLRI prefix, sourced by a single AS, which is
distributed via BGP within a given transit AS. BGP protocol rules distributed via BGP within a given transit AS. BGP protocol rules
guarantee that a BGP speaker has a valid route that can be used for guarantee that a BGP speaker has a valid route that can be used for
forwarding of data packets for that destination prefix, in the forwarding of data packets for that destination prefix, in the
inverse path of received routing updates. inverse path of received routing updates.
By the same token, and given that a {origin-as#, route-target} key By the same token, and given that an {origin-as#, route-target} key
provides uniqueness between several ASes that may be sourcing this provides uniqueness between several ASes that may be sourcing this
route-target, BGP route selection and advertisement procedures route-target, BGP route selection and advertisement procedures
guarantee that a valid VPN route distribution path exists to the guarantee that a valid VPN route distribution path exists to the
origin of the Route Target membership information advertisement. origin of the Route Target membership information advertisement.
Route Target membership information that is originated within the Route Target membership information that is originated within the
autonomous-system however requires more careful examination. Several autonomous-system, however, requires more careful examination.
PE routers within a given autonomous-system may source the same NLRI Several PE routers within a given autonomous-system may source the
{origin-as#, route-target}, thus default route advertisement rules same NLRI {origin-as#, route-target}, and thus default route
are no longer sufficient to guarantee that within the given AS each advertisement rules are no longer sufficient to guarantee that within
node in the distribution graph has selected a feasible path to each the given AS each node in the distribution graph has selected a
of the PEs that import the given route-target. feasible path to each of the PEs that import the given route-target.
When processing RT membership NLRIs received from internal iBGP When processing RT membership NLRIs received from internal iBGP
peers, it is necessary to consider all available iBGP paths for a peers, it is necessary to consider all available iBGP paths for a
given RT prefix, when building the outbound route filter, and not given RT prefix, for building the outbound route filter, and not just
just the best path. the best path.
In addition, when advertising Route Target membership information In addition, when advertising Route Target membership information
sourced by the local autonomous system to an iBGP peer, a BGP speaker sourced by the local autonomous system to an iBGP peer, a BGP speaker
shall modify its procedure to calculate the BGP attributes such that: shall modify its procedure to calculate the BGP attributes such that
the following apply:
i. When advertising RT membership NLRI to a route-reflector i. When advertising RT membership NLRI to a route-reflector client,
client, the Originator attribute shall be set to the router-id of the Originator attribute shall be set to the router-id of the
the advertiser and the Next-hop attribute shall be set of the advertiser, and the Next-hop attribute shall be set of the local
local address for that session. address for that session.
ii. When advertising a RT membership NLRI to a non client peer, ii. When advertising an RT membership NLRI to a non-client peer, if
if the best path as selected by path selection procedure described the best path as selected by the path selection procedure
in section 9.1 of the base BGP specification [5] is a route described in Section 9.1 of the base BGP specification [4] is a
received from a non-client peer, and there is an alternative path route received from a non-client peer, and if there is an
to the same destination from a client, the attributes of the alternative path to the same destination from a client, the
client path are advertised to the peer. attributes of the client path are advertised to the peer.
The first of these route advertisement rules is designed such that The first of these route advertisement rules is designed such that
the originator of RT membership NLRI does not drop a RT membership the originator of an RT membership NLRI does not drop an RT
NLRI which is reflected back to it, thus allowing the route reflector membership NLRI that is reflected back to it, thus allowing the route
to use this RT membership NLRI in order to signal the client that it reflector to use this RT membership NLRI in order to signal the
should distribute VPN routes with the specific target torwards the client that it should distribute VPN routes with the specific target
reflector. towards the reflector.
The second rule makes it such that any BGP speaker present in an iBGP The second rule allows any BGP speaker present in an iBGP mesh to
mesh can signal the interest of its route reflection clients in signal the interest of its route reflection clients in receiving VPN
receiving VPN routes for that target. routes for that target.
These procedures assume that the autonomous-system route reflection These procedures assume that the autonomous-system route reflection
topology is configured such that IPv4 unicast routing would work topology is configured such that IPv4 unicast routing would work
correctly. For instance, route reflection clusters must be correctly. For instance, route reflection clusters must be
contiguous. contiguous.
An alternative solution to the procedure given above would have been An alternative solution to the procedure given above would have been
to source different routes per PE, such as NLRI of the form {origina- to source different routes per PE, such as NLRI of the form
tor-id, route-target}, and aggregate them at the edge of the network. {originator-id, route-target}, and to aggregate them at the edge of
The solution adopted is considered to be advantageous over the former the network. The solution adopted is considered advantageous over
given that it requires less routing-information within a given AS. the former in that it requires less routing-information within a
given AS.
4. Route Target membership NLRI advertisements 4. Route Target Membership NLRI Advertisements
Route Target membership NLRI is advertised in BGP UPDATE messages Route Target membership NLRI is advertised in BGP UPDATE messages
using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [6]. The using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [5]. The
[AFI, SAFI] value pair used to identify this NLRI is (AFI=1, [AFI, SAFI] value pair used to identify this NLRI is (AFI=1,
SAFI=132). SAFI=132).
The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as
an IPv4 address, whenever the length of NextHop address is 4 octets, an IPv4 address whenever the length of NextHop address is 4 octets,
and as a IPv6 address, whenever the length of the NextHop address is and as a IPv6 address whenever the length of the NextHop address is
16 octets. 16 octets.
The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix
of 0 to 96 bits encoded as defined in section 4 of [6]. of 0 to 96 bits, encoded as defined in Section 4 of [5].
This prefix is structured as follows: This prefix is structured as follows:
+-------------------------------+ +-------------------------------+
| origin as (4 octets) | | origin as (4 octets) |
+-------------------------------+ +-------------------------------+
| route target (8 octets) | | route target (8 octets) |
+ + + +
| | | |
+-------------------------------+ +-------------------------------+
Except for the default route target, which is encoded as a 0 length Except for the default route target, which is encoded as a zero-
prefix, the minimum prefix length is 32 bits. As the origin-as field length prefix, the minimum prefix length is 32 bits. As the origin-
cannot be interpreted as a prefix. as field cannot be interpreted as a prefix.
Route targets can then be expressed as prefixes, where for instance, Route targets can then be expressed as prefixes, where, for instance,
a prefix would encompass all route target extended communities a prefix would encompass all route target extended communities
assigned by a given Global Administrator [7]. assigned by a given Global Administrator [6].
The default route target can be used to indicate to a peer the The default route target can be used to indicate to a peer the
willingness to receive all VPN route advertisements such as, for willingness to receive all VPN route advertisements such as, for
instance, the case of a route reflector speaking to one of its PE instance, the case of a route reflector speaking to one of its PE
router clients. router clients.
5. Capability Advertisement 5. Capability Advertisement
A BGP speaker that wishes to exchange Route Target membership A BGP speaker that wishes to exchange Route Target membership
information must use the Multiprotocol Extensions Capability Code as information must use the Multiprotocol Extensions Capability Code, as
defined in RFC 2858 [6], to advertise the corresponding (AFI, SAFI) defined in RFC 2858 [5], to advertise the corresponding (AFI, SAFI)
pair. pair.
A BGP speaker MAY participate in the distribution of Route Target A BGP speaker MAY participate in the distribution of Route Target
information while not using the learned information for purposes of information without using the learned information for purposes of VPN
VPN NLRI output route filtering, although the latter is discouraged. NLRI output route filtering, although this is discouraged.
6. Operation 6. Operation
A VPN NLRI route should be advertised to a peer that participates in A VPN NLRI route should be advertised to a peer that participates in
the exchange of Route Target membership information if that peer has the exchange of Route Target membership information if that peer has
advertised either the default Route Target membership NLRI or a Route advertised either the default Route Target membership NLRI or a Route
Target membership NLRI containing any of the targets contained in the Target membership NLRI containing any of the targets contained in the
extended communities attribute of the VPN route in question. extended communities attribute of the VPN route in question.
When a BGP speaker receives a BGP UPDATE that advertises or withdraws When a BGP speaker receives a BGP UPDATE that advertises or withdraws
a given Route Target membership NLRI, it should examine the RIB-OUTs a given Route Target membership NLRI, it should examine the RIB-OUTs
of VPN NLRIs and re-evaluate the advertisement status of routes that of VPN NLRIs and re-evaluate the advertisement status of routes that
match the Route Target in question. match the Route Target in question.
A BGP speaker should generate the minimum set of BGP VPN route A BGP speaker should generate the minimum set of BGP VPN route
updates necessary to transition between the previous and current updates (advertisements and/or withdrawls) necessary to transition
state of the route distribution graph that is derived from Route between the previous and current state of the route distribution
Target membership information. graph that is derived from Route Target membership information.
An an hint that initial RT membership exchange is complete As a hint that initial RT membership exchange is complete,
implementations SHOULD generate an End-of-RIB marker, as defined in implementations SHOULD generate an End-of-RIB marker, as defined in
[8], for the Route Target membership (afi, safi). Regardless of [8], for the Route Target membership (afi, safi), regardless of
whether graceful-restart is enabled on the BGP session. This allows whether graceful-restart is enabled on the BGP session. This allows
the receiver to know when it has received the full contents of the the receiver to know when it has received the full contents of the
peers membership information. The exchange of VPN NLRI should follow peer's membership information. The exchange of VPN NLRI should
the receipt of the End-of-RIB markers. follow the receipt of the End-of-RIB markers.
If a BGP speaker chooses to delay the advertisement of BGP VPN route If a BGP speaker chooses to delay the advertisement of BGP VPN route
updates until it receives this End-of-RIB marker, it MUST limit that updates until it receives this End-of-RIB marker, it MUST limit that
delay to an upper bound. By default, a 60 second value should be delay to an upper bound. By default, a 60 second value should be
used. used.
7. Deployment Considerations 7. Deployment Considerations
This mechanism reduces the scaling requirements that are imposed on This mechanism reduces the scaling requirements that are imposed on
route reflectors by limiting the number of VPN routes and events that route reflectors by limiting the number of VPN routes and events that
a reflector has to process to the VPN routes used by its direct a reflector has to process to the VPN routes used by its direct
clients. By default, a reflector must scale in terms of the total clients. By default, a reflector must scale in terms of the total
number of VPN routes present on the network. number of VPN routes present on the network.
This also means that its is now possible to reduce the load imposed This also means that it is now possible to reduce the load imposed on
on a given reflector by dividing the PE routers present on its a given reflector by dividing the PE routers present on its cluster
cluster into a new set of clusters. This is a localized into a new set of clusters. This is a localized configuration change
configuration change that need not affect any system outside this that need not affect any system outside this cluster.
cluster.
The effectiveness of RT-based filtering depends on how sparse the VPN The effectiveness of RT-based filtering depends on how sparse the VPN
membership is. membership is.
The same policy mechanisms applicable to other NLRIs are also The same policy mechanisms applicable to other NLRIs are also
applicable to RT membership information. This gives a network applicable to RT membership information. This gives a network
operator the option of controlling which VPN routes get advertised in operator the option of controlling which VPN routes get advertised in
an inter-domain border by filtering the acceptable RT membership an inter-domain border by filtering the acceptable RT membership
advertisements inbound. advertisements inbound.
For instance, in the inter-as case, it is likely that a given VPN is For instance, in the inter-as case, it is likely that a given VPN is
connected to only a subset of all participating ASes. The only connected only to a subset of all participating ASes. The only
current mechanism to limit the scope of VPN route flooding is through current mechanism to limit the scope of VPN route flooding is through
manual filtering on the EBGP border routers. With the current manual filtering on the external BGP border routers. With the
proposal such filtering can be performed based on the dynamic Route current proposal, such filtering can be performed according to the
Target membership information. dynamic Route Target membership information.
In some inter-as deployments not all RTs used for a given VPN have In some inter-as deployments, not all RTs used for a given VPN have
external significance. For example, a VPN can use an hub RT and a external significance. For example, a VPN can use a hub RT and a
spoke RT internally to an autonomous-system. The spoke RT does not spoke RT internally to an autonomous-system. The spoke RT does not
have meaning outside this AS and so it may be stripped at an external have meaning outside this AS, so it may be stripped at an external
border router. The same policy rules that result in extended border router. The same policy rules that result in extended
community filtering can be applied to RT membership information in community filtering can be applied to RT membership information in
order to avoid advertising an RT membership NLRI for the spoke-RT in order to avoid advertising an RT membership NLRI for the spoke-RT in
the example above. the example above.
Throughout this document, we assume that autonomous-systems agree on Throughout this document, we assume that autonomous-systems agree on
an RT assignment convention. RT translation at the external border an RT assignment convention. RT translation at the external border
router boundary, is considered to be a local implementation decision, router boundary is considered a local implementation decision, as it
as it should not affect inter-operability. should not affect inter-operability.
8. Security Considerations 8. Security Considerations
This document does not alter the security properties of BGP-based This document does not alter the security properties of BGP-based
VPNs. However it should be taken into consideration that output VPNs. However, note that output route filters built from RT
route filters built from RT membership information NLRI are not membership information NLRIs are not intended for security purposes.
intended for security purposes. When exchanging routing information When exchanging routing information between separate administrative
between separate administrative domains, it is a good practice to domains, it is a good practice to filter all incoming and outgoing
filter all incoming and outgoing NLRIs by some other means in NLRIs by some other means in addition to RT membership information.
addition to RT membership information. Implementations SHOULD also Implementations SHOULD also provide means to filter RT membership
provide means to filter RT membership information. information.
9. Acknowledgments 9. Acknowledgements
This proposal is based on the extended community route filtering This proposal is based on the extended community route filtering
mechanism defined in [4]. mechanism defined in [7].
Ahmed Guetari was instrumental in defining requirements for this Ahmed Guetari was instrumental in defining requirements for this
proposal. proposal.
The authors would also like to thank Yakov Rekhter, Dan Tappan, Dave The authors would also like to thank Yakov Rekhter, Dan Tappan, Dave
Ward, John Scudder, and Jerry Ash for their comments and suggestions. Ward, John Scudder, and Jerry Ash for their comments and suggestions.
10. References 10. References
10.1 Normative References 10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An [2] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An
Alternative to Full Mesh IBGP", RFC 2796, April 2000. Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April
2006.
[3] Rosen, E., "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-03
(work in progress), October 2004.
[4] Chen, E. and Y. Rekhter, "Cooperative Route Filtering Capability [3] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
for BGP-4", draft-ietf-idr-route-filter-11 (work in progress), (VPNs)", RFC 4364, February 2006.
December 2004.
[5] Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)", [4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4
draft-ietf-idr-bgp4-26 (work in progress), October 2004. (BGP-4)", RFC 4271, January 2006.
[6] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol [5] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol
Extensions for BGP-4", RFC 2858, June 2000. Extensions for BGP-4", RFC 2858, June 2000.
[7] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [6] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", draft-ietf-idr-bgp-ext-communities-08 Communities Attribute", RFC 4360, February 2006.
(work in progress), February 2005.
10.2. Informative References
[7] Chen, E. and Y. Rekhter, "Cooperative Route Filtering Capability
for BGP-4", Work in Progress, December 2004.
[8] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J., and E. Chen, [8] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J., and E. Chen,
"Graceful Restart Mechanism for BGP", draft-ietf-idr-restart-10 "Graceful Restart Mechanism for BGP", Work in Progress, June
(work in progress), June 2004. 2004.
10.2 Informative References [9] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service", Work
in Progress, April 2005.
[9] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service", [10] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
draft-ietf-l2vpn-vpls-bgp-05 (work in progress), April 2005. Private Network (VPN) Terminology", RFC 4026, March 2005.
Authors' Addresses Authors' Addresses
Pedro Marques Pedro Marques
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: roque@juniper.net EMail: roque@juniper.net
Ronald Bonica Ronald Bonica
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: rbonica@juniper.net EMail: rbonica@juniper.net
Luyuan Fang Luyuan Fang
AT&T Cisco Systems, Inc.
200 Laurel Avenue, Room C2-3B35 300 Beaver Brook Road
Middletown, NJ 07748 Boxborough, MA 01719
US US
Email: luyuanfang@att.com EMail: lufang@cisco.com
Luca Martini Luca Martini
Cisco Systems, Inc. Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400 9155 East Nichols Avenue, Suite 400
Englewood, CO 80112 Englewood, CO 80112
US US
Email: lmartini@cisco.com EMail: lmartini@cisco.com
Robert Raszuk Robert Raszuk
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Dr 170 West Tasman Dr
San Jose, CA 95134 San Jose, CA 95134
US US
Email: rraszuk@cisco.com EMail: rraszuk@cisco.com
Keyur Patel Keyur Patel
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Dr 170 West Tasman Dr
San Jose, CA 95134 San Jose, CA 95134
US US
Email: keyupate@cisco.com EMail: keyupate@cisco.com
Jim Guichard Jim Guichard
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
US US
Email: jguichar@cisco.com EMail: jguichar@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 19, line 29 skipping to change at page 14, line 46
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 78 change blocks. 
237 lines changed or deleted 270 lines changed or added

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