One document matched: draft-dong-idr-vpn-route-constrain-02.txt
Differences from draft-dong-idr-vpn-route-constrain-01.txt
Network working group J. Dong
Internet Draft M. Chen
Intended status: Standards Track G. Liu
Expires: March 2011 H. Ni
Huawei Technologies
Z. Li
China Mobile
September 27, 2010
Constrained Route Distribution for BGP based Virtual Private Networks
(VPNs)
draft-dong-idr-vpn-route-constrain-02.txt
Abstract
There are some problems with current RT-Constrain mechanism defined
in RFC 4684. Firstly, the IPv6 address specific Route Target defined
in [RFC5701] cannot be accommodated in current RT membership NLRI.
Secondly, the distribution of RT-Constrain information cannot build
correct VPN distribution graph when hierarchical route reflection (RR)
is used. Thirdly, current RT-Constrain mechanism is used for
filtering of all kinds of VPN services and can result in imprecise
VPN route distribution when multiple VPN services are deployed in the
network.
This document describes the above problems in detail and proposes
solutions for these problems. A generalized RT-Constrain mechanism is
defined to accommodate the IPv6 address specific Route Target and to
precisely control propagation of different kinds of VPN routing
information. The proposed solution avoids unnecessary advertising and
receiving of VPN routes when multiple VPN services are deployed. This
document also proposes modifications of advertisement rules of RT-
Constrain information to ensure the integrity of VPN distribution
graph.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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
Dong, et al. Expires March 27, 2011 [Page 1]
Internet-Draft BGP Based VPN Route Constrain September 2010
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 27, 2011.
Copyright Notice
Copyright (c) 2010 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 ................................................. 3
1.1. Terminologies ........................................... 3
2. Conventions used in this document ............................ 4
3. Use of Route Target .......................................... 4
4. IPv6 address specific Route Target ........................... 5
5. Problems with Hierarchical Route Reflection .................. 5
5.1. Modification of Advertisement Rules for Intra-AS scenario 7
6. Problems of Route Constraint with Multiple VPNs Services ..... 7
6.1. IPv4 L3VPN and IPv6 L3VPN ............................... 8
6.2. L3VPN and L2VPN ......................................... 9
6.3. Unicast VPN and Multicast VPN .......................... 10
6.4. Multiple L2VPN Services ................................ 11
7. Solutions for Route Constraint of Multiple VPN Services ..... 12
7.1. Unique RT Assignment ................................... 12
7.2. Generalized RT Constrain ............................... 12
7.2.1. Proposed Format of Generalized RT Membership NLRI . 13
8. Capability Advertisement .................................... 14
9. Compatibility Considerations ................................ 14
Dong, et al. Expires March 27, 2011 [Page 2]
Internet-Draft BGP Based VPN Route Constrain September 2010
10. Security Considerations .................................... 15
11. IANA Considerations......................................... 15
12. Acknowledgements ........................................... 15
13. References ................................................. 15
13.1. Normative References .................................. 15
13.2. Informative References ................................ 16
Appendix A. Use of Route Target in Single Type of VPN Service .. 16
Authors' Addresses ............................................. 20
1. Introduction
BGP [RFC4271] has been widely used in many kinds of Virtual Private
Networks (VPNs) for exchanging routes and auto discovery information.
Route Target (RT) extended communities defined in [RFC4360] are used
to control the distribution of received information into VPN
instances.
[RFC4684] defines procedures to restrict the distribution of VPN
routes. It defines a new MP-BGP NLRI with [AFI=1, SAFI=132] for
carrying RT membership information, which can be used to control the
propagation of VPN routes. This mechanism can be used for the
filtering for all kinds of VPN services.
However, there are some problems with current RT-Constrain mechanism
defined in RFC 4684. Firstly, the IPv6 address specific Route Target
defined in [RFC5701] cannot be accommodated in current RT membership
NLRI. Secondly, based on the attribute processing rules in section
3.2 of [RFC4684], the distribution of RT-Constrain information cannot
build correct VPN distribution graph when hierarchical route
reflection (RR) is used. Thirdly, current RT-Constrain mechanism is
used for filtering of all kinds of VPN services which can result in
imprecise VPN route distribution when multiple VPN services are
deployed in the network.
This document describes the use of RT for VPNs, specifies the above
problems in detail and proposes solutions to solve these problems. A
generalized RT-Constrain mechanism is defined to accommodate the IPv6
address specific RT and to precisely control the propagation of
different kinds of VPN routing information. This method avoids
unnecessary advertising and receiving of VPN routes when multiple VPN
services are deployed. This document also proposes modifications of
advertisement rules of RT-constrain information to ensure the
integrity of VPN distribution graph.
1.1. Terminologies
Terms and acronyms specific to BGP and VPNs are listed below:
Dong, et al. Expires March 27, 2011 [Page 3]
Internet-Draft BGP Based VPN Route Constrain September 2010
AFI Address Family Identifier
CE Customer Edge
L2VPN Layer 2 Virtual Private Network
L3VPN Layer 3 Virtual Private Network
MVPN Multicast L3VPN
NLRI Network Layer Reachability Information
PE Provider Edge
RT Route Target
SAFI Subsequent Address Family Identifier
VPLS Virtual Private LAN Service
VPN Virtual Private Network
VRF VPN Routing and Forwarding table
VSI Virtual Switching Instance
2. Conventions used in this document
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 [RFC2119].
3. Use of Route Target
The Route Target (RT) extended communities defined in [RFC4360] is
used for controlling the distribution of VPN routes. The use of RT in
each kind of VPN has been specified respectively in [RFC4364],
[RFC4659], [RFC4761], [RFC5195], [MVPN-BGP], [L2VPN-BGP], [VPLS-
MCAST], [L2VPN-SIG] and [VPMS-BGP]. The Appendix section extracts the
specifications about RT in these RFCs and drafts.
Currently there is no specification on RT assignment among different
kinds of VPNs. According to the procedures of BGP based VPN,
different kinds of VPNs are isolated using different AFI/SAFIs, which
allows the RT assignment in different kinds of VPNs to be performed
independently, i.e. the RT assignment in one kind of VPN has no
Dong, et al. Expires March 27, 2011 [Page 4]
Internet-Draft BGP Based VPN Route Constrain September 2010
impact on the RT assignment and route distribution of another kind of
VPN.
In some scenarios such as network migration and deployment of new VPN
services, in order to reduce manual configuration and the complexity
in network management, operators MAY prefer to use the same RT for
different kinds of VPN services. One case is to use the same RT for
IPv4 and IPv6 VPNs.
4. IPv6 Address Specific Route Target
[RFC5701] has defined IPv6 address specific Route Target with the
length of 20 octets. However, the format of RT membership NLRI in RFC
4684 contains a Route Target field of only 8 octets, thus the format
of RT membership NLRI is not applicable when IPv6 address specific
Route Target is used. From this point of view, an update to the
format of RT-membership NLRI is needed.
In order to solve this problem, this document proposes to change the
length of Route Target field in RT membership NLRI to "variable".
Thus the NLRI format is compatible with IPv6 address specific Route
Target and other potential RT types which may be defined in future.
Since the RT membership NLRI is encoded as defined in section 4 of
RFC 2858 (obsoleted by [RFC4760]), thus the length field in RT
membership NLRI can be used to calculate the length of Route Target.
In order to make this extension and other further extensions in this
document backward compatible with RFC 4684, a new SAFI is defined.
Details about this new SAFI are specified in section 7.
5. Problems with Hierarchical Route Reflection
For Intra-AS scenarios, section 3.2 of RFC 4684 proposes some
modification to the path attribute calculation in advertisement of RT
membership NLRI. These rules are used to guarantee the correct
propagation of RT membership NLRI:
i. When advertising RT membership NLRI to a route-reflector
client, the Originator attribute shall be set to the router-id of the
advertiser, and the Next-hop attribute shall be set of the local
address for that session.
ii. When advertising an RT membership NLRI to a non-client peer,
if the best path as selected by the path selection procedure
described in Section 9.1 of the base BGP specification [4] is a route
received from a non-client peer, and if there is an alternative path
to the same destination from a client, the attributes of the client
path are advertised to the peer.
Dong, et al. Expires March 27, 2011 [Page 5]
Internet-Draft BGP Based VPN Route Constrain September 2010
However, these procedures are not sufficient when hierarchical RRs
are used.
+---------------------------------+
| +----+ |
| Clu-1 |RR-1| |
| /+----+\ |
| / \ |
| +----+ +----+ |
| Clu-2 |RR-2| |RR-3| Clu-3 |
| +-/--+ +/--\+ |
| / / \ |
| +----+ +----+ +----+ |
| |PE-1| |PE-2| |PE-3| |
| +----+ +----+ +----+ |
| | | | |
+-------|----------|---------|----+
RT-1 | RT-1 | | RT-1
+--------+ +--------+ +--------+
| VPN-1 | | VPN-1 | | VPN-1 |
| | | | | |
+--------+ +--------+ +--------+
Figure 4.
As shown in Figure 4, hierarchical RR are deployed in the network,
RR-2 and RR-3 are clients of RR-1. Each PE advertises RT membership
information of RT-1 to the upstream RR. After the best path selection,
both RR-2 and RR-3 would create the CLUSTER_LIST attribute and
prepend their local CLUSTER_ID and then advertise the best path to
RR-1 and the downstream PEs respectively.
RR-1 will select one of the received RT-Constrain NLRI path as the
best path, say the path from RR-2. Then RR-1 needs to advertise the
best path to both RR-2 and RR-3 to create distribution graph of VPN-1.
RR-1 would prepend its CLUSTER_ID to the CLUSTER_LIST of the path,
and according to the procedure i of Section 3.2 in [RFC4684], it
SHOULD set the ORIGINATOR_ID to its router-id, and the NEXT_HOP to
the local address for the session. Then RR-1 would advertise this
route to both RR-2 and RR-3.
On receipt of the RT-Constrain route from RR-1, RR-2 would check the
CLUSTER_LIST and its own CLUSTER_ID is found in the list, so this
route will be ignored. Thus RR-2 will not form outbound filter of RT-
1 towards RR-1, which would impact the integrity of distribution
graph of VPN-1.
Dong, et al. Expires March 27, 2011 [Page 6]
Internet-Draft BGP Based VPN Route Constrain September 2010
Besides, based on rule i, the Originator and Next-hop attributes are
modified when advertising RT membership NLRI to the client, this may
affect the best path selection results on the client and can result
in unnecessary route oscillation especially when the client itself is
a lower layer RR.
5.1. Modification of Advertisement Rules for Intra-AS scenario
In order to avoid the problem described above, this section proposes
to modify the route advertisement rules when advertising Route Target
membership information sourced by the local autonomous system to an
iBGP peer. The rule i of section 3.2 of RFC 4684 SHOULD be replaced
with the following statement:
i. When advertising a RT membership NLRI to a route-reflector
client, if the best path as selected by the path selection procedure
described in Section 9.1 of the base BGP specification [4] is the
route received from this client, and the route does not carry
CLUSTER_LIST attribute, then if there is an alternative path from
another peer, the attributes of the alternative path are advertised
to that client; if the best path carries a CLUSTER_LIST and is
received from the same cluster as the client, then if there is an
alternative path to the same destination from another peer in a
different cluster, the attributes of the alternative path are
advertised to that client.
This route advertisement rule avoids advertising the best path back
to the advertiser of that path, and also avoids advertising the path
which was received from the same cluster of the peer, thus avoids the
discarding of RT-Constrain information due to loop detection. This
rule can also avoid possible route oscillation of RT membership NLRI.
6. Problems of Route Constraint with Multiple VPNs Services
Service Provider (SP) may deploy more than one kind of VPNs in the
same network. For example, both IPv4 and IPv6 L3VPNs, both L3VPN and
L2VPN, both unicast VPN and multicast VPN, or different types of
L2VPNs (VPLS, VPMS, Ethernet VPN, etc.) may be deployed in the same
network. It is reasonable for SPs to design, deploy and maintain
these different VPN services independently. Thus the RT assignment in
each VPN service should be performed independently. In addition, in
scenarios of inter-provider VPNs, it would be a complicated task to
coordinate the RT assignment in different kinds of VPN services
between different service providers. This burden can be relieved by
allocating RTs independently for different types of VPN services. In
this case, the same RT may be used by different types of VPNs. And in
some other cases like network migration, the SPs may prefer to use
Dong, et al. Expires March 27, 2011 [Page 7]
Internet-Draft BGP Based VPN Route Constrain September 2010
the same RT for different types of VPN services for management
simplicity.
Since current RT-Constrain mechanism is used for filtering of all
kinds of VPN services, it cannot work precisely in networks with
multiple kinds of VPNs. The RT membership NLRI cannot tell which kind
of VPN route (address family/subsequent address family) is requested.
Thus in some scenarios, the current RT-Constrain is not sufficient to
provide precise control for VPN route distribution, which result in
unnecessary advertising and receiving of undesired VPN routes.
Detailed analyses are given in sections below.
6.1. IPv4 L3VPN and IPv6 L3VPN
Some service providers need to deploy both IPv4 L3VPN (VPNv4) and
IPv6 L3VPN (VPNv6) in their network. During the migration from IPv4
to IPv6, for less manual configuration and management simplicity the
RTs used for VPNv6 can be the same as the ones for VPNv4. However,
it's likely that not all the VPN sites are both IPv4 and IPv6 capable,
some of them may be only IPv4 capable, some other ones may support
both IPv4 and IPv6, and the others may only recognize IPv6 packets.
In Figure 1, suppose the VPN site of VPN-1 connected to PE-1 is only
IPv4 capable, the sites of VPN-1 connected to PE-2 and PE-3 are IPv6
capable. Using procedures of RFC 4684, PE-1 advertises the RT
membership information containing RT-1 to the other PEs. According to
the received RT membership NLRI, PE-2 and PE-3 will advertise VPNv6
routes of VPN-1 to PE-1. As a result, PE-1 will receive undesired
VPNv6 routes of VPN-1. Similarly, PE-1 will receive undesired VPNv4
routes of VPN-2, PE-3 will receive undesired VPNv4 routes of VPN-1.
Dong, et al. Expires March 27, 2011 [Page 8]
Internet-Draft BGP Based VPN Route Constrain September 2010
+------------+ +------------+
| VPN-1 | | VPN-2 |
| | | |
| IPv4 | | IPv6 |
+------------+ +------------+
RT-1 \ / RT-2
+----------\------/----------+
| +----+ |
| Backbone |PE-1| |
| +----+ |
| | |
| +----+ |
| | RR | |
| /+----+\ |
| / \ |
| +----+ +----+ | +------------+
| |PE-2| |PE-3|----|------| VPN-2 |
| +----+ +----+ | RT-2 | |
+----/---------------|-------+ |IPv4 & IPv6 |
RT-1 / | RT-1 +------------+
+------------+ +------------+
| VPN-1 | | VPN-1 |
| | | |
|IPv4 & IPv6 | | IPv6 |
+------------+ +------------+
Figure 1.
Even if RTs allocated for VPNv6 are different from the ones used for
VPNv4 on each PE, if there is some overlapping between the RT space
of VPNv4 and VPNv6 in the network, some PEs may also receive
undesired VPN routes of other VPNs.
6.2. L3VPN and L2VPN
The mechanisms defined in RFC 4684 are claimed to be applicable for
L2VPNs which use Route Targets to control distribution of routing
information. However, if both L3VPN and L2VPN are deployed in the
same network, the mechanisms defined in RFC 4684 are not sufficient
to achieve precise control of route distribution.
If there is some overlapping between the RTs used in L3VPNs and
L2VPNs in the network, PEs may receive undesired VPN routes of
another kind of VPN service.
For example, in Figure 2, RT-1 is used by PE-1 and PE-4 for L2VPN-1,
and is also used by PE-2 and PE-3 for L3VPN-3. If PE-1 and PE-4
advertise RT membership information of RT-1 to other PEs in the
Dong, et al. Expires March 27, 2011 [Page 9]
Internet-Draft BGP Based VPN Route Constrain September 2010
network, subsequently PE-2 and PE-3 would advertise undesired L3VPN
routes to PE-1 and PE-4.
+------------+ +------------+ +------------+
| VPN-1 | | VPN-2 | | VPN-3 |
| | | | | |
| L2VPN | | L3VPN | | L3VPN |
+------------+ +------------+ +------------+
RT-1 \ | RT-2 / RT-1
+---\--|----------------/----+
| +----+ +----+/ |
| |PE-1| |PE-2| |
| +----+ +----+ |
| \ / |
| \+----+/ |
| Backbone | RR | |
| /+----+\ |
| / \ |
| +----+ +----+ | +------------+
| |PE-3| |PE-4|-----------| VPN-2 |
| +----+ +----+ | RT-2 | |
+----/---------------|-------+ | L3VPN |
RT-1 / | RT-1 +------------+
+------------+ +------------+
| VPN-3 | | VPN-1 |
| | | |
| L3VPN | | L2VPN |
+------------+ +------------+
Figure 2.
6.3. Unicast VPN and Multicast VPN
Multicast L3VPN [MVPN, MVPN-BGP] and VPLS multicast [VPLS-MCAST] have
defined new SAFIs for exchanging multicast routing information, and
RTs are used in these scenarios to control distribution of multiple
types of multicast routing information.
Since MVPN is deployed on the basis of unicast VPN, they are always
coexistent in the same network.
As [MVPN-BGP] says, by default the distribution of Intra-AS I-PMSI A-
D route is controlled by the same Route Targets as the ones used for
the distribution of VPN-IP unicast routes. Thus PE advertising RT
membership NLRI may receive undesired routing information, i.e., PE
wants to receive only unicast VPN routes corresponding to the RT may
also receive undesired multicast routing information.
Dong, et al. Expires March 27, 2011 [Page 10]
Internet-Draft BGP Based VPN Route Constrain September 2010
In Figure 3, suppose the site of VPN-1 connected to PE-1 only support
IP unicast, the sites of VPN-1 connected to PE-2 and PE-3 support IP
multicast. Using the mechanisms defined in [RFC4684], PE-1 will
advertise the RT membership information containing RT-1 to the other
PEs. According to the received RT membership information, PE-2 and
PE-3 will advertise multicast routes of VPN-1 to PE-1. As a result,
PE-1 will receive undesired multicast routes of VPN-1.
+------------+ +------------+
| VPN-1 | | VPN-2 |
| | | |
| Unicast | | Multicast |
+------------+ +------------+
RT-1 \ / RT-2
+----------\------/----------+
| +----+ |
| |PE-1| |
| +----+ |
| Backbone | |
| +----+ |
| | RR | |
| /+----+\ |
| / \ |
| +----+ +----+ | +------------+
| |PE-2| |PE-3|-----------| VPN-2 |
| +----+ +----+ | RT-2 | |
+----/---------------|-------+ | Unicast |
RT-1 / | RT-1 +------------+
+------------+ +------------+
| VPN-1 | | VPN-1 |
| | | |
| Multicast | | Multicast |
+------------+ +------------+
Figure 3.
Even if RTs allocated for MVPNs are different from the ones used for
unicast VPNs on each PE, if there is some overlapping between the RT
space of MVPNs and unicast VPNs in the network, some PEs may also
receive undesired VPN routes of other VPNs.
6.4. Multiple L2VPN Services
Currently there are a number of different types of L2VPN services,
such as VPLS, VPMS, Ethernet VPN etc., and different SAFIs have been
defined (or will be defined) for different Layer 2 VPN information.
All of these services use Route Target to control the distribution of
auto-discovery and routing information. When multiple L2VPN
Dong, et al. Expires March 27, 2011 [Page 11]
Internet-Draft BGP Based VPN Route Constrain September 2010
applications are deployed in the same network, if there are some
overlapping between the RT spaces of those different services, some
PEs may receive undesired VPN routes.
7. Solutions for Route Constraint of Multiple VPN Services
7.1. Unique RT Assignment
One straightforward solution to avoid receiving undesired VPN routes
with the use of RFC 4684 is to assign different RTs in different
kinds of VPNs.
One possible way is to pre-allocate disjoint RT ranges for different
kinds of VPN services, such as allocate RT-1 to RT-X for IPv4 VPN,
and RT-(X+1) to RT-Y for IPv6 VPN, RT-(Y+1) to RT-Z for L2VPN, etc.
This requires well planning of RT space for different kinds of VPNs
before the deployment of any VPN service. Since usually the VPN
services are not developed, designed and deployed simultaneously,
this solution seems not quite practical.
Another scheme is to make sure each RT is only used in one kind of
VPN service, e.g. if RT-X is used in IPv4 VPN, it cannot be used in
any other kind of VPN. This does not require pre-allocated disjoint
RT space for each VPN service, but operators has to assign RTs very
carefully to make sure that each RT is only used in one kind of VPN.
This brings additional planning and management burdens to operators
during the deployment of new VPN services.
As described in previous sections, in some cases the operators may
prefer to use the same RT for different kinds of VPN services, such
as IPv4 and IPv6 L3VPNs, or unicast and multicast VPNs. The unique RT
assignment can not work in these scenarios.
In the case of inter-provider VPNs, different providers need to
cooperate on the choice of RTs, which makes it more difficult to
select proper RTs for inter-provider VPNs based on the above
solutions.
7.2. Generalized RT Constrain
This section proposes a solution which could totally eliminate the
restriction on RT assignment among different kinds of VPN services,
thus keeps the management of RTs in one kind of VPN service
independent of the other kinds of VPNs. This will relieve operators'
burden on planning and management of different VPN applications.
Dong, et al. Expires March 27, 2011 [Page 12]
Internet-Draft BGP Based VPN Route Constrain September 2010
This solution provides mechanisms to achieve AFI/SAFI specific VPN
route filtering, which could precisely control the route distribution
of different kinds of BGP based VPN services. In addition, this
solution also provides mechanisms to accommodate IPv6 address
specific RT defined in [RFC5701].
In order to identify corresponding AFI of VPN routes that the RT
membership NLRI stands for, this document proposes to extend the AFI
value of RT membership NLRI. The AFI of this NLRI SHOULD be one of
the AFIs that use Route Target to control route distribution. This
document defines a new SAFI called Generalized Route Target
Membership. A new SAFI value needs to be assigned by IANA. Thus the
[AFI, SAFI] value pair of the Generalized RT Membership NLRI could be
[AFI=1, SAFI=TBA] for IPv4 L3VPN, and [AFI=2, SAFI=TBA] for IPv6
L3VPN, and [AFI=25, SAFI=TBA] for L2VPN, etc. Since currently there
is no fixed AFI value for L1VPN, a new AFI value MAY need to be
allocated by IANA, and the [AFI=TBD, SAFI=TBA] value pair represents
the Generalized RT membership NLRI of L1VPN.
In order to differentiate the filtering for VPN services with the
same AFI but different SAFIs (e.g. different kinds of L2VPN services,
unicast L3VPN and MVPN), the Generalized RT membership NLRI MUST
contain the SAFI information of the VPN routes being requested. Thus
the Generalized RT membership NLRI can be accurately identified as RT
information of one particular type of VPN. Besides, if L1VPN and
other kinds of VPNs are deployed in the same network, and no fixed
AFI value has been allocated for L1VPN, the SAFI value of L1VPN can
be used to identify RT membership information of L1VPN.
7.2.1. Proposed Format of Generalized RT Membership NLRI
The format of Generalized RT membership NLRI is structured as follows:
+-------------------------------+
| Length (1 octet) |
+-------------------------------+
| Origin AS (4 octets) |
+-------------------------------+
| SAFI of VPN (1 octet) |
+-------------------------------+
| |
~ Route Target (variable) ~
| |
+-------------------------------+
Dong, et al. Expires March 27, 2011 [Page 13]
Internet-Draft BGP Based VPN Route Constrain September 2010
The Length field is used to identify the total length of the rest
fields. [Author notes: Though this field is defined as "the length in
bits" in [RFC4760], it is RECOMMENDED that it represents the length
in octets of the rest fields as in [RFC4761] for convenience.]
The Origin AS field contains an Autonomous System number. Two octets
AS numbers are encoded in the two low order octets of the Origin AS
field, with the two high order octets set to zero.
The "SAFI of VPN" field is the SAFI value of the VPN routes the PE
intends to import using the Route Target below.
The Route Target field contains Route Target of VPN routes being
requested. Note the length of the Route Target field is variable, and
can be calculated using the Length field of this NLRI.
8. Capability Advertisement
In order for two BGP speakers to exchange Generalized RT membership
NLRI, they MUST use BGP Capabilities Advertisement to ensure that
they both are capable of properly processing such NLRI. This is done
as specified in [RFC4760], by using capability code 1 (multiprotocol
BGP) with an AFI of the corresponding VPN and a SAFI of Generalized
RT-Constrain (TBA).
9. Compatibility Considerations
The mechanism defined in this document is compatible with RT-
constrain in [RFC4684], which is achieved by capability negotiation
of different AFI/SAFIs.
Multiprotocol Extension Capability of AFI/SAFI pair 1/132 can be
regarded as common RT-constrain information applicable to all types
of VPNs (though in this case IPv6 address specific RT is not
applicable). When peering with legacy BGP speakers, only AFI/SAFI
1/132 is negotiated for RT-Constrain. When peering with BGP speakers
which support these extensions in this document, AFI/SAFI 1/132 can
also be used if address family specific filtering is not needed. When
it is needed to precisely control the route distribution of some
specific VPN types, this can be achieved by using Generalized RT-
Constrain mechanism with further capability negotiation of specific
AFI and SAFI of Generalized RT-Constrain (TBA). If the capability of
Generalized RT-Constrain for specific address family is successfully
negotiated, then for this address family the Generalized RT
membership information MUST override the RT information of AFI/SAFI
1/132.
Dong, et al. Expires March 27, 2011 [Page 14]
Internet-Draft BGP Based VPN Route Constrain September 2010
10. Security Considerations
This document does not change the security properties of BGP based
VPNs and RFC 4684.
11. IANA Considerations
IANA needs to assign a SAFI value for Generalized Route Target
Membership. This code point will come from the "Subsequent Address
Family Identifiers" registry.
IANA MAY assign an AFI number for L1VPN. This code point will come
from the "Address Family Numbers" registry.
12. Acknowledgements
The authors would like to thank John Scudder, Rajiv Asati, Keyur
Patel and Robert Raszuk for their valuable comments. Many thanks to
Qing Zeng, Yaqun Xiao for valuable discussion about hierarchical
route reflection scenario.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4360] Sangli, S., Tappan, D. and Rekhter, Y., "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[RFC4364] Rosen, E. and Rekhter, Y., "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M. and Le Faucheur, F.,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, September 2006.
[RFC4684] Marques, P. et. al, "Constrained Route Distribution for
Border Gateway Protocol/MultiProtocol Label Switching
(BGP/MPLS) Internet Protocol (IP) Virtual Private Networks
(VPNs)", RFC 4684, November 2006.
Dong, et al. Expires March 27, 2011 [Page 15]
Internet-Draft BGP Based VPN Route Constrain September 2010
[RFC4760] Bates, T., Chandra, R., Katz, D., Rekhter, Y.,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
[RFC4761] Kompella, K., Rekhter, Y., "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC
4761, January 2007.
[RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended
Communities Attribute", RFC 5701, November 2009.
[MVPN-BGP] Aggarwal, R., Rosen, E., Morin, T., Rekhter, Y., "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP VPNs",
work in progress.
13.2. Informative References
[RFC5195] Ould-Brahim, H., Fedyk, D. and Rekhter, Y., "BGP-Based
Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
[L2VPN-BGP] Kompella, K., Kothari, B. and Cherukuri, R., "Layer 2
Virtual Private Networks Using BGP for Auto-discovery and
signaling", work in progress.
[L2VPN-SIG] Rosen, E., Luo, W., Davie, B., Radoaca, V., "Provisioning,
Autodiscovery, and Signaling in L2VPNs", work in progress.
[MVPN] Rosen, E., Aggarwal, R., "Multicast in MPLS/BGP IP VPNs", work
in progress
[VPLS-MCAST] Aggarwal, R., Kamite, Y., Fang, L., "Multicast in VPLS",
work in progress.
[VPMS-BGP] Aggarwal, R., Kamite, Y., Jounay, F., "BGP based Virtual
Private Multicast Service Auto-Discovery and Signaling",
work in progress.
Appendix A. Use of Route Target in Single Type of VPN Service
The use of Route Target for single kind of VPN has been specified in
some IETF documents.
[RFC4364] specifies the use of RT in IPv4 VPNs:
Dong, et al. Expires March 27, 2011 [Page 16]
Internet-Draft BGP Based VPN Route Constrain September 2010
A Route Target attribute can be thought of as identifying a set of
sites. (Though it would be more precise to think of it as
identifying a set of VRFs.) Associating a particular Route Target
attribute with a route allows that route to be placed in the VRFs
that are used for routing traffic that is received from the
corresponding sites.
Suppose it is desired to create a fully meshed closed user group,
i.e., a set of sites where each can send traffic directly to the
other, but traffic cannot be sent to or received from other sites.
Then each site is associated with a VRF, a single Route Target
attribute is chosen, that Route Target is assigned to each VRF as
both the Import Target and the Export Target, and that Route Target
is not assigned to any other VRFs as either the Import Target or
the Export Target.
Alternatively, suppose one desired, for whatever reason, to create
a "hub and spoke" kind of VPN. This could be done by the use of
two Route Target values, one meaning "Hub" and one meaning "Spoke".
At the VRFs attached to the hub sites, "Hub" is the Export Target
and "Spoke" is the Import Target. At the VRFs attached to the
spoke site, "Hub" is the Import Target and "Spoke" is the Export
Target.
[RFC4659] states the use of Route Target in IPv6 VPNs:
The use of route target is specified in [BGP/MPLS-VPN] and applies
to IPv6 VPNs. Encoding of the extended community attribute is
defined in [BGP-EXTCOM].
[RFC4761] describes the use of Route Target in VPLS:
The semantics of the use of Route Targets is described in [RFC4364];
their use in VPLS is identical.
As it has been assumed that VPLSs are fully meshed, a single Route
Target RT suffices for a given VPLS V, and in effect that RT is the
identifier for VPLS V.
[RFC5195] states the use of Route Target in L1VPN auto-discovery:
To restrict the flow of this information to only the PITs within a
given L1VPN, we use BGP route filtering based on the Route Target
Extended Community [BGP-COMM], as follows.
Each PIT on a PE is configured with one or more Route Target
Communities, called "export Route Targets", that are used for
Dong, et al. Expires March 27, 2011 [Page 17]
Internet-Draft BGP Based VPN Route Constrain September 2010
tagging the local information when it is exported into the
provider's BGP. The granularity of such tagging could be as fine as
a single <CPI, PPI> pair. In addition, each PIT on a PE is
configured (at provisioning time) with one or more Route Target
Communities, called "import Route Targets", that restrict the set
of routes that could be imported from provider's BGP into the PIT
to only the routes that have at least one of these Communities.
[MVPN-BGP] specifies the use of RT in Multicast IP VPNs:
To support MVPN in addition to the import/export Route Target(s)
extended communities used by the unicast routing, each VRF on a PE
MUST have an import Route Target extended community, except if it
is known a priori that none of the (local) MVPN sites associated
with the VRF contain multicast source(s) and/or C-RP, in which case
the VRF need not have this import Route Target.
We refer to this Route Target as the "C-multicast Import RT", as
this Route Target controls imports of C-multicast routes into a
particular VRF.
By default the distribution of the Intra-AS I-PMSI A-D routes is
controlled by the same Route Targets as the ones used for the
distribution of VPN-IP unicast routes... The default could be
modified via configuration by having a set of Route Targets used
for the Intra-AS I-PMSI A-D routes being distinct from the ones
used for the VPN-IP unicast routes.
An ASBR MUST be configured with a set of (import) Route Targets
(RTs) that specifies the set of MVPNs supported by the ASBR. These
Route Targets control acceptance of Intra-AS/Inter-AS I-PMSI A-D
routes by the ASBR. As long as unicast and multicast connectivity
are congruent, this could be the same set of Route Targets as the
one used for supporting unicast (and therefore would not require
any additional configuration above and beyond of what is required
for unicast).
The ASBR MUST be (auto-)configured with an import Route Target
called "ASBR Import RT". ASBR Import RT controls acceptance of Leaf
A-D routes and C-multicast routes by the ASBR, and is used to
constrain distribution of both Leaf A-D routes and C-multicast
routes.
[L2VPN-BGP] uses Route Target to define the topology of L2VPN:
Dong, et al. Expires March 27, 2011 [Page 18]
Internet-Draft BGP Based VPN Route Constrain September 2010
Each PE is configured with the VPNs in which it participates. Each
VPN is associated with one or more Route Target communities
[RFC4360] which serve to define the topology of the VPN.
[L2VPN-SIG] specifies the coordination in RT assignment between
different operators in inter-provider L2VPN scenarios.
The main challenge is that it is necessary for the operator of one
AS to know what RT or RTs have been chosen in another AS for any
VPN that has sites in both ASes. As in layer 3 VPNs, there are many
ways to make this work, but all require some co-operation among the
providers.
[VPLS-MCAST] describes the use of RT for VPLS Multicast in a similar
way to mechanisms defined in [MVPN-BGP].
[VPMS-BGP] describes the use of RT in VPMS service in section 5 "VPMS
Auto-Discovery":
This document reuses the procedures described in [VPLS-MCAST] for
auto-discovery with modifications described in this document.
The BGP A-D route MUST carry the set of Route Targets being
exported by the VPMS instance.
As described in the section "Layer 2 Multicast VPN" the information
about whether a CE belongs to a sender site or a receiver site is
determined from the Route Targets (RT) that are configured to
enforce the administrative policies of a L2 MVPN. These RTs are
advertised in the corresponding BGP A-D routes. For instance if
some of the sites in a VPMS are only in sender site set while
others are only in receiver sites set, then CEs that are in the
receiver site set are configured to import only sender site set RTs.
While CEs that are in the sender site set are configured to import
only the receiver site set RTs. In this case two RTs are required
to provision the VPMS instance.
Dong, et al. Expires March 27, 2011 [Page 19]
Internet-Draft BGP Based VPN Route Constrain September 2010
Authors' Addresses
Jie Dong
Huawei Technologies Co.,Ltd.
Huawei Building, No.3 Xinxi Rd.,
Hai-Dian District
Beijing, 100085
P.R. China
EMail: dongjie_dj@huawei.com
Mach(Guoyi) Chen
Huawei Technologies Co.,Ltd.
Huawei Building, No.3 Xinxi Rd.,
Hai-Dian District
Beijing, 100085
P.R. China
EMail: mach@huawei.com
Guiyan Liu
Huawei Technologies Co.,Ltd
Huawei Building, No.156 Beiqing Rd.,
Hai-Dian District
Beijing, 100095
P.R. China
EMail: l62547@huawei.com
Hui Ni
Huawei Technologies Co.,Ltd
Huawei Building, No.156 Beiqing Rd.,
Hai-Dian District
Beijing, 100095
P.R. China
EMail: nihui@huawei.com
Zhenqiang Li
China Mobile
Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave,
Xuanwu District
Beijing, 100053
Dong, et al. Expires March 27, 2011 [Page 20]
Internet-Draft BGP Based VPN Route Constrain September 2010
P.R. China
Email: lizhenqiang@chinamobile.com
Dong, et al. Expires March 27, 2011 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 05:52:34 |