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