Network Working Group | M. Boucadair |
Internet-Draft | C. Jacquenet |
Intended status: Experimental | France Telecom |
Expires: March 19, 2016 | September 16, 2015 |
LISP Mapping Service Discovery at Large
draft-boucadair-lisp-idr-ms-discovery-00
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).
This document specifies a BGP Extended Communities attribute that can be used to dynamically discover LISP Mappig Systems of different domains.
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 RFC 2119 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 19, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Locator/ID Separation Protocol (LISP, [RFC6830] ) 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).
Within this document, a Mapping System provides the LISP Mapping service [RFC6833]. 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.
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.
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.
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.
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 .
Deploying LISP for inter-domain use cases may raise the following issues:
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.
This document relies on extended BGP communities [RFC4360] 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.
This document focuses on the discovery of LISP Mapping Systems that are deployed in distinct administrative domains.
The rationale is as follows:
Only the first two steps are in scope of this document; the remaining steps can be achieved by other means such as [I-D.boucadair-connectivity-provisioning-protocol].
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.
The LISP Mapping System Target Community is of an extended type. As such, the behavior specified in section 6 of [RFC4360] applies to the LISP Mapping System Target Community.
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.
This document reuses the Transitive IPv4-Address-Specific Extended Community [RFC4360] and Transitive IPv6-Address-Specific Extended Community [RFC5701] for the purpose of this document. Dedicated sub-types are to be allocated (see Section 5).
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.
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.
This document does not introduce any additional security issues other than those discussed in [RFC4360][RFC5701].
According to [RFC7153], 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
Type Value Name Reference TBA LISP Mapping System Target [This-Document]
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
Type Value Name Reference TBA LISP Mapping System Target [This-Document]
This work is partly funded by ANR LISP-Lab project #ANR-13-INFR-009-X.
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
[RFC4360] | Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006. |
[RFC5701] | Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009. |
[RFC6830] | Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013. |
[RFC7153] | Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014. |
[I-D.boucadair-connectivity-provisioning-protocol] | Boucadair, M., Jacquenet, C., Zhang, D. and P. Georgatsos, "Connectivity Provisioning Negotiation Protocol (CPNP)", Internet-Draft draft-boucadair-connectivity-provisioning-protocol-10, September 2015. |
[RFC6833] | Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013. |