draft-ietf-lisp-predictive-rlocs-00.txt   draft-ietf-lisp-predictive-rlocs-01.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft lispers.net Internet-Draft lispers.net
Intended status: Experimental P. Pillay-Esnault Intended status: Experimental P. Pillay-Esnault
Expires: December 9, 2017 Huawei Technologies Expires: May 31, 2018 Huawei Technologies
June 7, 2017 November 27, 2017
LISP Predictive RLOCs LISP Predictive RLOCs
draft-ietf-lisp-predictive-rlocs-00 draft-ietf-lisp-predictive-rlocs-01
Abstract Abstract
This specification will describe a method to achieve near-zero packet This specification will describe a method to achieve near-zero packet
loss when an EID is roaming quickly across RLOCs. loss when an EID is roaming quickly across RLOCs.
Requirements Language Requirements Language
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].
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 https://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 December 9, 2017. This Internet-Draft will expire on May 31, 2018.
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 (https://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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Design Details . . . . . . . . . . . . . . . . . . . . . . . 5 4. Design Details . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. RLE Encoding . . . . . . . . . . . . . . . . . . . . . . 5 4.1. RLE Encoding . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Packet Delivery Optimizations . . . . . . . . . . . . . . 6 4.2. Packet Delivery Optimizations . . . . . . . . . . . . . . 6
4.3. Trading Off Replication Cost . . . . . . . . . . . . . . 7 4.3. Trading Off Replication Cost . . . . . . . . . . . . . . 8
5. Directional Paths with Intersections . . . . . . . . . . . . 8 5. Directional Paths with Intersections . . . . . . . . . . . . 9
6. Multicast Considerations . . . . . . . . . . . . . . . . . . 9 6. Multicast Considerations . . . . . . . . . . . . . . . . . . 10
7. Multiple Address-Family Considerations . . . . . . . . . . . 10 7. Multiple Address-Family Considerations . . . . . . . . . . . 11
8. Scaling Considerations . . . . . . . . . . . . . . . . . . . 10 8. Scaling Considerations . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 13 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 13
B.1. Changes to draft-ietf-lisp-predictive-rlocs-00.txt . . . 13 B.1. Changes to draft-ietf-lisp-predictive-rlocs-01.txt . . . 13
B.2. Changes to draft-farinacci-lisp-predictive-rlocs-02.txt . 13 B.2. Changes to draft-ietf-lisp-predictive-rlocs-00.txt . . . 13
B.3. Changes to draft-farinacci-lisp-predictive-rlocs-01.txt . 13 B.3. Changes to draft-farinacci-lisp-predictive-rlocs-02.txt . 14
B.4. Changes to draft-farinacci-lisp-predictive-rlocs-00.txt . 13 B.4. Changes to draft-farinacci-lisp-predictive-rlocs-01.txt . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 B.5. Changes to draft-farinacci-lisp-predictive-rlocs-00.txt . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The LISP architecture [RFC6830] specifies two namespaces, End-Point The LISP architecture [RFC6830] specifies two namespaces, End-Point
IDs (EIDs) and Routing Locators (RLOCs). An EID identifies a node in IDs (EIDs) and Routing Locators (RLOCs). An EID identifies a node in
the network and the RLOC indicates the EID's topological location. the network and the RLOC indicates the EID's topological location.
When an node roams in the network, its EID remains fixed and When an node roams in the network, its EID remains fixed and
unchanged but the RLOCs associated with it change to reflect its new unchanged but the RLOCs associated with it change to reflect its new
topological attachment point. This specification will focus EIDs and topological attachment point. This specification will focus EIDs and
RLOCs residing in separate nodes. An EID is assigned to a host node RLOCs residing in separate nodes. An EID is assigned to a host node
skipping to change at page 4, line 25 skipping to change at page 4, line 25
For the send direction from roaming-EID to any destination can be For the send direction from roaming-EID to any destination can be
accomplish as a local decision. As long as the roaming-EID is in accomplish as a local decision. As long as the roaming-EID is in
signal range to any xTR along the path, it can use it to forward signal range to any xTR along the path, it can use it to forward
packets. The LISP xTR, acting as an ITR, can forward packets to packets. The LISP xTR, acting as an ITR, can forward packets to
destinations in non-LISP sites as well as to stationary and roaming destinations in non-LISP sites as well as to stationary and roaming
EIDs in LISP sites. This is accomplished by using the LISP overlay EIDs in LISP sites. This is accomplished by using the LISP overlay
via dynamic packet encapsulation. When the roaming-EID sends via dynamic packet encapsulation. When the roaming-EID sends
packets, the LISP xTR must discover the EID and MAY register the EID packets, the LISP xTR must discover the EID and MAY register the EID
with a set of RLOCs to the mapping system with a set of RLOCs to the mapping system
[I-D.portoles-lisp-eid-mobility]. The discovery process is important [I-D.ietf-lisp-eid-mobility]. The discovery process is important
because the LISP xTR, acting as an ETR for decapsulating packets that because the LISP xTR, acting as an ETR for decapsulating packets that
arrive, needs to know what local ports or radios to send packets to arrive, needs to know what local ports or radios to send packets to
the roaming-EID. the roaming-EID.
Much of the focus of this design is on the packet direction to the Much of the focus of this design is on the packet direction to the
roaming-EID. And how remote LISP ITRs find the current location roaming-EID. And how remote LISP ITRs find the current location
(RLOCs) quickly when the roaming-EID is moving at high speed. This (RLOCs) quickly when the roaming-EID is moving at high speed. This
specification solves the fast roaming with the introduction of the specification solves the fast roaming with the introduction of the
Predictive-RLOCs algorithm. Predictive-RLOCs algorithm.
skipping to change at page 5, line 17 skipping to change at page 5, line 17
4. Design Details 4. Design Details
Predictive RLOCs accommodates for encapsulated packets to be Predictive RLOCs accommodates for encapsulated packets to be
delivered to Road-Side-Unit LISP xTRs regardless where the roaming- delivered to Road-Side-Unit LISP xTRs regardless where the roaming-
EID is currently positioned. EID is currently positioned.
Referring to Figure 1, the following sequence is performed: Referring to Figure 1, the following sequence is performed:
1. The Predictive RLOCs are registered to the mapping system as a 1. The Predictive RLOCs are registered to the mapping system as a
LCAF encoded Replication List Entry (RLE) Type LCAF encoded Replication List Entry (RLE) Type [RFC8060]. The
[I-D.ietf-lisp-lcaf]. The registration can happen by one or more registration can happen by one or more RSUs or by a third-party.
RSUs or by a third-party. When registered by an RSU, and when no When registered by an RSU, and when no coordination is desired,
coordination is desired, they each register their own RLOC with they each register their own RLOC with merge-semantics so the
merge-semantics so the list can be created and maintained in the list can be created and maintained in the LISP Map-Server. When
LISP Map-Server. When registered by a third-party, the complete registered by a third-party, the complete list of RLOCs can be
list of RLOCs can be included in the RLE. included in the RLE.
2. There can be multiple RLEs present each as different RLOC- 2. There can be multiple RLEs present each as different RLOC-
records so a remote ITR can select one RLOC-record versus the records so a remote ITR can select one RLOC-record versus the
other based in priority and weight policy [RFC6830]. other based in priority and weight policy [RFC6830].
3. When a remote ITR receives a packet destined for a roaming-EID, 3. When a remote ITR receives a packet destined for a roaming-EID,
it encapsulates and replicates to each RLOC in the RLE thereby it encapsulates and replicates to each RLOC in the RLE thereby
delivering the packet to the locations the roaming-EID is about delivering the packet to the locations the roaming-EID is about
to appear. There are some cases where packets will go to to appear. There are some cases where packets will go to
locations where the roaming-EID has already been, but see locations where the roaming-EID has already been, but see
skipping to change at page 5, line 45 skipping to change at page 5, line 45
4. When the ETR resident RSU receives an encapsulated packet, it 4. When the ETR resident RSU receives an encapsulated packet, it
decapsulates the packet and then determines if the roaming-EID decapsulates the packet and then determines if the roaming-EID
had been previously discovered. If the EID has not been had been previously discovered. If the EID has not been
discovered, the ETR drops the packet. Otherwise, the ETR discovered, the ETR drops the packet. Otherwise, the ETR
delivers the decapsulated packet on the port interface the delivers the decapsulated packet on the port interface the
roaming-EID was discovered on. roaming-EID was discovered on.
4.1. RLE Encoding 4.1. RLE Encoding
The LCAF [I-D.ietf-lisp-lcaf] Replication List Entry (RLE) will be The LCAF [RFC8060] Replication List Entry (RLE) will be used to
used to encode the Predictive RLOCs in an RLOC-record for Map- encode the Predictive RLOCs in an RLOC-record for Map-Registers, Map-
Registers, Map-Reply, and Map-Notify messages [RFC6830]. Reply, and Map-Notify messages [RFC6830].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags | | AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 13 | Rsvd2 | 4 + n | | Type = 13 | Rsvd2 | 4 + n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd3 | Rsvd4 | Level Value | | Rsvd3 | Rsvd4 | Level Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 39 skipping to change at page 6, line 39
registrations come at different times and therefore arrive in registrations come at different times and therefore arrive in
different order than the physical RSU path, the level number creates different order than the physical RSU path, the level number creates
the necessary sequencing. Each RSU needs to know its position in the the necessary sequencing. Each RSU needs to know its position in the
path relative to other RSUs. For example, in xTR-B, it would path relative to other RSUs. For example, in xTR-B, it would
register with level 1 since it is after xTR-A (and before xTR-C). So register with level 1 since it is after xTR-A (and before xTR-C). So
if the registration order was xTR-B with level 1, xTR-C with level 2, if the registration order was xTR-B with level 1, xTR-C with level 2,
and xTR-A with level 0, the RLE list stored in the mapping system and xTR-A with level 0, the RLE list stored in the mapping system
would be (xTR-A, xTR-B, xTR-C). It is recommended that level numbers would be (xTR-A, xTR-B, xTR-C). It is recommended that level numbers
be assigned in increments of 10 so latter insertion is possible. be assigned in increments of 10 so latter insertion is possible.
The use of Geo-Prefixes and Geo-Points can be used to compare the The use of Geo-Prefixes and Geo-Points [I-D.farinacci-lisp-geo] can
physical presence of each RSU with respect to each other, so they can be used to compare the physical presence of each RSU with respect to
choose level numbers to sequence themselves. Also if the xTRs each other, so they can choose level numbers to sequence themselves.
register with a Geo-Point in an RLOC-record, then perhaps the Map- Also if the xTRs register with a Geo-Point in an RLOC-record, then
Server could sequence the RLE list. perhaps the Map-Server could sequence the RLE list.
4.2. Packet Delivery Optimizations 4.2. Packet Delivery Optimizations
Since the remote ITR will replicate to all RLOCs in the RLE, a Since the remote ITR will replicate to all RLOCs in the RLE, a
situation is created where packets go to RLOCs that don't need to. situation is created where packets go to RLOCs that don't need to.
For instance, if the roaming-EID is along side of xTR-B and the RLE For instance, if the roaming-EID is along side of xTR-B and the RLE
is (xTR-A, xTR-B, xTR-C), there is no reason to replicate to xTR-A is (xTR-A, xTR-B, xTR-C), there is no reason to replicate to xTR-A
since the roaming-EID has passed it and the the signal range is weak since the roaming-EID has passed it and the the signal range is weak
or lost. However, replicating to xTR-B and xTR-C is important to or lost. However, replicating to xTR-B and xTR-C is important to
deliver packets to where the roaming-EID resides and where it is deliver packets to where the roaming-EID resides and where it is
skipping to change at page 7, line 37 skipping to change at page 7, line 37
header could be used to convey this information to the remote xTR. header could be used to convey this information to the remote xTR.
This would only occur when the roaming-EID was discovered by both This would only occur when the roaming-EID was discovered by both
xTR-A and xTR-B so it was possible for either xTR to reach the xTR-A and xTR-B so it was possible for either xTR to reach the
roaming-EID. Either an IGP like routing protocol would be required roaming-EID. Either an IGP like routing protocol would be required
to allow each xTR to know the other could reach the roaming-EID or a to allow each xTR to know the other could reach the roaming-EID or a
path trace tool (i.e. traceroute) could be originated by one xTR path trace tool (i.e. traceroute) could be originated by one xTR
targeted for the roaming-EID but MAC-forwarded through the other xTR. targeted for the roaming-EID but MAC-forwarded through the other xTR.
These and other roaming-EID reachability mechanisms are work in These and other roaming-EID reachability mechanisms are work in
progress and for further study. progress and for further study.
When a remote ITR is doing "Directional Mobility" and replicating to
the last RLOC in the RLE list, it has a decision to guess where the
roaming-EID will move to next. Conservatively, an ITR can replicate
to the entire set of RLOCs in the RLE list and wait to see if the
roaming-EID moves to one of the RLOCs in the RLE list.
Or more liberally, the remote ITR can assume the new roaming
direction. For example, with an RLE list of (xTR-A, xTR-B, xTR-C,
xTR-D) and the roaming-EID is at D, the remote ITR can replicate to
all of A, B, C and D to determine where the roaming-EID will move to
next. If the roaming-EID moves to C after it was at D, it is
possible that the EID is moving in the opposite direction from C to B
to A. This would be known as "Back-n-Forth Mobility". If an
implementation is configured to support this for a particluar EID,
the remote ITR could replicate in this sequence as the roaming-EID
moves from A to D and back to A: (A, B, C, D), (B, C, D), (C, D), (D,
C, B, A), (C, B, A), (B, A), and again (A, B, C, D).
The roaming-EID could be doing "Circular Mobility" where it moves
from A to D directionally, next from D-to-A, and then back to A to D
directionally again. This form of mobility is just as predicatable
as "Back-n-Forth Mobility" since a consistent pattern can be relied
on. Both of these mobility forms can be achieved with near-zero
packet loss.
On the other hand, the roaming-EID can be roaming arbitrarily using
"Random Mobility" where it could roam in the following combinations:
A-to-B, A-to-C, A-to-D, B-to-A, B-to-C, B-to-D, C-to-A, C-to-B, C-to-
D, D-to-A, D-to-B, or D-to-C. In this situation, when a return
packet arrives at the ITR, it could then just replicate to where the
roaming-EID is at rest and do so for a short period of time before it
replciates to the entire RLE list again. Using the wrong time period
could lead to packet loss. All these types of mobility can be
supported by the remote ITR in a local manner without consulting or
depending on any other LISP system. It is left for further study, if
any of the mobility types above should be encoded in the mapping
system.
4.3. Trading Off Replication Cost 4.3. Trading Off Replication Cost
If RLE lists are large, packet replication can occur to locations If RLE lists are large, packet replication can occur to locations
well before the roaming-EID arrives. Making RLE lists small is well before the roaming-EID arrives. Making RLE lists small is
useful without sacrificing hand-off issues or incurring packet loss useful without sacrificing hand-off issues or incurring packet loss
to the application. By having overlapping RLEs in separate RLOC- to the application. By having overlapping RLEs in separate RLOC-
records we a simple mechanism to solve this problem. Here is an records we a simple mechanism to solve this problem. Here is an
example mapping entry to illustrate the point: example mapping entry to illustrate the point:
EID = <roaming-EID>, RLOC-records: EID = <roaming-EID>, RLOC-records:
skipping to change at page 11, line 40 skipping to change at page 12, line 15
specific EIDs which are on the train. This can be used for specific EIDs which are on the train. This can be used for
inventory, billing, or security purposes. inventory, billing, or security purposes.
This optimization comes at a cost of a 2-stage lookup. However, if This optimization comes at a cost of a 2-stage lookup. However, if
both sets of mapping entries are registered to the same Map-Server, a both sets of mapping entries are registered to the same Map-Server, a
combined RLOC-set could be returned. This idea is for further study. combined RLOC-set could be returned. This idea is for further study.
9. Security Considerations 9. Security Considerations
LISP has procedures for supporting both control-plane security LISP has procedures for supporting both control-plane security
[I-D.ietf-lisp-sec] and data-plane security [I-D.ietf-lisp-crypto]. [I-D.ietf-lisp-sec] and data-plane security [RFC8061].
10. IANA Considerations 10. IANA Considerations
At this time there are no requests for IANA. At this time there are no requests for IANA.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>. <https://www.rfc-editor.org/info/rfc6830>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <https://www.rfc-editor.org/info/rfc8060>.
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
(LISP) Data-Plane Confidentiality", RFC 8061,
DOI 10.17487/RFC8061, February 2017,
<https://www.rfc-editor.org/info/rfc8061>.
11.2. Informative References 11.2. Informative References
[I-D.farinacci-lisp-geo] [I-D.farinacci-lisp-geo]
Farinacci, D., "LISP Geo-Coordinate Use-Cases", draft- Farinacci, D., "LISP Geo-Coordinate Use-Cases", draft-
farinacci-lisp-geo-03 (work in progress), April 2017. farinacci-lisp-geo-04 (work in progress), October 2017.
[I-D.ietf-lisp-crypto] [I-D.ietf-lisp-eid-anonymity]
Farinacci, D. and B. Weis, "LISP Data-Plane Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP
Confidentiality", draft-ietf-lisp-crypto-10 (work in EID Anonymity", draft-ietf-lisp-eid-anonymity-01 (work in
progress), October 2016. progress), October 2017.
[I-D.ietf-lisp-lcaf] [I-D.ietf-lisp-eid-mobility]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
Address Format (LCAF)", draft-ietf-lisp-lcaf-22 (work in F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
progress), November 2016. Unified Control Plane", draft-ietf-lisp-eid-mobility-01
(work in progress), November 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-14
(work in progress), November 2016. (work in progress), October 2017.
[I-D.ietf-lisp-signal-free-multicast] [I-D.ietf-lisp-signal-free-multicast]
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
draft-ietf-lisp-signal-free-multicast-04 (work in draft-ietf-lisp-signal-free-multicast-06 (work in
progress), May 2017. progress), August 2017.
[I-D.portoles-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-portoles-lisp-eid-
mobility-02 (work in progress), April 2017.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The author would like to thank the LISP WG for their review and The author would like to thank the LISP WG for their review and
acceptance of this draft. acceptance of this draft.
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-predictive-rlocs-00.txt B.1. Changes to draft-ietf-lisp-predictive-rlocs-01.txt
o Posted November 2017.
o Update document timer and references.
o Reflect comments from Prague meeting presentation. There is no
need for "RLE Usage Types" as suggested. The ITR can treat what
RLOCs it replicates to as a local matter via implementation
configuration. RLE Directional is default. Circular rotation,
back-n-forth, and random selection of RLOCs is up to the ITR.
B.2. Changes to draft-ietf-lisp-predictive-rlocs-00.txt
o Posted June 2017. o Posted June 2017.
o Make this specification a working group document. It is a copy of o Make this specification a working group document. It is a copy of
draft-farinacci-lisp-predictive-rlocs-02. draft-farinacci-lisp-predictive-rlocs-02.
B.2. Changes to draft-farinacci-lisp-predictive-rlocs-02.txt B.3. Changes to draft-farinacci-lisp-predictive-rlocs-02.txt
o Posted May 2017 to update document timer. o Posted May 2017 to update document timer.
B.3. Changes to draft-farinacci-lisp-predictive-rlocs-01.txt B.4. Changes to draft-farinacci-lisp-predictive-rlocs-01.txt
o Posted November 2016 to update document timer. o Posted November 2016 to update document timer.
B.4. Changes to draft-farinacci-lisp-predictive-rlocs-00.txt B.5. Changes to draft-farinacci-lisp-predictive-rlocs-00.txt
o Initial post April 2016. o Initial post April 2016.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
lispers.net lispers.net
San Jose, CA San Jose, CA
USA USA
 End of changes. 25 change blocks. 
63 lines changed or deleted 118 lines changed or added

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