idnits 2.17.1 draft-kouvelas-lisp-rloc-membership-02.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 (September 10, 2019) is 1683 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 655 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-25 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Leong 3 Internet-Draft D. Lewis 4 Intended status: Experimental G. Schudel 5 Expires: March 13, 2020 A. Smirnov 6 Cisco Systems 7 C. Cassar 8 Tesla 9 I. Kouvelas 10 Arista Networks Inc. 11 September 10, 2019 13 LISP RLOC Membership Distribution 14 draft-kouvelas-lisp-rloc-membership-02 16 Abstract 18 The Locator/ID Separation Protocol (LISP) operation is based on EID 19 to RLOC mappings that are exchanged through a mapping system. The 20 mapping system can use the RLOCs included in mapping registrations to 21 construct the complete set of RLOC addresses across all xTRs that are 22 members of the LISP deployment. This set can then be made available 23 by the mapping system to all the member xTRs. An xTR can use the 24 RLOC set to optimise protocol operation as well as to implement new 25 functionality. This document describes the use of the LISP reliable 26 transport session between an xTR and a Map-Server to communicate the 27 contents of the RLOC membership set. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 13, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 65 3. Membership Distribution Overview . . . . . . . . . . . . . . 4 66 4. Membership Message Format . . . . . . . . . . . . . . . . . . 4 67 4.1. Membership Subscribe . . . . . . . . . . . . . . . . . . 5 68 4.2. Membership Subscribe ACK . . . . . . . . . . . . . . . . 6 69 4.3. Membership Subscribe NACK . . . . . . . . . . . . . . . . 7 70 4.4. Membership Unsubscribe . . . . . . . . . . . . . . . . . 8 71 4.5. Membership Element Add . . . . . . . . . . . . . . . . . 9 72 4.6. Membership Element Delete . . . . . . . . . . . . . . . . 10 73 4.7. Membership Refresh Request . . . . . . . . . . . . . . . 10 74 4.8. Membership Refresh Begin . . . . . . . . . . . . . . . . 11 75 4.9. Membership Refresh End . . . . . . . . . . . . . . . . . 12 76 5. Membership Distribution Message Exchange . . . . . . . . . . 12 77 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 83 10.2. Informative References . . . . . . . . . . . . . . . . . 15 84 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 The Locator/ID Separation Protocol (LISP) registration process 90 between an xTR and a Map-Server is defined in 91 [I-D.ietf-lisp-rfc6833bis]. In each registration message the xTR 92 communicates mapping records providing the list of routing locators 93 (RLOCs) that can be used to reach the endpoint identifier (EID) space 94 behind the xTR. By gleaning the RLOCs from all such registrations, 95 the map-server constructs the set of RLOCs across all the received 96 registrations. This set represents all the RLOCs used to encapsulate 97 traffic and is the complete RLOC membership of the LISP network 98 (limitations described below). 100 The gleaned RLOC membership set is communicated to the member xTRs 101 where it can be used to implement new functionality as well as to 102 optimise protocol operation. As one example in deployments where the 103 RLOC network provides guarantees against RLOC source address spoofing 104 the membership can be used as a decapsulation filter to prevent 105 injection of traffic by non-members. As a second example, a possible 106 optimisation to existing functionality can use changes to the RLOC 107 membership set to validate the xTR map-cache contents and trigger 108 updates for out-of-date mappings. 110 Distribution of the RLOC membership set is practical in VPN use cases 111 [I-D.lewis-lisp-vpns] where the number of member xTRs and their RLOCs 112 is bounded thus limiting both the number of membership elements that 113 must be distributed as well as the number of members that the set 114 must be distributed to. In a VPN use case the membership set is 115 specific to each VPN identified through the LISP Instance ID (IID). 116 It is reasonable to expect that all member xTRs for a specific VPN 117 can register against a pair of redundant Map-Servers. The complete 118 membership set will therefore be available on those Map-Servers. 119 Alternatively, registration can be across a small set of Map-Servers 120 that synchronise the RLOC membership set between them (outside the 121 scope of this document). In the general case the RLOC membership 122 knowledge is split across a distributed mapping system 123 [I-D.ietf-lisp-ddt] and its collection and distribution would hit 124 scale limits. 126 Membership gleaning at the Map-Server assumes symmetric ITR and ETR 127 deployments. All encapsulating ITRs also have to be configured as 128 ETRs registering against the Map-Servers. This is a common way of 129 deploying LISP xTRs. To allow members that do not own EID space 130 (such as exclusive ITRs and proxy routers) to be included in the 131 membership set the registration mechanism must be extended. 133 Note that automatic membership gleaning at the Map-Server through 134 registrations is just one mechanism that can be used to discover the 135 RLOC set to be distributed. This document focuses on the membership 136 set distribution mechanism. 138 The LISP extension in [I-D.kouvelas-lisp-reliable-transport] 139 introduces a reliable transport session between the xTR and the MS. 140 The membership set communication described in this document is based 141 on message exchange over the reliable transport. 143 2. Requirements Notation 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 3. Membership Distribution Overview 151 The RLOC membership set distribution from the Map-Server to the xTR 152 is initiated on demand by the xTR. Unless the xTR specifically 153 subscribes to receive the RLOC membership set no action is taken by 154 the Map-Server. The granularity at which a Map-Server gleans 155 membership, and that an xTR can request its distribution, is per EID 156 address family and instance ID. This matches the VPN EID space 157 segmentation model allowing separate communication of the membership 158 of different VPNs. It also allows for each EID address family to 159 have a different xTR membership. 161 The Map-Server SHOULD only allow the distribution of the RLOC 162 membership set for an EID instance and address family to xTRs that 163 are valid members of the set being distributed. An xTR that has a 164 reliable transport session established with the Map-Server and is 165 registering EID prefixes with the Map-Server but not for the specific 166 instance ID and EID address family, SHOULD NOT be sent the RLOC 167 membership set. 169 The set of member RLOCs for an EID address family and instance ID is 170 dynamic and changes as new registrations are received by the Map- 171 Server and as registration state times out. When membership 172 distribution is initiated by the xTR, the complete RLOC set contents 173 is communicated. In parallel updates to the membership set begin 174 being communicated. The membership set updates continue for the 175 duration of the reliable transport session or until the xTR 176 unsubscribes from the membership distribution. 178 4. Membership Message Format 180 The membership distribution exchange between the xTR and Map-Server 181 over the reliable transport session relies on a number of new 182 messages defined below. The use of these messages is described in 183 the following sections. The table below lists the messages. All 184 messages carry the EID address family and instance ID for the 185 membership distribution. Some messages additionally carry extra 186 fields that are listed in the table. The new messages are: 188 +------+-----------------+-----------+---------------------+ 189 | Type | Message | Direction | Additional fields | 190 +------+-----------------+-----------+---------------------+ 191 | 22 | Subscribe | xTR -> MS | | 192 | | | | | 193 | 23 | Subscribe ACK | MS -> xTR | Subscribe ID | 194 | | | | | 195 | 24 | Subscribe NACK | MS -> xTR | Subscribe ID, Error | 196 | | | | | 197 | 25 | Unsubscribe | xTR -> MS | | 198 | | | | | 199 | 26 | Element Add | MS -> xTR | Site-ID, RLOC | 200 | | | | | 201 | 27 | Element Delete | MS -> xTR | Site-ID, RLOC | 202 | | | | | 203 | 28 | Refresh Request | xTR -> MS | | 204 | | | | | 205 | 29 | Refresh Begin | MS -> xTR | Request ID | 206 | | | | | 207 | 30 | Refresh End | MS -> xTR | Request ID | 208 +------+-----------------+-----------+---------------------+ 210 Table 1: Reliable transport membership distribution TLVs 212 The rest of this section provides the format of each of the messages 213 in the table. For a description of the Type, Length, Message ID and 214 Message End Marker fields refer to 215 [I-D.kouvelas-lisp-reliable-transport]. 217 4.1. Membership Subscribe 219 The Membership subscribe message is sent by the xTR to the Map-Server 220 to initiate RLOC membership set distribution for a specific EID AFI 221 and instance ID. 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Type = 22 | Length | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Message ID | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | EID AFI | EID IID ... 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 ... | Message End Marker ... 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 ... | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Membership subscribe message format 239 o EID-AFI: EID address family for which the membership is being 240 requested. 242 o EID IID: The EID instance ID identifying the VPN for which the 243 membership is being requested [I-D.lewis-lisp-vpns]. Although the 244 IID is only 24 bits in size in the data encapsulation, it is being 245 defined as a 32 bit field for consistency with the LCAF Instance 246 ID header [I-D.ietf-lisp-lcaf]. 248 4.2. Membership Subscribe ACK 250 The Membership-Subscribe-ACK message is sent by the Map-Server to the 251 xTR to acknowledge acceptance of a Membership-Request. This message 252 indicates that the Map-Server will be providing the requested 253 membership to the xTR. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Type = 23 | Length | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Message ID | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | EID AFI | EID IID ... 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 ... | Subscribe message ID ... 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 ... | Message End Marker ... 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 ... | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Membership-Subscribe-ACK message format 273 o Subscribe message ID: The message ID carried over from the 274 membership subscribe message. 276 4.3. Membership Subscribe NACK 278 The Membership-Subscribe-NACK message is sent by the Map-Server to 279 the xTR to reject a membership request. This message indicates that 280 the Map-Server will not be providing the requested membership to the 281 xTR. The membership subscribe NACK message can be sent at any point 282 following the receipt of a Membership-Subscribe message. The Map- 283 Server may initially acknowledge a subscription with a Membership 284 Subscribe ACK and later when conditions change cancel the 285 subscription by issuing a membership subscribe NACK message. 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type = 24 | Length | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Message ID | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | EID AFI | EID IID ... 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 ... | Subscribe message ID ... 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 ... | Error code | ... 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 ... Message End Marker | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Membership subscribe NACK message format 305 o Subscribe message ID: The message ID carried over from the 306 membership subscribe message. 308 o Error code: The error code provides a reason for which the 309 registration was rejected by the Map-Server. Defined values are: 311 1 - Not found: The EID instance and address family do not match 312 the Map-Server configuration. 314 2 - Not enabled: The Map-Server is not configured to allow 315 membership distribution for the requested EID instance and 316 address family. 318 3 - Not authorized: The xTR that sent the request does not have a 319 valid registration under the EID instance and address family. 321 4.4. Membership Unsubscribe 323 The Membership-Unsubscribe message is sent by the xTR to the Map- 324 Server to terminate RLOC membership set distribution for a specific 325 EID AFI and instance ID. 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Type = 25 | Length | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Message ID | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | EID AFI | EID IID ... 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 ... | Message End Marker ... 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 ... | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Membership-Unsubscribe message format 343 4.5. Membership Element Add 345 The Membership-Element-Add message is sent by the Map-Server to the 346 xTR to communicate a single RLOC that is a member of the set for the 347 specified EID instance and address family. 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Type = 26 | Length | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Message ID | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | EID AFI | EID IID ... 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 ... | Site ID ... 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 ... Site ID continued ... 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 ... | RLOC address AFI | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | RLOC address ... 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Message End Marker | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Membership-Element-Add message format 371 o Site ID: The 64 bit site ID value from the mapping registration 372 that contributed this RLOC to the membership list. The site ID 373 can be used by the receiving xTR to derive information about the 374 grouping of member RLOCs to remote sites. 376 o RLOC address AFI: Address family identifier for the RLOC address 377 in the following field. 379 o RLOC address: The actual RLOC membership set element address being 380 communicated. Note that the length of this field depends on the 381 RLOC address AFI in the preceding field. 383 4.6. Membership Element Delete 385 The Membership-Element-Delete message is sent by the Map-Server to 386 the xTR to communicate a single RLOC that is no longer a member of 387 the set for the specified EID instance and address family. 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Type = 27 | Length | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Message ID | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | EID AFI | EID IID ... 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 ... | Site ID ... 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 ... Site ID continued ... 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 ... | RLOC address AFI | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | RLOC address ... 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Message End Marker | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Membership-Element-Delete message format 411 4.7. Membership Refresh Request 413 The Membership-Refresh-Request message is sent by the xTR to the Map- 414 Server to request that the Map-Server send the complete RLOC 415 membership set contents for the specified instance ID and AFI. 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Type = 28 | Length | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Message ID | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | EID AFI | EID IID ... 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 ... | Message End Marker ... 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 ... | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 Membership-Refresh-Request message format 433 4.8. Membership Refresh Begin 435 The Membership-Refresh-Begin message is sent by the Map-Server to the 436 xTR to acknowledge an earlier Membership-Refresh-Request message and 437 to indicate that the following membership updates are part of the 438 refresh. 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Type = 29 | Length | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Message ID | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | EID AFI | EID IID ... 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 ... | Request message ID ... 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 ... | Message End Marker ... 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 ... | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 Membership-Refresh-Begin message format 458 o Request message ID: The message ID carried over from the 459 membership request message. 461 4.9. Membership Refresh End 463 The Membership-Refresh-End message is sent by the Map-Server to the 464 xTR to indicate that the communication of the full membership refresh 465 for the specified EID instance ID and AF is now complete. 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Type = 30 | Length | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Message ID | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | EID AFI | EID IID ... 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 ... | Request message ID ... 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 ... | Message End Marker ... 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 ... | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Membership-Refresh-End message format 485 o Request message ID: The message ID carried over from the 486 membership request message. 488 5. Membership Distribution Message Exchange 490 Following the reliable transport session establishment, the EID 491 membership communication relies on the exchange of the membership 492 messages defined in the previous section. The description in this 493 section presents the exchange from the perspective of a single xTR 494 and Map-Server. 496 xTR MS 497 | | 498 | ------- Subscribe ------> | 499 | | 500 | <---- Subscribe ACK ----- | 501 | | 502 | ---- Refresh request ---> | 503 | | 504 | <---- Refresh begin ----- | 505 | | 506 | <----- Element add ------ | 507 | <----- Element add ------ | 508 | <----- Element add ------ | 509 | | 510 | <----- Refresh end ------ | 511 | | 512 | <-- Element add/delete -- | 513 | | 514 | ------ Unsubscribe -----> | 516 Typical membership distribution message exchange 518 The xTR starts the exchange by issuing a Membership-Subscribe-Request 519 message to the Map-Server for a specific EID instance. Assuming the 520 Map-Server is configured to allow membership distribution and the 521 requesting router is authorized to receive the membership of the EID 522 instance, the MS will reply with a Membership-Subscribe-ACK. After 523 sending the ACK, the MS will start sending to the xTR Membership- 524 Element-Add and Membership-Element-Delete messages corresponding to 525 changes of the EID instance membership. 527 On receipt of the Membership-Subscribe-ACK message, the xTR issues a 528 Membership-Refresh-Request message in order to receive the complete 529 contents of the EID instance membership held by the MS. The MS 530 responds to the Membership-Refresh-Request by issuing a Membership- 531 Refresh-Begin message, followed by a Membership-Element-Add message 532 for each member of the EID instance and finally completes the refresh 533 by sending a Membership-Refresh-End message. 535 On receipt of Membership-Element-Add and Membership-Element-Delete 536 messages, the xTR updates its membership database for the EID 537 instance ID and address family by adding or deleting the entry 538 corresponding to the communicated RLOC address. Note that the 539 membership state on the xTR is Map-Server specific and the xTR has to 540 maintain separate RLOC membership entries received from each Map- 541 Server it subscribes with. 543 When the xTR receives the Membership-Refresh-End message it purges 544 all the stale membership entries it may have obtained during a 545 previous session instantiation that were not updated during the 546 refresh. 548 The MS may issue Membership-Element-Add and Membership-Element-Delete 549 messages corresponding to membership changes at any point after 550 issuing the Membership-ACK message, even during a refresh. 552 The xTR may request additional full refreshes of the complete 553 membership set at any point after having received a Membership- 554 Subscribe-ACK message by issuing a new Membership-Refresh-Request. 556 When the Map-Server determines that an xTR is no longer eligible to 557 receive membership updates, for example the EID instance and address 558 family registration state of the xTR becomes invalid, then the Map- 559 Server SHOULD send it a Membership-NACK message to indicate the 560 termination of the membership communication. 562 6. Implementation Status 564 [Note to RFC Editor: Please remove this section and the reference to 565 [RFC6982] before publication.] 567 This section records the status of known implementations of the LISP 568 RLOC Membership Distribution at the time of posting of this Internet- 569 Draft, and is based on a proposal described in [RFC6982]. 571 The description of implementations in this section is intended to 572 assist the IETF in its decision processes in progressing drafts to 573 RFCs. 575 Cisco has a production implementation of the RLOC membership 576 distribution mechanism described in this draft on IOS, IOS-XE and 577 IOS-XR. The RLOC membership information is used to implement the 578 data plane security functionality described in: LISP Data Plane 579 Security [1]. For additional information please contact lisp- 580 support@cisco.com. 582 7. Security Considerations 584 The RLOC membership distribution message communication takes place 585 over a LISP reliable transport connection. The security mechanisms 586 of the reliable transport apply to this solution. 588 8. IANA Considerations 590 The following message types must be assigned out of the space defined 591 in [I-D.kouvelas-lisp-reliable-transport]. 593 Type Name Reference 594 ----- ----------------------------- -------------- 595 22 Membership Subscribe This document 596 23 Membership Subscribe ACK This document 597 24 Membership Subscribe NACK This document 598 25 Membership Unsubscribe This document 599 26 Membership Element Add This document 600 27 Membership Element Delete This document 601 28 Membership Refresh Request This document 602 29 Membership Refresh Begin This document 603 30 Membership Refresh End This document 605 9. Acknowledgments 607 The authors would like to thank Michiel Blokzijl, Selina Heimlich, 608 Vasileios Lakafosis, Fabio Maino, Andre Pelletier, Jesper Skriver and 609 Chao Yu, for their contributions to this specification. 611 10. References 613 10.1. Normative References 615 [I-D.ietf-lisp-rfc6833bis] 616 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 617 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 618 Plane", draft-ietf-lisp-rfc6833bis-25 (work in progress), 619 June 2019. 621 [I-D.kouvelas-lisp-reliable-transport] 622 Cassar, C., Kouvelas, I., and D. Lewis, "LISP Reliable 623 Transport", draft-kouvelas-lisp-reliable-transport-02 624 (work in progress), March 2015. 626 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 627 Requirement Levels", BCP 14, RFC 2119, 628 DOI 10.17487/RFC2119, March 1997, . 631 10.2. Informative References 633 [I-D.ietf-lisp-ddt] 634 Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 635 Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- 636 ddt-09 (work in progress), January 2017. 638 [I-D.ietf-lisp-lcaf] 639 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 640 Address Format (LCAF)", draft-ietf-lisp-lcaf-22 (work in 641 progress), November 2016. 643 [I-D.lewis-lisp-vpns] 644 Lewis, D. and G. Schudel, "LISP Virtual Private Networks 645 (VPNs)", draft-lewis-lisp-vpns-00 (work in progress), 646 February 2014. 648 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 649 Code: The Implementation Status Section", RFC 6982, 650 DOI 10.17487/RFC6982, July 2013, . 653 10.3. URIs 655 [1] http://www.cisco.com/c/en/us/td/docs/ios- 656 xml/ios/iproute_lisp/configuration/xe-3s/irl-xe-3s-book/irl-data- 657 plane-sec.html 659 Authors' Addresses 661 Johnson Leong 662 Cisco Systems 663 Tasman Drive 664 San Jose, CA 95134 665 USA 667 Email: joleong@cisco.com 669 Darrel Lewis 670 Cisco Systems 671 Tasman Drive 672 San Jose, CA 95134 673 USA 675 Email: darlewis@cisco.com 676 Gregg Schudel 677 Cisco Systems 678 Tasman Drive 679 San Jose, CA 95134 680 USA 682 Email: gschudel@cisco.com 684 Anton Smirnov 685 Cisco Systems 686 Tasman Drive 687 San Jose, CA 95134 688 USA 690 Email: asmirnov@cisco.com 692 Chris Cassar 693 Tesla 694 10 New Square Park 695 Bedfont Lakes, Feltham TW14 8HA 696 United Kingdom 698 Email: christiancassar@acm.org 700 Isidor Kouvelas 701 Arista Networks Inc. 702 5453 Great America Parkway 703 Santa Clara, CA 95054 704 USA 706 Email: isidor@kouvelas.net