idnits 2.17.1 draft-farinacci-lisp-predictive-rlocs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 13, 2016) is 2718 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-15) exists of draft-farinacci-lisp-geo-02 == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-20 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-11 == Outdated reference: A later version (-09) exists of draft-ietf-lisp-signal-free-multicast-02 == Outdated reference: A later version (-02) exists of draft-portoles-lisp-eid-mobility-01 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Experimental P. Pillay-Esnault 5 Expires: May 17, 2017 Huawei Technologies 6 November 13, 2016 8 LISP Predictive RLOCs 9 draft-farinacci-lisp-predictive-rlocs-01 11 Abstract 13 This specification will describe a method to achieve near-zero packet 14 loss when an EID is roaming quickly across RLOCs. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in [RFC2119]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 17, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Design Details . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. RLE Encoding . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. Packet Delivery Optimizations . . . . . . . . . . . . . . 6 62 4.3. Trading Off Replication Cost . . . . . . . . . . . . . . 7 63 5. Directional Paths with Intersections . . . . . . . . . . . . 8 64 6. Multicast Considerations . . . . . . . . . . . . . . . . . . 9 65 7. Multiple Address-Family Considerations . . . . . . . . . . . 10 66 8. Scaling Considerations . . . . . . . . . . . . . . . . . . . 10 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 11.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 73 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 13 74 B.1. Changes to draft-farinacci-lisp-predictive-rlocs-01.txt . 13 75 B.2. Changes to draft-farinacci-lisp-predictive-rlocs-00.txt . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 The LISP architecture [RFC6830] specifies two namespaces, End-Point 81 IDs (EIDs) and Routing Locators (RLOCs). An EID identifies a node in 82 the network and the RLOC indicates the EID's topological location. 83 When an node roams in the network, its EID remains fixed and 84 unchanged but the RLOCs associated with it change to reflect its new 85 topological attachment point. This specification will focus EIDs and 86 RLOCs residing in separate nodes. An EID is assigned to a host node 87 that roams while the RLOCs are assigned to network nodes that stay 88 stationary and are part of the network topology. For example, a set 89 of devices on an aircraft are assigned EIDs, and base stations on the 90 ground attached to the Internet infrastructure are configured as LISP 91 xTRs where their RLOCs are used for the bindings of the EIDs on the 92 aircraft up in the air. 94 The scope of this specification will not emphasize general physical 95 roaming as an aircraft would do in the sky but in a direction that is 96 more predictable such as a train traveling on a track or vehicle that 97 travels along a road. 99 2. Definition of Terms 101 Roaming-EID - is a network node that moves from one topological 102 location in the network to another. The network node uses the 103 same EID when it is roaming. That is, the EID address does not 104 change for reasons of mobility. A roaming-EID can also be a 105 roaming EID-prefix where a set of EIDs covered by the prefix are 106 all roaming and fate-sharing the same set of RLOCs at the same 107 time. 109 Predictive RLOCs - is a set of ordered RLOCs in a list each assigned 110 to LISP xTRs where the next RLOC in the list has high probability 111 it will be the next LISP xTR in a physical path going in a single 112 predictable direction. 114 Road-Side-Units (RSUs) - is a network node that acts as a router, 115 more specifically as a LISP xTR. The xTR automatically discovers 116 roaming-EIDs that come into network connectivity range and relays 117 packets to and from the roaming-EID. RSUs are typically deployed 118 along a directional path like a train track or road and are in 119 connectivity range of devices that travel along the directional 120 path. 122 3. Overview 124 The goal of this specification is to describe a make-before-break 125 EID-mobility mechanism that offers near-zero packet loss. Offering 126 minimal packet loss, not only allows transport layers to operate more 127 efficiently, but because an EID does not change while moving, 128 transport layer session continuity is maintained. To achieve these 129 requirements, a mechanism that reacts to the mobility event is 130 necessary but not sufficient. So the question is not that there 131 isn't a reaction but when it happens. By using some predictive 132 algorithms, we can guess with high probability where the EID will 133 roam to next. We can achieve this to a point where packet data will 134 be at the new location when the EID arrives. 136 First we should examine both the send and receive directions with 137 respect to the roaming-EID. Refer to Figure 1 for discussion. We 138 show a network node with a fixed EID address assigned to a roaming- 139 EID moving along a train track. And there are LISP xTRs deployed as 140 Road-Side-Units to support the connectivity between the roaming-EID 141 and the infrastructure or to another roaming-EID. 143 Roaming-EID ----> 145 ====//====//====//====//====//====//====//====//===//====//====//==== 146 // // // // // // // // // // // 147 ====//====//====//====//====//====//====//====//===//====//====//==== 149 xTR xTR xTR xTR xTR xTR 150 A B C D E F 152 Figure 1: Directional Mobility 154 For the send direction from roaming-EID to any destination can be 155 accomplish as a local decision. As long as the roaming-EID is in 156 signal range to any xTR along the path, it can use it to forward 157 packets. The LISP xTR, acting as an ITR, can forward packets to 158 destinations in non-LISP sites as well as to stationary and roaming 159 EIDs in LISP sites. This is accomplished by using the LISP overlay 160 via dynamic packet encapsulation. When the roaming-EID sends 161 packets, the LISP xTR must discover the EID and MAY register the EID 162 with a set of RLOCs to the mapping system 163 [I-D.portoles-lisp-eid-mobility]. The discovery process is important 164 because the LISP xTR, acting as an ETR for decapsulating packets that 165 arrive, needs to know what local ports or radios to send packets to 166 the roaming-EID. 168 Much of the focus of this design is on the packet direction to the 169 roaming-EID. And how remote LISP ITRs find the current location 170 (RLOCs) quickly when the roaming-EID is moving at high speed. This 171 specification solves the fast roaming with the introduction of the 172 Predictive-RLOCs algorithm. 174 Since a safe assumption is that the roaming-EID is going in one 175 direction and cannot deviate from it allows us to know a priori the 176 next set of RLOCs the roaming-EID will pass by. Referring to 177 Figure 1, if the roaming-EID is in range near xTR-A, then as it 178 moves, it will at some point pass by xTR-B and xTR-C, and so on. As 179 the roaming-EID moves, one could time when the EID is mapped to RLOC 180 A, and when it should change to RLOC B and so on. However, the speed 181 of movement of the roaming-EID won't be constant and the variables 182 involved in consistent timing cannot be relied on. Furthermore, 183 timing the move is not a make-before-break algorithm, meaning the 184 reaction of the binding happens at the time the roaming-EID is 185 discovered by an xTR. One cannot achieve fast hand-offs when message 186 signaling will be required to inform remote ITRs of the new binding. 188 The Predictive RLOCs algorithm allows a set of RLOCs, in an ordered 189 list, to be provided to remote ITRs so they have the information 190 available and local for when they need to use it. Therefore, no 191 control-plane message signaling occurs when the roaming-EID is 192 discovered by LISP xTRs. 194 4. Design Details 196 Predictive RLOCs accommodates for encapsulated packets to be 197 delivered to Road-Side-Unit LISP xTRs regardless where the roaming- 198 EID is currently positioned. 200 Referring to Figure 1, the following sequence is performed: 202 1. The Predictive RLOCs are registered to the mapping system as a 203 LCAF encoded Replication List Entry (RLE) Type 204 [I-D.ietf-lisp-lcaf]. The registration can happen by one or more 205 RSUs or by a third-party. When registered by an RSU, and when no 206 coordination is desired, they each register their own RLOC with 207 merge-semantics so the list can be created and maintained in the 208 LISP Map-Server. When registered by a third-party, the complete 209 list of RLOCs can be included in the RLE. 211 2. There can be multiple RLEs present each as different RLOC- 212 records so a remote ITR can select one RLOC-record versus the 213 other based in priority and weight policy [RFC6830]. 215 3. When a remote ITR receives a packet destined for a roaming-EID, 216 it encapsulates and replicates to each RLOC in the RLE thereby 217 delivering the packet to the locations the roaming-EID is about 218 to appear. There are some cases where packets will go to 219 locations where the roaming-EID has already been, but see 220 Section 4.2 for packet delivery optimizations. 222 4. When the ETR resident RSU receives an encapsulated packet, it 223 decapsulates the packet and then determines if the roaming-EID 224 had been previously discovered. If the EID has not been 225 discovered, the ETR drops the packet. Otherwise, the ETR 226 delivers the decapsulated packet on the port interface the 227 roaming-EID was discovered on. 229 4.1. RLE Encoding 231 The LCAF [I-D.ietf-lisp-lcaf] Replication List Entry (RLE) will be 232 used to encode the Predictive RLOCs in an RLOC-record for Map- 233 Registers, Map-Reply, and Map-Notify messages [RFC6830]. 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | AFI = 16387 | Rsvd1 | Flags | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Type = 13 | Rsvd2 | 4 + n | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Rsvd3 | Rsvd4 | Level Value | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | AFI = x | RTR/ETR #1 ... | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Rsvd3 | Rsvd4 | Level Value | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | AFI = x | RTR/ETR #n ... | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 When the RLOC-record contains an RLE with RLOC entries all with the 252 same level value, it means the physical order listed is the 253 directional path of the RSUs. This will typically be the result of a 254 third-party doing the registration where it knows ahead of time the 255 RSU deployment. 257 When each RSU is registering with merge-semantics on their own, the 258 level number is used to place them in an ordered list. Since the 259 registrations come at different times and therefore arrive in 260 different order than the physical RSU path, the level number creates 261 the necessary sequencing. Each RSU needs to know its position in the 262 path relative to other RSUs. For example, in xTR-B, it would 263 register with level 1 since it is after xTR-A (and before xTR-C). So 264 if the registration order was xTR-B with level 1, xTR-C with level 2, 265 and xTR-A with level 0, the RLE list stored in the mapping system 266 would be (xTR-A, xTR-B, xTR-C). It is recommended that level numbers 267 be assigned in increments of 10 so latter insertion is possible. 269 The use of Geo-Prefixes and Geo-Points can be used to compare the 270 physical presence of each RSU with respect to each other, so they can 271 choose level numbers to sequence themselves. Also if the xTRs 272 register with a Geo-Point in an RLOC-record, then perhaps the Map- 273 Server could sequence the RLE list. 275 4.2. Packet Delivery Optimizations 277 Since the remote ITR will replicate to all RLOCs in the RLE, a 278 situation is created where packets go to RLOCs that don't need to. 279 For instance, if the roaming-EID is along side of xTR-B and the RLE 280 is (xTR-A, xTR-B, xTR-C), there is no reason to replicate to xTR-A 281 since the roaming-EID has passed it and the the signal range is weak 282 or lost. However, replicating to xTR-B and xTR-C is important to 283 deliver packets to where the roaming-EID resides and where it is 284 about to go to. 286 A simple data-plane option, which converges fairly quickly is to have 287 the remote xTR, acting as an ETR, when packets are sent from the 288 roaming-EID, examine the source RLOC in the outer header of the 289 encapsulated packet. If the source RLOC is xTR-B, the remote xTR can 290 determine that the roaming-EID has moved past xTR-A and no longer 291 needs to encapsulate packets to xTR-A's RLOC. 293 In addition, the remote ITR can use RLOC-probing to determine if each 294 RLOC in the RLE is reachable. And if not reachable, exclude from the 295 list of RLOCs to replicate to. 297 This solution also handles the case where xTR-A and xTR-B may overlap 298 in radio signal range, but the signal is weak from the roaming-EID to 299 xTR-A but stronger to xTR-B. In this case, the roaming-EID selects 300 xTR-B to send packets that inform the remote xTR that return packets 301 should not be encapsulated to xTR-A. 303 There are also situations where the RSUs are in signal range of each 304 other in which case they could report reachability status of each 305 other. The use of the Locator-Status-Bits of the LISP encapsulation 306 header could be used to convey this information to the remote xTR. 307 This would only occur when the roaming-EID was discovered by both 308 xTR-A and xTR-B so it was possible for either xTR to reach the 309 roaming-EID. Either an IGP like routing protocol would be required 310 to allow each xTR to know the other could reach the roaming-EID or a 311 path trace tool (i.e. traceroute) could be originated by one xTR 312 targeted for the roaming-EID but MAC-forwarded through the other xTR. 313 These and other roaming-EID reachability mechanisms are work in 314 progress and for further study. 316 4.3. Trading Off Replication Cost 318 If RLE lists are large, packet replication can occur to locations 319 well before the roaming-EID arrives. Making RLE lists small is 320 useful without sacrificing hand-off issues or incurring packet loss 321 to the application. By having overlapping RLEs in separate RLOC- 322 records we a simple mechanism to solve this problem. Here is an 323 example mapping entry to illustrate the point: 325 EID = , RLOC-records: 326 RLOC = (RLE: xTR-A, xTR-B) 327 RLOC = (RLE: xTR-B, xTR-C, xTR-D, xTR-E) 328 RLOC = (RLE: xTR-E, xTR-F) 330 When the remote ITR is encapsulating to xTR-B as a decision to use 331 the first RLOC-record, it can decide to move to use the second RLOC- 332 record because xTR-B is the last entry in the first RLOC-record and 333 the first entry in the second RLOC-record. When there are 334 overlapping RLEs, the remote ITR can decide when it is more efficient 335 to switch over. For example, when the roaming-EID is in range of 336 xTR-A, the remote ITR uses the first RLOC-record so the wasted 337 replication cost is to xTR-B only versus a worse cost when using the 338 second RLOC-record. But when the roaming-EID is in range of xTR-B, 339 then replicating to the other xTRs in the second RLOC-record may be 340 crucial if the roaming-EID has increased speed. And when the 341 roaming-EID may be at rest in a parked mode, then the remote ITR 342 encapsulates to only xTR-F using the third RLOC-record since the 343 roaming-EID has moved past xTR-E. 345 In addition, to eliminate unnecessary replication to xTRs further 346 down a directional path, GEO-prefixes [I-D.farinacci-lisp-geo] can be 347 used so only nearby xTRs that the roaming-EID is about to come in 348 contact with are the only ones to receive encapsulated packets. 350 Even when replication lists are not large, we can reduce the cost of 351 replication that the entire network bears by moving the replicator 352 away from the the source (i.e. the ITR) and closer to the RSUs (i.e. 353 the ETRs). See the use of RTRs for Replication Engineering 354 techniques in [I-D.ietf-lisp-signal-free-multicast]. 356 5. Directional Paths with Intersections 358 A roaming-EID could be registered to the mapping system with the 359 following nested RLE mapping: 361 EID = , RLOC-records: 362 RLOC = (RLE: xTR-A, xTR-B, xTR-C, (RLE: xTR-X, xTR-Y, xTR-Z), 363 (RLE: xTR-I, xTR-J, xTR-K), xTR-D, xTR-E) 365 The mapping entry above describes 3 directional paths where the 366 ordered list has encoded one-level of two nested RLEs to denote 367 intersections in a horizontal path. Which is drawn as: 369 | | xTR-K 370 | | 371 | | 372 | | xTR-J 373 | | 374 | | 375 Roaming | | xTR-I 376 EID ----> | | 377 --------------------------------------- ------------------------------ 378 --------------------------------------- ------------------------------ 379 xTR-A xTR-B xTR-C | | xTR-D xTR-E 380 | | 381 | | xTR-X 382 | | 383 | | 384 | | xTR-Y 385 | | 386 | | 387 | | xTR-Z 389 When the roaming-EID is on the horizontal path, the remote-ITRs 390 typically replicate to the rest the of the xTRs in the ordered list. 391 When a list has nested RLEs, the replication should occur to at least 392 the first RLOC in a nested RLE list. So if the remote-ITR is 393 replicating to xTR-C, xTR-D, and xTR-E, it should also replicate to 394 xTR-X and xTR-I anticipating a possible turn at the intersection. 395 But when the roaming-EID is known to be at xTR-D (a left or right 396 hand turn was not taken), replication should only occur to xTR-D and 397 xTR-E. Once either xTR-I or xTR-X is determined to be where the 398 roaming-EID resides, then the replication occurs on the respective 399 directional path only. 401 When nested RLEs are used it may be difficult to get merge-semantics 402 to work when each xTR registers itself. So it is suggested a third- 403 party registers nested RLEs. It is left to further study to 404 understand better how to automate this. 406 6. Multicast Considerations 408 In this design, the remote ITR is receiving a unicast packet from an 409 EID and replicating and encapsulating to each RLOC in an RLE list. 410 This form of replication is no different than a traditional multicast 411 replication function. So replicating multicast packets in the same 412 fashion is a fallout from this design. 414 If there are multiple roaming-EIDs joined to the same multicast group 415 but reside at different RSUs, a merge has to be done of any pruned 416 RLEs used for forwarding. So if roaming-EID-1 resides at xTR-A and 417 roaming-EID-2 resides at xTR-B and the RLE list is (xTR-A, xTR-B, 418 xTR-C), and they are joined to the same multicast group, then 419 replication occurs to all of xTR-A, xTR-B, and xTR-C. Even since 420 roaming-EID-2 is past xTR-A, packets need to be delivered to xTR-A 421 for roaming-EID-1. In addition, packets need to be delivered to 422 xTR-C because roaming-EID-1 and roaming-EID-2 will get to xTR-C (and 423 roaming-EID-1 may get there sooner if it is traveling faster than 424 roaming-EID-2). 426 When a roaming-EID is a multicast source, procedures from 427 [I-D.ietf-lisp-signal-free-multicast] are used to deliver packets to 428 multicast group members anywhere in the network. The solution 429 requires no signaling to the RSUs. When RSUs receive multicast 430 packets from a roaming-EID, they do a (roaming-EID,G) mapping 431 database lookup to find the replication list of ETRs to encapsulate 432 to. 434 7. Multiple Address-Family Considerations 436 Note that roaming-EIDs can be assigned IPv6 EID addresses while the 437 RSU xTRs could be using IPv4 RLOC addresses. Any combination of 438 address-families can be supported as well as for multicast packet 439 forwarding, where (S,G) are IPv6 addresses entries and replication is 440 done with IPv4 RLOCs in the outer header. 442 8. Scaling Considerations 444 One can imagine there will be a large number of roaming-EIDs. So 445 there is a strong desire to efficiently store state in the mapping 446 database and the in remote ITRs map-caches. It is likely, that 447 roaming-EIDs may share the same path and move at the same speed (EID 448 devices on a train) and therefore share the same Predictive RLOCs. 449 And since EIDs are not reassigned for mobility purposes or may be 450 temporal , they will not be topologically aggregatable, so they 451 cannot compress into a single EID-prefix mapping entry that share the 452 same RLOC-set. 454 By using a level of indirection with the mapping system this problem 455 can be solved. The following mapping entries could exist in the 456 mapping database: 458 EID = , RLOC-records: 459 RLOC = (afi=: "am-train-to-paris") 460 EID = , RLOC-records: 461 RLOC = (afi=: "am-train-to-paris") 462 EID = , RLOC-records: 463 RLOC = (afi=: "am-train-to-paris") 465 EID = "am-train-to-paris", RLOC-records: 466 RLOC = (afi=lcaf/RLE-type: xTR-A, xTR-B, xTR-C) 468 EID = "am-train-to-paris-passengers", RLOC-records: 469 RLOC = (afi=lcaf/afi-list-type: , , ) 471 Each passenger that boards a train has their EID registered to point 472 to the name of the train "am-train-to-paris". And then the train 473 with EID "am-train-to-paris" stores the Predictive RLOC-set. When a 474 remote-ITR wants to encapsulate packets for an EID, it looks up the 475 EID in the mapping database gets the name "am-train-to-paris" 476 returned. Then the remote-ITR does another lookup for the name "am- 477 train-to-paris" to get the RLE list returned. 479 When new EIDs board the train, the RLE mapping entry does not need to 480 be modified. Only an EID-to-name mapping is registered for the 481 specific new EID. Optionally, another name "am-train-to-paris- 482 passengers" can be registered as an EID to allow mapping to all 483 specific EIDs which are on the train. This can be used for 484 inventory, billing, or security purposes. 486 This optimization comes at a cost of a 2-stage lookup. However, if 487 both sets of mapping entries are registered to the same Map-Server, a 488 combined RLOC-set could be returned. This idea is for further study. 490 9. Security Considerations 492 LISP has procedures for supporting both control-plane security 493 [I-D.ietf-lisp-sec] and data-plane security [I-D.ietf-lisp-crypto]. 495 10. IANA Considerations 497 At this time there are no requests for IANA. 499 11. References 501 11.1. Normative References 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, 505 DOI 10.17487/RFC2119, March 1997, 506 . 508 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 509 Locator/ID Separation Protocol (LISP)", RFC 6830, 510 DOI 10.17487/RFC6830, January 2013, 511 . 513 11.2. Informative References 515 [I-D.farinacci-lisp-geo] 516 Farinacci, D., "LISP Geo-Coordinate Use-Cases", draft- 517 farinacci-lisp-geo-02 (work in progress), October 2016. 519 [I-D.ietf-lisp-crypto] 520 Farinacci, D. and B. Weis, "LISP Data-Plane 521 Confidentiality", draft-ietf-lisp-crypto-10 (work in 522 progress), October 2016. 524 [I-D.ietf-lisp-lcaf] 525 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 526 Address Format (LCAF)", draft-ietf-lisp-lcaf-20 (work in 527 progress), October 2016. 529 [I-D.ietf-lisp-sec] 530 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 531 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-11 532 (work in progress), October 2016. 534 [I-D.ietf-lisp-signal-free-multicast] 535 Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", 536 draft-ietf-lisp-signal-free-multicast-02 (work in 537 progress), October 2016. 539 [I-D.portoles-lisp-eid-mobility] 540 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 541 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 542 Unified Control Plane", draft-portoles-lisp-eid- 543 mobility-01 (work in progress), October 2016. 545 Appendix A. Acknowledgments 547 The author would like to thank the LISP WG for their review and 548 acceptance of this draft. 550 Appendix B. Document Change Log 552 [RFC Editor: Please delete this section on publication as RFC.] 554 B.1. Changes to draft-farinacci-lisp-predictive-rlocs-01.txt 556 o Posted November 2016 to update document timer. 558 B.2. Changes to draft-farinacci-lisp-predictive-rlocs-00.txt 560 o Initial post April 2016. 562 Authors' Addresses 564 Dino Farinacci 565 lispers.net 566 San Jose, CA 567 USA 569 Email: farinacci@gmail.com 571 Padma Pillay-Esnault 572 Huawei Technologies 573 San Clara, CA 574 USA 576 Email: padma@huawei.com