doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc7814.txt b/doc/rfc/rfc7814.txt
new file mode 100644
index 0000000..82cc645
--- /dev/null
+++ b/doc/rfc/rfc7814.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                             X. Xu
+Request for Comments: 7814                           Huawei Technologies
+Category: Informational                                     C. Jacquenet
+ISSN: 2070-1721                                                   Orange
+                                                               R. Raszuk
+                                                                T. Boyes
+                                                            Bloomberg LP
+                                                                  B. Fee
+                                                        Extreme Networks
+                                                              March 2016
+
+
+   Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution
+
+Abstract
+
+   This document describes a BGP/MPLS IP VPN-based subnet extension
+   solution referred to as "Virtual Subnet", which can be used for
+   building Layer 3 network virtualization overlays within and/or
+   between data centers.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7814.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xu, et al.                    Informational                     [Page 1]
+
+RFC 7814                     Virtual Subnet                   March 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 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
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  Solution Description  . . . . . . . . . . . . . . . . . . . .   5
+     3.1.  Unicast . . . . . . . . . . . . . . . . . . . . . . . . .   5
+       3.1.1.  Intra-subnet Unicast  . . . . . . . . . . . . . . . .   5
+       3.1.2.  Inter-subnet Unicast  . . . . . . . . . . . . . . . .   6
+     3.2.  Multicast . . . . . . . . . . . . . . . . . . . . . . . .   8
+     3.3.  Host Discovery  . . . . . . . . . . . . . . . . . . . . .   9
+     3.4.  ARP/ND Proxy  . . . . . . . . . . . . . . . . . . . . . .   9
+     3.5.  Host Mobility . . . . . . . . . . . . . . . . . . . . . .   9
+     3.6.  Forwarding Table Scalability on Data-Center Switches  . .  10
+     3.7.  ARP/ND Cache Table Scalability on Default Gateways  . . .  10
+     3.8.  ARP/ND and Unknown Unicast Flood Avoidance  . . . . . . .  10
+     3.9.  Path Optimization . . . . . . . . . . . . . . . . . . . .  10
+   4.  Limitations . . . . . . . . . . . . . . . . . . . . . . . . .  11
+     4.1.  Non-support of Non-IP Traffic . . . . . . . . . . . . . .  11
+     4.2.  Non-support of IP Broadcast and Link-Local Multicast  . .  11
+     4.3.  TTL and Traceroute  . . . . . . . . . . . . . . . . . . .  11
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
+     6.2.  Informative References  . . . . . . . . . . . . . . . . .  13
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15
+
+
+
+
+
+
+
+
+
+
+Xu, et al.                    Informational                     [Page 2]
+
+RFC 7814                     Virtual Subnet                   March 2016
+
+
+1.  Introduction
+
+   For business continuity purposes, Virtual Machine (VM) migration
+   across data centers is commonly used in situations such as data-
+   center maintenance, migration, consolidation, expansion, or disaster
+   avoidance.  The IETF community has recognized that IP renumbering of
+   servers (i.e., VMs) after the migration is usually complex and
+   costly.  To allow the migration of a VM from one data center to
+   another without IP renumbering, the subnet on which the VM resides
+   needs to be extended across these data centers.
+
+   To achieve subnet extension across multiple cloud data centers in a
+   scalable way, the following requirements and challenges must be
+   considered:
+
+   a.  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.
+
+   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 to the forwarding table scalability of
+       data-center switches.  Provided multiple data centers of such
+       scale were interconnected at Layer 2, this challenge would become
+       even worse.
+
+   c.  ARP/ND Cache Table Scalability: [RFC6820] notes that the Address
+       Resolution Protocol (ARP) / Neighbor Discovery (ND) cache tables
+       maintained by default gateways within cloud data centers can
+       raise scalability issues.  Therefore, mastering the size of the
+       ARP/ND cache tables is critical as the number of data centers to
+       be connected increases.
+
+   d.  ARP/ND and Unknown Unicast Flooding: It's well-known that the
+       flooding of ARP/ND broadcast/multicast messages as well as
+       unknown unicast traffic within large Layer 2 networks is likely
+       to affect network and host performance.  When multiple data
+       centers that each host millions of VMs are interconnected at
+       Layer 2, the impact of such flooding would become even worse.  As
+       such, it becomes increasingly important to avoid the flooding of
+       ARP/ND broadcast/multicast as well as unknown unicast traffic
+       across data centers.
+
+
+
+
+
+
+Xu, et al.                    Informational                     [Page 3]
+
+RFC 7814                     Virtual Subnet                   March 2016
+
+
+   e.  Path Optimization: A subnet usually indicates a location in the
+       network.  However, when a subnet has been extended across
+       multiple geographically dispersed data-center locations, the
+       location semantics of such a subnet is not retained any longer.
+       As a result, traffic exchanged between a specific user and a
+       server that would be located in different data centers may first
+       be forwarded through a third data center.  This suboptimal
+       routing would obviously result in unnecessary consumption of the
+       bandwidth resources between data centers.  Furthermore, in the
+       case where traditional Virtual Private LAN Service (VPLS)
+       technology [RFC4761] [RFC4762] is used for data-center
+       interconnect, return traffic from a server may be forwarded to a
+       default gateway located in a different data center due to the
+       configuration of a virtual router redundancy group.  This
+       suboptimal routing would also unnecessarily consume the bandwidth
+       resources between data centers.
+
+   This document describes a BGP/MPLS IP VPN-based subnet extension
+   solution referred to as "Virtual Subnet", which can be used for data-
+   center interconnection while addressing all of the aforementioned
+   requirements and challenges.  Here, the BGP/MPLS IP VPN means both
+   BGP/MPLS IPv4 VPN [RFC4364] and BGP/MPLS IPv6 VPN [RFC4659].  In
+   addition, since Virtual Subnet is built mainly on proven technologies
+   such as BGP/MPLS IP VPN and ARP/ND proxy [RFC925] [RFC1027]
+   [RFC4389], those service providers that provide Infrastructure as a
+   Service (IaaS) cloud services can rely upon their existing BGP/MPLS
+   IP VPN infrastructure and take advantage of their BGP/MPLS VPN
+   operational experience to interconnect data centers.
+
+   Although Virtual Subnet is described in this document as an approach
+   for data-center interconnection, it can be used within data centers
+   as well.
+
+   Note that the approach described in this document is not intended to
+   achieve an exact emulation of Layer 2 connectivity, and therefore it
+   can only support a restricted Layer 2 connectivity service model with
+   limitations that are discussed in Section 4.  The discussion about
+   where this service model can apply is outside the scope of this
+   document.
+
+2.  Terminology
+
+   This memo makes use of the terms defined in [RFC4364].
+
+
+
+
+
+
+
+
+Xu, et al.                    Informational                     [Page 4]
+
+RFC 7814                     Virtual Subnet                   March 2016
+
+
+3.  Solution Description
+
+3.1.  Unicast
+
+3.1.1.  Intra-subnet Unicast
+
+                           +--------------------+
+    +------------------+   |                    |   +------------------+
+    |VPN_A:192.0.2.1/24|   |                    |   |VPN_A:192.0.2.1/24|
+    |              \   |   |                    |   |  /               |
+    |    +------+   \ ++---+-+                +-+---++/   +------+     |
+    |    |Host A+-----+ PE-1 |                | PE-2 +----+Host B|     |
+    |    +------+\    ++-+-+-+                +-+-+-++   /+------+     |
+    |     192.0.2.2/24 | | |                    | | |  192.0.2.3/24    |
+    |                  | | |                    | | |                  |
+    |     DC West      | | |  IP/MPLS Backbone  | | |     DC East      |
+    +------------------+ | |                    | | +------------------+
+                         | +--------------------+ |
+                         |                        |
+VRF_A :                  V                VRF_A : V
++------------+---------+--------+      +------------+---------+--------+
+|   Prefix   |Next hop |Protocol|      |   Prefix   |Next hop |Protocol|
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.1/32|127.0.0.1| Direct |      |192.0.2.1/32|127.0.0.1| Direct |
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.2/32|192.0.2.2| Direct |      |192.0.2.2/32|   PE-1  |  IBGP  |
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.3/32|   PE-2  |  IBGP  |      |192.0.2.3/32|192.0.2.3| Direct |
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.0/24|192.0.2.1| Direct |      |192.0.2.0/24|192.0.2.1| Direct |
++------------+---------+--------+      +------------+---------+--------+
+
+                  Figure 1: Intra-subnet Unicast Example
+
+   As shown in Figure 1, two hosts (i.e., Hosts A and B) belonging to
+   the same subnet (i.e., 192.0.2.0/24) are located in different data
+   centers (i.e., DC West and DC East), respectively.  PE routers (i.e.,
+   PE-1 and PE-2) that are used for interconnecting these two data
+   centers create host routes for their own local hosts respectively and
+   then advertise these routes by means of the BGP/MPLS IP VPN
+   signaling.  Meanwhile, an ARP proxy is enabled on Virtual Routing and
+   Forwarding (VRF) attachment circuits of these PE routers.
+
+   Let's now assume that Host A sends an ARP request for Host B before
+   communicating with Host B.  Upon receiving the ARP request, PE-1
+   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
+   packets towards PE-2, which in turn forwards them to Host B.  Thus,
+
+
+
+Xu, et al.                    Informational                     [Page 5]
+
+RFC 7814                     Virtual Subnet                   March 2016
+
+
+   Hosts A and B can communicate with each other as if they were located
+   within the same subnet.
+
+3.1.2.  Inter-subnet Unicast
+
+                           +--------------------+
+    +------------------+   |                    |   +------------------+
+    |VPN_A:192.0.2.1/24|   |                    |   |VPN_A:192.0.2.1/24|
+    |              \   |   |                    |   |  /               |
+    |  +------+     \ ++---+-+                +-+---++/     +------+   |
+    |  |Host A+-------+ PE-1 |                | PE-2 +-+----+Host B|   |
+    |  +------+\      ++-+-+-+                +-+-+-++ |   /+------+   |
+    |   192.0.2.2/24   | | |                    | | |  | 192.0.2.3/24  |
+    |   GW=192.0.2.4   | | |                    | | |  | GW=192.0.2.4  |
+    |                  | | |                    | | |  |    +------+   |
+    |                  | | |                    | | |  +----+  GW  +-- |
+    |                  | | |                    | | |      /+------+   |
+    |                  | | |                    | | |    192.0.2.4/24  |
+    |                  | | |                    | | |                  |
+    |     DC West      | | |  IP/MPLS Backbone  | | |      DC East     |
+    +------------------+ | |                    | | +------------------+
+                        | +--------------------+ |
+                        |                        |
+VRF_A :                 V                VRF_A : V
++------------+---------+--------+      +------------+---------+--------+
+|   Prefix   |Next hop |Protocol|      |   Prefix   |Next hop |Protocol|
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.1/32|127.0.0.1| Direct |      |192.0.2.1/32|127.0.0.1| Direct |
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.2/32|192.0.2.2| Direct |      |192.0.2.2/32|  PE-1   |  IBGP  |
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.3/32|   PE-2  |  IBGP  |      |192.0.2.3/32|192.0.2.3| Direct |
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.4/32|   PE-2  |  IBGP  |      |192.0.2.4/32|192.0.2.4| Direct |
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.0/24|192.0.2.1| Direct |      |192.0.2.0/24|192.0.2.1| Direct |
++------------+---------+--------+      +------------+---------+--------+
+| 0.0.0.0/0  |   PE-2  |  IBGP  |      | 0.0.0.0/0  |192.0.2.4| Static |
++------------+---------+--------+      +------------+---------+--------+
+
+                Figure 2: Inter-subnet Unicast Example (1)
+
+   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
+   to GW, would either be configured with or have learned a default
+   route from GW with the next hop being pointed at GW.  Meanwhile, this
+   route is distributed to other PE routers (i.e., PE-1) as per normal
+   operation as described in [RFC4364].  Assume Host A sends an ARP
+
+
+
+Xu, et al.                    Informational                     [Page 6]
+
+RFC 7814                     Virtual Subnet                   March 2016
+
+
+   request for its default gateway (i.e., 192.0.2.4) prior to
+   communicating with a destination 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.  Host A then sends a packet for Host B
+   to PE-1.  PE-1 tunnels such a packet towards PE-2 according to the
+   default route learned from PE-2, which in turn forwards that packet
+   to GW.
+                           +--------------------+
+    +------------------+   |                    |   +------------------+
+    |VPN_A:192.0.2.1/24|   |                    |   |VPN_A:192.0.2.1/24|
+    |              \   |   |                    |   |  /               |
+    |  +------+     \ ++---+-+                +-+---++/     +------+   |
+    |  |Host A+----+--+ PE-1 |                | PE-2 +-+----+Host B|   |
+    |  +------+\   |  ++-+-+-+                +-+-+-++ |   /+------+   |
+    |  192.0.2.2/24 |  | | |                    | | |  | 192.0.2.3/24  |
+    |  GW=192.0.2.4 |  | | |                    | | |  | GW=192.0.2.4  |
+    |  +------+    |   | | |                    | | |  |    +------+   |
+    |--+ GW-1 +----+   | | |                    | | |  +----+ GW-2 +-- |
+    |  +------+\       | | |                    | | |      /+------+   |
+    |  192.0.2.4/24    | | |                    | | |    192.0.2.4/24  |
+    |                  | | |                    | | |                  |
+    |     DC West      | | |  IP/MPLS Backbone  | | |      DC East     |
+    +------------------+ | |                    | | +------------------+
+                        | +--------------------+ |
+                        |                        |
+VRF_A :                 V                VRF_A : V
++------------+---------+--------+      +------------+---------+--------+
+|   Prefix   |Next hop |Protocol|      |   Prefix   |Next hop |Protocol|
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.1/32|127.0.0.1| Direct |      |192.0.2.1/32|127.0.0.1| Direct |
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.2/32|192.0.2.2| Direct |      |192.0.2.2/32|  PE-1   |  IBGP  |
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.3/32|   PE-2  |  IBGP  |      |192.0.2.3/32|192.0.2.3| Direct |
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.4/32|192.0.2.4| Direct |      |192.0.2.4/32|192.0.2.4| Direct |
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.0/24|192.0.2.1| Direct |      |192.0.2.0/24|192.0.2.1| Direct |
++------------+---------+--------+      +------------+---------+--------+
+| 0.0.0.0/0  |192.0.2.4| Static |      | 0.0.0.0/0  |192.0.2.4| Static |
++------------+---------+--------+      +------------+---------+--------+
+
+                Figure 3: Inter-subnet Unicast Example (2)
+
+   As shown in Figure 3, in the case where each data center is deployed
+   with a default gateway, hosts will get ARP responses directly from
+   their local default gateways, rather than from their local PE routers
+   when sending ARP requests for their default gateways.
+
+
+
+Xu, et al.                    Informational                     [Page 7]
+
+RFC 7814                     Virtual Subnet                   March 2016
+
+
+                                  +------+
+                           +------+ PE-3 +------+
+    +------------------+   |      +------+      |   +------------------+
+    |VPN_A:192.0.2.1/24|   |                    |   |VPN_A:192.0.2.1/24|
+    |              \   |   |                    |   |  /               |
+    |  +------+     \ ++---+-+                +-+---++/     +------+   |
+    |  |Host A+-------+ PE-1 |                | PE-2 +------+Host B|   |
+    |  +------+\      ++-+-+-+                +-+-+-++     /+------+   |
+    |  192.0.2.2/24    | | |                    | | |    192.0.2.3/24  |
+    |  GW=192.0.2.1    | | |                    | | |    GW=192.0.2.1  |
+    |                  | | |                    | | |                  |
+    |     DC West      | | |  IP/MPLS Backbone  | | |      DC East     |
+    +------------------+ | |                    | | +------------------+
+                         | +--------------------+ |
+                         |                        |
+VRF_A :                  V                VRF_A : V
++------------+---------+--------+      +------------+---------+--------+
+|   Prefix   |Next hop |Protocol|      |   Prefix   |Next hop |Protocol|
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.1/32|127.0.0.1| Direct |      |192.0.2.1/32|127.0.0.1| Direct |
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.2/32|192.0.2.2| Direct |      |192.0.2.2/32|  PE-1   |  IBGP  |
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.3/32|   PE-2  |  IBGP  |      |192.0.2.3/32|192.0.2.3| Direct |
++------------+---------+--------+      +------------+---------+--------+
+|192.0.2.0/24|192.0.2.1| Direct |      |192.0.2.0/24|192.0.2.1| Direct |
++------------+---------+--------+      +------------+---------+--------+
+| 0.0.0.0/0  |   PE-3  |  IBGP  |      | 0.0.0.0/0  |   PE-3  |  IBGP  |
++------------+---------+--------+      +------------+---------+--------+
+
+                Figure 4: Inter-subnet Unicast Example (3)
+
+   Alternatively, as shown in Figure 4, PE routers themselves could be
+   configured as default gateways for their locally connected hosts as
+   long as these PE routers have routes to reach outside networks.
+
+3.2.  Multicast
+
+   To support IP multicast between hosts of the same Virtual Subnet,
+   Multicast VPN (MVPN) technologies [RFC6513] could be used without any
+   change.  For example, PE routers attached to a given VPN join a
+   default provider multicast distribution tree that is dedicated to
+   that VPN.  Ingress PE routers, upon receiving multicast packets from
+   their local hosts, forward them towards remote PE routers through the
+   corresponding default provider multicast distribution tree.  Within
+   this context, the IP multicast doesn't include link-local multicast.
+
+
+
+
+
+Xu, et al.                    Informational                     [Page 8]
+
+RFC 7814                     Virtual Subnet                   March 2016
+
+
+3.3.  Host Discovery
+
+   PE routers should be able to dynamically discover their local hosts
+   and keep the list of these hosts up-to-date in a timely manner to
+   ensure the availability and accuracy of the corresponding host routes
+   originated from them.  PE routers could accomplish local host
+   discovery by some traditional host-discovery mechanisms using ARP or
+   ND protocols.
+
+3.4.  ARP/ND Proxy
+
+   Acting as an ARP or ND proxy, a PE router should only respond to 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 VRF
+   and the outgoing interface of that best route is different from 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 multihomed
+   to more than one PE router via an Ethernet switch or an Ethernet
+   network, the Virtual Router Redundancy Protocol (VRRP) [RFC5798] 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
+   ARP/ND proxy function.
+
+3.5.  Host Mobility
+
+   During the VM migration process, the PE router to which the moving VM
+   is now attached would create a host route for that host upon
+   receiving a notification message of VM attachment (e.g., a gratuitous
+   ARP or unsolicited NA message).  The PE router to which the moving VM
+   was previously attached would withdraw the corresponding host route
+   when noticing the detachment of that VM.  Meanwhile, the latter PE
+   router could optionally broadcast a gratuitous ARP or send an
+   unsolicited NA message on behalf of that host with the source MAC
+   address being one of its own.  In this way, the ARP/ND entry of this
+   host that moved and that has been cached on any local host would be
+   updated accordingly.  In the case where there is no explicit VM
+   detachment notification mechanism, the PE router could also use the
+   following trick to detect the VM detachment: upon learning a route
+   update for a local host from a remote PE router for the first time,
+   the PE router could immediately check whether that local host is
+   still attached to it by some means (e.g., ARP/ND PING and/or 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
+   VM would most likely continue to send packets to the same default
+   gateway address after having migrated from one data center to
+   another.  One possible way to achieve this goal is to configure the
+
+
+
+
+
+Xu, et al.                    Informational                     [Page 9]
+
+RFC 7814                     Virtual Subnet                   March 2016
+
+
+   same VRRP group on each location to ensure that the default gateway
+   active in each data center shares the same virtual MAC and virtual IP
+   addresses.
+
+3.6.  Forwarding Table Scalability on Data-Center Switches
+
+   In a Virtual Subnet environment, the MAC learning domain associated
+   with a given Virtual Subnet that has been extended across multiple
+   data centers is partitioned into segments, and each segment is
+   confined within a single data center.  Therefore, data-center
+   switches only need to learn local MAC addresses, rather than learning
+   both local and remote MAC addresses.
+
+3.7.  ARP/ND Cache Table Scalability on Default Gateways
+
+   When default gateway functions are implemented on PE routers as shown
+   in Figure 4, the ARP/ND cache table on each PE router only needs to
+   contain ARP/ND entries of local hosts.  As a result, the ARP/ND cache
+   table size would not grow as the number of data centers to be
+   connected increases.
+
+3.8.  ARP/ND and Unknown Unicast Flood Avoidance
+
+   In a Virtual Subnet environment, the flooding domain associated with
+   a given Virtual Subnet that was extended across multiple data
+   centers, is partitioned into segments and each segment is confined
+   within a single data center.  Therefore, the performance impact on
+   networks and servers imposed by the flooding of ARP/ND broadcast/
+   multicast and unknown unicast traffic is minimized.
+
+3.9.  Path Optimization
+
+   As shown in Figure 4, to optimize the forwarding path for the traffic
+   between cloud users and cloud data centers, PE routers located in
+   cloud data centers (i.e., PE-1 and PE-2), which are also acting as
+   default gateways, propagate host routes for their own local hosts to
+   remote PE routers that are attached to cloud user sites (i.e., PE-3).
+   As such, traffic from cloud user sites to a given server on the
+   Virtual Subnet that has been extended across data centers would be
+   forwarded directly to the data-center location where that server
+   resides, since traffic is now forwarded according to the host route
+   for that server, rather than the subnet route.  Furthermore, for
+   traffic coming from cloud data centers and forwarded to cloud user
+   sites, each PE router acting as a default gateway would forward
+   traffic according to the longest-match route in the corresponding
+   VRF.  As a result, traffic from data centers to cloud user sites is
+   forwarded along an optimal path as well.
+
+
+
+
+Xu, et al.                    Informational                    [Page 10]
+
+RFC 7814                     Virtual Subnet                   March 2016
+
+
+4.  Limitations
+
+4.1.  Non-support of Non-IP Traffic
+
+   Although most traffic within and across data centers is IP traffic,
+   there may still be a few legacy clustering applications that rely on
+   non-IP communications (e.g., heartbeat messages between cluster
+   nodes).  Since Virtual Subnet is strictly based on L3 forwarding,
+   those non-IP communications cannot be supported in the Virtual Subnet
+   solution.  In order to support those few non-IP traffic (if present)
+   in the environment where the Virtual Subnet solution has been
+   deployed, the approach following the idea of "route all IP traffic,
+   bridge non-IP traffic" could be considered.  In other words, all IP
+   traffic including both intra- and inter-subnet, would be processed
+   according to the Virtual Subnet design, while non-IP traffic would be
+   forwarded according to a particular Layer 2 VPN approach.  Such a
+   unified L2/L3 VPN approach requires ingress PE routers to classify
+   packets received from hosts before distributing them to the
+   corresponding L2 or L3 VPN forwarding processes.  Note that more and
+   more cluster vendors are offering clustering applications based on
+   Layer 3 interconnection.
+
+4.2.  Non-support of IP Broadcast and Link-Local Multicast
+
+   As illustrated before, intra-subnet traffic across PE routers is
+   forwarded at Layer 3 in the Virtual Subnet solution.  Therefore, IP
+   broadcast and link-local multicast traffic cannot be forwarded across
+   PE routers in the Virtual Subnet solution.  In order to support the
+   IP broadcast and link-local multicast traffic in the environment
+   where the Virtual Subnet solution has been deployed, the unified L2/
+   L3 overlay approach as described in Section 4.1 could be considered
+   as well.  That is, IP broadcast and link-local multicast messages
+   would be forwarded at Layer 2 while routable IP traffic would be
+   processed according to the Virtual Subnet design.
+
+4.3.  TTL and Traceroute
+
+   As mentioned before, intra-subnet traffic is forwarded at Layer 3 in
+   the Virtual Subnet context.  Since it doesn't require any change to
+   the Time-To-Live (TTL) handling mechanism of the BGP/MPLS IP VPN,
+   when doing a traceroute operation on one host for another host
+   (assuming that these two hosts are within the same subnet but are
+   attached to different sites), the traceroute output would reflect the
+   fact that these two hosts within the same subnet are actually
+   connected via a Virtual Subnet, rather than a Layer 2 connection
+   since the PE routers to which those two hosts are connected would be
+   displayed in the traceroute output.  In addition, for any other
+   applications that generate intra-subnet traffic with TTL set to 1,
+
+
+
+Xu, et al.                    Informational                    [Page 11]
+
+RFC 7814                     Virtual Subnet                   March 2016
+
+
+   these applications may not work properly in the Virtual Subnet
+   context, unless special TTL processing and loop-prevention mechanisms
+   for such context have been implemented.  Details about such special
+   TTL processing and loop-prevention mechanisms are outside the scope
+   of this document.
+
+5.  Security Considerations
+
+   Since the BGP/MPLS IP VPN signaling is reused without any change,
+   those security considerations as described in [RFC4364] are
+   applicable to this document.  Meanwhile, since security issues
+   associated with the NDP are inherited due to the use of NDP proxy,
+   those security considerations and recommendations as described in
+   [RFC6583] are applicable to this document as well.
+
+   Inter-data-center traffic often carries highly sensitive information
+   at higher layers that is not directly understood (parsed) within an
+   egress or ingress PE.  For example, migrating a VM will often mean
+   moving private keys and other sensitive configuration information.
+   For this reason, inter-data-center traffic should always be protected
+   for both confidentiality and integrity using a strong security
+   mechanism such as IPsec [RFC4301].  In the future, it may be feasible
+   to protect that traffic within the MPLS layer [MPLS-SEC] though at
+   the time of writing, the mechanism for that is not sufficiently
+   mature to recommend.  Exactly how such security mechanisms are
+   deployed will vary from case to case, so securing the inter-data-
+   center traffic may or may not involve deploying security mechanisms
+   on the ingress/egress PEs or further "inside" the data centers
+   concerned.  Note though that if security is not deployed on the
+   egress/ingress PEs, there is a substantial risk that some sensitive
+   traffic may be sent in the clear and will therefore be vulnerable to
+   pervasive monitoring [RFC7258] or other attacks.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC925]   Postel, J., "Multi-LAN address resolution", RFC 925,
+              DOI 10.17487/RFC0925, October 1984,
+              <http://www.rfc-editor.org/info/rfc925>.
+
+   [RFC1027]  Carl-Mitchell, S. and J. Quarterman, "Using ARP to
+              implement transparent subnet gateways", RFC 1027,
+              DOI 10.17487/RFC1027, October 1987,
+              <http://www.rfc-editor.org/info/rfc1027>.
+
+
+
+
+
+
+Xu, et al.                    Informational                    [Page 12]
+
+RFC 7814                     Virtual Subnet                   March 2016
+
+
+   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
+              2006, <http://www.rfc-editor.org/info/rfc4364>.
+
+   [RFC4389]  Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
+              Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
+              2006, <http://www.rfc-editor.org/info/rfc4389>.
+
+6.2.  Informative References
+
+   [MPLS-SEC] Farrel, A. and S. Farrell, "Opportunistic Security in MPLS
+              Networks", Work in Progress, draft-ietf-mpls-
+              opportunistic-encrypt-01, March 2016.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
+              December 2005, <http://www.rfc-editor.org/info/rfc4301>.
+
+   [RFC4659]  De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
+              "BGP-MPLS IP Virtual Private Network (VPN) Extension for
+              IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
+              <http://www.rfc-editor.org/info/rfc4659>.
+
+   [RFC4761]  Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
+              LAN Service (VPLS) Using BGP for Auto-Discovery and
+              Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
+              <http://www.rfc-editor.org/info/rfc4761>.
+
+   [RFC4762]  Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
+              LAN Service (VPLS) Using Label Distribution Protocol (LDP)
+              Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
+              <http://www.rfc-editor.org/info/rfc4762>.
+
+   [RFC5798]  Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
+              Version 3 for IPv4 and IPv6", RFC 5798,
+              DOI 10.17487/RFC5798, March 2010,
+              <http://www.rfc-editor.org/info/rfc5798>.
+
+   [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
+              BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
+              2012, <http://www.rfc-editor.org/info/rfc6513>.
+
+   [RFC6583]  Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
+              Neighbor Discovery Problems", RFC 6583,
+              DOI 10.17487/RFC6583, March 2012,
+              <http://www.rfc-editor.org/info/rfc6583>.
+
+
+
+
+
+Xu, et al.                    Informational                    [Page 13]
+
+RFC 7814                     Virtual Subnet                   March 2016
+
+
+   [RFC6820]  Narten, T., Karir, M., and I. Foo, "Address Resolution
+              Problems in Large Data Center Networks", RFC 6820,
+              DOI 10.17487/RFC6820, January 2013,
+              <http://www.rfc-editor.org/info/rfc6820>.
+
+   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
+              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
+              2014, <http://www.rfc-editor.org/info/rfc7258>.
+
+Acknowledgements
+
+   Thanks to Susan Hares, Yongbing Fan, Dino Farinacci, Himanshu Shah,
+   Nabil Bitar, Giles Heron, Ronald Bonica, Monique Morrow, Rajiv Asati,
+   Eric Osborne, Thomas Morin, Martin Vigoureux, Pedro Roque Marque, Joe
+   Touch, Wim Henderickx, Alia Atlas, and Stephen Farrell for their
+   valuable comments and suggestions on this document.  Thanks to Loa
+   Andersson for his WG LC review on this document.  Thanks to Alvaro
+   Retana for his AD review on this document.  Thanks to Ronald Bonica
+   for his RtgDir review.  Thanks to Donald Eastlake 3rd for his Sec-DIR
+   review of this document.  Thanks to Jouni Korhonen for the OPS-Dir
+   review of this document.  Thanks to Roni Even for the Gen-ART review
+   of this document.  Thanks to Sabrina Tanamal for the IANA review of
+   this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xu, et al.                    Informational                    [Page 14]
+
+RFC 7814                     Virtual Subnet                   March 2016
+
+
+Authors' Addresses
+
+   Xiaohu Xu
+   Huawei Technologies
+   No.156 Beiqing Rd
+   Beijing  100095
+   China
+
+   Email: xuxiaohu@huawei.com
+
+
+   Christian Jacquenet
+   Orange
+   4 rue du Clos Courtel
+   Cesson-Sevigne,  35512
+   France
+
+   Email: christian.jacquenet@orange.com
+
+
+   Robert Raszuk
+   Bloomberg LP
+   731 Lexington Avenue
+   New York City, NY  10022
+   United States
+
+   Email: robert@raszuk.net
+
+
+   Truman Boyes
+   Bloomberg LP
+
+   Email: tboyes@bloomberg.net
+
+
+   Brendan Fee
+   Extreme Networks
+
+   Email: bfee@extremenetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+Xu, et al.                    Informational                    [Page 15]
+