<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info"
     docName="draft-hertoghs-nvo3-lisp-controlplane-unified-02"
     ipr="trust200902">
  <front>
    <title abbrev="Unified LISP for NVO3">A Unified LISP Mapping Database for
    L2 and L3 Network Virtualization Overlays</title>

    <author fullname="Yves Hertoghs" initials="Y." surname="Hertoghs">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>6a De Kleetlaan</street>

          <city>Diegem</city>

          <code>1831</code>

          <region/>

          <country>Belgium2</country>
        </postal>

        <phone>+32-2778-435</phone>

        <facsimile>+32-2704-6000</facsimile>

        <email>yves@cisco.com</email>
      </address>
    </author>

    <author fullname="Fabio Maino" initials="F" surname="Maino">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>170 Tasman Drive</street>

          <city>San Jose</city>

          <code>95134</code>

          <region>California</region>

          <country>USA</country>
        </postal>

        <email>fmaino@cisco.com</email>
      </address>
    </author>

    <author fullname="Victor Moreno" initials="V." surname="Moreno">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>170 Tasman Drive</street>

          <city>San Jose</city>

          <code>95134</code>

          <region>California</region>

          <country>USA</country>
        </postal>

        <email>vimoreno@cisco.com</email>
      </address>
    </author>

    <author fullname="Michael Smith" initials="M." surname="Smith">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>170 Tasman Drive</street>

          <city>San Jose</city>

          <code>95134</code>

          <region>California</region>

          <country>USA</country>
        </postal>

        <email>michsmit@cisco.com</email>
      </address>
    </author>

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

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <region/>

          <country/>
        </postal>

        <email>farinacci@gmail.com</email>
      </address>
    </author>

    <author fullname="Luigi Iannone" initials="L." surname="Iannone">
      <organization>Telecom ParisTech</organization>

      <address>
        <email>luigi.iannone@telecom-paristech.fr</email>
      </address>
    </author>

    <date day="21" month="July" year="2014"/>

    <area>Routing Area</area>

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

    <keyword>LISP; deployment; NVO3</keyword>

    <abstract>
      <t>The purpose of this draft is to document how the Locator/ID
      Separation Protocol (LISP) Control Plane can be used to offer a unified
      (offering L2 AND L3) Overlay solution that matches the framework and
      requirements of Network Virtualization over L3 (NVO3). This information
      is provided as input to the NVO3 analysis of the suitability of existing
      IETF protocols to the NVO3 requirements.</t>
    </abstract>

    <note title="Requirements Language">
      <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">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>The purpose of this draft is to provide a mapping between the Network
      Virtualization over L3 (NVO3) framework <xref
      target="I-D.ietf-nvo3-framework"/> and the Locator/ID Separation
      Protocol (LISP) <xref target="RFC6830"/>, and in particular how LISP
      components map to the reference models defined therein. This document
      extends the scope of<xref target="I-D.maino-nvo3-lisp-cp"> </xref> to
      cover the case of a unified overlay that includes L2 and L3
      services.</t>

      <t>LISP is a flexible map and encap framework that can be used for
      overlay network applications, including Data Center Network
      Virtualization. The LISP framework provides two main tools for NVO3:</t>

      <t><list style="numbers">
          <t>A Data Plane that specifies how Endpoint Identifiers (EIDs) are
          encapsulated in Routing Locators (RLOCs), and</t>

          <t>A Control Plane that specifies the interfaces to the LISP Mapping
          System <xref target="RFC6833"/>. The LISP Mapping system provides
          the mapping between EIDs and RLOCs.</t>
        </list></t>

      <t>LISP can be leveraged to offer services to both Physical and Virtual
      endpoints, and is architecturally EID address family agnostic. Some
      flows will be across an L3 overlay (using IP addresses as EIDs), and
      other flows will be across an L2 overlay (using MAC addresses as
      EIDs).</t>

      <t>If certain requirements are met within the architecture, the choice
      of whether a flow is sent across the L2 overlay versus across the L3
      overlay is not mapped one to one to the choice between intra subnet
      (bridging) and inter subnet (routing) forwarding. This allows the
      network administrator to offer infrastructure spanning subnets to its
      tenants, while not forcing them to deploy infrastructure-wide broadcast
      domains.</t>

      <t>This document will focus on how to offer a unified L2 and L3 overlay,
      where both L2 and L3 services can be offered to the tenant's traffic
      simultaneously.</t>

      <t>The draft will elaborate on achieving multi homing of Tenant Systems
      (TS), as well as optimal routing and forwarding, including how VM
      mobility is achieved and optimal traffic forwarding is achieved.</t>

      <t>Although the LISP specification uses a specific data plane, its
      control plane can be decoupled fairly easily from the data plane and
      thus can support various data plane encapsulations. After describing the
      various data plane options, this document also addresses the NVO3 data
      plane requirements<xref
      target="I-D.ietf-nvo3-dataplane-requirements"/>.</t>

      <t>The document continues to lay out how the NVO3 control plane
      requirements <xref target="I-D.ietf-nvo3-nve-nva-cp-req"/> are
      addressed.</t>

      <t>Finally this document will provide security considerations in <xref
      target="security"/></t>
    </section>

    <section anchor="terms" title="Definition of Terms">
      <t><list style="empty">
          <t>Flood-and-Learn: the use of dynamic (data plane) learning in
          VXLAN to discover the location of a given Ethernet/IEEE 802 MAC
          address in the underlay network.</t>

          <t/>
        </list></t>

      <t>For definition of NVO3 related terms, notably Tenant System (TS),
      Virtual Network (VN), Virtual Network Identifier (VNI), Network
      Virtualization Edge (NVE), Network Virtualization Authority (NVA), Data
      Center (DC), please consult <xref
      target="I-D.ietf-nvo3-framework"/>.</t>

      <t>For definitions of LISP related terms, notably Map-Request,
      Map-Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR),
      Endstation IDentifier (EID), Routing LOCator (RLOC), Map-Server (MS) and
      Map-Resolver (MR) please consult the LISP specification <xref
      target="RFC6830"/>.</t>
    </section>

    <section title="NVO3 Framework and LISP">
      <t/>

      <section title="NVO3 Generic Reference Model">
        <t><xref target="I-D.maino-nvo3-lisp-cp"/> provides a mapping of the
        NVO3 generic reference model <xref target="I-D.ietf-nvo3-framework"/>
        onto the LISP architecture. In this document we will focus on the
        unified L2/L3 LISP control plane, and on how it will optimize
        forwarding .</t>
      </section>

      <section title="NVE Reference Model">
        <t>The LISP NVE Reference Model is described in <xref
        target="I-D.maino-nvo3-lisp-cp"/>. This section will look at the
        different types of NVEs: L2-only, L3-only, and unified L2/L3, as well
        as looking at VM Mobility, Multi-homing, optimal forwarding and
        external connectivity aspects. How TSes connect to the network is
        described in <xref target="VN-connect"/>.</t>

        <section title="Types of NVE's">
          <t><xref target="RFC6830"/> is defined as a L3 NVE, and it can be
          enhanced to support L2 NVEs.</t>

          <t>The separation of the L2 NVE and L3 NVE functions can be based on
          the nature of the packets: bridged packets are assigned to the L2
          NVE function, while routed packets are assigned to the L3 NVE
          function. Therefore these discrete functions could live on discrete
          networking nodes.</t>

          <t>However, it is possible to use LISP as an unified control plane,
          that combines and co-locates the function of L2/L3 NVE onto a single
          node. The network administrator can choose which traffic will be
          forwarded across each service type.</t>

          <section title="L2 only NVE">
            <t><xref target="I-D.smith-lisp-layer2"/> describes an
            encapsulation method for carrying Ethernet and IEEE 802 media
            access control (MAC) frames within the Locator/ID Separation
            Protocol (LISP). As described in <xref
            target="I-D.maino-nvo3-lisp-cp"/> MAC addresses are used as EIDs
            in an L2 only NVE. As control plane learning is used, only
            broadcast and multicast traffic needs mult-destination support
            from the underlay.</t>

            <t>The frame format defined in <xref
            target="I-D.mahalingam-dutt-dcops-vxlan"/>, has a header
            compatible with the LISP data path encapsulation header, when MAC
            addresses are used as EIDs, as described in section 4.12.2 of
            <xref target="I-D.ietf-lisp-lcaf"/>.</t>

            <t>The LISP control plane is extensible, and can support non-LISP
            data path encapsulations such as NVGRE <xref
            target="I-D.sridharan-virtualization-nvgre"/>, or other
            encapsulations that provide support for network
            virtualization.</t>
          </section>

          <section title="L3 only NVE">
            <t>LISP is defined as a virtualized IP routing and forwarding
            service in <xref target="RFC6830"/>, and as such can be used to
            provide L3 NVE services.</t>
          </section>

          <section anchor="L2L3NVE" title="Unified L2/L3 NVE">
            <t>When using a unified L2/L3 NVE, IP EIDs are registered to the
            LISP mapping system with the MAC Address of the Tenant System (TS)
            as an additional RLOC (next to the NVE RLOC), through the methods
            defined in <xref target="I-D.ietf-lisp-lcaf"/>, by encoding
            Key/Value Pairs. MAC Address based EIDs will also be registered
            for TSes that are transmitting non-IP based traffic. TSes that
            send out both IP and non-IP traffic will therefore be registered
            twice. For the L2 overlay the Virtual Networking Instance
            (VNI)/IID denotes a network-wide bridge domain, while for the L3
            overlay the VNI/IID denotes a Virtual Routing Forwarding (VRF)
            instance.</t>

            <t>Implementing an NVE with a unified L2 and L3 overlay support is
            beneficial for multiple reasons:</t>

            <t>Primarily it allows the network administrator to choose which
            traffic traverses the L2 overlay versus the L3 overlay, not only
            on the basis of intra-subnet (bridged) versus inter-subnet
            (routed) traffic flows. As a matter of fact, it is highly
            beneficial to choose a policy where all IP traffic is forwarded
            across the L3 overlay (i.e. both intra- and inter-subnet traffic).
            Effectively this allows the 'spread' of subnets across the
            Datacenter(s) without leading to network wide broadcast and
            associated failure domains, while allowing free mobility of the
            end-stations.</t>

            <t>Secondarily, when all the TS IP and MAC addresses are
            registered with the NVA/LISP Mapping system, optimisations in ARP
            and ND <xref target="RFC4861"/> forwarding and handling can be
            achieved. ARPs and IPv6 NDs for 'unknown' destinations are by
            default dropped, although a policy can allow for 'unknown' ARP/ND
            packets to be flooded across the underlay if so desired by the
            operator (e.g. when there is a desire to support 'silent
            hosts').</t>

            <t>Finally, as all IP traffic is forwarded across a L3 overlay,
            and ARP/ND operations do not need flooding services, the amount of
            traffic that needs to traverse the L2 overlay is limited to non-IP
            traffic only. This makes the registration of MAC-addresses as EIDs
            with the LISP control plane optional. The system in this case
            could use ingress replication and Flood-and-Learn to handle the
            non-IP traffic. Of course, the use of the LISP control plane for
            MAC address based EIDs is another option as well, but the choice
            is left to the network administrator.</t>

            <t>However, in order to achieve the benefits of this model, there
            are some requirements of how TSs can connect to the unified L2/L3
            NVE, and there are also requirements on how default gateway MAC/IP
            addresses are assigned to the NVE function, and how forwarding is
            done on the NVE function:<list style="symbols">
                <t>The NVE MUST always do an IP lookup for IP based traffic,
                independent of whether the destination is within the same
                subnet or not, or whether the destination TS is attached to
                the same VLAN or L2 NVI as the source TS.</t>

                <t>The unified L2/L3 NVE NVI instance MUST have a uniform
                default gateway MAC-address and IP address across the entire
                NVO3 network. This is to make sure that a TS can always reach
                its default gateway, irrespective of location.</t>

                <t>A TS can connect across a L2 switched network to a unified
                L2/L3 NVE, but traffic forwarded MUST follow a simple rule,
                where all traffic from a TS MUST always be sent upstream to
                the unified L2/L3 NVE, regardless of its destination MAC
                address, and traffic from locally attached TS's MUST be
                switched through the NVE. Directly connecting a TS to a
                unified L2/L3 NVE automatically solves that requirement.</t>
              </list></t>

            <t>There are various options to provide unified L2 and L3 support
            for LISP in the data path.</t>

            <t><xref target="I-D.smith-lisp-layer2"/> extends LISP to support
            MAC addresses as EIDs, and can be used in combination with <xref
            target="RFC6830"/>, using the destination UDP port in the outer
            LISP header for disambiguation.</t>

            <t>Recently extensions to both LISP and VXLAN have been proposed
            to offer multiprotocol support across the same outer header format
            (i.e. using a single UDP port number), as described in <xref
            target="I-D.lewis-lisp-gpe"/>, and <xref
            target="I-D.quinn-vxlan-gpe"/> respectively. It is to be noted
            that some functionality offered by native LISP is no longer
            available when using the <xref
            target="I-D.lewis-lisp-gpe"/>extension (namely nonce, echo-nonce,
            and map-versioning). These are optional control plane
            optimizations implemented in the data plane for <xref
            target="RFC6830"/>, and their use is less relevant in DC
            applications.</t>

            <t>The remainder of this document assumes a unified L2/L3 NVE
            deployment model.</t>
          </section>
        </section>

        <section title="Multihoming aspects">
          <t>If the TSes are co-located with the xTR/NVE function, no support
          for multi-homing is needed.</t>

          <t>If the network between the L2 device connecting the TSes and the
          LISP xTRs is a simple hub and spoke switched L2 topology using VLANs
          (this is a common assumption in DC networks), a multi-chassis Link
          Aggregation Group (LAG) solution can be used to offer redundancy,
          where both xTRs will be seen by the access device as one logical
          entity. xTRs connected to the same L2 switched access network are
          part of the same 'LISP site', and both of them can be used to send
          traffic to TSes behind them, as both xTRs are registering to the
          LISP mapping system for the EIDs behind them. Registrations
          performed by the individual xTR (as a result of detection of a new
          EID) part of the same site are performed using the RLOCs of all xTRs
          connected to that site. How the multi-chassis LAG solution is build
          is out of scope of this draft.</t>
        </section>

        <section title="External connectivity aspects">
          <t>External connectivity between a LISP enabled NVO3 DC, as well as
          any LISP site, and the external world can be handled through a
          gateway device.</t>

          <t>In case the gateway device handles connectivity to VPNs or the
          Internet, LISP interworking will be employed at the gateway device
          as per <xref target="RFC6832"/>.</t>

          <t>In case the gateway device is used to interconnect to another DC
          part of the same administrative domain (one Mapping System governs
          both DCs), the only function needed on this device is routing within
          the RLOC address space.</t>

          <t>In case separate LISP Mapping systems are used, interworking has
          to be established between them, as well as providing routing between
          the two administrative domain in between the RLOC address spaces of
          both DCs respectively. Today there is no described way of
          interworking between DDT based Mapping systems. An external
          controller could also insert new RLOC locations into a DDT based
          Mapping system when an EID has moved to a location not governed by
          this particular Mapping system.</t>
        </section>

        <section title="Optimal Forwarding aspects">
          <t>Implementing a co-located and unified L2 and L3 NVE, and placing
          that NVE as close as possible to the TSes, leads to the most optimal
          forwarding.</t>

          <t>East-to-west traffic (from NVE to NVE) will always be
          mapped-and-encapped towards the 'right' NVE, as the NVA function
          (the LISP Mapping system) has knowledge about all of the TSes IP and
          MAC addresses.</t>

          <t>North to South traffic (traffic ingress into the DC) will also be
          delivered to the right NVE, without traffic tromboning, as traffic
          is switched based on the EID IP address, which will always point to
          the correct ETR/RLOC.</t>

          <t>Traffic going from TSes to external destinations will also not be
          affected by traffic tromboning as all NVE's part of an NVI are seen
          as the same default gateway, independent of location.</t>

          <t>Traffic tromboning can occur if the last hop router is not in the
          same location as the egress NVE, and if only a single L2 NVE is
          deployed. In other words, the only way for a L2-only NVE based NVO3
          system to avoid traffic tromboning for north-south traffic, is by
          centralizing the default gateway for all VNI's in one location (that
          in some cases may be suboptimal).</t>
        </section>

        <section anchor="vm-mobility" title="VM Mobility aspects">
          <t>This section shows how the LISP control plane deals with VM
          mobility when end systems are migrated from one NVE/DC to
          another.</t>

          <t>We'll assume that a signaling protocol, as described in <xref
          target="I-D.kompella-nvo3-server2nve"/>, signals to the NVE
          operations such as creating/terminating/migrating an end system. The
          signaling protocol consists of three basic messages: "associate",
          "disassociate", and "pre-associate". The signaling protocol for
          attach/detach is in addition and orthogonal to the LISP control
          plane.</t>

          <t>Two approaches are laid out: An approach at L2, where
          MAC-addresses are used as EID, and an approach at L3, where both IP
          and MAC addresses are used as EIDs.</t>

          <section title="VM Mobility at L2">
            <t>VM mobility at L2 is described in <xref
            target="I-D.maino-nvo3-lisp-cp"/></t>

            <t>It is to be noted that the approach of solving VM mobility at
            L2 introduces scalability problems in terms of failure domain, NVA
            scaling (as MAC addresses are a flat and non de-aggregatable
            address space) and BUM containment.</t>
          </section>

          <section title="VM Mobility at L3">
            <t>This approach solves the scaling problems of the L2 approach by
            assuming that the majority of traffic is IP based. End Systems are
            therefor registered with their IP addresses as EID and xTR IP
            address as an RLOC, while their MAC-address is registered as an
            additional RLOC for the same EID.</t>

            <t><figure align="center" anchor="l2-mobility"
                title="End System Mobility">
                <artwork align="center"><![CDATA[
                                ,---------.
                              ,'           `.
                             (Mapping System )
                              `.           ,'
                                `-+------+'
                             +--+--+   +-+---+
                             |MS/MR|   |MS/MR|
                             +-+---+   +-----+
                                 |        |
                             .--..--. .--. ..
                            (    '           '.--.
                         .-.'        L3          '
                        (         Underlay       )
                         (                     '-'
                          ._.'--'._.'.-._.'.-._)  
                 RLOC=IP_A //                  \\ RLOC=IP_B
                        +---+--+              +-+--+--+ 
                  .--.-.|xTR A |'.-.         .| xTR B |.-.    
                 (      +---+--+    )       ( +-+--+--+   ) 
                (                __.       (              '.
              ..'  LISP Site A  )         .'   LISP Site B  )
             (             .'-'          (             .'-'
               '--'._.'.    )\            '--'._.'.    )\ 
                /       '--'  \            /       '--'  \ 
            '--------'   '--------'     '--------'   '--------'
            :  End   :   :  End   : ==> :  End   :   :  End   :
            : Device :   : Device : ==> : Device :   : Device :
            '--------'   '--------'     '--------'   '--------'
               EID=            EID=<IID1,MAC_W>         EID=
           <IID2,MAC_X>        EID=<IID1,IP_W>        <IID1,MAC_Z> 
           <IID2,IP_X>                                <IID1,IP_Z>]]></artwork>
              </figure></t>

            <t>It is assumed that the LISP xTRs have a unified L2 and L3
            map-en-encap function, where IP packets, regardless of the fact
            they are switched intra- or inter subnet, are mapped-and-encapped
            across the L3 overlay. All other traffic (non-routable traffic,
            non-IP traffic) is mapped-and-encapped by the L2 overlay. It is
            also assumed that all XTRs offer the same default gateway IP and
            MAC address across the network, on a per VNI instance.</t>

            <t>A unified L2/L3 overlay will lead in the xTRs registering two
            sets of EIDs for specific end systems, who deliver a mix of IP and
            non-IP traffic:</t>

            <t><list style="symbols">
                <t>A tuple of EID=&lt;IID, IP&gt; to use for IP traffic across
                the L3 overlay, whereby the IID maps to a VRF instance. It
                will register the EID to multiple RLOCs, one being the xTR IP
                address, and the other one being the TS MAC Address.</t>

                <t>A tuple EID= &lt;IID,MAC&gt; to use for non-routable,
                non-IP traffic, across the L2 overlay, whereby the IID maps to
                a network-wide Bridge Domain.</t>
              </list></t>

            <t>Assume the scenario described in <xref target="l2-mobility"/>.
            Also assume that for the sake of this discussion, the VMs do not
            send out traffic that needs treatment by an L2 overlay.</t>

            <t>As a result of the end system registration, the Mapping System
            contains the EID-to-RLOC mapping for end system W that associates
            EID=&lt;IID1, IP_W&gt; with the RLOC(s) associated with LISP site
            A (IP_A), as well as the RLOC associated with the MAC Address
            MAC_W of the end system W.</t>

            <t>The process of migrating end system W from data center A to
            data center B is initiated.</t>

            <t>ETR B receives a pre-associate message that includes
            EID=&lt;IID1, IP_W&gt;. ETR B sends a Map-Register to the mapping
            system registering RLOC=IP_B as an additional locator for end
            system W with priority set to 255. This means that the RLOC MUST
            NOT be used for unicast forwarding, but the mapping system is now
            aware of the new location.</t>

            <t>During the migration process of end system W, ETR A receives a
            dissociate message, and sends a Map-Register with Record TTL=0 to
            signal the mapping system that end system W is no longer reachable
            at RLOC=IP_A. xTR A will also add an entry in its forwarding table
            that marks EID=&lt;IID1, IP_W&gt; as non-local.</t>

            <t>When end system W has completed its migration, ETR B receives
            an associate message for end system W, and sends a Map-Register to
            the mapping system setting a non-255 priority for RLOC=IP_B. Now
            the mapping system is updated with the new EID-to-RLOC mapping for
            end system W with the desired priority.</t>

            <t>The remote ITRs that were corresponding with end system W
            during the migration will keep sending packets to ETR A.</t>

            <t>ETR A will keep forwarding locally those packets until it
            receives a dissociate message, and the entry in the forwarding
            table associated with EID=&lt;IID1, IP_W&gt; is marked as
            non-local.</t>

            <t>Subsequent packets arriving at ETR A from a remote ITR, and
            destined to end system W will hit the entry in the forwarding
            table that will generate an exception, and will generate a
            Solicit-Map-Request (SMR) message that is returned to the remote
            ITR.</t>

            <t>Upon receiving the SMR the remote ITR will invalidate its local
            map-cache entry for EID=&lt;IID1, IP_W&gt; and send a new
            Map-Request for that EID. The Map-Request will generate a
            Map-Reply that includes the new EID-to-RLOC mapping for end system
            W with RLOC=IP_B.</t>

            <t>Similarly, unencapsulated packets arriving at ITR A from local
            end systems and destined to end system W will hit the entry in the
            forwarding table marked as non-local, and will generate an
            exception that by sending a Map-Request for EID=&lt;IID1, IP_W&gt;
            will populate the map-cache of ITR A with an EID-to-RLOC mapping
            for end system W with RLOC=IP_B.</t>
          </section>
        </section>
      </section>

      <section anchor="dataplane"
               title="LISP dataplane options and NVO3 dataplane requirements">
        <t>This section maps the NVO3 data plane requirements <xref
        target="I-D.ietf-nvo3-dataplane-requirements"/> to the various options
        available.</t>

        <section anchor="native-lisp-dp" title="Native LISP Data Plane">
          <t><xref target="LISP-header"/>shows the LISP header defined in the
          LISP specification <xref target="RFC6830"/>. The UDP and LISP
          headers are shown below for reference. For header fields description
          see section 5.3 of <xref target="RFC6830"/>.</t>

          <t><figure align="center" anchor="LISP-header" title="LISP Header">
              <artwork><![CDATA[        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            IPv4 or IPv6 Header  (with RLOC addresses)         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = (L2-)LISP   |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|flags|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator Status Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure></t>

          <t>When the headers are used for encapsulating IP Packets, the UDP
          Destination Port is set to 4341. When the headers are used for
          encapsulating L2 frames, the UDP Destination Port is set to 8472
          <xref target="I-D.smith-lisp-layer2"/>.</t>

          <t>When used in private DC and Enterprise networks, the 'I'-bit
          (Instance bit) is set, indicating the presence of an Instance ID
          (IID) inside the header. A Virtual Networking Instance (VNI) is
          indicated by the IID, a 24 bit field, which is used as a global
          identifier for the tenant in LISP. When used for L3 services, the
          IID can be seen as a VRF, when used for L2 services, the IID can be
          seen as a L2 Bridge Domain instance.</t>

          <t>Virtual Access Point (VAP) identification is naturally supported
          by combining LISP and Integrated Routing and Bridging (IRB). IRB
          allows local ports or logical ports (ports instantiated on a local
          port, where frames are assigned based on some fields in the header
          like VLAN IDs (VIDs)), to be added to a NVE-local bridge domain.
          That bridge domain instantiates the L2 Specific VNI. The bridge
          domain also connects to a virtual routed port, which instantiates
          the L3 specific VNI.</t>

          <t>A L2 VNI provides an emulated Ethernet Multipoint service through
          the use of the LISP control plane, where it registers MAC addresses
          as EIDs.</t>

          <t>Loop-avoidance is handled by control plane learning, and control
          plane enabled registration of all TS EIDs as soon as they send a
          first packet. Therefore unicast traffic will never result in loops,
          as there is no 'unknown' unicast. multi-destination traffic
          forwarding is performed using a multicast enabled underlay and LISP
          procedures laid out in <xref target="RFC6831"/> or through ingress
          replication to the list of participating NVEs in that NVI, and
          therefore is loop-free.</t>

          <t>A L3 VNI behaves exactly as an IP VRF and therefore supports
          virtualized IP routing and forwarding, through per tenant forwarding
          with IP address isolation and L3 tunneling for interconnecting
          instances of the same VNI on NVEs.</t>

          <t>Note that , within this document, it is assumed that a unified
          L2/L3 NVE is deployed and therefore all IP traffic will be forwarded
          using the L3 overlay, even intra-subnet traffic.</t>

          <t>The LISP header performs the function of the NVO3 overlay
          header.</t>

          <t>Through using the LISP control plane, the egress NVE can be
          looked up.</t>

          <t>As the outer LISP header is an IPv4 or IPv6 header,
          differentiated forwarding can be supported naturally. Equally, as
          LISP uses IP/UDP as a transport, multipath over LAG and ECMP in the
          underlay are naturally supported, through the entropy introduced in
          the UDP header by selecting per flow source UDP port numbers. A LISP
          based NVO3 network can work in both uniform and pipe models <xref
          target="RFC2983"/> and fully supports ECN marking as per <xref
          target="RFC6040"/> .</t>

          <t>As it does for L3 services, the LISP control plane replaces the
          use of dynamic data plane learning (Flood-and-Learn) for unicast
          traffic for L2 services. Packet replication in the underlay network
          to support L2 broadcast, unknown unicast (optional, as all
          MAC-address are learned by the control plane) and multicast L2 and
          L3 overlay services can be done by:</t>

          <t><list style="symbols">
              <t>Ingress replication, which reduces the need for multicast in
              the NVO3 underlay to zero.</t>

              <t>Use of underlay multicast trees. These trees can be
              aggregated globally, or per tenant (rather than per VNI).</t>
            </list></t>

          <t><xref target="RFC6831"/> and <xref
          target="I-D.farinacci-lisp-mr-signaling"/>specifies how to map a
          multicast flow in the EID space during distribution tree setup and
          packet delivery in the underlay network. LISP, being an IP based
          map-and-encap protocol, does not require any specific data plane
          functionality to make this work.</t>

          <t>LISP interworking is described in <xref target="RFC6832"/> and
          fully supports connectivity to the internet or VPN gateways through
          the use of Proxy xTR's.</t>

          <t>LISP, being an IP based protocol, supports ICMP-based MTU Path
          Discovery <xref target="RFC1191"/> , <xref target="RFC1981"/>as well
          as extended MTU Path Discovery techniques <xref target="RFC4821"/>.
          LISP also supports a stateless and stateful way of dealing with
          Large Encapsulated packets, see section 5.4 of <xref
          target="RFC6830"/>.</t>

          <t>Multi-homing is handled in the control plane, by allowing the
          LISP mapping system to have multiple RLOC entries for every EID,
          allowing the ITR to load balance across both ETR's. xTRs register a
          'LISP site id' to the mapping system when they come online. When the
          LISP mapping system receives a registration for a given EID from a
          certain xTRs, it will install that EID entry pointing to all the
          RLOCs/xTR that have the same site-id. By performing LAG across
          multiple xTRs, multi-homing can be provided for the access or
          virtual switch that connects the TSs.</t>

          <t>OAM can be performed across LISP in the same way as OAM is
          performed over IP routed, or Ethernet L2 switched environments.</t>
        </section>

        <section title="LISP with Generic Protocol Extension (LISP-GPE)">
          <t><xref target="I-D.lewis-lisp-gpe"/> introduces multiprotocol
          support for LISP, by extending the LISP header, as shown in <xref
          target="lisp-gpe-header"/> .</t>

          <t><figure align="center" anchor="lisp-gpe-header"
              title="LISP with Generic Protocol Extension Header">
              <artwork><![CDATA[    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Source Port = xxxx      |       Dest Port = 4341        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           UDP Length          |        UDP Checksum           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|L|E|V|I|P|R|R| Reserved      |Nonce/Map-Version/Protocol-Type|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Instance ID/Locator-Status-Bits               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure></t>

          <t>A Protocol Bit (P-bit) is introduced, that when set, allows the
          insertion of a 16-bit Protocol Type. The UDP destination port number
          is 4341 for all protocol types.</t>

          <t>Although the use of Nonce and Map-versioning are not allowed
          simultaneously with Protocol Type with this deployment, all of the
          solutions to the requirements described in <xref
          target="native-lisp-dp"/> are exactly the same with this data plane
          encapsulation in an NVO3 context.</t>
        </section>

        <section title="VxLAN-GPE">
          <t><xref target="I-D.quinn-vxlan-gpe"/> extends the VXLAN
          encapsulation with a Protocol Type, by introducing a Protocol Bit
          (P-bit) and a 16-bit Protocol Type in the VXLAN header, see <xref
          target="vxlan-gpe-header"/>. Note that this data plane encapsulation
          is very similar to LISP-GPE, when used in an NVO3 context.</t>

          <t><figure align="center" anchor="vxlan-gpe-header"
              title="VXLAN with Generic Protocol Extension">
              <artwork><![CDATA[    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Source Port = xxxx      |       Dest Port = 4789        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           UDP Length          |        UDP Checksum           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|R|R|R|I|P|R|R|   Reserved    |   Protocol Type               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                VXLAN Network Identifier (VNI) |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure></t>

          <t>All of the solutions to the requirements described in <xref
          target="native-lisp-dp"/> are exactly the same with this data plane
          encapsulation.</t>
        </section>

        <section title="L2 only solutions such as VxLAN and nvGRE">
          <t>The LISP control plane can be leveraged to offer control plane
          learning for MAC Addresses for both the VXLAN <xref
          target="I-D.mahalingam-dutt-dcops-vxlan"/>, as well as NVGRE <xref
          target="I-D.sridharan-virtualization-nvgre"/>. However, this
          solution offers sub-optimal support and hence will not be looked
          into further.</t>
        </section>
      </section>

      <section title="NVO3 control plane requirements and LISP">
        <t>This section maps the NVO3 NVE to NVA control plane <xref
        target="I-D.ietf-nvo3-nve-nva-cp-req"/>requirements to the LISP
        control plane.</t>

        <section title="Inner to Outer Address Mapping">
          <t>The LISP control plane, through the use of a Mapping service,
          provides inner to outer address mapping.</t>

          <t>TS EIDs are registered to the LISP Mapping service by LISP ETRs
          within the context of a LISP instance ID, (i.e An NVO3 VNI).</t>

          <t>A LISP based NVE will check its local cache if it needs to send a
          packet across the overlay. If there is a cache miss, it will request
          the EID to RLOC mapping from the LISP Mapping service. If there is a
          cache hit, it will use the local EID to RLOC mapping.</t>

          <t>Cache entries are aged out when no traffic is being sent to those
          EIDs. The LISP control plane has ways of refreshing the local cache
          after the destination EID has moved to another RLOC. For more
          information, see <xref target="vm-mobility"/> and <xref
          target="RFC6830"/></t>
        </section>

        <section title="Underlying network Multi-Destination Delivery">
          <t>LISP supports delivering L2 and L3 multi-destination packets,
          independent of the underlying network multicast capabilities.</t>

          <t><xref target="RFC6831"/>, <xref
          target="I-D.farinacci-lisp-mr-signaling"/> , more specifically
          section 6, describes how the LISP Control Plane is used by NVEs/ETRs
          to join a given EID multicast group by sending LISP Map-Requests
          rather than PIM Joins. Joining can be triggered by the receipt of a
          PIM or IGMP join in the EID space. In the case of a L2 overlay
          configuration on the NVE, the join is static.</t>

          <t>In case the NVE/ETR is not multicast capable the ETR unicast RLOC
          will be registered, and will be added to the existing RLOC set for
          that given multicast EID, and the Map-Reply will contain the ITR
          from which the ETR wants to replicate. LISP ITRs will retrieve this
          list of ETRs from the Mapping System upon a Map-Request and will use
          this as a replication list.</t>

          <t>In case the underlying network is multicast capable the Map-Reply
          will contain the multicast RLOC, which will be joined via PIM
          subsequently. All this state is stored on the Mapping system, or in
          the xTR caches per IID/VNI. In case ingress replication is deemed
          unscaleable, <xref target="I-D.farinacci-lisp-te"/> can be used,
          allowing a Re-encapsulating Tunnel Router (RTR) to be used as a
          distribution server to replicate to all the NVEs.</t>

          <t>It is also important to point out that, in a unified L2/L3 NVE
          deployment, all IP traffic will get sent across the L3 overlay, and
          that ARP and ND packets are not handled using flooding.</t>

          <t>In case non-IP traffic needs to be supported, L2 EIDs only need
          to use multicast or ingress replication for broadcast and multicast,
          as unicast flows are handled by the LISP control plane. This
          significantly reduces the multicast or ingress replication load.</t>
        </section>

        <section anchor="VN-connect" title="VN connect/disconnect">
          <t>We assume that a provisioning framework will be responsible for
          provisioning end systems (e.g. VMs) in each data center. The
          provisioning system configures each end system with an Ethernet/IEEE
          802 MAC address and/or IP addresses and provisions the NVE with
          other end system specific attributes such as VLAN information, and
          TS/VLAN to VNI mapping information. LISP does not introduce new
          addressing requirements for end systems.</t>

          <t>The provisioning infrastructure is also responsible to provide a
          network attach function, that notifies the NVE (the LISP site ETR)
          that the end system is attached to a given virtual network
          (identified by its VNI/IID) and that the end system is identified,
          within that virtual network, by a given Ethernet/IEEE 802 MAC
          address.</t>

          <t>The LISP framework does not include mechanisms to provision the
          local NVE with the appropriate Tenant Instance for each Tenant
          Systems. Other protocols, such as VDP (in IEEE P802.1Qbg), should be
          used to implement a network attach/detach function, besides using
          link-up events for non-virtual end-systems. More-over it is quite
          common for devices to be able to 'sense' new tenant end-systems
          dynamically by tracking new mac addresses and IP addresses in case a
          VDP or link-up event cant be relied upon.</t>

          <t>The LISP control plane can take advantage of such a network
          attach/detach function or the discovery of new MAC/IP addresses to
          trigger the registration of a Tenant System to the Mapping System.
          This is particularly helpful to handle mobility across the DC of the
          Tenant System.</t>

          <t>Upon notification of end system network attach, the ETR sends a
          LISP Map-Register to the Mapping System. The Map-Register includes
          the EID and RLOCs of the LISP site. The EID-to-RLOC mapping is now
          available, via the Mapping System Infrastructure, to other LISP
          sites that are hosting end systems that belong to the same
          tenant.</t>

          <t>For more details on end system registration see <xref
          target="RFC6833"/>.</t>
        </section>

        <section title="VN name to VN ID Mapping">
          <t>The LISP Control Plane uses the Instance ID to identify the NVI.
          The VN Name to VNI mapping can be performed by the NVE as a result
          of local provisioning. Also, using LISP LCAF , it is possible to
          store ASCII Names in the Mapping Database, which can allow the
          system to resolve a VN Name to an IID/VNI.</t>
        </section>

        <section title="LISP Control Plane Characteristics in an NVO3 context">
          <t>LISP is a Control Plane solution that can scale very well to the
          NVO3 requirements:</t>

          <t><list style="numbers">
              <t>LISP ETRs register destination EIDs into the LISP Mapping
              System. LISP ITRs pull destination EIDs from the LISP Mapping
              System and cache them for as long as traffic is being sent to
              those destinations. Hence a LISP Based NVE is only holding state
              for the active TS to TS flows, and only for the NVIs that are
              configured on those NVEs.</t>

              <t>The LISP Control Plane is fast to acquire the needed state
              for a given destination through issuing a single
              Map-Request.</t>

              <t>When an ETR (lets say ETR1) detects an EID it will also
              register this EID to the Mapping system. If that EID has moved
              from another ETR (lets say ETR2), it will update the Mapping
              system with a Map-Notify saying to no longer forward packets to
              it, and will install a 'non-local' entry in the forwarding
              table. If an ITR has not updated its map-cache, and therefor
              sends a packet to ETR2, ETR will sent a Map-Notify directly to
              the ITR, updating its local cache. For further information see
              <xref target="vm-mobility"/></t>

              <t>As LISP support virtualization, the NVE running the LISP
              Control Plane will only be maintaining state for the Tenants
              VNIs that are configured on it.</t>

              <t>Through leveraging the LISP DDT-based Mapping system <xref
              target="I-D.ietf-lisp-ddt"/>, the necessary scaling can be
              achieved. The LISP DDT hierarchy can be based on address family,
              address family prefix, and IID, and scales in a very similar way
              as DNS.</t>

              <t>The solution described in this document does not make use of
              multiple protocols, and hence is low in complexity.</t>

              <t>Through the use of the LISP LCAF <xref
              target="I-D.ietf-lisp-lcaf"/> , extensibility is achieved. It is
              possible to add new address families (the MAC address family is
              the proof point). The LCAF format also allows lookups on a
              generic Key. This Key can be an identifier to an ACL or policy.
              A combination of multiple keys can be achieved by doing
              recursive lookups, where EID attributes are used as keys for a
              subsequent lookup. LCAF allows backwards compatibility between
              systems that use different LCAF implementations.</t>

              <t>As the state is maintained in the LISP Mapping system acting
              as an NVA, adding another NVE/xTR to the network does not
              require any changes on existing NVEs.</t>

              <t>LISP does not rely on Multicast in the underlay, while
              preserving the same Control Plane characteristics regardless of
              underlay multicast capability.</t>

              <t><xref target="I-D.barkai-lisp-nfv"/>documents one
              implementation of how the LISP Mapping System (NVA) can be
              programmed to create inner to outer address mappings. The LISP
              Control Plane will inform the xTR/NVE that hosts have moved, and
              if packets are attracted to those NVEs because of stale cache
              entries on other ITRs, packets will be routed to the right
              location, and the NVE will send a Solicited Map-Reply back to
              the ITR, clearing its cache, after which the ITR will request a
              new mapping. Obviously NVEs will be able to create inner to
              outer address mappings without the use of an orchestration
              solution.</t>

              <t>See <xref target="security"/></t>
            </list></t>
        </section>
      </section>

      <section title="NVO3 OAM Requirements and LISP">
        <t>TBD</t>
      </section>

      <section title="NVO3 Management Plane Requirements and LISP">
        <t>TBD</t>
      </section>

      <section title="Summary">
        <t>The LISP Control Plane, makes a very good choice to implement NVO3
        services due to the fact that it is agnostic to EID address families,
        and the fact that it provides an NVA in the form of the LISP Map
        Server with cache optimizations based on the pull-based LISP Map Cache
        on the LISP xTRs . The LISP control plane can be deployed across a set
        of different dataplane options as well. The usage of a unified L2 and
        L3 overlay , with the appropriate set of registrations in the LISP
        Mapping system, is recommended because of its optimal forwarding,
        scaling and IP centric characteristics, while supporting non-IP
        traffic as well.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>The security requirements for a NVO3 Control Plane are defined in
      <xref target="I-D.ietf-nvo3-security-requirements"/> . More
      specifically, seven requirements are defined (REQ 1 to REQ 7) for
      NVE-NVA Control Plane (Network Virtualization Edge to Network
      Virtualization Authority Control Plane) and two requirements (REQ 8 and
      REQ 9) for NVA-NVA Control Plane (Network Virtualization Authority to
      Network Virtualization Authority Control Plane). <xref target="sectab"/>
      provides a summary of which document defines LISP Control Plane
      mechanisms that allow to satisfy each specific requirement.</t>

      <texttable anchor="sectab"
                 title="NVO3 vs LISP CP Security      Requirements">
        <ttcol align="left">NVO3 Req.</ttcol>

        <ttcol align="left">LISP Control Plane Documents</ttcol>

        <c>REQ 1</c>

        <c><xref target="RFC6833"/> <xref target="I-D.ietf-lisp-sec"/></c>

        <c/>

        <c/>

        <c>REQ 2</c>

        <c><xref target="RFC6833"/> <xref target="I-D.ietf-lisp-sec"/></c>

        <c>REQ 3</c>

        <c>Not mandatory[1]</c>

        <c>REQ 4</c>

        <c><xref target="RFC6833"/> <xref target="I-D.ietf-lisp-sec"/></c>

        <c>REQ 5</c>

        <c><xref target="RFC6833"/> <xref target="I-D.ietf-lisp-sec"/></c>

        <c>REQ 6</c>

        <c><xref target="RFC6830"/> <xref target="RFC6833"/></c>

        <c>REQ 7</c>

        <c><xref target="RFC6830"/>[2]</c>

        <c>REQ 8</c>

        <c><xref target="I-D.ietf-lisp-ddt"/></c>

        <c>REQ 9</c>

        <c>Does not apply[3]</c>

        <postamble>[1] The requirement uses MAY as for <xref
        target="RFC2119"/> terminology. [2] Amplification attacks can be
        avoided by careful design of the mappings. [3] The existing LISP
        Control Planes do not use multicast messages.</postamble>
      </texttable>

      <t>Security mechanisms to protect the LISP Map-Register messages are
      defined in <xref target="RFC6833"/>.</t>

      <t><xref target="RFC6830"/> and <xref target="RFC6833"/> describe how to
      send control packet with limited frequencies.</t>

      <t><xref target="I-D.ietf-lisp-sec"/> defines a set of security
      mechanisms that provide origin authentication, integrity and anti-replay
      protection to LISP's EID-to-RLOC mapping data conveyed via mapping
      lookup process. <xref target="I-D.ietf-lisp-sec"/> also enables
      verification of authorization on EID-prefix claims in Map-Reply
      messages.</t>

      <t>The security of the Mapping System Infrastructure (NVA) depends on
      the particular mapping database used. The <xref
      target="I-D.ietf-lisp-ddt"/> specification, as an example, defines a
      public-key based mechanism that provides origin authentication and
      integrity protection to the LISP DDT protocol.</t>

      <t/>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t/>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
    </references>

    <references title="Informative References">
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-overlay-problem-statement.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-dataplane-requirements.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-nve-nva-cp-req.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-security-requirements.xml'?>

      <?rfc include='reference.RFC.6830'?>

      <?rfc include='reference.RFC.6831'?>

      <?rfc include='reference.RFC.6832'?>

      <?rfc include='reference.RFC.6833'?>

      <?rfc include='reference.RFC.6836'?>

      <?rfc include='reference.RFC.2983'?>

      <?rfc include='reference.RFC.6040'?>

      <?rfc include='reference.RFC.1191'?>

      <?rfc include='reference.RFC.1981'?>

      <?rfc include='reference.RFC.4821'?>

      <?rfc include='reference.RFC.4861'?>

      <?rfc include='reference.RFC.3971'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.maino-nvo3-lisp-cp.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.smith-lisp-layer2.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mahalingam-dutt-dcops-vxlan.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.sridharan-virtualization-nvgre.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-lcaf.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-framework.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-ddt.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-sec.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.lewis-lisp-gpe.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.quinn-vxlan-gpe.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.barkai-lisp-nfv.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.farinacci-lisp-mr-signaling.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.farinacci-lisp-te.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-kompella-nvo3-server2nve-02.xml'?>
    </references>
  </back>
</rfc>
