idnits 2.17.1 draft-ietf-lisp-pubsub-01.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 (October 4, 2018) is 2031 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-17 Summary: 0 errors (**), 0 flaws (~~), 2 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 V. Ermagan 4 Intended status: Experimental J. Leong 5 Expires: April 7, 2019 F. Maino 6 Cisco Systems 7 A. Cabellos-Aparicio 8 Technical University of Catalonia 9 S. Barkai 10 Fermi Serverless 11 D. Farinacci 12 lispers.net 13 M. Boucadair 14 C. Jacquenet 15 Orange 16 S. Secci 17 LIP6 UPMC 18 October 4, 2018 20 Publish/Subscribe Functionality for LISP 21 draft-ietf-lisp-pubsub-01 23 Abstract 25 This document specifies an extension to the use of Map-Request to 26 enable Publish/Subscribe (PubSub) operation for LISP. 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 https://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 April 7, 2019. 45 Copyright Notice 47 Copyright (c) 2018 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 (https://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 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 64 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 65 4. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 4 66 5. Map-Request Additions . . . . . . . . . . . . . . . . . . . . 4 67 6. Mapping Request Subscribe Procedures . . . . . . . . . . . . 6 68 7. Mapping Notification Publish Procedures . . . . . . . . . . . 8 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6833bis] 78 splits current IP addresses in two different namespaces, Endpoint 79 Identifiers (EIDs) and Routing Locators (RLOCs). LISP uses a map- 80 and-encap approach that relies on (1) a Mapping System (basically a 81 distributed database) that stores and disseminates EID-RLOC mappings 82 and on (2) LISP tunnel routers (xTRs) that encapsulate and 83 decapsulate data packets based on the content of those mappings. 85 ITRs/RTRs/PITRs pull EID-to-RLOC mapping information from the Mapping 86 System by means of an explicit request message. 87 [I-D.ietf-lisp-rfc6833bis] indicates how ETRs can tell ITRs/RTRs/ 88 PITRs about mapping changes. This document presents a Publish/ 89 Subscribe (PubSub) extension in which the Mapping System can notify 90 ITRs/RTRs/PITRs about mapping changes. When this mechanism is used, 91 mapping changes can be notified faster and can be managed in the 92 Mapping System versus the LISP sites. 94 In general, when an ITR/RTR/PITR wants to be notified for mapping 95 changes for a given EID-prefix, the following steps occur: 97 (1) The ITR/RTR/PITR sends a Map-Request for that EID-prefix. 99 (2) The ITR/RTR/PITR sets the Notification-Requested bit (N-bit) on 100 the Map-Request and includes its xTR-ID and Site-ID. 102 (3) The Map-Request is forwarded to one of the Map-Servers that the 103 EID-prefix is registered to. 105 (4) The Map-Server creates subscription state for the ITR/RTR/PITR 106 on the EID-prefix. 108 (5) The Map-Server sends a Map-Notify to the ITR/RTR/PITR to 109 acknowledge the successful subscription. 111 (6) When there is an RLOC-set change for the EID-prefix, the Map- 112 Server sends a Map-Notify message to each ITR/RTR/PITR in the 113 subscription list. 115 (7) Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the 116 received Map-Notify. 118 This operation is repeated for all EID-prefixes for which ITR/RTR/ 119 PITR want to be notified. The ITR/RTR/PITR can set the N-bit for 120 several EID-prefixes within a single Map-Request. 122 2. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 3. Definition of Terms 130 LISP xTR-ID: A 128-bit field that is used as a unique identifier 131 for an xTR. The xTR-ID is especially useful for identifying 132 multiple xTRs serving the same site/EID-prefix. A value of all 133 zeros indicate the xTR-ID is unspecified. 135 LISP Site-ID: A 64-bit field that is used as a unique identifier 136 of a group of xTRs belonging to the same site. A value of 0 137 indicate the Site-ID is unspecified. 139 4. Deployment Assumptions 141 The specification described in this document makes the following 142 deployment assumptions: 144 (1) A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is 145 assigned to each xTR. 147 (2) Map-Servers are configured in proxy-reply mode, i.e., they are 148 solicited to generate and send Map-Reply messages for the 149 mappings they are serving. 151 (3) There can be either a soft-state or hard-state security 152 association between the xTRs and the Map-Servers. 154 The distribution of xTR-IDs (and Site-IDs) and the management of 155 security associations are out of the scope of this document. 157 5. Map-Request Additions 159 Figure 1 shows the format of the updated Map-Request 160 [I-D.ietf-lisp-rfc6833bis] to support the PubSub functionality. 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 |Type=1 |A|M|P|S|p|s|R|I| Reserved | IRC | Record Count | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Nonce . . . | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | . . . Nonce | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Source-EID-AFI | Source EID Address ... | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | ... | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 / |N| Reserved | EID mask-len | EID-Prefix-AFI | 180 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 \ | EID-Prefix ... | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Map-Reply Record ... | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | | 186 + + 187 | | 188 + xTR-ID + 189 | | 190 + + 191 | | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | | 194 + Site-ID + 195 | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 1: Map-Request with I-bit, N-bit, xTR-ID and Site-ID 200 The following is added to the Map-Request message defined in 201 [I-D.ietf-lisp-rfc6833bis]: 203 xTR-ID bit (I-bit): The I-bit of a Map-Request message is set to 1 204 to indicate that a 128 bit xTR-ID and a 64 bit Site-ID fields are 205 present at the end of the Map-Request message. If an xTR is 206 configured with an xTR-ID or Site-ID, it MUST set the I bit to 1 207 and include its xTR-ID and Site-ID in the Map-Request messages it 208 generates. If either the xTR-ID or Site-ID is not configured an 209 unspecified value is encoded for whichever ID that is not 210 configured. 212 Notification-Requested bit (N-bit): The N-bit of an EID-record is 213 set to 1 to specify that the xTR wants to be notified of updates 214 for that mapping record. 216 xTR-ID field: xTR-ID is a 128 bit field at the end of the Map- 217 Request message, starting after the final Record in the message 218 (or the Map-Reply Record, if present). The xTR-ID is used to 219 uniquely identify the sender of a Map-Request message, especially 220 in the case where a site has more than one xTR. A value of all 221 zeros indicate that an xTR-ID is not specified, though encoded in 222 the message. This is useful in the case where a Site-ID is 223 specified, but no xTR-ID is configured. 225 Site-ID field: Site-ID is a 64 bit field at the end of the Map- 226 Request message, following the xTR-ID. Site-ID is used by the 227 Map-Server receiving the Map-Request message to identify which 228 xTRs belong to the same site. A value of 0 indicate that a Site- 229 ID is not specified, though encoded in the message. 231 6. Mapping Request Subscribe Procedures 233 The xTR subscribes for RLOC-set changes for a given EID-prefix by 234 sending a Map-Request to the Mapping System with the N-bit set on the 235 EID-Record. The xTR builds a Map-Request according to 236 [I-D.ietf-lisp-rfc6833bis] but also does the following: 238 (1) The xTR MUST set the I-bit of the Map-Request message to 1 and 239 append its xTR-ID and Site-ID to the Map-Request. The xTR-ID 240 uniquely identifies the xTR. 242 (2) The xTR MUST set the N-bit to 1 for each EID-Record to which the 243 xTR wants to subscribe. 245 The Map-Request is forwarded to the appropriate Map-Server through 246 the Mapping System. This document does not assume that a Map-Server 247 is pre-assigned to handle the subscription state for a given xTR. 248 The Map-Server that receives the Map-Request will be the Map-Server 249 responsible to notify that specific xTR about future mapping changes 250 for the subscribed mapping records. 252 Upon reception of the Map-Request, the Map-Server processes it as 253 described in [I-D.ietf-lisp-rfc6833bis]. Upon processing, for each 254 EID-Record that has the N-bit set to 1, the Map-Server proceeds 255 adding the xTR-ID contained in the Map-Request to the list of xTR 256 that have requested to be subscribed to that mapping record. 258 If the xTR-ID is added to the list, the Map-Server MUST send a Map- 259 Notify message back to the xTR to acknowledge the successful 260 subscription. The Map-Server MUST follow the specification in 261 Section 6.1.7 of [I-D.ietf-lisp-rfc6833bis] to build the Map-Notify 262 with the following considerations. 264 (1) The Map-Server MUST use the nonce from the Map-Request as the 265 nonce for the Map-Notify. 267 (2) The Map-Server MUST use its security association with the xTR 268 (see Section 4) to compute the authentication data of the Map- 269 Notify. 271 (3) The Map-Server MUST send the Map-Notify to one of the ITR-RLOCs 272 received in the Map-Request. 274 When the xTR receives a Map-Notify with a nonce that matches one in 275 the list of outstanding Map-Request messages sent with an N-bit set, 276 it knows that the Map-Notify is to acknowledge a successful 277 subscription. The xTR processes this Map-Notify as described in 278 [I-D.ietf-lisp-rfc6833bis] with the following considerations. The 279 xTR MUST use its security association with the Map-Server (see 280 Section 4) to validate the authentication data on the Map-Notify. 281 The xTR MUST use the Map-Notify to populate its map-cache with the 282 returned EID-prefix and RLOC-set. 284 The subscription of an xTR-ID to the list of subscribers for the EID- 285 Record may fail for a number of reasons. For example, because of 286 local configuration policies (such as white/black lists of 287 subscribers), or because the Map-Server has exhausted the resources 288 to dedicate to the subscription of that EID-Record (e.g., the number 289 of subscribers excess the capacity of the Map-Server). 291 If the subscription fails, the Map-Server MUST send a Map-Reply to 292 the originator of the Map-Request, as described in 293 [I-D.ietf-lisp-rfc6833bis]. This is also the case when the Map- 294 Server does not support PubSub operation. The xTR processes the Map- 295 Reply as specified in [I-D.ietf-lisp-rfc6833bis]. 297 If an xTR-ID is successfully added to the list of subscribers for an 298 EID-Record, the Map-Server MUST extract the ITR-RLOCs present in the 299 Map-Request, and store the association between the xTR-ID and those 300 RLOCs. Any already present state regarding ITR-RLOCs for the same 301 xTR-ID MUST be overwritten. 303 If the Map-Request only has one ITR-RLOC with AFI = 0 (i.e. Unknown 304 Address), the Map-Server MUST remove the subscription state for that 305 xTR-ID. In this case, the Map-Server MUST send the Map-Notify to the 306 source RLOC of the Map-Request. When the TTL for the EID-record 307 expires, the EID-prefix is removed from the Map-Server's subscription 308 cache. On EID-Record removal, the Map-Server notifies the 309 subscribers via a Map-Notify with TTL equal 0. 311 7. Mapping Notification Publish Procedures 313 The publish procedure is implemented via Map-Notify messages that the 314 Map-Server sends to xTRs. The xTRs acknowledge the reception of Map- 315 Notifies via sending Map-Notify-Ack messages back to the Map-Server. 316 The complete mechanism works as follows. 318 When a mapping stored in a Map-Server is updated (e.g. via a Map- 319 Register from an ETR), the Map-Server MUST notify the subscribers of 320 that mapping via sending Map-Notify messages with the most updated 321 mapping information. The Map-Notify message sent to each of the 322 subscribers as a result of an update event MUST follow the exact 323 encoding and logic defined in [I-D.ietf-lisp-rfc6833bis] for Map- 324 Notify, except for the following: 326 (1) The Map-Notify MUST be sent to one of the ITR-RLOCs associated 327 with the xTR-ID of the subscriber. 329 (2) The nonce of the Map-Notify MUST be the one the subscriber sent 330 in the Map-Request. If the subscriber sent no Map-Request (e.g. 331 was subscribed via configuration at the Map-Server) the nonce 332 MUST be randomly generated by the Map-Server. 334 (3) The Map-Server MUST use its security association with the xTR to 335 compute the authentication data of the Map-Notify. 337 When the xTR receives a Map-Notify with a nonce sent previously in a 338 Map-Request, or with a nonce not present in any list of previously 339 sent nonces but with an EID not local to the xTR, the xTR knows that 340 the Map-Notify has been received to update an entry on its map-cache. 341 Processing of unsolicited Map-Notify messages MUST be explicitly 342 enabled via configuration at the xTR. 344 The xTR processes the received Map-Notify as specified in 345 [I-D.ietf-lisp-rfc6833bis], with the following considerations. The 346 xTR MUST use its security association with the Map-Server (see 347 Section 4) to validate the authentication data on the Map-Notify. 348 The xTR MUST use the mapping information carried in the Map-Notify to 349 update its internal map-cache. The xTR MUST acknowledge the Map- 350 Notify by sending back a Map-Notify-Ack (specified in 351 [I-D.ietf-lisp-rfc6833bis]), with the nonce from the Map-Notify, to 352 the Map-Server. If after a configurable timeout, the Map-Server has 353 not received back the Map-Notify-Ack, it CAN try to send the Map- 354 Notify to a different ITR-RLOC for that xTR-ID. 356 8. Security Considerations 358 The way to provide a security association between the ITRs and the 359 Map-Servers must be evaluated according to the size of the 360 deployment. For small deployments, it is possible to have a shared 361 key (or set of keys) between the ITRs and the Map-Servers. For 362 larger and Internet-scale deployments, scalability is a concern and 363 further study is needed. 365 9. Acknowledgments 367 This work is partly funded by the ANR LISP-Lab project #ANR- 368 13-INFR-009 (https://lisplab.lip6.fr). 370 10. IANA Considerations 372 This document is requesting bit allocations in the Map-Request 373 message. The registry is introduced in [I-D.ietf-lisp-rfc6833bis] 374 and named "LISP Control Plane Header Bits". This document is adding 375 bits to the sub-registry "Map-Request Header Bits". 377 Sub-Registry: Map-Request Header Bits: 379 0 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 |Type=1 |A|M|P|S|p|s|R|I| Rsvd |L|D| IRC | Record Count | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 ~ ... Nonce, Source EID and ITR RLOCs ... ~ 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 |N| Reserved | EID mask-len | EID-Prefix-AFI | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 +----------+---------------+-------------+--------------------------+ 390 | Spec | IANA Name | Bit | Description | 391 | Name | | Position | | 392 +----------+---------------+-------------+--------------------------+ 393 | I | map-request-I | 11 | xTR-ID Bit | 394 | N | map-request-N | ... + 0 | Notification-Requested | 395 | | | | Bit | 396 +----------+---------------+-------------+--------------------------+ 398 LISP Map-Request Header Bits 400 11. Normative References 402 [I-D.ietf-lisp-rfc6833bis] 403 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 404 "Locator/ID Separation Protocol (LISP) Control-Plane", 405 draft-ietf-lisp-rfc6833bis-17 (work in progress), October 406 2018. 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, 410 DOI 10.17487/RFC2119, March 1997, 411 . 413 Authors' Addresses 415 Alberto Rodriguez-Natal 416 Cisco Systems 417 170 Tasman Drive 418 San Jose, CA 419 USA 421 Email: natal@cisco.com 423 Vina Ermagan 424 Cisco Systems 425 170 Tasman Drive 426 San Jose, CA 427 USA 429 Email: vermagan@cisco.com 431 Johnson Leong 432 Cisco Systems 433 170 Tasman Drive 434 San Jose, CA 435 USA 437 Email: joleong@cisco.com 438 Fabio Maino 439 Cisco Systems 440 170 Tasman Drive 441 San Jose, CA 442 USA 444 Email: fmaino@cisco.com 446 Albert Cabellos-Aparicio 447 Technical University of Catalonia 448 Barcelona 449 Spain 451 Email: acabello@ac.upc.edu 453 Sharon Barkai 454 Fermi Serverless 455 CA 456 USA 458 Email: sharon@fermicloud.io 460 Dino Farinacci 461 lispers.net 462 San Jose, CA 463 USA 465 Email: farinacci@gmail.com 467 Mohamed Boucadair 468 Orange 469 Rennes 35000 470 France 472 Email: mohamed.boucadair@orange.com 474 Christian Jacquenet 475 Orange 476 Rennes 35000 477 France 479 Email: christian.jacquenet@orange.com 480 Stefano Secci 481 LIP6 UPMC 482 France 484 Email: stefano.secci@lip6.fr