<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-lisp-pubsub-15" number="9437" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" prepTime="2023-08-04T15:00:30" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-lisp-pubsub-15" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9437" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="PubSub Functionality for LISP">Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP)</title>
    <seriesInfo name="RFC" value="9437" stream="IETF"/>
    <author fullname="Alberto Rodriguez-Natal" initials="A." surname="Rodriguez-Natal">
      <organization showOnFrontPage="true">Cisco</organization>
      <address>
        <postal>
          <street/>
          <city>Barcelona</city>
          <region/>
          <code/>
          <country>Spain</country>
        </postal>
        <phone/>
        <email>natal@cisco.com</email>
      </address>
    </author>
    <author fullname="Vina Ermagan" initials="V." surname="Ermagan">
      <organization showOnFrontPage="true">Google</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>United States of America</country>
        </postal>
        <phone/>
        <email>ermagan@gmail.com</email>
      </address>
    </author>
    <author fullname="Albert Cabellos" initials="A." surname="Cabellos">
      <organization showOnFrontPage="true">UPC/BarcelonaTech</organization>
      <address>
        <postal>
          <street/>
          <city>Barcelona</city>
          <region/>
          <code/>
          <country>Spain</country>
        </postal>
        <phone/>
        <email>acabello@ac.upc.edu</email>
      </address>
    </author>
    <author fullname="Sharon Barkai" initials="S." surname="Barkai">
      <organization showOnFrontPage="true">Nexar</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <phone/>
        <email>sharon.barkai@getnexar.com</email>
      </address>
    </author>
    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization showOnFrontPage="true">Orange</organization>
      <address>
        <postal>
          <street/>
          <city>Rennes</city>
          <region/>
          <code/>
          <country>France</country>
        </postal>
        <phone/>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>
    <date month="08" year="2023"/>
    <area>rtg</area>
    <workgroup>lisp</workgroup>
    <keyword>lisp</keyword>
    <keyword>publish</keyword>
    <keyword>subscribe</keyword>
    <keyword>subscription</keyword>
    <keyword>sdn</keyword>
    <keyword>nfv</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document specifies an extension to the Locator/ID Separation
      Protocol (LISP) control plane to enable
      Publish/Subscribe (PubSub) operation.
