idnits 2.17.1 draft-rodrigueznatal-lisp-pubsub-00.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 (August 2, 2017) is 2459 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-05 ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 1 error (**), 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: February 3, 2018 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 August 2, 2017 15 Publish-Subscribe mechanism for LISP 16 draft-rodrigueznatal-lisp-pubsub-00 18 Abstract 20 This document describes simple extensions to the use of Map-Request 21 to enable Publish/Subscribe (PubSub) operation for LISP. 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 http://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 February 3, 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 (http://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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 3 60 4. Map-Request Additions . . . . . . . . . . . . . . . . . . . . 4 61 5. Mapping Request Subscribe Procedures . . . . . . . . . . . . 5 62 6. Mapping Notification Publish Procedures . . . . . . . . . . . 6 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 10. Normative References . . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 The Locator/ID Separation Protocol (LISP) [RFC6830] splits current IP 72 addresses in two different namespaces, Endpoint Identifiers (EIDs) 73 and Routing Locators (RLOCs). LISP uses a map-and-encap approach 74 that relies on a Mapping System (basically a distributed database) 75 that stores and disseminates EID-RLOC mappings and on LISP tunnel 76 routers (xTRs) that encapsulate and decapsulate packets based on 77 those mappings. 79 ITRs/RTRs/PITRs pull EID-to-RLOC mapping information from the Mapping 80 System by means of explicitly requesting mappings. [RFC6830] 81 indicates how ETRs can tell ITRs/RTRs/PITRs about mapping changes. 82 This document presents a Publish/Subscribe (PubSub) architecture in 83 which the Mapping System can notify ITRs/RTRs/PITRs about mapping 84 changes. When this mechanism is used, mapping changes can be 85 notified faster and can be managed in the Mapping System versus the 86 LISP sites. 88 In general, when an ITR/RTR/PITR wants to be notified for mapping 89 changes, the following flow occurs: 91 (1) The ITR/RTR/PITR sends a Map-Request for the EID-prefix. 93 (2) The ITR/RTR/PITR sets the subscribe bit on the Map-Request and 94 includes its xTR-ID. 96 (3) The Map-Request flows to one of the Map-Servers that the EID- 97 prefix is registered to. 99 (4) The Map-Server creates subscription state for the ITR/RTR/PITR 100 on the EID-prefix. 102 (5) The Map-Server sends a Map-Notify to the ITR/RTR/PITR to 103 acknowledge the successful subscription. 105 (6) When there is an RLOC-set change for the EID-prefix, the Map- 106 Server sends a Map-Notify message to each ITR/RTR/PITR in the 107 subscription list. 109 (7) Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the 110 received Map-Notify. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. Deployment Assumptions 120 The specification described in this document makes the following 121 deployment assumptions: 123 (1) A unique 128-bit xTR-ID identifier is assigned to each xTR. 125 (2) Map-Servers are configured in proxy-reply mode i.e. they send 126 Map-Replies for the mappings they are serving. 128 (3) There can be either a soft-state or hard-state security 129 association between the xTRs and the Map-Servers. 131 The distribution of xTR-IDs and the management of security 132 associations are out of the scope of this document. 134 4. Map-Request Additions 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 |Type=1 |A|M|P|S|p|s|X| Reserved | IRC | Record Count | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Nonce . . . | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | . . . Nonce | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Source-EID-AFI | Source EID Address ... | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | ... | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 / |S| Reserved | EID mask-len | EID-Prefix-AFI | 154 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 \ | EID-Prefix ... | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Map-Reply Record ... | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | | 160 + + 161 | | 162 + xTR-ID + 163 | | 164 + + 165 | | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Map-Request with S bit and xTR-ID 170 The following fields are added to the Map-Request message defined in 171 [RFC6830]. 173 xTR-ID bit (X-bit): the first bit after the s bit in the Map- 174 Request header. The X-bit of a Map-Request message is set to 175 specify that a 128-bit xTR-ID field is appended to the end of the 176 Map-Request, immediately following the last EID-Record (or the 177 Map-Reply Record, if present). 179 xTR-ID field: The xTR-ID field uniquely identifies each xTR of a 180 given LISP deployment. Provisioning of unique xTR-IDs is out of 181 the scope of this document. 183 The following field is added to the EID-Record field of a Map-Request 184 message defined in [RFC6830]: 186 Subscribe bit (S-bit): the first bit in the EID-Record section of 187 a Map-Request message. The S-bit of an EID-record is set to 1 to 188 specify that the xTR wants to be notified of updates for that 189 mapping record. 191 5. Mapping Request Subscribe Procedures 193 The xTR subscribes for RLOC-set changes for a given EID-prefix by 194 sending a Map-Request to the Mapping System with the S-bit set on the 195 EID-Record. The xTR builds a Map-Request according to [RFC6830] but 196 also does the following: 198 (1) The xTR MUST set the S-bit to 1 in each EID-Record to which the 199 xTR wants to subscribe. 201 (2) The X-bit of the Map-Request message MUST be set to 1, to 202 specify the presence of an xTR-ID field that uniquely identifies 203 the xTR. 205 The Map-Request is routed to the appropriate Map-Server through the 206 Mapping System. No Map-Server is pre-assigned to handle the 207 subscription state for a given xTR. The Map-Server that receives the 208 Map-Request will be the Map-Server responsible to notify that 209 specific xTR about future mapping changes for the subscribed mapping 210 records. 212 Upon reception of the Map-Request, the Map-Server MUST process it as 213 described in [RFC6830]. After correct processing, for each EID- 214 Record that has the S-bit set to 1, the Map-Server MUST try to add 215 the xTR-ID contained in the Map-Request to the list of xTR that have 216 requested to be subscribed to that mapping record. 218 If the xTR-ID is added to the list, the Map-Server MUST send a Map- 219 Notify message back to the xTR to acknowledge the successful 220 subscription. The Map-Server MUST follow the specification on 221 [RFC6830] to build the Map-Notify with the following considerations. 222 The Map-Server MUST use the nonce from the Map-Request as the nonce 223 for the Map-Notify. The Map-Server MUST use its security association 224 with the xTR (see Section 3) to compute the authentication data of 225 the Map-Notify. The Map-Server MUST send the Map-Notify to one of 226 the ITR-RLOCs received in the Map-Request. 228 When the xTR receives a Map-Notify with a nonce that matches one in 229 the list of outstanding Map-Requests sent with a S-bit set, it knows 230 that the Map-Notify is to acknowledge a successful subscription. The 231 xTR processes this Map-Notify as described in [RFC6830] with the 232 following considerations. The xTR MUST use its security association 233 with the Map-Server (see Section 3) to validate the authentication 234 data on the Map-Notify. The xTR MUST use the Map-Notify to populate 235 its map-cache with the returned EID-prefix and RLOC-set. 237 The subscription of an xTR-ID to the list of subscribers for the EID- 238 Record may fail for a number of reasons. For example, because of 239 local configuration policies (e.g. white/black lists of subscribers), 240 or because the Map-Server has exhausted the resources to dedicate to 241 the subscription of that EID-Record (e.g. the number of subscribers 242 excess the capacity of the Map-Server). 244 If the subscription fails, the Map-Server MUST reply to the Map- 245 Request with a Map-Reply as described in [RFC6830]. This is also the 246 case when the Map-Server does not support PubSub operation. The xTR 247 processes the Map-Reply as specified in [RFC6830]. 249 If an xTR-ID is successfully added to the list of subscribers for an 250 EID-Record, the Map-Server MUST extract the ITR-RLOCs present in the 251 Map-Request, and store the association between the xTR-ID and those 252 RLOCs. Any already present state regarding ITR-RLOCs for the same 253 xTR-ID MUST be overwritten. 255 If the Map-Request only has one ITR-RLOC with AFI = 0 (i.e. Unknown 256 Address), the Map-Server MUST remove the subscription state for that 257 xTR-ID. In this case, the Map-Server MUST send the Map-Notify to the 258 source RLOC of the Map-Request. 260 6. Mapping Notification Publish Procedures 262 The publish procedure is implemented via Map-Notify messages that the 263 Map-Server sends to xTRs. The xTRs acknowledge the reception of Map- 264 Notifies via sending Map-Notify-Ack messages back to the Map-Server. 265 The complete mechanism works as follows. 267 When a mapping stored in a Map-Server is updated (e.g. via a Map- 268 Register from an ETR), the Map-Server MUST notify the subscribers of 269 that mapping via sending Map-Notify messages with the most updated 270 mapping information. The Map-Notify message sent to each of the 271 subscribers as a result of an update event MUST follow the exact 272 encoding and logic defined in [RFC6830] for Map-Notify, except for 273 the following. 275 (1) The Map-Notify MUST be sent to one of the ITR-RLOCs associated 276 with the xTR-ID of the subscriber. 278 (2) The nonce of the Map-Notify MUST be randomly generated by the 279 Map-Server. 281 (3) The Map-Server MUST use its security association with the xTR to 282 compute the authentication data of the Map-Notify. 284 When the xTR receives a Map-Notify with a nonce not present in any 285 list of previously sent nonces, and an EID not local to the xTR, the 286 xTR knows that the Map-Notify has been received due to an update on 287 the RLOC-set of a cached mapping. 289 The xTR processes the received Map-Notify as specified in [RFC6830], 290 with the following considerations. The xTR MUST use its security 291 association with the Map-Server (see Section 3) to validate the 292 authentication data on the Map-Notify. The xTR MUST use the mapping 293 information carried in the Map-Notify to update its internal map- 294 cache. The xTR MUST acknowledge the Map-Notify by sending back a 295 Map-Notify-Ack (specified in [I-D.ietf-lisp-rfc6833bis]), with the 296 nonce from the Map-Notify, to the Map-Server. If after a 297 configurable timeout, the Map-Server has not received back the Map- 298 Notify-Ack, it CAN try to send the Map-Notify to a different ITR-RLOC 299 for that xTR-ID. 301 7. Security Considerations 303 The way to provide a security association between the ITRs and the 304 Map-Servers must be evaluated according to the size of the 305 deployment. For small deployments, it is possible to have a shared 306 key (or set of keys) between the ITRs and the Map-Servers. For 307 larger and Internet-scale deployments, scalability is a concern and 308 further study is needed. 310 8. Acknowledgments 312 TBD. 314 9. IANA Considerations 316 This document makes no request to IANA. 318 10. Normative References 320 [I-D.ietf-lisp-rfc6833bis] 321 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 322 "Locator/ID Separation Protocol (LISP) Control-Plane", 323 draft-ietf-lisp-rfc6833bis-05 (work in progress), May 324 2017. 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 332 Locator/ID Separation Protocol (LISP)", RFC 6830, 333 DOI 10.17487/RFC6830, January 2013, 334 . 336 Authors' Addresses 338 Alberto Rodriguez-Natal 339 Cisco Systems 340 170 Tasman Drive 341 San Jose, CA 342 USA 344 Email: natal@cisco.com 346 Vina Ermagan 347 Cisco Systems 348 170 Tasman Drive 349 San Jose, CA 350 USA 352 Email: vermagan@cisco.com 354 Johnson Leong 355 Cisco Systems 356 170 Tasman Drive 357 San Jose, CA 358 USA 360 Email: joleong@cisco.com 362 Fabio Maino 363 Cisco Systems 364 170 Tasman Drive 365 San Jose, CA 366 USA 368 Email: fmaino@cisco.com 369 Albert Cabellos-Aparicio 370 Technical University of Catalonia 371 Barcelona 372 Spain 374 Email: acabello@ac.upc.edu 376 Sharon Barkai 377 Fermi Serverless 378 CA 379 USA 381 Email: sharon@fermicloud.io 383 Dino Farinacci 384 lispers.net 385 San Jose, CA 386 USA 388 Email: farinacci@gmail.com