draft-ietf-nvo3-vmm-09.txt   draft-ietf-nvo3-vmm-10.txt 
Network Working Group L. Dunbar Network Working Group L. Dunbar
Internet Draft Futurewei Internet Draft Futurewei
Intended status: Informational B. Sarikaya Intended status: Informational B. Sarikaya
Expires: September 26, 2020 Denpel Informatique Expires: September 27, 2020 Denpel Informatique
B.Khasnabish B.Khasnabish
Independent Independent
T. Herbert T. Herbert
Intel Intel
S. Dikshit S. Dikshit
Aruba-HPE Aruba-HPE
March 26, 2020 March 27, 2020
Virtual Machine Mobility Solutions for L2 and L3 Overlay Networks Virtual Machine Mobility Solutions for L2 and L3 Overlay Networks
draft-ietf-nvo3-vmm-09 draft-ietf-nvo3-vmm-10
Abstract Abstract
This document describes virtual machine mobility solutions commonly This document describes virtual machine mobility solutions commonly
used in data centers built with overlay-based network. This document used in data centers built with overlay-based network. This document
is intended for describing the solutions and the impact of moving is intended for describing the solutions and the impact of moving
VMs (or applications) from one Rack to another connected by the VMs (or applications) from one Rack to another connected by the
Overlay networks. Overlay networks.
For layer 2, it is based on using an NVA (Network Virtualization For layer 2, it is based on using an NVA (Network Virtualization
skipping to change at page 2, line 21 skipping to change at page 2, line 21
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 25, 2020. This Internet-Draft will expire on September 26, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 3, line 8 skipping to change at page 3, line 8
1. Introduction...................................................3 1. Introduction...................................................3
2. Conventions used in this document..............................4 2. Conventions used in this document..............................4
3. Requirements...................................................5 3. Requirements...................................................5
4. Overview of the VM Mobility Solutions..........................6 4. Overview of the VM Mobility Solutions..........................6
4.1. Inter-VNs communication...................................6 4.1. Inter-VNs communication...................................6
4.2. VM Migration in Layer 2 Network...........................6 4.2. VM Migration in Layer 2 Network...........................6
4.3. VM Migration in Layer-3 Network...........................8 4.3. VM Migration in Layer-3 Network...........................8
4.4. Address and Connection Management in VM Migration.........9 4.4. Address and Connection Management in VM Migration.........9
5. Handling Packets in Flight....................................10 5. Handling Packets in Flight....................................10
6. Moving Local State of VM......................................11 6. Moving Local State of VM......................................10
7. Handling of Hot, Warm and Cold VM Mobility....................11 7. Handling of Hot, Warm and Cold VM Mobility....................11
8. Other Options.................................................12 8. Other Options.................................................11
9. VM Lifecycle Management.......................................12 9. VM Lifecycle Management.......................................12
10. Security Considerations......................................12 10. Security Considerations......................................12
11. IANA Considerations..........................................13 11. IANA Considerations..........................................13
12. Acknowledgments..............................................13 12. Acknowledgments..............................................13
13. Change Log...................................................13 13. Change Log...................................................13
14. References...................................................13 14. References...................................................13
14.1. Normative References....................................14 14.1. Normative References....................................14
14.2. Informative References..................................15 14.2. Informative References..................................15
1. Introduction 1. Introduction
This document describes the overlay-based data center networks This document describes the overlay-based data center networks
solutions in supporting multitenancy and VM (Virtual Machine) solutions in supporting multitenancy and VM (Virtual Machine)
mobility. This document is strictly within the DCVPN, as defined mobility. Being able to move VMs dynamically, from one server to
by the NVO3 Framework [RFC 7365]. The intent is to describe Layer another, makes it possible for dynamic load balancing or work
2 and Layer 3 Network behavior when VMs are moved from one NVE to distribution. Therefore, dynamic VM Mobility is highly desirable
another. This document assumes that the VMs move is initiated by for large scale multi-tenant DCs.
VM management system, i.e. planed move. How and when to move VM This document is strictly within the DCVPN, as defined by the NVO3
are out of the scope of this document. RFC7666 already has the Framework [RFC 7365]. The intent is to describe Layer 2 and Layer
3 Network behavior when VMs are moved from one NVE to another.
This document assumes that the VMs move is initiated by VM
management system, i.e. planed move. How and when to move VM are
out of the scope of this document. RFC7666 already has the
description of the MIB for VMs controlled by Hypervisor. The description of the MIB for VMs controlled by Hypervisor. The
impact of VM mobility on higher layer protocols and applications impact of VM mobility on higher layer protocols and applications
is outside its scope. is outside its scope.
Many large DCs (Data Centers), especially Cloud DCs, host tasks Many large DCs (Data Centers), especially Cloud DCs, host tasks
(or workloads) for multiple tenants. A tenant can be a department (or workloads) for multiple tenants. A tenant can be a department
of one organization or an organization. There are communications of one organization or an organization. There are communications
among tasks belonging to one tenant and communications among tasks among tasks belonging to one tenant and communications among tasks
belonging to different tenants or with external entities. belonging to different tenants or with external entities.
Server Virtualization, which is being used in almost all of Server Virtualization, which is being used in almost all of
today's data centers, enables many VMs to run on a single physical today's data centers, enables many VMs to run on a single physical
skipping to change at page 6, line 31 skipping to change at page 6, line 34
Gateway function which is to relay traffic onto and off of a Gateway function which is to relay traffic onto and off of a
virtual network, i.e. among different VNs. virtual network, i.e. among different VNs.
After a VM is moved to a new NVE, the VM's corresponding Gateway After a VM is moved to a new NVE, the VM's corresponding Gateway
may need to change as well. If such a change is not possible, then may need to change as well. If such a change is not possible, then
the path to the external entity need to be hair-pinned to the NVO3 the path to the external entity need to be hair-pinned to the NVO3
Gateway used prior to the VM move. Gateway used prior to the VM move.
4.2. VM Migration in Layer 2 Network 4.2. VM Migration in Layer 2 Network
Being able to move VMs dynamically, from one server to another,
makes it possible for dynamic load balancing or work distribution.
Therefore, dynamic VM Mobility is highly desirable for large scale
multi-tenant DCs.
In a Layer-2 based approach, VM moving to another NVE does not In a Layer-2 based approach, VM moving to another NVE does not
change its IP address. But this VM is now under a new NVE, change its IP address. But this VM is now under a new NVE,
previously communicating NVEs will continue sending their packets previously communicating NVEs may continue sending their packets
to the Old NVE. Therefore, Address Resolution Protocol (ARP) to the Old NVE. Therefore, Address Resolution Protocol (ARP)
cache in IPv4 [RFC0826] or neighbor cache in IPv6 [RFC4861] in the cache in IPv4 [RFC0826] or neighbor cache in IPv6 [RFC4861] in the
NVEs need to be updated promptly, especially for the NVEs that NVEs that have attached VMs communicating with the VM being moved
have attached VMs communicating with the VM being moved. If the VM need to be updated promptly. If the VM being moved has
being moved has communication with external entities, the NVO3 communication with external entities, the NVO3 gateway needs to be
gateway needs to be notified of the new NVE where the VM is moved notified of the new NVE where the VM is moved to.
to.
Such a change enables those NVEs to encapsulate the outgoing MAC
frames with the current target NVE IP address.
In IPv4, the VM immediately after the move should send a In IPv4, the VM immediately after the move should send a
gratuitous ARP request message containing its IPv4 and Layer 2 MAC gratuitous ARP request message containing its IPv4 and Layer 2 MAC
address in its new NVE. This message's destination address is the address in its new NVE. Upon receiving this message, the New NVE
broadcast address. Upon receiving this message, the New NVE can can update its ARP cache. The New NVE should send a notification
update its cache of mapping MAC with IP. The New NVE should send a of the newly attached VM to the central directory [RFC7067]
notification of the newly attached VM to the central directory embedded in the NVA to update the mapping of the IPv4 address &
[RFC7067] embedded in the NVA to update the mapping of the IPv4 MAC address of the moving VM along with the new NVE address. An
address & MAC address of the moving VM along with the new NVE NVE-to-NVA protocol is used for this purpose [RFC8014]. The old
address. An NVE-to-NVA protocol is used for this purpose NVE, upon a VM is moved away, should send an ARP scan to all its
[RFC8014]. If an NVE has a VM being moved away or detached, the attached VMs to refresh its ARP Cache.
NVE should send an ARP scan to all its attached VMs to refresh its
ARP Cache.
Reverse ARP (RARP) which enables the host to discover its IPv4 Reverse ARP (RARP) which enables the host to discover its IPv4
address when it boots from a local server [RFC0903], is not used address when it boots from a local server [RFC0903], is not used
by VMs if the VM already knows its IPv4 address (most common by VMs if the VM already knows its IPv4 address (most common
scenario). Next, we describe a case where RARP is used. scenario). Next, we describe a case where RARP is used.
There are some vendor deployments (diskless systems or systems There are some vendor deployments (diskless systems or systems
without configuration files) wherein the VM's user, i.e. end-user without configuration files) wherein the VM's user, i.e. end-user
client askes for the same MAC address upon migration. This can be client askes for the same MAC address upon migration. This can be
achieved by the clients sending RARP request message which carries achieved by the clients sending RARP request message which carries
the MAC address looking for an IP address allocation. The server, the MAC address looking for an IP address allocation. The server,
in this case the new NVE needs to communicate with NVA, just like in this case the new NVE needs to communicate with NVA, just like
in the gratuitous ARP case to ensure that the same IPv4 address is in the gratuitous ARP case to ensure that the same IPv4 address is
assigned to the VM. NVA uses the MAC address as the key in the assigned to the VM. NVA uses the MAC address as the key in the
search of ARP cache to find the IP address and informs this to the search of ARP cache to find the IP address and informs this to the
new NVE which in turn sends RARP reply message. This completes IP new NVE which in turn sends RARP reply message. This completes IP
address assignment to the migrating VM. address assignment to the migrating VM.
Other NVEs communicating with this VM could have the old ARP Other NVEs that have attached VMs or the NVO3 Gateway that have
entry. To avoid old ARP entries being used by other NVEs, the old external entities communicating with this VM may still have the
NVE upon discovering a VM is detached should send a notification old ARP entry. To avoid old ARP entries being used by other NVEs,
to all other NVEs and its NVO3 Gateway to time out the ARP cache the old NVE upon discovering a VM is detached should send a
for the VM [RFC8171]. When an NVE (including the old NVE) receives notification to all other NVEs and its NVO3 Gateway to time out
packet or ARP request destined towards a VM (its MAC or IP the ARP cache for the VM [RFC8171]. When an NVE (including the old
address) that is not in the NVE's ARP cache, the NVE should send NVE) receives packet or ARP request destined towards a VM (its MAC
query to NVA's Directory Service to get the associated NVE address or IP address) that is not in the NVE's ARP cache, the NVE should
for the VM. This is how the Old NVE tunneling these in-flight send query to NVA's Directory Service to get the associated NVE
packets to the New NVE to avoid packets loss. address for the VM. This is how the Old NVE tunneling these in-
flight packets to the New NVE to avoid packets loss.
IPv6 operation is slightly different: When VM address is IPv6, the operation is similar:
In IPv6, after the move, the VM immediately sends an unsolicited In IPv6, after the move, the VM immediately sends an unsolicited
neighbor advertisement message containing its IPv6 address and neighbor advertisement message containing its IPv6 address and
Layer-2 MAC address to its new NVE. This message is sent to the Layer-2 MAC address to its new NVE. This message is sent to the
IPv6 Solicited Node Multicast Address corresponding to the target IPv6 Solicited Node Multicast Address corresponding to the target
address which is the VM's IPv6 address. The NVE receiving this address which is the VM's IPv6 address. The NVE receiving this
message should send request to update VM's neighbor cache entry in message should send request to update VM's neighbor cache entry in
the central directory of the NVA. The NVA's neighbor cache entry the central directory of the NVA. The NVA's neighbor cache entry
should include IPv6 address of the VM, MAC address of the VM and should include IPv6 address of the VM, MAC address of the VM and
the NVE IPv6 address. An NVE-to-NVA protocol is used for this the NVE IPv6 address. An NVE-to-NVA protocol is used for this
skipping to change at page 8, line 34 skipping to change at page 8, line 25
Traditional Layer-3 based data center networks usually have all Traditional Layer-3 based data center networks usually have all
hosts (tasks) within one subnet attached to one NVE. By this hosts (tasks) within one subnet attached to one NVE. By this
design, the NVE becomes the default route for all hosts (tasks) design, the NVE becomes the default route for all hosts (tasks)
within the subnet. But this design requires IP address of a host within the subnet. But this design requires IP address of a host
(task) to change after the move to comply with the prefixes of the (task) to change after the move to comply with the prefixes of the
IP address under the new NVE. IP address under the new NVE.
A VM migration in Layer 3 Network solution is to allow IP A VM migration in Layer 3 Network solution is to allow IP
addresses staying the same after moving to different locations. addresses staying the same after moving to different locations.
The Identifier Locator Addressing or ILA [I-D.herbert-nvo3-ila] is The Identifier Locator Addressing or ILA [I-D.herbert-intarea-ila]
one of such solutions. is one of such solutions.
Because broadcasting is not available in Layer-3 based networks, Because broadcasting is not available in Layer-3 based networks,
multicast of neighbor solicitations in IPv6 and ARP for IPv4 would multicast of neighbor solicitations in IPv6 and ARP for IPv4 would
need to be emulated. Scalability of the multicast (such as IPv6 ND need to be emulated. Scalability of the multicast (such as IPv6 ND
and IPv4 ARP) can become problematic because the hosts belonging and IPv4 ARP) can become problematic because the hosts belonging
to one subnet (or one VLAN) can span across many NVEs. Sending to one subnet (or one VLAN) can span across many NVEs. Sending
broadcast traffic to all NVEs can cause unnecessary traffic in the broadcast traffic to all NVEs can cause unnecessary traffic in the
DCN if the hosts belonging to one subnet are only attached to a DCN if the hosts belonging to one subnet are only attached to a
very small number of NVEs. It is preferable to have a directory very small number of NVEs. It is preferable to have a directory
[RFC7067] or NVA to manage the updates to an NVE of the potential [RFC7067] or NVA to manage the updates to an NVE of the potential
skipping to change at page 9, line 37 skipping to change at page 9, line 30
- Configure IPv4/v6 address on the target VM/NVE. - Configure IPv4/v6 address on the target VM/NVE.
- Suspend use of the address on the old NVE. This includes the - Suspend use of the address on the old NVE. This includes the
old NVE sending query to NVA upon receiving packets destined old NVE sending query to NVA upon receiving packets destined
towards the VM being moved away. If there is no response from towards the VM being moved away. If there is no response from
NVA for the new NVE for the VM, the old NVE can only drop the NVA for the new NVE for the VM, the old NVE can only drop the
packets. Referring to the VM State Machine described in packets. Referring to the VM State Machine described in
RFC7666. RFC7666.
- Trigger NVA to push the new NVE-VM mapping to other NVEs which - Trigger NVA to push the new NVE-VM mapping to other NVEs which
have the attached VMs communicating with the VM being moved. have the attached VMs communicating with the VM being moved.
Connection management for the VM being moved involves Connection management for the applications running on the VM being
reestablishing existing TCP connections in the new place. moved involves reestablishing existing TCP connections in the new
place.
The simplest course of action is to drop all TCP connections to The simplest course of action is to drop all TCP connections to
the VM across a migration. If the migrations are relatively rare the applications running on the VM during a migration. If the
events in a data center, impact is relatively small when TCP migrations are relatively rare events in a data center, impact is
connections are automatically closed in the network stack during a relatively small when TCP connections are automatically closed in
migration event. If the applications running are known to handle the network stack during a migration event. If the applications
this gracefully (i.e. reopen dropped connections) then this running are known to handle this gracefully (i.e. reopen dropped
approach may be viable. connections) then this approach may be viable.
More involved approach to connection migration entails pausing the More involved approach to connection migration entails a proxy to
connection, packaging connection state and sending to target, the application (or the application itself) to pause the
instantiating connection state in the peer stack, and restarting connection, package connection state and send to target,
the connection. From the time the connection is paused to the instantiate connection state in the peer stack, and restarting the
time it is running again in the new stack, packets received for connection. From the time the connection is paused to the time it
the connection could be silently dropped. For some period of is running again in the new stack, packets received for the
time, the old stack will need to keep a record of the migrated connection could be silently dropped. For some period of time,
the old stack will need to keep a record of the migrated
connection. If it receives a packet, it can either silently drop connection. If it receives a packet, it can either silently drop
the packet or forward it to the new location, as described in the packet or forward it to the new location, as described in
Section 5. Section 5.
5. Handling Packets in Flight 5. Handling Packets in Flight
The Old NVE may receive packets from the VM's ongoing The Old NVE may receive packets from the VM's ongoing
communications. These packets should not be lost; they should be communications. These packets should not be lost; they should be
sent to the New NVE to be delivered to the VM. The steps involved sent to the New NVE to be delivered to the VM. The steps involved
in handling packets in flight are as follows: in handling packets in flight are as follows:
skipping to change at page 11, line 22 skipping to change at page 11, line 17
The mechanism of transferring VM States and file system is out of The mechanism of transferring VM States and file system is out of
the scope of this document. Referring to RFC7666 for detailed the scope of this document. Referring to RFC7666 for detailed
information. information.
7. Handling of Hot, Warm and Cold VM Mobility 7. Handling of Hot, Warm and Cold VM Mobility
Both Cold and Warm VM mobility (or migration) refers to the VM Both Cold and Warm VM mobility (or migration) refers to the VM
being completely shut down at the Old NVE before restarted at the being completely shut down at the Old NVE before restarted at the
New NVE. Therefore, all transport services to the VM are New NVE. Therefore, all transport services to the VM are
restarted. restarted.
Upon starting at the New NVE, the VM should send an ARP or In this document, all VM mobility is initiated by VM Management
Neighbor Discovery message. Cold VM mobility also allows the Old System. The Cold VM mobility only exchange the needed states
NVE and all communicating NVEs to time out ARP/neighbor cache between the Old NVE and the New NVE after the VM attached to the
entries of the VM. It is necessary for the NVA to push the Old NVE is completely shut down. There is time delay before the
updated ARP/neighbor cache entry to NVEs or for NVEs to pull the new VM is launched. The cold mobility option can be used for non-
updated ARP/neighbor cache entry from NVA. critical applications and services that can tolerate interrupted
TCP connections.
The Cold VM mobility can be facilitated by VM management system to
exchange the needed states between the Old NVE and the New NVE.
The cold mobility option can be used for non-critical applications
and services that can tolerate interrupted TCP connections.
The Warm VM mobility refers to having the backup entities receive The Warm VM mobility refers to having the backup entities receive
backup information at more frequent intervals, so that it can take backup information at more frequent intervals, so that it can take
less time to launch the VM under the new NVE. The duration of the less time to launch the VM under the new NVE and other NVEs that
interval determines the effectiveness (or benefit) of Warm VM communicate with the VM can be notified prior to the VM move. The
mobility. The larger the duration, the less effective the Warm VM duration of the interval determines the effectiveness (or benefit)
mobility option becomes. of Warm VM mobility. The larger the duration, the less effective
the Warm VM mobility option becomes.
For Hot VM Mobility, once a VM moves to a New NVE, the VM IP For Hot VM Mobility, once a VM moves to a New NVE, the VM IP
address does not change and the VM should be able to continue to address does not change and the VM should be able to continue to
receive packets to its address(es). The VM needs to send a receive packets to its address(es). The VM needs to send a
gratuitous Address Resolution message or unsolicited Neighbor gratuitous Address Resolution message or unsolicited Neighbor
Advertisement message upstream after each move. Advertisement message upstream after each move.
Upon starting at the New NVE, the VM should send an ARP or
Neighbor Discovery message. Cold VM mobility also allows the Old
NVE and all communicating NVEs to time out ARP/neighbor cache
entries of the VM. It is necessary for the NVA to push the
updated ARP/neighbor cache entry to NVEs or for NVEs to pull the
updated ARP/neighbor cache entry from NVA.
8. Other Options 8. Other Options
There is also a Hot Standby option in addition to the Hot VM Hot mobility is to enable uninterrupted running of the
Mobility, where there are VMs in both primary and secondary NVEs. application or workload instantiated on the VM when the VM running
They have identical information and can provide services conditions changes, such as utilization overload, hardware running
condition changes, or others.
There is also a Hot Standby option to prevent unexpected failure
conditions, where there are VMs in both primary and secondary
NVEs. They have identical information and can provide services
simultaneously as in load-share mode of operation. If the VM in simultaneously as in load-share mode of operation. If the VM in
the primary NVE fails, there is no need to actively move the VM to the primary NVE fails, there is no need to actively move the VM to
the secondary NVE because the VM in the secondary NVE already the secondary NVE because the VM in the secondary NVE already
contain identical information. The Hot Standby option is the contain identical information. The Hot Standby option is the
costliest mechanism, and hence this option is utilized only for costliest mechanism, and hence this option is utilized only for
mission-critical applications and services. In Hot Standby mission-critical applications and services. In Hot Standby
option, regarding TCP connections, one option is to start with and option, regarding TCP connections, one option is to start with and
maintain TCP connections to two different VMs at the same time. maintain TCP connections to two different VMs at the same time.
The least loaded VM responds first and pickup providing service The least loaded VM responds first and pickup providing service
while the sender (origin) still continues to receive Ack from the while the sender (origin) still continues to receive Ack from the
skipping to change at page 13, line 5 skipping to change at page 13, line 5
In Layer-3 based overlay data center networks, the problem of In Layer-3 based overlay data center networks, the problem of
address spoofing may arise. An NVE may have untrusted VMs address spoofing may arise. An NVE may have untrusted VMs
attached. This usually happens in cases like the VMs running third attached. This usually happens in cases like the VMs running third
party applications. Those untrusted VMs can send falsified ARP party applications. Those untrusted VMs can send falsified ARP
(IPv4) and ND (IPv6) messages, causing NVE, NVO3 Gateway, and NVA (IPv4) and ND (IPv6) messages, causing NVE, NVO3 Gateway, and NVA
to be overwhelmed and not able to perform legitimate functions. to be overwhelmed and not able to perform legitimate functions.
The attacker can intercept, modify, or even stop data in-transit The attacker can intercept, modify, or even stop data in-transit
ARP/ND messages intended for other VNs and initiate DDOS attacks ARP/ND messages intended for other VNs and initiate DDOS attacks
to other VMs attached to the same NVE. to other VMs attached to the same NVE.
The locator-identifier mechanism given as an example (ILA) doesn't
include secure binding. It doesn't discuss how to securely bind
the new locator to the identifier.
This requires VM management system to apply stronger security This requires VM management system to apply stronger security
mechanisms when add a VM to an NVE. VM Management system is out of mechanisms when add a VM to an NVE. VM Management system is out of
scope of this document. scope of this document.
11. IANA Considerations 11. IANA Considerations
This document makes no request to IANA. This document makes no request to IANA.
12. Acknowledgments 12. Acknowledgments
skipping to change at page 15, line 24 skipping to change at page 15, line 24
[RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T.
Narten, "An Architecture for Data-Center Network Narten, "An Architecture for Data-Center Network
Virtualization over Layer 3 (NVO3)", RFC 8014, DOI Virtualization over Layer 3 (NVO3)", RFC 8014, DOI
10.17487/RFC8014, December 2016, <https://www.rfc- 10.17487/RFC8014, December 2016, <https://www.rfc-
editor.org/info/rfc8014>. editor.org/info/rfc8014>.
[RFC8171] D. Eastlake, L. Dunbar, R. Perlman, Y. Li, "Edge Directory [RFC8171] D. Eastlake, L. Dunbar, R. Perlman, Y. Li, "Edge Directory
Assistance Mechanisms", RFC 8171, June 2017 Assistance Mechanisms", RFC 8171, June 2017
14.2. Informative References 14.2. Informative References
[I-D.herbert-nvo3-ila] Herbert, T. and P. Lapukhov, "Identifier- [I-D.herbert-intarea-ila] Herbert, T. and P. Lapukhov, "Identifier-
locator addressing for IPv6", draft-herbert-nvo3-ila-04 locator addressing for IPv6", draft-herbert-intarea-ila -
(work in progress), March 2017. 04 (work in progress), March 2017.
Authors' Addresses Authors' Addresses
Linda Dunbar Linda Dunbar
Futurewei Futurewei
Email: ldunbar@futurewei.com Email: ldunbar@futurewei.com
Behcet Sarikaya Behcet Sarikaya
Denpel Informatique Denpel Informatique
Email: sarikaya@ieee.org Email: sarikaya@ieee.org
 End of changes. 23 change blocks. 
85 lines changed or deleted 94 lines changed or added

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