draft-ietf-l3vpn-virtual-subnet-00.txt   draft-ietf-l3vpn-virtual-subnet-01.txt 
Network working group X. Xu
Internet Draft Huawei
Category: Informational
R. Raszuk
Network Working Group X. Xu
Internet-Draft Huawei
Intended status: Informational R. Raszuk
Expires: March 8, 2015
S. Hares S. Hares
Y. Fan Y. Fan
China Telecom China Telecom
C. Jacquenet C. Jacquenet
Orange Orange
T. Boyes T. Boyes
Bloomberg LP Bloomberg LP
B. Fee
B Fee
Extreme Networks Extreme Networks
September 4, 2014
Expires: September 2014 March 3, 2014 Virtual Subnet: A L3VPN-based Subnet Extension Solution
draft-ietf-l3vpn-virtual-subnet-01
Virtual Subnet: A L3VPN-based Subnet Extension Solution
draft-ietf-l3vpn-virtual-subnet-00
Abstract Abstract
This document describes a Layer3 Virtual Private Network (L3VPN)- This document describes a Layer3 Virtual Private Network (L3VPN)-
based subnet extension solution referred to as Virtual Subnet, which based subnet extension solution referred to as Virtual Subnet, which
can be used as a kind of Layer3 network virtualization overlay can be used for building Layer3 network virtualization overlays
approach for data center interconnect. within and/or across data centers.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on March 8, 2015.
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 September 3, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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 RFC-2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction ................................................ 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology ................................................. 6 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Solution Description......................................... 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Unicast ................................................ 6 3. Solution Description . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Intra-subnet Unicast .............................. 6 3.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Inter-subnet Unicast .............................. 7 3.1.1. Intra-subnet Unicast . . . . . . . . . . . . . . . . 5
3.2. Multicast .............................................. 9 3.1.2. Inter-subnet Unicast . . . . . . . . . . . . . . . . 6
3.3. CE Host Discovery ..................................... 10 3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. ARP/ND Proxy .......................................... 10 3.3. CE Host Discovery . . . . . . . . . . . . . . . . . . . . 9
3.5. CE Host Mobility ...................................... 10 3.4. ARP/ND Proxy . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Forwarding Table Scalability on Data Center Switches .. 11 3.5. CE Host Mobility . . . . . . . . . . . . . . . . . . . . 9
3.7. ARP/ND Cache Table Scalability on Default Gateways .... 11 3.6. Forwarding Table Scalability on Data Center Switches . . 10
3.8. ARP/ND and Unknown Uncast Flood Avoidance ............. 11 3.7. ARP/ND Cache Table Scalability on Default Gateways . . . 10
3.9. Path Optimization ..................................... 11 3.8. ARP/ND and Unknown Uncast Flood Avoidance . . . . . . . . 10
4. Limitations ................................................ 12 3.9. Path Optimization . . . . . . . . . . . . . . . . . . . . 10
4.1. Non-support of Non-IP Traffic ......................... 12 4. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Non-support of IP Broadcast and Link-local Multicast .. 12 4.1. Non-support of Non-IP Traffic . . . . . . . . . . . . . . 11
4.3. TTL and Traceroute .................................... 13 4.2. Non-support of IP Broadcast and Link-local Multicast . . 11
5. Security Considerations .................................... 13 4.3. TTL and Traceroute . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations ........................................ 13 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements ........................................... 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References ................................................. 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References .................................. 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References ................................ 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses ............................................ 14 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
For business continuity purposes, Virtual Machine (VM) migration For business continuity purpose, Virtual Machine (VM) migration
across data centers is commonly used in those situations such as data across data centers is commonly used in those situations such as data
center maintenance, data center migration, data center consolidation, center maintenance, data center migration, data center consolidation,
data center expansion, and data center disaster avoidance. It's data center expansion, and data center disaster avoidance. It's
generally admitted that IP renumbering of servers (i.e., VMs) after generally admitted that IP renumbering of servers (i.e., VMs) after
the migration is usually complex and costly at the risk of extending the migration is usually complex and costly at the risk of extending
the business downtime during the process of migration. To allow the the business downtime during the process of migration. To allow the
migration of a VM from one data center to another without IP migration of a VM from one data center to another without IP
renumbering, the subnet on which the VM resides needs to be extended renumbering, the subnet on which the VM resides needs to be extended
across these data centers. across these data centers.
In Infrastructure-as-a-Service (IaaS) cloud data center environments, To achieve subnet extension across multiple Infrastructure-as-
to achieve subnet extension across multiple data centers in a a-Service (IaaS) cloud data centers in a scalable way, the following
scalable way, the following requirements SHOULD be considered for any requirements and challenges must be considered:
data center interconnect solution:
1) VPN Instance Space Scalability
In a modern cloud data center environment, thousands or even tens
of thousands of tenants could be hosted over a shared network
infrastructure. For security and performance isolation purposes,
these tenants need to be isolated from one another. Hence, the
data center interconnect solution SHOULD be capable of providing a
large enough Virtual Private Network (VPN) instance space for
tenant isolation.
2) Forwarding Table Scalability
With the development of server virtualization technologies, a
single cloud data center containing millions of VMs is not
uncommon. This number already implies a big challenge for data
center switches, especially for core/aggregation switches, from
the perspective of forwarding table scalability. Provided that
multiple data centers of such scale were interconnected at layer2,
this challenge would be even worse. Hence an ideal data center
interconnect solution SHOULD prevent the forwarding table size of
data center switches from growing by folds as the number of data
centers to be interconnected increases.
3) ARP/ND Cache Table Scalability on Default Gateways
[RFC6820] notes that the Address Resolution Protocol a. VPN Instance Space Scalability: In a modern cloud data center
(ARP)/Neighbor Discovery (ND) cache tables maintained by data environment, thousands or even tens of thousands of tenants could
center default gateways in cloud data centers can raise both be hosted over a shared network infrastructure. For security and
scalability and security issues. Therefore, an ideal data center performance isolation purposes, these tenants need to be isolated
interconnect solution SHOULD prevent the ARP/ND cache table size from one another.
from growing by multiples as the number of data centers to be
connected increases.
4) ARP/ND and Unknown Unicast Flood Suppression or Avoidance b. Forwarding Table Scalability: With the development of server
virtualization technologies, it's not uncommon for a single cloud
data center to contain millions of VMs. This number already
implies a big challenge on the forwarding table scalability of
data center switches. Provided multiple data centers of such
scale were interconnected at layer2, this challenge would become
even worse.
It's well-known that the flooding of Address Resolution Protocol c. ARP/ND Cache Table Scalability: [RFC6820] notes that the Address
(ARP)/Neighbor Discovery (ND) broadcast/multicast and unknown Resolution Protocol (ARP)/Neighbor Discovery (ND) cache tables
unicast traffic within a large Layer2 network are likely to affect maintained on default gateways within cloud data centers can
performances of networks and hosts. As multiple data centers each raise scalability issues. Therefore, it's very useful if the
containing millions of VMs are interconnected together across the ARP/ND cache table size could be prevented from growing by
Wide Area Network (WAN) at layer2, the impact of flooding as multiples as the number of data centers to be connected
mentioned above will become even worse. As such, it becomes increases.
increasingly desirable for data center operators to suppress or
even avoid the flooding of ARP/ND broadcast/multicast and unknown
unicast traffic across data centers.
5) Path Optimization d. ARP/ND and Unknown Unicast Flooding: It's well-known that the
flooding of ARP/ND broadcast/multicast and unknown unicast
traffic within large Layer2 networks would affect the performance
of networks and hosts. As multiple data centers with each
containing millions of VMs are interconnected at layer2, the
impact of flooding as mentioned above would become even worse.
As such, it becomes increasingly important to avoid the flooding
of ARP/ND broadcast/multicast and unknown unicast traffic across
data centers.
A subnet usually indicates a location in the network. However, e. Path Optimization: A subnet usually indicates a location in the
when a subnet has been extended across multiple geographically network. However, when a subnet has been extended across
dispersed data center locations, the location semantics of such multiple geographically dispersed data center locations, the
subnet is not retained any longer. As a result, the traffic from a location semantics of such subnet is not retained any longer. As
cloud user (i.e., a VPN user) which is destined for a given server a result, the traffic from a cloud user (i.e., a VPN user) which
located at one data center location of such extended subnet may is destined for a given server located at one data center
arrive at another data center location firstly according to the location of such extended subnet may arrive at another data
subnet route, and then be forwarded to the location where the center location firstly according to the subnet route, and then
service is actually located. This suboptimal routing would be forwarded to the location where the service is actually
obviously result in the unnecessary consumption of the bandwidth located. This suboptimal routing would obviously result in an
resources which are intended for data center interconnection. unnecessary consumption of the bandwidth resource between data
Furthermore, in the case where the traditional VPLS technology centers. Furthermore, in the case where the traditional VPLS
[RFC4761, RFC4762] is used for data center interconnect and technology [RFC4761] [RFC4762] is used for data center
default gateways of different data center locations are configured interconnect and default gateways of different data center
within the same virtual router redundancy group, the returning locations are configured within the same virtual router
traffic from that server to the cloud user may be forwarded at redundancy group, the returning traffic from that server to the
layer2 to a default gateway located at one of the remote data cloud user may be forwarded at layer2 to a default gateway
center premises, rather than the one placed at the local data located at one of the remote data center premises, rather than
center location. This suboptimal routing would also unnecessarily the one placed at the local data center location. This
consume the bandwidth resources which are intended for data center suboptimal routing would also unnecessarily consume the bandwidth
interconnect. resource between data centers
This document describes a L3VPN-based subnet extension solution This document describes a L3VPN-based subnet extension solution
referred to as Virtual Subnet (VS), which can meet all of the referred to as Virtual Subnet (VS), which can be used for data center
requirements of cloud data center interconnect as described above. interconnection while addressing all of the requirements and
Since VS mainly reuses existing technologies including BGP/MPLS IP challenges as mentioned above. In addition, since VS is mainly built
VPN [RFC4364] and ARP/ND proxy [RFC925][RFC1027][RFC4389], it allows on proven technologies such as BGP/MPLS IP VPN [RFC4364] and ARP/ND
those service providers offering IaaS public cloud services to proxy [RFC0925][RFC1027][RFC4389], those service providers offering
interconnect their geographically dispersed data centers in a much IaaS public cloud services could rely upon their existing BGP/MPLS IP
scalable way, and more importantly, data center interconnection VPN infrastructures and their corresponding experiences to realize
design can rely upon their existing MPLS/BGP IP VPN infrastructures data center interconnection.
and their experiences in the delivery and the operation of MPLS/BGP
IP VPN services.
Although Virtual Subnet is described as a data center interconnection Although Virtual Subnet is described in this document as an approach
solution in this document, there is no reason to assume that this for data center interconnection, it actually could be used within
technology couldn't be used within data centers. data centers as well.
Note that the approach described in this document is not intended to Note that the approach described in this document is not intended to
achieve an exact emulation of L2 connectivity and therefore can only achieve an exact emulation of L2 connectivity and therefore it can
support a restricted L2 connectivity service model with limitations only support a restricted L2 connectivity service model with
declared in Section 4. As for the discussion about in which limitations declared in Section 4. As for the discussion about in
environment this service model should be suitable, it's outside the which environment this service model should be suitable, it's outside
scope of this document. the scope of this document.
2. Terminology 1.1. Requirements Language
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].
2. Terminology
This memo makes use of the terms defined in [RFC4364]. This memo makes use of the terms defined in [RFC4364].
3. Solution Description 3. Solution Description
3.1. Unicast 3.1. Unicast
3.1.1. Intra-subnet Unicast 3.1.1. Intra-subnet Unicast
+--------------------+
+-----------------+ | | +-----------------+
|VPN_A:1.1.1.1/24 | | | |VPN_A:1.1.1.1/24 |
| \ | | | | / |
| +------+ \++---+-+ +-+---++/ +------+ |
| |Host A+----+ PE-1 | | PE-2 +----+Host B| |
| +------+\ ++-+-+-+ +-+-+-++ /+------+ |
| 1.1.1.2/24 | | | | | | 1.1.1.3/24 |
| | | | | | | |
| DC West | | | IP/MPLS Backbone | | | DC East |
+-----------------+ | | | | +-----------------+
| +--------------------+ |
| |
VRF_A : V VRF_A : V
+------------+---------+--------+ +------------+---------+--------+
| Prefix | Nexthop |Protocol| | Prefix | Nexthop |Protocol|
+------------+---------+--------+ +------------+---------+--------+
| 1.1.1.1/32 |127.0.0.1| Direct | | 1.1.1.1/32 |127.0.0.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
| 1.1.1.2/32 | 1.1.1.2 | Direct | | 1.1.1.2/32 | PE-1 | IBGP |
+------------+---------+--------+ +------------+---------+--------+
| 1.1.1.3/32 | PE-2 | IBGP | | 1.1.1.3/32 | 1.1.1.3 | Direct |
+------------+---------+--------+ +------------+---------+--------+
| 1.1.1.0/24 | 1.1.1.1 | Direct | | 1.1.1.0/24 | 1.1.1.1 | Direct | +--------------------+
+------------+---------+--------+ +------------+---------+--------+ +-----------------+ | | +-----------------+
|VPN_A:1.1.1.1/24 | | | |VPN_A:1.1.1.1/24 |
| \ | | | | / |
| +------+ \++---+-+ +-+---++/ +------+ |
| |Host A+----+ PE-1 | | PE-2 +----+Host B| |
| +------+\ ++-+-+-+ +-+-+-++ /+------+ |
| 1.1.1.2/24 | | | | | | 1.1.1.3/24 |
| | | | | | | |
| DC West | | | IP/MPLS Backbone | | | DC East |
+-----------------+ | | | | +-----------------+
| +--------------------+ |
| |
VRF_A : V VRF_A : V
+------------+---------+--------+ +------------+---------+--------+
| Prefix | Nexthop |Protocol| | Prefix | Nexthop |Protocol|
+------------+---------+--------+ +------------+---------+--------+
| 1.1.1.1/32 |127.0.0.1| Direct | | 1.1.1.1/32 |127.0.0.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
| 1.1.1.2/32 | 1.1.1.2 | Direct | | 1.1.1.2/32 | PE-1 | IBGP |
+------------+---------+--------+ +------------+---------+--------+
| 1.1.1.3/32 | PE-2 | IBGP | | 1.1.1.3/32 | 1.1.1.3 | Direct |
+------------+---------+--------+ +------------+---------+--------+
| 1.1.1.0/24 | 1.1.1.1 | Direct | | 1.1.1.0/24 | 1.1.1.1 | Direct |
+------------+---------+--------+ +------------+---------+--------+
Figure 1: Intra-subnet Unicast Example Figure 1: Intra-subnet Unicast Example
------------+---------+--------+ +------------+---------+--------+
As shown in Figure 1, two CE hosts (i.e., Hosts A and B) belonging to As shown in Figure 1, two CE hosts (i.e., Hosts A and B) belonging to
the same subnet (i.e., 1.1.1.0/24) are located at different data the same subnet (i.e., 1.1.1.0/24) are located at different data
centers (i.e., DC West and DC East) respectively. PE routers (i.e., centers (i.e., DC West and DC East) respectively. PE routers (i.e.,
PE-1 and PE-2) which are used for interconnecting these two data PE-1 and PE-2) which are used for interconnecting these two data
centers create host routes for their local CE hosts respectively and centers create host routes for their own local CE hosts respectively
then advertise them via L3VPN signaling. Meanwhile, ARP proxy is and then advertise them via the BGP/MPLS IP VPN signaling.
enabled on VRF attachment circuits of these PE routers. Meanwhile, ARP proxy is enabled on VRF attachment circuits of these
PE routers.
Now assume host A sends an ARP request for host B before Now assume host A sends an ARP request for host B before
communicating with host B. Upon receiving the ARP request, PE-1 communicating with host B. Upon receiving the ARP request, PE-1
acting as an ARP proxy returns its own MAC address as a response. acting as an ARP proxy returns its own MAC address as a response.
Host A then sends IP packets for host B to PE-1. PE-1 tunnels such Host A then sends IP packets for host B to PE-1. PE-1 tunnels such
packets towards PE-2 which in turn forwards them to host B. Thus, packets towards PE-2 which in turn forwards them to host B. Thus,
hosts A and B can communicate with each other as if they were located hosts A and B can communicate with each other as if they were located
within the same subnet. within the same subnet.
3.1.2. Inter-subnet Unicast 3.1.2. Inter-subnet Unicast
+--------------------+
+-----------------+ | | +-----------------+ +--------------------+
|VPN_A:1.1.1.1/24 | | | |VPN_A:1.1.1.1/24 | +-----------------+ | | +-----------------+
| \ | | | | / | |VPN_A:1.1.1.1/24 | | | |VPN_A:1.1.1.1/24 |
| +------+ \++---+-+ +-+---++/ +------+ | | \ | | | | / |
| |Host A+------+ PE-1 | | PE-2 +-+----+Host B| | | +------+ \++---+-+ +-+---++/ +------+ |
| +------+\ ++-+-+-+ +-+-+-++ | /+------+ | | |Host A+------+ PE-1 | | PE-2 +-+----+Host B| |
| 1.1.1.2/24 | | | | | | | 1.1.1.3/24 | | +------+\ ++-+-+-+ +-+-+-++ | /+------+ |
| GW=1.1.1.4 | | | | | | | GW=1.1.1.4 | | 1.1.1.2/24 | | | | | | | 1.1.1.3/24 |
| | | | | | | | +------+ | | GW=1.1.1.4 | | | | | | | GW=1.1.1.4 |
| | | | | | | +----+ GW +--| | | | | | | | | +------+ |
| | | | | | | /+------+ | | | | | | | | +----+ GW +--|
| | | | | | | 1.1.1.4/24 | | | | | | | | /+------+ |
| | | | | | | | | | | | | | | 1.1.1.4/24 |
| DC West | | | IP/MPLS Backbone | | | DC East | | | | | | | | |
+-----------------+ | | | | +-----------------+ | DC West | | | IP/MPLS Backbone | | | DC East |
| +--------------------+ | +-----------------+ | | | | +-----------------+
| | | +--------------------+ |
VRF_A : V VRF_A : V | |
+------------+---------+--------+ +------------+---------+--------+ VRF_A : V VRF_A : V
| Prefix | Nexthop |Protocol| | Prefix | Nexthop |Protocol| +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | Prefix | Nexthop |Protocol| | Prefix | Nexthop |Protocol|
| 1.1.1.1/32 |127.0.0.1| Direct | | 1.1.1.1/32 |127.0.0.1| Direct | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 1.1.1.1/32 |127.0.0.1| Direct | | 1.1.1.1/32 |127.0.0.1| Direct |
| 1.1.1.2/32 | 1.1.1.2 | Direct | | 1.1.1.2/32 | PE-1 | IBGP | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 1.1.1.2/32 | 1.1.1.2 | Direct | | 1.1.1.2/32 | PE-1 | IBGP |
| 1.1.1.3/32 | PE-2 | IBGP | | 1.1.1.3/32 | 1.1.1.3 | Direct | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 1.1.1.3/32 | PE-2 | IBGP | | 1.1.1.3/32 | 1.1.1.3 | Direct |
| 1.1.1.4/32 | PE-2 | IBGP | | 1.1.1.4/32 | 1.1.1.4 | Direct | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 1.1.1.4/32 | PE-2 | IBGP | | 1.1.1.4/32 | 1.1.1.4 | Direct |
| 1.1.1.0/24 | 1.1.1.1 | Direct | | 1.1.1.0/24 | 1.1.1.1 | Direct | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 1.1.1.0/24 | 1.1.1.1 | Direct | | 1.1.1.0/24 | 1.1.1.1 | Direct |
| 0.0.0.0/0 | PE-2 | IBGP | | 0.0.0.0/0 | 1.1.1.4 | Static | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 0.0.0.0/0 | PE-2 | IBGP | | 0.0.0.0/0 | 1.1.1.4 | Static |
Figure 2: Inter-subnet Unicast Example (1) +------------+---------+--------+ +------------+---------+--------+
Figure 2: Inter-subnet Unicast Example (1)
As shown in Figure 2, only one data center (i.e., DC East) is As shown in Figure 2, only one data center (i.e., DC East) is
deployed with a default gateway (i.e., GW). PE-2 which is connected deployed with a default gateway (i.e., GW). PE-2 which is connected
to GW would either be configured with or learn from GW a default to GW would either be configured with or learn from GW a default
route with next-hop being pointed to GW. Meanwhile, this route is route with next-hop being pointed to GW. Meanwhile, this route is
distributed to other PE routers (i.e., PE-1) as per normal [RFC4364] distributed to other PE routers (i.e., PE-1) as per normal [RFC4364]
operation. Assume host A sends an ARP request for its default operation. Assume host A sends an ARP request for its default
gateway (i.e., 1.1.1.4) prior to communicating with a destination gateway (i.e., 1.1.1.4) prior to communicating with a destination
host outside of its subnet. Upon receiving this ARP request, PE-1 host outside of its subnet. Upon receiving this ARP request, PE-1
acting as an ARP proxy returns its own MAC address as a response. acting as an ARP proxy returns its own MAC address as a response.
Host A then sends a packet for Host B to PE-1. PE-1 tunnels such Host A then sends a packet for Host B to PE-1. PE-1 tunnels such
packet towards PE-2 according to the default route learnt from PE-2, packet towards PE-2 according to the default route learnt from PE-2,
which in turn forwards that packet to GW. which in turn forwards that packet to GW.
+--------------------+
+-----------------+ | | +-----------------+ +--------------------+
|VPN_A:1.1.1.1/24 | | | |VPN_A:1.1.1.1/24 | +-----------------+ | | +-----------------+
| \ | | | | / | |VPN_A:1.1.1.1/24 | | | |VPN_A:1.1.1.1/24 |
| +------+ \++---+-+ +-+---++/ +------+ | | \ | | | | / |
| |Host A+----+-+ PE-1 | | PE-2 +-+----+Host B| | | +------+ \++---+-+ +-+---++/ +------+ |
| +------+\ | ++-+-+-+ +-+-+-++ | /+------+ | | |Host A+----+-+ PE-1 | | PE-2 +-+----+Host B| |
| 1.1.1.2/24 | | | | | | | | 1.1.1.3/24 | | +------+\ | ++-+-+-+ +-+-+-++ | /+------+ |
| GW=1.1.1.4 | | | | | | | | GW=1.1.1.4 | | 1.1.1.2/24 | | | | | | | | 1.1.1.3/24 |
| +------+ | | | | | | | | +------+ | | GW=1.1.1.4 | | | | | | | | GW=1.1.1.4 |
|--+ GW-1 +----+ | | | | | | +----+ GW-2 +--| | +------+ | | | | | | | | +------+ |
| +------+\ | | | | | | /+------+ | |--+ GW-1 +----+ | | | | | | +----+ GW-2 +--|
| 1.1.1.4/24 | | | | | | 1.1.1.4/24 | | +------+\ | | | | | | /+------+ |
| | | | | | | | | 1.1.1.4/24 | | | | | | 1.1.1.4/24 |
| DC West | | | IP/MPLS Backbone | | | DC East | | | | | | | | |
+-----------------+ | | | | +-----------------+ | DC West | | | IP/MPLS Backbone | | | DC East |
| +--------------------+ | +-----------------+ | | | | +-----------------+
| | | +--------------------+ |
VRF_A : V VRF_A : V | |
+------------+---------+--------+ +------------+---------+--------+ VRF_A : V VRF_A : V
| Prefix | Nexthop |Protocol| | Prefix | Nexthop |Protocol| +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | Prefix | Nexthop |Protocol| | Prefix | Nexthop |Protocol|
| 1.1.1.1/32 |127.0.0.1| Direct | | 1.1.1.1/32 |127.0.0.1| Direct | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 1.1.1.1/32 |127.0.0.1| Direct | | 1.1.1.1/32 |127.0.0.1| Direct |
| 1.1.1.2/32 | 1.1.1.2 | Direct | | 1.1.1.2/32 | PE-1 | IBGP | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 1.1.1.2/32 | 1.1.1.2 | Direct | | 1.1.1.2/32 | PE-1 | IBGP |
| 1.1.1.3/32 | PE-2 | IBGP | | 1.1.1.3/32 | 1.1.1.3 | Direct | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 1.1.1.3/32 | PE-2 | IBGP | | 1.1.1.3/32 | 1.1.1.3 | Direct |
| 1.1.1.4/32 | 1.1.1.4 | Direct | | 1.1.1.4/32 | 1.1.1.4 | Direct | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 1.1.1.4/32 | 1.1.1.4 | Direct | | 1.1.1.4/32 | 1.1.1.4 | Direct |
| 1.1.1.0/24 | 1.1.1.1 | Direct | | 1.1.1.0/24 | 1.1.1.1 | Direct | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 1.1.1.0/24 | 1.1.1.1 | Direct | | 1.1.1.0/24 | 1.1.1.1 | Direct |
| 0.0.0.0/0 | 1.1.1.4 | Static | | 0.0.0.0/0 | 1.1.1.4 | Static | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 0.0.0.0/0 | 1.1.1.4 | Static | | 0.0.0.0/0 | 1.1.1.4 | Static |
Figure 3: Inter-subnet Unicast Example (2) +------------+---------+--------+ +------------+---------+--------+
Figure 3: Inter-subnet Unicast Example (2)
As shown in Figure 3, in the case where each data center is deployed As shown in Figure 3, in the case where each data center is deployed
with a default gateway, CE hosts will get ARP responses directly from with a default gateway, CE hosts will get ARP responses directly from
their local default gateways, rather than from their local PE routers their local default gateways, rather than from their local PE routers
when sending ARP requests for their default gateways. when sending ARP requests for their default gateways.
+------+
+------+ PE-3 +------+ +------+
+-----------------+ | +------+ | +-----------------+ +------+ PE-3 +------+
|VPN_A:1.1.1.1/24 | | | |VPN_A:1.1.1.1/24 | +-----------------+ | +------+ | +-----------------+
| \ | | | | / | |VPN_A:1.1.1.1/24 | | | |VPN_A:1.1.1.1/24 |
| +------+ \++---+-+ +-+---++/ +------+ | | \ | | | | / |
| |Host A+------+ PE-1 | | PE-2 +------+Host B| | | +------+ \++---+-+ +-+---++/ +------+ |
| +------+\ ++-+-+-+ +-+-+-++ /+------+ | | |Host A+------+ PE-1 | | PE-2 +------+Host B| |
| 1.1.1.2/24 | | | | | | 1.1.1.3/24 | | +------+\ ++-+-+-+ +-+-+-++ /+------+ |
| GW=1.1.1.1 | | | | | | GW=1.1.1.1 | | 1.1.1.2/24 | | | | | | 1.1.1.3/24 |
| | | | | | | | | GW=1.1.1.1 | | | | | | GW=1.1.1.1 |
| DC West | | | IP/MPLS Backbone | | | DC East | | | | | | | | |
+-----------------+ | | | | +-----------------+ | DC West | | | IP/MPLS Backbone | | | DC East |
| +--------------------+ | +-----------------+ | | | | +-----------------+
| | | +--------------------+ |
VRF_A : V VRF_A : V | |
+------------+---------+--------+ +------------+---------+--------+ VRF_A : V VRF_A : V
| Prefix | Nexthop |Protocol| | Prefix | Nexthop |Protocol| +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | Prefix | Nexthop |Protocol| | Prefix | Nexthop |Protocol|
| 1.1.1.1/32 |127.0.0.1| Direct | | 1.1.1.1/32 |127.0.0.1| Direct | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 1.1.1.1/32 |127.0.0.1| Direct | | 1.1.1.1/32 |127.0.0.1| Direct |
| 1.1.1.2/32 | 1.1.1.2 | Direct | | 1.1.1.2/32 | PE-1 | IBGP | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 1.1.1.2/32 | 1.1.1.2 | Direct | | 1.1.1.2/32 | PE-1 | IBGP |
| 1.1.1.3/32 | PE-2 | IBGP | | 1.1.1.3/32 | 1.1.1.3 | Direct | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 1.1.1.3/32 | PE-2 | IBGP | | 1.1.1.3/32 | 1.1.1.3 | Direct |
| 1.1.1.0/24 | 1.1.1.1 | Direct | | 1.1.1.0/24 | 1.1.1.1 | Direct | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 1.1.1.0/24 | 1.1.1.1 | Direct | | 1.1.1.0/24 | 1.1.1.1 | Direct |
| 0.0.0.0/0 | PE-3 | IBGP | | 0.0.0.0/0 | PE-3 | IBGP | +------------+---------+--------+ +------------+---------+--------+
+------------+---------+--------+ +------------+---------+--------+ | 0.0.0.0/0 | PE-3 | IBGP | | 0.0.0.0/0 | PE-3 | IBGP |
Figure 4: Inter-subnet Unicast Example (3) +------------+---------+--------+ +------------+---------+--------+
Figure 4: Inter-subnet Unicast Example (3)
Alternatively, as shown in Figure 4, PE routers themselves could be Alternatively, as shown in Figure 4, PE routers themselves could be
directly configured as default gateways of their locally connected CE directly configured as default gateways of their locally connected CE
hosts as long as these PE routers have routes for outside networks. hosts as long as these PE routers have routes for outside networks.
3.2. Multicast 3.2. Multicast
To support IP multicast between CE hosts of the same virtual subnet, To support IP multicast between CE hosts of the same virtual subnet,
MVPN technology [MVPN] could be directly reused. For example, PE MVPN technologies [RFC6513] could be directly used without any
routers attached to a given VPN join a default provider multicast change. For example, PE routers attached to a given VPN join a
distribution tree which is dedicated for that VPN. Ingress PE routers, default provider multicast distribution tree which is dedicated for
upon receiving multicast packets from their local CE hosts, forward that VPN. Ingress PE routers, upon receiving multicast packets from
them towards remote PE routers through the corresponding default their local CE hosts, forward them towards remote PE routers through
provider multicast distribution tree. the corresponding default provider multicast distribution tree.
More details about how to support multicast and broadcast in VS will
be explored in a later version of this document.
3.3. CE Host Discovery 3.3. CE Host Discovery
PE routers SHOULD be able to discover their local CE hosts and keep PE routers SHOULD be able to discover their local CE hosts and keep
the list of these hosts up to date in a timely manner so as to ensure the list of these hosts up to date in a timely manner so as to ensure
the availability and accuracy of the corresponding host routes the availability and accuracy of the corresponding host routes
originated from them. PE routers could accomplish local CE host originated from them. PE routers could accomplish local CE host
discovery by some traditional host discovery mechanisms using ARP or discovery by some traditional host discovery mechanisms using ARP or
ND protocols. Furthermore, Link Layer Discovery Protocol (LLDP) ND protocols. Furthermore, Link Layer Discovery Protocol (LLDP) or
described in [802.1AB] or VSI Discovery and Configuration Protocol VSI Discovery and Configuration Protocol (VDP), or even interaction
(VDP) described in [802.1Qbg], or even interaction with the data with the data center orchestration system could also be considered as
center orchestration system could also be considered as a means to a means to dynamically discover local CE hosts
dynamically discover local CE hosts.
3.4. ARP/ND Proxy 3.4. ARP/ND Proxy
Acting as an ARP or ND proxies, a PE routers SHOULD only respond to Acting as an ARP or ND proxies, a PE routers SHOULD only respond to
an ARP request or Neighbor Solicitation (NS) message for a target an ARP request or Neighbor Solicitation (NS) message for a target
host when it has a best route for that target host in the associated host when it has a best route for that target host in the associated
VRF and the outgoing interface of that best route is different from VRF and the outgoing interface of that best route is different from
the one over which the ARP request or NS message is received. the one over which the ARP request or NS message is received. In the
scenario where a given VPN site (i.e., a data center) is multi-homed
In the scenario where a given VPN site (i.e., a data center) is to more than one PE router via an Ethernet switch or an Ethernet
multi-homed to more than one PE router via an Ethernet switch or an network, Virtual Router Redundancy Protocol (VRRP) [RFC5798] is
Ethernet network, Virtual Router Redundancy Protocol (VRRP) [RFC5798] usually enabled on these PE routers. In this case, only the PE
is usually enabled on these PE routers. In this case, only the PE
router being elected as the VRRP Master is allowed to perform the router being elected as the VRRP Master is allowed to perform the
ARP/ND proxy function. ARP/ND proxy function.
3.5. CE Host Mobility 3.5. CE Host Mobility
During the VM migration process, the PE router to which the moving VM During the VM migration process, the PE router to which the moving VM
is now attached would create a host route for that CE host upon is now attached would create a host route for that CE host upon
receiving a notification message of VM attachment (e.g., a gratuitous receiving a notification message of VM attachment (e.g., a gratuitous
ARP or unsolicited NA message). The PE router to which the moving VM ARP or unsolicited NA message). The PE router to which the moving VM
was previously attached would withdraw the corresponding host route was previously attached would withdraw the corresponding host route
when receiving a notification message of VM detachment (e.g., a VDP when receiving a notification message of VM detachment (e.g., a VDP
message about VM detachment). Meanwhile, the latter PE router could message about VM detachment). Meanwhile, the latter PE router could
optionally broadcast a gratuitous ARP or send an unsolicited NA optionally broadcast a gratuitous ARP or send an unsolicited NA
message on behalf of that CE host with source MAC address being one message on behalf of that CE host with source MAC address being one
of its own. In this way, the ARP/ND entry of this CE host that moved of its own. In this way, the ARP/ND entry of this CE host that moved
and which has been cached on any local CE host would be updated and which has been cached on any local CE host would be updated
accordingly. In the case where there is no explicit VM detachment accordingly. In the case where there is no explicit VM detachment
notification mechanism, the PE router could also use the following notification mechanism, the PE router could also use the following
trick to determine the VM detachment event: upon learning a route trick to determine the VM detachment event: upon learning a route
update for a local CE host from a remote PE router for the first time, update for a local CE host from a remote PE router for the first
the PE router could immediately check whether that local CE host is time, the PE router could immediately check whether that local CE
still attached to it by some means (e.g., ARP/ND PING and/or ICMP host is still attached to it by some means (e.g., ARP/ND PING and/or
PING). ICMP PING). It is important to ensure that the same MAC and IP are
associated to the default gateway active in each data center, as the
It is important to ensure that the same MAC and IP are associated to VM would most likely continue to send packets to the same default
the default gateway active in each data center, as the VM would most gateway address after migrated from one data center to another. One
likely continue to send packets to the same default gateway address possible way to achieve this goal is to configure the same VRRP group
after migrated from one data center to another. One possible way to on each location so as to ensure the default gateway active in each
achieve this goal is to configure the same VRRP group on each data center share the same virtual MAC and virtual IP addresses.
location so as to ensure the default gateway active in each data
center share the same virtual MAC and virtual IP addresses.
3.6. Forwarding Table Scalability on Data Center Switches 3.6. Forwarding Table Scalability on Data Center Switches
In a VS environment, the MAC learning domain associated with a given In a VS environment, the MAC learning domain associated with a given
virtual subnet which has been extended across multiple data centers virtual subnet which has been extended across multiple data centers
is partitioned into segments and each segment is confined within a is partitioned into segments and each segment is confined within a
single data center. Therefore data center switches only need to learn single data center. Therefore data center switches only need to
local MAC addresses, rather than learning both local and remote MAC learn local MAC addresses, rather than learning both local and remote
addresses. MAC addresses.
3.7. ARP/ND Cache Table Scalability on Default Gateways 3.7. ARP/ND Cache Table Scalability on Default Gateways
In case where data center default gateway functions are implemented When default gateway functions are implemented on PE routers as shown
on PE routers of the VS as shown in Figure 4, since the ARP/ND cache in Figure 4, the ARP/ND cache table on each PE router only needs to
table on each PE router only needs to contain ARP/ND entries of local contain ARP/ND entries of local CE hosts As a result, the ARP/ND
CE hosts, the ARP/ND cache table size will not grow as the number of cache table size would not grow as the number of data centers to be
data centers to be connected increases. connected increases.
3.8. ARP/ND and Unknown Uncast Flood Avoidance 3.8. ARP/ND and Unknown Uncast Flood Avoidance
In VS, the flooding domain associated with a given virtual subnet In VS, the flooding domain associated with a given virtual subnet
that has been extended across multiple data centers, has been that has been extended across multiple data centers, is partitioned
partitioned into segments and each segment is confined within a into segments and each segment is confined within a single data
single data center. Therefore, the performance impact on networks and center. Therefore, the performance impact on networks and servers
servers caused by the flooding of ARP/ND broadcast/multicast and imposed by the flooding of ARP/ND broadcast/multicast and unknown
unknown unicast traffic is alleviated. unicast traffic is alleviated.
3.9. Path Optimization 3.9. Path Optimization
Take the scenario shown in Figure 4 as an example, to optimize the Take the scenario shown in Figure 4 as an example, to optimize the
forwarding path for traffic between cloud users and cloud data forwarding path for the traffic between cloud users and cloud data
centers, PE routers located at cloud data centers (i.e., PE-1 and PE- centers, PE routers located at cloud data centers (i.e., PE-1 and PE-
2), which are also data center default gateways, propagate host 2), which are also acting as default gateways, propagate host routes
routes for their local CE hosts respectively to remote PE routers for their own local CE hosts respectively to remote PE routers which
which are attached to cloud user sites (i.e., PE-3). are attached to cloud user sites (i.e., PE-3). As such, the traffic
from cloud user sites to a given server on the virtual subnet which
As such, traffic from cloud user sites to a given server on the has been extended across data centers would be forwarded directly to
virtual subnet which has been extended across data centers would be the data center location where that server resides, since the traffic
forwarded directly to the data center location where that server is now forwarded according to the host route for that server, rather
resides, since traffic is now forwarded according to the host route than the subnet route. Furthermore, for the traffic coming from
for that server, rather than the subnet route. cloud data centers and forwarded to cloud user sites, each PE router
acting as a default gateway would forward the traffic according to
Furthermore, for traffic coming from cloud data centers and forwarded the best-match route in the corresponding VRF. As a result, the
to cloud user sites, each PE router acting as a default gateway would traffic from data centers to cloud user sites is forwarded along an
forward the traffic received from its local CE hosts according to the optimal path as well.
best-match route in the corresponding VRF. As a result, traffic from
data centers to cloud user sites is forwarded along the optimal path
as well.
4. Limitations 4. Limitations
4.1. Non-support of Non-IP Traffic 4.1. Non-support of Non-IP Traffic
Although most traffic within and across data centers is IP traffic, Although most traffic within and across data centers is IP traffic,
there may still be a few legacy clustering applications which rely on there may still be a few legacy clustering applications which rely on
non-IP communications (e.g., heartbeat messages between cluster non-IP communications (e.g., heartbeat messages between cluster
nodes). Since Virtual Subnet is strictly based on L3 forwarding, nodes). Since Virtual Subnet is strictly based on L3 forwarding,
those non-IP communications cannot be supported in the Virtual Subnet those non-IP communications cannot be supported in the Virtual Subnet
solution. In order to support those few non-IP traffic (if present) solution. In order to support those few non-IP traffic (if present)
in the environment where the Virtual Subnet solution has been in the environment where the Virtual Subnet solution has been
deployed, the approach following the idea of "route all IP traffic, deployed, the approach following the idea of "route all IP traffic,
bridge non-IP traffic" could be considered. That's to say, all IP bridge non-IP traffic" could be considered. That's to say, all IP
traffic including both intra-subnet and inter-subnet would be traffic including both intra-subnet and inter-subnet would be
processed by the Virtual Subnet process, while the non-IP traffic processed by the Virtual Subnet process, while the non-IP traffic
would be resorted to a particular Layer2 VPN approach. Such unified would be resorted to a particular Layer2 VPN approach. Such unified
L2/L3 VPN approach requires ingress PE routers to classify the L2/L3 VPN approach requires ingress PE routers to classify the
traffic received from CE hosts before distributing them to the traffic received from CE hosts before distributing them to the
corresponding L2 or L3 VPN forwarding processes. corresponding L2 or L3 VPN forwarding processes. Note that more and
more cluster vendors are offering clustering applications based on
Note that more and more cluster vendors are offering clustering Layer 3 interconnection.
applications based on Layer 3 interconnection.
4.2. Non-support of IP Broadcast and Link-local Multicast 4.2. Non-support of IP Broadcast and Link-local Multicast
As illustrated before, intra-subnet traffic is forwarded at Layer3 in As illustrated before, intra-subnet traffic is forwarded at Layer3 in
the Virtual Subnet solution. Therefore, IP broadcast and link-local the Virtual Subnet solution. Therefore, IP broadcast and link-local
multicast traffic cannot be supported by the Virtual Subnet solution. multicast traffic cannot be supported by the Virtual Subnet solution.
In order to support the IP broadcast and link-local multicast traffic In order to support the IP broadcast and link-local multicast traffic
in the environment where the Virtual Subnet solution has been in the environment where the Virtual Subnet solution has been
deployed, the unified L2/L3 overlay approach as described in Section deployed, the unified L2/L3 overlay approach as described in
4.1 could be considered as well. That's to say, the IP broadcast and Section 4.1 could be considered as well. That's to say, the IP
link-local multicast would be resorted to the L2VPN forwarding broadcast and link-local multicast would be resorted to the L2VPN
process while the routable IP traffic would be processed by the forwarding process while the routable IP traffic would be processed
Virtual Subnet process. by the Virtual Subnet process.
4.3. TTL and Traceroute 4.3. TTL and Traceroute
As illustrated before, intra-subnet traffic is forwarded at Layer3 in As illustrated before, intra-subnet traffic is forwarded at Layer3 in
the Virtual Subnet context. Since it doesn't require any change to the Virtual Subnet context. Since it doesn't require any change to
the TTL handling mechanism of the BGP/MPLS IP VPN, when doing a the TTL handling mechanism of the BGP/MPLS IP VPN, when doing a
traceroute operation on one CE host for another CE host (assuming traceroute operation on one CE host for another CE host (assuming
that these two hosts are within the same subnet but are attached to that these two hosts are within the same subnet but are attached to
different sites), the traceroute output would reflect the fact that different sites), the traceroute output would reflect the fact that
these two hosts belonging to the same subnet are actually connected these two hosts belonging to the same subnet are actually connected
via an virtual subnet emulated by ARP proxy, rather than a normal LAN. via an virtual subnet emulated by ARP proxy, rather than a normal
In addition, for any other applications which generate intra-subnet LAN. In addition, for any other applications which generate intra-
traffic with TTL set to 1, these applications may not be workable in subnet traffic with TTL set to 1, these applications may not be
the Virtual Subnet context, unless special TTL processing for such workable in the Virtual Subnet context, unless special TTL processing
case has been implemented (e.g., if the source and destination for such case has been implemented (e.g., if the source and
addresses of a packet whose TTL is set to 1 belong to the same destination addresses of a packet whose TTL is set to 1 belong to the
extended subnet, both ingress and egress PE routers MUST NOT same extended subnet, both ingress and egress PE routers MUST NOT
decrement the TTL of such packet. Furthermore, the TTL of such packet decrement the TTL of such packet. Furthermore, the TTL of such
SHOULD NOT be copied into the TTL of the transport tunnel and vice packet SHOULD NOT be copied into the TTL of the transport tunnel and
versa). vice versa).
5. Security Considerations
This document doesn't introduce additional security risk to BGP/MPLS
IP VPN, nor does it provide any additional security feature for
BGP/MPLS IP VPN.
6. IANA Considerations
There is no requirement for any IANA action.
7. Acknowledgements 5. Acknowledgements
Thanks to Dino Farinacci, Himanshu Shah, Nabil Bitar, Giles Heron, Thanks to Dino Farinacci, Himanshu Shah, Nabil Bitar, Giles Heron,
Ronald Bonica, Monique Morrow, Rajiv Asati, Eric Osborne, Thomas Ronald Bonica, Monique Morrow, Rajiv Asati, Eric Osborne, Thomas
Morin, Martin Vigoureux, Pedro Roque Marque, Joe Touch and Wim Morin, Martin Vigoureux, Pedro Roque Marque, Joe Touch and Wim
Henderickx for their valuable comments and suggestions on this Henderickx for their valuable comments and suggestions on this
document. document.
8. References 6. IANA Considerations
8.1. Normative References There is no requirement for any IANA action.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 7. Security Considerations
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References This document doesn't introduce additional security risk to BGP/MPLS
IP VPN, nor does it provide any additional security feature for BGP/
MPLS IP VPN.
[RFC4364] Rosen. E and Y. Rekhter, "BGP/MPLS IP Virtual Private 8. References
Networks (VPNs)", RFC 4364, February 2006.
[MVPN] Rosen. E and Aggarwal. R, "Multicast in MPLS/BGP IP VPNs", 8.1. Normative References
draft-ietf-l3vpn-2547bis-mcast-10.txt, Work in Progress,
Janurary 2010.
[RFC925] Postel, J., "Multi-LAN Address Resolution", RFC-925, USC [RFC0925] Postel, J., "Multi-LAN address resolution", RFC 925,
Information Sciences Institute, October 1984. October 1984.
[RFC1027] Smoot Carl-Mitchell, John S. Quarterman, "Using ARP to [RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to
Implement Transparent Subnet Gateways", RFC 1027, October implement transparent subnet gateways", RFC 1027, October
1987. 1987.
[RFC4389] D. Thaler, M. Talwar, and C. Patel, "Neighbor Discovery [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Proxies (ND Proxy) ", RFC 4389, April 2006. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5798] S. Nadas., "Virtual Router Redundancy Protocol", RFC 5798, [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
March 2010. Networks (VPNs)", RFC 4364, February 2006.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC Proxies (ND Proxy)", RFC 4389, April 2006.
4761, January 2007.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling", (VPLS) Using BGP for Auto-Discovery and Signaling", RFC
RFC 4762, January 2007. 4761, January 2007.
[802.1AB] IEEE Standard 802.1AB-2009, "Station and Media Access [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
Control Connectivity Discovery", September 17, 2009. (VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
[802.1Qbg] IEEE Draft Standard P802.1Qbg/D2.0, "Virtual Bridged Local [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
Area Networks -Amendment XX: Edge Virtual Bridging", Work Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
in Progress, December 1, 2011.
[RFC6820] Narten, T., Karir, M., and I. Foo, "Problem Statement for [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
ARMD", RFC 6820, January 2013. VPNs", RFC 6513, February 2012.
8.2. Informative References
[RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution
Problems in Large Data Center Networks", RFC 6820, January
2013.
Authors' Addresses Authors' Addresses
Xiaohu Xu Xiaohu Xu
Huawei Technologies, Huawei
Beijing, China.
Phone: +86 10 60610041
Email: xuxiaohu@huawei.com Email: xuxiaohu@huawei.com
Robert Raszuk Robert Raszuk
Email: robert@raszuk.net Email: robert@raszuk.net
Susan Hares Susan Hares
Email: shares@ndzh.com Email: shares@ndzh.com
Yongbing Fan Yongbing Fan
Guangzhou Institute, China Telecom China Telecom
Guangzhou, China.
Phone: +86 20 38639121
Email: fanyb@gsta.com Email: fanyb@gsta.com
Christian Jacquenet Christian Jacquenet
Orange Orange
Rennes France
Email: christian.jacquenet@orange.com
Email: christian.jacquenet@orange.com
Truman Boyes Truman Boyes
Bloomberg LP Bloomberg LP
Phone: +1 2126174826
Email: tboyes@bloomberg.net Email: tboyes@bloomberg.net
Brendan Fee Brendan Fee
Extreme Networks Extreme Networks
9 Northeastern Blvd.
Salem, NH, 03079
Email: bfee@enterasys.com Email: bfee@enterasys.com
 End of changes. 108 change blocks. 
452 lines changed or deleted 409 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/