One document matched: draft-boucadair-lisp-idr-ms-discovery-00.xml
<?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-00"
ipr="trust200902">
<front>
<title abbrev="Mapping Service Discovery">LISP Mapping Service Discovery
at Large</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</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>France Telecom</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 Mappig 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>Also, 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 the LISP protocol 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 LISP mapping system
is critical for the adoption of the protocol 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 those mapping systems 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.</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 mpping system of another LISP network,
etc.</t>
</list></t>
<t>The global objective of this effort is to encourage the deployment
and the operation of a global Mapping System at the scale of the
Internet instead of a fragmented mapping system.</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>
</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 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 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 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 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><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>
| PAFTECH AB 2003-2026 | 2026-04-24 05:44:06 |