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 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]