Internet DRAFT - draft-fang-bess-data-center-interconnect

draft-fang-bess-data-center-interconnect



 



INTERNET-DRAFT                                               Luyuan Fang
Intended Status: Informational                                 Microsoft
Expires: Sept 9, 2015                                  Luis M. Contreras
                                                              Telefonica
                                                            Daniel Voyer
                                                             Bell Canada
                                                                        
                                                           March 9, 2015



                BGP/MPLS IP VPN Data Center Interconnect
              draft-fang-bess-data-center-interconnect-00


Abstract

   This document discusses two categories of inter-connections of
   BGP/MPLS IP VPN and Data Center (DC) overlay networks. In the first
   category, DC overlay virtual network is built with BGP/MPLS IP VPN
   (IP VPN) technologies, the inter-connection of IP VPN in the DC to IP
   VPN in the WAN enables end-to-end IP VPN connectivity. In the second
   category, DC overlay network uses non IP VPN overlay technologies,
   the inter-connection of any overlay virtual network in the DC to IP
   VPN in the WAN provides end user connectivity through stitching of
   different overlay technologies.

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/1id-abstracts.html

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

 


Fang et al.              Expires <Sept 9, 2015>                 [Page 1]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>           <March 9, 2014>


Copyright and License Notice

   Copyright (c) 2014 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 Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1 Case 1: End-to-end BGP IP VPN cloud inter-connection . . . .  4
     2.2 Case 2: Hybrid cloud inter-connection  . . . . . . . . . . .  4
   3. Architecture reference models . . . . . . . . . . . . . . . . .  4
     3.1 BGP/MPLS IP VPN Inter-AS model . . . . . . . . . . . . . . .  5
     3.2 BGP/MPLS IP VPN Gateway PE to DC vCE Model . . . . . . . . .  6
     3.3 Hybrid inter-connection model  . . . . . . . . . . . . . . .  7
     3.4 Cloud Provider as a VPN customer . . . . . . . . . . . . . .  7
   4. Inter-connect IP VPN between DC and WAN . . . . . . . . . . . .  8
     4.1 Existing Inter-AS options and DCI gap analysis . . . . . . .  8
       4.1.1 Option A pros and cons . . . . . . . . . . . . . . . . .  8
       4.1.2 Option B pros and cons . . . . . . . . . . . . . . . . .  9
       4.1.3 Option C pros and cons . . . . . . . . . . . . . . . . .  9
       4.1.4 Use of RTC . . . . . . . . . . . . . . . . . . . . . . . 10
     4.2 Carriers' carrier model  . . . . . . . . . . . . . . . . . . 10
   5. Inter-connect IP VPN and non-IP VPN overlay networks  . . . . . 11
   6. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1  Normative References  . . . . . . . . . . . . . . . . . . . 12
     8.2  Informative References  . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13



1  Introduction

   With the growth of cloud services, the need of inter-connecting DC
   overlay networks and Enterprise BGP/MPLS IP VPNs in the Wide Area
 


Fang et al.              Expires <Sept 9, 2015>                 [Page 2]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>           <March 9, 2014>


   Network (WAN) arises.

   Two categories of inter-connections of BGP/MPLS IP VPN [RFC4364] and
   Data Center (DC) overlay networks are discussed in this document. In
   the first category, DC overlay virtual network is built with BGP/MPLS
   IP VPN (IP VPN) technologies, the inter-connection of IP VPN in the
   DC to IP VPN in the WAN enables end-to-end IP VPN connectivity for
   Virtual Private Cloud (VPC) services. In the second category, DC
   overlay network uses non IP VPN overlay technologies, the inter-
   connection of any overlay virtual network in the DC to IP VPN in the
   WAN provides end user connectivity through stitching of different
   overlay technologies.

   This document discusses use cases of the inter-connection of BGP/MPLS
   VPN to Data Centers, the general requirements, and the proposed
   solutions for the inter-connections.

