<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. --> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY ieee_802_1Q SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml6/reference.IEEE.802.1Q_2014.xml"> nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-lisp-gpe-19" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->  number="9305" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
        full title is longer than 39 characters -->

    <title>LISP
    <title abbrev="LISP-GPE">Locator/ID Separation Protocol (LISP) Generic Protocol Extension</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->
    <seriesInfo name="RFC" value="9305"/>
    <author fullname="Fabio Maino" initials="F." role="editor" surname="Maino">
      <organization abbrev="Cisco">Cisco Systems</organization>
      <address>
        <postal>
          <street/>

          <!-- Reorder these if your country does things differently -->
          <city>San Jose</city>
          <region>CA</region>

          <code>95134</code>

          <country>USA</country>
          <code></code>
          <country>United States of America</country>
        </postal>
        <email>fmaino@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <author fullname="Jennifer Lemon" initials="J." surname="Lemon">
      <organization>Broadcom</organization>
      <organization/>
      <address>
        <postal>
          <street>270 Innovation Drive</street>

          <!-- Reorder these if your country does things differently -->

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

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

        <email>jennifer.lemon@broadcom.com</email>

        <!-- uri and facsimile elements may also be added -->
        <email>jalemon@meus.us</email>
      </address>
    </author>
    <author fullname="Puneet Agarwal" initials="P." surname="Agarwal">
      <organization>Innovium</organization>
      <address>
        <postal>
          <street/>

          <!-- Reorder these if your country does things differently -->
          <city/>
          <region/>
          <code/>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>puneet@acm.org</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <author fullname="Darrel Lewis" initials="D." surname="Lewis">
      <organization abbrev="Cisco">Cisco Systems</organization>
      <address>
        <postal>
          <street/>

          <!-- Reorder these if your country does things differently -->
          <city>San Jose</city>
          <region>CA</region>

          <code>95134</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>darlewis@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <author fullname="Michael Smith" initials="M." surname="Smith">
      <organization abbrev="Cisco">Cisco Systems</organization>
      <address>
        <postal>
          <street/>

          <!-- Reorder these if your country does things differently -->
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>michsmit@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <date day="26" month="July" year="2020"/>

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
        in the current day for you. If only the current year is specified, xml2rfc will fill
	 in the current day and month for you. If the year is not the current one, it is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. --> month="October" year="2022"/>
    <area>Routing</area>
    <workgroup>lisp</workgroup>
    <keyword>security</keyword>
    <keyword>policy</keyword>

    <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->
    <abstract>
      <t>This document describes extensions to the Locator/ID Separation
      Protocol (LISP) Data-Plane, data plane, via changes to the LISP header, to support
      multi-protocol
      multiprotocol encapsulation and allow to introduce the introduction of new protocol
      capabilities.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="Introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The LISP Data-Plane data plane is defined in <xref
      target="I-D.ietf-lisp-rfc6830bis"/>. target="RFC9300" format="default"/>.
      It specifies an encapsulation
      format that carries IPv4 or IPv6 packets (henceforth jointly referred to
      as IP) in a LISP header and outer UDP/IP transport.</t>
      <t>The LISP Data-Plane data plane header does not specify the protocol being
      encapsulated and therefore and, therefore, is currently limited to encapsulating only IP
      packet payloads. Other protocols, most notably the Virtual eXtensible Local
      Area Network (VXLAN) protocol <xref target="RFC7348"/> target="RFC7348" format="default"/> (which defines a similar header format similar to LISP), are used to encapsulate Layer-2 Layer 2 (L2) protocols protocols,
      such as Ethernet.</t>
      <t>This document defines an extension for the LISP header, as defined in
      <xref target="I-D.ietf-lisp-rfc6830bis"/>, target="RFC9300" format="default"/>, to indicate the inner
      protocol, enabling the encapsulation of Ethernet, IP IP, or any other
      desired protocol protocol, all the while ensuring compatibility with existing LISP
      deployments.</t>
      <t>A flag in the LISP header, called header -- the P-bit, P-bit -- is used to signal the
      presence of the 8-bit Next Protocol 'Next Protocol' field. The Next Protocol 'Next Protocol' field, when
      present, uses 8 bits of the field that was allocated to the echo-noncing Echo-Noncing
      and map-versioning Map-Versioning features in <xref
      target="I-D.ietf-lisp-rfc6830bis"/>. target="RFC9300" format="default"/>. Those two features are no longer
      available when the P-bit is used. However, appropriate LISP-GPE (LISP LISP
      Generic Protocol Extension) Extension (LISP-GPE) shim headers can be defined to specify
      capabilities that are equivalent to echo-noncing Echo-Noncing and/or
      map-versioning.</t>
      Map-Versioning.</t>
      <t>Since all of the reserved bits of the LISP Data-Plane data plane header have
      been allocated, LISP-GPE can also be used to extend the LISP Data-Plane data plane
      header by defining Next Protocol "shim" shim headers that implements implement new
      data plane functions not supported in the LISP header. For example, the use
      of the Group-Based Policy (GBP) header <xref
      target="I-D.lemon-vxlan-lisp-gpe-gbp"/> target="VXLAN-LISP" format="default"/> or of the In-situ In situ Operations,
      Administration, and Maintenance (IOAM) header <xref
      target="I-D.brockners-ippm-ioam-vxlan-gpe"/> target="VXLAN-GPE" format="default"/> with LISP-GPE, LISP-GPE can be
      considered an extension to add support in the Data-Plane data plane for Group-Based
      Policy GBP functionalities or IOAM metadata.</t>
      <section anchor="Conventions" title="Conventions"> numbered="true" toc="default">
        <name>Conventions</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
        "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
        "OPTIONAL"
        "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP
        14 <xref target="RFC2119"/> target="RFC2119" format="default"/> <xref target="RFC8174"/> target="RFC8174" format="default"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>
      <section anchor="Abbreviations" title="Definition numbered="true" toc="default">
        <name>Definitions of Terms"> Terms</name>
        <t>This document uses terms already defined in <xref
        target="I-D.ietf-lisp-rfc6830bis"/>.</t> target="RFC9300" format="default"/>.</t>
      </section>
    </section>
    <section anchor="LISP_header"
             title="LISP numbered="true" toc="default">
      <name>LISP Header Without without Protocol Extensions"> Extensions</name>
      <t>As described in <xref target="Introduction"/>, target="Introduction" format="default"/>, the LISP header has no
      protocol identifier that indicates the type of payload being carried.
      Because of this, LISP is limited to carrying IP payloads.</t>
      <t>The LISP header <xref target="I-D.ietf-lisp-rfc6830bis"/> target="RFC9300" format="default"/> contains a
      series of flags (some defined, some reserved), a Nonce/Map-version field 'Nonce/Map-Version' field,
      and an instance ID/Locator-status-bit 'Instance ID/Locator-Status-Bits' field. The flags provide
      flexibility to define how the various fields are encoded. Notably, Flag
      bit 5 is the last reserved bit in the LISP header.</t>
      <figure align="left" anchor="LISP_Header" title="LISP Header"> anchor="LISP_Header">
        <name>LISP Header</name>
<artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Instance ID/Locator-Status-Bits               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
    </section>
    <section anchor="LISP_GPE"
             title="Generic numbered="true" toc="default">
      <name>LISP Generic Protocol Extension for LISP (LISP-GPE)"> (LISP-GPE)</name>
      <t>This document defines two changes to the LISP header in order to
      support multi-protocol multiprotocol encapsulation: the introduction of the P-bit and
      the definition of a Next Protocol 'Next Protocol' field. This document specifies the
      protocol behavior when the P-bit is set to 1, 1; no changes are introduced
      when the P-bit is set to 0. The LISP-GPE header is shown in <xref
      target="GPE_Header"> target="GPE_Header" format="default"> </xref> and described below.</t>
      <figure align="left" anchor="GPE_Header" title="LISP-GPE Header"> anchor="GPE_Header">
        <name>LISP-GPE Header</name>
<artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|P|K|K|        Nonce/Map-Version/Next Protocol        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Instance ID/Locator-Status-Bits               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>

      <t/>

      <t><list style="hanging">
          <t hangText="P-Bit:">Flag

      <dl newline="false" spacing="normal">
        <dt>P-Bit:</dt>
	<dd>Flag bit 5 is defined as the Next Protocol bit.
          The P-bit is set to 1 to indicate the presence of the 8 bit Next
          Protocol field.</t>

          <t hangText="">If 8-bit 'Next
        Protocol' field.</dd>
      </dl>
        <t>If the P-bit is clear (0) (0), the LISP header is
          bit-by-bit equivalent to the definition in <xref
          target="I-D.ietf-lisp-rfc6830bis"/>.</t> target="RFC9300" format="default"/>.</t>
        <t>When the P-bit is set to 1, bits N, E, and V, and bits 8-23 of the
          'Nonce/Map-Version/Next Protocol' field MUST <bcp14>MUST</bcp14> be set to zero on
          transmission and MUST <bcp14>MUST</bcp14> be ignored on receipt. Features equivalent to
          those that were implemented with bits N,E N, E, and V in <xref
          target="I-D.ietf-lisp-rfc6830bis"/>,
	  target="RFC9300" format="default"/>, such as echo-noncing Echo-Noncing and
          map-versioning,
	Map-Versioning, can be implemented by defining appropriate LISP-GPE
	shim headers.</t>
        <t>When the P-bit is set to 1, the LISP-GPE header is encoded
          as:</t>

          <t><figure align="left" anchor="GPE_Header_Next_Protocol"
              title="LISP-GPE

          <figure anchor="GPE_Header_Next_Protocol">
            <name>LISP-GPE with P-bit set Set to 1"> 1</name>
<artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
 0 x 0 0 x 1 x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|P|K|K|             0x0000            | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Instance ID/Locator-Status-Bits               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure></t>

          <t hangText="Next Protocol:">When
          </figure>

