idnits 2.17.1 draft-farinacci-lisp-decent-07.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 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 19 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 271: '... An ITR SHOULD lookup its mapping sy...' RFC 2119 keyword, line 418: '... The Hash Mask MUST include the stri...' RFC 2119 keyword, line 430: '...t messages, xTRs MAY round robin EID l...' RFC 2119 keyword, line 473: '... However, an implementation SHOULD do...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2021) is 1145 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) == Outdated reference: A later version (-12) exists of draft-ietf-lisp-ecdsa-auth-04 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-07 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-22 Summary: 4 errors (**), 0 flaws (~~), 7 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 C. Cantrell 5 Expires: September 9, 2021 Nexus 6 March 8, 2021 8 A Decent LISP Mapping System (LISP-Decent) 9 draft-farinacci-lisp-decent-07 11 Abstract 13 This draft describes how the LISP mapping system designed to be 14 distributed for scale can also be decentralized for management and 15 trust. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 9, 2021. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 53 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Push-Based Mapping System . . . . . . . . . . . . . . . . . . 5 55 4.1. Components of a Pushed-Based LISP-Decent xTR . . . . . . 5 56 4.2. No LISP Protocol Changes . . . . . . . . . . . . . . . . 6 57 4.3. Configuration and Authentication . . . . . . . . . . . . 7 58 4.4. Core Seed-Group . . . . . . . . . . . . . . . . . . . . . 7 59 5. Pull-Based Mapping System . . . . . . . . . . . . . . . . . . 9 60 5.1. Components of a Pulled-Based LISP-Decent xTR . . . . . . 9 61 5.2. Deployment Example . . . . . . . . . . . . . . . . . . . 10 62 5.3. Management Considerations . . . . . . . . . . . . . . . . 11 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 67 8.2. Informative References . . . . . . . . . . . . . . . . . 13 68 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 69 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 14 70 B.1. Changes to draft-farinacci-lisp-decent-07 . . . . . . . . 14 71 B.2. Changes to draft-farinacci-lisp-decent-06 . . . . . . . . 14 72 B.3. Changes to draft-farinacci-lisp-decent-05 . . . . . . . . 14 73 B.4. Changes to draft-farinacci-lisp-decent-04 . . . . . . . . 14 74 B.5. Changes to draft-farinacci-lisp-decent-03 . . . . . . . . 14 75 B.6. Changes to draft-farinacci-lisp-decent-02 . . . . . . . . 14 76 B.7. Changes to draft-farinacci-lisp-decent-01 . . . . . . . . 15 77 B.8. Changes to draft-farinacci-lisp-decent-00 . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 The LISP architecture and protocols [RFC6830] introduces two new 83 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 84 (RLOCs) which is intended to provide overlay network functionality. 85 To map from EID to a set or RLOCs, a control-plane mapping system are 86 used [RFC6836] [RFC8111]. These mapping systems are distributed in 87 nature in their deployment for scalability but are centrally managed 88 by a third- party entity, namely a Mapping System Provider (MSP). 89 The entities that use the mapping system, such as data-plane xTRs, 90 depend on and trust the MSP. They do not participate in the mapping 91 system other than to register and retrieve information to/from the 92 mapping system [RFC6833]. 94 This document introduces a Decentralized Mapping System (DMS) so the 95 xTRs can participate in the mapping system as well as use it. They 96 can trust each other rather than rely on third-party infrastructure. 98 The xTRs act as Map-Servers to maintain distributed state for scale 99 and reducing attack surface. 101 2. Definition of Terms 103 Mapping System Provider (MSP): is an infrastructure service that 104 deploys LISP Map-Resolvers and Map-Servers [RFC6833] and possibly 105 ALT-nodes [RFC6836] or DDT-nodes [RFC8111]. The MSP can be 106 managed by a separate organization other than the one that manages 107 xTRs. This model provides a business separation between who 108 manages and is responsible for the control-plane versus who 109 manages the data-plane overlay service. 111 Decentralized Mapping System (DMS): is a mapping system entity that 112 is not third-party to the xTR nodes that use it. The xTRs 113 themselves are part of the mapping system. The state of the 114 mapping system is fully distributed, decentralized, and the trust 115 relies on the xTRs that use and participate in their own mapping 116 system. 118 Pull-Based Mapping System: the mapping system is pull-based meaning 119 that xTRs will lookup and register mappings by algorithmic 120 transformation to locate which Map-Resolvers and Map-Servers are 121 used. It is required that the lookup and registration uses a 122 consistent algorithmic transformation function. Map-Registers are 123 pushed to specific Map-Servers. Map-Requests are external lookups 124 to Map-Resolvers on xTRs that do not participate in the mapping 125 system and internal lookups when they do. 127 Modulus Value: this value is used in the Pull-Based Mapping System. 128 It defines the number of map-server sets used for the mapping 129 system. The modulus value is used to produce a Name Index used 130 for a DNS lookup. 132 Name Index: this index value is used in the Pull-Based 133 Mapping System. For a mapping system that is configured with a 134 map-server set of DNS names in the form of .domain.com, the 135 name index is prepended to to form the lookup name 136 ..domain.com. If the Modulus Value is 8, then the 137 name indexes are 0 through 7. 139 Hash Mask: The Hash Mask is used in the Pull-Based Mapping System. 140 It is a mask value with 1 bits left justified. The mask is used 141 to select what high-order bits of an EID-prefix is used in the 142 hash function. 144 Push-Based Mapping System: the mapping system is push-based meaning 145 that xTRs will push registrations via IP multicast to a group of 146 Map-Servers and do local lookups acting as their own Map- 147 Resolvers. 149 Replication List Entry (RLE): is an RLOC-record format that contains 150 a list of RLOCs that an ITR replicates multicast packets on a 151 multicast overlay. The RLE format is specified in [RFC8060]. 152 RLEs are used with the Pushed-Based mapping system. 154 Group Address EID: is an EID-record format that contains IPv4 155 (0.0.0.0/0, G) or IPv6 (0::/0, G) state. This state is encoded as 156 a Multicast Info Type LCAF specified in [RFC8060]. Members of a 157 seed-group send Map-Registers for (0.0.0.0/0, G) or (0::/0, G) 158 with an RLOC-record that RLE encodes its RLOC address. Details 159 are specified in [RFC8378]. 161 Seed-Group: is a set of Map-Servers joined to a multicast group for 162 the Push-Based Mapping system or are mapped by DNS names in a 163 Pull-Based Mapping System. A core seed-group is used to bootstrap 164 a set of LISP-Decent xTRs so they can learn about each other and 165 use each other's mapping system service. A seed-group can be 166 pull-based to bootstrap a push-based mapping system. That is, a 167 set of DNS mapped map-servers can be used to join the mapping 168 system's IP multicast group. 170 3. Overview 172 The clients of the Decentralized Mapping System (DMS) are also the 173 providers of mapping state. Clients are typically ETRs that Map- 174 Register EID-to-RLOC mapping state to the mapping database system. 175 ITRs are clients in that they send Map-Requests to the mapping 176 database system to obtain EID-to-RLOC mappings that are cached for 177 data-plane use. When xTRs participate in a DMS, they are also acting 178 as Map-Resolvers and Map-Servers using the protocol machinery defined 179 in LISP control-plane specifications [RFC6833], [I-D.ietf-lisp-sec], 180 and [I-D.ietf-lisp-ecdsa-auth]. The xTRs are not required to run the 181 database mapping transport system protocols specified in [RFC6836] or 182 [RFC8111]. 184 This document will describe two decentralized and distributed mapping 185 system mechanisms. A Push-Based Mapping System uses IP multicast so 186 xTRs can find each other by locally joining an IP multicast group. A 187 Pull-Based Mapping System uses DNS with an algorithmic transformation 188 function so xTRs can find each other. 190 4. Push-Based Mapping System 192 The xTRs are organized in a mapping-system group. The group is 193 identified by an IPv4 or IPv6 multicast group address or using a 194 pull-based approach in described in Section 5. When using multicast, 195 the xTRs join the same multicast group and receive LISP control-plane 196 messages addressed to the group. Messages sent to the multicast 197 group are distributed when the underlay network supports IP multicast 198 [RFC6831] or is achieved with the overlay multicast mechanism 199 described in [RFC8378]. When overlay multicast is used and LISP Map- 200 Register messages are sent to the group, they are LISP data 201 encapsulated with a instance-ID set to 0xffffff in the LISP header. 202 The inner header of the encapsulated packet has the destination 203 address set to the multicast group address and the outer header that 204 is prepended has the destination address set to the RLOC of mapping 205 system member. The members of the mapping system group are kept in 206 the LISP data-plane map-cache so packets for the group can be 207 replicated to each member RLOC. 209 All xTRs in a mapping system group will store the same registered 210 mappings and maintain the state as Map-Servers normally do. The 211 members are not only receivers of the multicast group but also send 212 packets to the group. 214 4.1. Components of a Pushed-Based LISP-Decent xTR 216 When an xTR is configured to be a LISP-Decent xTR (or PxTR 217 [RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP 218 network functions. 220 The following diagram shows 3 LISP-Decent xTRs joined to mapping 221 system group 224.1.1.1. When the ETR function of xTR1 originates a 222 Map-Register, it is sent to all xTRs (including itself) synchronizing 223 all 3 Map-Servers in xTR1, xTR2, and xTR3. The ITR function can 224 populate its map-cache by sending a Map-Request locally to its Map- 225 Resolver so it can replicate packets to each RLOC for EID 224.1.1.1. 227 xTR1 228 Map-Request +--------------------+ 229 (always local) | +-----+ +-----+ | 230 +---------------| ITR | | ETR |-------------+ 231 | | +-----+ +-----+ | | 232 | | | | Map-Register to EID 233 | | +-------+ | | 224.1.1.1 encapsulated to 234 +------------------>| MR/MS |<---------------+ RLOCs xTR1, xTR2, and xTR3 235 | +-------+ | | 236 +--------------------+ | 237 | 238 +--------------------+------------+ 239 | | 240 | | 241 +----------v---------+ +----------v---------+ 242 | +--------+ | | +--------+ | 243 | | MR/MS | | | | MR/MS | | 244 | +--------+ | | +--------+ | 245 | +-----+ +-----+ | | +-----+ +-----+ | 246 | | ITR | | ETR | | | | ITR | | ETR | | 247 | +-----+ +-----+ | | +-----+ +-----+ | 248 +--------------------+ +--------------------+ 249 xTR2 xTR3 251 Note if any external xTR would like to use a Map-Resolver from the 252 mapping system group, it only needs to have one of the LISP-Decent 253 Map-Resolvers configured. By doing a looking to this Map-Resolver 254 for EID 224.1.1,1, the external xTR could get the complete list of 255 members for the mapping system group. 257 For future study, an external xTR could multicast the Map-Request to 258 224.1.1.1 and either one of the LISP-Decent Map-Resolvers would 259 return a Map-Reply or the external xTR is prepared to receive 260 multiple Map-Replies. 262 4.2. No LISP Protocol Changes 264 There are no LISP protocol changes required to support the push-based 265 LISP-Decent set of procedures. However, an implementation that sends 266 Map-Register messages to a multicast group versus a specific Map- 267 Server unicast address must change to call the data-plane component 268 so the ITR functionality in the node can encapsulate the Map-Register 269 as a unicast packet to each member of the mapping system group. 271 An ITR SHOULD lookup its mapping system group address periodically to 272 determine if the membership has changed. The ITR can also use the 273 pubsub capability documented in [I-D.ietf-lisp-pubsub] to be notified 274 when a new member joins or leaves the multicast group. 276 4.3. Configuration and Authentication 278 When xTRs are joined to a multicast group, they must have their site 279 registration configuration consistent. Any policy or authentication 280 key material must be configured correctly and consistently among all 281 members. When [I-D.ietf-lisp-ecdsa-auth] is used to sign Map- 282 Register messages, public-keys can be registered to the mapping 283 system group using the site authentication key mentioned above or 284 using a different authentication key from the one used for 285 registering EID records. 287 4.4. Core Seed-Group 289 A core seed-group can be discovered using a multicast group in a 290 push-based system or a Map-Server set of DNS names in a pull-based 291 system (see Section 5 for details). 293 When using multicast for the mapping system group, a core seed-group 294 multicast group address can be preconfigured to bootstrap the 295 decentralized mapping system. The group address (or DNS name that 296 maps to a group address) can be explicitly configured in a few xTRs 297 to start building up the registrations. Then as other xTRs come 298 online, they can add themselves to the core seed-group by joining the 299 seed-group multicast group. 301 Alternatively or additionally, new xTRs can join a new mapping system 302 multicast group to form another layer of a decentralized mapping 303 system. The group address and members of this new layer seed-group 304 would be registered to the core seed-group address and stored in the 305 core seed-group mapping system. Note each mapping system layer could 306 have a specific function or a specific circle of trust. 308 This multi-layer mapping system can be illustrated: 310 __________ --------- 311 / core \ 224.2.2.2 / layer-1 \ 312 | seed-group | --------> | I | 313 | 224.1.1.1 | | / \ | 314 \__________/ | J---K | 315 | \_________/ 316 | 224.3.3.3 317 | 318 v 319 --------- 320 / layer-2 \ 321 | X | 322 | / \ | 323 | Y---Z | 324 \_________/ 326 Configured in xTRs A, B, and C (they make up the core seed-group): 327 224.1.1.1 -> RLE: A, B, C 329 core seed-group DMS, mapping state in A, B, and C: 330 224.2.2.2 -> RLE: I, J, K 331 224.3.3.3 -> RLE: X, Y, Z 333 layer-1 seed-group DMS (inter-continental), mapping state in I, J, K: 334 EID1 -> RLOCs: i(1), j(2) 335 ... 336 EIDn -> RLOCs: i(n), j(n) 338 layer-2 seed-group DMS (intra-continental), mapping sate in X, Y, Z:: 339 EIDa -> RLOCs: x(1), y(2) 340 ... 341 EIDz -> RLOCs: x(n), y(n) 343 The core seed-group multicast address 224.1.1.1 is configured in xTRs 344 A, B and C so when each of them send Map-Register messages, they 345 would all be able to maintain synchronized mapping state. Any EID 346 can be registered to this DMS but in this example, seed-group 347 multicast group EIDs are being registered only to find other mapping 348 system groups. 350 For example, lets say that xTR I boots up and it wants to find its 351 other peers in its mapping system group 224.2.2.2. Group address 352 224.2.2.2 is configured so xTR I knows what group to join for its 353 mapping system group. But xTR I needs a mapping system to register 354 to, so the core seed-group is used and available to receive Map- 355 Registers. The other xTRs J and K in the mapping system group do the 356 same so when any of I, J or K needs to register EIDs, they can now 357 send their Map-Register messages to group 224.2.2.2. Examples of 358 EIDs being register are EID1 through EIDn shown above. 360 When Map-Registers are sent to group 224.2.2.2, they are encapsulated 361 by the LISP data-plane by looking up EID 224.2.2.2 in the core seed- 362 group mapping system. For the map-cache entry to be populated for 363 224.2.2.2, the data-plane must send a Map-Request so the RLOCs I, J, 364 and K are cached for replication. To use the core seed-group mapping 365 system, the data-plane must know of at least one of the RLOCs A, B, 366 and/or C. 368 5. Pull-Based Mapping System 370 5.1. Components of a Pulled-Based LISP-Decent xTR 372 When an xTR is configured to be a LISP-Decent xTR (or PxTR 373 [RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP 374 network functions. 376 Unlike the Push-Based Mapping System, the xTRs do not need to be 377 organized by joining a multicast group. In a Pull-Based Mappig 378 System, a hash function over an EID is used to identify which xTR is 379 used as the Map-Resolver and Map-Server. The Domain Name System 380 (DNS) [RFC1034] [RFC1035] is used as a resource discovery mechanism. 382 The RLOC addresses of the xTRs will be A and AAAA records for DNS 383 names that map algorithmically from the hash of the EID. A SHA-256 384 hash function [RFC6234] over the following ASCII formatted EID string 385 is used: 387 []/ 388 []/-/ 390 Where is the instance-ID and is the EID of any EID-type 391 defined in [RFC8060]. And then the Modulus Value is used to 392 produce the Name Index used to build the DNS lookup name: 394 eid = "[]/" 395 index = hash.sha_256(eid) MOD mv 397 The Hash Mask is used to select what bits are used in the SHA-256 398 hash function. This is required to support longest match lookups in 399 the mapping system. The same map-server set needs to be selected 400 when looking up a more-specific EID found in the Map-Request message 401 with one that could match a less-specific EID-prefix registered and 402 found in the Map-Register message. For example, if an EID-prefix 404 [0]240.0.1.0/24 is registered to the mapping system and EID 405 [0]240.0.1.1/32 is looked up to match the registered prefix, a Hash 406 Mask of 8 bytes can be used to AND both the /32 or /24 entries to 407 produce the same hash string bits of "[0]240.0". 409 For (*,G) and (S,G) multicast entries in the mapping system, the hash 410 strings are: 412 sg-eid = "[]/-/" 413 index = hash.sha_256(sg-eid) MOD mv 415 starg-eid = "[]/-0.0.0.0/0" 416 index = hash.sha_256(starg-eid) MOD mv 418 The Hash Mask MUST include the string "[]" and not string 419 . So when looking up [0](2.2.2.2, 224.1.1.1) that will match 420 a (*, 224.1.1.1/32), the hash string produced with a Hash Mask of 12 421 bytes is "[0]224.1.1.1". 423 When the is computed from a unicast or multicast EID, the DNS 424 lookup name becomes: 426 .map-server.domain.com 428 When an xTR does a DNS lookup on the lookup name, it will send Map- 429 Register messages to all A and AAAA records for EID registrations. 430 For Map-Request messages, xTRs MAY round robin EID lookup requests 431 among the A and AAAA records. 433 5.2. Deployment Example 435 Here is an example deployment of a pull-based model. Let's say 4 436 map-server sets are provisioned for the mapping system. Therefore 4 437 distinct DNS names are allocated and a Modulus Value 4 is used. Each 438 DNS name is allocated Name Index 0 through 3: 440 0.map-server.lispers.net 441 1.map-server.lispers.net 442 2.map-server.lispers.net 443 3.map-server.lispers.net 445 The A records for each name can be assigned as: 447 0.map-server.lispers.net: 448 A 449 A 450 1.map-server.lispers.net: 451 A 452 A 453 2.map-server.lispers.net: 454 A 455 A 456 3.map-server.lispers.net: 457 A 458 A 460 When an xTR wants to register "[1000]fd::2222", it hashes the EID 461 string to produce, for example, hash value 0x66. Using the modulus 462 value 4 (0x67 & 0x3) produces index 0x3, so the DNS name 3.map- 463 server.lispers.net is used and a Map-Regiter is sent to 464 and . 466 Note that the pull-based method can be used for a core seed-group for 467 bootstraping a push-based mapping system where multicast groups are 468 registered. 470 5.3. Management Considerations 472 There are no LISP protocol changes required to support the pull-based 473 LISP-Decent set of procedures. However, an implementation SHOULD do 474 periodic DNS lookups to determine if A records have changed for a DNS 475 entry. 477 When xTRs derive Map-Resolver and Map-Server names from the DNS, they 478 need to use the same Modulus Value otherwise some xTRs will lookup 479 EIDs to the wrong place they were registered. 481 The Modulus Value can be configured or pushed to the LISP-Decent 482 xTRs. A future version of this document will describe a push 483 mechanism so all xTRs use a consistent modulus value. 485 6. Security Considerations 487 Refer to the Security Considerations section of 488 [I-D.ietf-lisp-rfc6833bis] for a complete list of security mechanisms 489 as well as pointers to threat analysis drafts. 491 7. IANA Considerations 493 At this time there are no specific requests for IANA. 495 8. References 497 8.1. Normative References 499 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 500 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 501 . 503 [RFC1035] Mockapetris, P., "Domain names - implementation and 504 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 505 November 1987, . 507 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 508 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 509 DOI 10.17487/RFC6234, May 2011, 510 . 512 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 513 Locator/ID Separation Protocol (LISP)", RFC 6830, 514 DOI 10.17487/RFC6830, January 2013, 515 . 517 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 518 Locator/ID Separation Protocol (LISP) for Multicast 519 Environments", RFC 6831, DOI 10.17487/RFC6831, January 520 2013, . 522 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 523 "Interworking between Locator/ID Separation Protocol 524 (LISP) and Non-LISP Sites", RFC 6832, 525 DOI 10.17487/RFC6832, January 2013, 526 . 528 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 529 Protocol (LISP) Map-Server Interface", RFC 6833, 530 DOI 10.17487/RFC6833, January 2013, 531 . 533 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 534 "Locator/ID Separation Protocol Alternative Logical 535 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 536 January 2013, . 538 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 539 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 540 February 2017, . 542 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 543 Smirnov, "Locator/ID Separation Protocol Delegated 544 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 545 May 2017, . 547 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 548 Separation Protocol (LISP) Multicast", RFC 8378, 549 DOI 10.17487/RFC8378, May 2018, 550 . 552 8.2. Informative References 554 [I-D.ietf-lisp-ecdsa-auth] 555 Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA 556 Authentication and Authorization", draft-ietf-lisp-ecdsa- 557 auth-04 (work in progress), September 2020. 559 [I-D.ietf-lisp-pubsub] 560 Rodriguez-Natal, A., Ermagan, V., Cabellos-Aparicio, A., 561 Barkai, S., and M. Boucadair, "Publish/Subscribe 562 Functionality for LISP", draft-ietf-lisp-pubsub-07 (work 563 in progress), January 2021. 565 [I-D.ietf-lisp-rfc6833bis] 566 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 567 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 568 Plane", draft-ietf-lisp-rfc6833bis-30 (work in progress), 569 November 2020. 571 [I-D.ietf-lisp-sec] 572 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 573 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-22 574 (work in progress), January 2021. 576 Appendix A. Acknowledgments 578 The authors would like to thank the LISP WG for their review and 579 acceptance of this draft. 581 The authors would also like to give a special thanks to Roman 582 Shaposhnik for several discussions that occured before the first 583 draft was published. 585 Appendix B. Document Change Log 587 [RFC Editor: Please delete this section on publication as RFC.] 589 B.1. Changes to draft-farinacci-lisp-decent-07 591 o Posted March 2021. 593 o Update references and document expiry timer. 595 B.2. Changes to draft-farinacci-lisp-decent-06 597 o Posted September 2020. 599 o Update references and document expiry timer. 601 B.3. Changes to draft-farinacci-lisp-decent-05 603 o Posted March 2020. 605 o Update references and document expiry timer. 607 B.4. Changes to draft-farinacci-lisp-decent-04 609 o Posted September 2019. 611 o Update references and document expiry timer. 613 B.5. Changes to draft-farinacci-lisp-decent-03 615 o Posted March 2019. 617 o Introduce the Hash Mask which is used to grab common bits from a 618 registered prefix and a lookup prefix. 620 o Spec how multicast lookups are done in the pull-based mapping 621 system. 623 o Indicate the hash string includes the unicast EID mask-length and 624 multicast group and source mask-lengths. 626 B.6. Changes to draft-farinacci-lisp-decent-02 628 o Posted November 2018. 630 o Changed references from peer-group to seed-group to make the 631 algorithms in this document more like how blockchain networks 632 initialize the peer-to-peer network. 634 o Added pull mechanism to compliment the push mechanism. The pull 635 mechanism could be used as a seed-group to bootstrap the push 636 mechanism. 638 B.7. Changes to draft-farinacci-lisp-decent-01 640 o Posted July 2018. 642 o Document timer and reference update. 644 B.8. Changes to draft-farinacci-lisp-decent-00 646 o Initial draft posted January 2018. 648 Authors' Addresses 650 Dino Farinacci 651 lispers.net 652 San Jose, CA 653 USA 655 Email: farinacci@gmail.com 657 Colin Cantrell 658 Nexus 659 Tempe, AZ 660 USA 662 Email: colin@nexus.io