idnits 2.17.1 draft-rodrigueznatal-ila-lisp-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 5, 2018) is 2185 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-04 == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-01 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-12 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-10 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-14 == Outdated reference: A later version (-08) exists of draft-kouvelas-lisp-map-server-reliable-transport-04 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Rodriguez-Natal 3 Internet-Draft V. Ermagan 4 Intended status: Experimental F. Maino 5 Expires: October 7, 2018 Cisco Systems 6 A. Cabellos 7 Technical University of Catalonia 8 April 5, 2018 10 LISP control-plane for Identifier Locator Addressing (ILA) 11 draft-rodrigueznatal-ila-lisp-01 13 Abstract 15 This document specifies how to use the LISP control-plane to support 16 an Identifier Locator Addressing (ILA) data-plane. In particular, it 17 describes how ILA data-plane components can use the LISP control- 18 plane to dynamically resolve and register Identifier-to-Locator 19 mappings as well as Endpoint Address to Identifier/Locator mappings. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 7, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. LISP Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. ILA encoding in LISP . . . . . . . . . . . . . . . . . . . . 4 59 4.1. ILA LCAF . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1.1. Identifier Subtype . . . . . . . . . . . . . . . . . 5 61 4.1.2. Locator Subtype . . . . . . . . . . . . . . . . . . . 7 62 4.1.3. SIR Prefix Subtype . . . . . . . . . . . . . . . . . 8 63 4.2. IPv6 addresses . . . . . . . . . . . . . . . . . . . . . 8 64 4.2.1. Identifiers . . . . . . . . . . . . . . . . . . . . . 8 65 4.2.2. Locators . . . . . . . . . . . . . . . . . . . . . . 9 66 5. Device Roles and Provision . . . . . . . . . . . . . . . . . 9 67 5.1. Map Server (MS) . . . . . . . . . . . . . . . . . . . . . 10 68 5.2. Map Resolver (MR) . . . . . . . . . . . . . . . . . . . . 10 69 5.3. ILA-Router (ILA-R) . . . . . . . . . . . . . . . . . . . 10 70 5.4. ILA-Node (ILA-N) . . . . . . . . . . . . . . . . . . . . 10 71 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 6.1. ILA Identifier to Locator Mappings . . . . . . . . . . . 11 73 6.1.1. Resolution (via Map-Request to MR) . . . . . . . . . 12 74 6.1.2. Resolution (via Map-Notify from ILA-R/MS) . . . . . . 12 75 6.1.3. Registration . . . . . . . . . . . . . . . . . . . . 13 76 6.1.4. PubSub . . . . . . . . . . . . . . . . . . . . . . . 13 77 6.1.5. Mobility . . . . . . . . . . . . . . . . . . . . . . 13 78 6.2. Endpoint Address to ILA Identifier/Locator Mappings . . . 14 79 6.2.1. Resolution . . . . . . . . . . . . . . . . . . . . . 15 80 6.2.2. Registration . . . . . . . . . . . . . . . . . . . . 16 81 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 16 82 7.1. Protocol Transport . . . . . . . . . . . . . . . . . . . 16 83 7.2. Mapping System Internal Resolution . . . . . . . . . . . 16 84 7.3. Mapping System Replication and Synchronization . . . . . 17 85 7.4. Multiple ILA Domains . . . . . . . . . . . . . . . . . . 17 86 7.5. Proactive Mapping Push . . . . . . . . . . . . . . . . . 17 87 7.6. Checksum Adjustment per Locator . . . . . . . . . . . . . 18 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 8.1. Signaling Protection . . . . . . . . . . . . . . . . . . 18 90 8.2. Map-Cache Attacks . . . . . . . . . . . . . . . . . . . . 18 91 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 95 11.2. Informative References . . . . . . . . . . . . . . . . . 20 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 98 1. Introduction 100 The Locator/ID Separation Protocol (LISP) control-plane document 101 [I-D.ietf-lisp-rfc6833bis] defines a generic Mapping Service that in 102 addition to encapsulation-based Loc-ID separation data-planes, such 103 as the LISP data-plane [I-D.ietf-lisp-rfc6830bis], can be also 104 applied to translation-based Loc-ID separation data-planes. 106 Between the translation-based Loc-ID separation data-planes, this 107 document focuses on the use of LISP control-plane with the Identifier 108 Locator Addressing (ILA) [I-D.herbert-intarea-ila] data-plane, but a 109 similar approach can be used with other translation-based Loc-ID 110 separation data-planes such as the SRv6 Network Programming 111 [I-D.filsfils-spring-srv6-network-programming] data-plane, or the 112 Identifier-Locator Network Protocol (ILNP) [RFC6740] data-plane. 114 The Identifier Locator Addressing (ILA) is an IPv6 data-plane 115 protocol that relies on address splitting for ID/location separation. 116 Part of the IPv6 address expresses the Identifier of an endpoint, the 117 immutable identity of the node (e.g. task, end-host, mobile device, 118 etc), while another part represents its Locator, the topological 119 location of the endpoint, which can be dynamic. The Locator defines 120 where the Identifier is currently attached to the network and is used 121 to route the packets through the ILA domain. To do so, ILA Locators 122 are prepended to the ILA Identifier to form a routable ILA address 123 (bitwise equivalent to an IPv6 address). 125 The Identifier of an endpoint is unique and permanent for its 126 lifetime, meanwhile its locator is not fixed and subject to change 127 over time. A control-plane protocol to resolve Identifier-to-Locator 128 mappings is needed in order to use the ILA data-plane. The ILA data- 129 plane is agnostic to the control-plane mechanism in place and 130 therefore different control-plane protocols have been proposed 131 [I-D.lapukhov-bgp-ila-afi] [I-D.herbert-ila-ilamp]. 133 This document describes how the LISP control-plane can be used to 134 support the operation of the ILA data-plane, including the resolution 135 of the Identifier-to-Locator mappings and the Endpoint Address to ILA 136 Identifier/Locator mappings. 138 2. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 3. LISP Overview 146 TBD 148 4. ILA encoding in LISP 150 ILA Identifiers and Locators can be encoded in LISP messages using an 151 ILA-specific LCAF type or within IPv6 addresses. This section 152 describes both options. 154 4.1. ILA LCAF 156 To support explicit ILA mappings and associated data using the LISP 157 control-plane the following LISP Canonical Address Format (LCAF) 158 [RFC8060] is introduced. The ILA LCAF permits to explicitly identify 159 addresses as ILA Identifiers or Locators, allows to explicitly 160 indicate the length of the Identifier or Locator and enables to carry 161 ILA specific metadata with the ILA Identifiers and Locators. The ILA 162 LCAF type defines several subtypes, this document refers to the 163 different subtypes of the ILA LCAF using the syntax "ILA-Subtype" 164 LCAF (e.g. ILA-Identifier). All the ILA subtypes follow the format 165 defined below: 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | AFI = 16387 | Rsvd1 | Flags | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Type = ILA |Subtype| Rsvd2 | Length | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | ILA Subtype... ~ 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 ILA LCAF 179 The fields specific to the the ILA LCAF Type are defined below. For 180 definition of the rest of fields see the LCAF specification 181 [RFC8060]. 183 Subtype: This is the ILA LCAF Subtype. This field indicates which 184 particular ILA format the ILA LCAF encodes. Currently the 185 following Subtypes are defined: 187 0x0: Reserved. Reserved for future use. 189 0x1: Identifier Subtype. Used to encode ILA Identifiers as 190 described in Section 4.1.1 192 0x2: Locator Subtype. Used to encode ILA Locators as described 193 in Section 4.1.2 195 0x3: SIR Prefix Subtype. Used to encode SIR Prefixes as 196 described in Section 4.1.3 198 4.1.1. Identifier Subtype 200 The Identifier subtype (aka ILA-Identifier LCAF) can be used to carry 201 ILA Identifiers in the LISP control-plane signaling. The ILA 202 specification [I-D.herbert-intarea-ila] defines different Identifiers 203 formats that can be used in the data-plane. The same Identifier 204 formats are described in this document for the ILA-Identifier LCAF 205 Subtype. When used in this document, each Identifier format is 206 referred by the code point defined in [I-D.herbert-intarea-ila], e.g. 207 "ILA-Identifier-0x3" LCAF. The ILA data-plane formats are bitwise 208 compatible with their correspondent LCAF formats. It is thus 209 possible for an ILA data-plane device to resolve the Locator for a 210 particular ILA Identifier even if the ILA data-plane device does not 211 understand that particular Identifier type. 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | AFI = 16387 | Rsvd1 | Flags | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Type = ILA | 0x1 |E|Rsvd2| Length | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Type|0| Identifier ~ 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 ILA-Identifier LCAF 225 The fields specific to the the ILA-Identifier LCAF Subtype are 226 defined below. 228 Type: This is the Type of Identifier as defined in 229 [I-D.herbert-intarea-ila]. 231 E: This is the "Endpoint Address Mapping" bit. If the 'E' bit is set 232 to 1, it indicates that the Identifier is being resolved to an 233 Endpoint Address (see Section 6.2). The 'E' bit is set to 0 234 otherwise. 236 Identifier: This is a variable length field that encodes an ILA 237 Identifier. The length of the Identifier can be inferred from the 238 Length field of the LCAF. 240 For reference and using an Identifier size of 64 bits (including the 241 first 4 bits with the Type), the different types of Identifiers are 242 encoded in the ILA-Identifier LCAF as described below. The common 243 part of the ILA-Identifier LCAF is not shown. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | 0x0 |0| | 249 +-+-+-+-+ Interface Identifier | 250 | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Interface Identifier (0x0) 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 | 0x1 |0| | 259 +-+-+-+-+ Locally Unique Identifier | 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Locally Unique Identifier (0x1) 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | 0x2 |0| VNID | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Virtual IPv4 | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Virtual IPv4 Identifier (0x2) 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | 0x3 |0| VNID | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Virtual Unicast IPv6 (lower 32 bits) | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Virtual Unicast IPv6 Identifier (0x3) 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | 0x4 |0| VNID | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Scope | Virtual Multicast IPv6 (lower 28 bits) | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Virtual Multicast IPv6 Identifier (0x4) 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | 0x5 |0| Non-Local Address Identifier | 299 +-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 300 | | 0x0 | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Non-Local Address Identifier (0x5) 305 4.1.2. Locator Subtype 307 The Locator subtype (aka ILA-Locator LCAF) can be used to carry ILA 308 Locators in the LISP control-plane signaling. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | AFI = 16387 | Rsvd1 | Flags | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Type = ILA | 0x2 |C|Rsvd2| Length | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Locator ~ 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 ILA LCAF 322 The fields specific to the the ILA-Locator LCAF Subtype are defined 323 below. 325 C: This is the "Checksum-Adjustment-Needed" bit. If the 'C' bit is 326 set to 1 it indicates that an ILA data-plane device has to compute 327 the checksum adjustment as described in [I-D.herbert-intarea-ila] 328 when sending ILA packets to this Locator. The 'C' bit is set to 0 329 otherwise. See Section 7.6 for more details. 331 Locator: This is a variable length field that encodes an ILA 332 Locator. The length of the Locator can be inferred from the 333 Length field of the LCAF. 335 4.1.3. SIR Prefix Subtype 337 The SIR Prefix subtype (aka ILA-SIR LCAF) can be used to encode the 338 SIR prefix when different ILA domains co-exist as described in 339 Section 7.4. 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | AFI = 16387 | Rsvd1 | Flags | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type = ILA | 0x3 | Rsvd2 | Length | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 |SIR Prefix Len | SIR Prefix ... ~ 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 ~ ... SIR Prefix | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | AFI = x | Address... ~ 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 ILA-SIR LCAF 356 The fields specific to the the ILA-SIR LCAF Subtype are defined 357 below. 359 SIR Prefix Len: This field indicates the length of the SIR Prefix 360 that follows. 362 Locator: This is a variable length field that encodes an ILA SIR 363 Prefix. 365 4.2. IPv6 addresses 367 Alternatively, ILA Identifiers and Locators can be encoded in LISP 368 messages using just IPv6 addresses. This section describes how to 369 encode each. Using an IPv6 representation does not require to use 370 any LCAF but prevents from being explicit on the length and ILA 371 semantics of the Identifiers and Locators, as well as from carrying 372 associated metadata. 374 4.2.1. Identifiers 376 ILA Identifiers are encoded in the lower end bits of an IPv6 address 377 when used within LISP control messages. The upper bits of the IPv6 378 address encode the SIR prefix to which the Identifier belongs to. 380 4.2.2. Locators 382 ILA Locators are encoded in the upper end bits of an IPv6 address 383 when used within LISP control messages. There are two options on 384 what to encode in the lower bits of the IPv6 address carrying the ILA 385 Locator. One option is to encode the ILA Identifier that triggered 386 the LISP control message. Another option is to encode the Control- 387 Plane Identifier described in Section 5. In the latter case, there 388 is no longer needed to statically configure the Control-Plane 389 Identifier in the different devices. 391 5. Device Roles and Provision 393 The ILA specification [I-D.herbert-intarea-ila] defines different ILA 394 data-plane devices (i.e. devices that can perform ILA transformations 395 of SIR addresses to/from ILA addresses), namely ILA-Router (ILA-R), 396 ILA-Host (ILA-H) and ILA-Node (ILA-N). This documents relies on the 397 terminology introduced in [I-D.herbert-intarea-ila] but uses ILA- 398 Router and ILA-Node denominations to distinguish between ILA data- 399 plane devices that have a complete map-cache set (ILA-R) versus those 400 that only have an incomplete map-cache (ILA-N). For the purpose of 401 this document, it is assumed that an ILA-N has endpoints assigned to 402 it to which it has direct connectivity (if it is an ILA-Host it may 403 be even hosting the endpoints itself). On the contrary, no endpoint 404 assignment is assumed for an ILA-R (although not precluded). This 405 section describes in general terms the role and required provisioning 406 of the different devices involved in an ILA-LISP deployment, for 407 operational details of these devices see Section 6 409 To avoid verbosity on the description of the provisioning 410 requirements listed below, there are two things that are assumed to 411 be configured in all the devices belonging to a given ILA domain: 413 o SIR prefix(es) of the ILA domain: This prefix serves to identify 414 traffic belonging to the ILA domain. It is also used to 415 differentiate across different ILA domains where several domains 416 share the same infrastructure. 418 o Control-Plane Identifier: a given Identifier within the ILA domain 419 is reserved to be used when sending control-plane messages across 420 devices. This Identifier is concatenated with the Locator of the 421 device that the control-plane message is addressed towards. When 422 receiving an ILA packet with this special Identifier, the packet 423 will be delivered to the control-plane process of the device. 425 5.1. Map Server (MS) 427 A MS has the complete mapping information for all the Identifiers in 428 the ILA domain. If the Identifier space is divided into different 429 shards, then each MS is responsible for a particular shard of 430 Identifiers. Then, for the Identifiers of its shard, the MS has the 431 complete mapping information. The mapping information at an MS can 432 be populated by the ILA devices registering their local mappings and/ 433 or by an external source. A MS has to be pre-provisioned with the 434 following: 436 Shard index: of the shard the MS is responsible for (if any). 438 5.2. Map Resolver (MR) 440 A MR receives requests for mappings from ILA data-plane devices and 441 forwards them to the appropriate MS. If needed, a MR is also able to 442 find which MS is associated with a particular shard. See Section 7.2 443 for a discussion on different options regarding how a MR can find the 444 appropriate MS to forward a given mapping request. 446 5.3. ILA-Router (ILA-R) 448 An ILA-R has a complete map-cache for the mappings in the domain. If 449 shards are used, then each ILA-R is assigned to a particular shard of 450 Identifiers for which it has a complete map-cache of mappings. An 451 ILA-R subscribes (as described in Section 6.1.4) to a MS (or to the 452 MS responsible for its shard) to populate and keep its map-cache 453 updated. The logical functions of a MS and an ILA-R serving the same 454 domain (or shard) can be co-located and assigned to the same box. In 455 that case, the ILA-R does not need to subscribe to the mappings in 456 the domain (or shard) since they are locally available. Normally, an 457 ILA-R has no endpoint (e.g. task, user-endpoint, etc) directly 458 attached. Instead, it serves to translate packets that were not 459 transformed by an ILA-N. To do so, as described in 460 [I-D.herbert-intarea-ila], an ILA-R announces the SIR prefix (plus 461 its shard index if needed) as an "anycast" address on the underlay to 462 attract traffic towards itself. An ILA-R has to be pre-provisioned 463 with the following: 465 Shard index: of the shard the ILA-R is assigned to. 467 5.4. ILA-Node (ILA-N) 469 This document uses the term ILA-Node to refer to an ILA translating 470 device that does not have a complete map-cache, in contrast with ILA- 471 Router that has a complete map-cache for the domain (or its shard). 472 Each ILA-N has a set of endpoints (and associated Identifiers) 473 assigned to it for which it has complete mapping information. An 474 ILA-N registers its local mapping information into a MS (or set of 475 MSs) as described in Section 6.1.3. A given ILA-N may have 476 Identifiers from different shards, in that case per each Identifier 477 it has to register the mapping information in the appropriate MS (the 478 one handling the shard of the Identifier). Contrary to an ILA-R, the 479 ILA-N does not have a full map-cache for remote Identifiers, but 480 rather it populates its map-cache on demand (following the mechanisms 481 described in Section 6.1) based on the actual data-plane traffic. An 482 ILA-N has to be pre-provisioned with the following: 484 Identifiers: that the ILA-N is responsible for (if they are not 485 created or auto-discovered by the ILA-N). 487 Locators: to use on the ILA underlay (if they are not created or 488 auto-discovered by the ILA-N). 490 VNID / Tenant-Prefix pairs: if virtualization is used (see also 491 Section 6.2). 493 MR Locator: to request mappings for remote identifiers. 495 MS Locator: of the MS (or MSs) responsible for the Identifiers 496 assigned to the ILA-N. 498 Checksum adjustment setting: to indicate if the ILA-N has to 499 perform or not checksum adjustment (see also Section 7.6). 501 6. Operation 503 An ILA data-plane can leverage the LISP control-plane to support 504 different aspects of its operation. The main function provided by 505 the LISP control plane is resolving the Identifier to Locator 506 mappings. In addition, ILA can also use the LISP control-plane to 507 dynamically learn the ILA Identifier associated to an Endpoint 508 Address. These two steps can also be combined into a single 509 resolution exchange. 511 6.1. ILA Identifier to Locator Mappings 513 This section describes how ILA devices can use the LISP control-plane 514 to resolve, register and keep updated the Identifier to Locator 515 mappings required for the operation of the ILA data-plane. Two 516 different modes of resolving the Identifier are described, one on 517 which the ILA-N sends a Map-Request to a MR and another where a ILA-R 518 with a co-located MS reacts to data-plane traffic and sends a Map- 519 Notify towards the ILA-N. 521 6.1.1. Resolution (via Map-Request to MR) 523 When an ILA-N has to send traffic towards a remote Identifier for 524 which it does not have the associated Locator, it can obtain the 525 Locator via sending a request to the MR. To do so, it follows the 526 mechanisms described in [I-D.ietf-lisp-rfc6833bis] and sends a Map- 527 Request towards one of its configured MRs. This Map-Request includes 528 as EID the ILA Identifier of the remote endpoint encoded as described 529 in Section 4. As a response to this Map-Request, the ILA-N will get 530 a Map-Reply from the MS with the Locator(s) associated with the 531 remote Identifier (if any). Locators are carried in the Map-Reply as 532 RLOCs and are encoded as discussed in Section 4. In the current ILA 533 specification, Identifiers are considered to be in a flat, non- 534 hierarchical space. Therefore, when resolving a single Identifier 535 the "EID mask-len" of the Map-Request and Map-Reply is set to the 536 length of the Identifier. 538 As specified in [I-D.ietf-lisp-rfc6833bis], an ILA-N can use the 539 priority and weight information conveyed in the Map-Reply message to 540 load balance data-plane traffic across the different Locators for the 541 remote Identifier. While the mapping is being resolved via the Map- 542 Request/Map-Reply process, the ILA-N can still send the data packets 543 to the underlay using the SIR address as described in 544 [I-D.herbert-intarea-ila]. In that way, they can be attracted and 545 transformed at an ILA-R. See also Section 8.2 for discussion on how 546 the ILA-N can protect itself from malicious endpoints trying to 547 artificially force map-cache misses (and subsequent Map-Requests). 549 6.1.2. Resolution (via Map-Notify from ILA-R/MS) 551 As described in [I-D.herbert-intarea-ila], the ILA-N sends the SIR 552 traffic to the underlay if it has no map-cache entry to transform 553 packets. The SIR traffic will be eventually attracted to an ILA-R 554 announcing the SIR prefix. Thus, the cache of an ILA-N can also be 555 populated via unsolicited Map-Notifies (as described in 556 [I-D.rodrigueznatal-lisp-pubsub]) when the MS is co-located with the 557 ILA-R. In this scenario, the ILA-R/MS reacts to the data-plane 558 traffic received sending unsolicited Map-Notify to the origin of the 559 traffic. To build the Map-Notify, the ILA-R extracts the ILA 560 Identifier from the data-packet received and finds the matching 561 mapping entry in its co-located MS. The ILA-R/MS then encodes the 562 Identifier and Locators from that mapping as EID and RLOC(s) 563 respectively in the Map-Notify, using the encoding described in 564 Section 4. 566 In general, the unsolicited Map-Notify resolution mode assumes that 567 the ILA-R/MS has both the mapping for the destination Identifier as 568 well as the source Identifier received in the data-packet. If the 569 ILA domain is sharded and the ILA-R/MS does not contain the mapping 570 for the source Identifier, the Map-Notify has to be routed towards 571 another ILA-R/MS that contains the Locator for the source Identifier. 573 6.1.3. Registration 575 An ILA-N registers its local Identifier-to-Locator mappings in the 576 appropriate MSs (i.e. those handling its Identifiers) by sending Map- 577 Register messages following the process documented in 578 [I-D.ietf-lisp-rfc6833bis]. To do so, it uses the encoding defined 579 in Section 4 to include the ILA Identifier as EID in the Map- 580 Register. Similarly to the mapping resolution process, the "EID 581 mask-len" of the Map-Register is fixed to the length of the 582 Identifier. The ILA-N includes its local Locators in the Map- 583 Register using the encoding defined in Section 4. As described in 584 [I-D.ietf-lisp-rfc6833bis], the mapping registration may happen 585 periodically as well as when there is a change in the mapping(s) that 586 the ILA-N is registering. 588 6.1.4. PubSub 590 An ILA-N can explicitly subscribe to mapping updates using the 591 mechanisms described in [I-D.rodrigueznatal-lisp-pubsub]. When using 592 the mapping resolution described in Section 6.1.1 to populate its 593 map-cache, an ILA-N can combine the resolution and subscription into 594 the same Map-Request/Map-Reply exchange. 596 Additionally, when ILA-Rs are not co-located with the MSs they need 597 to subscribe to mappings in the domain (or their shard). An ILA-R 598 subscribes using [I-D.rodrigueznatal-lisp-pubsub] to receive updates 599 for all the Identifier-Locator mappings in the domain (or in its 600 shard). To subscribe to all Identifier mappings in the ILA domain, 601 the ILA-R sets the "EID mask-len" in the Map-Request to 0 and encodes 602 the ILA Identifier as described in Section 4 with all the Identifier 603 bits set to 0. To subscribe to all Identifier mappings in a 604 particular shard, the ILA-R sets the "EID mask-len" in the Map- 605 Request to the shard index length and encodes the Identifier with the 606 proper shard index set and the rest of the Identifier bits set to 0. 608 6.1.5. Mobility 610 Mobility of Identifiers is supported by the mechanisms described in 611 [I-D.ietf-lisp-eid-mobility]. As described there, when an Identifier 612 moves to a different ILA-N, its previous ILA-N is notified with the 613 new Locator(s) for the Identifier. When traffic is received at the 614 old Locator, the ILA-N there can use the updated Identifier-Locator 615 mapping information to replace the old Locator with the new Locator 616 and forward the traffic back to the underlay. In the interim between 617 the ILA-N detects that the Identifier has moved but the notification 618 with the new Locator is yet to be received, the ILA-N can translate 619 received traffic for the Identifier to the SIR address and forward it 620 back to the underlay (to be intercepted, transformed and forwarded by 621 an ILA-R). 623 Following [I-D.ietf-lisp-eid-mobility], when the old ILA-N receives 624 traffic addressed for the Identifier that is no longer locally 625 connected, it sends a Solict-Map-Request (SMR) to the Locator 626 associated with the source Identifier to inform it that it should 627 update its map-cache. Note that when ILA is used as the data-plane, 628 the source Locator may not be present in the received data packet and 629 a mapping resolution (to find the ILA-N that originated the packet) 630 may be needed before the SMR can be sent. Note also that, if the 631 data packet was transformed and sent by an ILA-R, the source 632 Identifier will not resolve to the Locator of the ILA-R (but instead 633 to the ILA-N where the source Identifier is attached). For this 634 version of the document, the case of sending this SMR to an ILA-R is 635 not considered. 637 6.2. Endpoint Address to ILA Identifier/Locator Mappings 639 The ILA data-plane [I-D.herbert-intarea-ila] defines some cases where 640 the address used by an endpoint is not a SIR address. In those 641 cases, the Endpoint Address needs to be mapped to an ILA Identifier 642 before an ILA address (or SIR address) can be formed. These mappings 643 of Endpoint Addresses to ILA Identifiers can be statically 644 provisioned at the ILA-N or can also be resolved via the LISP 645 control-plane. There are currently two cases defined in 646 [I-D.herbert-intarea-ila] where an endpoint does not use a SIR 647 address and requires a mapping of Endpoint Address to ILA Identifier. 649 o Virtualization: In virtualization scenarios, the endpoints use 650 virtual addresses (with a Tenant Prefix in the case of IPv6) 651 rather than SIR addresses. Before packets can be sent over the 652 ILA underlay, the Tenant Prefix has to be converted into a VNID. 653 Instead of pre-provisioning the Tenant Prefix to VNID pairs in 654 advance, the ILA data-plane can also use the LISP control-plane to 655 resolve the mapping of Tenant Prefix to VNID. Dynamic resolution 656 instead of static provisioning can be specially useful for cases 657 of cross-communication between different virtual networks (since 658 the mapping of a remote Virtual Prefix to VNID may not be 659 available at the ILA-N). Once the ILA-N has resolved the VNID 660 associated with a Tenant Prefix, it can cache this information and 661 only request Identifier to Locator mappings for new remote 662 Endpoint Addresses using the same Tenant Prefix. Note that for 663 virtualization cases using IPv4, the current version of this 664 document assumes that the VNID has to be pre-provisioned since 665 there is not Tenant Prefix that can be resolved into a VNID. 667 o Non-Local Addresses: ILA uses the concept of Non-Local Addresses 668 to refer to Endpoint Addresses that do not belong to the SIR 669 prefix(es) of the domain. To use Non-Local Addresses with an ILA 670 data-plane, they need to be first converted into an ILA identifier 671 (of 44 bits in the current ILA specification). The LISP control- 672 plane can be used by the ILA data-plane to retrieve the mappings 673 of Non-Local Addresses to Identifiers (on packet transmission) and 674 of Identifiers to Non-Local Addresses (on packet reception). If 675 the ILA data-plane devices are also performing the assignment of 676 Non-Local Addresses to ILA Identifiers, the LISP control-plane can 677 also be used to register this assignment into the Mapping System. 679 This section covers the resolution (including reverse resolution) and 680 registration of Endpoint Address mappings. Contrary to the 681 Identifier to Locator mappings, the mappings of Endpoint Address to 682 Identifier are not expected to change once they have been 683 established. Therefore, the cases of PubSub and mobility are not 684 considered in this section. 686 6.2.1. Resolution 688 As with Identifier to Locator mapping resolution, the resolution of 689 Endpoint Address to Identifier is done via the Map-Request/Map-Reply 690 exchange specified in [I-D.ietf-lisp-rfc6833bis]. It is assumed that 691 in the scenario where LISP is used to resolve Endpoint Address to 692 Identifier mappings, the MR is able to find the MS storing the 693 requested Endpoint Address mapping. 695 When Endpoint Addresses are carried as EIDs in LISP control messages 696 they are encoded using the same format the endpoint is using (i.e. 697 IPv6 in the currently defined cases). The Identifier associated to 698 the Endpoint Address is returned in the Map-Reply as an RLOC with 699 priority 255 and encoded as defined in Section 4. Note that when 700 resolving an Endpoint Address to Identifier mapping, the Identifier 701 to Locator mapping can be included as well. In other words, the 702 Locators can also be encoded as RLOCs in the Map-Reply returned by 703 the MS. 705 In some cases (such in the Non-Local Address case) some ILA devices 706 may need to perform a reverse resolution of the Endpoint Address 707 mapping (i.e. obtain the Endpoint Address associated with a given 708 Identifier). In those cases, and when using the encoding described 709 in Section 4.1.1, the Identifier is sent as EID in the Map-Request 710 with the 'E' bit (defined in Section 4.1.1) set to '1'. The 'E' bit 711 is used to signal that the requested mapping is "Identifier to 712 Endpoint Address" and distinguish the request from the default 713 "Identifier to Locator" resolution that is triggered when sending an 714 Identifier in the Map-Request. On this reverse resolution, the MS 715 will return the Endpoint Address in the Map-Reply encoded as an RLOC 716 with priority 255. If the encoding described in Section 4.2 is used 717 instead, both the Endpoint Address and the Locators have to be 718 returned when querying for an ILA Identifier. In this latter case, 719 the Endpoint Address is still encoded in the Map-Reply with priority 720 255. 722 6.2.2. Registration 724 When the assignment of Endpoint Address to ILA Identifier is 725 performed by the ILA-N, the ILA-N can register this assignment into 726 its MS(s). The ILA-N encodes the Endpoint Address as EID (using the 727 same format the endpoint is using) and the Identifier as RLOC with 728 priority 255 (using the encoding discussed in Section 4). It is 729 assumed that the MS(s) assigned to the ILA-N are able to understand 730 and store the Endpoint Address to Identifier mappings generated by 731 the ILA-N. Similarly to the resolution case, the Identifier to 732 Locator mapping can be also included when registering the Endpoint 733 Address mapping via means of providing too the Locators as RLOCs in 734 the Map-Register message. 736 7. Deployment Considerations 738 This section discusses different options and deployment scenarios to 739 consider when deploying an ILA data-plane using a LISP control-plane. 741 7.1. Protocol Transport 743 LISP as defined in [I-D.ietf-lisp-rfc6833bis] runs over a UDP 744 transport, however the exact same signaling can be used over a TCP 745 transport without affecting the protocol operation. If a TCP 746 transport is available, then the mechanisms described in 747 [I-D.kouvelas-lisp-map-server-reliable-transport] can also be used to 748 optimize the LISP control-plane protocol operation when this runs 749 over a reliable channel. 751 7.2. Mapping System Internal Resolution 753 For small deployments where each MS has the complete mapping 754 information for the domain, the MRs may just be provisioned with the 755 Locators for all the MSs. They can then do load balancing across the 756 MSs based on different metrics (e.g. latency, load, etc) 757 If the domain is split into shards, there are different ways for a MR 758 to find the MS that corresponds to a given shard. Some options can 759 include LISP-DDT [RFC8111] or LISP-ALT [RFC6836] for instance. 761 There is also the option that a backend database is used as Mapping 762 System, in which case both the MRs and MSs are just interfaces to 763 interact with the backend database. In that scenario, the database 764 internal implementation will find the appropriate instance that is 765 hosting the requested mapping. 767 7.3. Mapping System Replication and Synchronization 769 For reliability and latency purposes, several MSs can be deployed for 770 the same domain or the same shard. In that scenario, it is required 771 to have a mechanism to synchronize the mapping information across 772 them. One option is that, as described in 773 [I-D.ietf-lisp-rfc6833bis], the ILA-Ns register their local mappings 774 to several MSs. Alternatively, when a backend database is in place, 775 mechanisms specific to the database implementation can be leveraged 776 to provide synchronization across different replicas. 778 7.4. Multiple ILA Domains 780 When different ILA domains co-exist using the same infrastructure, it 781 may be needed to distinguish the particular domain to which a control 782 message refers to. In that case, the Identifiers and Endpoint 783 Addresses must be qualified with the appropriate ILA domain for the 784 control-plane operation. This can be done by prepending the ILA-SIR 785 LCAF described in Section 4.1.3 when needed. If the encoding 786 described in Section 4.1 is used both the ILA Identifiers and 787 Endpoint Addresses need to be qualified when used as EIDs in LISP 788 messages. When the encoding described in Section 4.2 is used only 789 Endpoint Addresses need to be qualified. 791 7.5. Proactive Mapping Push 793 Optionally, when a MS receives a Map-Request (or when an ILA-R/MS 794 receives data-traffic) for an Identifier, it can send a proactive 795 Map-Notify towards the ILA-N associated with that Identifier. In 796 this Map-Notify the MS (or ILA-R/MS) includes the mapping associated 797 with the Identifier that triggered the Map-Request. This will pre- 798 populate the map-cache of the destination ILA-N and provide the ILA-N 799 the mapping required to handle the returning traffic. This mechanism 800 assumes that the MS (or ILA-R/MS) has both the mapping for the 801 destination and source Identifiers. 803 7.6. Checksum Adjustment per Locator 805 While performing ILA transformations, ILA data-plane devices 806 optionally perform checksum adjustments to keep the transport 807 checksum neutral to the transformation. As an alternative to 808 statically configuring the checksum-neutral adjustment option per 809 ILA-N (or ILA-R), the Locators associated with a particular 810 Identifier can be qualified with the requested selection regarding 811 checksum-neutral adjustment. Then, the need to perform or not this 812 checksum adjustment when sending traffic to a particular Locator can 813 be stored and retrieved from the MSs encoded in the ILA Locator LCAF 814 defined in Section 4.1.2. 816 8. Security Considerations 818 8.1. Signaling Protection 820 All LISP messages have a field for authentication data defined in 821 either [I-D.ietf-lisp-rfc6833bis] or [I-D.ietf-lisp-sec]. As 822 described in [I-D.ietf-lisp-rfc6833bis] a shared key is required 823 between the data-plane devices and their associated MSs to sign and 824 secure the signaling. Additional authentication and integrity 825 protection can be enabled by using [I-D.ietf-lisp-sec]. 826 Complementary, if a TCP session is in place between the ILA data- 827 plane elements and the LISP control-plane components, then TLS can be 828 used to provide authentication and integrity protection. 830 8.2. Map-Cache Attacks 832 Malicious endpoints can try to deplete the map-cache and/or overload 833 the Map-Request channel of an ILA-N. To prevent against these 834 attacks, the ILA-N should implement efficient heavy hitters counters 835 such as Count-Min Sketch [CMS] to prevent data-plane traffic from 836 certain endpoints to trigger further control-plane processing once a 837 threshold has been reached. In addition, similar mechanisms can be 838 used to protect popular map-cache entries from eviction when the map- 839 cache space is being depleted. Discussion on how to apply heavy 840 hitter counters to LISP in particular can be found in [CMS-LISP]. 842 9. Acknowledgments 844 The authors would like to thank Sri Gundavelli, Marc Portoles- 845 Comeras, Tom Herbert, Dino Farinacci, Joel Halpern and Luigi Iannone 846 for their comments and feedback regarding this document. 848 10. IANA Considerations 850 Following the guidelines of [RFC5226], this document requests IANA to 851 update the "LISP Canonical Address Format (LCAF) Types" Registry 852 defined in [RFC8060] to allocate the following assignment: 854 +---------+---------------------+-------------+ 855 | Value # | LISP LCAF Type Name | Reference | 856 +---------+---------------------+-------------+ 857 | TBD | ILA | Section 4.1 | 858 +---------+---------------------+-------------+ 860 Table 1: ILA LCAF assignment 862 11. References 864 11.1. Normative References 866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 867 Requirement Levels", BCP 14, RFC 2119, 868 DOI 10.17487/RFC2119, March 1997, 869 . 871 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 872 IANA Considerations Section in RFCs", RFC 5226, 873 DOI 10.17487/RFC5226, May 2008, 874 . 876 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 877 Protocol (ILNP) Architectural Description", RFC 6740, 878 DOI 10.17487/RFC6740, November 2012, 879 . 881 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 882 "Locator/ID Separation Protocol Alternative Logical 883 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 884 January 2013, . 886 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 887 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 888 February 2017, . 890 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 891 Smirnov, "Locator/ID Separation Protocol Delegated 892 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 893 May 2017, . 895 11.2. Informative References 897 [CMS] Cormode, G. and S. Muthukrishnan, "An improved data stream 898 summary: the count-min sketch and its applications", 899 Journal of Algorithms 55(1), 58-75, April 2005. 901 [CMS-LISP] 902 Almasan, P., Paillisse, J., Rodriguez-Natal, A., Barlet- 903 Ros, P., Coras, F., Ermagan, V., Maino, F., and A. 904 Cabellos-Aparicio, "Securing the Control-plane Channel and 905 Cache of Pull-based ID/LOC Protocols", ArXiv 906 e-prints 1803.08568, March 2018. 908 [I-D.filsfils-spring-srv6-network-programming] 909 Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., 910 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 911 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 912 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and 913 M. Sharif, "SRv6 Network Programming", draft-filsfils- 914 spring-srv6-network-programming-04 (work in progress), 915 March 2018. 917 [I-D.herbert-ila-ilamp] 918 Herbert, T., "Identifier Locator Addressing Mapping 919 Protocol", draft-herbert-ila-ilamp-00 (work in progress), 920 December 2017. 922 [I-D.herbert-intarea-ila] 923 Herbert, T. and P. Lapukhov, "Identifier-locator 924 addressing for IPv6", draft-herbert-intarea-ila-01 (work 925 in progress), March 2018. 927 [I-D.ietf-lisp-eid-mobility] 928 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 929 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 930 Unified Control Plane", draft-ietf-lisp-eid-mobility-01 931 (work in progress), November 2017. 933 [I-D.ietf-lisp-rfc6830bis] 934 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 935 Cabellos-Aparicio, "The Locator/ID Separation Protocol 936 (LISP)", draft-ietf-lisp-rfc6830bis-12 (work in progress), 937 March 2018. 939 [I-D.ietf-lisp-rfc6833bis] 940 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 941 "Locator/ID Separation Protocol (LISP) Control-Plane", 942 draft-ietf-lisp-rfc6833bis-10 (work in progress), March 943 2018. 945 [I-D.ietf-lisp-sec] 946 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 947 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 948 (work in progress), October 2017. 950 [I-D.kouvelas-lisp-map-server-reliable-transport] 951 Cassar, C., Leong, J., Lewis, D., Kouvelas, I., and J. 952 Arango, "LISP Map Server Reliable Transport", draft- 953 kouvelas-lisp-map-server-reliable-transport-04 (work in 954 progress), September 2017. 956 [I-D.lapukhov-bgp-ila-afi] 957 Lapukhov, P., "Use of BGP for dissemination of ILA mapping 958 information", draft-lapukhov-bgp-ila-afi-02 (work in 959 progress), October 2016. 961 [I-D.rodrigueznatal-lisp-pubsub] 962 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 963 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 964 Boucadair, M., Jacquenet, C., and s. 965 stefano.secci@lip6.fr, "Publish/Subscribe Functionality 966 for LISP", draft-rodrigueznatal-lisp-pubsub-02 (work in 967 progress), March 2018. 969 Authors' Addresses 971 Alberto Rodriguez-Natal 972 Cisco Systems 973 170 Tasman Drive 974 San Jose, CA 975 USA 977 Email: natal@cisco.com 979 Vina Ermagan 980 Cisco Systems 981 170 Tasman Drive 982 San Jose, CA 983 USA 985 Email: vermagan@cisco.com 986 Fabio Maino 987 Cisco Systems 988 170 Tasman Drive 989 San Jose, CA 990 USA 992 Email: fmaino@cisco.com 994 Albert Cabellos 995 Technical University of Catalonia 996 Barcelona 997 Spain 999 Email: acabello@ac.upc.edu