<dl newline="false" spacing="normal">
        <dt>Next Protocol:</dt>
        <dd>When the P-bit is set to 1, the lower 8
          bits of the first 32-bit word are used to carry a Next Protocol.
          This Next Protocol 'Next Protocol' field contains the protocol of the encapsulated
          payload packet.</t> packet.</dd>
	</dl>

    <t>This document defines the following Next Protocol values:</t>

          <t><list style="hanging">
              <t hangText="0x00 :">Reserved</t>

              <t hangText="0x01 :">IPv4</t>

              <t hangText="0x02 :">IPv6</t>

              <t hangText="0x03 :">Ethernet</t>

              <t hangText="0x04 :">Network
          <dl newline="false" spacing="normal">
            <dt>0x00:</dt>
            <dd>Reserved</dd>
            <dt>0x01:</dt>
            <dd>IPv4</dd>
            <dt>0x02:</dt>
            <dd>IPv6</dd>
            <dt>0x03:</dt>
            <dd>Ethernet</dd>
            <dt>0x04:</dt>
            <dd>Network Service Header (NSH) <xref
              target="RFC8300"/></t>

              <t hangText="0x05 to 0x7D:">Unassigned</t>

              <t hangText="0x7E, 0x7F:">Experimentation target="RFC8300" format="default"/></dd>
            <dt>0x05 to 0x7D:</dt>
            <dd>Unassigned</dd>
            <dt>0x7E and testing</t>

              <t hangText="0x80 0x7F:</dt>
            <dd>Experimentation and testing</dd>
            <dt>0x80 to 0xFD:">Unassigned 0xFD:</dt>
            <dd>Unassigned (shim headers)</t>

              <t hangText="0xFE, 0xFF:">Experimentation headers)</dd>
            <dt>0xFE, 0xFF:</dt>
            <dd>Experimentation and testing (shim
              headers)</t>
            </list></t>

          <t hangText="">The
              headers)</dd>
          </dl>

        <t>The values are tracked in the IANA LISP-GPE "LISP-GPE Next
          Protocol Registry
        Protocol" registry, as described in <xref
          target="Next_protocol"/>.</t>
        </list></t> target="Next_protocol" format="default"/>.</t>

      <t>Next protocol Protocol values 0x7E, 0x7F and 0x7F, 0xFE, and 0xFF are assigned for
      experimentation and testing testing, as per <xref target="RFC3692"/>.</t> target="RFC3692" format="default"/>.</t>
      <t>Next protocol Protocol values from Ox80 0x80 to 0xFD are assigned to protocols
      encoded as generic "shim" shim headers. All shim protocols MUST <bcp14>MUST</bcp14> use the
      header structure in <xref target="shim"/>, target="shim" format="default"/>, which includes a Next
      Protocol 'Next
      Protocol' field. When shim headers are used with other protocols
      identified by next protocol Next Protocol values from 0x00 to 0x7F, all the shim
      headers MUST <bcp14>MUST</bcp14> come first.</t>
      <t>Shim headers can be used to incrementally deploy new GPE features,
      keeping the processing of shim headers known to a given xTR Tunnel Router (xTR)
      implementation in the 'fast' path (typically an ASIC), Application-Specific Integrated
      Circuit (ASIC)) while punting the
      processing of the remaining new GPE features to the 'slow' path.</t>
      <t>Shim protocols MUST <bcp14>MUST</bcp14> have the first 32 bits defined as:</t>

      <t><figure anchor="shim" title="Shim Header">
          <preamble/>

          <artwork><![CDATA[
      <t keepWithNext="true"/>
      <figure anchor="shim">
        <name>Shim Header</name>
<artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |   Reserved    | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                    Protocol Specific                    Protocol-Specific Fields                   ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>

          <postamble/>
        </figure></t>

      <t>Where:</t>

      <t><list style="hanging">
      </figure>
      <t hangText="Type:">This keepWithPrevious="true"/>
      <t>Where:</t>
      <dl newline="false" spacing="normal">
        <dt>Type:</dt>
        <dd>This field identifies the different messages of
          this protocol.</t>

          <t hangText="Length:">The protocol.</dd>
        <dt>Length:</dt>
        <dd>This field indicates the length, in 4-octet units, of this protocol
          message
          message, not including the first 4 octets.</t>

          <t hangText="Reserved:">The octets.</dd>
        <dt>Reserved:</dt>
        <dd>The use of this field is reserved to the
          protocol defined in this message.</t>

          <t hangText="Next Protocol Field:">The next protocol message.</dd>
        <dt>Next Protocol:</dt>
        <dd>This field contains
          the protocol of the encapsulated payload. The values are tracked in
          the IANA LISP-GPE "LISP-GPE Next Protocol Registry Protocol" registry, as described in <xref
          target="Next_protocol"/>.</t>
        </list></t>
	  target="Next_protocol" format="default"/>.</dd>
      </dl>
    </section>
    <section anchor="Deployments"
             title="Implementation numbered="true" toc="default">
      <name>Implementation and Deployment Considerations"> Considerations</name>
      <section anchor="Applicability" title="Applicability Statement"> numbered="true" toc="default">
        <name>Applicability Statement</name>
        <t>LISP-GPE conforms, as an a UDP-based encapsulation protocol, to the
        UDP usage guidelines as specified in <xref target="RFC8085"/>. target="RFC8085" format="default"/>. The
        applicability of these guidelines are is dependent on the underlay IP
        network and the nature of the encapsulated payload.</t>
        <t><xref target="RFC8085"/> target="RFC8085" format="default"/> outlines two applicability scenarios for
        UDP applications, applications: 1) the general Internet and 2) a controlled environment.
        The
        A controlled environment means a single administrative domain or
        adjacent set of cooperating domains. A network in a controlled
        environment can be managed to operate under certain conditions whereas conditions, whereas,
        in the general Internet Internet, this cannot be done. Hence Hence, requirements for a
        tunnel protocol operating under a controlled environment can be less
        restrictive than the requirements of the general internet.</t>

        <t>LISP-GPE Internet.</t>
        <t>The LISP-GPE scope of applicability is the same set of use cases
        covered by<xref target="I-D.ietf-lisp-rfc6830bis"/> by <xref target="RFC9300" format="default"/> for the LISP
        dataplane
        data plane protocol. The common property of these use cases is a large
        set of cooperating entities seeking to communicate over the public
        Internet or other large underlay IP infrastructures, infrastructures while keeping the
        addressing and topology of the cooperating entities separate from the
        underlay and Internet topology, routing, and addressing.</t>
        <t>LISP-GPE is meant to be deployed in network environments operated
        by a single operator or adjacent set of cooperating network operators
        that fits fit with the definition of controlled environments in <xref
        target="RFC8085"/>.</t> target="RFC8085" format="default"/>.</t>
        <t>For the purpose of this document, a traffic-managed controlled
        environment Traffic-Managed Controlled
        Environment (TMCE), outlined in <xref target="RFC8086"/>, target="RFC8086" format="default"/>, is defined
        as an IP network that is traffic-engineered and/or otherwise managed
        (e.g., via the use of traffic rate limiters) to avoid congestion.
        Significant portions of the text in this Section section are based on <xref
        target="RFC8086"/>.</t> target="RFC8086" format="default"/>.</t>
        <t>It is the responsibility of the network operators to ensure that
        the guidelines/requirements in this section are followed as applicable
        to their LISP-GPE deployments</t> deployments.</t>
      </section>
      <section anchor="CongestionControl"
               title="Congestion Control Functionality"> numbered="true" toc="default">
        <name>Congestion-Control Functionality</name>
        <t>LISP-GPE does not natively provide congestion control congestion-control functionality
        and relies on the payload protocol traffic for congestion control. As
        such
        such, LISP-GPE MUST <bcp14>MUST</bcp14> be used with congestion controlled congestion-controlled traffic or
        within a network that is traffic managed to avoid congestion (TMCE).
        An operator of a traffic managed traffic-managed network (TMCE) may avoid congestion
        by careful provisioning of their networks, rate-limiting rate limiting of user data
        traffic
        traffic, and traffic engineering according to path capacity.</t>
        <t>Keeping in mind the reccomendation recommendation above, new encapsulated
        payloads, when registered with LISP-GPE, MUST <bcp14>MUST</bcp14> be accompained accompanied by a set
        of guidelines derived from <xref target="I-D.ietf-lisp-rfc6830bis"/>. target="RFC9300" format="default" sectionFormat="of" section="5"/>.
        Such new protocols should be designed for explicit congestion signals
        to propagate consistently from lower layer lower-layer protocols into IP. Then Then, the
        IP internetwork layer can act as a portability layer to carry
        congestion notification notifications from non-IP-aware congested nodes up to the
        transport layer (L4). By following the guidelines in <xref
        target="I-D.ietf-tsvwg-ecn-encap-guidelines"/>, target="I-D.ietf-tsvwg-ecn-encap-guidelines" format="default"/>, subnetwork designers
        can enable a layer-2 Layer 2 protocol to participate in congestion control
        without dropping packets packets, via propagation of explicit congestion
        notification (ECN Explicit Congestion
        Notification (ECN) data <xref target="RFC3168"/> ) target="RFC3168" format="default"/> to receivers.</t>
      </section>
      <section anchor="UDPChecksum" title="UDP Checksum"> numbered="true" toc="default">
        <name>UDP Checksum</name>
        <t>For IP payloads, section 5.3 of <xref
        target="I-D.ietf-lisp-rfc6830bis"/> target="RFC9300" section="5.3" sectionFormat="of"/>
	specifies how to handle UDP
        Checksums
        checksums, encouraging implementors to consider UDP checksum usage
        guidelines in section 3.4 of <xref target="RFC8085"/> target="RFC8085" section="3.4" sectionFormat="of"/> when it is
        desirable to protect UDP and LISP headers against corruption.</t>
        <t>In order to provide protect the integrity of LISP-GPE headers, options options, and
        payload, for example
        payloads (for example, to avoid mis-delivery misdelivery of payload payloads to different
        tenant systems in the case of data corruption, corruption), the outer UDP checksum SHOULD <bcp14>SHOULD</bcp14>
        be used with LISP-GPE when transported over IPv4. The UDP checksum
        provides a statistical guarantee that a payload was not corrupted in
        transit. These integrity checks are not strong from a coding or
        cryptographic perspective and are not designed to detect
        physical-layer errors or malicious modification modifications of the datagram (see
        Section 3.4 of
        <xref target="RFC8085"/>). target="RFC8085" section="3.4" sectionFormat="of"/>). In deployments where such a
        risk exists, an operator SHOULD <bcp14>SHOULD</bcp14> use additional data integrity
        mechanisms
        mechanisms, such as those offered by IPSec.</t> IPsec.</t>
        <t>An operator MAY <bcp14>MAY</bcp14> choose to disable a UDP checksum and use a zero
        checksum if LISP-GPE packet integrity is provided by other data
        integrity mechanisms mechanisms, such as IPsec or additional checksums checksums, or if one
        of the conditions in <xref target="IPv6Checksum"/> a, target="IPv6Checksum" format="default"/> (a, b, c are or c) is
        met.</t>
        <section anchor="IPv6Checksum"
                 title="UDP numbered="true" toc="default">
          <name>UDP Zero Checksum Handling with IPv6"> IPv6</name>
          <t>By default, a UDP checksum MUST <bcp14>MUST</bcp14> be used when LISP-GPE is
          transported over IPv6. A tunnel endpoint MAY <bcp14>MAY</bcp14> be configured for use
          with a zero UDP checksum if additional requirements described in this
          section are met.</t>
          <t>When LISP-GPE is used over IPv6, a UDP checksum is used to protect
          IPv6 headers, UDP headers headers, and LISP-GPE headers and payload payloads from
          potential data corruption. As such such, by default default, LISP-GPE MUST <bcp14>MUST</bcp14> use a UDP
          checksum when transported over IPv6. An operator MAY <bcp14>MAY</bcp14> choose to
          configure to operate with a zero UDP checksum if operating in a
          traffic managed
          traffic-managed controlled environment environment, as stated in <xref
          target="Applicability"/> target="Applicability"
	  format="default"/>, if one of the following conditions are is met:</t>

          <t><list style="letters">
              <t>It
          <ol spacing="normal" type="a">
	    <li>It is known that the packet corruption is exceptionally
              unlikely (perhaps based on an operator's knowledge of equipment types in their
              underlay network) network), and the operator is willing to take a the risk of
              undetected packet corruption</t>

              <t>It corruption.</li>
              <li>It is judged determined through observational measurements
	      (perhaps
     through historic or current traffic flows that use non zero a non-zero
     checksum) that the level of packet corruption is tolerably low low,
     and where the operator is willing to take the risk of undetected
              corruption</t>

              <t>LISP-GPE payload is
     corruption.</li>
            <li>LISP-GPE payloads are carrying applications that are tolerant
              of misdelivered or corrupted packets (perhaps through higher
              layer higher-layer
	      checksum validation and/or reliability through
              retransmission)</t>
            </list>In addition retransmission).</li>
          </ol>
          <t>In addition, LISP-GPE tunnel implementations using Zero a zero UDP
          checksum MUST <bcp14>MUST</bcp14> meet the following requirements:</t>

          <t><list style="numbers">
              <t>Use
          <ol spacing="normal" type="1">
	    <li>Use of a UDP checksum over IPv6 MUST <bcp14>MUST</bcp14> be the default
              configuration for all LISP-GPE tunnels</t>

              <t>If tunnels.</li>
            <li>If LISP-GPE is used with a zero UDP checksum over IPv6 IPv6, then
              such xTR implementation MUST implementations <bcp14>MUST</bcp14> meet all the requirements specified
              in section 4 of <xref target="RFC6936"/> target="RFC6936" section="4" sectionFormat="of"/> and requirements requirement 1 as
              specified in section 5 of <xref target="RFC6936"/></t>

              <t>The ETR target="RFC6936" section="5" sectionFormat="of"/>.</li>
            <li>The Egress Tunnel Router (ETR) that decapsulates the packet SHOULD <bcp14>SHOULD</bcp14>
	    check that the source
              and destination IPv6 addresses are valid for the LISP-GPE tunnel
              that is configured to receive Zero a zero UDP checksum and discard
              other packets for which that fail such check fails</t>

              <t>The ITR checks.</li>
            <li>The Ingress Tunnel Router (ITR) that encapsulates the packet MAY <bcp14>MAY</bcp14>
	    use different IPv6
              source addresses for each LISP-GPE tunnel that uses Zero zero UDP
              checksum mode in order to strengthen the decapsulator's check of
              the IPv6 source address (i.e (i.e., the same IPv6 source address is not
              to be used with more than one IPv6 destination address,
              irrespective of whether that destination address is a unicast or
              multicast address). When this is not possible, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14>
              to use each source address for as few LISP-GPE tunnels that use a
            zero UDP checksum as is feasible</t>

              <t>Measures SHOULD feasible.</li>
            <li>Measures <bcp14>SHOULD</bcp14> be taken to prevent LISP-GPE traffic over
              IPv6 with a zero UDP checksum from escaping into the general
              Internet. Examples of such measures include employing packet
              filters at the PETR Proxy Egress Tunnel Router (PETR) and/or keeping logical or physical
              separation of the LISP network from networks carrying General
              Internet</t>
            </list>The in the general
              Internet.</li>
          </ol>
          <t>The above requirements do not change either the
          requirements specified in <xref target="RFC2460"/> as modified by target="RFC6935"/>,
	  <xref target="RFC6935"/> target="RFC6936" format="default"/>, or the requirements specified in <xref
          target="RFC6936"/>.</t> target="RFC8200" format="default"/>.</t>
          <t>The requirement to check the source IPv6 address in addition to
          the destination IPv6 address, plus the recommendation against the reuse
          of source IPv6 addresses among LISP-GPE tunnels tunnels, collectively provide
          some mitigation for the absence of UDP checksum coverage of the IPv6
          header. A traffic-managed controlled environment that satisfies at
          least one of the three conditions listed at the beginning of this
          section provides additional assurance.</t>
        </section>
      </section>
      <section anchor="DSCP" title="DSCP, numbered="true" toc="default">
        <name>DSCP, ECN, TTL, and 802.1Q"> 802.1Q</name>
        <t>When encapsulating IP (including over Ethernet) packets packets, <xref
        target="RFC2983"/> target="RFC2983"
	format="default"/> provides guidance for mapping DSCP packets that contain Differentiated Services Code Point
	(DSCP) information between inner
        and outer IP headers. The Pipe model typically fits better Network with network
        virtualization. The DSCP value on the tunnel header is set based on a
        policy (which may be a fixed value, one based on the inner traffic
        class, or some other mechanism for grouping traffic). Some aspects of
        the Uniform model (which treats the inner and outer DSCP value as a
        single field by copying on ingress and egress) may also apply, such as
        the ability to remark the inner header on tunnel egress based on
        transit marking. However, the Uniform model is not conceptually
        consistent with network virtualization, which seeks to provide strong
        isolation between encapsulated traffic and the physical network.</t>
        <t><xref target="RFC6040"/> target="RFC6040" format="default"/> describes the mechanism for exposing ECN
        capabilities on IP tunnels and propagating congestion markers to the
        inner packets. This behavior MUST <bcp14>MUST</bcp14> be followed for IP packets
        encapsulated in LISP-GPE.</t>
        <t>Though the Uniform model or the Pipe models model could be used for TTL (or Hop Limit
        in the case of IPv6) handling when tunneling IP packets, the Pipe model is
        more aligned with network virtualization. <xref target="RFC2003"/> target="RFC2003" format="default"/>
        provides guidance on handling TTL between inner IP header headers and outer IP
        tunnels; this model is more aligned with the Pipe model and is
        recommended for use with LISP-GPE for network virtualization network-virtualization
        applications.</t>
        <t>When a LISP-GPE router performs Ethernet encapsulation, the inner
        802.1Q <xref target="IEEE.802.1Q_2014"/> 3-bit priority code point
        (PCP) Priority Code Point
        ('PCP') field MAY <xref target="IEEE.802.1Q_2014" format="default"/> <bcp14>MAY</bcp14> be mapped from the encapsulated frame to the DSCP
        codepoint of the DS Differentiated Services ('DS') field defined in <xref target="RFC2474"/>.</t>
	target="RFC2474" format="default"/>.</t>
        <t>When a LISP-GPE router performs Ethernet encapsulation, the inner
        header
        inner-header 802.1Q <xref target="IEEE.802.1Q_2014"/> VLAN Identifier (VID)
        MAY <xref target="IEEE.802.1Q_2014" format="default"/>
        <bcp14>MAY</bcp14> be mapped to, or used to determine determine, the LISP Instance IDentifier 'Instance ID'
        (IID) field.</t>
        <t>Refer to <xref target="Security"/> target="Security" format="default"/> for consideration considerations about the use
        of integrity protection for deployments, such as the public Internet,
        concerned with on-path attackers.</t>
      </section>
    </section>
    <section anchor="Compatibility" title="Backward Compatibility"> numbered="true" toc="default">
      <name>Backward Compatibility</name>
      <t>LISP-GPE uses the same UDP destination port (4341) allocated to
      LISP.</t>
      <t>When encapsulating IP packets to a non LISP-GPE capable router non-LISP-GPE-capable router, the
      P-bit MUST <bcp14>MUST</bcp14> be set to 0. That is, the encapsulation format defined in
      this document MUST NOT <bcp14>MUST NOT</bcp14> be sent to a router that has not indicated that
      it supports this specification specification, because such a router would ignore the
      P-bit (as described in <xref target="I-D.ietf-lisp-rfc6830bis"/>) target="RFC9300" format="default"/>) and so
      would misinterpret the other LISP header fields fields, possibly causing
      significant errors.</t>
      <section anchor="ETR_CAPABILITIES" title="Detection numbered="true" toc="default">
        <name>Detection of ETR Capabilities"> Capabilities</name>
        <t>The discovery of xTR capabilities to support LISP-GPE is out of the
        scope of this document. Given that the applicability domain of
        LISP-GPE is a traffic-managed controlled environment, ITR/ETR (xTR)
        configuration mechanisms may be used for this purpose.</t>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t/>
      <section anchor="Next_protocol" title="LISP-GPE numbered="true" toc="default">
        <name>LISP-GPE Next Protocol Registry"> Registry</name>
        <t>IANA is requested to set up has created a registry of LISP-GPE "Next called "LISP-GPE Next Protocol".
        These are 8-bit values. Next Protocol values in the table below are
        defined in this document. New values are assigned under the
        Specification Required policy <xref target="RFC8126"/>. target="RFC8126" format="default"/>. The protocols
        that are being assigned values do not themselves need to be IETF
        standards track
        Standards Track protocols.</t>

        <texttable>
          <ttcol>Next Protocol</ttcol>

          <ttcol>Description</ttcol>

          <ttcol>Reference</ttcol>

          <c>0x0</c>

          <c>Reserved</c>

          <c>This Document</c>

          <c>0x1</c>

          <c>IPv4</c>

          <c>This Document</c>

          <c>0x2</c>

          <c>IPv6</c>

          <c>This Document</c>

          <c>0x3</c>

          <c>Ethernet</c>

          <c>This Document</c>

          <c>0x4</c>

          <c>NSH</c>

          <c>This Document</c>

          <c>0x05..0x7D</c>

          <c>Unassigned</c>

          <c/>

          <c>0x7E..0x7F</c>

          <c>Experimentation and testing</c>

          <c>This Document</c>

          <c>0x80..0xFD</c>

          <c>Unassigned
        <table align="center">
          <thead>
            <tr>
              <th align="left">Next Protocol</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0x00</td> <!-- 0 -->
              <td align="left">Reserved</td>
              <td align="left">RFC 9305</td>
            </tr>
            <tr>
              <td align="left">0x01</td> <!-- 1 -->
              <td align="left">IPv4</td>
              <td align="left">RFC 9305</td>
            </tr>
            <tr>
              <td align="left">0x02</td><!-- 2 -->
              <td align="left">IPv6</td>
              <td align="left">RFC 9305</td>
            </tr>
            <tr>
              <td align="left">0x03</td><!-- 3 -->
              <td align="left">Ethernet</td>
              <td align="left">RFC 9305</td>
            </tr>
            <tr>
              <td align="left">0x04</td> <!-- 4 -->
              <td align="left">NSH</td>
              <td align="left">RFC 9305</td>
            </tr>
            <tr>
              <td align="left">0x05-0x7D</td><!-- 5-125 -->
              <td align="left">Unassigned</td>
              <td align="left"/>
            </tr>
            <tr>
              <td align="left">0x7E-0x7F</td><!-- 126-127 -->
              <td align="left">Experimentation and testing</td>
              <td align="left">RFC 9305</td>
            </tr>
            <tr>
              <td align="left">0x80-0xFD</td><!-- 128-253 -->
              <td align="left">Unassigned (shim headers)</c>

          <c/>

          <c>0x8E..0x8F</c>

          <c>Experimentation headers)</td>
              <td align="left"/>
            </tr>
            <tr>
              <td align="left">0xFE-0xFF</td><!-- 254-255 -->
              <td align="left">Experimentation and testing (shim headers)</c>

          <c>This Document</c>
        </texttable> headers)</td>
              <td align="left">RFC 9305</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>LISP-GPE security considerations are similar to the LISP security
      considerations and mitigation techniques documented in <xref
      target="RFC7835"/>.</t>

      <t>LISP-GPE, as target="RFC7835" format="default"/>.</t>
      <t>As is the case for many encapsulations that use optional extensions, LISP-GPE is
      subject to on-path adversaries that can make arbitrary modifications to
      the packet (including the P-Bit) P-bit) to change or remove any part of the
      payload, or claim to encapsulate any protocol payload type. Typical
      integrity protection mechanisms (such as IPsec) SHOULD <bcp14>SHOULD</bcp14> be used in
      combination with LISP-GPE by those protocol extensions that want to
      protect from against on-path attackers.</t>
      <t>With LISP-GPE, issues such as data-plane data plane spoofing, flooding, and
      traffic redirection may depend on the particular protocol payload
      encapsulated.</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

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

