[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network working group                                            J. Dong
Internet Draft                                                   M. Chen
Intended status: Standards Track                                  G. Liu
Expires: March 2011                                                H. Ni
                                                     Huawei Technologies
                                                                   Z. Li
                                                            China Mobile

                                                      September 27, 2010

   Constrained Route Distribution for BGP based Virtual Private Networks
                                  (VPNs)
                 draft-dong-idr-vpn-route-constrain-02.txt


Abstract

   There are some problems with current RT-Constrain mechanism defined
   in RFC 4684. Firstly, the IPv6 address specific Route Target defined
   in [RFC5701] cannot be accommodated in current RT membership NLRI.
   Secondly, the distribution of RT-Constrain information cannot build
   correct VPN distribution graph when hierarchical route reflection (RR)
   is  used.  Thirdly,  current  RT-Constrain  mechanism  is  used  for
   filtering of all kinds of VPN services and can result in imprecise
   VPN route distribution when multiple VPN services are deployed in the
   network.

   This document describes the above problems in detail and proposes
   solutions for these problems. A generalized RT-Constrain mechanism is
   defined to accommodate the IPv6 address specific Route Target and to
   precisely control propagation of different kinds of VPN routing
   information. The proposed solution avoids unnecessary advertising and
   receiving of VPN routes when multiple VPN services are deployed. This
   document also proposes modifications of advertisement rules of RT-
   Constrain information to ensure the integrity of VPN distribution
   graph.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any



Dong, et al.           Expires March 27, 2011                 [Page 1]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 27, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents carefully,
   as they describe your rights and restrictions with respect to this
   document. Code Components extracted from this document must include
   Simplified BSD License text as described in Section 4.e of the Trust
   Legal Provisions and are provided without warranty as described in
   the Simplified BSD License.

Table of Contents


   1. Introduction ................................................. 3
      1.1. Terminologies ........................................... 3
   2. Conventions used in this document ............................ 4
   3. Use of Route Target .......................................... 4
   4. IPv6 address specific Route Target ........................... 5
   5. Problems with Hierarchical Route Reflection .................. 5
      5.1. Modification of Advertisement Rules for Intra-AS scenario 7
   6. Problems of Route Constraint with Multiple VPNs Services ..... 7
      6.1. IPv4 L3VPN and IPv6 L3VPN ............................... 8
      6.2. L3VPN and L2VPN ......................................... 9
      6.3. Unicast VPN and Multicast VPN .......................... 10
      6.4. Multiple L2VPN Services ................................ 11
   7. Solutions for Route Constraint of Multiple VPN Services ..... 12
      7.1. Unique RT Assignment ................................... 12
      7.2. Generalized RT Constrain ............................... 12
         7.2.1. Proposed Format of Generalized RT Membership NLRI . 13
   8. Capability Advertisement .................................... 14
   9. Compatibility Considerations ................................ 14


Dong, et al.           Expires March 27, 2011                 [Page 2]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


   10. Security Considerations .................................... 15
   11. IANA Considerations......................................... 15
   12. Acknowledgements ........................................... 15
   13. References ................................................. 15
      13.1. Normative References .................................. 15
      13.2. Informative References ................................ 16
   Appendix A. Use of Route Target in Single Type of VPN Service .. 16
   Authors' Addresses ............................................. 20

1. Introduction

   BGP [RFC4271] has been widely used in many kinds of Virtual Private
   Networks (VPNs) for exchanging routes and auto discovery information.
   Route Target (RT) extended communities defined in [RFC4360] are used
   to control the distribution of received information into VPN
   instances.

   [RFC4684] defines procedures to restrict the distribution of VPN
   routes. It defines a new MP-BGP NLRI with [AFI=1, SAFI=132] for
   carrying RT membership information, which can be used to control the
   propagation of VPN routes. This mechanism can be used for the
   filtering for all kinds of VPN services.

   However, there are some problems with current RT-Constrain mechanism
   defined in RFC 4684. Firstly, the IPv6 address specific Route Target
   defined in [RFC5701] cannot be accommodated in current RT membership
   NLRI. Secondly, based on the attribute processing rules in section
   3.2 of [RFC4684], the distribution of RT-Constrain information cannot
   build  correct  VPN  distribution  graph  when  hierarchical  route
   reflection (RR) is used. Thirdly, current RT-Constrain mechanism is
   used for filtering of all kinds of VPN services which can result in
   imprecise VPN route distribution when multiple VPN services are
   deployed in the network.

   This document describes the use of RT for VPNs, specifies the above
   problems in detail and proposes solutions to solve these problems. A
   generalized RT-Constrain mechanism is defined to accommodate the IPv6
   address specific RT and to precisely control the propagation of
   different kinds of VPN routing information. This method avoids
   unnecessary advertising and receiving of VPN routes when multiple VPN
   services are deployed. This document also proposes modifications of
   advertisement rules of RT-constrain information to ensure the
   integrity of VPN distribution graph.

1.1. Terminologies

   Terms and acronyms specific to BGP and VPNs are listed below:


Dong, et al.           Expires March 27, 2011                 [Page 3]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


   AFI     Address Family Identifier

   CE      Customer Edge

   L2VPN   Layer 2 Virtual Private Network

   L3VPN   Layer 3 Virtual Private Network

   MVPN    Multicast L3VPN

   NLRI    Network Layer Reachability Information

   PE      Provider Edge

   RT      Route Target

   SAFI    Subsequent Address Family Identifier

   VPLS    Virtual Private LAN Service

   VPN     Virtual Private Network

   VRF     VPN Routing and Forwarding table

   VSI     Virtual Switching Instance

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3. Use of Route Target

   The Route Target (RT) extended communities defined in [RFC4360] is
   used for controlling the distribution of VPN routes. The use of RT in
   each kind of VPN has been specified respectively in [RFC4364],
   [RFC4659], [RFC4761], [RFC5195], [MVPN-BGP], [L2VPN-BGP], [VPLS-
   MCAST], [L2VPN-SIG] and [VPMS-BGP]. The Appendix section extracts the
   specifications about RT in these RFCs and drafts.

   Currently there is no specification on RT assignment among different
   kinds of VPNs. According to the procedures of BGP based VPN,
   different kinds of VPNs are isolated using different AFI/SAFIs, which
   allows the RT assignment in different kinds of VPNs to be performed
   independently, i.e. the RT assignment in one kind of VPN has no



Dong, et al.           Expires March 27, 2011                 [Page 4]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


   impact on the RT assignment and route distribution of another kind of
   VPN.

   In some scenarios such as network migration and deployment of new VPN
   services, in order to reduce manual configuration and the complexity
   in network management, operators MAY prefer to use the same RT for
   different kinds of VPN services. One case is to use the same RT for
   IPv4 and IPv6 VPNs.

4. IPv6 Address Specific Route Target

   [RFC5701] has defined IPv6 address specific Route Target with the
   length of 20 octets. However, the format of RT membership NLRI in RFC
   4684 contains a Route Target field of only 8 octets, thus the format
   of RT membership NLRI is not applicable when IPv6 address specific
   Route Target is used. From this point of view, an update to the
   format of RT-membership NLRI is needed.

   In order to solve this problem, this document proposes to change the
   length of Route Target field in RT membership NLRI to "variable".
   Thus the NLRI format is compatible with IPv6 address specific Route
   Target and other potential RT types which may be defined in future.
   Since the RT membership NLRI is encoded as defined in section 4 of
   RFC 2858 (obsoleted by [RFC4760]), thus the length field in RT
   membership NLRI can be used to calculate the length of Route Target.
   In order to make this extension and other further extensions in this
   document backward compatible with RFC 4684, a new SAFI is defined.
   Details about this new SAFI are specified in section 7.

5. Problems with Hierarchical Route Reflection

   For Intra-AS scenarios, section 3.2 of RFC 4684 proposes some
   modification to the path attribute calculation in advertisement of RT
   membership NLRI. These rules are used to guarantee the correct
   propagation of RT membership NLRI:

       i. When advertising RT membership NLRI to a route-reflector
   client, the Originator attribute shall be set to the router-id of the
   advertiser, and the Next-hop attribute shall be set of the local
   address for that session.

      ii. When advertising an RT membership NLRI to a non-client peer,
   if the best path as selected by the path selection procedure
   described in Section 9.1 of the base BGP specification [4] is a route
   received from a non-client peer, and if there is an alternative path
   to the same destination from a client, the attributes of the client
   path are advertised to the peer.


Dong, et al.           Expires March 27, 2011                 [Page 5]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


   However, these procedures are not sufficient when hierarchical RRs
   are used.

                +---------------------------------+
                |              +----+             |
                |        Clu-1 |RR-1|             |
                |             /+----+\            |
                |            /        \           |
                |         +----+    +----+        |
                |  Clu-2  |RR-2|    |RR-3|  Clu-3 |
                |         +-/--+    +/--\+        |
                |          /        /    \        |
                |     +----+    +----+    +----+  |
                |     |PE-1|    |PE-2|    |PE-3|  |
                |     +----+    +----+    +----+  |
                |       |          |         |    |
                +-------|----------|---------|----+
                   RT-1 |     RT-1 |         | RT-1
                +--------+   +--------+    +--------+
                |  VPN-1 |   |  VPN-1 |    |  VPN-1 |
                |        |   |        |    |        |
                +--------+   +--------+    +--------+
                               Figure 4.

   As shown in Figure 4, hierarchical RR are deployed in the network,
   RR-2 and RR-3 are clients of RR-1. Each PE advertises RT membership
   information of RT-1 to the upstream RR. After the best path selection,
   both RR-2 and RR-3 would create the CLUSTER_LIST attribute and
   prepend their local CLUSTER_ID and then advertise the best path to
   RR-1 and the downstream PEs respectively.

   RR-1 will select one of the received RT-Constrain NLRI path as the
   best path, say the path from RR-2. Then RR-1 needs to advertise the
   best path to both RR-2 and RR-3 to create distribution graph of VPN-1.
   RR-1 would prepend its CLUSTER_ID to the CLUSTER_LIST of the path,
   and according to the procedure i of Section 3.2 in [RFC4684], it
   SHOULD set the ORIGINATOR_ID to its router-id, and the NEXT_HOP to
   the local address for the session. Then RR-1 would advertise this
   route to both RR-2 and RR-3.

   On receipt of the RT-Constrain route from RR-1, RR-2 would check the
   CLUSTER_LIST and its own CLUSTER_ID is found in the list, so this
   route will be ignored. Thus RR-2 will not form outbound filter of RT-
   1 towards RR-1, which would impact the integrity of distribution
   graph of VPN-1.




Dong, et al.           Expires March 27, 2011                 [Page 6]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


   Besides, based on rule i, the Originator and Next-hop attributes are
   modified when advertising RT membership NLRI to the client, this may
   affect the best path selection results on the client and can result
   in unnecessary route oscillation especially when the client itself is
   a lower layer RR.

5.1. Modification of Advertisement Rules for Intra-AS scenario

   In order to avoid the problem described above, this section proposes
   to modify the route advertisement rules when advertising Route Target
   membership information sourced by the local autonomous system to an
   iBGP peer. The rule i of section 3.2 of RFC 4684 SHOULD be replaced
   with the following statement:

     i. When advertising a RT membership NLRI to a route-reflector
   client, if the best path as selected by the path selection procedure
   described in Section 9.1 of the base BGP specification [4] is the
   route received from this client, and the route does not carry
   CLUSTER_LIST attribute, then if there is an alternative path from
   another peer, the attributes of the alternative path are advertised
   to that client; if the best path carries a CLUSTER_LIST and is
   received from the same cluster as the client, then if there is an
   alternative path to the same destination from another peer in a
   different cluster, the attributes of the alternative path are
   advertised to that client.

   This route advertisement rule avoids advertising the best path back
   to the advertiser of that path, and also avoids advertising the path
   which was received from the same cluster of the peer, thus avoids the
   discarding of RT-Constrain information due to loop detection. This
   rule can also avoid possible route oscillation of RT membership NLRI.

6. Problems of Route Constraint with Multiple VPNs Services

   Service Provider (SP) may deploy more than one kind of VPNs in the
   same network. For example, both IPv4 and IPv6 L3VPNs, both L3VPN and
   L2VPN, both unicast VPN and multicast VPN, or different types of
   L2VPNs (VPLS, VPMS, Ethernet VPN, etc.) may be deployed in the same
   network. It is reasonable for SPs to design, deploy and maintain
   these different VPN services independently. Thus the RT assignment in
   each VPN service should be performed independently. In addition, in
   scenarios of inter-provider VPNs, it would be a complicated task to
   coordinate the RT assignment in different kinds of VPN services
   between different service providers. This burden can be relieved by
   allocating RTs independently for different types of VPN services. In
   this case, the same RT may be used by different types of VPNs. And in
   some other cases like network migration, the SPs may prefer to use


Dong, et al.           Expires March 27, 2011                 [Page 7]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


   the same RT for different types of VPN services for management
   simplicity.

   Since current RT-Constrain mechanism is used for filtering of all
   kinds of VPN services, it cannot work precisely in networks with
   multiple kinds of VPNs. The RT membership NLRI cannot tell which kind
   of VPN route (address family/subsequent address family) is requested.
   Thus in some scenarios, the current RT-Constrain is not sufficient to
   provide precise control for VPN route distribution, which result in
   unnecessary advertising and receiving of undesired VPN routes.
   Detailed analyses are given in sections below.

6.1. IPv4 L3VPN and IPv6 L3VPN

   Some service providers need to deploy both IPv4 L3VPN (VPNv4) and
   IPv6 L3VPN (VPNv6) in their network. During the migration from IPv4
   to IPv6, for less manual configuration and management simplicity the
   RTs used for VPNv6 can be the same as the ones for VPNv4. However,
   it's likely that not all the VPN sites are both IPv4 and IPv6 capable,
   some of them may be only IPv4 capable, some other ones may support
   both IPv4 and IPv6, and the others may only recognize IPv6 packets.

   In Figure 1, suppose the VPN site of VPN-1 connected to PE-1 is only
   IPv4 capable, the sites of VPN-1 connected to PE-2 and PE-3 are IPv6
   capable. Using procedures of RFC 4684, PE-1 advertises the RT
   membership information containing RT-1 to the other PEs. According to
   the received RT membership NLRI, PE-2 and PE-3 will advertise VPNv6
   routes of VPN-1 to PE-1. As a result, PE-1 will receive undesired
   VPNv6 routes of VPN-1. Similarly, PE-1 will receive undesired VPNv4
   routes of VPN-2, PE-3 will receive undesired VPNv4 routes of VPN-1.


















Dong, et al.           Expires March 27, 2011                 [Page 8]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


          +------------+       +------------+
          |   VPN-1    |       |   VPN-2    |
          |            |       |            |
          |   IPv4     |       |   IPv6     |
          +------------+       +------------+
                 RT-1  \        /  RT-2
             +----------\------/----------+
             |           +----+           |
             | Backbone  |PE-1|           |
             |           +----+           |
             |              |             |
             |           +----+           |
             |           | RR |           |
             |          /+----+\          |
             |         /        \         |
             |     +----+       +----+    |      +------------+
             |     |PE-2|       |PE-3|----|------|   VPN-2    |
             |     +----+       +----+    | RT-2 |            |
             +----/---------------|-------+      |IPv4 & IPv6 |
           RT-1  /                |  RT-1        +------------+
       +------------+         +------------+
       |   VPN-1    |         |   VPN-1    |
       |            |         |            |
       |IPv4 & IPv6 |         |   IPv6     |
       +------------+         +------------+
                                Figure 1.

   Even if RTs allocated for VPNv6 are different from the ones used for
   VPNv4 on each PE, if there is some overlapping between the RT space
   of VPNv4 and VPNv6 in the network, some PEs may also receive
   undesired VPN routes of other VPNs.

6.2. L3VPN and L2VPN

   The mechanisms defined in RFC 4684 are claimed to be applicable for
   L2VPNs which use Route Targets to control distribution of routing
   information. However, if both L3VPN and L2VPN are deployed in the
   same network, the mechanisms defined in RFC 4684 are not sufficient
   to achieve precise control of route distribution.

   If there is some overlapping between the RTs used in L3VPNs and
   L2VPNs in the network, PEs may receive undesired VPN routes of
   another kind of VPN service.

   For example, in Figure 2, RT-1 is used by PE-1 and PE-4 for L2VPN-1,
   and is also used by PE-2 and PE-3 for L3VPN-3. If PE-1 and PE-4
   advertise RT membership information of RT-1 to other PEs in the


Dong, et al.           Expires March 27, 2011                 [Page 9]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


   network, subsequently PE-2 and PE-3 would advertise undesired L3VPN
   routes to PE-1 and PE-4.

         +------------+   +------------+    +------------+
         |   VPN-1    |   |   VPN-2    |    |   VPN-3    |
         |            |   |            |    |            |
         |   L2VPN    |   |   L3VPN    |    |   L3VPN    |
         +------------+   +------------+    +------------+
                 RT-1  \   |  RT-2           /  RT-1
                    +---\--|----------------/----+
                    |    +----+      +----+/     |
                    |    |PE-1|      |PE-2|      |
                    |    +----+      +----+      |
                    |         \        /         |
                    |          \+----+/          |
                    | Backbone  | RR |           |
                    |          /+----+\          |
                    |         /        \         |
                    |     +----+       +----+    |      +------------+
                    |     |PE-3|       |PE-4|-----------|   VPN-2    |
                    |     +----+       +----+    | RT-2 |            |
                    +----/---------------|-------+      |   L3VPN    |
                  RT-1  /                | RT-1         +------------+
              +------------+         +------------+
              |   VPN-3    |         |   VPN-1    |
              |            |         |            |
              |   L3VPN    |         |   L2VPN    |
              +------------+         +------------+
                                Figure 2.

6.3. Unicast VPN and Multicast VPN

   Multicast L3VPN [MVPN, MVPN-BGP] and VPLS multicast [VPLS-MCAST] have
   defined new SAFIs for exchanging multicast routing information, and
   RTs are used in these scenarios to control distribution of multiple
   types of multicast routing information.

   Since MVPN is deployed on the basis of unicast VPN, they are always
   coexistent in the same network.

   As [MVPN-BGP] says, by default the distribution of Intra-AS I-PMSI A-
   D route is controlled by the same Route Targets as the ones used for
   the distribution of VPN-IP unicast routes. Thus PE advertising RT
   membership NLRI may receive undesired routing information, i.e., PE
   wants to receive only unicast VPN routes corresponding to the RT may
   also receive undesired multicast routing information.



Dong, et al.           Expires March 27, 2011                [Page 10]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


   In Figure 3, suppose the site of VPN-1 connected to PE-1 only support
   IP unicast, the sites of VPN-1 connected to PE-2 and PE-3 support IP
   multicast. Using the mechanisms defined in [RFC4684], PE-1 will
   advertise the RT membership information containing RT-1 to the other
   PEs. According to the received RT membership information, PE-2 and
   PE-3 will advertise multicast routes of VPN-1 to PE-1. As a result,
   PE-1 will receive undesired multicast routes of VPN-1.

           +------------+       +------------+
           |   VPN-1    |       |   VPN-2    |
           |            |       |            |
           |  Unicast   |       | Multicast  |
           +------------+       +------------+
                  RT-1  \        /  RT-2
              +----------\------/----------+
              |           +----+           |
              |           |PE-1|           |
              |           +----+           |
              | Backbone     |             |
              |           +----+           |
              |           | RR |           |
              |          /+----+\          |
              |         /        \         |
              |     +----+       +----+    |      +------------+
              |     |PE-2|       |PE-3|-----------|   VPN-2    |
              |     +----+       +----+    | RT-2 |            |
              +----/---------------|-------+      |  Unicast   |
            RT-1  /                |  RT-1        +------------+
        +------------+         +------------+
        |   VPN-1    |         |   VPN-1    |
        |            |         |            |
        | Multicast  |         |  Multicast |
        +------------+         +------------+
                                Figure 3.

   Even if RTs allocated for MVPNs are different from the ones used for
   unicast VPNs on each PE, if there is some overlapping between the RT
   space of MVPNs and unicast VPNs in the network, some PEs may also
   receive undesired VPN routes of other VPNs.

6.4. Multiple L2VPN Services

   Currently there are a number of different types of L2VPN services,
   such as VPLS, VPMS, Ethernet VPN etc., and different SAFIs have been
   defined (or will be defined) for different Layer 2 VPN information.
   All of these services use Route Target to control the distribution of
   auto-discovery and routing information. When multiple L2VPN


Dong, et al.           Expires March 27, 2011                [Page 11]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


   applications are deployed in the same network, if there are some
   overlapping between the RT spaces of those different services, some
   PEs may receive undesired VPN routes.

7. Solutions for Route Constraint of Multiple VPN Services

7.1. Unique RT Assignment

   One straightforward solution to avoid receiving undesired VPN routes
   with the use of RFC 4684 is to assign different RTs in different
   kinds of VPNs.

   One possible way is to pre-allocate disjoint RT ranges for different
   kinds of VPN services, such as allocate RT-1 to RT-X for IPv4 VPN,
   and RT-(X+1) to RT-Y for IPv6 VPN, RT-(Y+1) to RT-Z for L2VPN, etc.
   This requires well planning of RT space for different kinds of VPNs
   before the deployment of any VPN service. Since usually the VPN
   services are not developed, designed and deployed simultaneously,
   this solution seems not quite practical.

   Another scheme is to make sure each RT is only used in one kind of
   VPN service, e.g. if RT-X is used in IPv4 VPN, it cannot be used in
   any other kind of VPN. This does not require pre-allocated disjoint
   RT space for each VPN service, but operators has to assign RTs very
   carefully to make sure that each RT is only used in one kind of VPN.
   This brings additional planning and management burdens to operators
   during the deployment of new VPN services.

   As described in previous sections, in some cases the operators may
   prefer to use the same RT for different kinds of VPN services, such
   as IPv4 and IPv6 L3VPNs, or unicast and multicast VPNs. The unique RT
   assignment can not work in these scenarios.

   In the case of inter-provider VPNs, different providers need to
   cooperate on the choice of RTs, which makes it more difficult to
   select proper RTs for inter-provider VPNs based on the above
   solutions.

7.2. Generalized RT Constrain

   This section proposes a solution which could totally eliminate the
   restriction on RT assignment among different kinds of VPN services,
   thus keeps the management of RTs in one kind of VPN service
   independent of the other kinds of VPNs. This will relieve operators'
   burden on planning and management of different VPN applications.




Dong, et al.           Expires March 27, 2011                [Page 12]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


   This solution provides mechanisms to achieve AFI/SAFI specific VPN
   route filtering, which could precisely control the route distribution
   of different kinds of BGP based VPN services. In addition, this
   solution also provides mechanisms to accommodate IPv6 address
   specific RT defined in [RFC5701].

   In order to identify corresponding AFI of VPN routes that the RT
   membership NLRI stands for, this document proposes to extend the AFI
   value of RT membership NLRI. The AFI of this NLRI SHOULD be one of
   the AFIs that use Route Target to control route distribution. This
   document defines a new SAFI called Generalized Route Target
   Membership. A new SAFI value needs to be assigned by IANA. Thus the
   [AFI, SAFI] value pair of the Generalized RT Membership NLRI could be
   [AFI=1, SAFI=TBA] for IPv4 L3VPN, and [AFI=2, SAFI=TBA] for IPv6
   L3VPN, and [AFI=25, SAFI=TBA] for L2VPN, etc. Since currently there
   is no fixed AFI value for L1VPN, a new AFI value MAY need to be
   allocated by IANA, and the [AFI=TBD, SAFI=TBA] value pair represents
   the Generalized RT membership NLRI of L1VPN.

   In order to differentiate the filtering for VPN services with the
   same AFI but different SAFIs (e.g. different kinds of L2VPN services,
   unicast L3VPN and MVPN), the Generalized RT membership NLRI MUST
   contain the SAFI information of the VPN routes being requested. Thus
   the Generalized RT membership NLRI can be accurately identified as RT
   information of one particular type of VPN. Besides, if L1VPN and
   other kinds of VPNs are deployed in the same network, and no fixed
   AFI value has been allocated for L1VPN, the SAFI value of L1VPN can
   be used to identify RT membership information of L1VPN.

7.2.1. Proposed Format of Generalized RT Membership NLRI

   The format of Generalized RT membership NLRI is structured as follows:

             +-------------------------------+
             | Length            (1 octet)   |
             +-------------------------------+
             | Origin AS        (4 octets)   |
             +-------------------------------+
             | SAFI of VPN       (1 octet)   |
             +-------------------------------+
             |                               |
             ~ Route Target     (variable)   ~
             |                               |
             +-------------------------------+





Dong, et al.           Expires March 27, 2011                [Page 13]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


   The Length field is used to identify the total length of the rest
   fields. [Author notes: Though this field is defined as "the length in
   bits" in [RFC4760], it is RECOMMENDED that it represents the length
   in octets of the rest fields as in [RFC4761] for convenience.]

   The Origin AS field contains an Autonomous System number. Two octets
   AS numbers are encoded in the two low order octets of the Origin AS
   field, with the two high order octets set to zero.

   The "SAFI of VPN" field is the SAFI value of the VPN routes the PE
   intends to import using the Route Target below.

   The Route Target field contains Route Target of VPN routes being
   requested. Note the length of the Route Target field is variable, and
   can be calculated using the Length field of this NLRI.

8. Capability Advertisement

   In order for two BGP speakers to exchange Generalized RT membership
   NLRI, they MUST use BGP Capabilities Advertisement to ensure that
   they both are capable of properly processing such NLRI. This is done
   as specified in [RFC4760], by using capability code 1 (multiprotocol
   BGP) with an AFI of the corresponding VPN and a SAFI of Generalized
   RT-Constrain (TBA).

9. Compatibility Considerations

   The mechanism defined in this document is compatible with RT-
   constrain in [RFC4684], which is achieved by capability negotiation
   of different AFI/SAFIs.

   Multiprotocol Extension Capability of AFI/SAFI pair 1/132 can be
   regarded as common RT-constrain information applicable to all types
   of VPNs (though in this case IPv6 address specific RT is not
   applicable). When peering with legacy BGP speakers, only AFI/SAFI
   1/132 is negotiated for RT-Constrain. When peering with BGP speakers
   which support these extensions in this document, AFI/SAFI 1/132 can
   also be used if address family specific filtering is not needed. When
   it is needed to precisely control the route distribution of some
   specific VPN types, this can be achieved by using Generalized RT-
   Constrain mechanism with further capability negotiation of specific
   AFI and SAFI of Generalized RT-Constrain (TBA). If the capability of
   Generalized RT-Constrain for specific address family is successfully
   negotiated, then for this address family the Generalized RT
   membership information MUST override the RT information of AFI/SAFI
   1/132.



Dong, et al.           Expires March 27, 2011                [Page 14]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


10. Security Considerations

   This document does not change the security properties of BGP based
   VPNs and RFC 4684.

11. IANA Considerations

   IANA needs to assign a SAFI value for Generalized Route Target
   Membership. This code point will come from the "Subsequent Address
   Family Identifiers" registry.

   IANA MAY assign an AFI number for L1VPN. This code point will come
   from the "Address Family Numbers" registry.

12. Acknowledgements

   The authors would like to thank John Scudder, Rajiv Asati, Keyur
   Patel and Robert Raszuk for their valuable comments. Many thanks to
   Qing Zeng, Yaqun Xiao for valuable discussion about hierarchical
   route reflection scenario.

13. References

13.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway
             Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4360] Sangli, S., Tappan, D. and Rekhter, Y., "BGP Extended
             Communities Attribute", RFC 4360, February 2006.

   [RFC4364] Rosen, E. and Rekhter, Y., "BGP/MPLS IP Virtual Private
             Networks (VPNs)", RFC 4364, February 2006.

   [RFC4659] De Clercq, J., Ooms, D., Carugi, M. and Le Faucheur, F.,
             "BGP-MPLS IP Virtual Private Network (VPN) Extension for
             IPv6 VPN", RFC 4659, September 2006.

   [RFC4684] Marques, P. et. al, "Constrained Route Distribution for
             Border Gateway Protocol/MultiProtocol Label Switching
             (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks
             (VPNs)", RFC 4684, November 2006.




Dong, et al.           Expires March 27, 2011                [Page 15]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


   [RFC4760] Bates, T., Chandra, R., Katz, D., Rekhter, Y.,
             "Multiprotocol Extensions for BGP-4", RFC 4760, January
             2007.

   [RFC4761] Kompella, K., Rekhter, Y., "Virtual Private LAN Service
             (VPLS) Using BGP for Auto-Discovery and Signaling", RFC
             4761, January 2007.

   [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended
             Communities Attribute", RFC 5701, November 2009.

   [MVPN-BGP] Aggarwal, R., Rosen, E., Morin, T., Rekhter, Y., "BGP
             Encodings and Procedures for Multicast in MPLS/BGP IP VPNs",
             work in progress.

13.2. Informative References

   [RFC5195] Ould-Brahim, H., Fedyk, D. and Rekhter, Y., "BGP-Based
             Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.

   [L2VPN-BGP] Kompella, K., Kothari, B. and Cherukuri, R., "Layer 2
             Virtual Private Networks Using BGP for Auto-discovery and
             signaling", work in progress.

   [L2VPN-SIG] Rosen, E., Luo, W., Davie, B., Radoaca, V., "Provisioning,
             Autodiscovery, and Signaling in L2VPNs", work in progress.

   [MVPN] Rosen, E., Aggarwal, R., "Multicast in MPLS/BGP IP VPNs", work
             in progress

   [VPLS-MCAST] Aggarwal, R., Kamite, Y., Fang, L., "Multicast in VPLS",
             work in progress.

   [VPMS-BGP] Aggarwal, R., Kamite, Y., Jounay, F., "BGP based Virtual
             Private Multicast Service Auto-Discovery and Signaling",
             work in progress.



Appendix A. Use of Route Target in Single Type of VPN Service

   The use of Route Target for single kind of VPN has been specified in
   some IETF documents.

   [RFC4364] specifies the use of RT in IPv4 VPNs:




Dong, et al.           Expires March 27, 2011                [Page 16]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


     A Route Target attribute can be thought of as identifying a set of
     sites. (Though it would be more precise to think of it as
     identifying a set of VRFs.)  Associating a particular Route Target
     attribute with a route allows that route to be placed in the VRFs
     that are used for routing traffic that is received from the
     corresponding sites.

     Suppose it is desired to create a fully meshed closed user group,
     i.e., a set of sites where each can send traffic directly to the
     other, but traffic cannot be sent to or received from other sites.
     Then each site is associated with a VRF, a single Route Target
     attribute is chosen, that Route Target is assigned to each VRF as
     both the Import Target and the Export Target, and that Route Target
     is not assigned to any other VRFs as either the Import Target or
     the Export Target.

     Alternatively, suppose one desired, for whatever reason, to create
     a "hub and spoke" kind of VPN.  This could be done by the use of
     two Route Target values, one meaning "Hub" and one meaning "Spoke".
     At the VRFs attached to the hub sites, "Hub" is the Export Target
     and "Spoke" is the Import Target.  At the VRFs attached to the
     spoke site, "Hub" is the Import Target and "Spoke" is the Export
     Target.

   [RFC4659] states the use of Route Target in IPv6 VPNs:

     The use of route target is specified in [BGP/MPLS-VPN] and applies
     to IPv6 VPNs. Encoding of the extended community attribute is
     defined in [BGP-EXTCOM].

   [RFC4761] describes the use of Route Target in VPLS:

     The semantics of the use of Route Targets is described in [RFC4364];
     their use in VPLS is identical.

     As it has been assumed that VPLSs are fully meshed, a single Route
     Target RT suffices for a given VPLS V, and in effect that RT is the
     identifier for VPLS V.

   [RFC5195] states the use of Route Target in L1VPN auto-discovery:

     To restrict the flow of this information to only the PITs within a
     given L1VPN, we use BGP route filtering based on the Route Target
     Extended Community [BGP-COMM], as follows.

     Each PIT on a PE is configured with one or more Route Target
     Communities, called "export Route Targets", that are used for


Dong, et al.           Expires March 27, 2011                [Page 17]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


     tagging the local information when it is exported into the
     provider's BGP. The granularity of such tagging could be as fine as
     a single <CPI, PPI> pair.  In addition, each PIT on a PE is
     configured (at provisioning time) with one or more Route Target
     Communities, called "import Route Targets", that restrict the set
     of routes that could be imported from provider's BGP into the PIT
     to only the routes that have at least one of these Communities.

   [MVPN-BGP] specifies the use of RT in Multicast IP VPNs:

     To support MVPN in addition to the import/export Route Target(s)
     extended communities used by the unicast routing, each VRF on a PE
     MUST have an import Route Target extended community, except if it
     is known a priori that none of the (local) MVPN sites associated
     with the VRF contain multicast source(s) and/or C-RP, in which case
     the VRF need not have this import Route Target.

     We refer to this Route Target as the "C-multicast Import RT", as
     this Route Target controls imports of C-multicast routes into a
     particular VRF.

     By default the distribution of the Intra-AS I-PMSI A-D routes is
     controlled by the same Route Targets as the ones used for the
     distribution of VPN-IP unicast routes... The default could be
     modified via configuration by having a set of Route Targets used
     for the Intra-AS I-PMSI A-D routes being distinct from the ones
     used for the VPN-IP unicast routes.

     An ASBR MUST be configured with a set of (import) Route Targets
     (RTs) that specifies the set of MVPNs supported by the ASBR. These
     Route Targets control acceptance of Intra-AS/Inter-AS I-PMSI A-D
     routes by the ASBR. As long as unicast and multicast connectivity
     are congruent, this could be the same set of Route Targets as the
     one used for supporting unicast (and therefore would not require
     any additional configuration above and beyond of what is required
     for unicast).

     The ASBR MUST be (auto-)configured with an import Route Target
     called "ASBR Import RT". ASBR Import RT controls acceptance of Leaf
     A-D routes and C-multicast routes by the ASBR, and is used to
     constrain distribution of both Leaf A-D routes and C-multicast
     routes.

   [L2VPN-BGP] uses Route Target to define the topology of L2VPN:





Dong, et al.           Expires March 27, 2011                [Page 18]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


     Each PE is configured with the VPNs in which it participates. Each
     VPN is associated with one or more Route Target communities
     [RFC4360] which serve to define the topology of the VPN.

   [L2VPN-SIG] specifies the coordination in RT assignment between
   different operators in inter-provider L2VPN scenarios.

     The main challenge is that it is necessary for the operator of one
     AS to know what RT or RTs have been chosen in another AS for any
     VPN that has sites in both ASes. As in layer 3 VPNs, there are many
     ways to make this work, but all require some co-operation among the
     providers.

   [VPLS-MCAST] describes the use of RT for VPLS Multicast in a similar
   way to mechanisms defined in [MVPN-BGP].

   [VPMS-BGP] describes the use of RT in VPMS service in section 5 "VPMS
   Auto-Discovery":

     This document reuses the procedures described in [VPLS-MCAST] for
     auto-discovery with modifications described in this document.

     The BGP A-D route MUST carry the set of Route Targets being
     exported by the VPMS instance.

     As described in the section "Layer 2 Multicast VPN" the information
     about whether a CE belongs to a sender site or a receiver site is
     determined from the Route Targets (RT) that are configured to
     enforce the administrative policies of a L2 MVPN. These RTs are
     advertised in the corresponding BGP A-D routes. For instance if
     some of the sites in a VPMS are only in sender site set while
     others are only in receiver sites set, then CEs that are in the
     receiver site set are configured to import only sender site set RTs.
     While CEs that are in the sender site set are configured to import
     only the receiver site set RTs. In this case two RTs are required
     to provision the VPMS instance.












Dong, et al.           Expires March 27, 2011                [Page 19]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


Authors' Addresses

   Jie Dong
   Huawei Technologies Co.,Ltd.
   Huawei Building, No.3 Xinxi Rd.,
   Hai-Dian District
   Beijing, 100085
   P.R. China

   EMail: dongjie_dj@huawei.com


   Mach(Guoyi) Chen
   Huawei Technologies Co.,Ltd.
   Huawei Building, No.3 Xinxi Rd.,
   Hai-Dian District
   Beijing, 100085
   P.R. China

   EMail: mach@huawei.com


   Guiyan Liu
   Huawei Technologies Co.,Ltd
   Huawei Building, No.156 Beiqing Rd.,
   Hai-Dian District
   Beijing, 100095
   P.R. China

   EMail: l62547@huawei.com


   Hui Ni
   Huawei Technologies Co.,Ltd
   Huawei Building, No.156 Beiqing Rd.,
   Hai-Dian District
   Beijing, 100095
   P.R. China

   EMail: nihui@huawei.com


   Zhenqiang Li
   China Mobile
   Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave,
   Xuanwu District
   Beijing, 100053


Dong, et al.           Expires March 27, 2011                [Page 20]


Internet-Draft      BGP Based VPN Route Constrain       September 2010


   P.R. China

   Email: lizhenqiang@chinamobile.com













































Dong, et al.           Expires March 27, 2011                [Page 21]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/