idnits 2.17.1 draft-boucadair-lisp-itr-failure-05.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 9 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2017) is 2357 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 8113 (Obsoleted by RFC 9304) == Outdated reference: A later version (-07) exists of draft-boucadair-lisp-bulk-05 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Experimental Orange 5 Expires: April 18, 2018 October 15, 2017 7 Improving ITR Resiliency in Locator/ID Separation Protocol (LISP) 8 Networks 9 draft-boucadair-lisp-itr-failure-05 11 Abstract 13 This document defines an extension to the Locator/ID Separation 14 Protocol (LISP) to minimize LISP service disruption during Ingress 15 Tunnel Routers (ITRs) failure events. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 18, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Map-Solicit-Request: Message Format & Behavior . . . . . . . 5 60 4. Map-Solicit-Reply: Message Format & Behavior . . . . . . . . 7 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 8.1. Normative references . . . . . . . . . . . . . . . . . . 10 66 8.2. Informative References . . . . . . . . . . . . . . . . . 11 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 Locator/ID Separation Protocol (LISP, [RFC6830] ) operation relies 72 upon a mapping mechanism that is used by Ingress/Egress Tunnel 73 Routers (xTR) to forward traffic over the LISP network. 75 A reboot of an ITR may dramatically affect the LISP-based forwarding 76 service for hosts connected to the LISP network. Because of the 77 purge of the mapping cache maintained by the rebooting ITR, the 78 absence of a matching entry for packets to be forwarded over the LISP 79 network will simply cause the dropping of such packets, even though 80 other ITRs of the LISP domain may be "ready-to-serve". 82 An ITR that loses its local mapping table for some reason is very 83 likely to drop incoming packets whose forwarding decision relies upon 84 the entries of the local mapping table. This type of ITR failure may 85 rarely occur, but when it does, it is likely to provoke severe 86 service degradation. 88 This document proposes a solution to enhance the robustness of LISP 89 networks during such ITR failure events. This document assumes that 90 several ITRs are available within the LISP network. The solution 91 allows for an automatic discovery of the available ITRs of a given 92 LISP domain. 94 The approach exclusively focuses on engineering tweaks that can be 95 implemented within a LISP-enabled network without soliciting the help 96 of the LISP Mapping System. [I-D.boucadair-lisp-subscribe] is a 97 companion document that specifies a procedure that is meant to 98 rapidly populate a local mapping cache upon restart or whenever 99 failures affect ITR operation. 101 2. Procedure 103 The overall procedure is as follows: 105 1. A dedicated IPv4 and/or IPv6 multicast address is reserved for 106 ITR resiliency (called @MCAST in this document). An address can 107 be reserved by an administrator for this purpose. 109 2. A list of unicast addresses of available ITRs in a given domain 110 is maintained by the requesting ITR (ITR-PEER-LIST). 112 3. When an ITR loses its mapping table for some reason (power 113 failure, software issue, etc.), but can still forward packets, it 114 checks whether it maintains a list of peer ITRs. If the peer ITR 115 list is empty, it sends a message, denoted Map-Solicit-Request 116 (Section 3), to @MCAST. If a list is available, the ITR follows 117 Steps (5, 6, and 7). 119 Note that the same IP address (@MCAST) is used to announce the 120 availability of an ITR within a LISP domain on a regular basis. 122 4. Once this message is received by another ITR reachable in the 123 LISP domain, it replies with a Map-Solicit-Reply (Section 4) 124 using its unicast address as the source IP address. The Map- 125 Solicit-Reply includes the following information: 127 * Database Status (including cache status). A status set to 128 'Null' indicates this ITR does not maintain any cache because, 129 e.g., it is a new ITR, it lost its mappings, etc. 131 * The content of local ITR-PEER-LIST: This is to accelerate the 132 process of discovering other ITRs within a LISP domain without 133 waiting for responses from other ITRs. 135 * Synchronisation reachability information (address, port 136 number, protocol, etc.) 138 5. Bulk mapping requests (e.g., [I-D.boucadair-lisp-bulk] or 139 [I-D.boucadair-lisp-multiple-records]) are then sent to peer ITRs 140 to retrieve a copy of their map cache. One or several ITRs can 141 be solicited simultaneously. 143 6. In the meantime, cache synchronisation is in progress, packets 144 that do not match a mapping entry are redirected to another ITR 145 in the domain that has its database 'ready-to-serve'. These 146 packets are encapsulated in a LISP header using the unicast 147 address discovered in the previous steps. 149 7. A peer ITR decapsulates the packet, encapsulates it according to 150 the matching mapping entry, and forwards the encapsulated packet 151 towards the next hop. Moreover, it sends an unsolicited Map- 152 Reply to the original ITR so that it can handle locally 153 subsequent packets that belong to this flow. 155 The 'nonce' of the unsolicited Map-Reply must echo the one 156 included in the encapsulated packet received from the first ITR. 158 An indication to disable data gleaning may be included by the 159 relay ITR (e.g., using the extension defined in Section 3 of 160 [I-D.boucadair-lisp-ms-assisted-forwarding]). 162 Figure 1 illustrates an example of an ITR (ITR1) which encounters a 163 loss of its mapping cache. As a result, it generates a Map-Solicit- 164 Request that it sends to the multicast address @MCAST. Upon receipt 165 of that request by ITR2 and ITR3, they each reply with a Map-Solicit- 166 Reply message. The first reply is used by ITR1 to decide to which 167 peer ITR it will redirect packets during the failure event (ITR2). 168 These packets are encapsulated with a LISP header and forwarded to 169 ITR2. Once received by ITR2, these packets are forwarded to their 170 ultimate ETR. In the meantime, ITR2 generates an unsolicited Map- 171 Reply to inform ITR1 with the mapping entries related to the 172 destination EID. Subsequent packets that belong to this flow are 173 therefore handled locally by ITR1 without soliciting ITR2. 175 +--------+ +--------+ +--------+ +--------+ 176 | ITR1 | | ITR2 | | ITR3 | | ETR | 177 +--------+ +--------+ +--------+ +--------+ 178 | | | | 179 |Map-Solicit-Request | | | 180 | to @MCAST | | | 181 |--------> | | | 182 | Map-Solicit-Reply| | | 183 |<--------------------------| | | 184 | Map-Solicit-Reply| | 185 |<-------------------------------------| | 186 src=s_EID| | | 187 -------->|src=RLOC_itr1 dst=RLOC_itr2| | 188 dst=d_EID|===Encapsulated Packet====>|src=RLOC_itr2 dst=RLOC_etr|src=s_EID 189 | Unsolicited Map-Reply |===Encapsulated Packet===>|--------> 190 |<--------------------------| |dst=d_EID 191 | | 192 src=s_EID| | 193 -------->|src=RLOC_itr1 dst=RLOC_etr|src=s_EID 194 dst=d_EID|===================Encapsulated Packet===============>|--------> 195 | |dst=d_EID 196 .... 197 src=s_EID| | 198 -------->|src=RLOC_itr1 dst=RLOC_etr |src=s_EID 199 dst=d_EID|===================Encapsulated Packet===============>|--------> 200 | |dst=d_EID 202 Figure 1: Flow Example 204 3. Map-Solicit-Request: Message Format & Behavior 206 The format of the Map-Solicit-Request message is shown in Figure 2. 207 This format follows the LISP shared extension message defined in 208 [RFC8113]. 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 |Type=15| Sub-type |R|S|D| Reserved | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Nonce . . . | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | . . . Nonce | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Key ID | Authentication Data Length | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 ~ Authentication Data ~ 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | | 224 | IP Address (128 bits) | 225 | | 226 | | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Port Number | Protocol | Reserved | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 2: Map-Solicit-Request Message Format 233 The description of the fields is as follows: 235 o Type MUST be set to 15 [RFC8113]. 237 o sub-type: MUST be set to 1026. 239 o R: MUST be set to 0 for Map-Solicit-Request messages. 241 o S: when set, this flag indicates that the originating ITR supports 242 a mechanism for state synchronisation of the mapping cache between 243 ITRs. When this flag is set, the message MUST carry the port 244 number, protocol, and IP Address used for synchronisation 245 purposes. This specification allows to indicate a distinct IP 246 address for state synchronisation purposes. 248 o D: This flag indicates the status of the mapping cache table. It 249 is RECOMMENDED to set this flag to 1 when the ITR is up and 250 running for at least one hour and has a non-empty mapping cache. 251 An ITR that lost its state MUST set this flag to 0. 253 o Nonce, Key ID, Authentication Data Length, and Authentication Data 254 are similar to those of a LISP Map-Register message ([RFC6830]). 256 o IP Address: If S-bit is set, this field indicates the IP address 257 used to receive state synchronisation messages. If S-bit is 258 unset, this field MUST be set to zero at the originating ITR and 259 MUST be ignored at receipt. The length of this field is 128 bits. 260 IPv4 addresses are encoded as IPv4-mapped IPv6 addresses [RFC4291] 261 (::ffff:0:0/96). 263 o Port Number: If the S-bit is set, this field indicates the port 264 number used to receive state synchronisation messages. If unset, 265 this field MUST be set to zero at the originating ITR and MUST be 266 ignored at receipt. 268 o Protocol: If the S-bit is set, this field indicates the protocol 269 used to transport state synchronisation messages. If unset, this 270 field MUST be set to zero at the originating ITR and MUST be 271 ignored upon receipt. 273 An ITR that issues this message MUST use one of its unicast IP 274 addresses as the source address. The destination IP address MUST be 275 set to the @MCAST multicast address introduced in Section 2. An ITR 276 that loses its cache MUST issue this message with a D-bit set to 0. 278 4. Map-Solicit-Reply: Message Format & Behavior 280 All ITRs of a LISP domain MUST subscribe to the multicast group 281 defined by the aforementioned @MCAST multicast address. 283 Upon receipt of the Map-Solicit-Request message by an ITR within the 284 domain, it replies (unicast) with a Map-Solicit-Reply. It is the 285 responsibility of the first ITR to initiate a state synchronisation 286 with that peer if the D-bit and S-bit are unset and if it supports 287 the synchronisation protocol indicated in the Map-Solicit-Reply. 289 ITRs of a LISP domain MUST send Map-Solicit-Reply in a regular 290 interval (that is configured by an administrator) or upon major 291 change in the ITR stats (e.g., loss of the mapping cache, change of 292 the IP address). This message MUST use one of the ITR unicast IP 293 addresses as the source address while the destination IP address MUST 294 be set to the @MCAST. 296 The format of the Map-Solicit-Reply message is shown in Figure 3. 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |Type=15| Sub-type |R|S|D| Reserved | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Nonce . . . | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | . . . Nonce | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Key ID | Authentication Data Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 ~ Authentication Data ~ 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | | 312 | IP Address (128 bits) | 313 | | 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 |Port Number |Protocol |ITR List Count | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | | 319 | Peer ITR Unicast Address | 320 | (128 bits) | 321 | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 ... 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | | 326 | Peer ITR Unicast Address | 327 | (128 bits) | 328 | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 3: Map-Solicit-Reply Message Format 333 The description of the fields is as follows: 335 o Type MUST be set to 15 [RFC8113]. 337 o sub-type: MUST be set to 1026. 339 o R: MUST be set to 1. 341 o S: when set, this flag indicates that the originating ITR supports 342 a mechanism for state synchronisation of the mapping caches 343 between ITRs. When set, the message MUST carry the port number, 344 protocol, and IP Address used for synchronisation purposes. This 345 specification allows to indicate a distinct IP address for state 346 synchronisation purposes. 348 o D: This flag indicates the status of the mapping cache table. It 349 is RECOMMENDED to set this flag when the ITR is up and running for 350 at least one hour and has a non-empty mapping cache. 352 o Nonce: The 'Nonce' field of multicast Map-Solicit-Reply MUST be 353 set to 0 while it MUST echo the one included in a Map-Solicit- 354 Request when replying to a multicast Map-Solicit-Request. 356 o Key ID, Authentication Data Length, and Authentication Data are 357 similar to those of a LISP Map-Register message ([RFC6830]). 359 o IP Address: If the S-bit is set, this field indicates the IP 360 address used to receive state synchronisation messages. If unset, 361 this field MUST be set to zero at the originating ITR and MUST be 362 ignored upon receipt. The length of this field is 128 bits. IPv4 363 addresses are encoded as IPv4-mapped IPv6 addresses [RFC4291] 364 (::ffff:0:0/96). 366 o Port Number: If the S-bit is set, this field indicates the port 367 number used to receive state synchronisation messages. If unset, 368 this field MUST be set to zero at the originating ITR and MUST be 369 ignored upon receipt. 371 o Protocol: If the S-bit is set, this field indicates the protocol 372 used to transport state synchronisation messages. If unset, this 373 field MUST be set to zero at the originating ITR and MUST be 374 ignored upon receipt. 376 o ITR List Count: This field indicates whether peer ITR addresses 377 are also included. When this field is set to 0, it indicates that 378 no peers other than the solicited peer ITR are known to the 379 originating ITR. 381 o Peer ITR Unicast Address: one or multiple IP addresses that belong 382 to other ITRs in the domain as known to the originating ITR. The 383 length of each "Peer ITR Unicast Address" is 128 bits. IPv4 384 addresses are encoded as IPv4-mapped IPv6 addresses 385 (::ffff:0:0/96). 387 A Map-Solicit-Reply can be generated by an ITR to advertise its 388 availability to the other ITRs of the LISP domain, as per normal LISP 389 operation. 391 When an ITR receives a LISP-encapsulated packet from an ITR that is 392 present in its list of peer ITRs, it may generate an unsolicited Map- 393 Reply that conveys the mapping entry that was used to process the 394 encapsulated packet. 396 Upon failure or reboot that lead to lose the contents of its mapping 397 cache, an ITR uses the list of peers ITRs it discovered by means of 398 the Map-Solicit-Request message sent to @MCAST to redirect packets 399 that do not match any entry of its local cache (which is likely to be 400 empty). 402 In order to minimize the risk of overloading some ITRs, a mechanism 403 to distribute the load among all the peer ITRs or part of them is 404 deemed useful. Of course, other traffic load distribution policies 405 may be enforced. The exact set of policies to be enforced are 406 implementation- and deployment-specific. 408 5. Security Considerations 410 LISP security considerations are discussed in [RFC6830]. 412 This document specifies a mechanism that enhances the serviceability 413 of LISP networks by redirecting traffic that do not match a local 414 mapping entry to other ITRs of the domain. These ITRs are assumed to 415 belong to the same administrative domain. Means to ensure that only 416 trusted ITRs are maintained in a peer list MUST be enabled. 418 6. IANA Considerations 420 IANA has assigned the following code from the LISP Shared Extension 421 Message Type Sub-types ([RFC8113]): 423 Message Sub-type Reference 424 ===================================== ======= =============== 425 Map-Solicit-Request/Map-Solicit-Reply 1026 [This document] 427 7. Acknowledgments 429 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 430 009-X. 432 Many thanks to Chi Dung Phung for the review. 434 8. References 436 8.1. Normative references 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, 440 DOI 10.17487/RFC2119, March 1997, 441 . 443 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 444 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 445 2006, . 447 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 448 Locator/ID Separation Protocol (LISP)", RFC 6830, 449 DOI 10.17487/RFC6830, January 2013, 450 . 452 [RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation 453 Protocol (LISP): Shared Extension Message & IANA Registry 454 for Packet Type Allocations", RFC 8113, 455 DOI 10.17487/RFC8113, March 2017, 456 . 458 8.2. Informative References 460 [I-D.boucadair-lisp-bulk] 461 Boucadair, M. and C. Jacquenet, "LISP Mapping Bulk 462 Retrieval", draft-boucadair-lisp-bulk-05 (work in 463 progress), April 2017. 465 [I-D.boucadair-lisp-ms-assisted-forwarding] 466 Boucadair, M. and C. Jacquenet, "Mapping System-Assisted 467 Forwarding for Inter-Domain LISP Deployments", draft- 468 boucadair-lisp-ms-assisted-forwarding-00 (work in 469 progress), September 2015. 471 [I-D.boucadair-lisp-multiple-records] 472 Boucadair, M. and C. Jacquenet, "Retrieving Multiple LISP 473 Records", draft-boucadair-lisp-multiple-records-00 (work 474 in progress), October 2017. 476 [I-D.boucadair-lisp-subscribe] 477 Boucadair, M. and C. Jacquenet, "LISP Subscription", 478 draft-boucadair-lisp-subscribe-05 (work in progress), 479 April 2017. 481 Authors' Addresses 482 Mohamed Boucadair 483 Orange 484 Rennes 35000 485 France 487 EMail: mohamed.boucadair@orange.com 489 Christian Jacquenet 490 Orange 491 Rennes 35000 492 France 494 EMail: christian.jacquenet@orange.com