<displayreference target="I-D.ietf-tsvwg-ecn-encap-guidelines" to="ENCAP-GUIDE"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml"/>

        <reference anchor="IEEE.802.1Q_2014" target="http://ieeexplore.ieee.org/servlet/opac?punumber=6991460">
          <front>
            <title>IEEE Standard for Local and Contributors"> metropolitan area networks--Bridges and Bridged Networks</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date month="December" year="2014"/>
          </front>
          <refcontent>IEEE Std 802.1Q-2014</refcontent>
        </reference>

<reference anchor='RFC9300' target="https://www.rfc-editor.org/info/rfc9300">
<front>
<title>The Locator/ID Separation Protocol (LISP)</title>
<author initials='D' surname='Farinacci' fullname='Dino Farinacci'>
    <organization />
</author>
<author initials='V' surname='Fuller' fullname='Vince Fuller'>
    <organization />
</author>
<author initials='D' surname='Meyer' fullname='David Meyer'>
    <organization />
</author>
<author initials='D' surname='Lewis' fullname='Darrel Lewis'>
    <organization />
</author>
<author initials='A' surname='Cabellos' fullname='Albert Cabellos' role='editor'>
    <organization />
</author>
<date month='October' year='2022' />
</front>
<seriesInfo name="RFC" value="9300"/>
<seriesInfo name="DOI" value="10.17487/RFC9300"/>
</reference>
      </references>
      <references>
        <name>Informative References</name>

      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tsvwg-ecn-encap-guidelines.xml"/>

