draft-ietf-lisp-rfc6830bis-01.txt   draft-ietf-lisp-rfc6830bis-02.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft V. Fuller Internet-Draft V. Fuller
Intended status: Standards Track D. Meyer Intended status: Standards Track D. Meyer
Expires: September 27, 2017 D. Lewis Expires: October 13, 2017 D. Lewis
Cisco Systems Cisco Systems
A. Cabellos (Ed.) A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
March 26, 2017 April 11, 2017
The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-rfc6830bis-01 draft-ietf-lisp-rfc6830bis-02
Abstract Abstract
This document describes the Locator/ID Separation Protocol (LISP) This document describes the data-plane protocol for the Locator/ID
data-plane encapsulation protocol. LISP defines two namespaces, End- Separation Protocol (LISP). LISP defines two namespaces, End-point
point Identifiers (EIDs) that identify end-hosts and Routing Locators Identifiers (EIDs) that identify end-hosts and Routing Locators
(RLOCs) that identify network attachment points. With this, LISP (RLOCs) that identify network attachment points. With this, LISP
effectively separates control from data, and allows routers to create effectively separates control from data, and allows routers to create
overlay networks. LISP-capable routers exchange encapsulated packets overlay networks. LISP-capable routers exchange encapsulated packets
according to EID-to-RLOC mappings stored in a local map-cache. The according to EID-to-RLOC mappings stored in a local map-cache. The
map-cache is populated by the LISP Control-Plane protocol map-cache is populated by the LISP Control-Plane protocol
[I-D.ietf-lisp-rfc6833bis]. [I-D.ietf-lisp-rfc6833bis].
LISP requires no change to either host protocol stacks or to underlay LISP requires no change to either host protocol stacks or to underlay
routers and offers Traffic Engineering, multihoming and mobility, routers and offers Traffic Engineering, multihoming and mobility,
among other features. among other features.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 September 27, 2017. This Internet-Draft will expire on October 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 41 skipping to change at page 2, line 41
6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 20 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 20
7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20
7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 21 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 21
7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 22 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 22
8. Using Virtualization and Segmentation with LISP . . . . . . . 22 8. Using Virtualization and Segmentation with LISP . . . . . . . 22
9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 23 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 23
10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24
10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 27 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 27
10.2. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 28 10.2. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 28
11. EID Reachability within a LISP Site . . . . . . . . . . . . . 29 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 29
12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 29 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 30
13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 31
13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 32
13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32 13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32
13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 33 13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 34
14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34
15. Router Performance Considerations . . . . . . . . . . . . . . 35 15. Router Performance Considerations . . . . . . . . . . . . . . 35
16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 36 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 36
16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 36
16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 36
16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 37 16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 37
17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 37 17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 38
17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 38 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 39
17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39 17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39
17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 39 17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 40
17.4. LISP Functionality with Conventional NATs . . . . . . . 40 17.4. LISP Functionality with Conventional NATs . . . . . . . 40
17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 40 17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 41
18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 41 18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 41
18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 42
18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 42
18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 42 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 43
19. Security Considerations . . . . . . . . . . . . . . . . . . . 43 19. Security Considerations . . . . . . . . . . . . . . . . . . . 43
20. Network Management Considerations . . . . . . . . . . . . . . 44 20. Network Management Considerations . . . . . . . . . . . . . . 44
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
21.1. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 44 21.1. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 44
21.2. LISP Address Type Codes . . . . . . . . . . . . . . . . 44 21.2. LISP Address Type Codes . . . . . . . . . . . . . . . . 45
21.3. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 45 21.3. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 45
21.4. LISP Key ID Numbers . . . . . . . . . . . . . . . . . . 45 21.4. LISP Key ID Numbers . . . . . . . . . . . . . . . . . . 45
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
22.1. Normative References . . . . . . . . . . . . . . . . . . 45 22.1. Normative References . . . . . . . . . . . . . . . . . . 45
22.2. Informative References . . . . . . . . . . . . . . . . . 48 22.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 52 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 52
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 52 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 52
B.1. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 53 B.1. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 53
B.2. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 53 B.2. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 53
B.3. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
This document describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier Separation Protocol
(LISP). LISP is an encapsulation protocol built around the (LISP). LISP is an encapsulation protocol built around the
fundamental idea of separating the topological location of a network fundamental idea of separating the topological location of a network
attachment point from the node's identity [CHIAPPA]. As a result attachment point from the node's identity [CHIAPPA]. As a result
LISP creates two namespaces: Endpoint Identifiers (EIDs), that are LISP creates two namespaces: Endpoint Identifiers (EIDs), that are
used to identify end-hosts (e.g., nodes or Virtual Machines) and used to identify end-hosts (e.g., nodes or Virtual Machines) and
routable Routing Locators (RLOCs), used to identify network routable Routing Locators (RLOCs), used to identify network
attachment points. LISP then defines functions for mapping between attachment points. LISP then defines functions for mapping between
the two numbering spaces and for encapsulating traffic originated by the two namespaces and for encapsulating traffic originated by
devices using non-routable EIDs for transport across a network devices using non-routable EIDs for transport across a network
infrastructure that routes and forwards using RLOCs. infrastructure that routes and forwards using RLOCs.
LISP is an overlay protocol that separates control from data-plane, LISP is an overlay protocol that separates control from data-plane,
this document specifies the data-plane, how LISP-capable routers this document specifies the data-plane, how LISP-capable routers
(Tunnel Routers) exchange packets by encapsulating them to the (Tunnel Routers) exchange packets by encapsulating them to the
appropriate location. Tunnel routers are equipped with a cache, appropriate location. Tunnel routers are equipped with a cache,
called map-cache, that contains EID-to-RLOC mappings. The map-cache called map-cache, that contains EID-to-RLOC mappings. The map-cache
is populated using the LISP Control-Plane protocol is populated using the LISP Control-Plane protocol
[I-D.ietf-lisp-rfc6833bis]. [I-D.ietf-lisp-rfc6833bis].
skipping to change at page 4, line 15 skipping to change at page 4, line 15
LISP does not require changes to either host protocol stack or to LISP does not require changes to either host protocol stack or to
underlay routers. By separating the EID from the RLOC space, LISP underlay routers. By separating the EID from the RLOC space, LISP
offers native Traffic Engineering, multihoming and mobility, among offers native Traffic Engineering, multihoming and mobility, among
other features. other features.
Creation of LISP was initially motivated by discussions during the Creation of LISP was initially motivated by discussions during the
IAB-sponsored Routing and Addressing Workshop held in Amsterdam in IAB-sponsored Routing and Addressing Workshop held in Amsterdam in
October 2006 (see [RFC4984]) October 2006 (see [RFC4984])
This document specifies the LISP data-plane encapsulation and other This document specifies the LISP data-plane encapsulation and other
xTR functionality while [I-D.ietf-lisp-rfc6833bis] specifies the LISP LISP forwarding node functionality while [I-D.ietf-lisp-rfc6833bis]
control plane. LISP deployment guidelines can be found in [RFC7215] specifies the LISP control plane. LISP deployment guidelines can be
and [RFC6835] describes considerations for network operational found in [RFC7215] and [RFC6835] describes considerations for network
management. Finally, [I-D.ietf-lisp-introduction] describes the LISP operational management. Finally, [I-D.ietf-lisp-introduction]
architecture. describes the LISP architecture.
2. Requirements Notation 2. 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].
3. Definition of Terms 3. Definition of Terms
Provider-Independent (PI) Addresses: PI addresses are an address Provider-Independent (PI) Addresses: PI addresses are an address
skipping to change at page 13, line 44 skipping to change at page 13, line 44
information about additional RLOCs SHOULD be verified by sending information about additional RLOCs SHOULD be verified by sending
a LISP Map-Request for that EID. Both the ITR and the ETR may a LISP Map-Request for that EID. Both the ITR and the ETR may
also influence the decision the other makes in selecting an RLOC. also influence the decision the other makes in selecting an RLOC.
5. LISP Encapsulation Details 5. LISP Encapsulation Details
Since additional tunnel headers are prepended, the packet becomes Since additional tunnel headers are prepended, the packet becomes
larger and can exceed the MTU of any link traversed from the ITR to larger and can exceed the MTU of any link traversed from the ITR to
the ETR. It is RECOMMENDED in IPv4 that packets do not get the ETR. It is RECOMMENDED in IPv4 that packets do not get
fragmented as they are encapsulated by the ITR. Instead, the packet fragmented as they are encapsulated by the ITR. Instead, the packet
is dropped and an ICMP Too Big message is returned to the source. is dropped and an ICMP Unreachable/Fragmentation-Needed message is
returned to the source.
This specification RECOMMENDS that implementations provide support This specification RECOMMENDS that implementations provide support
for one of the proposed fragmentation and reassembly schemes. Two for one of the proposed fragmentation and reassembly schemes. Two
existing schemes are detailed in Section 7. existing schemes are detailed in Section 7.
Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP
architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner
header is in IPv4 packet format and the outer header is in IPv6 header is in IPv4 packet format and the outer header is in IPv6
packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header
is in IPv6 packet format and the outer header is in IPv4 packet is in IPv6 packet format and the outer header is in IPv4 packet
skipping to change at page 21, line 43 skipping to change at page 21, line 43
then forwards each fragment to the destination host of the then forwards each fragment to the destination host of the
destination site. The two fragments are reassembled at the destination site. The two fragments are reassembled at the
destination host into the single IP datagram that was originated by destination host into the single IP datagram that was originated by
the source host. Note that reassembly can happen at the ETR if the the source host. Note that reassembly can happen at the ETR if the
encapsulated packet was fragmented at or after the ITR. encapsulated packet was fragmented at or after the ITR.
This behavior is performed by the ITR when the source host originates This behavior is performed by the ITR when the source host originates
a packet with the 'DF' field of the IP header set to 0. When the a packet with the 'DF' field of the IP header set to 0. When the
'DF' field of the IP header is set to 1, or the packet is an IPv6 'DF' field of the IP header is set to 1, or the packet is an IPv6
packet originated by the source host, the ITR will drop the packet packet originated by the source host, the ITR will drop the packet
when the size is greater than L and send an ICMP Too Big message to when the size is greater than L and send an ICMP Unreachable/
the source with a value of S, where S is (L - H). Fragmentation-Needed message to the source with a value of S, where S
is (L - H).
When the outer-header encapsulation uses an IPv4 header, an When the outer-header encapsulation uses an IPv4 header, an
implementation SHOULD set the DF bit to 1 so ETR fragment reassembly implementation SHOULD set the DF bit to 1 so ETR fragment reassembly
can be avoided. An implementation MAY set the DF bit in such headers can be avoided. An implementation MAY set the DF bit in such headers
to 0 if it has good reason to believe there are unresolvable path MTU to 0 if it has good reason to believe there are unresolvable path MTU
issues between the sending ITR and the receiving ETR. issues between the sending ITR and the receiving ETR.
This specification RECOMMENDS that L be defined as 1500. This specification RECOMMENDS that L be defined as 1500.
7.2. A Stateful Solution to MTU Handling 7.2. A Stateful Solution to MTU Handling
skipping to change at page 22, line 17 skipping to change at page 22, line 19
An ITR stateful solution to handle MTU issues is described as follows An ITR stateful solution to handle MTU issues is described as follows
and was first introduced in [OPENLISP]: and was first introduced in [OPENLISP]:
1. The ITR will keep state of the effective MTU for each Locator per 1. The ITR will keep state of the effective MTU for each Locator per
Map-Cache entry. The effective MTU is what the core network can Map-Cache entry. The effective MTU is what the core network can
deliver along the path between the ITR and ETR. deliver along the path between the ITR and ETR.
2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet
with the DF bit set to 1, exceeds what the core network can with the DF bit set to 1, exceeds what the core network can
deliver, one of the intermediate routers on the path will send an deliver, one of the intermediate routers on the path will send an
ICMP Too Big message to the ITR. The ITR will parse the ICMP ICMP Unreachable/Fragmentation-Needed message to the ITR. The
message to determine which Locator is affected by the effective ITR will parse the ICMP message to determine which Locator is
MTU change and then record the new effective MTU value in the affected by the effective MTU change and then record the new
Map-Cache entry. effective MTU value in the Map-Cache entry.
3. When a packet is received by the ITR from a source inside of the 3. When a packet is received by the ITR from a source inside of the
site and the size of the packet is greater than the effective MTU site and the size of the packet is greater than the effective MTU
stored with the Map-Cache entry associated with the destination stored with the Map-Cache entry associated with the destination
EID the packet is for, the ITR will send an ICMP Too Big message EID the packet is for, the ITR will send an ICMP Unreachable/
back to the source. The packet size advertised by the ITR in the Fragmentation-Needed message back to the source. The packet size
ICMP Too Big message is the effective MTU minus the LISP advertised by the ITR in the ICMP Unreachable/Fragmentation-
encapsulation length. Needed message is the effective MTU minus the LISP encapsulation
length.
Even though this mechanism is stateful, it has advantages over the Even though this mechanism is stateful, it has advantages over the
stateless IP fragmentation mechanism, by not involving the stateless IP fragmentation mechanism, by not involving the
destination host with reassembly of ITR fragmented packets. destination host with reassembly of ITR fragmented packets.
8. Using Virtualization and Segmentation with LISP 8. Using Virtualization and Segmentation with LISP
When multiple organizations inside of a LISP site are using private When multiple organizations inside of a LISP site are using private
addresses [RFC1918] as EID-Prefixes, their address spaces MUST remain addresses [RFC1918] as EID-Prefixes, their address spaces MUST remain
segregated due to possible address duplication. An Instance ID in segregated due to possible address duplication. An Instance ID in
skipping to change at page 45, line 46 skipping to change at page 46, line 14
[I-D.ietf-lisp-introduction] [I-D.ietf-lisp-introduction]
Cabellos-Aparicio, A. and D. Saucez, "An Architectural Cabellos-Aparicio, A. and D. Saucez, "An Architectural
Introduction to the Locator/ID Separation Protocol Introduction to the Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-introduction-13 (work in (LISP)", draft-ietf-lisp-introduction-13 (work in
progress), April 2015. progress), April 2015.
[I-D.ietf-lisp-rfc6833bis] [I-D.ietf-lisp-rfc6833bis]
Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,
"Locator/ID Separation Protocol (LISP) Control-Plane", "Locator/ID Separation Protocol (LISP) Control-Plane",
draft-ietf-lisp-rfc6833bis-00 (work in progress), December draft-ietf-lisp-rfc6833bis-01 (work in progress), March
2016. 2017.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12
(work in progress), November 2016. (work in progress), November 2016.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>. <http://www.rfc-editor.org/info/rfc768>.
skipping to change at page 49, line 14 skipping to change at page 49, line 29
[I-D.meyer-loc-id-implications] [I-D.meyer-loc-id-implications]
Meyer, D. and D. Lewis, "Architectural Implications of Meyer, D. and D. Lewis, "Architectural Implications of
Locator/ID Separation", draft-meyer-loc-id-implications-01 Locator/ID Separation", draft-meyer-loc-id-implications-01
(work in progress), January 2009. (work in progress), January 2009.
[I-D.portoles-lisp-eid-mobility] [I-D.portoles-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-portoles-lisp-eid- Unified Control Plane", draft-portoles-lisp-eid-
mobility-01 (work in progress), October 2016. mobility-02 (work in progress), April 2017.
[LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin, [LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin,
"Renumbering: Threat or Menace?", Usenix Tenth System "Renumbering: Threat or Menace?", Usenix Tenth System
Administration Conference (LISA 96), October 1996. Administration Conference (LISA 96), October 1996.
[OPENLISP] [OPENLISP]
Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP
Implementation Report", Work in Progress, July 2008. Implementation Report", Work in Progress, July 2008.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
skipping to change at page 53, line 5 skipping to change at page 53, line 5
The LISP working group would like to give a special thanks to Jari The LISP working group would like to give a special thanks to Jari
Arkko, the Internet Area AD at the time that the set of LISP Arkko, the Internet Area AD at the time that the set of LISP
documents were being prepared for IESG last call, and for his documents were being prepared for IESG last call, and for his
meticulous reviews and detailed commentaries on the 7 working group meticulous reviews and detailed commentaries on the 7 working group
last call documents progressing toward standards-track RFCs. last call documents progressing toward standards-track RFCs.
Appendix B. Document Change Log Appendix B. Document Change Log
[RFC Editor: Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on publication as RFC.]
B.1. Changes to draft-ietf-lisp-rfc6830bis-01 B.1. Changes to draft-ietf-lisp-rfc6830bis-02
o Posted April 2017.
o Reflect some editorial comments from Damien Sausez.
B.2. Changes to draft-ietf-lisp-rfc6830bis-01
o Posted March 2017. o Posted March 2017.
o Include references to new RFCs published. o Include references to new RFCs published.
o Change references from RFC6833 to RFC6833bis. o Change references from RFC6833 to RFC6833bis.
o Clarified LCAF text in the IANA section. o Clarified LCAF text in the IANA section.
o Remove references to "experimental". o Remove references to "experimental".
B.2. Changes to draft-ietf-lisp-rfc6830bis-00 B.3. Changes to draft-ietf-lisp-rfc6830bis-00
o Posted December 2016. o Posted December 2016.
o Created working group document from draft-farinacci-lisp o Created working group document from draft-farinacci-lisp
-rfc6830-00 individual submission. No other changes made. -rfc6830-00 individual submission. No other changes made.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
Cisco Systems Cisco Systems
 End of changes. 23 change blocks. 
41 lines changed or deleted 51 lines changed or added

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