--- 1/draft-ietf-lisp-eid-block-mgmnt-03.txt 2014-12-31 09:14:50.080702235 -0800 +++ 2/draft-ietf-lisp-eid-block-mgmnt-04.txt 2014-12-31 09:14:50.104702823 -0800 @@ -1,81 +1,82 @@ Network Working Group L. Iannone Internet-Draft Telecom ParisTech Intended status: Informational R. Jorgensen -Expires: April 27, 2015 Bredbandsfylket Troms +Expires: July 4, 2015 Bredbandsfylket Troms D. Conrad Virtualized, LLC G. Huston - APNIC - Asia Pacific Network Information Center - October 24, 2014 + APNIC - Asia Pacific Network + Information Center + December 31, 2014 LISP EID Block Management Guidelines - draft-ietf-lisp-eid-block-mgmnt-03.txt + draft-ietf-lisp-eid-block-mgmnt-04.txt Abstract This document proposes a framework for the management of the LISP EID Prefix. The framework described relies on hierarchical distribution of the address space, granting temporary usage of sub-prefixes of such space to requesting organizations. -Status of This Memo +Status of this Memo 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 April 27, 2015. + This Internet-Draft will expire on July 4, 2015. Copyright Notice Copyright (c) 2014 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. Table of Contents - 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 - 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 - 4. EID Prefix Registration Policy . . . . . . . . . . . . . . . 3 - 5. EID Prefixes Registration Requirements . . . . . . . . . . . 4 - 6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 4 - 7. Policy Validity Period . . . . . . . . . . . . . . . . . . . 6 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. EID Prefix Registration Policy . . . . . . . . . . . . . . . . 3 + 5. EID Prefixes Registration Requirements . . . . . . . . . . . . 4 + 6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 5 + 7. Policy Validity Period . . . . . . . . . . . . . . . . . . . . 6 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 - 11.2. Informative References . . . . . . . . . . . . . . . . . 7 - Appendix A. LISP Terms . . . . . . . . . . . . . . . . . . . . . 8 - Appendix B. Document Change Log . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 11.2. Informative References . . . . . . . . . . . . . . . . . 8 + Appendix A. LISP Terms . . . . . . . . . . . . . . . . . . . . . 9 + Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Requirements Notation 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 [RFC2119]. 2. Introduction The Locator/ID Separation Protocol (LISP - [RFC6830]) and related @@ -117,27 +118,29 @@ documented in the original description, the renewal of the registration may be denied. 2. EID prefix registrations SHOULD be renewed on a regular basis to ensure their use by active participants in the experiment. The registration period is proposed to be 12 months. Registration renewal SHOULD NOT cause a change in the registered EID prefix. The conditions of registration renewal should no different to the conditions of registration. - 3. When an EID prefix registration is removed from the registry, - then the reuse of the EID prefix in a subsequent registration on - behalf of a different end user should be avoided where possible. - If the considerations of overall usage of the EID block prefix - requires reuse of a previously registered EID prefix, then a - minimum delay of at least one week between removal and subsequent - registration SHOULD be applied by the registry operator. + 3. It is preferable not to reuse EID prefixes whose registration is + expired. When an EID prefix registration is removed from the + registry, then the reuse of the EID prefix in a subsequent + registration on behalf of a different end user should be avoided + where possible. If the considerations of overall usage of the + EID block prefix requires reuse of a previously registered EID + prefix, then a minimum delay of at least one week between removal + and subsequent registration SHOULD be applied by the registry + operator. 4. All registrations of EID prefixes cease at the time of the expiration of the reserved experimental LISP EID Block. The further disposition of these prefixes and the associated registry entries is to be specified in the announcement of the cessation of this experiment. 5. EID Prefixes Registration Requirements All EID prefix registrations MUST respect the following requirements: @@ -195,38 +198,41 @@ (c) Phone (d) Fax (optional) (e) Email 3. EID Prefix Request (Mandatory) (a) Prefix Size + + Expressed as an address prefix length. + (b) Prefix Size Rationale (c) Lease Period - + Note Well: All EID Prefix registrations will be valid until - the earlier date of 12 months from the date of registration - or 31 December 2017. + + Note Well: All EID Prefix registrations will be valid + until the earlier date of 12 months from the date of + registration or 31 December 2017. + All registrations may be renewed by the applicant for further 12 month periods, ending on 31 December 2017. - + According to the 3+3 year experimentation plan, defined in - [I-D.ietf-lisp-eid-block], all registrations MUST end by 31 - December 2017, unless the IETF community decides to grant a - permanent LISP EID address block. In the latter case, - registrations following the present document policy MUST end - by 31 December 2020 and a new policy (to be decided - see - Section 7) will apply starting 1 January 2021. + + According to the 3+3 year experimentation plan, defined + in [I-D.ietf-lisp-eid-block], all registrations MUST end + by 31 December 2017, unless the IETF community decides to + grant a permanent LISP EID address block. In the latter + case, registrations following the present document policy + MUST end by 31 December 2020 and a new policy (to be + decided - see Section 7) will apply starting 1 January + 2021. 4. Experiment Description (a) Experiment and Deployment Description (b) Interoperability with existing LISP deployments (c) Interoperability with Legacy Internet 5. Reverse DNS Servers (Optional) @@ -267,25 +273,26 @@ architecture nor in the Legacy Internet architecture. For accountability reasons, and in line with the security considerations in [RFC7020], each registration request MUST contain accurate information on the requesting entity (company, institution, individual, etc.) and valid and accurate contact information of a referral person (see Section 6). 9. Acknowledgments - Thanks to J. Curran, A. Severin, B. Haberman, T. Manderson, D. - Lewis, D. Farinacci, M. Binderberger, for their helpful comments. + Thanks to J. Curran, A. Severin, B. Haberman, T. Manderson, D. Lewis, + D. Farinacci, M. Binderberger, D. Saucez, E. Lear, for their helpful + comments. - The work of Luigi Iannone has been partially supported by the ANR- - 13-INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT- + The work of Luigi Iannone has been partially supported by the ANR-13- + INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT- Labs SOFNETS Project. 10. IANA Considerations This document provides only management guidelines for the reserved LISP EID prefix requested in [I-D.ietf-lisp-eid-block]. There is an operational requirement for an EID registration service that ensures uniqueness of EIDs according to the requirements described in Section 5. Furthermore, there is an operational @@ -312,42 +319,43 @@ Plan", BCP 122, RFC 4632, August 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 11.2. Informative References [I-D.ietf-weirds-rdap-sec] Hollenbeck, S. and N. Kong, "Security Services for the - Registration Data Access Protocol", draft-ietf-weirds- - rdap-sec-06 (work in progress), February 2014. + Registration Data Access Protocol", + draft-ietf-weirds-rdap-sec-12 (work in progress), + December 2014. [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The - Locator/ID Separation Protocol (LISP)", RFC 6830, January - 2013. + Locator/ID Separation Protocol (LISP)", RFC 6830, + January 2013. [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, January 2013. [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013. [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation - Protocol (LISP) Map-Server Interface", RFC 6833, January - 2013. + Protocol (LISP) Map-Server Interface", RFC 6833, + January 2013. [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, January 2013. [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, January 2013. [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical @@ -472,20 +480,25 @@ logical next-hop on the overlay network. The primary function of LISP+ALT routers is to provide a lightweight forwarding infrastructure for LISP control-plane messages (Map-Request and Map-Reply), and to transport data packets when the packet has the same destination address in both the inner (encapsulating) destination and outer destination addresses ((i.e., a Data Probe packet). See [RFC6830] for more details. Appendix B. Document Change Log + Version 04 Posted December 2014. + + o Added two clarification sentences to address the comments of E. + Lear and D. Saucez during WG LC. + Version 03 Posted October 2014. o Re-worded the document so to avoid confusion on "allocation" and "assignement". The document now reffers to "registration". As for comments by G. Huston and M. Binderberger. Version 02 Posted July 2014. o Deleted the trailing paragraph of Section 4, as for discussion in the mailing list.