<reference anchor='VXLAN-LISP'>
<front>
<title>Group Policy Encoding with VXLAN-GPE and LISP-GPE</title>
<author initials='J' surname='Lemon' fullname='John Lemon' role='editor'>
    <organization />
</author>
<author initials='F' surname='Maino' fullname='Fabio Maino'>
    <organization />
</author>
<author initials='M' surname='Smith' fullname='Michael Smith'>
    <organization />
</author>
<author initials='A' surname='Isaac' fullname='Aldrin Isaac'>
    <organization />
</author>
<date month='April' day='30' year='2019' />
</front>
<seriesInfo name='Internet-Draft' value='draft-lemon-vxlan-lisp-gpe-gbp-02' />
</reference>

<reference anchor="VXLAN-GPE">
   <front>
      <title>VXLAN-GPE Encapsulation for In-situ OAM Data</title>
      <author initials="F." surname="Brockners" fullname="Frank Brockners">
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <author initials="S." surname="Bhandari" fullname="Shwetha Bhandari">
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <author initials="V." surname="Govindan" fullname="Vengada Prasad Govindan">
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <author initials="H." surname="Gredler" fullname="Hannes Gredler">
         <organization>RtBrick Inc.</organization>
      </author>
      <author initials="J." surname="Leddy" fullname="John Leddy">
         </author>
      <author initials="S." surname="Youell" fullname="Stephen Youell">
         <organization>JP Morgan Chase</organization>
      </author>
      <author initials="T." surname="Mizrahi" fullname="Tal Mizrahi">
         <organization>Huawei Network.IO Innovation Lab</organization>
      </author>
      <author initials="A." surname="Kfir" fullname="Aviv Kfir">
         <organization>Mellanox Technologies, Inc.</organization>
      </author>
      <author initials="B." surname="Gafni" fullname="Barak Gafni">
         <organization>Mellanox Technologies, Inc.</organization>
      </author>
      <author initials="P." surname="Lapukhov" fullname="Petr Lapukhov">
         <organization>Facebook</organization>
      </author>
      <author initials="M." surname="Spiegel" fullname="Mickey Spiegel">
         <organization>Barefoot Networks</organization>
      </author>
      <date month="November" day="4" year="2019" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-brockners-ippm-ioam-vxlan-gpe-03" />