</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9437" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scope-of-applicability">Scope of Applicability</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology-and-requirement">Terminology and Requirements Notation</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deployment-requirements">Deployment Requirements</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-map-request-pubsub-addition">Map-Request PubSub Additions</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mapping-request-subscribe-p">Mapping Request Subscribe Procedures</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mapping-notification-publis">Mapping Notification Publish Procedures</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-association-betwee">Security Association between ITR and Map-Server</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ddos-attack-mitigation">DDoS Attack Mitigation</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sample-pubsub-deployment-ex">Sample PubSub Deployment Experiences</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pubsub-as-a-monitoring-tool">PubSub as a Monitoring Tool</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mitigating-negative-map-cac">Mitigating Negative Map-Cache Entries</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.3">
                <t indent="0" pn="section-toc.1-1.10.2.3.1"><xref derivedContent="A.3" format="counter" sectionFormat="of" target="section-appendix.a.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-improved-mobility-latency">Improved Mobility Latency</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.4">
                <t indent="0" pn="section-toc.1-1.10.2.4.1"><xref derivedContent="A.4" format="counter" sectionFormat="of" target="section-appendix.a.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-enhanced-reachability-with-">Enhanced Reachability with Dynamic Redistribution of
        Prefixes</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.5">
                <t indent="0" pn="section-toc.1-1.10.2.5.1"><xref derivedContent="A.5" format="counter" sectionFormat="of" target="section-appendix.a.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-better-serviceability">Better Serviceability</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The Locator/ID Separation Protocol (LISP) <xref target="RFC9300" format="default" sectionFormat="of" derivedContent="RFC9300"/> <xref target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/> splits IP
      addresses into two different namespaces: Endpoint Identifiers (EIDs) and
      Routing Locators (RLOCs). LISP uses a map and encapsulate (a.k.a.,
      map-and-encap) approach that relies on (1) a Mapping System (basically a
      distributed database) that stores and disseminates EID-RLOC mappings and
      on (2) LISP Tunnel Routers (xTRs) that encapsulate and decapsulate data
      packets based on the content of those mappings.</t>
      <t indent="0" pn="section-1-2">Ingress Tunnel Routers (ITRs), Re-encapsulating Tunnel Routers
      (RTRs), and Proxy Ingress Tunnel Routers (PITRs) pull EID-to-RLOC mapping
      information from the Mapping System by means of an explicit request
      message. <xref target="RFC9301" sectionFormat="of" section="6.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-6.1" derivedContent="RFC9301"/>
      indicates how Egress Tunnel Routers (ETRs) can tell ITRs/RTRs/PITRs
      about mapping changes. This document presents a Publish/Subscribe
      (PubSub) extension in which the Mapping System can notify
      ITRs/RTRs/PITRs about mapping changes. When this mechanism is used,
      mapping changes can be notified faster and can be managed in the Mapping
      System versus the LISP sites.</t>
      <t indent="0" pn="section-1-3">In general, when an ITR/RTR/PITR wants to be notified for mapping
      changes for a given EID-Prefix, the following main steps occur:</t>
      <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-1-4">
	<li pn="section-1-4.1" derivedCounter="1.">The ITR/RTR/PITR builds a Map-Request for that EID-Prefix with the
	Notification-Requested bit (N-bit) set and that also includes its
	xTR-ID and Site-ID.</li>
        <li pn="section-1-4.2" derivedCounter="2.">The Map-Request is forwarded to one of the Map-Servers that the
        EID-Prefix is registered to.</li>
        <li pn="section-1-4.3" derivedCounter="3.">The Map-Server creates subscription state for the ITR/RTR/PITR on
        the EID-Prefix.</li>
        <li pn="section-1-4.4" derivedCounter="4.">The Map-Server sends a Map-Notify to the ITR/RTR/PITR to confirm
        that the subscription has been created and then waits for an
        acknowledgement of the notification.</li>
        <li pn="section-1-4.5" derivedCounter="5.">The ITR/RTR/PITR sends back a Map-Notify-Ack to acknowledge the
        successful receipt of the Map-Notify.</li>
        <li pn="section-1-4.6" derivedCounter="6.">When there is a change in the mapping of the EID-Prefix, the
        Map-Server sends a Map-Notify message to each ITR/RTR/PITR in the
        subscription list.</li>
        <li pn="section-1-4.7" derivedCounter="7.">Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the
        received Map-Notify.</li>
      </ol>
      <t indent="0" pn="section-1-5">This operation is repeated for all EID-Prefixes for which ITRs/RTRs/PITRs want to be notified. An ITR/RTR/PITR can set the N-bit for several EID-Prefixes within a single Map-Request. Please note that the steps above illustrate only the simplest scenario and that details for this and other scenarios are described later in the document.</t>
      <t indent="0" pn="section-1-6">The reader may refer to <xref target="I-D.boucadair-lisp-pubsub-flow-examples" format="default" sectionFormat="of" derivedContent="FLOW-EXAMPLES"/> for sample flows to illustrate the use of the PubSub specification.</t>
      <section anchor="app-scope" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-scope-of-applicability">Scope of Applicability</name>
        <t indent="0" pn="section-1.1-1">The PubSub procedure specified in this document is intended for use in contexts with controlled access to the Map-Server. How a deployment controls access to a Map-Server is deployment specific and therefore out of the scope of this document. However, the Map-Resolvers and Map-Servers need to be configured with the required information to ensure at least the following:</t>
        <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-1.1-2">
	  <li pn="section-1.1-2.1" derivedCounter="1.">Map-Resolvers <bcp14>MUST</bcp14> verify that an xTR is allowed
	  to (1) set the N-bit to 1 and (2) use the xTR-ID, Site-ID, and
	  ITR-RLOCs included in a Map-Request.</li>
          <li pn="section-1.1-2.2" derivedCounter="2.">Map-Servers <bcp14>MUST</bcp14> only accept subscription
          requests from Map-Resolvers that verify Map-Requests as previously
          described.</li>
        </ol>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology-and-requirement">Terminology and Requirements Notation</name>
      <t indent="0" pn="section-2-1">
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
      <t indent="0" pn="section-2-2">The document uses the terms defined in <xref target="RFC9300" sectionFormat="of" section="3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9300#section-3" derivedContent="RFC9300"/>. </t>
    </section>
    <section anchor="assumptions" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-deployment-requirements">Deployment Requirements</name>
      <t indent="0" pn="section-3-1">In addition to the general assumptions and expectations that <xref target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/> makes for LISP deployments, this document imposes the following deployment requirements: </t>
      <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-3-2">
	<li pn="section-3-2.1" derivedCounter="1.">A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is
	assigned to each xTR.</li>
        <li pn="section-3-2.2" derivedCounter="2.">Map-Servers are configured to proxy Map-Replying (i.e., they are
        solicited to generate and send Map-Reply messages) for the mappings
        they are serving.</li>
        <li pn="section-3-2.3" derivedCounter="3.">A security association (e.g., a PubSubKey) is required between the
        ITRs and the Map-Servers (see <xref target="association" format="default" sectionFormat="of" derivedContent="Section 7.1"/>).</li>
      </ol>
      <t indent="0" pn="section-3-3">If a requirement is not met, a subscription cannot be established, and the network will continue operating without this enhancement. The configuration of xTR-IDs and Site-IDs is out of the scope of this document. The reader may refer to <xref target="I-D.ietf-lisp-yang" format="default" sectionFormat="of" derivedContent="LISP-YANG"/> for an example of how these identifiers can be provisioned to LISP nodes.</t>
    </section>
    <section anchor="map-request" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-map-request-pubsub-addition">Map-Request PubSub Additions</name>
      <t indent="0" pn="section-4-1"><xref target="mrq-fig" format="default" sectionFormat="of" derivedContent="Figure 1"/> shows the format of the updated Map-Request to support the PubSub functionality. In particular, this document associates a meaning with one of the reserved bits (see <xref target="IANA" format="default" sectionFormat="of" derivedContent="Section 8"/>). </t>
      <figure anchor="mrq-fig" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-map-request-with-i-bit-n-bi">Map-Request with I-bit, N-bit, xTR-ID, and Site-ID</name>
        <artwork align="center" name="" type="" alt="" pn="section-4-2.1">
     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=1 |A|M|P|S|p|s|R|I|  Rsvd   |L|D|   IRC   | Record Count  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Nonce . . .                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         . . . Nonce                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Source-EID-AFI        |   Source EID Address  ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         ITR-RLOC-AFI 1        |    ITR-RLOC Address 1  ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              ...                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         ITR-RLOC-AFI n        |    ITR-RLOC Address n  ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  / |N|   Reserved  | EID mask-len  |        EID-Prefix-AFI         |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  \ |                       EID-Prefix  ...                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Map-Reply Record  ...                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                            xTR-ID                             +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                           Site-ID                             +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
      </figure>
      <t indent="0" pn="section-4-3">The following is added to the Map-Request message defined in <xref target="RFC9301" sectionFormat="of" section="5.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.2" derivedContent="RFC9301"/>:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-4-4">
        <dt pn="section-4-4.1">xTR-ID bit (I-bit):</dt>
        <dd pn="section-4-4.2">This bit is set to 1 to indicate that 128-bit xTR-ID and 64-bit
	Site-ID fields are present in the Map-Request message. For PubSub
	operation, an xTR <bcp14>MUST</bcp14> be configured with an xTR-ID and
	Site-ID, and it <bcp14>MUST</bcp14> set the I-bit to 1 and include its
	xTR-ID and Site-ID in the Map-Request messages it generates. If the
	I-bit is set but the Site-ID and/or xTR-ID are not included, a
	receiver can detect the error because, after processing that last
	EID-Record, there are no bytes left from processing the message. In
	this case, the receiver <bcp14>SHOULD</bcp14> log a malformed
	Map-Request and <bcp14>MUST</bcp14> drop the message.</dd>
        <dt pn="section-4-4.3">Notification-Requested bit (N-bit):</dt>
        <dd pn="section-4-4.4">The N-bit of an EID-Record is set to 1 to specify that the xTR
	wants to be notified of updates for that EID-Prefix.</dd>
        <dt pn="section-4-4.5">xTR-ID field:</dt>
        <dd pn="section-4-4.6">If the I-bit is set, this field is added to the Map-Request
	message as shown in <xref target="mrq-fig" format="default" sectionFormat="of" derivedContent="Figure 1"/>,
	starting right after the final Record in the message (or the Map-Reply
	Record, if present). The xTR-ID is specified in <xref target="RFC9301" sectionFormat="of" section="5.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.6" derivedContent="RFC9301"/>.</dd>
        <dt pn="section-4-4.7">Site-ID field:</dt>
        <dd pn="section-4-4.8">If the I-bit is set, this field is added to the Map-Request
	message as shown in <xref target="mrq-fig" format="default" sectionFormat="of" derivedContent="Figure 1"/>,
	following the xTR-ID field.  The Site-ID is defined in <xref target="RFC9301" sectionFormat="of" section="5.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.6" derivedContent="RFC9301"/>.</dd>
      </dl>
    </section>
    <section anchor="sub" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-mapping-request-subscribe-p">Mapping Request Subscribe Procedures</name>
      <t indent="0" pn="section-5-1"> The xTR subscribes for changes to a given EID-Prefix by sending a
      Map-Request to the Mapping System with the N-bit set on the
      EID-Record. The xTR builds a Map-Request according to <xref target="RFC9301" sectionFormat="of" section="5.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.3" derivedContent="RFC9301"/> and also does the
      following: </t>
      <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-5-2">
	<li pn="section-5-2.1" derivedCounter="1.">The xTR <bcp14>MUST</bcp14> set the I-bit to 1 and append its
	xTR-ID and Site-ID to the Map-Request.</li>
        <li pn="section-5-2.2" derivedCounter="2.">The xTR <bcp14>MUST</bcp14> set the N-bit to 1 for the EID-Record
        to which the xTR wants to subscribe.</li>
        <li pn="section-5-2.3" derivedCounter="3.">If the xTR has a nonce associated with the EID-Prefix, it
        <bcp14>MUST</bcp14> use this nonce increased by one in the
        Map-Request. Otherwise, it generates a nonce as described in <xref target="RFC9301" sectionFormat="of" section="5.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.2" derivedContent="RFC9301"/>. It is
        <bcp14>RECOMMENDED</bcp14> that the xTR use persistent storage to
        keep nonce state. If the xTR does not have persistent storage and does
        not have a nonce associated with the EID-Prefix, it
        <bcp14>MUST</bcp14> reset the nonce by using the procedure described
        in <xref target="association" format="default" sectionFormat="of" derivedContent="Section 7.1"/> to successfully
        create a new security association with the Map-Server.</li>
      </ol>
      <t indent="0" pn="section-5-3">The Map-Request is forwarded to the appropriate Map-Server through the Mapping System. This document does not assume that a Map-Server is pre-assigned to handle the subscription state for a given xTR. The Map-Server that receives the Map-Request will be the Map-Server responsible for notifying that specific xTR about future mapping changes for the subscribed mapping records.</t>
      <t indent="0" pn="section-5-4">Upon receipt of the Map-Request, the Map-Server processes it as
      described in <xref target="RFC9301" sectionFormat="of" section="8.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-8.3" derivedContent="RFC9301"/>. In addition, unless the xTR is using the procedure
      described in <xref target="association" format="default" sectionFormat="of" derivedContent="Section 7.1"/> to create a
      new security association, the Map-Server <bcp14>MUST</bcp14> verify that
      the nonce in the Map-Request is greater than the stored nonce (if any)
      associated with the xTR-ID (and EID-Prefix, when applicable). Otherwise,
      the Map-Server <bcp14>MUST</bcp14> silently drop the Map-Request message
      and <bcp14>SHOULD</bcp14> log the event to record that a replay attack
      could have occurred. Furthermore, upon processing, for the EID-Record
      that has the N-bit set to 1, the Map-Server proceeds to add the xTR-ID
      contained in the Map-Request to the list of xTRs that have requested to
      be subscribed to that EID-Prefix. </t>
      <t indent="0" pn="section-5-5">If an xTR-ID is successfully added to the list of subscribers for an
      EID-Prefix, the Map-Server <bcp14>MUST</bcp14> extract the nonce and
      ITR-RLOCs present in the Map-Request and store the association between
      the EID-Prefix, xTR-ID, ITR-RLOCs, and nonce. Any state that is already
      present regarding ITR-RLOCs and/or nonce for the same xTR-ID
      <bcp14>MUST</bcp14> be overwritten. When the LISP deployment has a
      single Map-Server, the Map-Server can be configured to keep a single
      nonce per xTR-ID for all EID-Prefixes (when used, this option
      <bcp14>MUST</bcp14> be enabled at the Map-Server and all xTRs).</t>
      <t indent="0" pn="section-5-6">If the xTR-ID is added to the list, the Map-Server
      <bcp14>MUST</bcp14> send a Map-Notify message back to the xTR to
      acknowledge the successful subscription. The Map-Server builds the
      Map-Notify according to Sections <xref target="RFC9301" section="5.5" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.5" derivedContent="RFC9301"/> and <xref target="RFC9301" section="5.7" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.7" derivedContent="RFC9301"/> of <xref target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/> with
      the following considerations:</t>
      <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-5-7">
	<li pn="section-5-7.1" derivedCounter="1.">The Map-Server <bcp14>MUST</bcp14> use the nonce from the
	Map-Request as the nonce for the Map-Notify.</li>
        <li pn="section-5-7.2" derivedCounter="2.">The Map-Server <bcp14>MUST</bcp14> use its security association
        with the xTR (<xref target="association" format="default" sectionFormat="of" derivedContent="Section 7.1"/>) to sign
        the authentication data of the Map-Notify. The xTR <bcp14>MUST</bcp14>
        use the security association to verify the received authentication
        data. </li>
        <li pn="section-5-7.3" derivedCounter="3.">The Map-Server <bcp14>MUST</bcp14> send the Map-Notify to one of
        the ITR-RLOCs received in the Map-Request (which one is
        implementation specific).</li>
      </ol>
      <t indent="0" pn="section-5-8">As a reminder, the initial transmission and retransmission of
      Map-Notify messages by a Map-Server follow the procedure specified in
      <xref target="RFC9301" sectionFormat="of" section="5.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.7" derivedContent="RFC9301"/>. Some state
      changes may trigger an overload that would impact, e.g., the outbound
      capacity of a Map-Server. A similar problem may be experienced when a
      large number of state entries are simultaneously updated. To prevent
      such phenomena, Map-Servers <bcp14>SHOULD</bcp14> be configured with
      policies to control the maximum number of subscriptions and also the
      pace of Map-Notify messages. For example, the Map-Server may be
      instructed to limit the resources that are dedicated to unsolicited
      Map-Notify messages to a small fraction (e.g., less than 10%) of its
      overall processing and forwarding capacity. The exact details to
      characterize such policies are deployment and implementation specific.
      Likewise, this document does not specify which notifications take
      precedence when these policies are enforced.</t>
      <t indent="0" pn="section-5-9">When the xTR receives a Map-Notify with a nonce that matches one in
      the list of outstanding Map-Request messages sent with an N-bit set, it
      knows that the Map-Notify is to acknowledge a successful
      subscription. The xTR processes this Map-Notify, as described in <xref target="RFC9301" sectionFormat="of" section="5.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.7" derivedContent="RFC9301"/> and
      <bcp14>MUST</bcp14> use the Map-Notify to populate its Map-Cache with
      the returned EID-Prefix and RLOC-set. As a reminder, following <xref target="RFC9301" sectionFormat="of" section="5.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.7" derivedContent="RFC9301"/>, the xTR has to send
      a Map-Notify-Ack back to the Map-Server. If the Map-Server does not
      receive the Map-Notify-Ack after exhausting the Map-Notify
      retransmissions described in <xref target="RFC9301" sectionFormat="of" section="5.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.7" derivedContent="RFC9301"/>, the Map-Server can remove the subscription state. If
      the Map-Server removes the subscription state, and absent explicit
      policy, it <bcp14>SHOULD</bcp14> notify the xTR by sending a single
      Map-Notify with the same nonce but with Loc-Count = 0 (and Loc-AFI = 0)
      and ACT bits set to 5 "Drop/Auth-Failure". It is <bcp14>OPTIONAL</bcp14>
      for the xTR to update its Map-Cache entry for the EID-Prefix (if any)
      based on this Map-Notify. This message is specifically useful for cases
      where Map-Notifies are successfully received by an xTR, but the
      corresponding Map-Notify-Acks are lost when forwarded to the
      Map-Server. xTR implementations can use this signal to try to reinstall
      their subscription state instead of maintaining stale mappings.</t>
      <t indent="0" pn="section-5-10">The subscription of an xTR-ID may fail for a number of reasons. For
      example, it fails because of local configuration policies (such as
      accept and drop lists of subscribers), because the Map-Server has
      exhausted the resources to dedicate to the subscription of that
      EID-Prefix (e.g., the number of subscribers excess the capacity of the
      Map-Server), or because the xTR was not successful tried but was not successful in
      establishing a new security association (<xref target="association" format="default" sectionFormat="of" derivedContent="Section 7.1"/>).</t>
      <t indent="0" pn="section-5-11">If the subscription request fails, the Map-Server sends a Map-Reply
      to the originator of the Map-Request, as described in <xref target="RFC9301" sectionFormat="of" section="8.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-8.3" derivedContent="RFC9301"/>, with the following
      considerations:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-12">
        <li pn="section-5-12.1">If the subscription request fails due to policy (e.g., for
        explicitly configured subscriptions, as described later in this
        section), the Map-Server <bcp14>MUST</bcp14> respond to the Map-Request
        with a Negative Map-Reply (Loc-Count = 0 and Loc-AFI = 0) with ACT
        bits set to 4 "Drop/Policy-Denied".</li>
        <li pn="section-5-12.2">If the subscription request fails due to authentication (e.g., when
        a new security association is being established, as described in
        <xref target="association" format="default" sectionFormat="of" derivedContent="Section 7.1"/>), the Map-Server
        <bcp14>MUST</bcp14> respond to the Map-Request with a Negative
        Map-Reply (Loc-Count = 0 and Loc-AFI = 0) with ACT bits set to 5
        "Drop/Auth-Failure".</li>
        <li pn="section-5-12.3">If the subscription request fails due to any other reason, the
        Map-Server <bcp14>MUST</bcp14> follow <xref target="RFC9301" sectionFormat="of" section="8.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-8.3" derivedContent="RFC9301"/> with no changes.</li>
      </ul>
      <t indent="0" pn="section-5-13">The xTR processes any Map-Reply or Negative Map-Reply as specified in <xref target="RFC9301" sectionFormat="of" section="8.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-8.1" derivedContent="RFC9301"/>, with the following
      considerations: if the xTR receives a Negative Map-Reply with ACT bits
      set to 4 "Drop/Policy-Denied" or 5 "Drop/Auth-Failure" as a response to
      a subscription request, it is <bcp14>OPTIONAL</bcp14> for the xTR to
      update its Map-Cache entry for the EID-Prefix (if any). If the subscription request fails (for whichever
      reason), it is up to the implementation of the xTR to try to subscribe
      again.</t>
      <t indent="0" pn="section-5-14">If the Map-Server receives a subscription request for an EID-Prefix
      not present in the mapping database, it <bcp14>SHOULD</bcp14> follow the
      same logic described in <xref target="RFC9301" sectionFormat="of" section="8.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-8.4" derivedContent="RFC9301"/> and create a temporary subscription state for the xTR-ID
      to the least specific prefix that both matches the original query and
      does not match any EID-Prefix known to exist in the LISP-capable
      infrastructure. Alternatively, the Map-Server can determine that
      such a subscription request fails and send a Negative Map-Reply
      following <xref target="RFC9301" sectionFormat="of" section="8.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-8.3" derivedContent="RFC9301"/>. In
      both cases, the TTL of the temporary subscription state or the Negative
      Map-Reply <bcp14>SHOULD</bcp14> be configurable, with a value of
      15 minutes being <bcp14>RECOMMENDED</bcp14>. </t>
      <t indent="0" pn="section-5-15">The subscription state can also be created explicitly by
      configuration at the Map-Server (possible when a pre-shared security
      association exists, see <xref target="security" format="default" sectionFormat="of" derivedContent="Section 7"/>)
      using a variety of means that are outside the scope of this document. 
  If there is no nonce that can be
  used for the explicit subscription state at the time the explicit
  subscription is configured (e.g., from a different subscription
  already established with the same xTR when a single nonce is kept per
  xTR-ID), then both the xTR and Map-Server <bcp14>MUST</bcp14> be configured with the initial nonce.
      <bcp14>RECOMMENDED</bcp14> to have a configuration option to enable (or
      disable) the xTR to accept publication information for EID-Prefixes that
      the xTR did not explicitly subscribe to. By default, the xTR is allowed
      to modify explicitly configured subscription state following the
      procedures described in this section; however, this <bcp14>MAY</bcp14> be
      disabled at the Map-Server via configuration. If the Map-Server is
      instructed to not allow xTRs to modify explicitly configured
      subscriptions, and an xTR tries to do so, this triggers a Negative
      Map-Reply with ACT bits set to 4 "Drop/Policy-Denied" as described
      earlier in this section.</t>
      <t indent="0" pn="section-5-16">The following specifies the procedure to remove a subscription:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-17">
        <li pn="section-5-17.1">If a valid Map-Request with the N-bit set to 1 only has one
	ITR-RLOC with AFI = 0 (i.e., Unknown Address), the Map-Server
	<bcp14>MUST</bcp14> remove the subscription state for that xTR-ID
	(unless this is disabled via configuration, see previous
	paragraph).</li>
        <li pn="section-5-17.2">If the subscription state is removed, the Map-Server
	<bcp14>MUST</bcp14> send a Map-Notify to the source RLOC of the
	Map-Request.</li>
        <li pn="section-5-17.3">
          <t indent="0" pn="section-5-17.3.1">If the subscription removal fails due to configuration, this
	triggers a Negative Map-Reply with ACT bits set to 4
	"Drop/Policy-Denied" as described earlier in this section; the
	Map-Server sends the Negative Map-Reply to the source RLOC of the
	Map-Request in this case.</t>
        </li>
        <li pn="section-5-17.4">
          <t indent="0" pn="section-5-17.4.1">Removing subscription state at the Map-Server can lead to replay
	attacks. To soften this, the Map-Server <bcp14>SHOULD</bcp14> keep the
	last nonce seen per xTR-ID (and EID-Prefix, when applicable).</t>
        </li>
        <li pn="section-5-17.5">If the Map-Server does not keep the last nonces seen, then the
	Map-Server <bcp14>MUST</bcp14> require the xTRs to subscribe using the
	procedure described in <xref target="association" format="default" sectionFormat="of" derivedContent="Section 7.1"/>
	to create a new security association with the Map-Server.</li>
      </ul>
      <t indent="0" pn="section-5-18">
