<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY % RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?rfc rfcedstyle="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<rfc category="std" docName="draft-boucadair-lisp-bulk-07" ipr="trust200902">
  <front>
    <title abbrev="LISP Map-Bulk">LISP Mapping Bulk Retrieval</title>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>Orange</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
      <organization>Orange</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>christian.jacquenet@orange.com</email>
      </address>
    </author>

    <date day="03" month="April" year="2018" />

    <area>Internet</area>

    <keyword>Service Availability</keyword>

    <keyword>IPv6</keyword>

    <keyword>IPv4 over IPv6</keyword>

    <keyword>Routing Tables</keyword>

    <keyword>Sustain Internet growth</keyword>

    <keyword>reduce the size of RIBs</keyword>

    <abstract>
      <t>This document extends Locator/ID Separation Protocol (LISP) with a
      capability for bulk mapping retrieval. It does so by defining new LISP
      messages that are meant to facilitate state recovery of mapping tables
      and improve Ingress Tunnel Routers (ITR) recovery times, in particular.
      Unlike base LISP, these new messages are transported over TCP. </t>

      <t>In addition, this document allows to request mappings that match
      destination IP prefixes, names, or AS numbers.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>Locator/ID Separation Protocol (LISP, <xref target="RFC6830"></xref>
      ) operation relies upon a mapping mechanism that is used by
      ingress/egress Tunnel Routers (xTR) to forward traffic over the LISP
      network. This document extends LISP with a capability for bulk mappings
      retrieval. It does so by defining new LISP messages that are meant to
      facilitate state recovery of mapping tables and improve Ingress Tunnel
      Routers (ITR) recovery times, in particular.</t>

      <t>The base LISP specification does not define how a requestor may ask
      for multiple EIDs. Indeed, the current LISP specification <xref
      target="RFC6830"></xref> states the following:<figure>
          <artwork><![CDATA[      Support for requesting multiple EIDs in a single Map-Request
      message will be specified in a future version of the protocol.]]></artwork>
        </figure></t>

      <t><xref target="I-D.boucadair-lisp-multiple-records"></xref> defines a
      backward compatible extension of the LISP Map-Request message to request
      multiple records.</t>

      <t>This document defines a more reliable method for the retrieval of
      mapping records from one or multiple Map-Resolvers (<xref
      target="bmr"></xref>). It does so by using TCP (<xref
      target="RFC0793"></xref>) as a transport protocol for exchanges the bulk
      retrieval messages. Other proposals have been made to use TCP for
      reliable transport (e.g., <xref
      target="I-D.kouvelas-lisp-map-server-reliable-transport"></xref>).</t>

      <t>The extensions defined by this document allow for faster recovery of
      mapping entries. For example: <list style="numbers">
          <t>Whenever an ITR fails for some reason, the faulty ITR needs to
          recover at least the list of mappings for the most popular prefixes
          in a timely manner, etc. </t>

          <t>These extensions may be used by a leaf LISP network or enabled
          between Mapping Systems for the sake of global mapping table
          maintenance. Policies for the mapping entries to be recovered are
          deployment-specific.</t>
        </list></t>

      <t>This document allows to request mappings that match destination IP
      prefixes, names, or AS numbers. Other filter types may be defined in
      future versions, if needed.</t>
    </section>

    <section title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </section>

    <section anchor="bmr" title="Bulk Mapping Retrieval: Message Formats">
      <t>To allow for a more reliable method when retrieving multiple EID
      mapping records from one or multiple Map-Resolvers, this section defines
      additional LISP messages that are, unlike LISP control messages,
      transported over TCP.</t>

      <t>After establishing a TCP connection towards a Map-Resolver (using the
      LISP service port), the ITR sends a Map-Bulk-Request (<xref
      target="mbr"></xref>). Upon receipt of that message, the Map-Resolver
      must reply with one or more Map-Bulk-Reply messages (<xref
      target="mbs"></xref>). Once the last Map-Bulk-Reply is received from the
      Map-Resolver, the underlying TCP connection may be closed.</t>

      <section anchor="mbr" title="Map-Bulk-Request Message Format">
        <t>The format of the Map-Bulk-Request message is shown in <xref
        target="mbrf"></xref>.</t>

        <t><figure anchor="mbrf" title="Map-Bulk-Request Message Format">
            <artwork><![CDATA[        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=15|        Sub-type       |R|         Reserved            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Transaction ID                         |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   | Length        |                                               |
   F   +-+-+-+-+-+-+-+-+                                               :
   I   :                             Filter                            :
   L   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   T                                 ...
   E   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Length        |                                               |
   S   +-+-+-+-+-+-+-+-+                                               :
   |   :                             Filter                            :
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>

        <t>The description of the fields is as follows:<list style="symbols">
            <t>Type: MUST be set to 15(see <xref
            target="RFC8113"></xref>).</t>

            <t>Sub-type: MUST be set to 1025.</t>

            <t>R bit: MUST be set to 0 for Map-Bulk-Request messages.</t>

            <t>Reserved: reserved bits, MUST be sent as zeros and MUST be
            ignored when received.</t>

            <t>Transaction ID: This field is used to uniquely identify a
            connection context among those established with the same
            Map-Resolver. Demux connections established with distinct
            Map-Resolvers may rely on the address of the Map-Resolver. A
            transaction-id MUST be unique for connections bound to the same
            Map-Resolver.</t>

            <t>Length: This field indicates, in octets, the length of the
            filter that is encoded in the "Filter" field.</t>

            <t>Filter: This field carries a destination EID (or a set thereof)
            that is encoded as an UTF-8 string. This specification allows to
            convey IP prefix literals, Names and/or AS numbers. One or
            multiple filters may be present in a request. IPv4 prefixes are
            encoded as IPv4-mapped IPv6 prefixes <xref
            target="RFC4291"></xref> (i.e., starting with ::ffff:0:0/96). A
            mix of names, IP prefixes and AS numbers may be enclosed in the
            same request. The value 0 is used to indicate "ANY" mapping.</t>
          </list></t>
      </section>

      <section anchor="mbs" title="Map-Bulk-Response Message Format">
        <t>The format of the Map-Bulk-Reply message is shown in <xref
        target="mbsf"></xref>.</t>

        <t><figure anchor="mbsf" title="Map-Bulk-Reply Message Format">
            <artwork><![CDATA[
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=15|        Sub-type       |R|M|rsv| Records Count |Results|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Transaction ID                         |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |  Code         |   Length      |                               |
   F   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               :
   I   :                             Filter                            :
   L   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   T                                 ...
   E   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   |  Code         |   Length      |                               |
   S   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               :
   |   :                             Filter                            :
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record TTL                           |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |       EID-Prefix-AFI          |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-Prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      ...  
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record TTL                           |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |       EID-Prefix-AFI          |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-Prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure></t>

        <t>The description of the fields of the Map-Bulk-Reply is similar to
        those of a LISP Map-Request message (<xref target="RFC6830"></xref>),
        except the following:</t>

        <t><list style="symbols">
            <t>Type is to be defined. The same code is used for both
            Map-Bulk-Request and Map-Bulk-Reply.</t>

            <t>R bit: MUST be set to 1 for Map-Bulk-Reply messages.</t>

            <t>M (more-data bit): When set, this flag indicates that other
            records are to be expected from the Map-Resolver.</t>

            <t>rsv: reserved bits, MUST be sent as zeros and MUST be ignored
            when received.</t>

            <t>Records Count: Indicates the number of records included in the
            response.</t>

            <t>Result: indicates the result code of the processing of the
            Map-Bulk-Request message. The following codes are defined:<list
                style="hanging">
                <t hangText="0:">SUCCESS. This code indicates the request is
                successfully processed.</t>

                <t hangText="1:">BULK-PROHIBITED. This code indicates the bulk
                mapping is blocked for this ITR, leaf LISP network,
                subscriber, etc.</t>

                <t hangText="2:">BULK-LIMIT. This code indicates a rate-limit
                is applied on the Map-Bulk-Request messages from the same ITR,
                leaf LISP network, subscriber, etc. The ITR SHOULD re-issue
                the request after the expiry of a timer; the default value of
                that timer is 60 seconds. Other values may be configured on
                the ITR.</t>

                <t hangText="3:">OUT-OF-RESOURCES. This code indicates a
                Map-Resolver is running out of resources. The ITR SHOULD
                re-iterate the same request after the expiry of a timer. The
                default value of that timer is 300 seconds. Other values MAY
                be configured on the ITR.</t>
              </list></t>

            <t>Filter Count:</t>

            <t>Transaction ID: MUST echo the one included in the
            Map-Bulk-Request.</t>

            <t>Code: Filters that were not processed by the Map-Resolver are
            included. A filter MUST be included in a response if and only if
            an error was encountered when processing that filter at the
            Map-Resolver side. The code field provides more details about the
            reason for not processing such filter. If all filters were
            successfully processed by the Map-Resolver, this field MUST be set
            to 0. The following values are defined:<list style="hanging">
                <t hangText="0:">FILTER-UNSUPPORTED. This code indicates a
                request is successfully processed but this filter was not
                processed because the format of the filter is not
                supported.</t>

                <t hangText="1:">FILTER-BAD. This code indicates a request is
                successfully processed but the filter was not processed
                because it is malformed.</t>

                <t hangText="2:">FILTER-MAX. This code indicates a request is
                successfully processed but the filter was not processed
                because of a limit enforced on the maximum number of filters
                to be processed.</t>

                <t hangText="3:">FILTER-LOCAL. This code indicates a request
                is successfully processed but the filter was not processed
                because of local reasons. The ITR SHOULD, after a certain
                timer expires, send a Map-Bulk-Request message for the set of
                filters that are not processed with a reason code set to
                BULK-LOCAL.</t>
              </list></t>

            <t>Length: Indicates the length of a filter this is not processed
            by the Map-Resolver.</t>

            <t>Filter: Conveys a filter that is not processed by the
            Map-Resolver.</t>
          </list></t>
      </section>
    </section>

    <section anchor="gen" title="Generating a Map-Bulk-Request  Message">
      <t>ITRs MUST support a configurable parameter to enable/disable bulk
      mapping retrieval over TCP. The default value is set to "enabled".</t>

      <t>If distinct port number is used by remote Map-Resolvers, the
      destination port number to send Map-Bulk-Request messages SHOULD be
      configured to the ITR.</t>

      <t>After establishing a TCP connection towards a Map-Resolver (using the
      LISP service port), the ITR MUST send a Map-Bulk-Request (<xref
      target="mbr"></xref>) to a Map-Resolver. Configuration information for
      triggering bulk retrieval request messages MAY be provisioned to each
      ITR. Multiple Map-Bulk-Request messages may be sent over the same TCP
      connection.</t>

      <t>An ITR that loses its mapping cache for some reason SHOULD generate a
      Map-Bulk-Request message towards its Map-Resolver(s) with the set of
      filters that are configured locally.</t>

      <t>An ITR MAY generate several Map-Bulk-Request messages to the same or
      distinct Map-Resolvers.</t>

      <t>An ITR MUST generate a unique transaction-id per Map-Bulk-Request it
      issues.</t>

      <t>An ITR MUST expect that the Map-Resolver may limit the number of
      filters that may be processed. Filters that are not accepted or not
      processed by the Map-Resolvers are included in a Map-Bulk-Reply.</t>
    </section>

    <section title="Processing a Map-Bulk-Request Message">
      <t>A Map-Resolver that does not support the Map-Bulk-Request message
      MUST silently ignore any Map-Bulk-Request message it receives.</t>

      <t>Map-Resolvers MUST support a configurable parameter to enable/disable
      the processing of Map-Bulk-Request messages. The default value is set to
      "enabled".</t>

      <t>A Map-Resolver that is enabled to process Map-Bulk-Request messages
      MUST listen to incoming TCP connections on the default LISP service
      port. ACLs MAY be configured to control the leaf networks that can
      invoke this feature.</t>

      <t>A Map-Resolver SHOULD support a configuration parameter to rate-limit
      the number of simultaneous Map-Bulk-Request messages per leaf LISP
      network, per ITR, etc.</t>

      <t>If a Map-Resolver receives a Map-Bulk-Request message and it is
      enabled to process it, a Map-Resolver MUST reply with one or multiple
      Map-Bulk-Reply messages.</t>

      <t>If multiple Map-Bulk-Reply messages are required to respond to a
      given request, the Map-Resolver MUST:<list style="symbols">
          <t>Echo the transaction-id.</t>

          <t>Set to R-bit.</t>

          <t>Set the M-bit for all Map-Bulk-Reply messages, except for the
          last one.</t>

          <t>Include the set of filters that are not successfully processed
          for some reason (e.g., malformed filter) and set the "Filter Count"
          accordingly.</t>
        </list></t>

      <t>If filters are included in the request, the Map-Resolver MUST extract
      those filters and lookup its mapping system accordingly. In particular,
      the Map-Resolver MUST reply with a full mapping table if a Null filter
      is included in the Map-Bulk-Request.</t>

      <t>If bulk mapping retrieval is not allowed for a given ITR, the
      'Result' field MUST be set to BULK-PROHIBITED.</t>

      <t>If the Map-Resolver fails to process a request because limits for
      that ITR are exceeded, it MUST set the 'Result' field to BULK-LIMIT.</t>

      <t>If a subset of filters are successfully processed, the 'Result' field
      MUST be set to SUCCESS. The set of filters that are not processed MUST
      be echoed in the Map-Bulk-Reply; each with a failure code that reflects
      the reason why the filter was not applied. If a filter type is not
      supported by the Map-Resolver, the 'Code' field MUST be set to
      FILTER-UNSUPPORTED. If the Map-Resolver fails to process some of the
      filters included in a request because these filters were malformed, it
      MUST echo the corresponding filters in the Map-Bulk-Reply message and
      MUST set the 'Code' field to FILTER-BAD. f the Map-Resolver fails to
      process some of the filters included in a request because a maximum
      number of filters is supported, it MUST echo the corresponding filters
      in the Map-Bulk-Reply message and set the 'Code' field to FILTER-MAX.
      If, for some other reasons, the Map-Resolver fails to apply some filters
      included in a request, it MUST echo the corresponding filter in the
      Map-Bulk-Reply message. The 'Code' field MUST be set to
      FILTER-LOCAL.</t>

      <t>A Map-Resolver that is overloaded MUST reply with a Map-Bulk-Reply
      message with the "Result" code set to OUT-OF-RESOURCES.</t>
    </section>

    <section title="Processing a Map-Bulk-Reply Message">
      <t>Upon receipt of a Map-Bulk-Reply message, the ITR MUST check whether
      the message matches a Map-Bulk-Request it issued for the same
      Map-Resolver. If no matching state is found, the message MUST be
      silently dropped. If a state is found, the ITR MUST proceed as
      follows:<list style="symbols">
          <t>An ITR that receives the result code set to BULK-PROHIBITED MUST
          NOT reissue a Map-Bulk-Request message to that Map-Resolver.</t>

          <t>An ITR that receives the result code set to BULK-LIMIT MUST NOT
          try to resend the same request before the expiry of the
          retransmission timeout (default value set to 60 seconds).</t>

          <t>An ITR that receives the result code set to OUT-OF-RESOURCES MUST
          NOT resend the same request before 300 seconds.</t>

          <t>If the M-bit is set, it should expect that other Map-Bulk-Reply
          messages will be received from this Map-Resolver. Appropriate
          security mechanisms (e.g., Access Control Lists) SHOULD be activated
          to allow the processing of these incoming unsolicited Map-Bulk-Reply
          messages.</t>

          <t>If the M-bit is unset, this is an indication that this message
          terminates the mapping bulk retrieval transaction. The ITR may
          decide to terminate the underlying TCP connections if no other
          transactions bound to the same Map-Resolver are active.</t>

          <t>Filters that are returned in the Map-Bulk-Reply message may not
          be valid or have exceeded a limit. The "Code" field indicates the
          reason for not processing these filters. In particular:<list
              style="symbols">
              <t>An ITR that receives the 'Code' field set to FILTER-BAD or
              FILTER-UNSUPPORTED MUST NOT resend the same filters that were
              returned in the Map-Bulk-Reply message, in subsequent
              Map-Bulk-Request messages. Furthermore, subsequent
              Map-Bulk-Request messages MUST NOT use the unsupported format to
              encode the filters.</t>

              <t>An ITR that receives the 'Code' field set to FILTER-MAX
              SHOULD issue another Map-Bulk-Request message with the filters
              that were returned in the Map-Bulk-Reply message with this
              code.</t>

              <t>An ITR that receives the 'Code' field set to FILTER-LOCAL
              SHOULD for at least 60 seconds before issuing another
              Map-Bulk-Request message with the filters that were returned in
              the Map-Bulk-Reply message with this code.</t>
            </list></t>
        </list></t>

      <t></t>
    </section>

    <section title="Bulk Mapping Retrival from Multiple Resolvers">
      <t>In order to retrieve mapping entries from multiple Map-Resolvers, an
      ITR issues Map-Bulk-Request messages to a list of Map-Resolvers. Each of
      these requests is handled as specified in <xref
      target="gen"></xref>.</t>

      <t>An ITR MAY be configured to issue multiple Map-Bulk-Request messages
      to distinct Map-Resolvers.</t>

      <t>Conflicts may arise when contacting multiple Map-Resolvers. These
      conflicts are not specific to the bulk mapping retrieval as this is also
      an issue for individual mapping lookup.</t>
    </section>

    <section title="Sample Examples">
      <t><xref target="retrieval1"></xref> illustrates the example of a bulk
      mapping retrieval that is achieved with one single Map-Bulk-Reply, while
      <xref target="retrieval2"></xref> shows an example of a bulk mapping
      retrieval that requires multiple Map-Bulk-Reply messages.</t>

      <t><figure anchor="retrieval1" title="Example of Bulk Mapping Retrieval">
          <artwork align="center"><![CDATA[    +--------+                  +--------+
    |  ITR   |                  |   MR   |
    +--------+                  +--------+
         |<- Session Establishment--->|
         |                            |
         |Map-Bulk-Request (ID, d_EID |
         | d_EID2, ..., d_EIDn)       |
         |--------------------------->|
         |      Map-Bulk-Reply(M=0)   |
         |<---------------------------|                  
]]></artwork>
        </figure></t>

      <t><figure anchor="retrieval2" title="Example of Bulk Mapping Retrieval">
          <artwork align="center"><![CDATA[    +--------+                  +--------+
    |  ITR   |                  |   MR   |
    +--------+                  +--------+
         |<- Session Establishment -->|
         |                            |
         |Map-Bulk-Request (ID, d_EID |
         | d_EID2, ..., d_EIDn)       |
         |--------------------------->|
         |Map-Bulk-Reply(M=1, rec1,   |
         |            rec2, ..., recn)|
         |<---------------------------| 
         |Map-Bulk-Reply(M=1,recn+1   |
         |          recn+2, ..., recm)|
         |<---------------------------| 
                      ...
         |Map-Bulk-Reply(M=0, recs)   |
         |<---------------------------| 
                 
]]></artwork>
        </figure>The bulk mapping retrieval allows to retrieve records that do
      not only match IP prefixes, but also AS numbers or even names. When
      names or AS numbers are included, the Map-Resolver is responsible for
      identifying which IP prefixes are to be returned.</t>

      <t>An ITR can establish multiple transactions with the same Map-Resolver
      as shown in <xref target="retrieval3"></xref>.</t>

      <t><figure anchor="retrieval3"
          title="Multiple Transactions with the Same Map-Resolver">
          <artwork align="center"><![CDATA[    +--------+                  +--------+      
    |  ITR   |                  |   MR   |     
    +--------+                  +--------+
         |<- Session Establishment -->|
         |                            |
         |Map-Bulk-Request (ID1)      |
         |--------------------------->|
         |      Map-Bulk-Reply(ID1)   |
         |<---------------------------|
                      ...
         |Map-Bulk-Request (ID2)      |
         |--------------------------->|
         |      Map-Bulk-Reply(ID2)   |
         |<---------------------------|
         |      Map-Bulk-Reply(ID2)   |
         |<---------------------------|
                      ...
         |Map-Bulk-Request (IDa)      |
         |--------------------------->|
         |Map-Bulk-Request (IDb)      |
         |--------------------------->|
         |      Map-Bulk-Reply(IDa)   |
         |<---------------------------|
         |      Map-Bulk-Reply(IDb)   |
         |<---------------------------|
         |      Map-Bulk-Reply(IDb)   |
         |<---------------------------|
         |      Map-Bulk-Reply(IDa)   |
         |<---------------------------|
                 
]]></artwork>
        </figure></t>
    </section>

    <section title="Security Considerations">
      <t>In addition to the security considerations discussed in <xref
      target="RFC6830"></xref> and <xref target="RFC6833"></xref>,
      TCP-specific threats are valid for this specification (e.g., <xref
      target="I-D.ietf-tcpm-tcp-security"></xref>).</t>

      <t>In order to avoid exhausting the resources of Map-Resolvers,
      Map-Bulk-Request messages SHOULD be rate-limited. Furthermore, a
      Map-Resolver MAY configure ACLs to control leaf LISP networks that are
      allowed to issue Map-Bulk-Request messages.</t>

      <t>The structure of a record conveyed in a Map-Bulk-Reply is exactly the
      same as in <xref target="RFC6830"></xref>. As such, this specification
      does leak information that would not be revealed using the base
      LISP.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>IANA has assigned this LISP Shared Extension Message Type Sub-type
      (<xref target="RFC8113"></xref>) for this registry
      https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml#lisp-shared-extension-message-type-sub-types:</t>

      <t><figure>
          <artwork><![CDATA[Message                           Sub-type    Reference
================================= =======     ===============
Map-Bulk-Request/Map-Bulk-Reply    1025        [This document]]]></artwork>
        </figure></t>
    </section>

    <section title="Acknowledgments">
      <t>This work is partly funded by ANR LISP-Lab project
      #ANR-13-INFR-009-X.</t>

      <t>Many thanks to S. Secci and Chi Dung Phung for the comments.</t>
    </section>
  </middle>

  <back>
    <references title="Normative references">
      <?rfc include='reference.RFC.6830'
?>

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

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

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

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

      <?rfc include='reference.RFC.8113'?>
    </references>

    <references title="Informative references">
      <?rfc include='reference.I-D.ietf-tcpm-tcp-security'?>

      <?rfc include='reference.I-D.boucadair-lisp-multiple-records'?>

      <?rfc include='reference.I-D.kouvelas-lisp-map-server-reliable-transport'?>
    </references>
  </back>
</rfc>