</reference>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2003.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2983.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3692.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6935.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6936.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7835.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8086.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/>
      </references>
    </references>
    <section anchor="Acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>A special thank you goes to Dino Farinacci <contact fullname="Dino Farinacci"/> for his guidance and
      detailed review. Thanks to Tom Herbert <contact fullname="Tom Herbert"/> for the suggestion to assign
      codepoints for experimentations and testing.</t>

      <t>This Working Group (WG) document originated as draft-lewis-lisp-gpe;
      the following are its coauthors and contributors along with their
      respective affiliations at the time of WG adoption. The
    </section>
    <section anchor="Contributors" numbered="false" toc="default">
      <name>Contributors</name>
      <t>The editor of this document would like to thank and recognize them the
   following coauthors and contributors for their contributions.  These
   coauthors and contributors provided invaluable concepts and content
   for this document's creation.</t>

      <t><list style="symbols">
          <t>Darrel Lewis, Cisco

      <contact fullname="Darrel Lewis">
        <organization>Cisco Systems, Inc.</t>

          <t>Fabio Maino, Cisco Inc.</organization>
        <address/>
    </contact>
    <contact fullname="Fabio Maino">
        <organization>Cisco Systems, Inc.</t>

          <t>Paul Quinn, Cisco Inc.</organization>
	<address/>
      </contact>
      <contact fullname="Paul Quinn">
	<organization>Cisco Systems, Inc.</t>

          <t>Michael Smith, Cisco Inc.</organization>
	<address/>
      </contact>
      <contact fullname="Michael Smith">
        <organization>Cisco Systems, Inc.</t>

          <t>Navindra Yadav, Cisco Inc.</organization>
	<address/>
      </contact>
      <contact fullname="Navindra Yadav">
        <organization>Cisco Systems, Inc.</t>

          <t>Larry Kreeger</t>

          <t>Jennifer Lemon, Broadcom</t>

          <t>Puneet Agarwal, Innovium</t>
        </list></t> Inc.</organization>
	<address/>
      </contact>
      <contact fullname="Larry Kreeger">
        <organization/>
	<address/>
      </contact>
      <contact fullname="Jennifer Lemon">
	<organization>Broadcom</organization>
	<address/>
      </contact>
      <contact fullname="Puneet Agarwal">
	<organization>Innovium</organization>
	<address/>
      </contact>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** v-->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
    2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use the PI option, xml2rfc will, by default, try to find included files in the same
    directory as the including file. You can also define the XML_LIBRARY environment variable
    with a value containing a set of directories to search.  These can be either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

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

      &ieee_802_1Q;

      <?rfc include="reference.I-D.ietf-lisp-rfc6830bis"
