idnits 2.17.1 draft-ietf-lisp-te-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 : ---------------------------------------------------------------------------- == There are 8 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An ELP that is first used by an ITR must be inspected for encoding loops. If any RLOC appears twice in the ELP, it MUST not be used. -- The document date (March 20, 2022) is 761 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Experimental M. Kowal 5 Expires: September 21, 2022 cisco Systems 6 P. Lahiri 7 March 20, 2022 9 LISP Traffic Engineering Use-Cases 10 draft-ietf-lisp-te-10 12 Abstract 14 This document describes how LISP reencapsulating tunnels can be used 15 for Traffic Engineering purposes. The mechanisms described in this 16 document require no LISP protocol changes but do introduce a new 17 locator (RLOC) encoding. The Traffic Engineering features provided 18 by these LISP mechanisms can span intra-domain, inter-domain, or 19 combination of both. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 21, 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 58 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Explicit Locator Paths . . . . . . . . . . . . . . . . . . . 6 60 5.1. ELP Re-optimization . . . . . . . . . . . . . . . . . . . 8 61 5.2. Using Recursion . . . . . . . . . . . . . . . . . . . . . 8 62 5.3. ELP Selection based on Class of Service . . . . . . . . . 9 63 5.4. Packet Loop Avoidance . . . . . . . . . . . . . . . . . . 10 64 6. Service Chaining . . . . . . . . . . . . . . . . . . . . . . 10 65 7. RLOC Probing by RTRs . . . . . . . . . . . . . . . . . . . . 10 66 8. ELP Probing . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 9. Interworking Considerations . . . . . . . . . . . . . . . . . 11 68 10. Multicast Considerations . . . . . . . . . . . . . . . . . . 12 69 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 73 13.2. Informative References . . . . . . . . . . . . . . . . . 15 74 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 75 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 16 76 B.1. Changes to draft-ietf-lisp-te-10 . . . . . . . . . . . . 16 77 B.2. Changes to draft-ietf-lisp-te-09 . . . . . . . . . . . . 16 78 B.3. Changes to draft-ietf-lisp-te-08 . . . . . . . . . . . . 16 79 B.4. Changes to draft-ietf-lisp-te-07 . . . . . . . . . . . . 16 80 B.5. Changes to draft-ietf-lisp-te-06 . . . . . . . . . . . . 16 81 B.6. Changes to draft-ietf-lisp-te-05 . . . . . . . . . . . . 16 82 B.7. Changes to draft-ietf-lisp-te-04 . . . . . . . . . . . . 16 83 B.8. Changes to draft-ietf-lisp-te-03 . . . . . . . . . . . . 17 84 B.9. Changes to draft-ietf-lisp-te-02 . . . . . . . . . . . . 17 85 B.10. Changes to draft-ietf-lisp-te-01 . . . . . . . . . . . . 17 86 B.11. Changes to draft-ietf-lisp-te-00 . . . . . . . . . . . . 17 87 B.12. Changes to draft-farinacci-lisp-te-02 through -12 . . . . 17 88 B.13. Changes to draft-farinacci-lisp-te-01.txt . . . . . . . . 17 89 B.14. Changes to draft-farinacci-lisp-te-00.txt . . . . . . . . 18 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 92 1. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 2. Introduction 100 This document describes the Locator/Identifier Separation Protocol 101 (LISP), which provides a set of functions for routers to exchange 102 information used to map from non globally routeable Endpoint 103 Identifiers (EIDs) to routeable Routing Locators (RLOCs). It also 104 defines a mechanism for these LISP routers to encapsulate IP packets 105 addressed with EIDs for transmission across the Internet that uses 106 RLOCs for routing and forwarding. 108 When LISP routers encapsulate packets to other LISP routers, the path 109 stretch is typically 1, meaning the packet travels on a direct path 110 from the encapsulating ITR to the decapsulating ETR at the 111 destination site. The direct path is determined by the underlying 112 routing protocol and metrics it uses to find the shortest path. 114 This specification will examine how reencapsulating tunnels [RFC6830] 115 can be used so a packet can take an adminstratively specified path, a 116 congestion avoidance path, a failure recovery path, or multiple load- 117 shared paths, as it travels from ITR to ETR. By introducing an 118 Explicit Locator Path (ELP) locator encoding [RFC8060], an ITR can 119 encapsulate a packet to a Reencapsulating Tunnel Router (RTR) which 120 decapsulates the packet, then encapsulates it to the next locator in 121 the ELP. 123 3. Definition of Terms 125 Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for 126 IPv6) value used in the source and destination address fields of 127 the first (most inner) LISP header of a packet. The host obtains 128 a destination EID the same way it obtains an destination address 129 today, for example through a Domain Name System (DNS) [RFC1034] 130 lookup or Session Invitation Protocol (SIP) [RFC3261] exchange. 131 The source EID is obtained via existing mechanisms used to set a 132 host's "local" IP address. An EID used on the public Internet 133 must have the same properties as any other IP address used in that 134 manner; this means, among other things, that it must be globally 135 unique. An EID is allocated to a host from an EID-prefix block 136 associated with the site where the host is located. An EID can be 137 used by a host to refer to other hosts. EIDs MUST NOT be used as 138 LISP RLOCs. Note that EID blocks MAY be assigned in a 139 hierarchical manner, independent of the network topology, to 140 facilitate scaling of the mapping database. In addition, an EID 141 block assigned to a site may have site-local structure 142 (subnetting) for routing within the site; this structure is not 143 visible to the global routing system. In theory, the bit string 144 that represents an EID for one device can represent an RLOC for a 145 different device. As the architecture is realized, if a given bit 146 string is both an RLOC and an EID, it must refer to the same 147 entity in both cases. When used in discussions with other 148 Locator/ID separation proposals, a LISP EID will be called a 149 "LEID". Throughout this document, any references to "EID" refers 150 to an LEID. 152 Routing Locator (RLOC): A RLOC is an IPv4 [RFC0791] or IPv6 153 [RFC2460] address of an egress tunnel router (ETR). A RLOC is the 154 output of an EID-to-RLOC mapping lookup. An EID maps to one or 155 more RLOCs. Typically, RLOCs are numbered from topologically- 156 aggregatable blocks that are assigned to a site at each point to 157 which it attaches to the global Internet; where the topology is 158 defined by the connectivity of provider networks, RLOCs can be 159 thought of as PA addresses. Multiple RLOCs can be assigned to the 160 same ETR device or to multiple ETR devices at a site. 162 Reencapsulating Tunnel Router (RTR): An RTR is a router that acts 163 as an ETR (or PETR) by decapsulating packets where the destination 164 address in the "outer" IP header is one of its own RLOCs. Then 165 acts as an ITR (or PITR) by making a decision where to encapsulate 166 the packet based on the next locator in the ELP towards the final 167 destination ETR. 169 Explicit Locator Path (ELP): The ELP is an explicit list of RLOCs 170 for each RTR a packet must travel to along its path toward a final 171 destination ETR (or PETR). The list is a strict ordering where 172 each RLOC in the list is visited. However, the path from one RTR 173 to another is determined by the underlying routing protocol and 174 how the infrastructure assigns metrics and policies for the path. 176 Recursive Tunneling: Recursive tunneling occurs when a packet has 177 more than one LISP IP header. Additional layers of tunneling MAY 178 be employed to implement traffic engineering or other re-routing 179 as needed. When this is done, an additional "outer" LISP header 180 is added and the original RLOCs are preserved in the "inner" 181 header. Any references to tunnels in this specification refers to 182 dynamic encapsulating tunnels and they are never statically 183 configured. 185 Reencapsulating Tunnels: Reencapsulating tunneling occurs when an 186 ETR removes a LISP header, then acts as an ITR to prepend another 187 LISP header. Doing this allows a packet to be re-routed by the 188 reencapsulating router without adding the overhead of additional 189 tunnel headers. Any references to tunnels in this specification 190 refers to dynamic encapsulating tunnels and they are never 191 statically configured. When using multiple mapping database 192 systems, care must be taken to not create reencapsulation loops 193 through misconfiguration. 195 4. Overview 197 Typically, a packet's path from source EID to destination EID travels 198 through the locator core via the encapsulating ITR directly to the 199 decapsulating ETR as the following diagram illustrates: 201 Legend: 203 seid: Packet is originated by source EID 'seid'. 205 deid: Packet is consumed by destination EID 'deid'. 207 A,B,C,D : Core routers in different ASes. 209 ---> : The physical topological path between two routers. 211 ===> : A multi-hop LISP dynamic tunnel between LISP routers. 213 Core Network 214 Source site (----------------------------) Destination Site 215 +--------+ ( ) +---------+ 216 | \ ( ) / | 217 | seid ITR ---(---> A --> B --> C --> D ---)---> ETR deid | 218 | / || ( ) ^^ \ | 219 +--------+ || ( ) || +---------+ 220 || (----------------------------) || 221 || || 222 =========================================== 223 LISP Tunnel 225 Typical Data Path from ITR to ETR 227 Let's introduce RTRs 'X' and 'Y' so that, for example, if it is 228 desirable to route around the path from B to C, one could provide an 229 ELP of (X,Y,etr): 231 Core Network 232 Source site (----------------------------) Destination Site 233 +--------+ ( ) +---------+ 234 | \ ( ) / | 235 | seid ITR ---(---> A --> B --> C --> D ---)---> ETR deid | 236 | / || ( / ^ ) ^^ \ | 237 | / || ( | \ ) || \ | 238 +-------+ || ( v | ) || +--------+ 239 || ( X ======> Y ) || 240 || ( ^^ || ) || 241 || (--------||---------||-------) || 242 || || || || 243 ================= ================= 244 LISP Tunnel LISP Tunnel 246 ELP tunnel path ITR ==> X, then X ==> Y, and then Y ==> ETR 248 There are various reasons why the path from 'seid' to 'deid' may want 249 to avoid the path from B to C. To list a few: 251 o There may not be sufficient capacity provided by the networks that 252 connect B and C together. 254 o There may be a policy reason to avoid the ASes that make up the 255 path between B and C. 257 o There may be a failure on the path between B and C which makes the 258 path unreliable. 260 o There may be monitoring or traffic inspection resources close to 261 RTRs X and Y that do network accounting or measurement. 263 o There may be a chain of services performed at RTRs X and Y 264 regardless if the path from ITR to ETR is through B and C. 266 5. Explicit Locator Paths 268 The notation for a general formatted ELP is (x, y, etr) which 269 represents the list of RTRs a packet SHOULD travel through to reach 270 the final tunnel hop to the ETR. 272 The procedure for using an ELP at each tunnel hop is as follows: 274 1. The ITR will retrieve the ELP from the mapping database. 276 2. The ITR will encapsulate the packet to RLOC 'x'. 278 3. The RTR with RLOC 'x' will decapsulate the packet. It will use 279 the decapsulated packet's destination address as a lookup into 280 the mapping database to retrieve the ELP. 282 4. RTR 'x' will encapsulate the packet to RTR with RLOC 'y'. 284 5. The RTR with RLOC 'y' will decapsulate the packet. It will use 285 the decapsulated packet's destination address as a lookup into 286 the mapping database to retrieve the ELP. 288 6. RTR 'y' will encapsulate the packet on the final tunnel hop to 289 ETR with RLOC 'etr'. 291 7. The ETR will decapsulate the packet and deliver the packet to the 292 EID inside of its site. 294 The specific format for the ELP can be found in [RFC8060]. It is 295 defined that an ELP will appear as a single encoded locator in a 296 locator-set. Say for instance, we have a mapping entry for EID- 297 prefix 10.0.0.0/8 that is reachable via 4 locators. Two locators are 298 being used as active/active and the other two are used as active/ 299 active if the first two go unreachable (as noted by the priority 300 assignments below). This is what the mapping entry would look like: 302 EID-prefix: 10.0.0.0/8 303 Locator-set: ETR-A: priority 1, weight 50 304 ETR-B: priority 1, weight 50 305 ETR-C: priority 2, weight 50 306 ETR-D: priority 2, weight 50 308 If an ELP is going to be used to have a policy path to ETR-A and 309 possibly another policy path to ETR-B, the locator-set would be 310 encoded as follows: 312 EID-prefix: 10.0.0.0/8 313 Locator-set: (x, y, ETR-A): priority 1, weight 50 314 (q, r, ETR-B): priority 1, weight 50 315 ETR-C: priority 2, weight 50 316 ETR-D: priority 2, weight 50 318 The mapping entry with ELP locators is registered to the mapping 319 database system just like any other mapping entry would. The 320 registration is typically performed by the ETR(s) that are assigned 321 and own the EID-prefix. That is, the destination site makes the 322 choice of the RTRs in the ELP. However, it may be common practice 323 for a provisioning system to program the mapping database with ELPs. 325 Another case where a locator-set can be used for flow-based load- 326 sharing across multiple paths to the same destination site: 328 EID-prefix: 10.0.0.0/8 329 Locator-set: (x, y, ETR-A): priority 1, weight 75 330 (q, r, ETR-A): priority 1, weight 25 332 Using this mapping entry, an ITR would load split 75% of the EID 333 flows on the (x, y, ETR-A) ELP path and 25% of the EID flows on the 334 (q, r, ETR-A) ELP path. If any of the ELPs go down, then the other 335 can take 100% of the load. 337 5.1. ELP Re-optimization 339 ELP re-optimization is a process of changing the RLOCs of an ELP due 340 to underlying network change conditions. Just like when there is any 341 locator change for a locator-set, the procedures from the main LISP 342 specification [RFC6830] are followed. 344 When a RLOC from an ELP is changed, Map-Notify messages [RFC6833] can 345 be used to inform the existing RTRs in the ELP so they can do a 346 lookup to obtain the latest version of the ELP. Map-Notify messages 347 can also be sent to new RTRs in an ELP so they can get the ELP in 348 advance to receiving packets that will use the ELP. This can 349 minimize packet loss during mapping database lookups in RTRs. 351 5.2. Using Recursion 353 In the previous examples, we showed how an ITR encapsulates using an 354 ELP of (x, y, etr). When a packet is encapsulated by the ITR to RTR 355 'x', the RTR may want a policy path to RTR 'y' and run another level 356 of reencapsulating tunnels for packets destined to RTR 'y'. In this 357 case, RTR 'x' does not encapsulate packets to 'y' but rather performs 358 a mapping database lookup on the address 'y', requests the ELP for 359 RTR 'y', and encapsulates packets to the first-hop of the returned 360 ELP. This can be done when using a public or private mapping 361 database. The decision to use address 'y' as an encapsulation 362 address versus a lookup address is based on the L-bit setting for 'y' 363 in the ELP entry. The decision and policy of ELP encodings are local 364 to the entity which registers the EID-prefix associated with the ELP. 366 Another example of recursion is when the ITR uses the ELP (x, y, etr) 367 to first prepend a header with a destination RLOC of the ETR and then 368 prepend another header and encapsulate the packet to RTR 'x'. When 369 RTR 'x' decapsulates the packet, rather than doing a mapping database 370 lookup on RTR 'y' the last example showed, instead RTR 'x' does a 371 mapping database lookup on ETR 'etr'. In this scenario, RTR 'x' can 372 choose an ELP from the locator-set by considering the source RLOC 373 address of the ITR versus considering the source EID. 375 This additional level of recursion also brings advantages for the 376 provider of RTR 'x' to store less state. Since RTR 'x' does not need 377 to look at the inner most header, it does not need to store EID 378 state. It only stores an entry for RTR 'y' which many EID flows 379 could share for scaling benefits. The locator-set for entry 'y' 380 could either be a list of typical locators, a list of ELPs, or 381 combination of both. Another advantage is that packet load-splitting 382 can be accomplished by examining the source of a packet. If the 383 source is an ITR versus the source being the last-hop of an ELP the 384 last-hop selected, different forwarding paths can be used. 386 5.3. ELP Selection based on Class of Service 388 Paths to an ETR may want to be selected based on different classes of 389 service. Packets from a set of sources that have premium service can 390 use ELP paths that are less congested where normal sources use ELP 391 paths that compete for less resources or use longer paths for best 392 effort service. 394 Using source/destination lookups into the mapping database can yield 395 different ELPs. So for example, a premium service flow with 396 (source=1.1.1.1, dest=10.1.1.1) can be described by using the 397 following mapping entry: 399 EID-prefix: (1.0.0.0/8, 10.0.0.0/8) 400 Locator-set: (x, y, ETR-A): priority 1, weight 50 401 (q, r, ETR-A): priority 1, weight 50 403 And all other best-effort sources would use different mapping entry 404 described by: 406 EID-prefix: (0.0.0.0/0, 10.0.0.0/8) 407 Locator-set: (x, x', y, y', ETR-A): priority 1, weight 50 408 (q, q', r, r', ETR-A): priority 1, weight 50 410 If the source/destination lookup is coupled with recursive lookups, 411 then an ITR can encapsulate to the ETR, prepending a header that 412 selects source address ITR-1 based on the premium class of service 413 source, or selects source address ITR-2 for best-effort sources with 414 normal class of service. The ITR then does another lookup in the 415 mapping database on the prepended header using lookup key 416 (source=ITR-1, dest=10.1.1.1) that returns the following mapping 417 entry: 419 EID-prefix: (ITR-1, 10.0.0.0/8) 420 Locator-set: (x, y, ETR-A): priority 1, weight 50 421 (q, r, ETR-A): priority 1, weight 50 423 And all other sources would use different mapping entry with a lookup 424 key of (source=ITR-2, dest=10.1.1.1): 426 EID-prefix: (ITR-2, 10.0.0.0/8) 427 Locator-set: (x, x', y, y', ETR-A): priority 1, weight 50 428 (q, q', r, r', ETR-A): priority 1, weight 50 430 This will scale the mapping system better by having fewer source/ 431 destination combinations. Refer to the Source/Dest LCAF type 432 described in [RFC8060] for encoding EIDs in Map-Request and Map- 433 Register messages. 435 5.4. Packet Loop Avoidance 437 An ELP that is first used by an ITR must be inspected for encoding 438 loops. If any RLOC appears twice in the ELP, it MUST not be used. 440 Since it is expected that multiple mapping systems will be used, 441 there can be a loop across ELPs when registered in different mapping 442 systems. The TTL copying procedures for reencapsulating tunnels and 443 recursive tunnels in [RFC6830] MUST be followed. 445 6. Service Chaining 447 An ELP can be used to deploy services at each reencapsulation point 448 in the network. One example is to implement a scrubber service when 449 a destination EID is being DoS attacked. That is, when a DoS attack 450 is recognized when the encapsulation path is between ITR and ETR, an 451 ELP can be registered for a destination EID to the mapping database 452 system. The ELP can include an RTR so the ITR can encapsulate 453 packets to the RTR which will decapsulate and deliver packets to a 454 scrubber service device. The scrubber could decide if the offending 455 packets are dropped or allowed to be sent to the destination EID. In 456 which case, the scurbber delivers packets back to the RTR which 457 encapsulates to the ETR. 459 7. RLOC Probing by RTRs 461 Since an RTR knows the next tunnel hop to encapsulate to, it can 462 monitor the reachability of the next-hop RTR RLOC by doing RLOC- 463 probing according to the procedures in [RFC6830]. When the RLOC is 464 determined unreachable by the RLOC-probing mechanisms, the RTR can 465 use another locator in the locator-set. That could be the final ETR, 466 a RLOC of another RTR, or an ELP where it must search for itself and 467 use the next RLOC in the ELP list to encapsulate to. 469 RLOC-probing can also be used to measure delay on the path between 470 RTRs and when it is desirable switch to another lower delay ELP. 472 8. ELP Probing 474 Since an ELP-node knows the reachabiliy of the next ELP-node in a ELP 475 by using RLOC probing, the sum of reachability can determine the 476 reachability of the entire path. A head-end ITR/RTR/PITR can 477 determine the quality of a path and decide to select one path from 478 another based on the telemetry data gathered by RLOC-probing for each 479 encapsulation hop. 481 ELP-probing mechanism details can be found in [I-D.filyurin-lisp-elp- 482 probing]. 484 9. Interworking Considerations 486 [RFC6832] defines procedures for how non-LISP sites talk to LISP 487 sites. The network elements defined in the Interworking 488 specification, the proxy ITR (PITR) and proxy ETR (PETR) (as well as 489 their multicast counterparts defined in [RFC6831]) can participate in 490 LISP-TE. That is, a PITR and a PETR can appear in an ELP list and 491 act as an RTR. 493 Note when an RLOC appears in an ELP, it can be of any address-family. 494 There can be a mix of IPv4 and IPv6 locators present in the same ELP. 495 This can provide benefits where islands of one address-family or the 496 other are supported and connectivity across them is necessary. For 497 instance, an ELP can look like: 499 (x4, a46, b64, y4, etr) 501 Where an IPv4 ITR will encapsulate using an IPv4 RLOC 'x4' and 'x4' 502 could reach an IPv4 RLOC 'a46', but RTR 'a46' encapsulates to an IPv6 503 RLOC 'b64' when the network between them is IPv6-only. Then RTR 504 'b64' encapsulates to IPv4 RLOC 'y4' if the network between them is 505 dual-stack. 507 Note that RTRs can be used for NAT-traversal scenarios 508 [I-D.ermagan-lisp-nat-traversal] as well to reduce the state in both 509 an xTR that resides behind a NAT and the state the NAT needs to 510 maintain. In this case, the xTR only needs a default map-cache entry 511 pointing to the RTR for outbound traffic and all remote ITRs can 512 reach EIDs through the xTR behind a NAT via a single RTR (or a small 513 set RTRs for redundancy). 515 RTRs have some scaling features to reduce the number of locator-set 516 changes, the amount of state, and control packet overhead: 518 o When ITRs and PITRs are using a small set of RTRs for 519 encapsulating to "orders of magnitude" more EID-prefixes, the 520 probability of locator-set changes are limited to the RTR RLOC 521 changes versus the RLOC changes for the ETRs associated with the 522 EID-prefixes if the ITRs and PITRs were directly encapsulating to 523 the ETRs. This comes at an expense in packet stretch, but 524 depending on RTR placement, this expense can be mitigated. 526 o When RTRs are on-path between many pairwise EID flows, ITRs and 527 PITRs can store a small number of coarse EID-prefixes. 529 o RTRs can be used to help scale RLOC-probing. Instead of ITRs 530 RLOC-probing all ETRs for each destination site it has cached, the 531 ITRs can probe a smaller set of RTRs which in turn, probe the 532 destination sites. 534 10. Multicast Considerations 536 ELPs have application in multicast environments. Just like RTRs can 537 be used to provide connectivity across different address family 538 islands, RTRs can help concatenate a multicast region of the network 539 to one that does not support native multicast. 541 Note there are various combinations of connectivity that can be 542 accomplished with the deployment of RTRs and ELPs: 544 o Providing multicast forwarding between IPv4-only-unicast regions 545 and IPv4-multicast regions. 547 o Providing multicast forwarding between IPv6-only-unicast regions 548 and IPv6-multicast regions. 550 o Providing multicast forwarding between IPv4-only-unicast regions 551 and IPv6-multicast regions. 553 o Providing multicast forwarding between IPv6-only-unicast regions 554 and IPv4-multicast regions. 556 o Providing multicast forwarding between IPv4-multicast regions and 557 IPv6-multicast regions. 559 An ITR or PITR can do a (S-EID,G) lookup into the mapping database. 560 What can be returned is a typical locator-set that could be made up 561 of the various RLOC addresses: 563 Multicast EID key: (seid, G) 564 Locator-set: ETR-A: priority 1, weight 25 565 ETR-B: priority 1, weight 25 566 g1: priority 1, weight 25 567 g2: priority 1, weight 25 569 An entry for host 'seid' sending to application group 'G' 571 The locator-set above can be used as a replication list. That is 572 some RLOCs listed can be unicast RLOCs and some can be delivery group 573 RLOCs. A unicast RLOC in this case is used to encapsulate a 574 multicast packet originated by a multicast source EID into a unicast 575 packet for unicast delivery on the underlying network. ETR-A could 576 be a IPv4 unicast RLOC address and ETR-B could be a IPv6 unicast RLOC 577 address. 579 A delivery group address is used when a multicast packet originated 580 by a multicast source EID is encapsulated in a multicast packet for 581 multicast delivery on the underlying network. Group address 'g1' 582 could be a IPv4 delivery group RLOC and group address 'g2' could be 583 an IPv6 delivery group RLOC. 585 Flexibility for these various types of connectivity combinations can 586 be achieved and provided by the mapping database system. And the RTR 587 placement allows the connectivity to occur where the differences in 588 network functionality are located. 590 Extending this concept by allowing ELPs in locator-sets, one could 591 have this locator-set registered in the mapping database for (seid, 592 G). For example: 594 Multicast EID key: (seid, G) 595 Locator-set: (x, y, ETR-A): priority 1, weight 50 596 (a, g, b, ETR-B): priority 1, weight 50 598 Using ELPs for multicast flows 600 In the above situation, an ITR would encapsulate a multicast packet 601 originated by a multicast source EID to the RTR with unicast RLOC 602 'x'. Then RTR 'x' would decapsulate and unicast encapsulate to RTR 603 'y' ('x' or 'y' could be either IPv4 or IPv6 unicast RLOCs), which 604 would decapsulate and unicast encapsulate to the final RLOC 'ETR-A'. 605 The ETR 'ETR-A' would decapsulate and deliver the multicast packet 606 natively to all the receivers joined to application group 'G' inside 607 the LISP site. 609 Let's look at the ITR using the ELP (a, g, b, ETR-B). Here the 610 encapsulation path would be the ITR unicast encapsulates to unicast 611 RLOC 'a'. RTR 'a' multicast encapsulates to delivery group 'g'. The 612 packet gets to all ETRs that have joined delivery group 'g' so they 613 can deliver the multicast packet to joined receivers of application 614 group 'G' in their sites. RTR 'b' is also joined to delivery group 615 'g'. Since it is in the ELP, it will be the only RTR that unicast 616 encapsulates the multicast packet to ETR 'ETR-B'. Lastly, 'ETR-B' 617 decapsulates and delivers the multicast packet to joined receivers to 618 application group 'G' in its LISP site. 620 As one can see there are all sorts of opportunities to provide 621 multicast connectivity across a network with non-congruent support 622 for multicast and different address-families. One can also see how 623 using the mapping database can allow flexible forms of delivery 624 policy, rerouting, and congestion control management in multicast 625 environments. 627 11. Security Considerations 629 When an RTR receives a LISP encapsulated packet, it can look at the 630 outer source address to verify that RLOC is the one listed as the 631 previous hop in the ELP list. If the outer source RLOC address 632 appears before the RLOC which matches the outer destination RLOC 633 address, the decapsulating RTR (or ETR if last hop), MAY choose to 634 drop the packet. 636 12. IANA Considerations 638 At this time there are no requests for IANA. 640 13. References 642 13.1. Normative References 644 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 645 DOI 10.17487/RFC0791, September 1981, 646 . 648 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 649 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 650 . 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, 654 DOI 10.17487/RFC2119, March 1997, 655 . 657 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 658 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 659 December 1998, . 661 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 662 A., Peterson, J., Sparks, R., Handley, M., and E. 663 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 664 DOI 10.17487/RFC3261, June 2002, 665 . 667 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 668 Locator/ID Separation Protocol (LISP)", RFC 6830, 669 DOI 10.17487/RFC6830, January 2013, 670 . 672 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 673 Locator/ID Separation Protocol (LISP) for Multicast 674 Environments", RFC 6831, DOI 10.17487/RFC6831, January 675 2013, . 677 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 678 "Interworking between Locator/ID Separation Protocol 679 (LISP) and Non-LISP Sites", RFC 6832, 680 DOI 10.17487/RFC6832, January 2013, 681 . 683 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 684 Protocol (LISP) Map-Server Interface", RFC 6833, 685 DOI 10.17487/RFC6833, January 2013, 686 . 688 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 689 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 690 February 2017, . 692 13.2. Informative References 694 [I-D.ermagan-lisp-nat-traversal] 695 Ermagan, V., Farinacci, D., Lewis, D., Maino, F., Comeras, 696 M. P., Skriver, J., White, C., Lopez, A., and A. Cabellos, 697 "NAT traversal for LISP", draft-ermagan-lisp-nat- 698 traversal-19 (work in progress), May 2021. 700 Appendix A. Acknowledgments 702 The authors would like to thank the following people for their ideas 703 and comments. They are Albert Cabellos, Khalid Raza, and Vina 704 Ermagan, Gregg Schudel, Yan Filyurin, Robert Raszuk, and Truman 705 Boyes. 707 Appendix B. Document Change Log 709 B.1. Changes to draft-ietf-lisp-te-10 711 o Posted March 2022. 713 o Update document timer and references. 715 B.2. Changes to draft-ietf-lisp-te-09 717 o Posted September 2021. 719 o Update document timer and references. 721 B.3. Changes to draft-ietf-lisp-te-08 723 o Posted March 2021. 725 o Update document timer and references. 727 B.4. Changes to draft-ietf-lisp-te-07 729 o Posted October 2020. 731 o Update document timer and references. 733 B.5. Changes to draft-ietf-lisp-te-06 735 o Posted April 2020. 737 o Update document timer and references. 739 B.6. Changes to draft-ietf-lisp-te-05 741 o Posted October 2019. 743 o Update document timer and references. 745 B.7. Changes to draft-ietf-lisp-te-04 747 o Posted April 2019. 749 o Update document timer and references. 751 B.8. Changes to draft-ietf-lisp-te-03 753 o Posted October 2018. 755 o Update document timer and references. 757 B.9. Changes to draft-ietf-lisp-te-02 759 o Posted April 2018. 761 o Update document timer and references. 763 B.10. Changes to draft-ietf-lisp-te-01 765 o Posted October 2017. 767 o Added section on ELP-probing that tells an ITR/RTR/PITR the 768 feasibility and reachability of an Explicit Lcoator Path. 770 B.11. Changes to draft-ietf-lisp-te-00 772 o Posted April 2017. 774 o Changed draft-farinacci-lisp-te-12 to working group document. 776 B.12. Changes to draft-farinacci-lisp-te-02 through -12 778 o Many postings from January 2013 through February 2017. 780 o Update references and document timer. 782 B.13. Changes to draft-farinacci-lisp-te-01.txt 784 o Posted July 2012. 786 o Add the Lookup bit to allow an ELP to be a list of encapsulation 787 and/or mapping database lookup addresses. 789 o Indicate that ELPs can be used for service chaining. 791 o Add text to indicate that Map-Notify messages can be sent to new 792 RTRs in a ELP so their map-caches can be pre-populated to avoid 793 mapping database lookup packet loss. 795 o Fixes to editorial comments from Gregg. 797 B.14. Changes to draft-farinacci-lisp-te-00.txt 799 o Initial draft posted March 2012. 801 Authors' Addresses 803 Dino Farinacci 804 lispers.net 805 San Jose, California 806 USA 808 Phone: 408-718-2001 809 Email: farinacci@gmail.com 811 Michael Kowal 812 cisco Systems 813 111 Wood Avenue South 814 ISELIN, NJ 815 USA 817 Email: mikowal@cisco.com 819 Parantap Lahiri 820 USA 822 Email: parantap.lahiri@gmail.com