1.1 Terminology

   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 RFC 2119 [RFC2119].


   Term              Definition
   -----------       --------------------------------------------------
   AS                Autonomous System
   ASBR              Autonomous System Border Router
   BGP               Border Gateway Protocol
   CE                Customer Edge
   GRE               Generic Routing Encapsulation
   Hypervisor        Virtual Machine Manager
   I2RS              Interface to Routing System
   MP-BGP            Multi-Protocol Border Gateway Protocol
   NVGRE             Network Virtualization using GRE
   QoS               Quality of Service
   RD                Route Distinguisher
   RR                Route Reflector
   RT                Route Target
   RTC               RT Constraint
   SDN               Software Defined Network
   ToR               Top-of-Rack switch
   vCE               virtual Customer Edge Router
   VM                Virtual Machine
   VN                Virtual Network
   VPC               Virtual Private Cloud
   vPE               virtual Provider Edge Router
   VPN               Virtual Private Network
 


Fang et al.              Expires <Sept 9, 2015>                 [Page 3]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>           <March 9, 2014>


   VXLAN             Virtual eXtensible Local Area Network
   WAN               Wide Area Network

2. Use Cases

2.1 Case 1: End-to-end BGP IP VPN cloud inter-connection

   SPs have large deployments of BGP/MPLS IP VPNs. Many SPs are
   interested to extend the IP VPN capabilities into their DCs to
   provide end-to-end native BGP IP VPN services to their enterprise
   customers.

   BGP IP VPN provides routing isolation, rich policy control, and QoS
   support. The technologies developed to extend BGP IP VPN into DC
   servers or ToR are work in progress in IETF,
   [I-D.fang-l3vpn-virtual-pe],and [I-D.ietf-l3vpn-end-system].

   The WAN and DC may be managed by the same or different administrative
   domains.

   One special case of the cloud inter-connection is the extension
   across the network of large DCs, typically concentrated in central
   areas of a network, being complemented by one or more micro-DCs,
   usually close to the access points of presence.


                                 ,-----.        
                                (       ')      
               +------+     .--(.       '.---.     +------+
               |      |    (     '      '     )    |      |
               | DC_a +---(    IP/MPLS WAN     )---+ DC_b |
               |      |    (.                .)    |      |
               +------+     '-(     (       .)     +------+
                              ''--' '-''--''  


                 Figure 1. Cloud Inter-Connection use case

2.2 Case 2: Hybrid cloud inter-connection

    Inter-connecting network SPs Enterprise IP VPNs to Cloud/Content
    providers DCs for expanded services. The inter-connection between
    the SP BGP/MPLS IP VPNs and the cloud provider networks is needed to
    provide the service end-to-end. The inter-connection of different
    types of providers can be BGP/MPLS IP VPN to other VPN or overlay
    technologies which may be virtualized or non-virtualized.

3. Architecture reference models
 


Fang et al.              Expires <Sept 9, 2015>                 [Page 4]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>           <March 9, 2014>


    The architecture reference models described below focus on the
    inter-connection aspects. Although the intra-DC implementation is
    not within the scope of this discussion, the intra-DC technology has
    a direct impact to inter-DC connection. Therefore, various models
    are illustrated.

3.1 BGP/MPLS IP VPN Inter-AS model

    The BGP/MPLS IP VPNs are implemented in both the WAN network and the
    Data Center. A customer VPN, for example VPNA in figure 2, consists
    of enterprise remote sites and VMs supporting applications in the
    DC. The IP VPN implementation is using vPE technology in DC. The two
    segments of the VPNs are inter-connected through ASBRs facing each
    other in the respective networks.


                   ,-----.                      ,-----.
                  (       ')                   (       ')
              .--(.       '.---.           .-.(.       '.---.
             (     '      '   +-----+   +-----+              )
            (    IP/MPLS WAN  |ASBR1|---|ASBR2|  DC Network   )
             (.               +-----+   +-----+             .)
            +-----+    (       .)          (     (     +-----+
            | PE1 |-.-' '-''--''            ''--' '-''-|vPE2 |
         .----.-.----.                               .----.-.----.
         |VRFA| |VRFB|                               |VRFA| |VRFB|
         '----' '----'                               '----' '----'
           /       \                                  /  \     \
        +---+     +---+                            .---. .---. .---.
        |CE1|     |CE2|                            |VM1| |VM2| |VM3|
        +---+     +---+                            '---' '---' '---'
        (VPNA)    (VPNB)                           (   VPNA  ) (VPNB)


             Figure 2. BGP/MPLS IP VPN Inter-Connection
                       with ASBR in each network

   One boarding ASBR can be shared for the inter-connection of the two
   networks, especially if the WAN and DC belong to the same provider.
   Figure 3 illustrates this shared ASBR model.








 


Fang et al.              Expires <Sept 9, 2015>                 [Page 5]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>           <March 9, 2014>


                     ,----..                 ,-----.
                    (       ')              (       ')
                .--(.       '.----.     .-.(.       '.---.
               (     '      '     +------+                )
              (    IP/MPLS WAN    | ASBR |   DC Network    )
               (.                 +------+               .)
              +-----+    (        .)   (     (     +-----+
              | PE1 |-.-' '-''---''     ''--' '-''-|vPE2 |
           .----.-.----.                        .----.-.----.
           |VRFA| |VRFB|                        |VRFA| |VRFB|
           '----' '----'                        '----' '----'
             /       \                           /  \     \
          +---+     +---+                    .---. .---. .---.
          |CE1|     |CE2|                    |VM1| |VM2| |VM3|
          +---+     +---+                    '---' '---' '---'
          (VPNA)    (VPNB)                   (   VPNA  ) (VPNB)


             Figure 3. BGP/MPLS IP VPN Inter-Connection
                       with share ASBR

3.2 BGP/MPLS IP VPN Gateway PE to DC vCE Model


   A simple virtual CE (vCE) [I-D.fang-l3vpn-virtual-ce] model can be
   used to inter-connect client containers to the DC Gateway which
   function as PE. This model is used by SPs to provide managed
   services, when scale can meet the service requirement.

                  ,----..                 ,-----.
                 (       ')              (       ')
             .--(.       '.----.     .----.      '.----.
            (     '      '     +-----|VRFA|            +----+
           (    IP/MPLS WAN    |GW/PE'----' DC Network |vCE4|
            (.                 +-----|VRFB|            +----+
           +-----+    (       )'     '----'.(       )-'  |  (VPNB)
           | PE1 |-.-' '-''- '         '--'  '+----+   .---.
        .----.-.----.                         |vCE3|   |VM3|
        |VRFA| |VRFB|                  (VPNA) +----+   '---'
        '----' '----'                         /   \
          /       \                        .---..---.
       +---+     +---+                      |VM1||VM2|
       |CE1|     |CE2|                      '---''---'
       +---+     +---+
       (VPNA)    (VPNB)


             Figure 4. BGP/MPLS IP VPN GW/PE to vCEs
 


Fang et al.              Expires <Sept 9, 2015>                 [Page 6]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>           <March 9, 2014>


                       without BGP/MPLS IP VPN in the DC

3.3 Hybrid inter-connection model

   The BGP/MPLS IP VPNs are implemented in the WAN network, and non
   BGP/MPLS IP VPN Overlay are implemented in the DC. The connection of
   the two networks is outside of the technologies for Inter-AS
   connections for BGP IP VPNs. This model includes many variations
   depending on the specific technologies used in the DC overlay. Figure
   5 provides a general view of this inter-connecting model with ASBR on
   the MPLS WAN side, and the DC GW on the DC side. It is also viable to
   use one shared ASBR/GW for the inter-connection, especially if the
   WAN and the DC belong to the same provider.

                 ,-----.                      ,-----.
                (       ')                   (       ')
            .--(.       '.---.           .-.(.       '.---.
           (     '      '   +-----+   +-----+              )
          (    IP/MPLS WAN  |ASBR |---|DC GW|  DC Network   )
           (.               +-----+   +-----+             .)
          +-----+    (       .)          (     (     +-----+
          | PE1 |-.-' '-''--''            ''--' '-''-| NVE |
       .----.-.----.                                 +-----+
       |VRFA| |VRFB|                                 /  \     \
       '----' '----'                             .---. .---. .---.
         /       \                               |VM1| |VM2| |VM3|
      +---+     +---+                            .---. .---. .---.
      |CE1|     |CE2|                            ( TenantA)  (TenantB)
      +---+     +---+
      (VPNA)    (VPNB)


             Figure 5. BGP/MPLS IP VPN Inter-Connection with
                       non BGP/MPLS IP VPN Overlay in DC

3.4 Cloud Provider as a VPN customer

   The Cloud Provider can establish its own VPN for internal services
   between dispersed DCs across the network. The SP should facilitate
   the BGP connectivity between DCs without requiring the knowledge
   respect to the the detailed routing information of the Cloud Provider
   VPNs.






 


Fang et al.              Expires <Sept 9, 2015>                 [Page 7]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>           <March 9, 2014>


           (VPN A) (VPN B)                      (VPN A) (VPN B)
            .---.   .---.                        .---.   .---.
            |VM1|   |VM2|                        |VMi|   |VMj|
            '---'   '---'                        '---'   '---'
              /       /                            /       /
           .----. .----.                        .----. .----.
           |VRFA| |VRFB|        ,-----.         |VRFA| |VRFB|
           '----'-'----'       (       ')       '----'-'----'
             +-|vPE|-+     .--(.       '.---.     +-|vPE|-+
             | +---+ |    (     '      '     )    | +--+  |
             |   :  +--+ (    IP/MPLS WAN     ) +--+  :   |
             |   :..|CE|--(.                .)--|CE|..:   |
             |      +--+   '-(     (       .)   +--+      |
             | DC_a  |        ''--' '-''--''      | DC_b  |
             +-------+                            +-------+


             Figure 6. BGP/MPLS IP VPN Inter-Connection with
                       SP as carrier's carrier of Cloud Provider


4. Inter-connect IP VPN between DC and WAN

4.1 Existing Inter-AS options and DCI gap analysis

   The inter-AS options described in [RFC4364] can be used for DC inter-
   connection. Option A, B, and C must be supported.

4.1.1 Option A pros and cons

   In Option A: back-to-back VRF. The PE-ASBR in one AS performs MPLS or
   IP VPN de-encapsulation and transmits packets to the peer PE-ASBR in
   the adjacent AS. The peer PE-ASBR performs MPLS or IP VPN
   encapsulation on the customer IPv4/IPv6 packets received, and
   transmits the packet through the IP backbone of the AS. VPN service
   providers exchange routes across a back-to-back VRF connection. Each
   VRF instance represents a separate VPN client, and it is configured
   on a separate PE-ASBR interface, allowing a PE-ASBR to communicate
   with its peer PE-ASBR as if the peer was a CE router.

   Pros: This is the most secure option among options A, B, and C. And
   it is the simplest model from operation perspective. Each PE-ASBR is
   treating the other as a CE.

   Cons: This option suffers from scaling limitations, because per
   Inter-AS VPN VRF and interface are needed on the PE-ASBR.

   Option A has been commonly used in BGP/MPLS VPN Inter-Provider inter-
 


Fang et al.              Expires <Sept 9, 2015>                 [Page 8]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>           <March 9, 2014>


   connections because of the security considerations and its clear
   operational demarcation.

   DCI considerations: This is a simple way to connect DC and WAN if
   both sides are of small scale. Scale will be the major concern for DC
   inter-connect if large scale support is needed. Even if the DC scale
   is small, there are major concerns on receiving relevant routes
   (potentially a large number) from the WAN side, and Vice Versa.

4.1.2 Option B pros and cons

   In Option B: EBGP redistribution of labeled VPN-IPv4/IPv6 routes
   between the neighboring ASes. ASes exchange VPN routing information
   (routes and labels) to establish connections. To control connections
   between ASes, the PE routers and EBGP border edge routers maintain a
   label forwarding information base (LFIB). The LFIB manages the labels
   and routes that the PE routers and EBGP border edge routers receive
   during the exchange of VPN information. The ASes exchange VPN routing
   information, such as, the destination network, the next hop field
   associated with the distributing router, a local MPLS label, and an
   RD. ASBRs are configured to change the next hop (next-hop-self) when
   sending VPN-IPv4 NLRIs to the IBGP neighbors; the ASBRs must allocate
   a new label when they forward the NLRI to the IBGP neighbors.

   Pros: It provides improved scalability when compared with option A,
   since it removes the needs of per Inter-AS VPN VRF and interface on
   the ASBR.

   Cons: vanilla version of Option B is considered less secure in
   comparison with Option A, due to the dynamic routing information
   exchange that is involved. The ASBR scaling may still be an issue
   because ASBR must maintain all VPN routes.

   Option B is commonly used within single provider or for inter-
   provider connections.

   DCI considerations: Option B is one viable option to be used in DC
   inter-connection. However, it has the same scale concerns as other
   options because of the potentially large number of routes exchanged
   between the WAN and the DC.

4.1.3 Option C pros and cons

   In option C: Multihop eBGP redistribution of labeled VPN-IPv4/Ipv6
   routes between source and destination ASs, with eBGP redistribution
   of labeled IPv4/IPv6 routes from AS to neighboring AS. The ASBRs need
   only to exchange host routes (/32 or /128) to the PE routers involved
   in the VPN, with the labels needed to get there. A Label Switch Path
 


Fang et al.              Expires <Sept 9, 2015>                 [Page 9]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>           <March 9, 2014>


   (LSP) is built from the ingress PE router in one AS to the egress PE
   in the other AS (using Loopback addresses). VPN traffic uses this LSP
   to reach the other AS. From data plane's perspective, the ASBRs act
   as P routers, with no knowledge about the VPNs concerned. Between the
   two inter-connecting ASBRs, the VPN traffic is treated just as
   between two P routers, each VPN data packet is pre-pended with the
   VPN label and then with an egress-PE label. Option C can be further
   scaled by using route reflectors (RRs) in each AS.

   Pros:It is the most scalable option among all three. ASBR is no
   longer a bottle neck for VPN routes scaling as in Option B.

   Cons: Major security issues as IGP reachability must be exchanged
   between the inter-connecting ASes.

   Option C has seen used within a single SP for inter-AS connections.
   Using RR for VPN routes exchange is the common approach.

   DCI consideration: Option C SHOULD NOT be used for any DCI which is
   between two different providers for security reasons.

   In this option, though ASBR is not longer the scaling bottleneck, the
   scaling issues still call for careful design, as the total numbers of
   VRFs, VPN interfaces, and the VPN routes being exchanged between the
   two ASes can be very large.

4.1.4 Use of RTC

   RT constraint [RFC4684] function must be used to only distribute the
   IP VPN routes of a VPN from one AS to another under the condition
   that they both support that VPN in each of the AS. This is one most
   important function for scalable solution.

   However, all IP VPN routes are exchanged between the two ASes (e.g.
   WAN and DC) as long as they have to support the same VPNs. The
   potential IP VPN routes distribution can still be very substantial in
   large WAN and DC deployment. Additional aggregation and abstraction
   mechnisms can be used to avoid large numbers of VPN routes being
   exchanges across the border between the interconnecting WAN and the
   DC in either directions.

4.2 Carriers' carrier model

   A BGP/MPLS IP VPN is implemented between DCs in the WAN side. The DCs
   connected through the WAN belong to the same AS. Now the CE routers
   in the DCs are responsible of establishing a BGP session among them
   for advertising between DCs the routes external to the DCs, since now
   such responsibility lays on the Cloud/Content provider.
 


Fang et al.              Expires <Sept 9, 2015>                [Page 10]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>           <March 9, 2014>


   The Cloud Provider can establish its own VPN services that can be
   extended including dispersed DCs.

   The SP will not be involved in the routing of the VPN services
   implemented in the DCs; it will just provide MPLS connectivity
   between them. In the same way, the DC will not require to routing
   information from the SP (only the corresponding local PE). 

   Pros: The SP does not require getting knowledge of the routes for the
   carried VPN. <analysis to be completed>

   Cons: The equipment within the DCs should support MPLS. <analysis to
   be completed>

   DCI considerations: The equipment within the DCs should support MPLS.


5. Inter-connect IP VPN and non-IP VPN overlay networks

   As one significant instance of the hybrid use-case described in
   section 2.2, a DC may support a multi-tenant virtualized service
   network using IP based DC overlay encapsulations such as VXLAN
   [I-D.mahalingam-dutt-dcops-vxlan] or NVGRE
   [I-D.sridharan-virtualization-nvgre]. Different deployment models may
   be used within the DC depending on the DC provider's functional and
   operational requirements.

   When an IP DC overlay is terminated at the DC Gateway router and
   traffic directed into a BGP/MPLS IP VPN, the DC Gateway router
   performs MPLS encapsulation towards the WAN and IP overlay based
   forwarding within the DC.

   The inter-connection mechanisms between the DC and the WAN may fall
   into two categories:

   1. VRF Termination

   The overlay based virtual network terminates into a BGP IP VPN VRF at
   the DC-WAN Gateway router. Both the internal routes of the DC as well
   as the external routes received from the WAN router can be installed
   in the VRF forwarding table at the DC Gateway router. The DC Gateway
   performs an IP lookup, appropriate MPLS or IP encapsulation, and
   forward traffic.

   The DC Gateway router peers with the WAN router using one of the
   existing inter-AS mechanisms described above. The DC Gateway
   functions as an IP-VPN ASBR with local VRFs; for example, packets
   still undergo an IP forwarding lookup.
 


Fang et al.              Expires <Sept 9, 2015>                [Page 11]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>           <March 9, 2014>


   2. DC-VN and IP VPN Inter-working

   In this case, the DC Gateway router performs a direct translation
   between VN-IDs and IP VPN labels while switching packets between the
   DC and WAN interfaces without performing an IP lookup. The forwarding
   table at the DC Gateway router is set up to do a VN-ID or label
   lookup and derive the output label or VN-ID. The DC Gateway Router
   acts as an Inter-AS Option B ASBR peering with other ASBRs.

6. Security Considerations

   BGP/MPLS Inter-AS security threats and defense techniques described
   in RFC 4111 [RFC4111] are applicable for the WAN/DC inter-
   connections.

   In addition, the protocols between the Gateway routers and the
   controller/orchestrator MUST be mutually authenticated. Given the
   potentially very large scale and the dynamic nature in the cloud/DC
   environment, the choice of key management mechanisms need to be
   further studied.

7. IANA Considerations

   None.

8.  References

8.1  Normative References

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

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

   [RFC4684]  Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
              R., Patel, K., and J. Guichard, "Constrained Route
              Distribution for Border Gateway Protocol/MultiProtocol
              Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
              Private Networks (VPNs)", RFC 4684, November 2006.

8.2  Informative References

   [RFC4111]  Fang, L., Ed., "Security Framework for Provider-
              Provisioned Virtual Private Networks (PPVPNs)", RFC 4111,
              July 2005.

   [I-D.ietf-l3vpn-end-system] Marques, P., Fang, L., Pan, P., Shukla,
 


Fang et al.              Expires <Sept 9, 2015>                [Page 12]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>           <March 9, 2014>


              A., Napierala, M., "BGP-signaled end-system IP/VPNs",
              draft-ietf-l3vpn-end-system, work in progress.

   [I-D.fang-l3vpn-virtual-pe] Fang, L., Ward, D., Fernando, R.,
              Napierala, M., Bitar, N., Rao, D., Rijsman, B., So, N.,
              "BGP IP VPN Virtual PE", draft-fang-l3vpn-virtual-pe, work
              in progress.

   [I-D.fang-l3vpn-virtual-ce] Fang, L., Evans, J., Ward, D., Fernando,
              R., Mullooly, J., So, N., Bitar., N., Napierala, M., "BGP
              IP VPN Virtual PE", draft-fang-l3vpn-virtual-ce, work in
              progress.

   [I-D.mahalingam-dutt-dcops-vxlan]: Mahalingam, M, Dutt, D.., et al.,
              "A Framework for Overlaying Virtualized Layer 2 Networks
              over Layer 3 Networks" draft-mahalingam-dutt-dcops-vxlan,
              work in progress.

   [I-D.sridharan-virtualization-nvgre]: SridharanNetwork, M., et al.,
              "Virtualization using Generic Routing Encapsulation",
              draft-sridharan-virtualization-nvgre, work in progress.

Authors' Addresses

   Luyuan Fang
   Microsoft
   5600 148th Ave NE
   Redmond, WA 98052
   Email: lufang@microsoft.com

   Luis M. Contreras
   Telefonica
   Ronda de la Comunicacion, s/n
   Sur-3 building, 3rd floor
   Madrid  28050
   Spain
   Email: luismiguel.contrerasmurillo@telefonica.com
   URI:   http://people.tid.es/LuisM.Contreras/

   Daniel Voyer
   Bell Canada
   Email: daniel.voyer@bell.ca









Fang et al.              Expires <Sept 9, 2015>                [Page 13]