?>

      <?rfc include="reference.RFC.6040"?>
    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      <?rfc include="reference.I-D.ietf-tsvwg-ecn-encap-guidelines"
?>

      <?rfc include="reference.I-D.lemon-vxlan-lisp-gpe-gbp"?>

      <?rfc include="reference.I-D.brockners-ippm-ioam-vxlan-gpe"?>

      <?rfc include="reference.RFC.2460"?>

      <?rfc include="reference.RFC.2003"?>

      <?rfc include="reference.RFC.2474"?>

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

      <?rfc include="reference.RFC.3168"?>

      <?rfc include="reference.RFC.3692"?>

      <?rfc include="reference.RFC.6935"?>

      <?rfc include="reference.RFC.6936"?>

      <?rfc include="reference.RFC.7348"?>

      <?rfc include="reference.RFC.7835"
?>

      <?rfc include="reference.RFC.8085"?>

      <?rfc include="reference.RFC.8086"?>

      <?rfc include="reference.RFC.8126"?>

      <?rfc include="reference.RFC.8174"?>

      <?rfc include="reference.RFC.8300"?>
    </references>

    <!-- Change Log

v00.01 2017-01-24  FM    Renamed as draft-ietf-lisp-gpe to reflect WG adoption
v00.02 2017-12-12  FM    Changed to reflect RFC6830bis header format
-->

    <!--v00.03 2017-12-14  FM    Changed Intended Status to Standard Track
v01.00 2018-03-05  FM    Removed reference to GBP draft (informational) and fixed paulq email address-->

    <!--v02.00 2018-03-22  FM    Updated Section 4. Backward Compatibilty to be consistent with RFC8061 and addressed WG chair comments-->

    <!--v04.00 2018-07-19  FM    Addressed WG chair editorial comments-->

    <!--v05.00 2018-08-15  FM    Addressed rtgdir comments -->

    <!--v06.00 2018-09-20  FM    Addressed secdir, tsvart + Mirja comments. Some tsvart comments are still to be resolved
v07.00 2018-10-    FM    Fixed a few nits, added support for shim protoocls GBP and iOAM.
                         Introduced concept of LISP-GPE shim headers, new section 4 dealing with deployment considerations:
                         Applicability, Congestion Control, UDP checksum, Ethernet Payoads
-->
  </back>
  </rfc>