idnits 2.17.1 draft-boucadair-lisp-subscribe-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 3, 2017) is 2629 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental draft: draft-ietf-lisp-type-iana (ref. 'I-D.ietf-lisp-type-iana') ** 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 (-07) exists of draft-boucadair-lisp-bulk-03 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: Standards Track Orange 5 Expires: August 7, 2017 February 3, 2017 7 LISP Subscription 8 draft-boucadair-lisp-subscribe-04 10 Abstract 12 Mapping Services in Locator/ID Separation Protocol (LISP) networks 13 are key to proper LISP forwarding operation. When considering the 14 deployment of LISP at large scale, these Mapping Services are even 15 more crucial for the sake of the LISP forwarding efficiency. This 16 document introduces two additional LISP messages that are meant to 17 facilitate the dynamic discovery of Mapping Systems, improve Ingress 18 Tunnel Routers (ITR) recovery times and optimize the solicitation of 19 the LISP Mapping System as a function of the ITR location, in 20 particular. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 7, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Issues . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.3. Improving LISP Mapping Services . . . . . . . . . . . . . 4 66 2. Map-Subscribe Message Format . . . . . . . . . . . . . . . . 5 67 3. Map-Subscribe-Ack Message Format . . . . . . . . . . . . . . 6 68 4. Generating a Map-Subscribe Message . . . . . . . . . . . . . 9 69 5. Processing a Map-Subscribe Message . . . . . . . . . . . . . 10 70 6. Processing a Map-Subscribe-Ack Message . . . . . . . . . . . 12 71 7. Subscription to Multiple Resolvers . . . . . . . . . . . . . 13 72 8. Sample Examples . . . . . . . . . . . . . . . . . . . . . . . 13 73 8.1. Map-Resolver Redirect . . . . . . . . . . . . . . . . . . 13 74 8.2. Mapping Cache Retrieval . . . . . . . . . . . . . . . . . 14 75 8.3. Unsolicited Map-Reply . . . . . . . . . . . . . . . . . . 16 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 78 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 12.1. Normative references . . . . . . . . . . . . . . . . . . 18 81 12.2. Informative references . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 Locator/ID Separation Protocol (LISP, [RFC6830] ) operation relies 87 upon a mapping mechanism that is used by ingress/egress Tunnel 88 Routers (xTR) to forward traffic over the LISP network. The ability 89 of dynamically discovering the Map-Resolver and Map-Server entities 90 that provide such mapping services is meant to facilitate global LISP 91 operation. In particular, the ability to inform Ingress Tunnel 92 Routers (ITR) of a LISP network about the availability and the status 93 of several Mapping Services is likely to improve the overall LISP 94 forwarding serviceability. 96 1.1. Issues 98 This section lists a set of issues that need further investigation: 100 Discover ITRs: Current LISP design does not allow to automatically 101 discover active ITRs of a LISP domain (nor the mapping system of a 102 given domain is aware of ITRs of the same domain that can solicit 103 its services, let alone ITRs of other domains). The solution 104 proposed in this document allows to fill that gap. 106 Optimize EID-ROLC resolution time: Leaf LISP networks can be better 107 serviced, for example by avoiding the cascading of Map-Resolvers, 108 or by avoiding the solicitation of a Map-Resolver that is located 109 an ocean away, etc. Policies should be taken into account when 110 configuring Map-Resolver information on an ITR for improving EID- 111 to-RLOC resolution. These policies should be modified and 112 adjusted according to various events (e.g., installation of an 113 additional Map-Resolver). 115 Accomodate Map-Resolvers constraints: Allows for the protocol to 116 redirect a requesting ITR to another Map-Resolver when some events 117 occur, such as an overload of the initially targeted Map-Resolver 118 or when Map-Resolvers are optimized to service a set of 119 destination EIDs, etc. 121 Faster Recovery of mapping entries: Whenever an ITR fails for some 122 reason, the faulty ITR needs to recover at least the list of 123 mappings for the most popular prefixes in a timely manner, in 124 particular. Policies for mapping entries (to be recovered) are 125 deployment-specific. 127 Receive push notifications: For LISP leaf networks that would need 128 to maintain an up-to-date mapping table for a set of destination 129 EIDs (or even the global mapping table) to avoid issues such as 130 the loss of a first packet or to optimize LISP forwarding delay 131 (and therefore the overall forwarding efficiency), a dynamic push 132 mechanism would be helpful. 134 1.2. Assumptions 136 This document makes the following assumptions: 138 o Various LISP players (network operators, service providers, etc.) 139 are likely to deploy and operate different LISP Mapping Systems. 140 Multiple Mapping Systems will therefore coexist for various 141 reasons, e.g., avoid country-centric governance, allow for 142 distinct technologies to implement the mapping service, business 143 opportunities, service innovation, etc. 145 o Interconnection between these Mapping Systems is required for the 146 sake of global connectivity and also to minimize the risk of 147 fragmenting the Internet. 149 o Mapping Services are supposed to be dimensioned to maintain a 150 global mapping database for the entire LISP-enabled Internet. 152 o Mapping Service providers may offer advanced services to their 153 customers such as maintain local caches (a la CDN), or update ITR 154 mapping entries that match some criteria requested by a leaf LISP 155 network, redirect ITR requests to the closest Map-Resolvers, 156 structure the mapping resolution service so that the resolution 157 time is optimized, etc. 159 o The entries of the mapping tables are exchanged between these 160 Mapping systems so that Map-Request messages can be processed as 161 close to the LISP leaf networks as possible. 163 o A leaf LISP-enabled network subscribes to the Mapping Service 164 provided by one or several Mapping Service operators. 166 o The contribution of each player involved in the provisioning and 167 the operation of a LISP-based connectivity forwarding service 168 should be rationalized so that clear interfaces are defined and 169 adequate mechanisms for troubleshooting, diagnosis and repair 170 purposes can be easily implemented and adopted. The inability of 171 identifying what is at the origin of the degradation of a LISP 172 connectivity service is seen as one of the hurdles that are likely 173 to jeopardize LISP deployments at large scale. 175 1.3. Improving LISP Mapping Services 177 This document specifies a couple of additional LISP messages that are 178 meant to improve the subscription to Mapping Services, let alone 179 their serviceability. They are described in the following sections. 181 A simple method to redirect ITR-originated mapping requests towards 182 another Map-Resolver when some conditions are met (e.g., overload of 183 a Map-Resolver, enforcement of traffic engineering policies, etc.) is 184 defined in Section 2 and Section 3. 186 2. Map-Subscribe Message Format 188 The format of the Map-Subscribe message is shown in Figure 1. 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Type |A|U|B|I| Reserved | Filter Count | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | ITR Identifier | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Nonce . . . | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Nonce . . . | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | . . . Nonce | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Key ID | Authentication Data Length | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 ~ Authentication Data ~ 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Expiry Timer | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Length | | 210 +-+-+-+-+-+-+-+-+ : 211 : Filter : 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 ... 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Length | | 216 +-+-+-+-+-+-+-+-+ : 217 : Filter : 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 1: Map-Subscribe Message Format 222 The description of the fields is as follows: 224 o Type is to be defined. 226 o A (Ack-bit): this bit MUST be set to 0 for Map-Subscribe requests. 228 o U (unsolicited-map-reply bit): When set, this flag indicates that 229 the originating ITR is ready to receive implicit Map-Reply 230 messages. 232 o B (bulk-support bit): When set, this flag indicates that the 233 originating ITR supports mapping bulk retrieval method (e.g., 234 [I-D.boucadair-lisp-bulk]). 236 o I (immediate-retrieval bit): When set, this flag indicates that 237 the originating ITR requests immediate retrieval of the portion of 238 the mapping table that matches the filters included in the 239 request. 241 o Reserved: reserved bits, MUST be sent as 0 and MUST be ignored 242 when received. 244 o Filter Count: This field indicates the number of the filters 245 included in the message. 247 o Nonce, Key ID, Authentication Data Length, and Authentication Data 248 are similar to those of a LISP Map-Register message ([RFC6830]). 250 o Expiry Timer: This field indicates, in seconds, the validity timer 251 for the subscription. 253 o Length: This field indicates, in octets, the length of the filter 254 that is encoded in the "Filter" field. 256 o Filter: This field carries a destination EID (or a set thereof) 257 that is encoded as an UTF-8 string. This specification allows to 258 convey IP prefix literals, Names and/or AS numbers. One or 259 multiple filters may be present in a request. IPv4 prefixes are 260 encoded as IPv4-mapped IPv6 prefixes [RFC4291] (i.e., starting 261 with ::ffff:0:0/96). A mix of names, IP prefixes and AS numbers 262 may be enclosed in the same request. The value 0 is used to 263 delete existing filters. Filters MUST be applied in the order 264 they appear in the request. 266 3. Map-Subscribe-Ack Message Format 268 The format of the Map-Subscribe-Ack message is shown in Figure 2. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Type |A|U|B|I|R| Reserved | Result | Filter Count | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | ITR Identifier | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Nonce . . . | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | . . . Nonce | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Key ID | Authentication Data Length | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 ~ Authentication Data ~ 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Expiry Timer | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Length | | 288 +-+-+-+-+-+-+-+-+ : 289 : Filter : 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 ... 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Length | | 294 +-+-+-+-+-+-+-+-+ : 295 : Filter : 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 | Redirect Map-Resolver | 299 | IP Address (128 bits) | 300 | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 2: Map-Subscribe-Ack Message Format 305 The description of the fields is as follows: 307 o Type is to be defined. The same code is used for both Map- 308 Subscribe and Map-Subscribe-Ack. 310 o A (Ack-bit): this bit MUST be set to 1 for Map-Subscribe-Ack 311 responses. 313 o U (unsolicited-map-reply bit): When set, this flag indicates that 314 the Map-Resolver can issue implicit Map-Reply messages. 316 o B (bulk-support bit): When set, this flag indicates that the Map- 317 Resolver supports mapping bulk retrieval method (e.g., 318 [I-D.boucadair-lisp-bulk]). 320 o I (immediate-retrieval bit): When set, this flag indicates that 321 the Map-Resolver will initiate an immediate push cycle of the 322 portion of the mapping table that matches the filters included in 323 the request. 325 o R (Redirect bit): When set, this flag indicates that a redirect 326 Map-Resolver is enclosed in the message. 328 o Reserved: reserved bits, MUST be set to 0 and MUST be ignored when 329 received. 331 o Result: indicates the result code of the processing of the Map- 332 Subscribe request. The following codes are defined: 334 0: SUCCESS. This code is used to indicate the request is 335 successfully processed. 337 1: PARTIAL-FILTERS-INSTALLED-LIMIT. This code is used to indicate 338 a request is successfully processed but some filters were not 339 installed because the number of filters carried in the initial 340 Map-Subscribe message exceeds the filter limit. 342 2: PARTIAL-FILTERS-INSTALLED-BAD. This code is used to indicate a 343 request is successfully processed but some filters were not 344 installed because they were malformed. 346 3: PARTIAL-FILTERS-INSTALLED-LOCAL. This code is used to indicate 347 a request is successfully processed but some filters were not 348 installed because of local reasons. The ITR SHOULD, after a 349 certain timer expires, send a Map-Subscribe request message for 350 the set of filters that are not included in the Map-Subscribe- 351 Ack message received by the ITR in response to its initial Map- 352 Subscribe request message. 354 4: FILTERS-PROHIBITED. This code is used to indicate a request is 355 successfully processed but the installation of filters is 356 prohibited. 358 o Filter Count: This field indicates the number of the filters 359 included in the message. 361 o Nonce, Key ID, Authentication Data Length, and Authentication Data 362 are similar to those of a LISP Map-Register message ([RFC6830]). 364 o Expiry Timer: This field indicates, in seconds, the validity timer 365 for the subscription. 367 o Length: This field indicates, in octets, the length of the filter 368 that is encoded in the "Filter" field. 370 o Filter: This field carries the set of filters that were 371 successfully installed. 373 o Redirect Map-Resolver IP Address (128 bits): When the R-bit is 374 set, this field carries the IP address of the Map-Resolver where 375 mapping requests should be redirected. An IPv4 address is encoded 376 as an IPv4-mapped IPv6 address. 378 4. Generating a Map-Subscribe Message 380 The A-bit of a Map-Subscribe message MUST be set to 0. 382 An ITR uses the U-bit to inform a Map-Resolver whether it is ready to 383 handle unsolicited Map-Reply messages or not. The ITR MUST set the 384 U-bit when it supports such capability. 386 An ITR uses the B-bit to inform a Map-Resolver whether it supports 387 the mapping bulk transfer method or not. The ITR MUST set to the 388 B-bit when it supports such method (e.g., [I-D.boucadair-lisp-bulk]). 390 An ITR that joins the LISP network is likely to delete all 391 notifications that are bound to its RLOCs. It does so by including a 392 Null filter prior to any filter that it wishes the Map-Resolver to 393 record. Note, an ITR can indicate a Null filter using one of these 394 methods: 396 1. Send a Map-Subscribe message with a "Filter Count" set to 0, or 398 2. Include a Filter with a 'Filter" field set to zeros. 400 An ITR that loses its mapping cache for some reason SHOULD generate a 401 Map-Subscribe message towards its Map-Resolver(s) with the I-bit set. 403 An ITR MAY generate several Map-Subscribe messages to make the Map- 404 Resolver install the required filters. Nevertheless, an ITR MUST 405 expect that the Map-Resolver may limit the number of filters that may 406 be installed. Filters that are not accepted or not processed by the 407 Map-Resolvers are not included in a Map-Subscribe-Ack message. 409 An ITR that wants to delete one or a set of filters MUST generate a 410 Map-Subscribe message which carries those filters with an Expiry 411 Timer set to 0. 413 5. Processing a Map-Subscribe Message 415 A Map-Resolver that does not support the Map-Subscribe message MUST 416 silently ignore any Map-Subscribe message it receives. 418 Map-Resolvers MUST support a configurable parameter to enable/disable 419 the processing of Map-Subscribe messages. The default value is set 420 to "enabled". 422 A Map-Resolver SHOULD support a configuration parameter to limit the 423 number of filters per leaf LISP network, per ITR, etc. 425 If a Map-Resolver receives a Map-Subscribe message and is enabled to 426 process it, a Map-Resolver MUST reply with a Map-Subscribe-Ack 427 message to acknowledge the receipt of the corresponding Map-Subscribe 428 message. 430 When building a Map-Subscribe-Ack message, the Map-Resolver MUST: 432 o Set the A-bit to indicate this is a response to a Map-Subscribe 433 request. 435 o Set the U-bit if it supports the unsolicited Map-Reply capability, 436 except if a redirect Map-Resolver is to be returned. 438 o Set the B-bit if it supports a method for mapping bulk transfer, 439 except if a redirect Map-Resolver is to be returned. 441 o Set the R-bit if it wants to inform the requesting ITR about 442 another Map-Resolver it should contact. The Map-Resolver MAY 443 return a set of filters that are to be applied by the ITR to 444 select the Map-Resolver (i.e., destination EID Map-Resolver 445 address selection). 447 o Echo the I-bit if the Map-Resolver accepts to initiate unsolicited 448 mapping retrievals, except if a redirect Map-Resolver is to be 449 returned. 451 o If no redirect is enabled and the request includes one or several 452 filters, the Map-Resolver MUST echo the filters it succeeds to 453 install, and in the same order of appearance, in the Map- 454 Subscribe-Ack message. 456 o If the Map-Resolver is configured with maximum and minimum values 457 for the expiry timer, the Map-Resolver MUST adjust the Expiry 458 Timer enclosed in the request so that it does not exceed these 459 boundary values. 461 If the I-bit is set in the Map-Subscribe request and the Map-Resolver 462 supports the unsolicited mapping retrieval capability, the Map- 463 Resolver SHOULD generate unsolicited Map-Reply messages or dedicated 464 bulk transfer messages that carry the EID-RLOC mapping entries that 465 match the filters already present in the Mapping System for that ITR 466 or that match those carried by the Map-Subscribe message. 468 If filters are included in the request, the Map-Resolver MUST extract 469 those filters and update its mapping system subscription for that ITR 470 accordingly. In particular, the Map-Resolver MUST delete all filters 471 that are active for that ITR if a Null filter is included in the Map- 472 Subscribe request or if the expiry timer is null. 474 If filters are not allowed for a given ITR, the 'Result' field MUST 475 be set to FILTERS-PROHIBITED. 477 If all filters are successfully installed, the 'Result' field MUST be 478 set to SUCCESS. 480 If the Map-Resolver fails to install some of the filters included in 481 a request because the filter limits for that ITR are exceeded, it 482 MUST NOT echo the corresponding filters in the Map-Subscribe-Ack 483 message. The 'Result' field MUST be set to PARTIAL-FILTERS- 484 INSTALLED-LIMIT. 486 If the Map-Resolver fails to install some of the filters included in 487 a request because these filters were malformed, it MUST NOT echo the 488 corresponding filters in the Map-Subscribe-Ack message; only 489 successfully installed filters MUST be included. The 'Result' field 490 MUST be set to PARTIAL-FILTERS-INSTALLED-BAD. 492 If, for some other reasons, the Map-Resolver fails to apply the 493 filters included in a request, it MUST NOT echo the said filters in 494 the Map-Subscribe-Ack message; only the successfully installed 495 filters MUST be included. The 'Result' field MUST be set to PARTIAL- 496 FILTERS-INSTALLED-LOCAL. 498 If a filter that is included in the request is more specific than a 499 filter that is already present in the mapping system for the same 500 ITR, the Map-Resolver MUST NOT add a new filter but MUST include the 501 old filter in the response to the requesting ITR. 503 If a more specific filter exists in the mapping system for the same 504 ITR, the Map-Resolver MUST replace the old filter (i.e., the one 505 already stored in the system) with the new filter (i.e., the one 506 included in the Map-Subscribe message). 508 An ITR can replace an existing filter by a more specific one by 509 deleting all filters and install the new ones. 511 A Map-Resolver that is overloaded or configured by means of a 512 specific policy to redirect requests sent by a set of ITRs to other 513 Map-Resolvers, the Map-Resolver MUST reply with a Map-Subscribe-Ack 514 message with the R-bit set and 'Redirect Map-Resolver IP Address' 515 field set to the redirect Map-Resolver'address. All other bit flags 516 MUST be returned unset. Moreover, the Expiry Timer MUST be set to 0. 517 No Filter MUST be included in the message. 519 If an event matches one of the filters that have been installed by an 520 ITR, the Map-Resolvers MUST generate the corresponding unsolicited 521 mapping update message (e.g., Map-Reply, mapping bulk method). 523 Upon expiry of the validity timer associated with a filter, the Map- 524 Resolver MUST delete that filter from its mapping subscription 525 system. 527 6. Processing a Map-Subscribe-Ack Message 529 Upon receipt of a Map-Subscribe-Ack message, the ITR MUST check 530 whether the message matches a Map-Subscribe message it sent to the 531 same Map-Resolver. If no matching state is found, the message MUST 532 be silently dropped. If a state is found, in addition to 533 authentication checks, the ITR MUST proceed as follows: 535 o If the U-bit is set, it should expect that unsolicited Map-Reply 536 messages will be received from this Map-Resolver. Appropriate 537 security mechanisms (e.g., Access Control Lists) SHOULD be 538 activated to allow the processing of these incoming unsolicited 539 Map-Reply messages. 541 o If the B-bit is set, it should expect that (unsolicited) mapping 542 bulk transfer messages are supported by this Map-Resolver. 543 Appropriate security mechanisms (e.g., Access Control Lists) 544 SHOULD be activated to allow the processing of these incoming 545 unsolicited bulk transfer messages. 547 o If the R-bit is set and the 'Redirect Map-Resolver IP Address' 548 field embeds a valid IP address, the ITR MUST update its Map- 549 Resolver contact information with the new Map-Resolver's IP 550 address. The ITR MUST use that IP address for subsequent 551 exchanges. Optionally, if filters were included in the reply sent 552 by the Map-Resolver, these filters are used for the destination 553 EID Map-Resolver address selection. 555 o If the message includes one or several filters, the ITR MUST check 556 whether the same set of filters as those included in the Map- 557 Subscribe request are carried in the Map-Subscribe-Ack message. 558 Filters that are not returned in the Map-Subscribe-Ack message may 559 not be valid or have exceeded a limit. The "Result" code 560 indicates the reason for not installing these filters. In 561 particular: 563 * An ITR that receives the result code set to PARTIAL-FILTERS- 564 INSTALLED-LIMIT MUST NOT try to install new filters unless it 565 clears all the filters maintained by the Map-Resolver or it 566 removes some of them. 568 * An ITR that receives the result code set to PARTIAL-FILTERS- 569 INSTALLED-BAD MUST NOT resend the same filters that were not 570 returned in the Map-Subscribe-Ack message, in subsequent Map- 571 Subscribe requests. 573 * An ITR that receives the result code set to FILTERS-PROHIBITED 574 MUST NOT include the filters that were not returned in the Map- 575 Subscribe-Ack message, in a Map-Subscribe message sent to that 576 Map-Resolver. 578 * An ITR that receives the result code set to PARTIAL-FILTERS- 579 INSTALLED-LOCAL SHOULD wait for at least 60 seconds before 580 issuing another Map-Subscribe message to install the filters 581 that were not returned in the Map-Subscribe-Ack message. 583 o The ITR MUST adjust the Expiry Timer carried in the Map-Subscribe- 584 Ack. Subscription should be renewed before the expiry of that 585 timer. 587 7. Subscription to Multiple Resolvers 589 In order to subscribe to multiple Map-Resolvers, an ITR sends Map- 590 Subscribe messages to a list of Map-Resolvers. Each of these 591 requests is handled as specified in Section 4. 593 8. Sample Examples 595 This section includes a set of examples to illustrate the usage of 596 the methods defined in Section 2. 598 8.1. Map-Resolver Redirect 600 The example shown in Figure 3, illustrates an example of an ITR 601 (ITR1) that is redirected to another Map-Resolver (MR2). 603 +--------+ +--------+ +--------+ 604 | ITR1 | | MR1 | | MR2 | 605 +--------+ +--------+ +--------+ 606 | | | 607 |Map-Subscribe | | 608 |-------------------------->| | 609 | Map-Subscribe-Ack (R, MR2)| | 610 |<--------------------------| | 611 |Map-Subscribe | | 612 |------------------------------------->| 613 | Map-Subscribe-Ack| 614 |<-------------------------------------| 615 | | 616 |Map-Request | 617 |------------------------------------->| 618 | Map-Reply| 619 |<-------------------------------------| 621 Figure 3: Example of Map-Resolver Redirection 623 8.2. Mapping Cache Retrieval 625 The examples shown in Figure 4 and Figure 5, illustrate examples of 626 an ITR (ITR1) that restores its mapping tables upon reboot according 627 to the filters already present in the mapping system. 629 The example in Figure 4, indicates how an ITR retrieves the mappings 630 that match the filters included in the Map-Subscribe request using 631 distinct Map-Reply messages. 633 The example in Figure 5, assumes that multiple records bound to 634 distinct EIDs are included in the same Map-Reply message. 636 This procedure applies to ITRs which do not store the mapping table 637 in a permanent memory storage facility. 639 Owing to this procedure, the ITR is ready-to-serve as soon as reboot 640 is completed or right after a mapping cache clear event. 642 +--------+ +--------+ 643 | ITR1 | | MR | 644 +--------+ +--------+ 645 | | 646 | | 647 |Map-Subscribe(d_EID, d_EID2,| 648 |..., d_EIDn) | 649 |--------------------------->| 650 | Map-Subscribe-Ack (d_EID,| 651 | d_EID2, ..., d_EIDn)| 652 |<---------------------------| 653 | | 654 <> 655 |Map-Subscribe(I) | 656 |--------------------------->| 657 | Map-Subscribe-Ack (I)| 658 |<---------------------------| 659 | Map-Reply (d_EID)| 660 |<---------------------------| 661 | Map-Reply (d_EID2)| 662 |<---------------------------| 663 .... 664 | Map-Reply (d_EIDn)| 665 |<---------------------------| 667 Figure 4: Example of Mapping Cache Retrieval: Matching the Filters 668 Installed in the Mapping System 670 +--------+ +--------+ 671 | ITR1 | | MR | 672 +--------+ +--------+ 673 | | 674 | | 675 |Map-Subscribe(d_EID, d_EID2,| 676 |..., d_EIDn) | 677 |--------------------------->| 678 | Map-Subscribe-Ack (d_EID,| 679 | d_EID2, ..., d_EIDn)| 680 |<---------------------------| 681 | | 682 <> 683 |Map-Subscribe(I) | 684 |--------------------------->| 685 | Map-Subscribe-Ack (I)| 686 |<---------------------------| 687 | Map-Reply (d_EID, d_EID2, 688 | ..., )| 689 |<---------------------------| 691 Figure 5: Example of Bulk Mapping Cache Retrieval: Matching the 692 Filters Installed in the Mapping System 694 8.3. Unsolicited Map-Reply 696 The example shown in Figure 6, illustrates an ITR (ITR1) that is 697 notified with the new EID-RLOC mapping that it subscribed to. 699 +--------+ +--------+ +--------+ 700 | ITR1 | | MR | | ETR | 701 +--------+ +--------+ +--------+ 702 | | | 703 | | | 704 |Map-Subscribe | | 705 |--------------------------->| | 706 | Map-Subscribe-Ack (d_EID)| | 707 |<---------------------------| | 708 | | | 709 | Map-Reply (d_EID)| | 710 |<---------------------------| | 711 .... 712 src=s_EID| | 713 -------->|src=RLOC_itr1 dst=RLOC_etr|src=s_EID 714 dst=d_EID|==============Encapsulated Packet==========>|--------> 715 | |dst=d_EID 716 .... 718 Figure 6: Example of Unsolicited Map-Reply 720 9. Security Considerations 722 This document does not introduce any additional security issues other 723 than those discussed in [RFC6830] and [RFC6833]. 725 10. IANA Considerations 727 This document requests IANA to assign a new code from the LISP Packet 728 Types registry ([I-D.ietf-lisp-type-iana]): 730 Message Code Reference 731 ================================= ==== =============== 732 Map-Subscribe/Map-Subscribe-Ack TBD [This document] 734 11. Acknowledgments 736 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR-009. 738 Many thanks to Stefano Secci and Chi-Dung Phung for their review. 740 12. References 741 12.1. Normative references 743 [I-D.ietf-lisp-type-iana] 744 Boucadair, M. and C. Jacquenet, "LISP Shared Extension 745 Message & IANA Registry for LISP Packet Type Allocations", 746 draft-ietf-lisp-type-iana-06 (work in progress), February 747 2017. 749 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 750 Requirement Levels", BCP 14, RFC 2119, 751 DOI 10.17487/RFC2119, March 1997, 752 . 754 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 755 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 756 2006, . 758 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 759 Locator/ID Separation Protocol (LISP)", RFC 6830, 760 DOI 10.17487/RFC6830, January 2013, 761 . 763 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 764 Protocol (LISP) Map-Server Interface", RFC 6833, 765 DOI 10.17487/RFC6833, January 2013, 766 . 768 12.2. Informative references 770 [I-D.boucadair-lisp-bulk] 771 Boucadair, M. and C. Jacquenet, "LISP Mapping Bulk 772 Retrieval", draft-boucadair-lisp-bulk-03 (work in 773 progress), July 2016. 775 Authors' Addresses 777 Mohamed Boucadair 778 Orange 779 Rennes 35000 780 France 782 EMail: mohamed.boucadair@orange.com 783 Christian Jacquenet 784 Orange 785 Rennes 35000 786 France 788 EMail: christian.jacquenet@orange.com