<?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="exp" docName="draft-boucadair-lisp-idr-ms-discovery-01"
     ipr="trust200902">
  <front>
    <title abbrev="Mapping Service Discovery">LISP Mapping Service Discovery
    at Large</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="" month="" year="" />

    <area>Internet</area>

    <keyword>IPv4 service continuity</keyword>

    <keyword>IPv4 address exhaustion</keyword>

    <keyword>Service Availability</keyword>

    <keyword>Address sharing</keyword>

    <keyword>IPv6</keyword>

    <keyword>Reliability</keyword>

    <keyword>IPv4 over IPv6</keyword>

    <abstract>
      <t>Locator/ID Separation Protocol (LISP) 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 and Map-Server entities that provide such mapping
      services is meant to facilitate global LISP operation (automatic
      discovery of Map-Resolvers and Map-Servers).</t>

      <t>This document specifies a BGP Extended Communities attribute that can
      be used to dynamically discover LISP Mapping Systems of different
      domains.</t>
    </abstract>

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

  <middle>
    <section title="Introduction">
      <t>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 and
      Map-Server entities that provide such mapping services is meant to
      facilitate global LISP operation (automatic discovery of Map-Resolvers
      and Map-Servers).</t>

      <t>Within this document, a Mapping System provides the LISP mapping
      service <xref target="RFC6833"></xref>. Map-Resolvers, Map-Servers, and
      other components may be part of a Mapping System such as authorization,
      subscription profiles, etc. These components are considered as black
      boxes; only the external behavior of the Mapping System is in scope.</t>

      <t>Distinct LISP mapping systems may emerge if LISP users or network
      operators who solicit or manage the Mapping System want to avoid some
      region-centric systems, for example, or if they want to position
      themselves as a core provider of the Mapping System. The lack of clear
      policies of the management and operation of the LISP Mapping Systems may
      encourage such practices.</t>

      <t>This document assumes a hierarchy in the Mapping System organisation
      for business, governance, control, and regulatory purposes in
      particular. In such contexts, the document assumes that a Mapping System
      may maintain a portion of or a global mapping table.</t>

      <t>Because of its experimental nature of LISP and the various platforms
      LISP operation relies upon (like the platforms used by the LISP mapping
      systems) should encourage innovation by testing new services that may
      take advantage of LISP in inter-domain deployment scenarios without
      requiring the participation of all LISP-enabled domains. Such approach
      is also meant to avoid any risk of freezing LISP developments.</t>

      <t>Because the design and operation of a consistent Mapping System is
      critical for the adoption of LISP at large scale, this document
      advocates for means to dynamically discover other Mapping Systems that
      are open to cooperate in inter-domain LISP deployment scenarios,
      typically .</t>

      <t>Deploying LISP for inter-domain use cases may raise the following
      issues:</t>

      <t><list style="hanging">
          <t hangText="Issue#1: ">A LISP domain may need to discover available
          Mapping Systems so that it can rely upon them to extend the
          reachability scope.</t>

          <t hangText="Issue#2: ">Various Mapping Systems can be deployed over
          the Internet. These Mapping Systems need to interconnect to extend
          the reachability scope and avoid pressure on PTR (Proxy Tunnel
          Router) devices. Also, various Mapping Systems encourage the
          enforcement of policies that aim at optimizing LISP forwarding: for
          example, policies that consist in avoiding the solicitation of
          specific domains/ASes.</t>

          <t hangText="Issue#3: ">Distinct flavors of Mapping Systems may be
          deployed. These mappings may not rely on the same database mapping
          system (e.g., NERD, ALT, CONS, etc.). As such, a clear interface to
          ease interconnection between these realms is needed. Standard
          solutions to discover Mapping Systems capabilities are likely to
          ease the interconnection of Mapping Systems.</t>

          <t hangText="Issue#4: ">Security concerns may arise during the
          discovery of the available Mapping Systems: for example, a given
          Mapping System may deny access from another domain, or available
          Mapping Systems need to make sure that they are entitled to exchange
          information with one another or that an xTR of a given LISP network
          is entitled to solicit a mapping system of another LISP network,
          etc.</t>
        </list></t>

      <t>An efficient and scalable deployment of LISP within an inter-domain
      context for traffic engineering purposes, in particular, relies heavily
      on the availability of an inter-domain mapping system that spans several
      domains. From this perspective, the success of a global LISP adoption
      and deployment will mainly depend on how LISP-enabled domains will graft
      to existing mapping systems that can guarantee a global reachability
      scope. To minimize the risk of a fragmented Mapping System that would
      jeopardize the overall efficiency of an inter-domain LISP routing
      system, there is a need to encourage and facilitate the coordination of
      participating Mapping Systems.</t>

      <t>This document relies on extended BGP communities <xref
      target="RFC4360"></xref> to advertise that a given domain supports the
      LISP Mapping Service. A contact IPv4 address and/or IPv6 address are
      also included in the attribute so that remote LISP Mapping Systems or
      LISP domains may initiate negotiation cycles for the sake of LISP
      Mapping System Interconnection or subscription to the Mapping Service
      offered by that Mapping System.</t>

      <t><xref target="att"></xref> specifies a solution for the discovery of
      LISP Mapping Systems that are deployed in distinct administrative
      domains. This BGP-based solution assumes that domains that support a
      LISP Mapping Service will use the BGP Extended Communities attribute to
      inform other domains about the support of the service. EIDs that can be
      serviced with LISP will be tagged accordingly. Note that an EID can be
      serviced by multiple Mapping Systems. Remote LISP Mapping Systems will
      rely upon that BGP-based advertising capability to discover the
      existence and the status of other Mapping Systems. Once a Mapping System
      is discovered, a local Mapping System can establish an interconnection
      agreement with that remote Mapping System. The contact IP address
      provided as part of the BGP Extended Communities attribute will be used
      to contact a remote Mapping System to request for further LISP-related
      capabilities, possibly negotiate an interconnection agreement and,
      consequently, extend the scope of the networks that can be serviced
      using LISP. Also, leaf LISP-aware networks can rely upon the information
      carried in the BGP Extended Communities attribute to discover Mapping
      Systems that may be solicited to invoke their mapping service.
      Subscription cycles may then be considered. </t>
    </section>

    <section title="Rationale">
      <t>This document focuses on the discovery of LISP Mapping Systems that
      are deployed in distinct administrative domains.</t>

      <t>The rationale is as follows:<list style="numbers">
          <t>Announce: Domains that support a LISP Mapping Service will use
          the BGP Extended Communities attribute (<xref target="att"></xref>)
          to inform other domains about the support of the service. EIDs that
          can be serviced with LISP can be tagged accordingly. Note that an
          EID can be serviced by multiple Mapping Systems.</t>

          <t>Discover: Remote LISP Mapping Systems will rely upon that
          BGP-based advertising capability (<xref target="att"></xref>) to
          discover the existence of other Mapping Systems.</t>

          <t>Negotiate/Interconnect/Invoke: The contact IP address provided as
          part of the BGP Extended Communities attribute (<xref
          target="att"></xref>) will be used to contact a remote Mapping
          System to request for further LISP-related capabilities, possibly
          negotiate an interconnection agreement and, consequently, extend the
          scope of the networks that can be serviced using LISP.</t>

          <t>Negotiate/Subscribe/Invoke: Also, leaf LISP-aware networks can
          rely upon the information carried in the BGP Extended Communities
          attribute to discover Mapping Systems that may be solicited to
          invoke their mapping service. Subscription cycles may then be
          considered.</t>
        </list></t>

      <t>Only the first two steps are in scope of this document; the remaining
      steps can be achieved by other means such as <xref
      target="I-D.boucadair-connectivity-provisioning-protocol"></xref>.</t>
    </section>

    <section anchor="att"
             title="LISP Mapping System Target BGP Extended Community">
      <t>The LISP Mapping System Target Community identifies one or more
      Mapping System contact points that can receive mapping system
      interconnect and/or subscription requests. These contact points are
      identified with IPv4 and/or IPv6 addresses.</t>

      <t>The LISP Mapping System Target Community is of an extended type. As
      such, the behavior specified in Section 6 of <xref
      target="RFC4360"></xref> applies to the LISP Mapping System Target
      Community.</t>

      <t>The presence of this community is an explicit indication that
      associated networks can be managed by a LISP Mapping System that is
      reachable at the addresses carried in the attribute.</t>

      <t>This document reuses the Transitive IPv4-Address-Specific Extended
      Community <xref target="RFC4360"></xref> and Transitive
      IPv6-Address-Specific Extended Community <xref target="RFC5701"></xref>
      for the purpose of this document. Dedicated sub-types are to be
      allocated (see <xref target="iana"></xref>).</t>

      <t>The Global Administrator field MUST be set to an IP address of the
      Mapping System. This address MUST be configured on the originating BGP
      speaker.</t>

      <t>The "Local Administrator" field of the LISP Mapping System Target
      Community is used to encode an identifier of the Mapping System.
      Considerations about the assignment of globally unique identifiers to
      LISP Mapping Systems are out of scope. A configurable parameter may be
      supported by BGP implementations to provide the value carried in the
      "Local Administrator" field. If no identifier is configured on the
      originating BGP speaker, the "Local Administrator" field MUST be set to
      0.</t>
    </section>

    <section title="Security Considerations">
      <t>This document does not introduce any additional security issues other
      than those discussed in <xref target="RFC4360"></xref> and <xref
      target="RFC5701"></xref>.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>According to <xref target="RFC7153"></xref>, this document requests
      the assignment of a sub-type in the "0x00-0xbf" range from the
      Transitive IPv4-Address-Specific Extended Community Sub-Types registry
      available at
      http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xml#trans-ipv4:</t>

      <t><figure>
          <artwork><![CDATA[Type Value     Name                        Reference 
    TBA        LISP Mapping System Target  [This-Document]]]></artwork>
        </figure></t>

      <t>Also, this document requests the assignment of a sub-type from the
      Transitive IPv6-Address-Specific Extended Community Types registry
      available at
      http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xml#trans-ipv6:</t>

      <t><figure>
          <artwork><![CDATA[Type Value     Name                        Reference 
    TBA        LISP Mapping System Target  [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>
    </section>
  </middle>

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

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

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

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

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

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

      <?rfc include='reference.I-D.boucadair-connectivity-provisioning-protocol'?>
    </references>
  </back>
</rfc>
