<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-wu-nvo3-mac-learning-arp-03"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="TS Info Discovery Gap Analysis">Tenant system information
    discovery approaches Gap analysis</title>

    <author fullname="Liang Xia" initials="L." surname="Xia">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>frank.xialiang@huawei.com</email>
      </address>
    </author>

    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>bill.wu@huawei.com</email>
      </address>
    </author>

    <date year="2013" />

    <area>Internet Area</area>

    <workgroup>Network Virtualization Overlays Working Group</workgroup>

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <keyword>Network Virtualization Overlays</keyword>

    <abstract>
      <t>This document analyzes various protocol solutions for tenant system
      information (e.g. MAC, IP, etc) discovery in the virtualization
      environment (e.g.,MAC in MAC, MAC in IP, IP in IP) and identifies the
      gap against NVO3 control plane and data plane requirements.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>The tenant system information in this document is referred to as L2
      address and L3 address of VM. As described in [I.D-ietf-nvo3-
      framework], for an L2 NVE, the NVE needs to be able to determine MAC
      addresses of the tenant system. For an L3 NVE, the NVE needs to be able
      to determine IP addresses of the tenant system.</t>

      <t>This can be achieved mainly in 3 ways: data plane learning; ARP;
      control plane distribution (e.g. by BGP or IS-IS). This document
      analyzes various protocol solutions for tenant system information (e.g.
      MAC, IP, etc) discovery in the virtualization environment (e.g.,MAC in
      MAC, MAC in IP, IP in IP) and identifies the gap against NVO3 control
      plane and data plane requirements.</t>
    </section>

    <section title="Conventions used in this document">
      <t>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 <xref
      target="RFC2119">RFC2119</xref>.</t>
    </section>

    <section title="Overview of tenant system information discovery in the virtualization domain using NVO3">
      <t>Tenant system information discovery can be achieved either using
      dynamic data plane learning or ARP or control plane distribution. This
      document addresses how tenant system information discovery works in the
      overlay network enviroment. Figure 1 shows the NVO3 reference
      architecture for tenant system information discovery. The reference
      architecture assumes that: <list style="symbols">
          <t>Tenant system A in DC site X wants to establish communication
          with tenant system B in the DC site Y.</t>

          <t>Tenant system A is connecting to VN by attaching to NVE X. Tenant
          System A knows IP address of Tenant System B using out of band means
          but does not know MAC address of Tenant System B.</t>

          <t>Tenant system B is connecting to VN by attaching to NVE Y. Tenant
          System B knows IP address of Tenant System A using out of band means
          but does not know MAC address of Tenant System A.</t>

          <t>NVE X associated with tenant system A doesn't know IP address and
          MAC address of tenant system B.</t>

          <t>NVE Y associated with tenant system B doesn't know IP address and
          MAC address of tenant system A.</t>
        </list></t>

      <figure anchor="fig1"
              title="Example of NVO3 reference architecture for tenant system information discovery">
        <artwork>
                            ,---------.
                          ,'  Backend  `.
                         (      NVA       )
                          `.           ,'
                            `-+------+'
                            |         |
                       .--..--. .--. ..
                      (    '           '.--.
                   .-.'        L3          '
                  (          Overlay       )
                   (                     '-'
                        .'--'._.'.-._.'.-._)  
        NVE X =       //                \\    NVE Y =
  (MAC_X,IP_X) +------+              +-------+(MAC_Y,IP_Y)
             .-|NVE X |              | NVE Y |
           (   +------+--.         ( +-------+.--.
         .-.'              '     .-.'              '
        (    DC Site X     )    (    DC Site Y     )
         (             .'-'      (             .'-'
          '--'._.'.    )          '--'._.'.    )
                  '--'              /     '--'
               /     \             /       \
            __/_      \           /_       _\__
     '--------'   '--------'   '--------'   '--------'
     : Tenant :   : Tenant :   : Tenant :   : Tenant :
     : SystemA:   : SystemC:   : SystemD:   : SystemB:
     '--------'   '--------'   '--------'   '--------'
       TSID=                                  TSID=
   (VNID,MAC_A,IP_A)                      (VNID,MAC_B,IP_B)
</artwork>
      </figure>

      <section title="Issues with tenant system information discovery in the virtualization domain using NVO3">
        <t>Here we give an example of tenant system information discovery in
        large layer 2 domain using NVO3 using traditional approach for MAC
        address learning. The packet flow and control plane operation are as
        follows:<list style="numbers">
            <t>Tenant system A sends a broadcast ARP message to discover the
            MAC address of Tenant system B. The message contains IP_B in the
            ARP message payload.</t>

            <t>The ARP proxy [RFC1027] in NVE X, receiving the ARP message and
            knowing source and destination are in the different subnet will
            encapsulate it with overlay header and outer header and flood it
            on the overlay network for TSID = &lt;VNID,IP_B,*&gt;. VNID is
            included in the overlay header.</t>

            <t>The ARP message will be processed by NVE Y which maintains
            mapping table matching TSID = &lt;VNID,IP_B,*&gt;. NVE Y, will
            forward the ARP message to tenant system B. Tenant System B sends
            ARP reply to tenant system A containing MAC_B.</t>

            <t>NVE X processes ARP reply message and populates the mapping
            table with the received entry, then sends it to Tenant System A
            that includes MAC_B and IP_B of Tenant System B.</t>

            <t>Tenant system A learns MAC_B from the ARP rely message and can
            now send a packet to Tenant system B by including MAC_B, and IP_B,
            as destination addresses.</t>
          </list></t>

        <t>The issues with tenant system information discovery are as
        follows:<list style="symbols">
            <t>The demand on the forwarding table capacity at each NVE is
            increased compared to non-virtualized environments since layer 2
            network is no longer constrained to small local network and has a
            need for millions of hosts.</t>

            <t>If Address resolution protocol is used for control plane
            learning, it may cause excessive flooding since ARP packets need
            to be flooded over the whole overlay network. the ARP/ND
            processing load imposes great challenge on L2/L3 boundary
            routers.</t>

            <t>Dynamic data plane learning implies that flooding of unknown
            destinations be supported and hence implies that broadcast and/or
            multicast be supported or that ingress replication, which may
            cause excessive flooding issue and lead to significant scalability
            limitations.</t>

            <t>A control plane protocol (e.g., BGP) that carries both MAC and
            IP addresses eliminates the need for ARP, however some NVEs or DC
            Gateways may not support complex control plane protocol, for
            example, BGP protocol.</t>
          </list></t>
      </section>
    </section>

    <section title="Related work for Tenant system information discovery">
      <t>Currently, 3 main solutions or their combination can be used to
      perform the tenant system information discovery. They are dynamic data
      plane learning, ARP, control plane distribution (including two options:
      centralized or distributed). Additionally, the ARP proxy [RFC1027]
      mechanism can be used for preventing the ARP flooding in the core
      network and limiting the MAC table size of NVEs and hosts. Here is a
      brief analysis of them and the associated protocols are discussed.</t>

      <section title="SPB and TRILL">
        <t>Shortest Path Bridging (SPB) [SPB] and TRILL [TRILL] are two
        different methods of IS-IS based overlay that operates over L2
        Ethernets. They all use the MAC in MAC encapsulation and have the same
        default MAC address learning method: <list style="symbols">
            <t>Using IS-IS extension for outer MAC address distribution over
            the SPB area or TRILL campus network;</t>

            <t>Using ARP or data plane snooping for inner MAC address learning
            of locally attached hosts.</t>

            <t>In addition, the TRILL maybe use
            [draft-ietf-trill-directory-framework] distributes the inner MAC
            address between all the RBriges</t>
          </list></t>

        <t>In the centralized approach, TRILL may use TRILL ESADI to
        distribute the inner MAC address between all the RBridges however SPB
        doesn’t support ESADI distribution mechanism. In the distributed
        approach, SPB and TRILL may use combination of the above 3
        methods.</t>
      </section>

      <section title="ARMD and SARP">
        <t>The ARMD WG examined data center scaling issues with a focus on
        address resolution and developed a problem statement document
        [RFC6820]. In this document, the scaling issues of MAC address
        learning related to the overlay-based approach are listed as
        followed:<list>
            <t>ARP processing on Routers: This issue mainly concerns about the
            significant amount of ARP traffic or BUM packets traffic in large
            L2 broadcast domains and its impact to the routers. Finally, some
            optimized method are proposed;</t>

            <t>IPv6 Neighbor Discovery has the similar issue as ARP processing
            on router;</t>

            <t>MAC Address Table Size Limitations at Switches: This issue
            mainly concerns on the MAC Address Table Size Limitations when the
            VM number is very large in the Virtualized data center
            environment.</t>
          </list></t>

        <t>In order to tackle the above problems, SARP [SARP] seamlessly
        supports Layer 2 network virtualization services over the overlay
        network and significantly reduces their complexity in terms of table
        size and performance. The overlay networks are only required to map
        MAC addresses of the SARP proxies, instead of MAC address of the
        destination end host, to the correct tunnel.</t>
      </section>

      <section title="BGP/MPLS IP VPNs – Distributed control plane distribution">
        <t>BGP/MPLS IP VPNs [RFC4364] provides IP Virtual Private Networks
        (VPNs) for its customers and support VPN traffic isolation, address
        overlapping and separation between customer networks. The BGP/MPLS
        control plane is used to distribute both the VPN labels and the tenant
        system IP addresses that are used to identify the customer. However
        BGP/MPLS IP VPN doesn’t support interconnection with Data Center (DC)
        overlay networks and provide a virtual end to end tenant network
        service to tenant systems in the BGP/MPLS IPVPN.It also has the
        scalability related problems when IP addresses of a large number of
        VMs need to be propagated in control plane in the Virtualized data
        center environments.</t>

        <t>For an L3 overlay node, the overlay node only needs to determine IP
        addresses of the tenant system but doesn't need to know the MAC
        address of the destination system since overlay tunnels the L3 traffic
        from the tenant system in an encapsulated format to the final
        destination and doesn't care about the MAC address of destination end
        system for the inner L3 packet. Therefore overlay node can answer any
        address resolution query with its own MAC address or one virtual MAC
        address. In [I.D-ietf-l3vpn-end-system], NVE uses XMPP to exchange
        information with the tenant system and answer the address resolution
        query from tenant system with a virtual router MAC address.</t>

        <t>In order to propagate tenant system information to the whole
        overlay network environment, [I.D-ietf-l3vpn-end-system]use Route
        Server to gather VPN membership on each Forwarder and IP addresses
        that are currently associated with each virtual interface of tenant
        system and advertise them to the BGP speaker. In addition, BGP speaker
        also can interact with Route Server to generate tenant system
        information update to the upstream end systems.</t>
      </section>

      <section title="BGP/MPLS Ethernet VPNs and PBB-EVPN">
        <t>Ethernet Virtual Private Networks (E-VPNs) [I-D.ietf-l2vpn-evpn]
        provide an emulated L2 service in which each tenant has its own
        Ethernet network over a common IP or MPLS infrastructure. PBB-EVPN
        [I-D.ietf -l2vpn-pbb-evpn] is a combined solution of PBB and E-VPN.
        They all use BGP for MAC address distribution over the core MPLS/IP
        network, and use ARP or data plane snooping for MAC address learning
        of locally attached hosts. In other words, the mapping table
        information &lt;VNID,IP_A,NVE_X&gt; should be distributed to all the
        remote overlay nodes that belong to the same VN. After that,the tenant
        system information&lt;VNID,IP_A, MAC_X&gt; is distributed from remote
        overlay nodes to all the remote tenant system. When all the tenant
        system information is populated, overlay nodes will process the packet
        from each tenant system and perform a lookup operation in its map
        table for the destination TSID=&lt;VNID,IP_B&gt; and determine which
        tunnel the packet needs to be sent to. <vspace blankLines="1" />The
        analysis of their MAC address learning methods is as followed: <vspace
        blankLines="1" />Pros:<list style="symbols">
            <t>ARP broadcast Suppression: They all construct ARP caches on the
            PEs and synchronize them either via BGP or data plane snooping.
            The PEs act as ARP proxies for locally attached hosts, thereby
            preventing repeated ARP broadcast over the core MPLS/IP
            network;</t>

            <t>Comparing E-VPN, PBB-EVPN reduces the number of BGP MAC
            advertisement routes, provide C-MAC address mobility, confine the
            scope of C-MAC address learning to only active flows, offer per
            site policies and avoid C-MAC address flushing on topology
            changes.</t>
          </list><vspace blankLines="1" />Con: An E-VPN PE sends a BGP MAC
        Advertisement Route per customer/client MAC (C-MAC) address. This will
        raise the scalability related problems in the case of Virtualized data
        center environments where the number of virtual machines (VMs) is very
        large.</t>
      </section>

      <section title="VPLS – ARP + data plane learning">
        <t>VPLS is an L2 VPN technology. VPLS uses the ARP and data plane
        learning for L2 tenant system information discovery, and not
        advertised and distributed via a BGP/LDP control plane. The analysis
        of this method is as followed: <vspace blankLines="1" />Pros:<list
            style="symbols">
            <t>Reducing complexity and work burden of the control plane by
            decreasing the control packets;</t>

            <t>MAC address learning based on active flows can save the space
            of MAC mapping table.</t>
          </list><vspace blankLines="1" />Cons:<list style="symbols">
            <t>PE will learn all active MACs over the associated PW by BUM
            flooding of data plane. But, some active MACs is not destined to
            the PE;</t>

            <t>Unlike the active MAC withdraw mechanism in control plane, PE
            cannot flush MAC address real-time in data plane, when host MACs
            behind the PE are changed.</t>
          </list></t>
      </section>

      <section title="LISP – Centralized control plane distribution">
        <t>LISP[RFC6830] essentially provides an IP over IP overlay where the
        internal addresses are end station Identifiers and the outer IP
        addresses represent the location of the end station within the core IP
        network topology. [draft-maino-nvo3-lisp-cp-02] discusses L2 over L3
        LISP Encapsulation and proposes a LISP Mapping System for ARP
        resolution to eliminate the flooding of ARP traffic and further reduce
        the need for multicast in the underlay network. This system relies on
        mapping system for tenant system information distribution and involves
        MAP-request/MAP-Response message exchange between overlay node and
        mapping system. With introduced LISP Mapping system, the scalability
        is improved for tenant system information discovery. the packet flow
        and control plane operation are as follows: <list style="symbols">
            <t>Tenant System A sends a broadcast ARP message to discover the
            MAC address of Tenant system B. The message contains IP_B in the
            ARP message payload.</t>

            <t>NVE X as an ARP proxy, receiving the ARP message and knowing
            source and destination are in the different subnet[RFC1027], but
            rather than flooding it on the overlay network, sends a Map-
            Request(i.e.,LISP signaling) to the backend LISP mapping system
            (i.e.,NVA) that maintains mapping information for entire overlay
            network for TSID = &lt;VNID,IP_B,*&gt;.</t>

            <t>The Map-Request is reflected by the backend LISP Mapping system
            to NVE Y, that will send a Map-Reply back to NVE X containing the
            mapping TSID=&lt;VNID,IP_B,MAC_B&gt;. Alternatively, depending on
            the Backend LISP Mapping system configuration, the backend LISP
            Mapping system may send directly a Map-Reply to NVE X.</t>

            <t>NVE X populates the mapping table with the received entry, and
            sends an ARP-Agent Reply to Tenant System A that includes MAC_B
            and IP_B.</t>

            <t>Tenant system A learns MAC_B from the ARP message and can now
            send a packet to Tenant system B by including MAC_B, and IP_B, as
            destination addresses.</t>
          </list></t>
      </section>
    </section>

    <section title="Gap Analysis and Discuss">
      <t>The following table compares several tenant system information
      discovery methods from different aspects under the same network topology
      and scale.</t>

      <figure>
        <artwork>
+-----------+-------------+--------------+-------------+------------+
|   TS      |  Forwarding |   Packets    |Control plane| Directory  |
| Discovery |     table   |  flooding    |Distribution    Support   |
|  method   |     size    |   impact     |  support    |            |
+-----------+-------------+--------------+-------------+------------+
|           |             |              |             |            |
|   SPB     |             |              |             | Trill:Yes  |
| &amp;TRILL    |   Mediaum   |     Medium   |    Yes      | SPB:No     |
|           |             |              |             |            |
|           |             |              |             |            |
+-----------+-------------+--------------+-------------+------------+
|           |             |              |             |            |
|           |             |              |             |            |
| ARMD&amp;SARP |   Small     |     Medium   |    No       |   No       |
|           |             |              |             |            |
|           |             |              |             |            |
+-----------+-------------+--------------+-------------+------------+
|           |             |              |             |            |
|   LISP    |             |              |             |LISP Mapping|
|    +      |   Medium    |     Medium   |   Yes       |   System   |
+ ARP proxy |             |              |             |            |
|           |             |              |             |            |
+-----------+-------------+--------------+-------------+------------+
|           |             |              |             |            |
| BGP/MPLS  |             |              |             |            |
|    IP     |   Large     |     Large    |   Yes       |   No       |
|   VPN     |             |              |             |            |
|           |             |              |             |            |
+-----------+-------------+--------------+-------------+------------+
|           |             |              |             |            |
|  BGP/MPLS |             |              |             |            |
|  Ethernet |   Large     |     Large    |   Yes       |   No       |
|    VPN    |             |              |             |            |
|           |             |              |             |            |
+-----------+-------------+--------------+-------------+------------+
|           |             |              |             |            |
|   VPLS    |             |              |             |            |
|    +      |   Medium    |     Small    |   Yes       |   No       |
| ARP proxy |             |              |             |            |
|           |             |              |             |            |
+-----------+-------------+--------------+-------------+------------+
  Table 1: The comparison between several tenant system 
            information discovery methods
</artwork>
      </figure>
    </section>

    <section title="Conclusion">
      <t>There are three ways for tenant system information discovery, data
      plane learning and control plane ARP learning and control plane
      distribution. In large layer 2 domain, the MAC address can not be simply
      learnt by looking at the outer layer 2 header, instead, Deeper parsing
      inner Ethernet header is required. However it also introduces a lot of
      processing overhead. In order to address this issue, the control plane
      distribution is proposed, and used to carry both MAC address and IP
      address and eliminate the above data plane learning issue. However
      distribution protocol is needed. How distribution protocol is used to
      propagate tenant system information and mapping table information in
      large scale and in a more efficient way is still under study.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document has no actions for IANA.</t>
    </section>

    <section title="Security Considerations">
      <t>TBC.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
          Requirement Levels</title>

          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>

            <address>
              <postal>
                <street>1350 Mass. Ave.</street>

                <street>Cambridge</street>

                <street>MA 02138</street>
              </postal>

              <phone>- +1 617 495 3864</phone>

              <email>sob@harvard.edu</email>
            </address>
          </author>

          <date month="March" year="1997" />

          <area>General</area>

          <keyword>keyword</keyword>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. Authors who follow these
            guidelines should incorporate this phrase near the beginning of
            their document: <list>
                <t>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.</t>
              </list></t>

            <t>Note that the force of these words is modified by the
            requirement level of the document in which they are used.</t>
          </abstract>
        </front>
      </reference>

      <reference anchor="I.D-ietf-nvo3-framework">
        <front>
          <title>Framework for DC Network Virtualization</title>

          <author fullname="M.Lasserre" initials="M." surname="Lasserre">
            <organization></organization>
          </author>

          <date month="September" year="2012" />
        </front>

        <seriesInfo name="ID" value="draft-ietf-nvo3-framework-00" />
      </reference>

      <reference anchor="SPB">
        <front>
          <title>IEEE standard for local and metropolitan area networks: Media
          access control (MAC) bridges and virtual bridged local area networks
          -- Amendment 20: Shortest path bridging</title>

          <author>
            <organization></organization>
          </author>

          <date month="June" year="2012" />
        </front>

        <seriesInfo name="IEEE" value="802.1aq" />
      </reference>

      <reference anchor="I-D.ietf-l2vpn-evpn">
        <front>
          <title>BGP MPLS Based Ethernet VPN</title>

          <author fullname="A.Sajassi" initials="A." surname="Sajassi">
            <organization></organization>
          </author>

          <author fullname="R.Aggarwal" initials="R." surname="Aggarwal">
            <organization></organization>
          </author>

          <date month="February" year="2013" />
        </front>

        <seriesInfo name="ID" value="draft-ietf-l2vpn-evpn-03" />
      </reference>

      <reference anchor="I-D.ietf-trill-directory-framework">
        <front>
          <title>TRILL (Transparent Interconnection of Lots of Links): Edge
          Directory Assistance Framework</title>

          <author fullname="Linda Dunbar" initials="L." surname="Dunbar">
            <organization></organization>
          </author>

          <author fullname="Donald Eastlake" initials="D." surname="Eastlake">
            <organization></organization>
          </author>

          <date month="April" year="2013" />
        </front>

        <seriesInfo name="ID" value="draft-ietf-trill-directory-framework-05" />
      </reference>

      <reference anchor="ESADI">
        <front>
          <title>TRILL (Transparent Interconnection of Lots of Links): ESADI
          (End Station Address Distribution Information) Protocol</title>

          <author fullname="Donald Eastlake" initials="D." surname="Eastlake">
            <organization></organization>
          </author>

          <date month="February" year="2013" />
        </front>

        <seriesInfo name="ID" value="draft-ietf-trill-esadi-02" />
      </reference>

      <reference anchor="SARP">
        <front>
          <title>Scaling the Address Resolution Protocol for Large Data
          Centers (SARP)</title>

          <author fullname="Linda Dunbar" initials="L." surname="Dunbar">
            <organization></organization>
          </author>

          <author fullname="Ilan Yerushalmi" initials="I."
                  surname="Yerushalmi">
            <organization></organization>
          </author>

          <date month="February" year="2013" />
        </front>

        <seriesInfo name="ID" value="draft-nachum-sarp-04" />
      </reference>

      <reference anchor="RFC6325">
        <front>
          <title>RBridges: Base Protocol Specification</title>

          <author fullname="R.Perlman" initials="R." surname="Perlman">
            <organization></organization>
          </author>

          <date month="July" year="2011" />
        </front>
      </reference>

      <reference anchor="draft-maino-nvo3-lisp-cp">
        <front>
          <title>LISP Control Plane for Network Virtualization
          Overlays</title>

          <author fullname="F. Maino" initials="F." surname="Maino">
            <organization></organization>
          </author>

          <author fullname="R.Aggarwal" initials="R." surname="Aggarwal">
            <organization></organization>
          </author>

          <date month="April" year="2013" />
        </front>

        <seriesInfo name="ID" value="draft-maino-nvo3-lisp-cp-02" />
      </reference>

      <reference anchor="I.D-ietf-l3vpn-end-system">
        <front>
          <title>BGP-signaled end-system IP/VPNs</title>

          <author fullname="P. Marques" initials="P." surname="Marques">
            <organization></organization>
          </author>

          <date month="April" year="2013" />
        </front>

        <seriesInfo name="ID" value="draft-maino-nvo3-lisp-cp-02" />
      </reference>

      <reference anchor="I-D.ietf-l2vpn-pbb-evpn">
        <front>
          <title>PBB-EVPN</title>

          <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
            <organization></organization>
          </author>

          <date month="April" year="2013" />
        </front>

        <seriesInfo name="ID" value="draft-ietf-l2vpn-pbb-evpn-04" />
      </reference>

      <reference anchor="RFC6830">
        <front>
          <title>The Locator/ID Separation Protocol (LISP)</title>

          <author fullname="D. Farinacci" initials="D." surname="Farinacci">
            <organization></organization>
          </author>

          <date month="January" year="2013" />
        </front>
      </reference>

      <reference anchor="RFC6820">
        <front>
          <title>The Locator/ID Separation Protocol (LISP)</title>

          <author fullname="D. Farinacci" initials="D." surname="Farinacci">
            <organization></organization>
          </author>

          <date month="January" year="2013" />
        </front>
      </reference>

      <reference anchor="RFC4364">
        <front>
          <title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>

          <author fullname="E. Rosen" initials="E." surname="Rosen">
            <organization></organization>
          </author>

          <date month="February" year="2006" />
        </front>
      </reference>

      <reference anchor="RFC1027">
        <front>
          <title>Using ARP to Implement Transparent Subnet Gateways</title>

          <author fullname="S. Carl-Mitchell" initials="S."
                  surname="Carl-Mitchell">
            <organization></organization>
          </author>

          <date month="October" year="1987" />
        </front>
      </reference>
    </references>
  </back>
</rfc>
