<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-boucadair-lisp-function-discovery-03"
     ipr="trust200902">
  <front>
    <title abbrev="Service Function Discovery">LISP Mapping Service Functions
    Discovery (LMSFD) using OSPF</title>

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

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

          <city>Rennes</city>

          <region></region>

          <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>

          <region></region>

          <code>35000</code>

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

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

    <date day="" month="" year="" />

    <abstract>
      <t>This document specifies extensions to the Open Shortest Path First
      (OSPF) protocol for the discovery of Locator/ID Separation Protocol
      (LISP) Mapping Service functions, especially the Map-Resolver (MR) and
      Map-Server (MS) LISP components.</t>
    </abstract>

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

  <middle>
    <section anchor="introduction" 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. The ability of dynamically discovering the Map-Resolver (MR)
      and Map-Server (MS) entities that provide such mapping services is meant
      to facilitate global LISP operation (automatic discovery of
      Map-Resolvers and Map-Servers).</t>

      <t>The dynamically-acquired information will not only be used by xTR
      routers but also by management platforms (e.g., a service controller, a
      network manager, etc.) to forward traffic over the LISP network or to
      get an up-to-date view of the global LISP network topology, including
      the location of the resolvers and servers. For example, ETRs will
      register in all instances that are reachable in a given domain.</t>

      <t>The ability to dynamically discover LISP mapping component
      information and update such information as appropriate is also useful to
      ease state synchronization among the various Mapping Service Functions
      that can be solicited in the LISP network, especially whenever a new MS
      joins the LISP Mapping System. This specification allows the
      following:</t>

      <t><list style="numbers">
          <t>Ease the introduction of new MS servers: Additional MS instances
          may be added to a Mapping Service domain. New MSes need to build an
          updated mapping database to avoid service disruption. Owing to the
          mechanism defined in this document, <list style="symbols">
              <t>Peer MSes can be discovered by a new MS, thereby triggering a
              state synchronisation procedure. How state synchronisation is
              achieved is out of scope of this document.</t>

              <t>xTRs can immediately send registration messages to the new
              MS.</t>
            </list><vspace blankLines="1" /><xref target="RFC7215"></xref>
          indicates that, "for some LISP sites, there is a need for mechanisms
          to dynamically obtain the address of the Map-Server in the ETR of
          the AS".</t>

          <t>Minimize service disruption when multiple MS/MRs are available:
          this specification allows to disseminate information that will drive
          the selection process undertaken by an xTR to select an MS/MR and
          solicit it. For example, MRs with empty databases will be avoided;
          "ready-to-serve" MRs will be solicited instead. Map-Register
          requests can thus be sent to multiple MSes whenever needed. When a
          Mapping Service function loses its state, an explicit message can be
          generated accordingly so that xTRs (and also management platforms)
          can trigger appropriate actions.</t>
        </list></t>

      <t>This document specifies a means to dynamically discover Map-Resolver
      and Map-Server instances of a LISP network within a domain. Also, it
      introduces some features to enhance the serviceability of LISP (e.g.,
      detect that a MS lost its state so that a registration procedure is
      triggered immediately, inform an xTR that a MS/MR instance is about to
      be unavailable for some reason, indicate the synchronisation status of
      the mapping database, etc.).</t>

      <t>The document exclusively focuses on the dynamic information
      discovery; how this information is actually used by an xTR to infer its
      MS/MR selection procedures is out of the scope.</t>

      <t>The reader should be familiar with the terms defined in <xref
      target="RFC6833"></xref>.</t>
    </section>

    <section title="Overview">
      <t>This document defines extensions to OSPFv2 <xref
      target="RFC2328"></xref> and OSPFv3 <xref target="RFC5340"></xref> so
      that routers of the OSPF routing domain (a single area or the entire
      routing domain) can advertise a Mapping Service Function within the
      domain, along with some other useful information. To do so, a new TLV
      (named the LISP Mapping Service Function Discovery TLV (LMSFD TLV)) is
      used to announce LISP MR and MS information. This TLV is carried by the
      OSPF Router Information LSA <xref target="RFC7770"></xref>.</t>

      <t>The location of each Mapping Service Function is then flooded into an
      OSPF area or the whole OSPF routing domain (in the case the LSA is
      AS-scoped). The xTR routers deployed within the OSPF domain must listen
      to the flooding messages sent by active Mapping Service Function
      instances. Such messages are referred to "Mapping Service Discovery"
      messages in this document.</t>

      <t>The information to be announced by means of the LMSFD TLV carried in
      the Router Information LSA during the LISP Mapping Service Function
      Discovery procedure includes (but is not necessarily limited to):</t>

      <t><list style="symbols">
          <t>Mapping Service Function type: Indicates whether the MSF acts as
          Map-Resolver (MR), Map-Server (MS), or both.</t>

          <t>Mapping Service Function Service locator(s): Includes one or
          several IPv4 addresses, one or several IPv6 addresses or a
          combination thereof. This information lists the set of locators that
          unambiguously indicate where the Mapping Service Function can be
          reached. The locator information must be included in the Mapping
          Service Function Discovery messages.</t>

          <t>Mapping Service Function unavailability timer: Indicates the time
          when the Mapping Service Function will be unavailable. This
          parameter can be used for planned maintenance operations, for
          instance. This parameter does not provide any indication about when
          the Mapping Service Function instance will be available again. This
          information is optional and may therefore be included in the Mapping
          Service Function Discovery messages.</t>

          <t>Mapping Service Function reboot timer: Operational teams often
          proceed with a reboot of the devices deployed in the network, within
          the context of major software upgrade campaigns, for example. This
          timer is used to indicate that a Mapping Service Function will be
          unavailable during the reboot of the device that supports the
          function. Unlike the previous timer, this timer is used to indicate
          that the Mapping Service Function will be available immediately
          after the reboot of the device that supports this function is
          completed. This information is optional and may therefore be
          included in the Mapping Service Function Discovery messages.</t>

          <t>Mapping Service Function Diagnosis: Indicates whether this
          Mapping Service Function instance supports a diagnostic mechanism.
          This information is optional and may therefore be included in the
          Mapping Service Function Discovery messages.</t>

          <t>Mapping Service Status: Provides information about the status of
          the mapping database. In particular, it indicates whether the
          database is empty, synchronized with other MS servers located in the
          same OSPF domain, etc. This information is optional and may
          therefore be included in the Mapping Service Function Discovery
          messages.</t>

          <t>Mapping Service Function Status: Indicates the status of the
          Mapping Service Function Instance (enabled, disabled). This
          information is optional and may therefore be included in the LMSFD
          messages.</t>

          <t>Additional capabilities such as the support of mapping bulk
          retrieval <xref target="I-D.boucadair-lisp-bulk"></xref> or
          notifications <xref target="I-D.boucadair-lisp-subscribe"></xref>
          may be advertised.</t>
        </list></t>
    </section>

    <section title="Mapping Service Function Discovery (MSFD) TLV">
      <t>The format of the OSPF Mapping Service Function Discovery TLV (LMSFD
      TLV, <xref target="tlv"></xref>) and its sub-TLVs use the same TLV
      format as in the Traffic Engineering Extensions to OSPF <xref
      target="RFC3630"></xref>.</t>

      <t><figure anchor="tlv">
          <artwork><![CDATA[                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                            sub-TLVs                           :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>The description of the fields is as follows:<list
          style="symbols">
          <t>Type: To be assigned by IANA (see <xref
          target="iana"></xref>).</t>

          <t>Length: Variable (octets).</t>

          <t>sub-TLVs: Includes the list of sub-TLVs. The following sub-TLVs
          are defined in this document:</t>
        </list></t>

      <figure>
        <artwork><![CDATA[Sub-TLV type  Length               Name
      1         1      MSF-TYPE sub-TLV
      2      variable  MSF-LOCATOR sub-TLV
      3      variable  MSF-DESCRIPTION sub-TLV
      4        4       MSF-EPOCH sub-TLV
      5        4       MSF-UNAVAILABILITY-TIMER sub-TLV
      6        4       MSF-REBOOT-TIMER sub-TLV
      7        1       MSF-DIAGNOSIS sub-TLV
      8        4       MS-STATUS sub-TLV
      9        4       MSF-STATUS sub-TLV
]]></artwork>
      </figure>

      <t></t>

      <t>The MSF-TYPE and MSF-LOCATOR sub-TLVs MUST always be present within
      the LMSFD TLV. Additional optional sub-TLVs MAY be included.</t>

      <section title="MSF-TYPE sub-TLV">
        <t>The format of MSF-TYPE sub-TLV is shown in <xref
        target="ty"></xref>.</t>

        <t><figure anchor="ty" title="MSF-TYPE sub-TLV">
            <artwork><![CDATA[                        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         |        Length=4               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type                |        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The current type values are defined: 
   0: Map-Server
   1: Map-Resolver
   2: Both
]]></artwork>
          </figure></t>
      </section>

      <section title="MSF-LOCATOR sub-TLV">
        <t>The format of MSF-LOCATOR sub-TLV is shown in <xref
        target="loc"></xref>.</t>

        <t><figure anchor="loc" title="MSF-LOCATOR sub-TLV">
            <artwork><![CDATA[                        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 = 2         |        Length=Variable        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                         IPv4 or IPv6 address                  :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>The MSF-LOCATOR sub-TLV MAY appear twice, especially when
        the SF can be reached via either an IPv4 or an IPv6 address or both.
        It MAY also appear more than once for the same address family if the
        Service Function is assigned several addresses of the same family.</t>
      </section>

      <section title="MSF-DESCRIPTION sub-TLV">
        <t>The format of MSF-DESCRIPTION sub-TLV is shown in <xref
        target="des"></xref>.<figure anchor="des"
            title="MSF-DESCRIPTION sub-TLV">
            <artwork><![CDATA[                        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 = 3         |        Length=Variable        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                         Description                           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>

        <t>When present, the MSF-DESCRIPTION sub-TLV MUST carry UTF-8 encoded
        <xref target="RFC3629"></xref> description text. The description text
        SHOULD NOT be null terminated.</t>
      </section>

      <section title="MSF-EPOCH sub-TLV">
        <t>The format of MSF-EPOCH sub-TLV is shown in <xref
        target="epo"></xref>.<figure anchor="epo" title="MSF-EPOCH sub-TLV">
            <artwork><![CDATA[                        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 = 4         |             Length=4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Value (seconds)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>

        <t>When a Mapping Service Function loses its state (e.g., power
        failure, bug, reset by an administrator, etc.), it may use this
        sub-TLV with a value set to 0. This value is then incremented by
        one.</t>

        <t>If the value field of the MSF-EPOCH sub-TLV is set to 0, it
        indicates that the Mapping Service Function instance has been reset or
        lost its state. This information is particularly important for ETRs so
        that they can send their registration request immediately.</t>

        <t>Receivers may maintain a record of transmitted values to detect
        anomalies in the Mapping Service Function.</t>
      </section>

      <section title="MSF-UNAVAILABILITY-TIMER sub-TLV">
        <t>The format of MSF-UNAVAILABILITY-TIMER sub-TLV is shown in <xref
        target="un"></xref>.<figure anchor="un"
            title="MSF-UNAVAILABILITY-TIMER sub-TLV">
            <artwork><![CDATA[                        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 = 5         |             Length=4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Timer (seconds)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>

        <t>The MSF-UNAVAILABILITY-TIMER sub-TLV indicates, in seconds, when
        the Mapping Service Function instance will be unavailable.</t>

        <t>If the value field of the MSF-UNAVAILABILITY-TIMER sub-TLV is set
        to 0, it indicates the Mapping Service Function instance will be
        unavailable immediately.</t>
      </section>

      <section title="MSF-REBOOT-TIMER sub-TLV">
        <t>The format of MSF-REBOOT-TIMER sub-TLV is shown in <xref
        target="reb"></xref>.<figure anchor="reb"
            title="MSF-REBOOT-TIMER sub-TLV">
            <artwork><![CDATA[                        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 = 6         |             Length=4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Timer (seconds)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>

        <t>The MSF-REBOOT-TIMER sub-TLV indicates, in seconds, when the
        Mapping Service Function instance will start to reboot. The function
        will be operational right after the reboot is completed.</t>
      </section>

      <section title="MSF-DIAGNOSIS sub-TLV">
        <t>The format of MSF-DIAGNOSIS sub-TLV is shown in <xref
        target="diag"></xref>.</t>

        <t><figure anchor="diag" title="MSF-DIAGNOSIS sub-TLV">
            <artwork><![CDATA[                        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 = 7         |             Length=0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>The presence of this sub-TLV indicates that the Mapping
        Service Function supports diagnostic functions.</t>
      </section>

      <section title="MS-STATUS sub-TLV">
        <t>The format of MS-STATUS sub-TLV is shown in <xref
        target="stat"></xref></t>

        <figure anchor="stat" title="MS-STATUS sub-TLV">
          <artwork><![CDATA[                    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 = 8         |        Length=4               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Status              |        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The current Status values are defined: 
      0: Reset
      1: Partial
      2: Synchronized
]]></artwork>
        </figure>

        <t></t>

        <t>The presence of this sub-TLV indicates the status of the Mapping
        Service database. This is important for influencing the selection
        process of Map-Resolvers, in particular.</t>
      </section>

      <section title="MSF-STATUS sub-TLV">
        <t>The format of MSF-STATUS sub-TLV is shown in <xref
        target="msfs"></xref></t>

        <figure anchor="msfs" title="MSF-STATUS sub-TLV">
          <artwork><![CDATA[                    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 = 9         |        Length=4               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Status              |        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The current Status values are defined: 
       0: Enabled
       1: Disabled]]></artwork>
        </figure>

        <t>The presence of this sub-TLV indicates the status of Mapping
        Service Function.</t>

        <t>The presence of this sub-TLV is particularly useful to indicate
        that a given instance is disabled.</t>
      </section>
    </section>

    <section title="Mapping Service Reachability Information">
      <t>This document assumes that Mapping Service Reachability information
      can be injected into OSPF by a router that embeds a Mapping Service
      Function instance, or which has been instructed (by means of specific
      configuration tasks, for example) to advertise such information on
      behalf of a third party Mapping Service Function.</t>

      <t>The mechanism defined in this document may be used to advertise and
      learn Mapping Service Functions that are available in the same
      administrative domain than xTRs. Also, it can be used to dynamically
      advertise related reachability information that is learned using other
      means when the Mapping Service Functions and xTRs do not belong to the
      same administrative entity.</t>

      <t>Some of the information carried in the LMSFD TLV may be automatically
      set by an OSPF speaker while other may be explicitly configured.</t>
    </section>

    <section title="OSPF Operation">
      <t>The LMSFD TLV is advertised within OSPFv2 or OSPFv3 Router
      Information LSAs <xref target="RFC7770"></xref>.</t>

      <t>A change in the operational status of a Mapping Service Function
      instance (e.g., enabled, disabled) MUST trigger the generation of a
      Router Information LSA that carries the LMSFD TLV with the updated
      information.</t>

      <t>The flooding scope is defined by the Opaque LSA type for OSPFv2 <xref
      target="RFC5250"></xref>, and by the S1/S2 bits for OSPFv3 <xref
      target="RFC5340"></xref>.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>The extensions defined in this document do not introduce any
      additional security threats than those already documented in the current
      OSPF protocol specifications.</t>

      <t>OSPF does not support any encryption mechanism for protecting the
      integrity of Mapping Service Function discovery information. Means such
      as <xref target="RFC2154"></xref> may be enabled.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document requests IANA to assign a Router Information TLV type
      for the LISP Mapping Service Discovery Function (LMSFD) TLV.</t>
    </section>

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

      <t>Thanks to Liu Xiang for the comments.</t>
    </section>
  </middle>

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

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

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

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

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

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

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

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

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

    <references title="Informative References">
      <?rfc include='reference.RFC.2154'?>

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

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

      <?rfc include='reference.I-D.boucadair-lisp-subscribe'?>
    </references>
  </back>
</rfc>