If the Map-Server receives a Map-Request asking to remove a
                subscription for an EID-Prefix without subscription state for that
                xTR-ID and the EID-Prefix is covered by a less-specific EID-Prefix for which
                subscription state exists for the xTR-ID, the Map-Server <bcp14>SHOULD</bcp14> stop
                publishing updates about this more-specific EID-Prefix to that xTR
                until the xTR subscribes to the more-specific EID-Prefix. The same
      considerations regarding authentication, integrity protection, and nonce
      checks, which are described in this section and <xref target="security" format="default" sectionFormat="of" derivedContent="Section 7"/> for Map-Requests used to update subscription state,
      apply for Map-Requests used to remove subscription state.</t>
      <t indent="0" pn="section-5-19">When an EID-Prefix is removed from the Map-Server (either when
      explicitly withdrawn or when its TTL expires), the Map-Server notifies
      its subscribers (if any) via a Map-Notify with TTL equal to 0.</t>
    </section>
    <section anchor="publish" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-mapping-notification-publis">Mapping Notification Publish Procedures</name>
      <t indent="0" pn="section-6-1">The publish procedure is implemented via Map-Notify messages that the
      Map-Server sends to xTRs. The xTRs acknowledge the receipt of
      Map-Notifies by sending Map-Notify-Ack messages back to the
      Map-Server. The complete mechanism works as follows: </t>
      <t indent="0" pn="section-6-2"> When a mapping stored in a Map-Server is updated (e.g., via a
      Map-Register from an ETR), the Map-Server <bcp14>MUST</bcp14> notify the
      subscribers of that mapping via sending Map-Notify messages with the
      most up to date mapping information. If subscription state in the
      Map-Server exists for a less-specific EID-Prefix and a more-specific
      EID-Prefix is updated, then the Map-Notify is sent with the
      more-specific EID-Prefix mapping to the subscribers of the less-specific
      EID-Prefix mapping. The Map-Notify message sent to each of the
      subscribers as a result of an update event follows the encoding and
      logic defined in <xref target="RFC9301" sectionFormat="of" section="5.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.7" derivedContent="RFC9301"/> for Map-Notify, except for the following:</t>
      <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-6-3">
	<li pn="section-6-3.1" derivedCounter="1.">The Map-Notify <bcp14>MUST</bcp14> be sent to one of the ITR-RLOCs
	associated with the xTR-ID of the subscriber (which one is
	implementation specific). </li>
        <li pn="section-6-3.2" derivedCounter="2.">The Map-Server increments the nonce by one every time it sends a
        Map-Notify as publication to an xTR-ID for a particular
        EID-Prefix. </li>
        <li pn="section-6-3.3" derivedCounter="3.">The Map-Server <bcp14>MUST</bcp14> use its security association
        with the xTR to compute the authentication data of the
        Map-Notify.</li>
      </ol>
      <t indent="0" pn="section-6-4">When the xTR receives a Map-Notify with an EID that is not local  to the xTR, the xTR knows that the Map-Notify is to update an entry on its Map-Cache.
