draft-ietf-lisp-eid-block-mgmnt-01.txt   draft-ietf-lisp-eid-block-mgmnt-02.txt 
Network Working Group L. Iannone Network Working Group L. Iannone
Internet-Draft Telecom ParisTech Internet-Draft Telecom ParisTech
Intended status: Informational R. Jorgensen Intended status: Informational R. Jorgensen
Expires: August 18, 2014 Bredbandsfylket Troms Expires: January 2, 2015 Bredbandsfylket Troms
D. Conrad D. Conrad
Virtualized, LLC Virtualized, LLC
February 14, 2014 July 1, 2014
LISP EID Block Management Guidelines LISP EID Block Management Guidelines
draft-ietf-lisp-eid-block-mgmnt-01.txt draft-ietf-lisp-eid-block-mgmnt-02.txt
Abstract Abstract
This document proposes an allocation framework for the management of This document proposes an allocation framework for the management of
the LISP EID address prefix (requested in [I-D.ietf-lisp-eid-block]). the LISP EID address prefix. The framework described relies on
The framework described relies on hierarchical distribution of the hierarchical distribution of the address space with sub-prefixes
address space with sub-prefixes allocated on a temporary basis to allocated on a temporary basis to requesting organizations.
requesting organizations.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 14
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
4. EID Prefix Allocation Policy . . . . . . . . . . . . . . . . . 3 4. EID Prefix Allocation Policy . . . . . . . . . . . . . . . . . 3
5. EID Prefixes Allocation Requirements . . . . . . . . . . . . . 5 5. EID Prefixes Allocation Requirements . . . . . . . . . . . . . 5
6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 6 6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 5
7. Policy Validity Period . . . . . . . . . . . . . . . . . . . . 7 7. Policy Validity Period . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. LISP Terms . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. LISP Terms . . . . . . . . . . . . . . . . . . . . . 10
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 12 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Requirements Notation 1. Requirements Notation
skipping to change at page 4, line 32 skipping to change at page 4, line 32
accordance with the 3+3 years experimental allocation plan accordance with the 3+3 years experimental allocation plan
outlined in [I-D.ietf-lisp-eid-block]. outlined in [I-D.ietf-lisp-eid-block].
5. Upon IETF review before 31 December 2017, the EID prefix space 5. Upon IETF review before 31 December 2017, the EID prefix space
may become a permanent allocation. In this case existing may become a permanent allocation. In this case existing
allocations CAN be renewed and new allocations granted (still on allocations CAN be renewed and new allocations granted (still on
a yearly temporary basis). All allocations (renewed or not, a yearly temporary basis). All allocations (renewed or not,
including delegations and sub-allocations) MUST be returned by 31 including delegations and sub-allocations) MUST be returned by 31
December 2020, in accordance to the 3+3 years plan outlined in 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 [I-D.ietf-lisp-eid-block]. During the second 3 years phase of
the experiment, the IETF will decide the final EID prefix block the experiment, following the policies outlined in [RFC5226], the
size and elaborate the allocation and management policies that IETF will decide the final EID prefix block size and elaborate
will be applied starting 1 January 2021. 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 6. When an allocation is freed because of non-renewal or the
termination of an experiment, the address space is returned to termination of an experiment, the address space is returned to
the global pool of free EID prefixes. This freed allocation MUST the global pool of free EID prefixes. This freed allocation MUST
NOT be announced through registration on Map Servers in the LISP NOT be announced through registration on Map Servers in the LISP
mapping system for at least 72 hours to ensure expiration of all mapping system for at least 72 hours to ensure expiration of all
cached map entries in the global LISP infrastructure. cached map entries in the global LISP infrastructure.
7. The EID prefix of an allocation that is not renewed (or whose 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 renewal has been denied) can be re-used after no less than one
skipping to change at page 5, line 8 skipping to change at page 5, line 11
provide sufficient time for all cached map entries in the global provide sufficient time for all cached map entries in the global
LISP infrastructure to expire and will allow any management LISP infrastructure to expire and will allow any management
process for re-allocation to be dealt with. process for re-allocation to be dealt with.
8. EID prefix allocations can be revoked as a result of abuse, 8. EID prefix allocations can be revoked as a result of abuse,
unjustified usage (e.g., not conforming the intended use provided unjustified usage (e.g., not conforming the intended use provided
at request time), failure to pay maintenance fees, legal court at request time), failure to pay maintenance fees, legal court
orders, etc. Withdrawal can be enforced by filtering on Map orders, etc. Withdrawal can be enforced by filtering on Map
Servers so to prevent map registration. 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 5. EID Prefixes Allocation Requirements
All EID prefix allocations (and delegations) MUST respect the All EID prefix allocations (and delegations) MUST respect the
following requirements: following requirements:
1. Allocations MUST be globally unique. 1. Allocations MUST be globally unique.
2. Requirements for allocation MUST be the same globally. No 2. Requirements for allocation MUST be the same globally. No
regional/national/local variations are permitted. regional/national/local variations are permitted.
3. The registration information MUST be maintained and made publicly 3. The registration information MUST be maintained and made publicly
available through a searchable interface, preferably RDAP available through a searchable interface, preferably RDAP
([I-D.ietf-weirds-rdap-sec]) and optionally whois, http, or ([I-D.ietf-weirds-rdap-sec]) and optionally whois, http, or
similar access methods. similar access methods.
4. The registration information service MUST be available 99% of the 4. The registration information service should be reasonably
time. The allocation service SHOULD be provided during regular reliable so to make such information readily available. The
business hours in venue in which the allocation service is allocation service SHOULD be provided during regular business
housed. hours in venue in which the allocation service is housed.
5. Facilities SHOULD exist to allow for the delegation of the 5. Facilities SHOULD exist to allow for the delegation of the
reverse DNS for EID address prefixes. Reverse DNS delegation is reverse DNS for EID address prefixes. Reverse DNS delegation is
not required, and may not be provided from the beginning of the 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 use of the EID Block. However it may be made available on a
later stage if operational requirements necessitate it or IETF later stage if operational requirements necessitate it or IETF
decides it should be available. decides it should be available.
6. If fees are charged for EID allocation and registration services, 6. Anyone, private persons, companies, or other entities can request
those fees MUST be no more than the cost of providing those
services.
7. Anyone, private persons, companies, or other entities can request
EID space and those requests MUST be granted, provided that they EID space and those requests MUST be granted, provided that they
can show a clear intent in carrying out LISP experimentation. can show a clear intent in carrying out LISP experimentation.
6. EID Prefix Request Template 6. EID Prefix Request Template
The following is a basic request template for prefix allocation (and The following is a basic request template for prefix allocation (and
delegation) so to ensure a uniform process. Such a template is delegation) so to ensure a uniform process. Such a template is
inspired by the IANA Private Enterprise Number online request form inspired by the IANA Private Enterprise Number online request form
(http://pen.iana.org/pen/PenApplication.page). (http://pen.iana.org/pen/PenApplication.page).
skipping to change at page 8, line 47 skipping to change at page 8, line 36
IANA must ensure both of these services are provided, for the space IANA must ensure both of these services are provided, for the space
directly allocated by IANA, in a globally uniform fashion for the directly allocated by IANA, in a globally uniform fashion for the
duration of the experiment. duration of the experiment.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-lisp-eid-block] [I-D.ietf-lisp-eid-block]
Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP
EID Block", draft-ietf-lisp-eid-block-08 (work in EID Block", draft-ietf-lisp-eid-block-09 (work in
progress), January 2014. progress), July 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006. Plan", BCP 122, RFC 4632, August 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
11.2. Informative References 11.2. Informative References
[I-D.ietf-weirds-rdap-sec] [I-D.ietf-weirds-rdap-sec]
Hollenbeck, S. and N. Kong, "Security Services for the Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol", Registration Data Access Protocol",
draft-ietf-weirds-rdap-sec-05 (work in progress), draft-ietf-weirds-rdap-sec-06 (work in progress),
August 2013. February 2014.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, June 2000. Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013. January 2013.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
skipping to change at page 12, line 40 skipping to change at page 12, line 27
logical next-hop on the overlay network. The primary function of logical next-hop on the overlay network. The primary function of
LISP+ALT routers is to provide a lightweight forwarding LISP+ALT routers is to provide a lightweight forwarding
infrastructure for LISP control-plane messages (Map-Request and infrastructure for LISP control-plane messages (Map-Request and
Map-Reply), and to transport data packets when the packet has the Map-Reply), and to transport data packets when the packet has the
same destination address in both the inner (encapsulating) same destination address in both the inner (encapsulating)
destination and outer destination addresses ((i.e., a Data Probe destination and outer destination addresses ((i.e., a Data Probe
packet). See [RFC6830] for more details. packet). See [RFC6830] for more details.
Appendix B. Document Change Log 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. Version 01 Posted February 2014.
o Dropped the reverse DNS requirement as for discussion during the o Dropped the reverse DNS requirement as for discussion during the
88th IETF meeting. 88th IETF meeting.
o Dropped the minimum allocation requirement as for discussion o Dropped the minimum allocation requirement as for discussion
during the 88th IETF meeting. during the 88th IETF meeting.
o Changed Section 7 from "General Consideration" to "Policy Validity o Changed Section 7 from "General Consideration" to "Policy Validity
Period", according to J. Curran feedback. The purpose of the Period", according to J. Curran feedback. The purpose of the
skipping to change at page 13, line 14 skipping to change at page 13, line 15
Version 00 Posted December 2013. Version 00 Posted December 2013.
o Rename of draft-iannone-lisp-eid-block-mgmnt-03.txt. o Rename of draft-iannone-lisp-eid-block-mgmnt-03.txt.
Authors' Addresses Authors' Addresses
Luigi Iannone Luigi Iannone
Telecom ParisTech Telecom ParisTech
Email: luigi.iannone@telecom-paristech.fr Email: ggx@gigix.net
Roger Jorgensen Roger Jorgensen
Bredbandsfylket Troms Bredbandsfylket Troms
Email: rogerj@gmail.com Email: rogerj@gmail.com
David Conrad David Conrad
Virtualized, LLC Virtualized, LLC
Email: drc@virtualized.org Email: drc@virtualized.org
 End of changes. 15 change blocks. 
37 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/