draft-ietf-lisp-eid-block-10.txt   draft-ietf-lisp-eid-block-11.txt 
Network Working Group L. Iannone Network Working Group L. Iannone
Internet-Draft Telecom ParisTech Internet-Draft Telecom ParisTech
Intended status: Informational D. Lewis Intended status: Informational D. Lewis
Expires: July 12, 2015 Cisco Systems, Inc. Expires: October 29, 2015 Cisco Systems, Inc.
D. Meyer D. Meyer
Brocade Brocade
V. Fuller V. Fuller
January 8, 2015 April 27, 2015
LISP EID Block LISP EID Block
draft-ietf-lisp-eid-block-10.txt draft-ietf-lisp-eid-block-11.txt
Abstract Abstract
This is a direction to IANA to allocate a /32 IPv6 prefix for use This is a direction to IANA to allocate a /32 IPv6 prefix for use
with the Locator/ID Separation Protocol (LISP). The prefix will be with the Locator/ID Separation Protocol (LISP). The prefix will be
used for local intra-domain routing and global endpoint used for local intra-domain routing and global endpoint
identification, by sites deploying LISP as EID (Endpoint IDentifier) identification, by sites deploying LISP as EID (Endpoint IDentifier)
addressing space. addressing space.
Status of this Memo Status of this Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 July 12, 2015. This Internet-Draft will expire on October 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 14 skipping to change at page 2, line 14
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Rationale and Intent . . . . . . . . . . . . . . . . . . . . . 3 3. Rationale and Intent . . . . . . . . . . . . . . . . . . . . . 3
4. Expected use . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Expected use . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . 6 5. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . 5
6. 3+3 Allocation Plan . . . . . . . . . . . . . . . . . . . . . 6 6. 3+3 Allocation Plan . . . . . . . . . . . . . . . . . . . . . 6
7. Routing Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Routing Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. LISP Terminology . . . . . . . . . . . . . . . . . . 11 Appendix A. LISP Terminology . . . . . . . . . . . . . . . . . . 11
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 13 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
skipping to change at page 4, line 5 skipping to change at page 4, line 5
mapping system. In the meanwhile (waiting the Map-Reply), mapping system. In the meanwhile (waiting the Map-Reply),
packets may be dropped in order to avoid excessive buffering. packets may be dropped in order to avoid excessive buffering.
Avoid penalize non-LISP traffic: In certain circumstances it might Avoid penalize non-LISP traffic: In certain circumstances it might
be desirable to configure a router using LISP features to be desirable to configure a router using LISP features to
natively forward all packets that have not a destination natively forward all packets that have not a destination
address in the block, hence, no lookup whatsoever is performed address in the block, hence, no lookup whatsoever is performed
and packets destined to non-LISP sites are not penalized in any and packets destined to non-LISP sites are not penalized in any
manner. manner.
Avoid excessive stretch: In some deployment scenarios, in order to
avoid packet drops, packets triggering a LISP Cache miss are
forwarded toward a PETR, during the time necessary to perform a
mapping lookup over the LISP mapping system. Once a mapping is
obtained packet are not forwarded anymore toward the PETR, they
are LISP encapsulated and forwarded according to the LISP
specifications. The existence of a LISP specific EID block
would allow to avoid scenarios with excessive overhead, where
the destination is a LISP EID and where (while the mapping is
looked up) packets are forwarded over paths like
Source->ITR->PETR->PITR->ETR->Destination, which may show an
excessive stretch factor and degraded performance.
Traffic Engineering: In some deployment scenarios it might be Traffic Engineering: In some deployment scenarios it might be
desirable to apply different traffic engineering policies for desirable to apply different traffic engineering policies for
LISP and non-LISP traffic. A LISP specific EID block would LISP and non-LISP traffic. A LISP specific EID block would
allow improved traffic engineering capabilities with respect to allow improved traffic engineering capabilities with respect to
LISP vs. non-LISP traffic. In particular, LISP traffic might LISP vs. non-LISP traffic. In particular, LISP traffic might
be identified without having to use DPI techniques in order to be identified without having to use DPI techniques in order to
parse the encapsulated packet, performing instead a simple parse the encapsulated packet, performing instead a simple
inspection of the outer header is sufficient. inspection of the outer header is sufficient.
Transition Mechanism: The existence of an LISP specific EID block Transition Mechanism: The existence of an LISP specific EID block
skipping to change at page 5, line 20 skipping to change at page 5, line 8
IPv6 prefix. IPv6 prefix.
4. Expected use 4. Expected use
Sites planning to deploy LISP may request a prefix in the IPv6 EID Sites planning to deploy LISP may request a prefix in the IPv6 EID
block. Such prefix will be used for routing and endpoint block. Such prefix will be used for routing and endpoint
identification inside the site requesting it. Mappings related to identification inside the site requesting it. Mappings related to
such prefix, or part of it, will be made available through the such prefix, or part of it, will be made available through the
mapping system in use and registered to one or more Map Server(s). mapping system in use and registered to one or more Map Server(s).
To provide reachability from the non-LISP Internet, EID prefixes may
be restrictively announced in the BGP routing infrastructure by one
or more PITR(s) as more specifics (longer mask length). The intended
scope of these more specific prefix advertisements may be deliberated
limited by the PITR to reflect local routing policies.
The EID block must be used for LISP experimentation and must not be The EID block must be used for LISP experimentation and must not be
advertised in the form of more specific route advertisements in the advertised in the form of more specific route advertisements in the
non-LISP inter-domain routing environment. Interworking between the non-LISP inter-domain routing environment. Interworking between the
EID block sub-prefixes and the non-LISP Internet is done according to EID block sub-prefixes and the non-LISP Internet is done according to
[RFC6832] and [RFC7215]. [RFC6832] and [RFC7215].
As the LISP adoption progress, the EID block will potentially help in As the LISP adoption progress, the EID block will potentially help in
reducing the impact on the BGP routing infrastructure with respect to reducing the impact on the BGP routing infrastructure with respect to
the case of the same number of adopters using global unicast space the case of the same number of adopters using global unicast space
allocated by RIRs ([MobiArch2007]). From a short-term perspective, allocated by RIRs ([MobiArch2007]). From a short-term perspective,
skipping to change at page 7, line 50 skipping to change at page 7, line 33
element, must not include any special handling code or hardware for element, must not include any special handling code or hardware for
addresses in the IPv6 EID block. In particular, it is recommended addresses in the IPv6 EID block. In particular, it is recommended
that the default router configuration does not handle such addresses that the default router configuration does not handle such addresses
in any special way. Doing differently could prevent communication in any special way. Doing differently could prevent communication
between the Legacy Internet and LISP sites or even break local intra- between the Legacy Internet and LISP sites or even break local intra-
domain connectivity. domain connectivity.
8. Security Considerations 8. Security Considerations
This document does not introduce new security threats in the LISP This document does not introduce new security threats in the LISP
architecture nor in the Legacy Internet architecture. architecture nor in the legacy Internet architecture.
9. IANA Considerations 9. IANA Considerations
This document instructs the IANA to assign a /32 IPv6 prefix for use This document instructs the IANA to assign a /32 IPv6 prefix for use
as the global LISP EID space using a hierarchical allocation as as the global LISP EID space using a hierarchical allocation as
outlined in [RFC5226] and summarized in Table 1. outlined in [RFC5226] and summarized in Table 1.
+----------------------+--------------------+ +----------------------+--------------------+
| Attribute | Value | | Attribute | Value |
+----------------------+--------------------+ +----------------------+--------------------+
skipping to change at page 9, line 11 skipping to change at page 9, line 8
Allocation and management of the Global EID Space is detailed in a Allocation and management of the Global EID Space is detailed in a
different document. Nevertheless, all prefix allocations out of this different document. Nevertheless, all prefix allocations out of this
space must be temporary and no allocation must go beyond December space must be temporary and no allocation must go beyond December
2018 unless the IETF Review decides for a permanent Global EID Space 2018 unless the IETF Review decides for a permanent Global EID Space
assignment. assignment.
10. Acknowledgments 10. Acknowledgments
Special thanks to Roque Gagliano for his suggestions and pointers. Special thanks to Roque Gagliano for his suggestions and pointers.
Thanks to Damien, Saucez, David Conrad, Scott Bradner, John Curran, Thanks to Ron Bonica, Damien Saucez, David Conrad, Scott Bradner,
Paul Wilson, Geoff Huston, Wes George, Arturo Servin, Sander John Curran, Paul Wilson, Geoff Huston, Wes George, Arturo Servin,
Steffann, Brian Carpenter, Roger Jorgensen, Terry Manderson, Brian Sander Steffann, Brian Carpenter, Roger Jorgensen, Terry Manderson,
Haberman, Adrian Farrel, Job Snijders, Marla Azinger, Chris Morrow, Brian Haberman, Adrian Farrel, Job Snijders, Marla Azinger, Chris
and Peter Schoenmaker, for their insightful comments. Thanks as well Morrow, and Peter Schoenmaker, for their insightful comments. Thanks
to all participants to the fruitful discussions on the IETF mailing as well to all participants to the fruitful discussions on the IETF
list. mailing list.
The work of Luigi Iannone has been partially supported by the ANR-13- 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- INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT-
Labs SOFNETS Project. Labs SOFNETS Project.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-lisp-eid-block-mgmnt] [I-D.ietf-lisp-eid-block-mgmnt]
skipping to change at page 13, line 40 skipping to change at page 13, 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 [RFC6836] for more details. packet). See [RFC6836] for more details.
Appendix B. Document Change Log Appendix B. Document Change Log
Version 11 Posted April 2015.
o In Section 4, deleted contradictory text on EID prefix
advertisement in non-LISP inter-domain routing environments.
o In Section 3 deleted the "Avoid excessive strech" bullet, because
confusing.
o Deleted last bullet of the list in Section 3 because retundant
w.r.t. global content of the document.
Version 10 Posted January 2015. Version 10 Posted January 2015.
o Keep alive verision o Keep alive version
Version 09 Posted July 2014. Version 09 Posted July 2014.
o Few Editorial modifications as requested by D. Saucez, as o Few Editorial modifications as requested by D. Saucez, as
shepherd, during the write up of the document. shepherd, during the write up of the document.
o Allocation date postponed to beginning 2015, as suggested by D. o Allocation date postponed to beginning 2015, as suggested by D.
Saucez. Saucez.
Version 08 Posted January 2014. Version 08 Posted January 2014.
 End of changes. 12 change blocks. 
35 lines changed or deleted 27 lines changed or added

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