The xTR <bcp14>MUST</bcp14> keep track of the last
      nonce seen in a Map-Notify received as a publication from the Map-Server
      for the EID-Prefix. When the LISP deployment has a single Map-Server,
      the xTR can be configured to keep track of a single nonce for all
      EID-Prefixes (when used, this option <bcp14>MUST</bcp14> be enabled at
      the Map-Server and all xTRs). If a Map-Notify that is received as a
      publication has a nonce value that is not greater than the saved nonce,
      the xTR drops the Map-Notify message and logs the fact a replay attack
      could have occurred. The same considerations discussed in <xref target="RFC9301" sectionFormat="of" section="5.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.6" derivedContent="RFC9301"/> regarding
      Map-Register nonces apply here for Map-Notify nonces.</t>
      <t indent="0" pn="section-6-5">The xTR processes the received Map-Notify as specified in <xref target="RFC9301" sectionFormat="of" section="5.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.7" derivedContent="RFC9301"/>, with the following
      considerations:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6-6">
        <li pn="section-6-6.1">The xTR <bcp14>MUST</bcp14> use its security association with the
	Map-Server (<xref target="association" format="default" sectionFormat="of" derivedContent="Section 7.1"/>) to validate
	the authentication data on the Map-Notify.</li>
        <li pn="section-6-6.2">The xTR <bcp14>MUST</bcp14> use the mapping information carried
	in the Map-Notify to update its internal Map-Cache.</li>
        <li pn="section-6-6.3">If after following <xref target="RFC9301" sectionFormat="of" section="5.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.7" derivedContent="RFC9301"/> regarding retransmission of Map-Notify messages, the
	Map-Server has not received the Map-Notify-Ack, it can try 
	sending the Map-Notify to a different ITR-RLOC for that xTR-ID.</li>
        <li pn="section-6-6.4">If the Map-Server tries all the ITR-RLOCs without receiving a
	response, it may stop trying to send the
	Map-Notify.</li>
      </ul>
    </section>
    <section anchor="security" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">Generic security considerations related to LISP control messages are
      discussed in <xref target="RFC9301" sectionFormat="of" section="9" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-9" derivedContent="RFC9301"/>. </t>
      <t indent="0" pn="section-7-2">In the particular case of PubSub, cache poisoning via malicious
      Map-Notify messages is avoided by the use of nonce and the security
      association between the ITRs and the Map-Servers.</t>
      <t indent="0" pn="section-7-3">It is <bcp14>RECOMMENDED</bcp14> to follow guidance from the last
      paragraph of <xref target="RFC9301" sectionFormat="of" section="9" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-9" derivedContent="RFC9301"/> to
      ensure integrity protection of Map-Request messages (e.g., to prevent
      xTR-ID hijacking).</t>
      <section anchor="association" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-security-association-betwee">Security Association between ITR and Map-Server</name>
        <t indent="0" pn="section-7.1-1">Since Map-Notifies from the Map-Server to the ITR need to be
        authenticated, there is a need for a soft-state or hard-state security
        association (e.g., a PubSubKey) between the ITRs and the
        Map-Servers. For some controlled deployments, it might be possible to
        have a shared PubSubKey (or set of keys) between the ITRs and the
        Map-Servers. However, if pre-shared keys are not used in the
        deployment, LISP Security (LISP-SEC) <xref target="RFC9303" format="default" sectionFormat="of" derivedContent="RFC9303"/> can be used as follows to create a
        security association between the ITR and the Map-Server.</t>
        <t indent="0" pn="section-7.1-2">First, when the ITR is sending a Map-Request with the N-bit set
        as described in <xref target="sub" format="default" sectionFormat="of" derivedContent="Section 5"/>, the ITR also performs
        the steps described in <xref target="RFC9303" sectionFormat="of" section="6.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9303#section-6.4" derivedContent="RFC9303"/>. The ITR can then generate a PubSubKey by deriving a
        key from the One-Time Key (OTK) and Map-Request's nonce as follows:
        PubSubKey = KDF(OTK + nonce), where KDF is the Key Derivation Function
        indicated by the OTK Wrapping ID. If the OTK Wrapping ID equals
        NULL-KEY-WRAP-128, then the PubSubKey is the OTK. Note that, as opposed
        to the pre-shared PubSubKey, this generated PubSubKey is different per
        EID-Prefix to which an ITR subscribes (since the ITR will use a
        different OTK per Map-Request).</t>
        <t indent="0" pn="section-7.1-3">When the Map-Server receives the Map-Request, it follows the
        procedure specified in <xref target="sub" format="default" sectionFormat="of" derivedContent="Section 5"/> with the
        following considerations: the Map-Server <bcp14>MUST</bcp14> verify
        that the OTK has not been used before. If the Map-Server verifies the
        OTK and cannot determine that the OTK has not been used before, the
        subscription request fails due to authentication, which triggers a
        Negative Map-Reply with ACT bits set to 5 "Drop/Auth-Failure", as
        described in <xref target="sub" format="default" sectionFormat="of" derivedContent="Section 5"/>. The xTR might try
        again with a different OTK upon receipt of this Negative
        Map-Reply. Note that a Map-Server implementation may decide not to keep track
   of all past OTKs and instead use some form of hash. In that case,
        hash collisions are handled as if the OTK has been reused. Such an
        implementation needs to balance the hash length with the rate of
        collisions expected for the particular deployment; this is
        implementation specific. If the Map-Server has to reply with a
        Map-Reply for any other reason (e.g., if PubSub is not supported or a
        subscription is not accepted), then it follows the normal LISP-SEC
        procedure described in <xref target="RFC9303" sectionFormat="of" section="5.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9303#section-5.7" derivedContent="RFC9303"/>. No PubSubKey, security association, or subscription
        state is created when the Map-Server responds with any Map-Reply
        message.</t>
        <t indent="0" pn="section-7.1-4">Otherwise, if the Map-Server has to reply with a Map-Notify (e.g.,
        due to the subscription being accepted) to a received Map-Request, the
        following extra steps take place:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.1-5">
          <li pn="section-7.1-5.1">The Map-Server extracts the OTK and the OTK Wrapping ID from the
          LISP-SEC Encapsulated Control Message (ECM) Authentication Data.</li>
          <li pn="section-7.1-5.2">The Map-Server generates a PubSubKey by deriving a key from the
          OTK, as described before for the ITR. This is the same PubSubKey
          derived at the ITR that is used to establish a security association
          between the ITR and the Map-Server.</li>
          <li pn="section-7.1-5.3">The PubSubKey can now be used to sign and authenticate any
          Map-Notify between the Map-Server and the ITR for the subscribed
          EID-Prefix. This includes the Map-Notify sent as a confirmation to
          the subscription. When the ITR wants to update the security
          association for that Map-Server and EID-Prefix, it once again
          follows the procedure described in this section.</li>
        </ul>
        <t indent="0" pn="section-7.1-6">Note that if the Map-Server replies with a Map-Notify, none of the
        regular LISP-SEC steps regarding Map-Reply described in <xref target="RFC9303" sectionFormat="of" section="5.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9303#section-5.7" derivedContent="RFC9303"/> occur.</t>
      </section>
      <section anchor="ddos" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-ddos-attack-mitigation">DDoS Attack Mitigation</name>
        <t indent="0" pn="section-7.2-1">If PubSub is deployed under the scope of applicability defined in
        <xref target="app-scope" format="default" sectionFormat="of" derivedContent="Section 1.1"/>, only known nodes can
        participate on the PubSub deployment. DDoS attacks based on replayed
        messages by unknown nodes are avoided by the use of nonce and the
        security association between the ITRs and the Map-Servers. Misbehaving
        known nodes may send massive subscription requests, which may lead to
        exhausting the resources of a Map-Server. Furthermore, frequently
        changing the state of a subscription may also be considered as an
        attack vector. To mitigate such issues, <xref target="RFC9301" sectionFormat="of" section="5.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.3" derivedContent="RFC9301"/> discusses rate-limiting
        Map-Requests, and <xref target="RFC9301" sectionFormat="of" section="5.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.7" derivedContent="RFC9301"/> discusses rate-limiting Map-Notifies. Note that when
        the Map-Notify rate-limit threshold is met for a particular xTR-ID,
        the Map-Server will discard additional subscription requests from that
        xTR-ID and will fall back to the behavior described in <xref target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/> when receiving a Map-Request from
        that xTR-ID (i.e., the Map-Server will send a Map-Reply).</t>
      </section>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-8-1">IANA has assigned the following new bit from the 
