idnits 2.17.1 draft-ietf-lisp-predictive-rlocs-10.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 (April 11, 2022) is 745 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-lisp-eid-anonymity' is defined on line 582, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-15) exists of draft-farinacci-lisp-geo-13 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-eid-anonymity-12 == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-09 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-25 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: October 13, 2022 Independent 6 April 11, 2022 8 LISP Predictive RLOCs 9 draft-ietf-lisp-predictive-rlocs-10 11 Abstract 13 This specification describes 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 https://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 October 13, 2022. 39 Copyright Notice 41 Copyright (c) 2022 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Packet Delivery Optimizations . . . . . . . . . . . . . . 7 62 4.3. Trading Off Replication Cost . . . . . . . . . . . . . . 8 63 5. Directional Paths with Intersections . . . . . . . . . . . . 9 64 6. Multicast Considerations . . . . . . . . . . . . . . . . . . 10 65 7. Multiple Address-Family Considerations . . . . . . . . . . . 11 66 8. Scaling Considerations . . . . . . . . . . . . . . . . . . . 11 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 11.2. Informative References . . . . . . . . . . . . . . . . . 13 72 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14 73 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 14 74 B.1. Changes to draft-ietf-lisp-predictive-rlocs-10 . . . . . 14 75 B.2. Changes to draft-ietf-lisp-predictive-rlocs-09 . . . . . 14 76 B.3. Changes to draft-ietf-lisp-predictive-rlocs-08 . . . . . 14 77 B.4. Changes to draft-ietf-lisp-predictive-rlocs-07 . . . . . 14 78 B.5. Changes to draft-ietf-lisp-predictive-rlocs-06 . . . . . 14 79 B.6. Changes to draft-ietf-lisp-predictive-rlocs-05 . . . . . 14 80 B.7. Changes to draft-ietf-lisp-predictive-rlocs-04 . . . . . 15 81 B.8. Changes to draft-ietf-lisp-predictive-rlocs-03 . . . . . 15 82 B.9. Changes to draft-ietf-lisp-predictive-rlocs-02 . . . . . 15 83 B.10. Changes to draft-ietf-lisp-predictive-rlocs-01 . . . . . 15 84 B.11. Changes to draft-ietf-lisp-predictive-rlocs-00 . . . . . 15 85 B.12. Changes to draft-farinacci-lisp-predictive-rlocs-02 . . . 15 86 B.13. Changes to draft-farinacci-lisp-predictive-rlocs-01 . . . 15 87 B.14. Changes to draft-farinacci-lisp-predictive-rlocs-00 . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 The LISP architecture [RFC6830] specifies two namespaces, End-Point 93 IDs (EIDs) and Routing Locators (RLOCs). An EID identifies a node in 94 the network and the RLOC indicates the EID's topological location. 95 When an node roams in the network, its EID remains fixed and 96 unchanged but the RLOCs associated with it change to reflect its new 97 topological attachment point. This specification will focus EIDs and 98 RLOCs residing in separate nodes. An EID is assigned to a host node 99 that roams while the RLOCs are assigned to network nodes that stay 100 stationary and are part of the network topology. For example, a set 101 of devices on an aircraft are assigned EIDs, and base stations on the 102 ground attached to the Internet infrastructure are configured as LISP 103 xTRs where their RLOCs are used for the bindings of the EIDs on the 104 aircraft up in the air. 106 The scope of this specification will not emphasize general physical 107 roaming as an aircraft would do in the sky but in a direction that is 108 more predictable such as a train traveling on a track or vehicle that 109 travels along a road. 111 2. Definition of Terms 113 Roaming-EID - is a network node that moves from one topological 114 location in the network to another. The network node uses the 115 same EID when it is roaming. That is, the EID address does not 116 change for reasons of mobility. A roaming-EID can also be a 117 roaming EID-prefix where a set of EIDs covered by the prefix are 118 all roaming and fate-sharing the same set of RLOCs at the same 119 time. 121 Predictive RLOCs - is a set of ordered RLOCs in a list each assigned 122 to LISP xTRs where the next RLOC in the list has high probability 123 it will be the next LISP xTR in a physical path going in a single 124 predictable direction. 126 Road-Side-Units (RSUs) - is a network node that acts as a router, 127 more specifically as a LISP xTR. The xTR automatically discovers 128 roaming-EIDs that come into network connectivity range and relays 129 packets to and from the roaming-EID. RSUs are typically deployed 130 along a directional path like a train track or road and are in 131 connectivity range of devices that travel along the directional 132 path. 134 3. Overview 136 The goal of this specification is to describe a make-before-break 137 EID-mobility mechanism that offers near-zero packet loss. Offering 138 minimal packet loss, not only allows transport layers to operate more 139 efficiently, but because an EID does not change while moving, 140 transport layer session continuity is maintained. To achieve these 141 requirements, a mechanism that reacts to the mobility event is 142 necessary but not sufficient. So the question is not that there 143 isn't a reaction but when it happens. By using some predictive 144 algorithms, we can guess with high probability where the EID will 145 roam to next. We can achieve this to a point where packet data will 146 be at the new location when the EID arrives. 148 First we should examine both the send and receive directions with 149 respect to the roaming-EID. Refer to Figure 1 for discussion. We 150 show a network node with a fixed EID address assigned to a roaming- 151 EID moving along a train track. And there are LISP xTRs deployed as 152 Road-Side-Units to support the connectivity between the roaming-EID 153 and the infrastructure or to another roaming-EID. 155 Roaming-EID ----> 157 ====//====//====//====//====//====//====//====//===//====//====//==== 158 // // // // // // // // // // // 159 ====//====//====//====//====//====//====//====//===//====//====//==== 161 xTR xTR xTR xTR xTR xTR 162 A B C D E F 164 Figure 1: Directional Mobility 166 For the send direction from roaming-EID to any destination can be 167 accomplish as a local decision. As long as the roaming-EID is in 168 signal range to any xTR along the path, it can use it to forward 169 packets. The LISP xTR, acting as an ITR, can forward packets to 170 destinations in non-LISP sites as well as to stationary and roaming 171 EIDs in LISP sites. This is accomplished by using the LISP overlay 172 via dynamic packet encapsulation. When the roaming-EID sends 173 packets, the LISP xTR must discover the EID and MAY register the EID 174 with a set of RLOCs to the mapping system 175 [I-D.ietf-lisp-eid-mobility]. The discovery process is important 176 because the LISP xTR, acting as an ETR for decapsulating packets that 177 arrive, needs to know what local ports or radios to send packets to 178 the roaming-EID. 180 Much of the focus of this design is on the packet direction to the 181 roaming-EID. And how remote LISP ITRs find the current location 182 (RLOCs) quickly when the roaming-EID is moving at high speed. This 183 specification solves the fast roaming with the introduction of the 184 Predictive-RLOCs algorithm. 186 Since a safe assumption is that the roaming-EID is going in one 187 direction and cannot deviate from it allows us to know a priori the 188 next set of RLOCs the roaming-EID will pass by. Referring to 189 Figure 1, if the roaming-EID is in range near xTR-A, then as it 190 moves, it will at some point pass by xTR-B and xTR-C, and so on. As 191 the roaming-EID moves, one could time when the EID is mapped to RLOC 192 A, and when it should change to RLOC B and so on. However, the speed 193 of movement of the roaming-EID won't be constant and the variables 194 involved in consistent timing cannot be relied on. Furthermore, 195 timing the move is not a make-before-break algorithm, meaning the 196 reaction of the binding happens at the time the roaming-EID is 197 discovered by an xTR. One cannot achieve fast hand-offs when message 198 signaling will be required to inform remote ITRs of the new binding. 200 The Predictive RLOCs algorithm allows a set of RLOCs, in an ordered 201 list, to be provided to remote ITRs so they have the information 202 available and local for when they need to use it. Therefore, no 203 control-plane message signaling occurs when the roaming-EID is 204 discovered by LISP xTRs. 206 4. Design Details 208 Predictive RLOCs accommodates for encapsulated packets to be 209 delivered to Road-Side-Unit LISP xTRs regardless where the roaming- 210 EID is currently positioned. 212 Referring to Figure 1, the following sequence is performed: 214 1. The Predictive RLOCs are registered to the mapping system as a 215 LCAF encoded Replication List Entry (RLE) Type [RFC8060]. The 216 registration can happen by one or more RSUs or by a third-party. 217 When registered by an RSU, and when no coordination is desired, 218 they each register their own RLOC with merge-semantics so the 219 list can be created and maintained in the LISP Map-Server. When 220 registered by a third-party, the complete list of RLOCs can be 221 included in the RLE. 223 2. There can be multiple RLEs present each as different RLOC- 224 records so a remote ITR can select one RLOC-record versus the 225 other based in priority and weight policy [RFC6830]. 227 3. When a remote ITR receives a packet destined for a roaming-EID, 228 it encapsulates and replicates to each RLOC in the RLE thereby 229 delivering the packet to the locations the roaming-EID is about 230 to appear. There are some cases where packets will go to 231 locations where the roaming-EID has already been, but see 232 Section 4.2 for packet delivery optimizations. 234 4. When the ETR resident RSU receives an encapsulated packet, it 235 decapsulates the packet and then determines if the roaming-EID 236 had been previously discovered. If the EID has not been 237 discovered, the ETR drops the packet. Otherwise, the ETR 238 delivers the decapsulated packet on the port interface the 239 roaming-EID was discovered on. 241 4.1. RLE Encoding 243 The LCAF [RFC8060] Replication List Entry (RLE) will be used to 244 encode the Predictive RLOCs in an RLOC-record for Map-Registers, Map- 245 Reply, and Map-Notify messages [RFC6830]. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | AFI = 16387 | Rsvd1 | Flags | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type = 13 | Rsvd2 | 4 + n | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Rsvd3 | Rsvd4 | Level Value | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | AFI = x | RTR/ETR #1 ... | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Rsvd3 | Rsvd4 | Level Value | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | AFI = x | RTR/ETR #n ... | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 When the RLOC-record contains an RLE with RLOC entries all with the 264 same level value, it means the physical order listed is the 265 directional path of the RSUs. This will typically be the result of a 266 third-party doing the registration where it knows ahead of time the 267 RSU deployment. 269 When each RSU is registering with merge-semantics on their own, the 270 level number is used to place them in an ordered list. Since the 271 registrations come at different times and therefore arrive in 272 different order than the physical RSU path, the level number creates 273 the necessary sequencing. Each RSU needs to know its position in the 274 path relative to other RSUs. For example, in xTR-B, it would 275 register with level 1 since it is after xTR-A (and before xTR-C). So 276 if the registration order was xTR-B with level 1, xTR-C with level 2, 277 and xTR-A with level 0, the RLE list stored in the mapping system 278 would be (xTR-A, xTR-B, xTR-C). It is recommended that level numbers 279 be assigned in increments of 10 so latter insertion is possible. 281 The use of Geo-Prefixes and Geo-Points [I-D.farinacci-lisp-geo] can 282 be used to compare the physical presence of each RSU with respect to 283 each other, so they can choose level numbers to sequence themselves. 284 Also if the xTRs register with a Geo-Point in an RLOC-record, then 285 perhaps the Map-Server could sequence the RLE list. 287 4.2. Packet Delivery Optimizations 289 Since the remote ITR will replicate to all RLOCs in the RLE, a 290 situation is created where packets go to RLOCs that don't need to. 291 For instance, if the roaming-EID is along side of xTR-B and the RLE 292 is (xTR-A, xTR-B, xTR-C), there is no reason to replicate to xTR-A 293 since the roaming-EID has passed it and the the signal range is weak 294 or lost. However, replicating to xTR-B and xTR-C is important to 295 deliver packets to where the roaming-EID resides and where it is 296 about to go to. 298 A simple data-plane option, which converges fairly quickly is to have 299 the remote xTR, acting as an ETR, when packets are sent from the 300 roaming-EID, examine the source RLOC in the outer header of the 301 encapsulated packet. If the source RLOC is xTR-B, the remote xTR can 302 determine that the roaming-EID has moved past xTR-A and no longer 303 needs to encapsulate packets to xTR-A's RLOC. 305 In addition, the remote ITR can use RLOC-probing to determine if each 306 RLOC in the RLE is reachable. And if not reachable, exclude from the 307 list of RLOCs to replicate to. 309 This solution also handles the case where xTR-A and xTR-B may overlap 310 in radio signal range, but the signal is weak from the roaming-EID to 311 xTR-A but stronger to xTR-B. In this case, the roaming-EID selects 312 xTR-B to send packets that inform the remote xTR that return packets 313 should not be encapsulated to xTR-A. 315 There are also situations where the RSUs are in signal range of each 316 other in which case they could report reachability status of each 317 other. The use of the Locator-Status-Bits of the LISP encapsulation 318 header could be used to convey this information to the remote xTR. 319 This would only occur when the roaming-EID was discovered by both 320 xTR-A and xTR-B so it was possible for either xTR to reach the 321 roaming-EID. Either an IGP like routing protocol would be required 322 to allow each xTR to know the other could reach the roaming-EID or a 323 path trace tool (i.e. traceroute) could be originated by one xTR 324 targeted for the roaming-EID but MAC-forwarded through the other xTR. 325 These and other roaming-EID reachability mechanisms are work in 326 progress and for further study. 328 When a remote ITR is doing "Directional Mobility" and replicating to 329 the last RLOC in the RLE list, it has a decision to guess where the 330 roaming-EID will move to next. Conservatively, an ITR can replicate 331 to the entire set of RLOCs in the RLE list and wait to see if the 332 roaming-EID moves to one of the RLOCs in the RLE list. 334 Or more liberally, the remote ITR can assume the new roaming 335 direction. For example, with an RLE list of (xTR-A, xTR-B, xTR-C, 336 xTR-D) and the roaming-EID is at D, the remote ITR can replicate to 337 all of A, B, C and D to determine where the roaming-EID will move to 338 next. If the roaming-EID moves to C after it was at D, it is 339 possible that the EID is moving in the opposite direction from C to B 340 to A. This would be known as "Back-n-Forth Mobility". If an 341 implementation is configured to support this for a particluar EID, 342 the remote ITR could replicate in this sequence as the roaming-EID 343 moves from A to D and back to A: (A, B, C, D), (B, C, D), (C, D), (D, 344 C, B, A), (C, B, A), (B, A), and again (A, B, C, D). 346 The roaming-EID could be doing "Circular Mobility" where it moves 347 from A to D directionally, next from D-to-A, and then back to A to D 348 directionally again. This form of mobility is just as predicatable 349 as "Back-n-Forth Mobility" since a consistent pattern can be relied 350 on. Both of these mobility forms can be achieved with near-zero 351 packet loss. 353 On the other hand, the roaming-EID can be roaming arbitrarily using 354 "Random Mobility" where it could roam in the following combinations: 355 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- 356 D, D-to-A, D-to-B, or D-to-C. In this situation, when a return 357 packet arrives at the ITR, it could then just replicate to where the 358 roaming-EID is at rest and do so for a short period of time before it 359 replciates to the entire RLE list again. Using the wrong time period 360 could lead to packet loss. All these types of mobility can be 361 supported by the remote ITR in a local manner without consulting or 362 depending on any other LISP system. It is left for further study, if 363 any of the mobility types above should be encoded in the mapping 364 system. 366 4.3. Trading Off Replication Cost 368 If RLE lists are large, packet replication can occur to locations 369 well before the roaming-EID arrives. Making RLE lists small is 370 useful without sacrificing hand-off issues or incurring packet loss 371 to the application. By having overlapping RLEs in separate RLOC- 372 records we a simple mechanism to solve this problem. Here is an 373 example mapping entry to illustrate the point: 375 EID = , RLOC-records: 376 RLOC = (RLE: xTR-A, xTR-B) 377 RLOC = (RLE: xTR-B, xTR-C, xTR-D, xTR-E) 378 RLOC = (RLE: xTR-E, xTR-F) 380 When the remote ITR is encapsulating to xTR-B as a decision to use 381 the first RLOC-record, it can decide to move to use the second RLOC- 382 record because xTR-B is the last entry in the first RLOC-record and 383 the first entry in the second RLOC-record. When there are 384 overlapping RLEs, the remote ITR can decide when it is more efficient 385 to switch over. For example, when the roaming-EID is in range of 386 xTR-A, the remote ITR uses the first RLOC-record so the wasted 387 replication cost is to xTR-B only versus a worse cost when using the 388 second RLOC-record. But when the roaming-EID is in range of xTR-B, 389 then replicating to the other xTRs in the second RLOC-record may be 390 crucial if the roaming-EID has increased speed. And when the 391 roaming-EID may be at rest in a parked mode, then the remote ITR 392 encapsulates to only xTR-F using the third RLOC-record since the 393 roaming-EID has moved past xTR-E. 395 In addition, to eliminate unnecessary replication to xTRs further 396 down a directional path, GEO-prefixes [I-D.farinacci-lisp-geo] can be 397 used so only nearby xTRs that the roaming-EID is about to come in 398 contact with are the only ones to receive encapsulated packets. 400 Even when replication lists are not large, we can reduce the cost of 401 replication that the entire network bears by moving the replicator 402 away from the the source (i.e. the ITR) and closer to the RSUs (i.e. 403 the ETRs). See the use of RTRs for Replication Engineering 404 techniques in [RFC8378]. 406 5. Directional Paths with Intersections 408 A roaming-EID could be registered to the mapping system with the 409 following nested RLE mapping: 411 EID = , RLOC-records: 412 RLOC = (RLE: xTR-A, xTR-B, xTR-C, (RLE: xTR-X, xTR-Y, xTR-Z), 413 (RLE: xTR-I, xTR-J, xTR-K), xTR-D, xTR-E) 415 The mapping entry above describes 3 directional paths where the 416 ordered list has encoded one-level of two nested RLEs to denote 417 intersections in a horizontal path. Which is drawn as: 419 | | xTR-K 420 | | 421 | | 422 | | xTR-J 423 | | 424 | | 425 Roaming | | xTR-I 426 EID ----> | | 427 --------------------------------------- ------------------------------ 428 --------------------------------------- ------------------------------ 429 xTR-A xTR-B xTR-C | | xTR-D xTR-E 430 | | 431 | | xTR-X 432 | | 433 | | 434 | | xTR-Y 435 | | 436 | | 437 | | xTR-Z 439 When the roaming-EID is on the horizontal path, the remote-ITRs 440 typically replicate to the rest the of the xTRs in the ordered list. 441 When a list has nested RLEs, the replication should occur to at least 442 the first RLOC in a nested RLE list. So if the remote-ITR is 443 replicating to xTR-C, xTR-D, and xTR-E, it should also replicate to 444 xTR-X and xTR-I anticipating a possible turn at the intersection. 445 But when the roaming-EID is known to be at xTR-D (a left or right 446 hand turn was not taken), replication should only occur to xTR-D and 447 xTR-E. Once either xTR-I or xTR-X is determined to be where the 448 roaming-EID resides, then the replication occurs on the respective 449 directional path only. 451 When nested RLEs are used it may be difficult to get merge-semantics 452 to work when each xTR registers itself. So it is suggested a third- 453 party registers nested RLEs. It is left to further study to 454 understand better how to automate this. 456 6. Multicast Considerations 458 In this design, the remote ITR is receiving a unicast packet from an 459 EID and replicating and encapsulating to each RLOC in an RLE list. 460 This form of replication is no different than a traditional multicast 461 replication function. So replicating multicast packets in the same 462 fashion is a fallout from this design. 464 If there are multiple roaming-EIDs joined to the same multicast group 465 but reside at different RSUs, a merge has to be done of any pruned 466 RLEs used for forwarding. So if roaming-EID-1 resides at xTR-A and 467 roaming-EID-2 resides at xTR-B and the RLE list is (xTR-A, xTR-B, 468 xTR-C), and they are joined to the same multicast group, then 469 replication occurs to all of xTR-A, xTR-B, and xTR-C. Even since 470 roaming-EID-2 is past xTR-A, packets need to be delivered to xTR-A 471 for roaming-EID-1. In addition, packets need to be delivered to 472 xTR-C because roaming-EID-1 and roaming-EID-2 will get to xTR-C (and 473 roaming-EID-1 may get there sooner if it is traveling faster than 474 roaming-EID-2). 476 When a roaming-EID is a multicast source, procedures from [RFC8378] 477 are used to deliver packets to multicast group members anywhere in 478 the network. The solution requires no signaling to the RSUs. When 479 RSUs receive multicast packets from a roaming-EID, they do a 480 (roaming-EID,G) mapping database lookup to find the replication list 481 of ETRs to encapsulate to. 483 7. Multiple Address-Family Considerations 485 Note that roaming-EIDs can be assigned IPv6 EID addresses while the 486 RSU xTRs could be using IPv4 RLOC addresses. Any combination of 487 address-families can be supported as well as for multicast packet 488 forwarding, where (S,G) are IPv6 addresses entries and replication is 489 done with IPv4 RLOCs in the outer header. 491 8. Scaling Considerations 493 One can imagine there will be a large number of roaming-EIDs. So 494 there is a strong desire to efficiently store state in the mapping 495 database and the in remote ITRs map-caches. It is likely, that 496 roaming-EIDs may share the same path and move at the same speed (EID 497 devices on a train) and therefore share the same Predictive RLOCs. 498 And since EIDs are not reassigned for mobility purposes or may be 499 temporal , they will not be topologically aggregatable, so they 500 cannot compress into a single EID-prefix mapping entry that share the 501 same RLOC-set. 503 By using a level of indirection with the mapping system this problem 504 can be solved. The following mapping entries could exist in the 505 mapping database: 507 EID = , RLOC-records: 508 RLOC = (afi=: "am-train-to-paris") 509 EID = , RLOC-records: 510 RLOC = (afi=: "am-train-to-paris") 511 EID = , RLOC-records: 512 RLOC = (afi=: "am-train-to-paris") 514 EID = "am-train-to-paris", RLOC-records: 515 RLOC = (afi=lcaf/RLE-type: xTR-A, xTR-B, xTR-C) 517 EID = "am-train-to-paris-passengers", RLOC-records: 518 RLOC = (afi=lcaf/afi-list-type: , , ) 520 Each passenger that boards a train has their EID registered to point 521 to the name of the train "am-train-to-paris". And then the train 522 with EID "am-train-to-paris" stores the Predictive RLOC-set. When a 523 remote-ITR wants to encapsulate packets for an EID, it looks up the 524 EID in the mapping database gets the name "am-train-to-paris" 525 returned. Then the remote-ITR does another lookup for the name "am- 526 train-to-paris" to get the RLE list returned. 528 When new EIDs board the train, the RLE mapping entry does not need to 529 be modified. Only an EID-to-name mapping is registered for the 530 specific new EID. Optionally, another name "am-train-to-paris- 531 passengers" can be registered as an EID to allow mapping to all 532 specific EIDs which are on the train. This can be used for 533 inventory, billing, or security purposes. 535 This optimization comes at a cost of a 2-stage lookup. However, if 536 both sets of mapping entries are registered to the same Map-Server, a 537 combined RLOC-set could be returned. This idea is for further study. 539 9. Security Considerations 541 LISP has procedures for supporting both control-plane security 542 [I-D.ietf-lisp-sec] and data-plane security [RFC8061]. 544 10. IANA Considerations 546 At this time there are no requests for IANA. 548 11. References 550 11.1. Normative References 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, 554 DOI 10.17487/RFC2119, March 1997, 555 . 557 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 558 Locator/ID Separation Protocol (LISP)", RFC 6830, 559 DOI 10.17487/RFC6830, January 2013, 560 . 562 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 563 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 564 February 2017, . 566 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 567 (LISP) Data-Plane Confidentiality", RFC 8061, 568 DOI 10.17487/RFC8061, February 2017, 569 . 571 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 572 Separation Protocol (LISP) Multicast", RFC 8378, 573 DOI 10.17487/RFC8378, May 2018, 574 . 576 11.2. Informative References 578 [I-D.farinacci-lisp-geo] 579 Farinacci, D., "LISP Geo-Coordinate Use-Cases", draft- 580 farinacci-lisp-geo-13 (work in progress), March 2022. 582 [I-D.ietf-lisp-eid-anonymity] 583 Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP 584 EID Anonymity", draft-ietf-lisp-eid-anonymity-12 (work in 585 progress), March 2022. 587 [I-D.ietf-lisp-eid-mobility] 588 Comeras, M. P., Ashtaputre, V., Maino, F., Moreno, V., and 589 D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified 590 Control Plane", draft-ietf-lisp-eid-mobility-09 (work in 591 progress), January 2022. 593 [I-D.ietf-lisp-sec] 594 Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, 595 "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-25 (work 596 in progress), December 2021. 598 Appendix A. Acknowledgments 600 The author would like to thank the LISP WG for their review and 601 acceptance of this draft. 603 Appendix B. Document Change Log 605 [RFC Editor: Please delete this section on publication as RFC.] 607 B.1. Changes to draft-ietf-lisp-predictive-rlocs-10 609 o Posted April 2022. 611 o Update document timer and references. 613 B.2. Changes to draft-ietf-lisp-predictive-rlocs-09 615 o Posted October 2021. 617 o Update document timer and references. 619 B.3. Changes to draft-ietf-lisp-predictive-rlocs-08 621 o Posted March 2021. 623 o Update document timer and references. 625 B.4. Changes to draft-ietf-lisp-predictive-rlocs-07 627 o Posted November 2020. 629 o Update document timer and references. 631 B.5. Changes to draft-ietf-lisp-predictive-rlocs-06 633 o Posted May 2020. 635 o Update document timer and references. 637 B.6. Changes to draft-ietf-lisp-predictive-rlocs-05 639 o Posted November 2019. 641 o Update document timer and references. 643 B.7. Changes to draft-ietf-lisp-predictive-rlocs-04 645 o Posted May 2019. 647 o Update document timer and references. 649 B.8. Changes to draft-ietf-lisp-predictive-rlocs-03 651 o Posted November 2018. 653 o Update document timer and references. 655 B.9. Changes to draft-ietf-lisp-predictive-rlocs-02 657 o Posted May 2018. 659 o Update document timer and references. 661 B.10. Changes to draft-ietf-lisp-predictive-rlocs-01 663 o Posted November 2017. 665 o Update document timer and references. 667 o Reflect comments from Prague meeting presentation. There is no 668 need for "RLE Usage Types" as suggested. The ITR can treat what 669 RLOCs it replicates to as a local matter via implementation 670 configuration. RLE Directional is default. Circular rotation, 671 back-n-forth, and random selection of RLOCs is up to the ITR. 673 B.11. Changes to draft-ietf-lisp-predictive-rlocs-00 675 o Posted June 2017. 677 o Make this specification a working group document. It is a copy of 678 draft-farinacci-lisp-predictive-rlocs-02. 680 B.12. Changes to draft-farinacci-lisp-predictive-rlocs-02 682 o Posted May 2017 to update document timer. 684 B.13. Changes to draft-farinacci-lisp-predictive-rlocs-01 686 o Posted November 2016 to update document timer. 688 B.14. Changes to draft-farinacci-lisp-predictive-rlocs-00 690 o Initial post April 2016. 692 Authors' Addresses 694 Dino Farinacci 695 lispers.net 696 San Jose, CA 697 USA 699 Email: farinacci@gmail.com 701 Padma Pillay-Esnault 702 Independent 703 San Clara, CA 704 USA 706 Email: padma.ietf@gmail.com