draft-ietf-lisp-eid-block-mgmnt-03.txt   draft-ietf-lisp-eid-block-mgmnt-04.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: April 27, 2015 Bredbandsfylket Troms Expires: July 4, 2015 Bredbandsfylket Troms
D. Conrad D. Conrad
Virtualized, LLC Virtualized, LLC
G. Huston G. Huston
APNIC - Asia Pacific Network Information Center APNIC - Asia Pacific Network
October 24, 2014 Information Center
December 31, 2014
LISP EID Block Management Guidelines LISP EID Block Management Guidelines
draft-ietf-lisp-eid-block-mgmnt-03.txt draft-ietf-lisp-eid-block-mgmnt-04.txt
Abstract Abstract
This document proposes a framework for the management of the LISP EID This document proposes a framework for the management of the LISP EID
Prefix. The framework described relies on hierarchical distribution Prefix. The framework described relies on hierarchical distribution
of the address space, granting temporary usage of sub-prefixes of of the address space, granting temporary usage of sub-prefixes of
such space to requesting organizations. such space to 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 April 27, 2015. This Internet-Draft will expire on July 4, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . 2 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
4. EID Prefix Registration Policy . . . . . . . . . . . . . . . 3 4. EID Prefix Registration Policy . . . . . . . . . . . . . . . . 3
5. EID Prefixes Registration Requirements . . . . . . . . . . . 4 5. EID Prefixes Registration Requirements . . . . . . . . . . . . 4
6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 4 6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 5
7. Policy Validity Period . . . . . . . . . . . . . . . . . . . 6 7. Policy Validity Period . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. LISP Terms . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. LISP Terms . . . . . . . . . . . . . . . . . . . . . 9
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 11 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Requirements Notation 1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
The Locator/ID Separation Protocol (LISP - [RFC6830]) and related The Locator/ID Separation Protocol (LISP - [RFC6830]) and related
skipping to change at page 3, line 35 skipping to change at page 4, line 13
documented in the original description, the renewal of the documented in the original description, the renewal of the
registration may be denied. registration may be denied.
2. EID prefix registrations SHOULD be renewed on a regular basis to 2. EID prefix registrations SHOULD be renewed on a regular basis to
ensure their use by active participants in the experiment. The ensure their use by active participants in the experiment. The
registration period is proposed to be 12 months. Registration registration period is proposed to be 12 months. Registration
renewal SHOULD NOT cause a change in the registered EID prefix. renewal SHOULD NOT cause a change in the registered EID prefix.
The conditions of registration renewal should no different to the The conditions of registration renewal should no different to the
conditions of registration. conditions of registration.
3. When an EID prefix registration is removed from the registry, 3. It is preferable not to reuse EID prefixes whose registration is
then the reuse of the EID prefix in a subsequent registration on expired. When an EID prefix registration is removed from the
behalf of a different end user should be avoided where possible. registry, then the reuse of the EID prefix in a subsequent
If the considerations of overall usage of the EID block prefix registration on behalf of a different end user should be avoided
requires reuse of a previously registered EID prefix, then a where possible. If the considerations of overall usage of the
minimum delay of at least one week between removal and subsequent EID block prefix requires reuse of a previously registered EID
registration SHOULD be applied by the registry operator. 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 4. All registrations of EID prefixes cease at the time of the
expiration of the reserved experimental LISP EID Block. The expiration of the reserved experimental LISP EID Block. The
further disposition of these prefixes and the associated registry further disposition of these prefixes and the associated registry
entries is to be specified in the announcement of the cessation entries is to be specified in the announcement of the cessation
of this experiment. of this experiment.
5. EID Prefixes Registration Requirements 5. EID Prefixes Registration Requirements
All EID prefix registrations MUST respect the following requirements: All EID prefix registrations MUST respect the following requirements:
skipping to change at page 5, line 21 skipping to change at page 5, line 48
(c) Phone (c) Phone
(d) Fax (optional) (d) Fax (optional)
(e) Email (e) Email
3. EID Prefix Request (Mandatory) 3. EID Prefix Request (Mandatory)
(a) Prefix Size (a) Prefix Size
+ Expressed as an address prefix length.
(b) Prefix Size Rationale (b) Prefix Size Rationale
(c) Lease Period (c) Lease Period
+ Note Well: All EID Prefix registrations will be valid until + Note Well: All EID Prefix registrations will be valid
the earlier date of 12 months from the date of registration until the earlier date of 12 months from the date of
or 31 December 2017. registration or 31 December 2017.
+ All registrations may be renewed by the applicant for + All registrations may be renewed by the applicant for
further 12 month periods, ending on 31 December 2017. further 12 month periods, ending on 31 December 2017.
+ According to the 3+3 year experimentation plan, defined in + According to the 3+3 year experimentation plan, defined
[I-D.ietf-lisp-eid-block], all registrations MUST end by 31 in [I-D.ietf-lisp-eid-block], all registrations MUST end
December 2017, unless the IETF community decides to grant a by 31 December 2017, unless the IETF community decides to
permanent LISP EID address block. In the latter case, grant a permanent LISP EID address block. In the latter
registrations following the present document policy MUST end case, registrations following the present document policy
by 31 December 2020 and a new policy (to be decided - see MUST end by 31 December 2020 and a new policy (to be
Section 7) will apply starting 1 January 2021. decided - see Section 7) will apply starting 1 January
2021.
4. Experiment Description 4. Experiment Description
(a) Experiment and Deployment Description (a) Experiment and Deployment Description
(b) Interoperability with existing LISP deployments (b) Interoperability with existing LISP deployments
(c) Interoperability with Legacy Internet (c) Interoperability with Legacy Internet
5. Reverse DNS Servers (Optional) 5. Reverse DNS Servers (Optional)
skipping to change at page 6, line 44 skipping to change at page 7, line 30
architecture nor in the Legacy Internet architecture. architecture nor in the Legacy Internet architecture.
For accountability reasons, and in line with the security For accountability reasons, and in line with the security
considerations in [RFC7020], each registration request MUST contain considerations in [RFC7020], each registration request MUST contain
accurate information on the requesting entity (company, institution, accurate information on the requesting entity (company, institution,
individual, etc.) and valid and accurate contact information of a individual, etc.) and valid and accurate contact information of a
referral person (see Section 6). referral person (see Section 6).
9. Acknowledgments 9. Acknowledgments
Thanks to J. Curran, A. Severin, B. Haberman, T. Manderson, D. Thanks to J. Curran, A. Severin, B. Haberman, T. Manderson, D. Lewis,
Lewis, D. Farinacci, M. Binderberger, for their helpful comments. D. Farinacci, M. Binderberger, D. Saucez, E. Lear, for their helpful
comments.
The work of Luigi Iannone has been partially supported by the ANR- The work of Luigi Iannone has been partially supported by the ANR-13-
13-INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT- INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT-
Labs SOFNETS Project. Labs SOFNETS Project.
10. IANA Considerations 10. IANA Considerations
This document provides only management guidelines for the reserved This document provides only management guidelines for the reserved
LISP EID prefix requested in [I-D.ietf-lisp-eid-block]. LISP EID prefix requested in [I-D.ietf-lisp-eid-block].
There is an operational requirement for an EID registration service There is an operational requirement for an EID registration service
that ensures uniqueness of EIDs according to the requirements that ensures uniqueness of EIDs according to the requirements
described in Section 5. Furthermore, there is an operational described in Section 5. Furthermore, there is an operational
skipping to change at page 7, line 43 skipping to change at page 8, line 32
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", draft-ietf-weirds- Registration Data Access Protocol",
rdap-sec-06 (work in progress), February 2014. draft-ietf-weirds-rdap-sec-12 (work in progress),
December 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, January Locator/ID Separation Protocol (LISP)", RFC 6830,
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
Locator/ID Separation Protocol (LISP) for Multicast Locator/ID Separation Protocol (LISP) for Multicast
Environments", RFC 6831, January 2013. Environments", RFC 6831, January 2013.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013. (LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, January Protocol (LISP) Map-Server Interface", RFC 6833,
2013. January 2013.
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834, Separation Protocol (LISP) Map-Versioning", RFC 6834,
January 2013. January 2013.
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
Protocol Internet Groper (LIG)", RFC 6835, January 2013. Protocol Internet Groper (LIG)", RFC 6835, January 2013.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol Alternative Logical
skipping to change at page 11, line 10 skipping to change at page 12, line 7
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 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. Version 03 Posted October 2014.
o Re-worded the document so to avoid confusion on "allocation" and o Re-worded the document so to avoid confusion on "allocation" and
"assignement". The document now reffers to "registration". As "assignement". The document now reffers to "registration". As
for comments by G. Huston and M. Binderberger. for comments by G. Huston and M. Binderberger.
Version 02 Posted July 2014. Version 02 Posted July 2014.
o Deleted the trailing paragraph of Section 4, as for discussion in o Deleted the trailing paragraph of Section 4, as for discussion in
the mailing list. the mailing list.
o Deleted the fees policy as of suggestion of G. Huston and o Deleted the fees policy as of suggestion of G. Huston and
discussion during 89th IETF. discussion during 89th IETF.
o Re-phrased the availability of the registration information o Re-phrased the availability of the registration information
requirement avoiding putting specific numbers (previously requirement avoiding putting specific numbers (previously
requiring 99% up time), as of suggestion of G. Huston and requiring 99% up time), as of suggestion of G. Huston and
discussion during 89th IETF. 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
section is just to clearly state the period during which the section is just to clearly state the period during which the
policy applies. policy applies.
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
 End of changes. 21 change blocks. 
55 lines changed or deleted 68 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/