draft-ietf-lisp-eid-block-11.txt   draft-ietf-lisp-eid-block-12.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: October 29, 2015 Cisco Systems, Inc. Expires: November 20, 2015 Cisco Systems, Inc.
D. Meyer D. Meyer
Brocade Brocade
V. Fuller V. Fuller
April 27, 2015 May 19, 2015
LISP EID Block LISP EID Block
draft-ietf-lisp-eid-block-11.txt draft-ietf-lisp-eid-block-12.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 October 29, 2015. This Internet-Draft will expire on November 20, 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 4, line 14 skipping to change at page 4, line 14
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 a LISP specific EID block may
may prove useful in transition scenarios. A non-LISP domain prove useful in transition scenarios. A non-LISP domain would
would ask an allocation in the LISP EID block and use it to ask an allocation in the LISP EID block and use it to deploy
deploy LISP in its network. Such allocation will not be LISP in its network. Such allocation will not be announced in
announced in the BGP routing infrastructure (cf., Section 4). the BGP routing infrastructure (cf., Section 4). This approach
This approach will avoid non-LISP domains to fragment their will avoid non-LISP domains to fragment their already allocated
already allocated non-LISP addressing space, which may lead to non-LISP addressing space, which may lead to BGP routing table
BGP routing table inflation since it may (rightfully) be inflation since it may (rightfully) be announced in the BGP
announced in the BGP routing infrastructure. routing infrastructure.
Limit the impact on BGP routing infrastructure: As described in the Limit the impact on BGP routing infrastructure: As described in the
previous scenario, LISP adopters will avoid fragmenting their previous scenario, LISP adopters will avoid fragmenting their
addressing space, which would negatively impact the BGP routing addressing space, which would negatively impact the BGP routing
infrastructure. Adopters will use addressing space from the infrastructure. Adopters will use addressing space from the
EID block, which might be announced in large aggregates and in EID block, which might be announced in large aggregates and in
a tightly controlled manner only by proxy xTRs. a tightly controlled manner only by proxy xTRs.
Is worth to mention that new use cases can arise in the future, due Is worth to mention that new use cases can arise in the future, due
to new and unforeseen scenarios. to new and unforeseen scenarios.
skipping to change at page 13, line 27 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 12 Posted May 2015.
o Fixed typos and references as suggested by the Gen-ART and OPS-DIR
review.
Version 11 Posted April 2015. Version 11 Posted April 2015.
o In Section 4, deleted contradictory text on EID prefix o In Section 4, deleted contradictory text on EID prefix
advertisement in non-LISP inter-domain routing environments. advertisement in non-LISP inter-domain routing environments.
o In Section 3 deleted the "Avoid excessive strech" bullet, because o In Section 3 deleted the "Avoid excessive strech" bullet, because
confusing. confusing.
o Deleted last bullet of the list in Section 3 because retundant o Deleted last bullet of the list in Section 3 because retundant
w.r.t. global content of the document. w.r.t. global content of the document.
 End of changes. 6 change blocks. 
13 lines changed or deleted 18 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/