--- 1/draft-ietf-lisp-eid-block-mgmnt-01.txt 2014-07-02 04:14:41.277245403 -0700 +++ 2/draft-ietf-lisp-eid-block-mgmnt-02.txt 2014-07-02 04:14:41.301245988 -0700 @@ -1,46 +1,45 @@ Network Working Group L. Iannone Internet-Draft Telecom ParisTech Intended status: Informational R. Jorgensen -Expires: August 18, 2014 Bredbandsfylket Troms +Expires: January 2, 2015 Bredbandsfylket Troms D. Conrad Virtualized, LLC - February 14, 2014 + July 1, 2014 LISP EID Block Management Guidelines - draft-ietf-lisp-eid-block-mgmnt-01.txt + draft-ietf-lisp-eid-block-mgmnt-02.txt Abstract This document proposes an allocation framework for the management of - the LISP EID address prefix (requested in [I-D.ietf-lisp-eid-block]). - The framework described relies on hierarchical distribution of the - address space with sub-prefixes allocated on a temporary basis to - requesting organizations. + the LISP EID address prefix. The framework described relies on + hierarchical distribution of the address space with sub-prefixes + allocated on a temporary basis to requesting organizations. 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 August 18, 2014. + This Internet-Draft will expire on January 2, 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 @@ -50,23 +49,23 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 4. EID Prefix Allocation Policy . . . . . . . . . . . . . . . . . 3 5. EID Prefixes Allocation Requirements . . . . . . . . . . . . . 5 - 6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 6 + 6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 5 7. Policy Validity Period . . . . . . . . . . . . . . . . . . . . 7 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. LISP Terms . . . . . . . . . . . . . . . . . . . . . 10 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Requirements Notation @@ -135,23 +134,24 @@ accordance with the 3+3 years experimental allocation plan outlined in [I-D.ietf-lisp-eid-block]. 5. Upon IETF review before 31 December 2017, the EID prefix space may become a permanent allocation. In this case existing allocations CAN be renewed and new allocations granted (still on a yearly temporary basis). All allocations (renewed or not, including delegations and sub-allocations) MUST be returned by 31 December 2020, in accordance to the 3+3 years plan outlined in [I-D.ietf-lisp-eid-block]. During the second 3 years phase of - the experiment, the IETF will decide the final EID prefix block - size and elaborate the allocation and management policies that - will be applied starting 1 January 2021. + the experiment, following the policies outlined in [RFC5226], the + IETF will decide the final EID prefix block size and elaborate + the allocation and management policies that will be applied + starting 1 January 2021. 6. When an allocation is freed because of non-renewal or the termination of an experiment, the address space is returned to the global pool of free EID prefixes. This freed allocation MUST NOT be announced through registration on Map Servers in the LISP mapping system for at least 72 hours to ensure expiration of all cached map entries in the global LISP infrastructure. 7. The EID prefix of an allocation that is not renewed (or whose renewal has been denied) can be re-used after no less than one @@ -159,62 +159,48 @@ provide sufficient time for all cached map entries in the global LISP infrastructure to expire and will allow any management process for re-allocation to be dealt with. 8. EID prefix allocations can be revoked as a result of abuse, unjustified usage (e.g., not conforming the intended use provided at request time), failure to pay maintenance fees, legal court orders, etc. Withdrawal can be enforced by filtering on Map Servers so to prevent map registration. - If/When the EID block experiment changes status (e.g., to not being - "experimental"), and following the policies outlined in [RFC5226], - the EID block will change status as well and will be converted to a - permanent allocation. The IETF will define the transition process - from the policies and requirements outlined in this document to a new - set of policies and requirements. This transition process will - include mechanisms that will allow for requests to convert existing - temporary allocations (with or without renumbering) to permanent - allocations. - 5. EID Prefixes Allocation Requirements All EID prefix allocations (and delegations) MUST respect the following requirements: 1. Allocations MUST be globally unique. 2. Requirements for allocation MUST be the same globally. No regional/national/local variations are permitted. 3. The registration information MUST be maintained and made publicly available through a searchable interface, preferably RDAP ([I-D.ietf-weirds-rdap-sec]) and optionally whois, http, or similar access methods. - 4. The registration information service MUST be available 99% of the - time. The allocation service SHOULD be provided during regular - business hours in venue in which the allocation service is - housed. + 4. The registration information service should be reasonably + reliable so to make such information readily available. The + allocation service SHOULD be provided during regular business + hours in venue in which the allocation service is housed. 5. Facilities SHOULD exist to allow for the delegation of the reverse DNS for EID address prefixes. Reverse DNS delegation is not required, and may not be provided from the beginning of the use of the EID Block. However it may be made available on a later stage if operational requirements necessitate it or IETF decides it should be available. - 6. If fees are charged for EID allocation and registration services, - those fees MUST be no more than the cost of providing those - services. - - 7. Anyone, private persons, companies, or other entities can request + 6. Anyone, private persons, companies, or other entities can request EID space and those requests MUST be granted, provided that they can show a clear intent in carrying out LISP experimentation. 6. EID Prefix Request Template The following is a basic request template for prefix allocation (and delegation) so to ensure a uniform process. Such a template is inspired by the IANA Private Enterprise Number online request form (http://pen.iana.org/pen/PenApplication.page). @@ -337,41 +322,41 @@ IANA must ensure both of these services are provided, for the space directly allocated by IANA, in a globally uniform fashion for the duration of the experiment. 11. References 11.1. Normative References [I-D.ietf-lisp-eid-block] Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP - EID Block", draft-ietf-lisp-eid-block-08 (work in - progress), January 2014. + EID Block", draft-ietf-lisp-eid-block-09 (work in + progress), July 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation 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-05 (work in progress), - August 2013. + draft-ietf-weirds-rdap-sec-06 (work in progress), + February 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. [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The @@ -516,20 +501,33 @@ 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 02 Posted July 2014. + + o Deleted the trailing paragraph of Section 4, as for discussion in + the mailing list. + + o Deleted the fees policy as of suggestion of G. Huston and + discussion during 89th IETF. + + o Re-phrased the availability of the registration information + requirement avoiding putting specific numbers (previously + requiring 99% up time), as of suggestion of G. Huston and + discussion during 89th IETF. + Version 01 Posted February 2014. o Dropped the reverse DNS requirement as for discussion during the 88th IETF meeting. o Dropped the minimum allocation requirement as for discussion during the 88th IETF meeting. o Changed Section 7 from "General Consideration" to "Policy Validity Period", according to J. Curran feedback. The purpose of the @@ -538,21 +536,21 @@ Version 00 Posted December 2013. o Rename of draft-iannone-lisp-eid-block-mgmnt-03.txt. Authors' Addresses Luigi Iannone Telecom ParisTech - Email: luigi.iannone@telecom-paristech.fr + Email: ggx@gigix.net Roger Jorgensen Bredbandsfylket Troms Email: rogerj@gmail.com David Conrad Virtualized, LLC Email: drc@virtualized.org