One document matched: draft-dong-idr-vpn-route-constrain-01.txt
Differences from draft-dong-idr-vpn-route-constrain-00.txt
Network working group J. Dong
Internet Draft M. Chen
Intended status: Standards Track G. Liu
Expires: January 2011 H. Ni
Huawei Technologies
Z. Li
China Mobile
July 12, 2010
Constrained Route Distribution for BGP based Virtual Private Networks
(VPNs)
draft-dong-idr-vpn-route-constrain-01.txt
Abstract
This document defines generalized procedures that allow BGP speakers
to exchange Route Target reachability information. This information
can be used to precisely control the propagation of different kinds
of Virtual Private Network (VPN) routing information. This method
avoids unnecessary advertising of VPN routes when more than one kind
of VPN service is deployed in the network. This document also
provides a solution to ensure the RT-Constrain mechanism compatible
with IPv6 address specific Route Target defined in [RFC5701].
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
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 January 12, 2011.
Dong, et al. Expires January 12, 2011 [Page 1]
Internet-Draft BGP Based VPN Route Constrain July 2010
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..................................................2
1.1. Terminologies............................................3
2. Conventions used in this document.............................4
3. Use of Route Target...........................................4
4. Problems of Route Constraint in Multiple Kinds of VPNs........4
4.1. IPv4 L3VPN and IPv6 L3VPN................................5
4.2. L3VPN and L2VPN..........................................6
4.3. Unicast VPN and Multicast VPN............................7
5. Considerations about IPv6 address specific Route Target.......8
6. Possible Solutions............................................9
6.1. Compatibility with IPv6 address specific Route Target....9
6.2. Identifying RT Membership in Multiple Kinds of VPNs......9
6.2.1. Unique RT Assignment................................9
6.2.2. Generalized RT Constrain...........................10
6.3. Proposed Format of Generalized RT Membership NLRI.......10
7. Capability advertisement.....................................11
8. Security Considerations......................................11
9. IANA Considerations..........................................11
10. Acknowledgements............................................12
11. References..................................................12
11.1. Normative References...................................12
11.2. Informative References.................................13
Appendix A. Use of Route Target in Single Kind of VPN Service...13
Authors' Addresses..............................................16
1. Introduction
BGP [RFC4271] has been widely used in many kinds of Virtual Private
Networks (VPNs) for exchanging routes and auto discovery information.
Dong, et al. Expires January 12, 2011 [Page 2]
Internet-Draft BGP Based VPN Route Constrain July 2010
Route Target (RT) extended communities defined in [RFC4360] are used
to control the distribution of received information into VPN
instances.
[RFC4684] defines some 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. The procedures are helpful in limiting the
propagation of VPN routes in networks where only one kind of VPN is
deployed. If multiple different kinds of VPN services are deployed in
the network, the procedures in RFC 4684 are not sufficient for
providing precise control of VPN route distribution. In addition, the
format of RT membership NLRI defined is not compatible with IPv6
address specific Route Target which is defined in [RFC5701].
This document describes the use of RT for VPNs, analyses possible
problems RFC 4684 may meet with and provides solutions for these
problems.
1.1. Terminologies
Terms and acronyms specific to BGP and VPNs are listed below:
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
Dong, et al. Expires January 12, 2011 [Page 3]
Internet-Draft BGP Based VPN Route Constrain July 2010
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. Based on the procedures of BGP based VPN, different
kinds of VPNs are isolated using different AFI/SAFI, which allows the
RT assignment in different kinds of VPNs be performed independently,
i.e. the RT assignment in one kind of VPN has no 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 VPN.
4. Problems of Route Constraint in Multiple Kinds of VPNs
Service Provider (SP) may deploy more than one kind of VPNs in the
same network. For example, SPs may deploy both IPv4/IPv6 L3VPNs, or
both L3VPN and L2VPN, or both unicast VPN and multicast VPN, or even
more than 2 kinds of VPN services coexisted in their network. It is
reasonable for SPs to design, deploy and maintain these different VPN
services independently. Thus the RT assignment in different VPN
services should be performed independently. In addition, in the
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 kinds of VPN services. In
this case, the same RT may be used by different kinds of VPNs.
The procedures of RFC 4684 cannot work accurately in networks with
multiple kinds of VPNs. The RT membership NLRI used for controlling
Dong, et al. Expires January 12, 2011 [Page 4]
Internet-Draft BGP Based VPN Route Constrain July 2010
the distribution of VPN routes cannot tell which kind of VPN route is
requested. Thus in some scenarios, the mechanism in RFC 4684 is not
sufficient to provide precise control for VPN route distribution, and
some PEs may receive undesired VPN routes. Detailed analyses are
given in sections below.
4.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 information, 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 January 12, 2011 [Page 5]
Internet-Draft BGP Based VPN Route Constrain July 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.
4.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 accurate 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 January 12, 2011 [Page 6]
Internet-Draft BGP Based VPN Route Constrain July 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.
4.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 January 12, 2011 [Page 7]
Internet-Draft BGP Based VPN Route Constrain July 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 unwanted VPN routes of other VPNs.
5. Considerations about IPv6 address specific Route Target
The format of RT membership NLRI in RFC 4684 contains a Route Target
field of 8 octets. However, [RFC5701] has defined IPv6 address
specific Route Target with the length of 20 octets, thus the format
of RT membership NLRI is not applicable when IPv6 address specific
Dong, et al. Expires January 12, 2011 [Page 8]
Internet-Draft BGP Based VPN Route Constrain July 2010
Route Target is used. From this point of view, an update to the
format of RT-membership NLRI is necessary.
6. Possible Solutions
6.1. Compatibility with IPv6 address specific Route Target
First of all, 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 types of Route Targets which can be defined in future.
Since the RT membership NLRI is encoded as defined in section 4 of
RFC 2858 (which is obsoleted by [RFC4760]), thus the length field in
RT membership NLRI can be used to calculate the length of Route
Target.
6.2. Identifying RT Membership in Multiple Kinds of VPNs
6.2.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
Dong, et al. Expires January 12, 2011 [Page 9]
Internet-Draft BGP Based VPN Route Constrain July 2010
select proper RTs for inter-provider VPNs based on the above
solutions.
6.2.2. Generalized RT Constrain
This section provides a solution which totally eliminates the
restriction on RT assignment among different kinds of VPNs, thus
keeps the management of RTs in one kind of VPN independent of the
other kinds of VPNs. This will relieve operators' burden on planning
and management of different VPN services.
This solution proposes to extend RFC 4684 to a more general method
for controlling the route distribution of all kinds of BGP based VPNs
in any scenario.
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 distinguish the control of VPN routes with the same AFI
value but different SAFIs, e.g. 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 route. 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.
6.3. Proposed Format of Generalized RT Membership NLRI
The format of Generalized RT membership NLRI is structured as follows:
Dong, et al. Expires January 12, 2011 [Page 10]
Internet-Draft BGP Based VPN Route Constrain July 2010
+-------------------------------+
| Length (1 octet) |
+-------------------------------+
| Origin AS (4 octets) |
+-------------------------------+
| SAFI of VPN (1 octet) |
+-------------------------------+
| |
~ Route Target (variable) ~
| |
+-------------------------------+
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
wants 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.
7. 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 an SAFI of TBA.
8. Security Considerations
This document does not change the security properties of BGP based
VPNs and RFC 4684.
9. 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.
Dong, et al. Expires January 12, 2011 [Page 11]
Internet-Draft BGP Based VPN Route Constrain July 2010
IANA MAY assign an AFI number for L1VPN. This code point will come
from the "Address Family Numbers" registry.
10. Acknowledgements
The authors would like to thank John Scudder, Rajiv Asati and Robert
Raszuk for their valuable comments.
11. References
11.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.
[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.
Dong, et al. Expires January 12, 2011 [Page 12]
Internet-Draft BGP Based VPN Route Constrain July 2010
11.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 Kind 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:
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.
Dong, et al. Expires January 12, 2011 [Page 13]
Internet-Draft BGP Based VPN Route Constrain July 2010
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
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.
Dong, et al. Expires January 12, 2011 [Page 14]
Internet-Draft BGP Based VPN Route Constrain July 2010
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:
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":
Dong, et al. Expires January 12, 2011 [Page 15]
Internet-Draft BGP Based VPN Route Constrain July 2010
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.
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
Dong, et al. Expires January 12, 2011 [Page 16]
Internet-Draft BGP Based VPN Route Constrain July 2010
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
P.R. China
Email: lizhenqiang@chinamobile.com
Dong, et al. Expires January 12, 2011 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 05:52:34 |