"LISP Control Plane Header Bits: Map-Request" registry within the
      "Locator/ID Separation Protocol (LISP) Parameters" group of registries <xref target="IANA-LISP" format="default" sectionFormat="of" derivedContent="IANA-LISP"/>:</t>
      <table align="center" pn="table-1">
        <name slugifiedName="name-addition-to-the-map-request">Addition to the Map-Request Header Bits Registry</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Spec Name</th>
            <th align="left" colspan="1" rowspan="1">IANA Name</th>
            <th align="left" colspan="1" rowspan="1">Bit Position</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">I</td>
            <td align="left" colspan="1" rowspan="1">Map-Request-I</td>
            <td align="left" colspan="1" rowspan="1">11</td>
            <td align="left" colspan="1" rowspan="1">xTR-ID Bit</td>
            <td align="left" colspan="1" rowspan="1">RFC 9437</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-8-3">IANA has also created a new registry
      entitled "LISP Control Plane Header Bits: Map-Request-Record" within the
      "Locator/ID Separation Protocol (LISP) Parameters" group of registries <xref target="IANA-LISP" format="default" sectionFormat="of" derivedContent="IANA-LISP"/>.</t>
      <t indent="0" pn="section-8-4">The initial content of this registry is shown in <xref target="bits-table" format="default" sectionFormat="of" derivedContent="Table 2"/>.</t>
      <table anchor="bits-table" align="center" pn="table-2">
        <name slugifiedName="name-initial-content-of-lisp-con">Initial Content of LISP Control Plane Header Bits: Map‑Request-Record Registry</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Spec Name</th>
            <th align="left" colspan="1" rowspan="1">IANA Name</th>
            <th align="left" colspan="1" rowspan="1">Bit Position</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">N</td>
            <td align="left" colspan="1" rowspan="1">Map-Request-N</td>
            <td align="left" colspan="1" rowspan="1">1</td>
            <td align="left" colspan="1" rowspan="1">Notification-Requested Bit</td>
            <td align="left" colspan="1" rowspan="1">RFC 9437</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-8-6">The remaining bits (i.e., bit positions 2-8) are Unassigned.</t>
      <t indent="0" pn="section-8-7">The policy for allocating new bits in this registry is
      "Specification Required" (<xref target="RFC8126" sectionFormat="of" section="4.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8126#section-4.6" derivedContent="RFC8126"/>). </t>
      <t indent="0" pn="section-8-8">Allocation requests are evaluated on the advice of one or more designated
      experts. 
   Designated experts should consider whether the proposed registration duplicates
   existing entries and whether the registration description is
   sufficiently detailed and fits the purpose of this registry.  These
   criteria are to be considered in addition to those provided in
   <xref target="RFC8126" sectionFormat="of" section="4.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8126#section-4.6" derivedContent="RFC8126"/> (e.g., the proposed registration "must be
   documented in a permanent and readily available public
   specification"). The designated experts will either approve or
      deny the registration request, and communicate their decision to
      IANA. Denials should include an explanation and, if applicable,
      suggestions as to how to make the request successful. </t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-lisp-eid-mobility" to="EID-MOBILITY"/>
    <displayreference target="I-D.haindl-lisp-gb-atn" to="GB-ATN"/>
    <displayreference target="I-D.moreno-lisp-uberlay" to="UBERLAY"/>
    <displayreference target="I-D.boucadair-lisp-pubsub-flow-examples" to="FLOW-EXAMPLES"/>
    <displayreference target="I-D.ietf-lisp-yang" to="LISP-YANG"/>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC9300" target="https://www.rfc-editor.org/info/rfc9300" quoteTitle="true" derivedAnchor="RFC9300">
          <front>
            <title>The Locator/ID Separation Protocol (LISP)</title>
            <author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
            <author fullname="V. Fuller" initials="V." surname="Fuller"/>
            <author fullname="D. Meyer" initials="D." surname="Meyer"/>
            <author fullname="D. Lewis" initials="D." surname="Lewis"/>
            <author fullname="A. Cabellos" initials="A." role="editor" surname="Cabellos"/>
            <date month="October" year="2022"/>
            <abstract>
              <t indent="0">This document describes the data plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces: Endpoint Identifiers (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify network attachment points. With this, LISP effectively separates control from data and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.</t>
              <t indent="0">LISP requires no change to either host protocol stacks or underlay routers and offers Traffic Engineering (TE), multihoming, and mobility, among other features.</t>
              <t indent="0">This document obsoletes RFC 6830.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9300"/>
          <seriesInfo name="DOI" value="10.17487/RFC9300"/>
        </reference>
        <reference anchor="RFC9301" target="https://www.rfc-editor.org/info/rfc9301" quoteTitle="true" derivedAnchor="RFC9301">
          <front>
            <title>Locator/ID Separation Protocol (LISP) Control Plane</title>
            <author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
            <author fullname="F. Maino" initials="F." surname="Maino"/>
            <author fullname="V. Fuller" initials="V." surname="Fuller"/>
            <author fullname="A. Cabellos" initials="A." role="editor" surname="Cabellos"/>
            <date month="October" year="2022"/>
            <abstract>
              <t indent="0">This document describes the control plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provide a simplified "front end" for one or more Endpoint IDs (EIDs) to Routing Locator mapping databases.</t>
              <t indent="0">By using this control plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems; this behavior facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP control plane infrastructure, connecting EID addressable nodes of a LISP site, the implementation and operational complexity of the overall cost and effort of deploying LISP is reduced.</t>
              <t indent="0">This document obsoletes RFCs 6830 and 6833.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9301"/>
          <seriesInfo name="DOI" value="10.17487/RFC9301"/>
        </reference>
        <reference anchor="RFC9303" target="https://www.rfc-editor.org/info/rfc9303" quoteTitle="true" derivedAnchor="RFC9303">
          <front>
            <title>Locator/ID Separation Protocol Security (LISP-SEC)</title>
            <author fullname="F. Maino" initials="F." surname="Maino"/>
            <author fullname="V. Ermagan" initials="V." surname="Ermagan"/>
            <author fullname="A. Cabellos" initials="A." surname="Cabellos"/>
            <author fullname="D. Saucez" initials="D." surname="Saucez"/>
            <date month="October" year="2022"/>
            <abstract>
              <t indent="0">This memo specifies Locator/ID Separation Protocol Security (LISP-SEC), a set of security mechanisms that provides origin authentication, integrity, and anti-replay protection to the LISP's Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mapping data conveyed via the mapping lookup process. LISP-SEC also enables verification of authorization on EID-Prefix claims in Map-Reply messages.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9303"/>
          <seriesInfo name="DOI" value="10.17487/RFC9303"/>
        </reference>
      </references>
      <references pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-lisp-eid-mobility" target="https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-mobility-12" quoteTitle="true" derivedAnchor="EID-MOBILITY">
          <front>
            <title>LISP L2/L3 EID Mobility Using a Unified Control Plane</title>
            <author initials="M." surname="Portoles" fullname="Marc Portoles">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author initials="V." surname="Ashtaputre" fullname="Vrushali Ashtaputre">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author initials="F." surname="Maino" fullname="Fabio Maino">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author initials="V." surname="Moreno" fullname="Victor Moreno">
              <organization showOnFrontPage="true">Google LLC</organization>
            </author>
            <author initials="D." surname="Farinacci" fullname="Dino Farinacci">
              <organization showOnFrontPage="true">lispers.net</organization>
            </author>
            <date month="July" day="4" year="2023"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-eid-mobility-12"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.boucadair-lisp-pubsub-flow-examples" target="https://datatracker.ietf.org/doc/html/draft-boucadair-lisp-pubsub-flow-examples-03" quoteTitle="true" derivedAnchor="FLOW-EXAMPLES">
          <front>
            <title>LISP PubSub Flow Examples</title>
            <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
              <organization showOnFrontPage="true">Orange</organization>
            </author>
            <date day="10" month="February" year="2023"/>
            <abstract>
              <t indent="0">This document provides a set of flow examples to illustrate the use of LISP PubSub specification. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Locator/ID Separation Protocol Working Group mailing list (lisp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/lisp/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/lisp-pubsub-flow-examples.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-boucadair-lisp-pubsub-flow-examples-03"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.haindl-lisp-gb-atn" target="https://datatracker.ietf.org/doc/html/draft-haindl-lisp-gb-atn-09" quoteTitle="true" derivedAnchor="GB-ATN">
          <front>
            <title>Ground-Based LISP for the Aeronautical Telecommunications Network</title>
            <author initials="B." surname="Haindl" fullname="Bernhard Haindl">
              <organization showOnFrontPage="true">Frequentis</organization>
            </author>
            <author initials="M." surname="Lindner" fullname="Manfred Lindner">
              <organization showOnFrontPage="true">Frequentis</organization>
            </author>
            <author initials="V." surname="Moreno" fullname="Victor Moreno">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <author initials="M." surname="Portoles" fullname="Marc Portoles">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author initials="F." surname="Maino" fullname="Fabio Maino">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author initials="B." surname="Venkatachalapathy" fullname="Balaji Venkatachalapathy">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <date month="March" day="27" year="2023"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-haindl-lisp-gb-atn-09"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="IANA-LISP" target="https://www.iana.org/assignments/lisp-parameters/" quoteTitle="true" derivedAnchor="IANA-LISP">
          <front>
            <title>Locator/ID Separation Protocol (LISP) Parameters</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="I-D.ietf-lisp-yang" target="https://datatracker.ietf.org/doc/html/draft-ietf-lisp-yang-19" quoteTitle="true" derivedAnchor="LISP-YANG">
          <front>
            <title>LISP YANG Model</title>
            <author initials="V." surname="Ermagan" fullname="Vina Ermagan">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <author initials="A." surname="Rodriguez-Natal" fullname="Alberto Rodriguez-Natal">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author initials="F." surname="Coras" fullname="Florin Coras">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author initials="C." surname="Moberg" fullname="Carl Moberg">
              <organization showOnFrontPage="true">Avassa</organization>
            </author>
            <author initials="R." surname="Rahman" fullname="Reshad Rahman"> </author>
            <author initials="A." surname="Cabellos" fullname="Albert Cabellos">
              <organization showOnFrontPage="true">Technical University of Catalonia</organization>
            </author>
            <author initials="F." surname="Maino" fullname="Fabio Maino">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <date month="March" day="2" year="2023"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lisp-yang-19"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC6835" target="https://www.rfc-editor.org/info/rfc6835" quoteTitle="true" derivedAnchor="RFC6835">
          <front>
            <title>The Locator/ID Separation Protocol Internet Groper (LIG)</title>
            <author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
            <author fullname="D. Meyer" initials="D." surname="Meyer"/>
            <date month="January" year="2013"/>
            <abstract>
              <t indent="0">A simple tool called the Locator/ID Separation Protocol (LISP) Internet Groper or 'lig' can be used to query the LISP mapping database. This document describes how it works. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6835"/>
          <seriesInfo name="DOI" value="10.17487/RFC6835"/>
        </reference>
        <reference anchor="I-D.moreno-lisp-uberlay" target="https://datatracker.ietf.org/doc/html/draft-moreno-lisp-uberlay-06" quoteTitle="true" derivedAnchor="UBERLAY">
          <front>
            <title>Uberlay Interconnection of Multiple LISP overlays</title>
            <author fullname="Victor Moreno" initials="V." surname="Moreno">
              <organization showOnFrontPage="true">Google LLC</organization>
            </author>
            <author fullname="Dino Farinacci" initials="D." surname="Farinacci">
              <organization showOnFrontPage="true">lispers.net</organization>
            </author>
            <author fullname="Alberto Rodriguez-Natal" initials="A." surname="Rodriguez-Natal">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Marc Portoles-Comeras" initials="M." surname="Portoles-Comeras">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Fabio Maino" initials="F." surname="Maino">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Sanjay Hooda" initials="S." surname="Hooda">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <date day="28" month="September" year="2022"/>
            <abstract>
              <t indent="0">This document describes the use of the Locator/ID Separation Protocol (LISP) to interconnect multiple disparate and independent network overlays by using a transit overlay. The transit overlay is referred to as the "uberlay" and provides connectivity and control plane abstraction between different overlays. Each network overlay may use different control and data plane approaches and may be managed by a different organization. Structuring the network into multiple network overlays enables the interworking of different overlay approaches to data and control plane methods. The different network overlays are autonomous from a control and data plane perspective, this in turn enables failure survivability across overlay domains. This document specifies the mechanisms and procedures for the distribution of control plane information across overlay sites and in the uberlay as well as the lookup and forwarding procedures for unicast and multicast traffic within and across overlays. The specification also defines the procedures to support inter-overlay mobility of EIDs and their integration with the intra-overlay EID mobility procedures defined in draft-ietf-lisp-eid-mobility.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-moreno-lisp-uberlay-06"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="deployment" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-sample-pubsub-deployment-ex">Sample PubSub Deployment Experiences</name>
      <t indent="0" pn="section-appendix.a-1">Some LISP production networks have been running different forms of PubSub for some time. The following subsections provide an inventory of some experience lessons from these deployments.</t>
      <section anchor="deploy-monitoring" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.1">
        <name slugifiedName="name-pubsub-as-a-monitoring-tool">PubSub as a Monitoring Tool</name>
        <t indent="0" pn="section-appendix.a.1-1">Some LISP deployments are using PubSub as a way to monitor
        EID-Prefixes (particularly, EID-to-RLOC mappings). To that aim, some
        LISP implementations have extended the LISP Internet Groper ('lig')
        <xref target="RFC6835" format="default" sectionFormat="of" derivedContent="RFC6835"/> tool to use PubSub. Such an
        extension is meant to support an interactive mode with 'lig' and to
        request subscription for the EID of interest. If there are RLOC
        changes, the Map-Server sends a notification, and then the 'lig' client
        displays that change to the user. </t>
      </section>
      <section anchor="deploy-nmr" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.2">
        <name slugifiedName="name-mitigating-negative-map-cac">Mitigating Negative Map-Cache Entries</name>
        <t indent="0" pn="section-appendix.a.2-1"><xref target="RFC9301" sectionFormat="of" section="8.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-8.1" derivedContent="RFC9301"/> suggests
        two TTL values for Negative Map-Replies: either a 15-minute TTL (if
        the EID-Prefix does not exist) or a 1-minute TTL (if the prefix exists
        but has not been registered). While these values are based on the
        original operational experience of the LISP protocol designers,
        negative cache entries have two unintended effects that were observed
        in production.</t>
        <t indent="0" pn="section-appendix.a.2-2">First, if the xTR keeps receiving traffic for a negative EID
        destination (i.e., an EID-Prefix with no RLOCs associated with it), it
        will try to resolve the destination again once the cached state
        expires, even if the state has not changed in the Map-Server. It was
        observed in production that this is happening often in networks that
        have a significant amount of traffic addressed for outside of the LISP
        network. This might result in excessive resolution signaling to keep
        retrieving the same state due to the cache expiring. PubSub is used to
        relax TTL values and cache negative mapping entries for longer periods
        of time, avoiding unnecessary refreshes of these forwarding entries
        and drastically reducing signaling in these scenarios. In general, a
        TTL-based schema is a "polling mechanism" that leads to more signaling
        where PubSub provides an "event-triggered mechanism" at the cost of
        state.</t>
        <t indent="0" pn="section-appendix.a.2-3">Second, if the state does indeed change in the Map-Server, updates
        based on TTL timeouts might prevent the cached state at the xTR from
        being updated until the TTL expires. This behavior was observed during
        configuration (or reconfiguration) periods on the network, where
        EID-Prefixes that are no longer negative do not receive the traffic
        yet, due to stale Map-Cache entries present in the network. With the
        activation of PubSub, stale caches can be updated as soon as the state
        changes.</t>
      </section>
      <section anchor="deploy-mobility" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.3">
        <name slugifiedName="name-improved-mobility-latency">Improved Mobility Latency</name>
        <t indent="0" pn="section-appendix.a.3-1">An improved convergence time was observed on the presence of
        mobility events on LISP networks running PubSub as compared with
        running LISP <xref target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>. As described
        in Section 4.1.2.1 of <xref target="I-D.ietf-lisp-eid-mobility" format="default" sectionFormat="of" derivedContent="EID-MOBILITY"/>, LISP can rely on data-driven Solicit-Map-Requests
        (SMRs) to ensure eventual network convergence. Generally, PubSub offers
        faster convergence due to (1) no need to wait for a data-triggered
        event and (2) less signaling as compared with the SMR-based flow. Note
        that when a Map-Server running PubSub has to update a large number of
        subscribers at once (i.e., when a popular mapping is updated),
        SMR-based convergence may be faster for a small subset of the
        subscribers (those receiving PubSub updates last). Deployment
        experience reveals that data-driven SMRs and PubSub mechanisms
        complement each other and provide a fast and resilient network
        infrastructure in the presence of mobility events.</t>
        <t indent="0" pn="section-appendix.a.3-2">Furthermore, experience showed that not all LISP entities on the
        network need to implement PubSub for the network to get the
        benefits. In scenarios with significant traffic coming from outside of
        the LISP network, the experience showed that enabling PubSub in the
        border routers significantly improves mobility latency overall. Even
        if edge xTRs do not implement PubSub, and traffic is exchanged between
        EID-Prefixes at the edge, xTRs still converge based on data-driven
        events and SMR-triggered updates.</t>
      </section>
      <section anchor="deploy-redistribution" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.4">
        <name slugifiedName="name-enhanced-reachability-with-">Enhanced Reachability with Dynamic Redistribution of
        Prefixes</name>
        <t indent="0" pn="section-appendix.a.4-1">There is a need to interconnect LISP networks with other networks
        that might or might not run LISP. Some of those scenarios are similar
        to the ones described in <xref target="I-D.haindl-lisp-gb-atn" format="default" sectionFormat="of" derivedContent="GB-ATN"/> and <xref target="I-D.moreno-lisp-uberlay" format="default" sectionFormat="of" derivedContent="UBERLAY"/>. When connecting LISP to other networks, the
        experience revealed that in many deployments the point of interaction
        with the other domains is not the Mapping System but rather the border
        router of the LISP site. For those cases, the border router needs to be
        aware of the LISP prefixes to redistribute them to the other
        networks. Over the years, different solutions have been used.</t>
        <t indent="0" pn="section-appendix.a.4-2">First, Map-Servers were collocated with the border routers, but
        this was hard to scale since border routers scale at a different pace
        than Map-Servers. Second, decoupled Map-Servers and border routers
        were used with static configuration of LISP entries on the border,
        which was problematic when modifications were made. Third, a routing
        protocol (e.g., BGP) can be used to redistribute LISP prefixes from
        the Map-Servers to a border router, but this comes with some
        implications; in particular, the Map-Servers need to implement an
        additional protocol, which consumes resources and needs to be properly
        configured. Therefore, once PubSub was available, deployments started
        to adapt it to enable border routers to dynamically learn the prefixes
        they need to redistribute without a need for extra protocols or extra
        configuration on the network.</t>
        <t indent="0" pn="section-appendix.a.4-3">In other words, PubSub can be used to discover EID-Prefixes so they
        can be imported into other routing domains that do not use
        LISP. Similarly, PubSub can also be used to discover when EID-Prefixes
        need to be withdrawn from other routing domains. That is, in a typical
        deployment, a border router will withdraw an EID-Prefix that it has
        been announcing to external routing domains if it receives a
        notification that the RLOC-set for that EID-Prefix is now empty.</t>
      </section>
      <section anchor="deploy-service" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.5">
        <name slugifiedName="name-better-serviceability">Better Serviceability</name>
        <t indent="0" pn="section-appendix.a.5-1">EID-to-RLOC mappings can have a very long TTL, sometimes on the order
        of several hours. Upon the expiry of that TTL, the xTR checks if these
        entries are being used and removes any entry that is not being
        used. The problem with a very long Map-Cache TTL is that (in the
   absence of PubSub) if a mapping changes but is not being used,
   the cache remains but is stale. This is due to no data traffic being sent to
        the old location to trigger an SMR-based Map-Cache update as described
        in Section 4.1.2.1 of <xref target="I-D.ietf-lisp-eid-mobility" format="default" sectionFormat="of" derivedContent="EID-MOBILITY"/>. If the network operator runs a show command on a
        router to track the state of the Map-Cache, the router will display
        multiple entries waiting to expire but with stale RLOC
        information. This might be confusing for operators sometimes,
        particularly when they are debugging problems. With PubSub, the
        Map-Cache is updated with the correct RLOC information, even when it
        is not being used or waiting to expire, which helps with
        debugging.</t>
      </section>
    </section>
    <section numbered="false" anchor="Acknowledgments" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.b-1"> We would like to thank <contact fullname="Marc Portoles"/>, <contact fullname="Balaji Venkatachalapathy"/>, <contact fullname="Bernhard       Haindl"/>, <contact fullname="Luigi Iannone"/>, and <contact fullname="Padma Pillay-Esnault"/> for their great suggestions and help
      regarding this document. </t>
      <t indent="0" pn="section-appendix.b-2"> Many thanks to <contact fullname="Alvaro Retana"/> for the careful
      AD review.</t>
      <t indent="0" pn="section-appendix.b-3">Thanks to <contact fullname="Chris M. Lonvick"/> for the security
      directorate review, <contact fullname="Al Morton"/> for the OPS-DIR
      review, <contact fullname="Roni Even"/> for the Gen-ART review, <contact fullname="Mike McBride"/> for the rtg-dir review, <contact fullname="Magnus Westerlund"/> for the tsv directorate review, and
      <contact fullname="Sheng Jiang"/> for the int-dir review.</t>
      <t indent="0" pn="section-appendix.b-4"> Thanks to <contact fullname="John Scudder"/>, <contact fullname="Erik Kline"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Martin Duke"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Éric Vyncke"/>,
      <contact fullname="Robert Wilton"/>, <contact fullname="Zaheduzzaman       Sarker"/>, and <contact fullname="Roman Danyliw"/> for the IESG
      review.</t>
      <t indent="0" pn="section-appendix.b-5"> This work was partly funded by the ANR LISP-Lab project
      #ANR-13-INFR-009 <eref target="https://anr.fr/Projet-ANR-13-INFR-0009" brackets="angle"/>.</t>
    </section>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.c">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact fullname="Dino Farinacci">
        <organization showOnFrontPage="true">lispers.net</organization>
        <address>
          <postal>
            <city>San Jose</city>
            <region>CA</region>
            <country>United States of America</country>
          </postal>
          <email>farinacci@gmail.com</email>
        </address>
      </contact>
      <contact fullname="Johnson Leong">
        <address>
          <email>johnsonleong@gmail.com</email>
        </address>
      </contact>
      <contact fullname="Fabio Maino">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <postal>
            <city>San Jose</city>
            <region>CA</region>
            <country>United States of America</country>
          </postal>
          <email>fmaino@cisco.com</email>
        </address>
      </contact>
      <contact fullname="Christian Jacquenet">
        <organization showOnFrontPage="true">Orange</organization>
        <address>
          <postal>
            <city>Rennes</city>
            <country>France</country>
          </postal>
          <email>christian.jacquenet@orange.com</email>
        </address>
      </contact>
      <contact fullname="Stefano Secci">
        <organization showOnFrontPage="true">Cnam</organization>
        <address>
          <postal>
            <country>France</country>
          </postal>
          <email>stefano.secci@cnam.fr</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Alberto Rodriguez-Natal" initials="A." surname="Rodriguez-Natal">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <postal>
            <street/>
            <city>Barcelona</city>
            <region/>
            <code/>
            <country>Spain</country>
          </postal>
          <phone/>
          <email>natal@cisco.com</email>
        </address>
      </author>
      <author fullname="Vina Ermagan" initials="V." surname="Ermagan">
        <organization showOnFrontPage="true">Google</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country>United States of America</country>
          </postal>
          <phone/>
          <email>ermagan@gmail.com</email>
        </address>
      </author>
      <author fullname="Albert Cabellos" initials="A." surname="Cabellos">
        <organization showOnFrontPage="true">UPC/BarcelonaTech</organization>
        <address>
          <postal>
            <street/>
            <city>Barcelona</city>
            <region/>
            <code/>
            <country>Spain</country>
          </postal>
          <phone/>
          <email>acabello@ac.upc.edu</email>
        </address>
      </author>
      <author fullname="Sharon Barkai" initials="S." surname="Barkai">
        <organization showOnFrontPage="true">Nexar</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country/>
          </postal>
          <phone/>
          <email>sharon.barkai@getnexar.com</email>
        </address>
      </author>
      <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
        <organization showOnFrontPage="true">Orange</organization>
        <address>
          <postal>
            <street/>
            <city>Rennes</city>
            <region/>
            <code/>
            <country>France</country>
          </postal>
          <phone/>
          <email>mohamed.boucadair@orange.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
