idnits 2.17.1 draft-rodrigueznatal-lisp-multi-tuple-eids-12.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 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 238 has weird spacing: '...src-add pr ...' -- The document date (11 October 2021) is 928 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'LISP-DHT' is mentioned on line 305, but not defined == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-te-09 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP Working Group A. Rodriguez-Natal 3 Internet-Draft Cisco Systems 4 Intended status: Experimental A. Cabellos-Aparicio 5 Expires: 14 April 2022 Technical University of Catalonia 6 S. Barkai 7 Nexar Inc. 8 V. Ermagan 9 Google 10 D. Lewis 11 F. Maino 12 Cisco Systems 13 D. Farinacci 14 lispers.net 15 11 October 2021 17 LISP support for Multi-Tuple EIDs 18 draft-rodrigueznatal-lisp-multi-tuple-eids-12 20 Abstract 22 This document describes extensions for LISP to support EIDs based on 23 tuples of multiple elements. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 14 April 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 60 2. Definition of terms . . . . . . . . . . . . . . . . . . . . . 3 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Protocol Operation with Extended-EIDs . . . . . . . . . . . . 3 63 4.1. LISP Tunnel Routers . . . . . . . . . . . . . . . . . . . 4 64 4.2. Mapping System . . . . . . . . . . . . . . . . . . . . . 4 65 5. Extended-EIDs Encoding . . . . . . . . . . . . . . . . . . . 5 66 5.1. 5-Tuple . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6. Extended-EID Lookups . . . . . . . . . . . . . . . . . . . . 5 68 6.1. 5-Tuple (Coarse) . . . . . . . . . . . . . . . . . . . . 5 69 6.2. 5-Tuple (Exact) . . . . . . . . . . . . . . . . . . . . . 6 70 7. Mapping Databases for Extended-EIDs . . . . . . . . . . . . . 7 71 7.1. 5-Tuple (Coarse) . . . . . . . . . . . . . . . . . . . . 7 72 7.2. 5-Tuple (Exact) . . . . . . . . . . . . . . . . . . . . . 7 73 8. A Note on Instance-ID . . . . . . . . . . . . . . . . . . . . 7 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 11. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 12. Normative References . . . . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 This document describes how LISP handles lookups based on Extended- 83 EIDs, i.e. tuples of n elements. Particularly it describes how the 84 Tunnel Routers and the Mapping System operate when Extended-EIDs are 85 in place, the different types of Extended-EIDs defined so far, how 86 the lookup is performed for each Extended-EID type and which mapping 87 databases are recommended to use depending on the kind of Extended- 88 EIDs used. 90 1.1. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 2. Definition of terms 98 * n-tuple: The term n-tuple is used in this document to describe the 99 set of n elements present in a data packet (e.g. IP address, 100 port, protocol) that can be used to identify unequivocally a 101 packet or a set of packets. 103 * 5-tuple: The term 5-tuple is used in this document to describe the 104 set comprised by 5 elements, being these the source IP address, 105 the destination IP address, the level 4 protocol number, the level 106 4 protocol source port and the level 4 protocol destination port 107 of a data packet. 109 * Extended-EID: This document uses the term Extended-EID to refer to 110 any n-tuple (including a 5-tuple) used in a EID role. See as well 111 [RFC8111] 113 * Flow: The term flow is used in this document to refer to the 114 sequence of packets identified by the same n-tuple. 116 * MT-[xTR, RTR, MS, MR]: A LISP [xTR, RTR, MS, MR] that supports the 117 enhanced operation for Multi-Tuple Extended-EIDs described in this 118 document. 120 * MT-TR: A LISP tunnel router (e.g. xTR, RTR) that supports the 121 enhanced operation for Multi-Tuple Extended-EIDs described in this 122 document, e.g. MT-xTR, MT-RTR. 124 The rest of the terms are defined in their respective documents. See 125 the LISP specification [I-D.ietf-lisp-rfc6833bis] for most of the 126 definitions, [RFC8060] for LCAF and [I-D.ietf-lisp-te] for RTR. 128 3. Overview 130 This document describes extensions for LISP to support Multi-Tuple 131 Extended-EIDs. Protocol operation follows the specification defined 132 on [I-D.ietf-lisp-rfc6833bis] except for the following. Besides of 133 IP mappings, a Mapping System can store Extended-EID mappings. Being 134 Extended-EID a n-tuple identifying a flow. LISP routers perform 135 look-ups based on these Extended-EIDs, instead of on destination IPs. 136 Apart from using n-tuples instead of IPs, retrieving information from 137 the Mapping System follows LISP standard mechanisms (i.e. Map- 138 Request, Map-Reply). 140 4. Protocol Operation with Extended-EIDs 141 4.1. LISP Tunnel Routers 143 LISP tunnel routers with enhanced operation for Multi-Tuple Extended- 144 EIDs, or MT-TRs (MT-xTRs and MT-RTRs), behave as specified on and 145 [I-D.ietf-lisp-rfc6833bis], with the particularity that MT-TRs 146 perform mapping lookups based on Extended-EIDs (n-tuples). 148 Any MT-TR must keep an internal map-cache indexed by Extended-EIDs. 149 When a MT-TR receives a packet to encapsulate, it extracts the fields 150 required by the n-tuple lookup in use and stores them in an Extended- 151 EID structure. In the case of a 5-tuple lookup, it will extract the 152 source address, destination address, level 4 protocol, source port 153 (if any) and destination port (if any) from the packet. The MT-TR 154 uses the Extended-EID to perform a look-up into the map-cache. The 155 lookup process must follow the procedure described in section 156 Section 6. If there is an entry on the map-cache that matches the 157 Extended-EID, the MT-TR retrieves the mapping information, selects a 158 destination RLOC and encapsulates the packet, as defined in 159 [I-D.ietf-lisp-rfc6833bis] 161 If the map-cache of the MT-TR contains no entry for the Extended-EID, 162 the MT-TR sends a Map-Request to a MT-MR. The MT-TR MUST be 163 provisioned with the RLOC of at least one MT-MR. The Map-Request 164 sent carries the Extended-EID (encoded in the specific LCAF for that 165 Extended-EID type) in the EID-prefix field of the Map-Request. This 166 Map-Request will eventually trigger a Map-Reply to be sent back the 167 requester MT-TR, see section Section 4.2. This Map-Reply carries an 168 Extended-EID on the EID-prefix field. The MT-TR stores, as defined 169 in [I-D.ietf-lisp-rfc6833bis], the mapping for the Extended-EID. 171 4.2. Mapping System 173 Mapping System elements (comprising Map Servers and Map Resolvers) 174 behave as specified on [I-D.ietf-lisp-rfc6833bis] when implementing 175 enhanced Multi-Tuple Extended-EIDs operation, with the particularity 176 that MT-MRs resolve Map-Requests based on Extended-EIDs and MT-MSs 177 store mappings indexed by Extended-EIDs. 179 MT-MRs must be capable of processing Map-Requests with an Extended- 180 EID on the EID-prefix field, of finding the appropriate MT-MS for the 181 Extended-EID and of forwarding the Map-Request to it. This is done 182 according to the lookup rules described in section Section 6 and 183 using the mapping database described in section Section 7 which 184 differs depending on the specific Extended-EID. 186 LISP elements must perform the mapping update mechanisms defined in 187 [I-D.ietf-lisp-rfc6833bis] (e.g, SMR) using as EID the Extended-EID. 189 5. Extended-EIDs Encoding 191 This section describes the Extended-EID types defined so far and the 192 LCAFs to support them. 194 5.1. 5-Tuple 196 The 5-tuple LCAF is a combination of Application Data Type 4 and 197 Source/Dest Type 12 LCAFs. Experimental deployment may indicate that 198 a specific 5-tuple type LCAF is necessary. 200 6. Extended-EID Lookups 202 This section describes the lookup process to be followed when using 203 Extended-EID. At this point, this document only covers 5-tuple kind 204 of Extended-EID lookups (with options for coarse or exact lookup). 205 It is expected to include lookup mechanism for n-tuple lookups with 206 more complex protocol combinations. 208 6.1. 5-Tuple (Coarse) 210 When using a coarse lookup for 5-tuple, the encoding described in 211 Section 5.1 is used to carry the Extended-EID. Note that a coarse 212 lookup also covers exact lookups. The lookup is (logically) done at 213 steps, one per each element of the tuple. The lookup MUST follow 214 this strict order: 216 (1) Destination address 218 (2) Source address 220 (3) Protocol number 222 (4) Destination port 224 (5) Source port 226 This means that for a given 5-tuple, the lookup process will first 227 select from the available 5-tuples present in the system, the ones 228 that match the destination address. Among them, those that also 229 match the source address. This is iterated for the rest of the 230 elements in the tuple. If a 5-tuple matches several entries, then 231 the one with the longest prefix match or shortest port-range has 232 priority. To clarify the process an example is provided below. 234 Suppose that a MT-MS stores the mappings indexed by the tuples (A), 235 (B), (C), (D) and (E), and that it receives Map-Request messages 236 carrying the Extended-EIDs (T), (U), (V), (W), (X) and (Y). 238 dst-add src-add pr dst-prt src-prt 240 (A) [1.1.1.0/24, 2.2.0.0/16, 17, 1000-3000, 1000-3000] 241 (B) [1.1.0.0/16, 2.2.2.0/24, 17, 1000-3000, 1000-3000] 242 (C) [3.3.3.0/24, 4.4.4.0/24, 6, 4000-4500, 7000-8000] 243 (D) [3.3.3.0/24, 4.4.4.0/24, 6, 4000-6000, 7000-8000] 244 (E) [5.5.5.0/24, 6.6.6.0/24, 17, 0-65535, 0-65535] 246 (T) [ 1.1.1.8, 2.2.2.9, 17, 2000, 2000 ] 247 (U) [ 1.1.8.8, 2.2.9.9, 17, 2000, 2000 ] 248 (V) [ 1.1.8.8, 2.2.2.9, 17, 2000, 2000 ] 249 (W) [ 3.3.3.3, 4.4.4.4, 6, 4300, 7500 ] 250 (X) [ 3.3.3.3, 4.4.4.4, 6, 5000, 7500 ] 251 (Y) [ 5.5.5.5, 6.6.6.6, 17, 6000, 6000 ] 253 Figure 1: 5-tuple example for coarse lookup 255 (1) When (T) is Map-Requested, the lookup could match both (A) and 256 (B), however destination address has preference over source 257 address and therefore (A) is returned. 259 (2) When (U) is Map-Requested, the lookup will return that no entry 260 exists for the 5-tuple. 262 (3) When (V) is Map-Requested, the lookup will return (B). 264 (4) When (W) is Map-Requested, the lookup will return (C) and not 265 (D), although both could match the tuple, since the destination 266 port range is shorter in (C). 268 (5) When (X) is Map-Requested, the lookup will return (D). 270 (6) When (Y) is Map-Requested, the lookup will return (E). A port 271 range of 0-65535 means any port. 273 6.2. 5-Tuple (Exact) 275 In scenarios where 5-tuple coarse lookup is not required, the lookup 276 can be optimized to only account for exact matchs. When using a 277 exact lookup for 5-tuple, the encoding described in Section 6.1 is 278 used to carry the Extended-EID. The exact match lookup is performed 279 by serializing the elements of the 5-tuple as a single vector of 280 bits. The order to serialize the elements is the same that is 281 described in Section 5.1 This (unique) vector of bits is then used as 282 the key to perform a exact match lookup over the available entries. 284 7. Mapping Databases for Extended-EIDs 286 The mapping database, i.e. the system to interconnect (MT-)MRs and 287 (MT-)MSs should be optimal for each one of the different Extended- 288 EIDs types. This section covers recommended mapping databases for 289 each of the Extended-EIDs described in this document. 291 7.1. 5-Tuple (Coarse) 293 The mapping database to be used for a coarse lookup of 5-tuples can 294 leverage on the LISP-DDT mapping database [RFC8111] since it supports 295 multi-tuple lookups. Note that a LISP-DDT based database can support 296 also a exact lookup. 298 7.2. 5-Tuple (Exact) 300 Although a LISP-DDT based mapping database supports both coarse and 301 exact lookups, the particularities of the latter benefit of using a 302 mapping database optimized for flat namespaces rather than one 303 optimized for hierarchical data. In that sense, the exact match 304 mechanism should be supported by a DHT-like mapping database, such 305 [I-D.cheng-lisp-shdht] or [LISP-DHT]. 307 8. A Note on Instance-ID 309 Instance-ID is a special case to be considered. If it is in use, its 310 lookup is resolved before the lookup for the Extended-EID begins 311 (regardless of the Extended-EID type). In terms of implementation 312 this means that if the Instance-ID is present, it will have always 313 more priority that any other field within the multi-tuple EID. In 314 other words, Instance-ID is the high-order parts of the destination 315 and source addresses and a longest match lookup should be applied to 316 it before looking up the address itself. 318 9. Acknowledgments 320 10. IANA Considerations 322 This memo includes no request to IANA. 324 11. Security Considerations 326 Security Considerations TBD 328 12. Normative References 330 [I-D.cheng-lisp-shdht] 331 Cheng, L. and M. Sun, "LISP Single-Hop DHT Mapping 332 Overlay", Work in Progress, Internet-Draft, draft-cheng- 333 lisp-shdht-04, 15 July 2013, 334 . 337 [I-D.ietf-lisp-rfc6833bis] 338 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 339 "Locator/ID Separation Protocol (LISP) Control-Plane", 340 Work in Progress, Internet-Draft, draft-ietf-lisp- 341 rfc6833bis-30, 18 November 2020, 342 . 345 [I-D.ietf-lisp-te] 346 Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic 347 Engineering Use-Cases", Work in Progress, Internet-Draft, 348 draft-ietf-lisp-te-09, 19 September 2021, 349 . 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, 354 DOI 10.17487/RFC2119, March 1997, 355 . 357 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 358 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 359 February 2017, . 361 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 362 Smirnov, "Locator/ID Separation Protocol Delegated 363 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 364 May 2017, . 366 Authors' Addresses 368 Alberto Rodriguez-Natal 369 Cisco Systems 370 170 Tasman Drive 371 San Jose, CA 372 United States of America 374 Email: natal@cisco.com 375 Albert Cabellos-Aparicio 376 Technical University of Catalonia 377 Barcelona 378 Spain 380 Email: acabello@ac.upc.edu 382 Sharon Barkai 383 Nexar Inc. 384 CA 385 United States of America 387 Email: sharon.barkai@getnexar.com 389 Vina Ermagan 390 Google 391 United States of America 393 Email: ermagan@gmail.com 395 Darrel Lewis 396 Cisco Systems 397 170 Tasman Drive 398 San Jose, CA 399 United States of America 401 Email: darlewis@cisco.com 403 Fabio Maino 404 Cisco Systems 405 170 Tasman Drive 406 San Jose, CA 407 United States of America 409 Email: fmaino@cisco.com 411 Dino Farinacci 412 lispers.net 413 San Jose, CA 414 United States of America 416 Email: farinacci@gmail.com