idnits 2.17.1 draft-moreno-lisp-uberlay-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2019) is 1857 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3618' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'RFC4601' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'RFC4607' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'RFC6407' is defined on line 744, but no explicit reference was found in the text == Unused Reference: 'RFC6831' is defined on line 753, but no explicit reference was found in the text == Unused Reference: 'RFC7348' is defined on line 763, but no explicit reference was found in the text == Unused Reference: 'RFC8060' is defined on line 770, but no explicit reference was found in the text == Unused Reference: 'RFC8061' is defined on line 774, but no explicit reference was found in the text == Unused Reference: 'RFC8111' is defined on line 779, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-14) exists of draft-farinacci-lisp-decent-03 == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-02 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-02 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-25 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-19 == Outdated reference: A later version (-12) exists of draft-ietf-lisp-vpn-02 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 6833 (Obsoleted by RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Moreno 3 Internet-Draft Cisco Systems 4 Intended status: Experimental D. Farinacci 5 Expires: September 28, 2019 lispers.net 6 A. Rodriguez-Natal 7 M. Portoles-Comeras 8 F. Maino 9 S. Hooda 10 S. Kondalam 11 Cisco Systems 12 March 27, 2019 14 Uberlay Interconnection of Multiple LISP overlays 15 draft-moreno-lisp-uberlay-01 17 Abstract 19 This document describes the use of the Locator/ID Separation Protocol 20 (LISP) to interconnect multiple disparate and independent network 21 overlays by using a transit overlay. The transit overlay is referred 22 to as the "uberlay" and provides connectivity and control plane 23 abstraction between different overlays. Each network overlay may use 24 different control and data plane approaches and may be managed by a 25 different organization. Structuring the network into multiple 26 network overlays enables the interworking of different overlay 27 approaches to data and control plane methods. The different network 28 overlays are autonomous from a control and data plane perspective, 29 this in turn enables failure survivability across overlay domains. 30 This document specifies the mechanisms and procedures for the 31 distribution of control plane information across overlay sites and in 32 the uberlay as well as the lookup and forwarding procedures for 33 unicast and multicast traffic within and across overlays. The 34 specification also defines the procedures to support inter-overlay 35 mobility of EIDs and their integration with the intra-overlay EID 36 mobility procedures defined in draft-ietf-lisp-eid-mobility. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in [RFC2119]. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on September 28, 2019. 61 Copyright Notice 63 Copyright (c) 2019 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (https://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 80 3. Interconnecting multiple LISP site-overlays via the Uberlay . 4 81 4. General Procedures . . . . . . . . . . . . . . . . . . . . . 7 82 4.1. Control Plane Procedures . . . . . . . . . . . . . . . . 8 83 4.1.1. Split-horizon at the Border xTRs . . . . . . . . . . 9 84 4.2. Resolution and Forwarding Procedures . . . . . . . . . . 10 85 4.2.1. Multi-overlay requests at border xTR . . . . . . . . 11 86 4.3. Default EID registration and treatment . . . . . . . . . 11 87 5. Multicast Specific Procedures . . . . . . . . . . . . . . . . 12 88 5.1. Inter-site-overlay Control Plane Procedures for Signal- 89 free multicast . . . . . . . . . . . . . . . . . . . . . 12 90 5.2. Border xTR Resolution and Forwarding procedures for 91 Signal-free multicast . . . . . . . . . . . . . . . . . . 13 92 6. Inter site-overlay Mobility Procedures . . . . . . . . . . . 13 93 7. Virtual Private Network (VPN) Considerations . . . . . . . . 15 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 95 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 98 10.2. Informative References . . . . . . . . . . . . . . . . . 16 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 101 1. Introduction 103 The main motivation for this specification is to provide a 104 methodology for the interconnection of LISP domains that may use 105 disparate control and/or data plane approaches. For instance, one 106 domain may use native LISP encapsulation for its data plane and a DDT 107 based mapping system, while another domain may use VXLAN-GPE 108 encapsulation and a mapping system based on 109 [I-D.farinacci-lisp-decent]. Furthermore, one domain may use an IPv4 110 RLOC space and the other domain may use an IPv6 RLOC space and there 111 may not be connectivity between the domains at the RLOC level. We 112 propose a method to interconnect and enable interoperability between 113 these disparate LISP overlay networks by connecting them to a common 114 transit LISP overlay. 116 In order to provide interworking across implementations of overlays 117 that may use different control and data plane approaches, a LISP 118 network may be structured as a collection of site-overlays 119 interconnected by a transit area. Each site-overlay is a fully 120 functional overlay network and has its own set of Map Servers and Map 121 Resolvers. Site-overlays share a border xTR with a transit area. 122 Connectivity between site-overlays is provided via the transit area 123 which we will refer to as "The Uberlay". This specification 124 describes the Control Plane and Forwarding procedures for the 125 implementation of an Uberlay connected multi-overlay LISP network. 126 This approach to the structure of a LISP network may also enable 127 regional failure survivability and fault isolation. 129 2. Definition of Terms 131 LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel 132 Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map- 133 Resolver (MR) are defined in the LISP specification [RFC6830]. 135 Terms defining interactions with the LISP Mapping System are defined 136 in [RFC6833]. 138 Terms related to the procedures for signal free multicast are defined 139 in [RFC8378]. 141 The following terms are here defined to facilitate the descriptions 142 and discussions within this particular document. 144 Site-Overlay - Overlay network at a specific area or domain. This 145 overlay network has a dedicated Mapping System. 147 Border-xTR - xTR that connects a site-overlay to one or more 148 uberlays. 150 xTR - LISP Tunnel Router as defined in [RFC6833]. An xTR connects 151 end-points to the site-overlay. 153 Local Mapping System - Mapping system of the site-overlay 155 Uberlay - Overlay network that interconnects different site-overlays 156 to each other. The Uberlay has a dedicated Mapping System and 157 creates an overlay amongst the border xTRs which connect different 158 site-overlays. 160 Uberlay Mapping System - Autonomous mapping system dedicated to the 161 uberlay. 163 Site-Overlay EIDs - Also referred to as local site-overlay EIDs, 164 these are the EIDs that are connected to xTRs in a particular site- 165 overlay and are registered in their own local site-overlay mapping 166 system. These EIDs will also be registered in the uberlay but not in 167 the remote site-overlay mapping systems. 169 Remote site-overlay EIDs - These are EIDs connected and registered in 170 site-overlays other than the local site-overlay. 172 Local site-overlay EIDs - These are EIDs connected and registered in 173 the local site-overlay. 175 3. Interconnecting multiple LISP site-overlays via the Uberlay 177 A LISP network can be structured as a collection of LISP site- 178 overlays that are interconnected by one or more LISP Uberlays. 180 A LISP site-overlay is an overlay network that has its own set of 181 xTRs, its own dedicated Mapping System and it may have a dedicated 182 RLOC space, separate from that of other site-overlays or the uberlay. 183 A LISP uberlay is also an overlay network with its own set of xTRs, 184 its own dedicated Mapping System and it may have its own dedicated 185 RLOC space. When the RLOC spaces are dedicated, RLOC routes in the 186 local underlay do not leak across to the underlay of other site- 187 overlays. 189 A site-overlay will have xTRs and Border xTRs. The xTRs provide 190 connectivity to the local site-overlay EIDs, which are the EIDs that 191 are locally connected to the overlay-site. The Border xTRs are Re- 192 encapsulating Tunnel Routers (RTRs) that connect the site-overlays to 193 the LISP Uberlay in the transit network. xTRs participate in one 194 site-overlay and one site-overlay only. Border xTRs participate in 195 the mapping system of the site-overlay it resides in and the mapping 196 system of the uberlay it connects the site-overlay to. Border xTRs 197 may be shared by more than one site-overlay. 199 The different site-overlays can be interconnected by an uberlay. The 200 uberlay consists of a dedicated Mapping System and the set of Border 201 xTRs that connect the participating site-overlays to the Uberlay and 202 the Uberlay Mapping System. 204 Each site-overlay will have its own set of Map Servers and Map 205 Resolvers (MS/MRs) which operate as an autonomous Mapping System. 206 The Uberlay Mapping System is also autonomous and includes all 207 necessary Map Servers and Map Resolvers. Any of the Mapping Systems, 208 in site-overlays or in the Uberlay, follow the control plane 209 specification in [RFC6833] and may be structured as a Distributed 210 Delegation Tree (DDT) per [RFC8111]for the purposes of horizontal 211 scaling or other optimizations within each Mapping System. 213 The MS/MRs can be co-located with the border-xTRs of the site-overlay 214 When a Border xTR services more than one site-overlay, and the MS/MRs 215 are instantiated on the Border xTR, logical instances of MS/MRs must 216 be dedicated to each site-overlay. 218 This specification defines the interaction between the Mapping 219 Systems of the site-overlays and the uberlay to deliver a multi- 220 overlay hierarchical network. The forwarding procedures relevant to 221 the border xTRs are also specified. Figure 1 illustrates the multi- 222 overlay network. 224 +-------------------------------+ 225 | +-----+ +-----+ +-----+ | 226 | | xTR | | xTR | | xTR | | 227 | +-----+ +-----+ +-----+ | 228 | | 229 | +-------+ | RLOC space 1 230 | Site Overlay 1 | MS/MR | | (underlay 1) 231 | +-------+ | 232 | | 233 | | 234 | +--------+ +--------+ | 235 +-----| Border |--| Border |----+ 236 +-----| xTR |--| xTR |----+ 237 | +--------+ +--------+ | 238 | | 239 | | 240 | | 241 | +-------+ | Uberlay 242 | Uberlay | MS/MR | | RLOC Space 243 | +-------+ | (Transit Underlay) 244 | | 245 | | 246 | +----------+ | 247 +---------| Border |----------+ 248 +---------| xTR |----------+ 249 | +----------+ | 250 | | 251 | +-------+ | RLOC space 2 252 | Site Overlay 2 | MS/MR | | (underlay 2) 253 | +-------+ | 254 | | 255 | +-----+ +-----+ +-----+ | 256 | | xTR | | xTR | | xTR | | 257 | +-----+ +-----+ +-----+ | 258 +-------------------------------+ 260 Figure 1. Site-overlays connected via Uberlay 262 Structuring the LISP network as multiple site-overlays interconnected 263 by an uberlay delivers the following benefits: 265 o Enable the interworking of diverse site-overlay implementations in 266 which different mapping systems and encapsulations may be used. 268 o Enhanced resiliency through regional failure survivability. 269 Failures in one site-overlay or failures in a portion of the 270 underlay should not affect other site-overlays. 272 o Reduce the state of the site-overlay control plane. The site- 273 overlay control plane will only maintain state for EIDs that are 274 connected to xTRs within the site-overlay These EIDs are referred 275 to as local site-overlay EIDs in this specification. Remote site- 276 overlay EIDs will not be explicitly registered within the site- 277 overlay. 279 o Separate the RLOC space of the different site-overlays as well as 280 the uberlay RLOC space. Each site-overlay will only need 281 reachability to its own RLOCs, making the RLOCs private to the 282 site-overlay Similarly, the uberlay RLOC space does not require 283 knowledge of site-overlay specific RLOCs. This simplifies the 284 underlay routing protocol structure and reduces the state that 285 must be handled and maintained by the underlay routing protocols. 287 o Reduced latency for local site-overlay EID registrations may be 288 achieved when xTRs and Map Servers are topologically close. 289 Topological proximity is expected when the RLOC spaces for the 290 different overlays are kept separate. 292 o Reduced latency for local site-overlay EID lookups may be achieved 293 when xTRs, Map Resolvers and Map Servers are topologically close. 294 Topological proximity is expected when the RLOC spaces for the 295 different overlays are kept separate. 297 o Creates a multicast replication hierarchy where the Border RTRs 298 serve as the points of multicast replication for multicast traffic 299 that spans multiple site-overlays. 301 o Creates a distributed structure of RTRs that can be leveraged for 302 the deployment of NAT traversal in the RLOC space. 304 4. General Procedures 306 A site-overlay maintains state only for its local site-overlay EIDs 307 and RLOCs. Tunnels never cross site-overlay or uberlay boundaries. 308 Remote site-overlay EIDs are reachable at the source site-overlay via 309 a default mapping which will steer all traffic destined to remote 310 site-overlay EIDs to the border xTRs where it can be handed off to 311 the uberlay. The uberlay maintains state for the EIDs of all 312 interconnected site-overlays and will steer traffic from the source 313 site-overlay to the destination site-overlay by encapsulating the 314 traffic from the source site-overlay border xTR to the destination 315 site-overlay border xTR. Thus, forwarding is achieved by 316 concatenating overlays and doing Re-encapsulation at the border xTRs 317 to forward the traffic from the Ingress site-overlay to the Egress 318 site-overlay via the Uberlay. 320 Inter-site communication is achieved by encapsulating traffic 321 destined to remote site-overlay EIDs to the border xTRs following the 322 mapping registered for the default EID-prefix, rather than having to 323 maintain state for remote site-overlay EIDs. Traffic will be 324 decapsulated at the border xTRs and a lookup in the uberlay mapping 325 system will determine the site-overlay to which traffic is to be re- 326 encapsulated. The lookup should return the uberlay RLOCs for the 327 border xTRs of the site-overlay where the destination EID is located. 328 At the border xTR of the destination site, traffic will be de- 329 capsulated, a lookup in the local destination site-overlay Mapping 330 System will take place and traffic will be re-encapsulated to the xTR 331 that connects to the destination EID. 333 Traffic for non-LISP sites, or for EIDs not registered in any site- 334 overlay, will also be forwarded to the border xTR where it will be 335 forwarded or dropped as appropriate. 337 4.1. Control Plane Procedures 339 Local EIDs must be registered by the xTRs into the local Mapping 340 System of the site-overlay. Intra-site communication follows the 341 standard procedures of registration, resolution, caching and 342 encapsulation defined in [I-D.ietf-lisp-rfc6830bis] and 343 [I-D.ietf-lisp-rfc6833bis] amongst the xTRs within the local site- 344 overlay. 346 The border xTRs at a site-overlay should have a local site-overlay 347 RLOC-set and will also have an uberlay RLOC-set. The local site- 348 overlay RLOC-set is in the private site-overlay RLOC space and is 349 used by the border xTRs as the RLOC set for any mappings it may 350 register with the site-overlay Mapping System. The uberlay RLOC-set 351 for the border-xTRs of a particular site-overlay are the RLOCs to 352 reach the site-overlay in the uberlay RLOC space. The border xTR 353 will use the uberlay RLOC-set in any mappings it may register with 354 the uberlay Mapping System. It is possible for a deployment to 355 connect the RLOC spaces of the site-overlays and the uberlay, it is 356 also possible in the scenario of a common RLOC space for the uberlay 357 and local site-overlay RLOC sets to be one and the same. Any 358 implementation of this specification should support disjoint RLOC 359 spaces or joint RLOC spaces. 361 The border xTRs must register a default EID-prefix as specified in 362 Section 4.3 with the local site-overlay Mapping System. Remote EIDs 363 will be generally reachable by xTRs in a site-overlay using the 364 default EID mapping registered by the border xTRs. This is expected 365 to be the mapping used for most communications to remote site-overlay 366 EIDs. Remote site-overlay EIDs may be registered with the local 367 site-overlay Mapping System for the purposes of supporting inter- 368 overlay EID mobility as specified in Section 6, these mappings will 369 be preferred over the default EID mapping whenever present. 371 Local EIDs registered with the site-overlay mapping system must also 372 be registered with the Uberlay Mapping System. The registration of 373 the local site-overlay EIDs with the uberlay Mapping System is 374 originated by the Border xTRs. The local site-overlay EIDs SHOULD be 375 aggregated into the shortest covering prefix possible before being 376 registered with the uberlay Mapping System. How this aggregation is 377 achieved is implementation specific. 379 In order to be able to register the local site-overlay EIDs with the 380 uberlay Mapping System, the border xTRs must subscribe to all EIDs 381 registered in their local site-overlay Mapping System. This is a 382 subscription to 0.0.0.0/0 (or 0::/0) with the N-bit set as specified 383 in [I-D.ietf-lisp-pubsub]. The subscription populates all local 384 site-overlay EID mappings in the map-cache of the border xTRs. 386 Once received through the subscription, the local site-overlay EIDs 387 in the map-cache at the border xTRs must be registered by the border 388 xTRs with the uberlay Mapping System. The local site-overlay EIDs 389 will be registered using the 'uberlay' RLOC-set for the registering 390 border xTR. 392 Following [I-D.ietf-lisp-eid-mobility], the border xTRs will also 393 subscribe to any EID prefixes it registers with the uberlay Mapping 394 System. This allows the border xTRs to get Map Notify messages from 395 the uberlay Mapping System for EID prefixes that may move from their 396 local site-overlay to a remote site-overlay. 398 4.1.1. Split-horizon at the Border xTRs 400 Remote site-overlay EIDs may be learnt at a border xTR due to 401 resolution of a remote destination EID or due to a mobility event as 402 specified in Section 6. Remote site-overlay EIDs learnt from the 403 uberlay will be installed in the map-cache of the border xTR with the 404 corresponding remote uberlay RLOC-set for the remote border xTR. 405 When these remote site-overlay EIDs are learnt as a consequence of 406 the map-notify messages defined in the Inter-overlay mobility 407 procedures in Section 6, the EIDs will also be registered with the 408 local site-overlay mapping system using the local site-overlay RLOC- 409 set for the border-xTR. The remote site-overlay EIDs registered with 410 the local site-overlay mapping system will be learnt back at the 411 border xTR because of the border xTR's subscription to all local 412 site-overlay EIDs. This can cause the mapping for the remote EID 413 that is installed in the border xTR map-cache to flip flop between 414 the uberlay RLOC-set and the local site-overlay RLOC-set. 416 In order to avoid this flip flopping a split horizon procedure must 417 be implemented. When a mapping received at the border xTR (as part 418 of its subscription to all local site-overlay EID prefixes) has the 419 local site-overlay RLOC-set for the border xTR, the mapping received 420 in the subscription corresponds to a remote site-overlay EID and 421 should be ignored by the border xTR. The mapping should not be 422 installed in the map-cache of the border xTR and the EIDs in the 423 mapping should not be advertised to the uberlay. More robust split 424 horizon mechanisms can be proposed in future revisions of this 425 specification. 427 4.2. Resolution and Forwarding Procedures 429 Intra-site communication follows the standard procedures of 430 registration, resolution, caching and encapsulation defined in 431 [I-D.ietf-lisp-rfc6830bis] and [I-D.ietf-lisp-rfc6833bis] amongst the 432 xTRs within the local site-overlay. 434 Inter-site communication is achieved by encapsulating traffic 435 destined to remote site-overlay EIDs from the xTRs to the border 436 xTRs. Traffic will be decapsulated at the border xTRs and a lookup 437 in the uberlay mapping system will determine the site-overlay to 438 which traffic is to be re-encapsulated. The lookup should return the 439 uberlay RLOCs for the border xTRs of the site-overlay where the 440 destination EID is located. At the border xTR of the destination 441 overlay-site, traffic will be de-capsulated, and re-encapsulated to 442 the destination xTR, just like an RTR does. The border xTR already 443 has the destination EID in its cache per its subscription to all 444 local site-overlay EIDs. 446 When receiving encapsulated traffic, a border xTR will de-capsulate 447 the traffic and will do a lookup for the destination EID in its map 448 cache. If the destination EID is present in the map cache, the 449 traffic is forwarded and no lookup takes place. If the destination 450 EID is not present in the cache, the destination EID is not in any 451 local site-overlay connected to the border xTR, in which case the 452 border xTR will issue a map-request to all Uberlay Mapping Systems it 453 is connected to. The criteria to determine which Mapping Systems are 454 Uberlay Mapping Systems is simply to select those Mapping Systems 455 with which the border xTR doesn't hold a subscription to 0.0.0.0/0 456 (or 0::/0). 458 4.2.1. Multi-overlay requests at border xTR 460 Border xTRs may query all Mapping Systems in all uberlays it 461 participates in. The border xTR will then chose based on longest 462 prefix match the more specific EID mapping provided by any of the 463 Mapping Systems. This procedure could also include site-overlay 464 Mapping Systems, however those are not expected to be queried as the 465 border xTR subscribes to all EIDs in the site-overlays and the 466 presence of the mappings in the cache will prevent any lookups. The 467 processing of Map Requests following the multi-domain request logic 468 works as follows: 470 1. The Border xTR sends a map request for the prefix that it intends 471 to resolve to each of the Mapping Systems it participates in. 473 2. The Border xTR receives Map Replies from each of the different 474 Mapping Systems it sent requests to. The Border xTR will treat 475 the replies differently depending on their contents: 477 * Negative Map Replies are ignored and discarded unless all Map 478 Replies are Negative, then the border xTR follows the 479 procedures specified in [RFC6833] for Negative Map Replies. 481 * Map Replies with RLOCs that belong to the requesting border 482 xTR are ignored. 484 * Map Replies with EID prefixes that are not already in the map 485 cache of the border xTR are accepted and cached. 487 * If the prefix already exists in the cache/routing table and 488 the source of the prefix is another reply from the multi- 489 domain request, the RLOCs received in the mapping are added to 490 the RLOC set cached for the prefix. 492 When following these rules when processing multi-domain requests, the 493 Border xTR guarantees proper discovery and use of destination 494 prefixes, that will be associated with their corresponding overlay 495 fabric. By ignoring the negative replies the procedure works 496 regardless of whether the Mapping Systems of multiple fabrics have 497 consistent configurations or operate individually without being aware 498 of the whole addressing space in the overlay fabric. 500 4.3. Default EID registration and treatment 502 Border xTRs will register a mapping to be used as a default mapping 503 to handle the forwarding of traffic destined to any EIDs that are not 504 explicitly registered. These mappings will be registered in the 505 local site-overlay Mapping System of each site-overlay. The RLOCs 506 for the mappings will be the site-overlay RLOCs of the border xTR. 507 This registration is intended to instruct the Mapping System to 508 follow the procedures in [RFC6833] for Negative Map Replies and 509 calculate the broadest non-registered EID prefix that includes the 510 requested destination EID and issue a map-reply with the calculated 511 EID and the RLOCs registered by the border xTRs. The map-reply may 512 have a shorter TTL to accommodate any changes in the registrations. 514 The instruction to the Mapping System can be encoded as the 515 registration of a 0.0.0.0/0 (or 0::/0) EID or it can be encoded as 516 the registration of an agreed upon distinguished name such as 517 "Default". In either case, the registration will contain the RLOC 518 set desired for the default handling. 520 5. Multicast Specific Procedures 522 This specification will focus on the procedures necessary to extend 523 signal-free multicast [RFC8378] across multiple site-overlays 524 interconnected with an uberlay. The specification will focus on the 525 extensions of the Sender and Receiver site procedures 527 5.1. Inter-site-overlay Control Plane Procedures for Signal-free 528 multicast 530 1. At the listener sites, xTRs with multicast listeners will follow 531 the receiver site procedures described in [RFC8378]. A 532 replication list will be built and registered on the site-overlay 533 Mapping System for the multicast channel being joined by the 534 listeners. 536 2. The Mapping System for the listener site-overlay will send Map- 537 Notify messages towards the multicast source or RP per [RFC8378]. 538 The multicast source or RP is reachable via the border-xTRs of 539 the listener site-overlay via the default EID mapping registered 540 in the listener site-overlay. 542 3. Upon reception of the Map-Notify in the previous step, the 543 listener site-overlay border-xTR will register the multicast EID 544 with the uberlay Mapping System using the uberlay RLOCs for its 545 site-overlay as the RLOC set for the mapping being registered. 546 Only one of the RLOCs in the set should be active in the 547 registration per the procedures in [RFC8378]. A replication tree 548 is built in the uberlay as specified in [RFC8378]. 550 4. After the listener site-overlay border-xTR registers the 551 multicast EID with the uberlay Mapping system, the uberlay MS 552 will send a Map-Notify toward the multicast source per [RFC8378] 554 5. Upon reception of the Map-Notify in the previous step, the border 555 xTR at the source site-overlay registers its interest in the 556 multicast EID with the source site-overlay Mapping System 557 following the procedures described in [RFC8378]. 559 5.2. Border xTR Resolution and Forwarding procedures for Signal-free 560 multicast 562 The mapping resolution procedures for multicast EIDs at border xTRs 563 fall within the scope of the mechanisms specified in Section 4. The 564 Map-replies obtained from the lookup will follow the behavior 565 specified in [RFC8378] for signal-free multicast. 567 Forwarding will also follow the General Procedures specified in 568 Section 4 without alteration. It is worth noting that the 569 concatenation of overlays between listener sites, uberlay and sender 570 site-overlays creates a convenient replication structure where the 571 border xTRs act as the replication points to form an optimized end- 572 to-end multi-level replication tree [Ref to Replication Engineering 573 draft]. 575 6. Inter site-overlay Mobility Procedures 577 The receiver and sender site procedures defined in 578 [I-D.ietf-lisp-eid-mobility] apply without change to each site- 579 overlay and to the uberlay. Border xTRs are connected to two or more 580 overlay networks which are following the mobility procedures. An 581 away table is defined at the border xTR for each overlay network it 582 participates in. In order to illustrate the procedures required, 583 this specification describes a scenario where a border xTR has one 584 local site-overlay away table and one uberlay facing away table. The 585 procedures for mobility described in this section are extensible to 586 border xTRs participating in more than two overlays. 588 When a map notify for an EID is received at an xTR, an away entry is 589 created on the receiving side table. Any away entries for the 590 specific EID in other tables on the same LISP node (xTR or RTR) must 591 be removed. This general rule addresses convergence necessary for a 592 first move as well as any subsequent moves (moves that take place 593 after the away tables are already populated with entries for the 594 moving EID due to previous moves). 596 The following set of procedures highlights any additions to the 597 mobility procedures defined in [I-D.ietf-lisp-eid-mobility]: 599 1. Detect the roaming EID per the mechanisms described in 600 [I-D.ietf-lisp-eid-mobility] and register the EID with the site- 601 overlay Mapping System at the landing site-overlay 603 2. The site-overlay Mapping System at the landing site-overlay must 604 send a Map-Notify to the last registrant xTR (if it is local to 605 the site-overlay) and to the border xTR as the border xTR 606 subscribes to all EIDs in the site-overlay. 608 3. The border xTR will install an entry for the moved host in the 609 local away table of the border xTR. 611 4. The border xTR from the landing site-overlay will register the 612 roaming EID with the uberlay Mapping System using the uberlay 613 RLOC-set for the landing site-overlay 615 5. The Uberlay Map Server will send Map-Notify messages to the 616 border xTRs at the departure site-overlay as specified in 617 [I-D.ietf-lisp-eid-mobility] (border xTR with the previously 618 registered RLOCs). 620 6. Upon reception of the Map-Notify, the border xTR must check if 621 the Map-Notify is for an EID-prefix that is covered by a broader 622 or equal EID-prefix that is locally registered. Local 623 registration is determined by the presence of the broader or 624 equal EID prefix in the map-cache of the border xTR. 626 7. If the roaming EID-prefix received in the Map-Notify is not 627 covered under a previously registered EID-prefix in the local 628 site-overlay, the EID-prefix is a newly registered prefix and no 629 further action is required. 631 8. If the roaming EID-prefix received in the Map-Notify is covered 632 under a registered EID-prefix, the Map-Notify is due to a move 633 event. In this case, the site-overlay border xTR must register 634 the roaming EID prefix in the site-overlay mapping system using 635 the site-overlay facing RLOC-set of the border-xTRs. The 636 roaming EID-prefix must also be installed in the uberlay facing 637 away table of the border xTR at the departure site-overlay. 639 9. The departure site-overlay Map-Server will send Map-Notify 640 messages to the xTRs at the departure site-overlay as specified 641 in [I-D.ietf-lisp-eid-mobility] (edge xTRs with the previously 642 registered RLOCs). 644 10. When the site-overlay xTR at the departure site-overlay receives 645 the Map-Notify from the border xTR, it will include the EID 646 prefix received in the Map-Notify in its away table per the 647 procedures described in [I-D.ietf-lisp-eid-mobility]. 649 11. Data triggered Solicit Map Requests (SMRs) will be initiated in 650 the different site-overlays and the uberlay as traffic matches 651 the different away tables. As specified in 652 [I-D.ietf-lisp-eid-mobility], these SMRs notify the different 653 ITRs involved in communications with the roaming EID that they 654 must issue a new Map-Request to the mapping system to renew 655 their mappings for the roaming EID. 657 7. Virtual Private Network (VPN) Considerations 659 When supporting multiple Instance IDs as specified in 660 [I-D.ietf-lisp-vpn] the Instance IDs range is divided in two sets. A 661 reuse-set that can be used in each site-overlay and a global-set used 662 across site-overlays and the uberlay. 664 Instance-IDs that are local to a site-overlay should only provide 665 intra-overlay connectivity and are in the site-overlay mapping system 666 only for VPN use for the xTRs in the site-overlay. When the VPN 667 reaches across site-overlays, then the global-set instance-IDs are in 668 the uberlay mapping system as well as each site-overlay mapping 669 system where the VPN members exist. 671 8. IANA Considerations 673 This document has no IANA implications 675 9. Acknowledgements 677 The authors want to thank Kedar Karamarkar, Prakash Jain and Vina 678 Ermagan for their insightful contribution to shaping the ideas in 679 this document. We would also like to acknowledge the valuable input 680 from the workgroup chairs Joel Halpern and Luigi Iannone in refining 681 the objectives of the document. 683 10. References 685 10.1. Normative References 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, 689 DOI 10.17487/RFC2119, March 1997, 690 . 692 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 693 Discovery Protocol (MSDP)", RFC 3618, 694 DOI 10.17487/RFC3618, October 2003, 695 . 697 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 698 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 699 Protocol Specification (Revised)", RFC 4601, 700 DOI 10.17487/RFC4601, August 2006, 701 . 703 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 704 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 705 . 707 10.2. Informative References 709 [I-D.farinacci-lisp-decent] 710 Farinacci, D. and C. Cantrell, "A Decent LISP Mapping 711 System (LISP-Decent)", draft-farinacci-lisp-decent-03 712 (work in progress), March 2019. 714 [I-D.ietf-lisp-eid-mobility] 715 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 716 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 717 Unified Control Plane", draft-ietf-lisp-eid-mobility-02 718 (work in progress), May 2018. 720 [I-D.ietf-lisp-pubsub] 721 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 722 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 723 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 724 Subscribe Functionality for LISP", draft-ietf-lisp- 725 pubsub-02 (work in progress), November 2018. 727 [I-D.ietf-lisp-rfc6830bis] 728 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 729 Cabellos-Aparicio, "The Locator/ID Separation Protocol 730 (LISP)", draft-ietf-lisp-rfc6830bis-25 (work in progress), 731 October 2018. 733 [I-D.ietf-lisp-rfc6833bis] 734 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 735 "Locator/ID Separation Protocol (LISP) Control-Plane", 736 draft-ietf-lisp-rfc6833bis-19 (work in progress), October 737 2018. 739 [I-D.ietf-lisp-vpn] 740 Moreno, V. and D. Farinacci, "LISP Virtual Private 741 Networks (VPNs)", draft-ietf-lisp-vpn-02 (work in 742 progress), May 2018. 744 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 745 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 746 October 2011, . 748 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 749 Locator/ID Separation Protocol (LISP)", RFC 6830, 750 DOI 10.17487/RFC6830, January 2013, 751 . 753 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 754 Locator/ID Separation Protocol (LISP) for Multicast 755 Environments", RFC 6831, DOI 10.17487/RFC6831, January 756 2013, . 758 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 759 Protocol (LISP) Map-Server Interface", RFC 6833, 760 DOI 10.17487/RFC6833, January 2013, 761 . 763 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 764 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 765 eXtensible Local Area Network (VXLAN): A Framework for 766 Overlaying Virtualized Layer 2 Networks over Layer 3 767 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 768 . 770 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 771 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 772 February 2017, . 774 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 775 (LISP) Data-Plane Confidentiality", RFC 8061, 776 DOI 10.17487/RFC8061, February 2017, 777 . 779 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 780 Smirnov, "Locator/ID Separation Protocol Delegated 781 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 782 May 2017, . 784 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 785 Separation Protocol (LISP) Multicast", RFC 8378, 786 DOI 10.17487/RFC8378, May 2018, 787 . 789 Authors' Addresses 791 Victor Moreno 792 Cisco Systems 793 170 Tasman Drive 794 San Jose, California 95134 795 USA 797 Email: vimoreno@cisco.com 799 Dino Farinacci 800 lispers.net 801 San Jose, CA 95120 802 USA 804 Email: farinacci@gmail.com 806 Alberto Rodriguez-Natal 807 Cisco Systems 808 170 Tasman Drive 809 San Jose, California 95134 810 USA 812 Email: natal@cisco.com 814 Marc Portoles-Comeras 815 Cisco Systems 816 170 Tasman Drive 817 San Jose, California 95134 818 USA 820 Email: mportole@cisco.com 822 Fabio Maino 823 Cisco Systems 824 170 Tasman Drive 825 San Jose, California 95134 826 USA 828 Email: fmaino@cisco.com 829 Sanjay Hooda 830 Cisco Systems 831 170 Tasman Drive 832 San Jose, California 95134 833 USA 835 Email: shooda@cisco.com 837 Satish Kondalam 838 Cisco Systems 839 170 West Tasman Drive 840 San Jose, California 95134 841 USA 843 Email: skondala@cisco.com