idnits 2.17.1 draft-moreno-lisp-uberlay-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (November 4, 2018) is 1993 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3618' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'RFC4601' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'RFC4607' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'RFC6407' is defined on line 728, but no explicit reference was found in the text == Unused Reference: 'RFC6831' is defined on line 737, but no explicit reference was found in the text == Unused Reference: 'RFC7348' is defined on line 747, but no explicit reference was found in the text == Unused Reference: 'RFC8060' is defined on line 754, but no explicit reference was found in the text == Unused Reference: 'RFC8061' is defined on line 758, but no explicit reference was found in the text == Unused Reference: 'RFC8111' is defined on line 763, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == 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 (~~), 15 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: May 8, 2019 lispers.net 6 A. Rodriguez-Natal 7 M. Portoles-Comeras 8 F. Maino 9 S. Hooda 10 S. Kondalam 11 Cisco Systems 12 November 4, 2018 14 Uberlay Interconnection of Multiple LISP overlays 15 draft-moreno-lisp-uberlay-00 17 Abstract 19 This document describes the use of the Locator/ID Separation Protocol 20 (LISP) to create multiple independent and survivable network overlays 21 that are interconnected by a transit overlay. The transit overlay is 22 referred to as the "uberlay" and provides connectivity and control 23 plane abstraction between overlays. Structuring the network into 24 multiple network overlays allows each overlay to scale independently. 25 The different network overlays are autonomous from a control and data 26 plane perspective to enable failure survivability across overlays. 27 The hierarchical structure of the multi-overlay network 28 interconnected by an uberlay provides optimizations to the forwarding 29 of unicast traffic as well as the replication of multicast traffic in 30 both the overlay and underlay. This document specifies the 31 mechanisms and procedures for the distribution of control plane 32 information across overlay sites and in the uberlay as well as the 33 lookup and forwarding procedures for unicast and multicast traffic 34 within and across overlays. The specification also defines the 35 procedures to support inter-overlay mobility of EIDs and their 36 integration with the intra-overlay EID mobility procedures defined in 37 draft-ietf-lisp-eid-mobility. 39 Requirements Language 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in [RFC2119]. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on May 8, 2019. 62 Copyright Notice 64 Copyright (c) 2018 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (https://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 81 3. Interconnecting multiple LISP site-overlays via the Uberlay . 4 82 4. General Procedures . . . . . . . . . . . . . . . . . . . . . 7 83 4.1. Control Plane Procedures . . . . . . . . . . . . . . . . 8 84 4.1.1. Split-horizon at the Border xTRs . . . . . . . . . . 9 85 4.2. Resolution and Forwarding Procedures . . . . . . . . . . 10 86 4.2.1. Multi-overlay requests at border xTR . . . . . . . . 10 87 4.3. Default EID registration and treatment . . . . . . . . . 11 88 5. Multicast Specific Procedures . . . . . . . . . . . . . . . . 12 89 5.1. Inter-site-overlay Control Plane Procedures for Signal- 90 free multicast . . . . . . . . . . . . . . . . . . . . . 12 91 5.2. Border xTR Resolution and Forwarding procedures for 92 Signal-free multicast . . . . . . . . . . . . . . . . . . 13 94 6. Inter site-overlay Mobility Procedures . . . . . . . . . . . 13 95 7. Virtual Private Network (VPN) Considerations . . . . . . . . 15 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 100 10.2. Informative References . . . . . . . . . . . . . . . . . 16 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 103 1. Introduction 105 In order to improve scale, enhance resiliency, provide regional 106 failure survivability, and provide fault isolation, a LISP network 107 may be structured as a collection of site-overlays interconnected by 108 a transit area. Each site-overlay is a fully functional overlay 109 network and has its own set of Map Servers and Map Resolvers. Site- 110 overlays share a border xTR with a transit area. Connectivity 111 between site-overlays is provided via the transit area which we will 112 refer to as "The Uberlay". This specification describes the Control 113 Plane and Forwarding procedures for the implementation of an Uberlay 114 connected multi-overlay LISP network. 116 2. Definition of Terms 118 LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel 119 Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map- 120 Resolver (MR) are defined in the LISP specification [RFC6830]. 122 Terms defining interactions with the LISP Mapping System are defined 123 in [RFC6833]. 125 Terms related to the procedures for signal free multicast are defined 126 in [RFC8378]. 128 The following terms are here defined to facilitate the descriptions 129 and discussions within this particular document. 131 Site-Overlay - Overlay network at a specific area or domain. This 132 overlay network has a dedicated Mapping System. 134 Border-xTR - xTR that connects a site-overlay to one or more 135 uberlays. 137 xTR - LISP Tunnel Router as defined in [RFC6833]. An xTR connects 138 end-points to the site-overlay. 140 Local Mapping System - Mapping system of the site-overlay 141 Uberlay - Overlay network that interconnects different site-overlays 142 to each other. The Uberlay has a dedicated Mapping System and 143 creates an overlay amongst the border xTRs which connect different 144 site-overlays. 146 Uberlay Mapping System - Autonomous mapping system dedicated to the 147 uberlay. 149 Site-Overlay EIDs - Also referred to as local site-overlay EIDs, 150 these are the EIDs that are connected to xTRs in a particular site- 151 overlay and are registered in their own local site-overlay mapping 152 system. These EIDs will also be registered in the uberlay but not in 153 the remote site-overlay mapping systems. 155 Remote site-overlay EIDs - These are EIDs connected and registered in 156 site-overlays other than the local site-overlay. 158 Local site-overlay EIDs - These are EIDs connected and registered in 159 the local site-overlay. 161 3. Interconnecting multiple LISP site-overlays via the Uberlay 163 A LISP network can be structured as a collection of LISP site- 164 overlays that are interconnected by one or more LISP Uberlays. 166 A LISP site-overlay is an overlay network that has its own set of 167 xTRs, its own dedicated Mapping System and it may have a dedicated 168 RLOC space, separate from that of other site-overlays or the uberlay. 169 A LISP uberlay is also an overlay network with its own set of xTRs, 170 its own dedicated Mapping System and it may have its own dedicated 171 RLOC space. When the RLOC spaces are dedicated, RLOC routes in the 172 local underlay do not leak across to the underlay of other site- 173 overlays. 175 A site-overlay will have xTRs and Border xTRs. The xTRs provide 176 connectivity to the local site-overlay EIDs, which are the EIDs that 177 are locally connected to the overlay-site. The Border xTRs are Re- 178 encapsulating Tunnel Routers (RTRs) that connect the site-overlays to 179 the LISP Uberlay in the transit network. xTRs participate in one 180 site-overlay and one site-overlay only. Border xTRs participate in 181 the mapping system of the site-overlay it resides in and the mapping 182 system of the uberlay it connects the site-overlay to. Border xTRs 183 may be shared by more than one site-overlay. 185 The different site-overlays can be interconnected by an uberlay. The 186 uberlay consists of a dedicated Mapping System and the set of Border 187 xTRs that connect the participating site-overlays to the Uberlay and 188 the Uberlay Mapping System. 190 It is assumed that a single uberlay is used to connect any site- 191 overlays that are part of the same global network. Multiple paths 192 may be realized in the underlay by standard routing procedures, but 193 the uberlay remains a single instance. No provisions are made for 194 multiple uberlays and any multi-path routing calculation that may be 195 required in the overlay to support such an environment. In addition, 196 any communication between site-overlays must happen via the uberlay, 197 which may include a border xTR that is shared by the site-overlays 198 communicating. Multiple adminstrative entities may remain in control 199 of different site-overlays, but the uberlay remains a single overlay 200 servicing the multiple site-overlays connecting to it. 202 Each site-overlay will have its own set of Map Servers and Map 203 Resolvers (MS/MRs) which operate as an autonomous Mapping System. 204 The Uberlay Mapping System is also autonomous and includes all 205 necessary Map Servers and Map Resolvers. Any of the Mapping Systems, 206 in site-overlays or in the Uberlay, follow the control plane 207 specification in [RFC6833] and may be structured as a Distributed 208 Delegation Tree (DDT) per [RFC8111]for the purposes of horizontal 209 scaling or other optimizations within each Mapping System. 211 The MS/MRs can be co-located with the border-xTRs of the site-overlay 212 When a Border xTR services more than one site-overlay, and the MS/MRs 213 are instantiated on the Border xTR, logical instances of MS/MRs must 214 be dedicated to each site-overlay. 216 This specification defines the interaction between the Mapping 217 Systems of the site-overlays and the uberlay to deliver a multi- 218 overlay hierarchical network. The forwarding procedures relevant to 219 the border xTRs are also specified. Figure 1 illustrates the multi- 220 overlay network. 222 +-------------------------------+ 223 | +-----+ +-----+ +-----+ | 224 | | xTR | | xTR | | xTR | | 225 | +-----+ +-----+ +-----+ | 226 | | 227 | +-------+ | RLOC space 1 228 | Site Overlay 1 | MS/MR | | (underlay 1) 229 | +-------+ | 230 | | 231 | | 232 | +--------+ +--------+ | 233 +-----| Border |--| Border |----+ 234 +-----| xTR |--| xTR |----+ 235 | +--------+ +--------+ | 236 | | 237 | | 238 | | 239 | +-------+ | Uberlay 240 | Uberlay | MS/MR | | RLOC Space 241 | +-------+ | (Transit Underlay) 242 | | 243 | | 244 | +----------+ | 245 +---------| Border |----------+ 246 +---------| xTR |----------+ 247 | +----------+ | 248 | | 249 | +-------+ | RLOC space 2 250 | Site Overlay 2 | MS/MR | | (underlay 2) 251 | +-------+ | 252 | | 253 | +-----+ +-----+ +-----+ | 254 | | xTR | | xTR | | xTR | | 255 | +-----+ +-----+ +-----+ | 256 +-------------------------------+ 258 Figure 1. Site-overlays connected via Uberlay 260 Structuring the LISP network as multiple site-overlays interconnected 261 by an uberlay delivers the following benefits: 263 o Horizontally scale the LISP Mapping System by segmenting it into 264 smaller independent Mapping Systems at each site-overlay. 266 o Enhanced resiliency through regional failure survivability. 267 Failures in one site-overlay or failures in a portion of the 268 underlay should not affect other site-overlays. 270 o Reduce the state of the site-overlay control plane. The site- 271 overlay control plane will only maintain state for EIDs that are 272 connected to xTRs within the site-overlay These EIDs are referred 273 to as local site-overlay EIDs in this specification. Remote site- 274 overlay EIDs will not be explicitly registered within the site- 275 overlay. 277 o Separate the RLOC space of the different site-overlays as well as 278 the uberlay RLOC space. Each site-overlay will only need 279 reachability to its own RLOCs, making the RLOCs private to the 280 site-overlay Similarly, the uberlay RLOC space does not require 281 knowledge of site-overlay specific RLOCs. This simplifies the 282 underlay routing protocol structure and reduces the state that 283 must be handled and maintained by the underlay routing protocols. 285 o Reduced latency for local site-overlay EID registrations may be 286 achieved when xTRs and Map Servers are topologically close. 287 Topological proximity is expected when the RLOC spaces for the 288 different overlays are kept separate. 290 o Reduced latency for local site-overlay EID lookups may be achieved 291 when xTRs, Map Resolvers and Map Servers are topologically close. 292 Topological proximity is expected when the RLOC spaces for the 293 different overlays are kept separate. 295 o Creates a multicast replication hierarchy where the Border RTRs 296 serve as the points of multicast replication for multicast traffic 297 that spans multiple site-overlays. 299 4. General Procedures 301 A site-overlay maintains state only for its local site-overlay EIDs 302 and RLOCs. Tunnels never cross site-overlay or uberlay boundaries. 303 Remote site-overlay EIDs are reachable at the source site-overlay via 304 a default mapping which will steer all traffic destined to remote 305 site-overlay EIDs to the border xTRs where it can be handed off to 306 the uberlay. The uberlay maintains state for the EIDs of all 307 interconnected site-overlays and will steer traffic from the source 308 site-overlay to the destination site-overlay by encapsulating the 309 traffic from the source site-overlay border xTR to the destination 310 site-overlay border xTR. Thus, forwarding is achieved by 311 concatenating overlays and doing Re-encapsulation at the border xTRs 312 to forward the traffic from the Ingress site-overlay to the Egress 313 site-overlay via the Uberlay. 315 Inter-site communication is achieved by encapsulating traffic 316 destined to remote site-overlay EIDs. to the border xTRs following 317 the mapping registered for the default EID-prefix, rather than having 318 to maintain state for remote site-overlay EIDs. Traffic will be 319 decapsulated at the border xTRs and a lookup in the uberlay mapping 320 system will determine the site-overlay to which traffic is to be re- 321 encapsulated. The lookup should return the uberlay RLOCs for the 322 border xTRs of the site-overlay where the destination EID is located. 323 At the border xTR of the destination site, traffic will be de- 324 capsulated, a lookup in the local destination site-overlay Mapping 325 System will take place and traffic will be re-encapsulated to the xTR 326 that connects to the destination EID. 328 Traffic for non-LISP sites, or for EIDs not registered in any site- 329 overlay, will also be forwarded to the border xTR where it will be 330 forwarded or dropped as appropriate. 332 4.1. Control Plane Procedures 334 Local EIDs must be registered by the xTRs into the local Mapping 335 System of the site-overlay. Intra-site communication follows the 336 standard procedures of registration, resolution, caching and 337 encapsulation defined in [I-D.ietf-lisp-rfc6830bis] and 338 [I-D.ietf-lisp-rfc6833bis] amongst the xTRs within the local site- 339 overlay. 341 The border xTRs at a site-overlay should have a local site-overlay 342 RLOC-set and will also have an uberlay RLOC-set. The local site- 343 overlay RLOC-set is in the private site-overlay RLOC space and is 344 used by the border xTRs as the RLOC set for any mappings it may 345 register with the site-overlay Mapping System. The uberlay RLOC-set 346 for the border-xTRs of a particular site-overlay are the RLOCs to 347 reach the site-overlay in the uberlay RLOC space. The border xTR 348 will use the uberlay RLOC-set in any mappings it may register with 349 the uberlay Mapping System. It is possible for a deployment to 350 connect the RLOC spaces of the site-overlays and the uberlay, it is 351 also possible in the scenario of a common RLOC space for the uberlay 352 and local site-overlay RLOC sets to be one and the same. Any 353 implementation of this specification should support disjoint RLOC 354 spaces or joint RLOC spaces. 356 The border xTRs must register a default EID-prefix as specified in 357 Section 4.3 with the local site-overlay Mapping System. Remote EIDs 358 will be generally reachable by xTRs in a site-overlay using the 359 default EID mapping registered by the border xTRs. This is expected 360 to be the mapping used for most communications to remote site-overlay 361 EIDs. Remote site-overlay EIDs may be registered with the local 362 site-overlay Mapping System for the purposes of supporting inter- 363 overlay EID mobility as specified in Section 6, these mappings will 364 be preferred over the default EID mapping whenever present. 366 Local EIDs registered with the site-overlay mapping system must also 367 be registered with the Uberlay Mapping System. The registration of 368 the local site-overlay EIDs with the uberlay Mapping System is 369 originated by the Border xTRs. The local site-overlay EIDs SHOULD be 370 aggregated into the shortest covering prefix possible before being 371 registered with the uberlay Mapping System. How this aggregation is 372 achieved is implementation specific. 374 In order to be able to register the local site-overlay EIDs with the 375 uberlay Mapping System, the border xTRs must subscribe to all EIDs 376 registered in their local site-overlay Mapping System. This is a 377 subscription to 0.0.0.0/0 (or 0::/0) with the N-bit set as specified 378 in [I-D.ietf-lisp-pubsub]. The subscription populates all local 379 site-overlay EID mappings in the map-cache of the border xTRs. 381 Once received through the subscription, the local site-overlay EIDs 382 in the map-cache at the border xTRs must be registered by the border 383 xTRs with the uberlay Mapping System. The local site-overlay EIDs 384 will be registered using the 'uberlay' RLOC-set for the registering 385 border xTR. 387 Following [I-D.ietf-lisp-eid-mobility], the border xTRs will also 388 subscribe to any EID prefixes it registers with the uberlay Mapping 389 System. This allows the border xTRs to get Map Notify messages for 390 EID prefixes that may move from their local site-overlay to a remote 391 site-overlay. 393 4.1.1. Split-horizon at the Border xTRs 395 Remote site-overlay EIDs may be learnt at a border xTR due to 396 resolution of a remote destination EID or due to a mobility event as 397 specified in Section 6. Remote site-overlay EIDs learnt from the 398 uberlay will be installed in the map-cache of the border xTR with the 399 corresponding remote uberlay RLOC-set for the remote border xTR. 400 When these remote site-overlay EIDs are learnt as a consequence of 401 the map-notify messages defined in the Inter-overlay mobility 402 procedures in Section 6, the EIDs will also be registered with the 403 local site-overlay mapping system using the local site-overlay RLOC- 404 set for the border-xTR. The remote site-overlay EIDs registered with 405 the local site-overlay mapping system will be learnt back at the 406 border xTR because of the border xTR's subscription to all local 407 site-overlay EIDs. This can cause the mapping for the remote EID 408 that is installed in the border xTR map-cache to flip flop between 409 the uberlay RLOC-set and the local site-overlay RLOC-set. 411 In order to avoid this flip flopping a split horizon procedure must 412 be implemented. When a mapping received at the border xTR (as part 413 of its subscription to all local site-overlay EID prefixes) has the 414 local site-overlay RLOC-set for the border xTR, the mapping received 415 in the subscription corresponds to a remote site-overlay EID and 416 should be ignored by the border xTR. The mapping should not be 417 installed in the map-cache of the border xTR and the EIDs in the 418 mapping should not be advertised to the uberlay. 420 4.2. Resolution and Forwarding Procedures 422 Intra-site communication follows the standard procedures of 423 registration, resolution, caching and encapsulation defined in 424 [I-D.ietf-lisp-rfc6830bis] and [I-D.ietf-lisp-rfc6833bis] amongst the 425 xTRs within the local site-overlay. 427 Inter-site communication is achieved by encapsulating traffic 428 destined to remote site-overlay EIDs from the xTRs to the border 429 xTRs. Traffic will be decapsulated at the border xTRs and a lookup 430 in the uberlay mapping system will determine the site-overlay to 431 which traffic is to be re-encapsulated. The lookup should return the 432 uberlay RLOCs for the border xTRs of the site-overlay where the 433 destination EID is located. At the border xTR of the destination 434 overlay-site, traffic will be de-capsulated, and re-encapsulated to 435 the destination xTR, just like an RTR does. The border xTR already 436 has the destination EID in its cache per its subscription to all 437 local site-overlay EIDs. 439 When receiving encapsulated traffic, a border xTR will de-capsulate 440 the traffic and will do a lookup for the destination EID in its map 441 cache. If the destination EID is present in the map cache, the 442 traffic is forwarded and no lookup takes place. If the destination 443 EID is not present in the cache, the destination EID is not in any 444 local site-overlay connected to the border xTR, in which case the 445 border xTR will issue a map-request to all Uberlay Mapping Systems it 446 is connected to. The criteria to determine which Mapping Systems are 447 Uberlay Mapping Systems is simply to select those Mapping Systems 448 with which the border xTR doesn't hold a subscription to 0.0.0.0/0 449 (or 0::/0). 451 4.2.1. Multi-overlay requests at border xTR 453 Border xTRs may query all Mapping Systems in all uberlays it 454 participates in. The border xTR will then chose based on longest 455 prefix match the more specific EID mapping provided by any of the 456 Mapping Systems. This procedure could also include site-overlay 457 Mapping Systems, however those are not expected to be queried as the 458 border xTR subscribes to all EIDs in the site-overlays and the 459 presence of the mappings in the cache will prevent any lookups. The 460 processing of Map Requests following the multi-domain request logic 461 works as follows: 463 1. The Border xTR sends a map request for the prefix that it intends 464 to resolve to each of the Mapping Systems it participates in. 466 2. The Border xTR receives Map Replies from each of the different 467 Mapping Systems it sent requests to. The Border xTR will treat 468 the replies differently depending on their contents: 470 * Negative Map Replies are ignored and discarded unless all Map 471 Replies are Negative, then the border xTR follows the 472 procedures specified in [RFC6833] for Negative Map Replies. 474 * Map Replies with RLOCs that belong to the requesting border 475 xTR are ignored. 477 * Map Replies with EID prefixes that are not already in the map 478 cache of the border xTR are accepted and cached. 480 * If the prefix already exists in the cache/routing table and 481 the source of the prefix is another reply from the multi- 482 domain request, the RLOCs received in the mapping are added to 483 the RLOC set cached for the prefix. 485 When following these rules when processing multi-domain requests, the 486 Border xTR guarantees proper discovery and use of destination 487 prefixes, that will be associated with their corresponding overlay 488 fabric. By ignoring the negative replies the procedure works 489 regardless of whether the Mapping Systems of multiple fabrics have 490 consistent configurations or operate individually without being aware 491 of the whole addressing space in the overlay fabric. 493 4.3. Default EID registration and treatment 495 Border xTRs will register a mapping to be used as a default mapping 496 to handle the forwarding of traffic destined to any EIDs that are not 497 explicitly registered. These mappings will be registered in the 498 local site-overlay Mapping System of each site-overlay. The RLOCs 499 for the mappings will be the site-overlay RLOCs of the border xTR. 500 This registration is intended to instruct the Mapping System to 501 follow the procedures in [RFC6833] for Negative Map Replies and 502 calculate the broadest non-registered prefix that includes the 503 requested destination EID and issue a map-reply with the calculated 504 EID and the RLOCs registered by the border xTRs. The map-reply may 505 have a shorter TTL to accommodate any changes in the registrations. 507 The instruction to the Mapping System can be encoded as the 508 registration of a 0.0.0.0/0 (or 0::/0) EID or it can be encoded as 509 the registration of an agreed upon distinguished name such as 510 "Default". In either case, the registration will contain the RLOC 511 set desired for the default handling. 513 5. Multicast Specific Procedures 515 This specification will focus on the procedures necessary to extend 516 signal-free multicast [RFC8378] across multiple site-overlays 517 interconnected with an uberlay. The specification will focus on the 518 extensions of the Sender and Receiver site procedures 520 5.1. Inter-site-overlay Control Plane Procedures for Signal-free 521 multicast 523 1. At the listener sites, xTRs with multicast listeners will follow 524 the receiver site procedures described in [RFC8378]. A 525 replication list will be built and registered on the site-overlay 526 Mapping System for the multicast channel being joined by the 527 listeners. 529 2. The Mapping System for the listener site-overlay will send Map- 530 Notify messages towards the multicast source or RP per [RFC8378]. 531 The multicast source or RP is reachable via the border-xTRs of 532 the listener site-overlay via the default EID mapping registered 533 in the listener site-overlay. 535 3. Upon reception of the Map-Notify in the previous step, the 536 listener site-overlay border-xTR will register the multicast EID 537 with the uberlay Mapping System using the uberlay RLOCs for its 538 site-overlay as the RLOC set for the mapping being registered. 539 Only one of the RLOCs in the set should be active in the 540 registration per the procedures in [RFC8378]. A replication tree 541 is built in the uberlay as specified in [RFC8378]. 543 4. After the listener site-overlay border-xTR registers the 544 multicast EID with the uberlay Mapping system, the uberlay MS 545 will send a Map-Notify toward the multicast source per [RFC8378] 547 5. Upon reception of the Map-Notify in the previous step, the border 548 xTR at the source site-overlay registers its interest in the 549 multicast EID with the source site-overlay Mapping System 550 following the procedures described in [RFC8378]. 552 5.2. Border xTR Resolution and Forwarding procedures for Signal-free 553 multicast 555 The mapping resolution procedures for multicast EIDs at border xTRs 556 fall within the scope of the mechanisms specified in Section 4. The 557 Map-replies obtained from the lookup will follow the behavior 558 specified in [RFC8378] for signal-free multicast. 560 Forwarding will also follow the General Procedures specified in 561 Section 4 without alteration. It is worth noting that the 562 concatenation of overlays between listener sites, uberlay and sender 563 site-overlays creates a convenient replication structure where the 564 border xTRs act as the replication points to form an optimized end- 565 to-end multi-level replication tree [Ref to Replication Engineering 566 draft]. 568 6. Inter site-overlay Mobility Procedures 570 The receiver and sender site procedures defined in [Ref eid-mobility] 571 apply without change to each site-overlay and to the uberlay. Border 572 xTRs are connected to two or more overlay networks which are 573 following the mobility procedures. An away table is defined at the 574 border xTR for each overlay network it participates in. In order to 575 illustrate the procedures required, this specification describes a 576 scenario where a border xTR has one local site-overlay away table and 577 one uberlay facing away table. The procedures for mobility described 578 in this section are extensible to border xTRs participating in more 579 than two overlays. 581 When a map notify for an EID is received, an away entry is created on 582 the receiving side table. Any away entries for the specific EID in 583 other tables on the same LISP node (xTR or RTR) must be removed. 584 This general rule addresses convergence necessary for a first move as 585 well as any subsequent moves (moves that take place after the away 586 tables are already populated with entries for the moving EID due to 587 previous moves). 589 The following set of procedures highlights any additions to the 590 mobility procedures defined in [Ref eid-mobility]: 592 1. Detect the roaming EID per the mechanisms described in [Ref EID- 593 mobility] and register the EID with the site-overlay Mapping 594 System at the landing site-overlay 596 2. The site-overlay Mapping System at the landing site-overlay must 597 send a Map-Notify to the last registrant xTR (if it is local to 598 the site-overlay) and to the border xTR as the border xTR 599 subscribes to all EIDs in the site-overlay. 601 3. The border xTR will install an entry for the moved host in the 602 local away table of the border xTR. 604 4. The border xTR from the landing site-overlay will register the 605 roaming EID with the uberlay Mapping System using the uberlay 606 RLOC-set for the landing site-overlay 608 5. The Uberlay Map Server will send Map-Notify messages to the 609 border xTRs at the departure site-overlay as specified in [Ref 610 eid-mobility] (border xTR with the previously registered RLOCs). 612 6. Upon reception of the Map-Notify, the border xTR must check if 613 the Map-Notify is for an EID-prefix that is covered by a broader 614 or equal EID-prefix that is locally registered. Local 615 registration is determined by the presence of the broader or 616 equal EID prefix in the map-cache of the border xTR. 618 7. If the roaming EID-prefix received in the Map-Notify is not 619 covered under a previously registered EID-prefix in the local 620 site-overlay, the EID-prefix is a newly registered prefix and no 621 further action is required. 623 8. If the roaming EID-prefix received in the Map-Notify is covered 624 under a registered EID-prefix, the Map-Notify is due to a move 625 event. In this case, the site-overlay border xTR must register 626 the roaming EID prefix in the site-overlay mapping system using 627 the site-overlay facing RLOC-set of the border-xTRs. The 628 roaming EID-prefix must also be installed in the uberlay facing 629 away table of the border xTR at the departure site-overlay. 631 9. The departure site-overlay Map-Server will send Map-Notify 632 messages to the xTRs at the departure site-overlay as specified 633 in [Ref eid-mobility] (edge xTRs with the previously registered 634 RLOCs). 636 10. When the site-overlay xTR at the departure site-overlay receives 637 the Map-Notify from the border xTR, it will include the EID 638 prefix received in the Map-Notify in its away table per the 639 procedures described in [Ref eid-mobility]. 641 11. Data triggered Solicit Map Requests (SMRs) will be initiated in 642 the different site-overlays and the uberlay as traffic matches 643 the different away tables. As specified in [Ref eid-mobility], 644 these SMRs notify the different ITRs involved in communications 645 with the roaming EID that they must issue a new Map-Request to 646 the mapping system to renew their mappings for the roaming EID. 648 7. Virtual Private Network (VPN) Considerations 650 When supporting multiple Instance IDs as specified in 651 [I-D.ietf-lisp-vpn] the Instance IDs range is divided in two sets. A 652 reuse-set that can be used in each site-overlay and a global-set used 653 across site-overlays and the uberlay. 655 Instance-IDs that are local to a site-overlay should only provide 656 intra-overlay connectivity and are in the site-overlay mapping system 657 only for VPN use for the xTRs in the site-overlay. When the VPN 658 reaches across site-overlays, then the global-set instance-IDs are in 659 the uberlay mapping system as well as each site-overlay mapping 660 system where the VPN members exist. 662 8. IANA Considerations 664 This document has no IANA implications 666 9. Acknowledgements 668 The authors want to thank Kedar Karamarkar, Prakash Jain and Vina 669 Ermagan for their insightful contribution to shaping the ideas in 670 this document. 672 10. References 674 10.1. Normative References 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, 678 DOI 10.17487/RFC2119, March 1997, 679 . 681 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 682 Discovery Protocol (MSDP)", RFC 3618, 683 DOI 10.17487/RFC3618, October 2003, 684 . 686 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 687 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 688 Protocol Specification (Revised)", RFC 4601, 689 DOI 10.17487/RFC4601, August 2006, 690 . 692 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 693 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 694 . 696 10.2. Informative References 698 [I-D.ietf-lisp-eid-mobility] 699 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 700 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 701 Unified Control Plane", draft-ietf-lisp-eid-mobility-02 702 (work in progress), May 2018. 704 [I-D.ietf-lisp-pubsub] 705 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 706 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 707 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 708 Subscribe Functionality for LISP", draft-ietf-lisp- 709 pubsub-02 (work in progress), November 2018. 711 [I-D.ietf-lisp-rfc6830bis] 712 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 713 Cabellos-Aparicio, "The Locator/ID Separation Protocol 714 (LISP)", draft-ietf-lisp-rfc6830bis-25 (work in progress), 715 October 2018. 717 [I-D.ietf-lisp-rfc6833bis] 718 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 719 "Locator/ID Separation Protocol (LISP) Control-Plane", 720 draft-ietf-lisp-rfc6833bis-19 (work in progress), October 721 2018. 723 [I-D.ietf-lisp-vpn] 724 Moreno, V. and D. Farinacci, "LISP Virtual Private 725 Networks (VPNs)", draft-ietf-lisp-vpn-02 (work in 726 progress), May 2018. 728 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 729 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 730 October 2011, . 732 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 733 Locator/ID Separation Protocol (LISP)", RFC 6830, 734 DOI 10.17487/RFC6830, January 2013, 735 . 737 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 738 Locator/ID Separation Protocol (LISP) for Multicast 739 Environments", RFC 6831, DOI 10.17487/RFC6831, January 740 2013, . 742 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 743 Protocol (LISP) Map-Server Interface", RFC 6833, 744 DOI 10.17487/RFC6833, January 2013, 745 . 747 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 748 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 749 eXtensible Local Area Network (VXLAN): A Framework for 750 Overlaying Virtualized Layer 2 Networks over Layer 3 751 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 752 . 754 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 755 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 756 February 2017, . 758 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 759 (LISP) Data-Plane Confidentiality", RFC 8061, 760 DOI 10.17487/RFC8061, February 2017, 761 . 763 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 764 Smirnov, "Locator/ID Separation Protocol Delegated 765 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 766 May 2017, . 768 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 769 Separation Protocol (LISP) Multicast", RFC 8378, 770 DOI 10.17487/RFC8378, May 2018, 771 . 773 Authors' Addresses 775 Victor Moreno 776 Cisco Systems 777 170 Tasman Drive 778 San Jose, California 95134 779 USA 781 Email: vimoreno@cisco.com 783 Dino Farinacci 784 lispers.net 785 San Jose, CA 95120 786 USA 788 Email: farinacci@gmail.com 789 Alberto Rodriguez-Natal 790 Cisco Systems 791 170 Tasman Drive 792 San Jose, California 95134 793 USA 795 Email: natal@cisco.com 797 Marc Portoles-Comeras 798 Cisco Systems 799 170 Tasman Drive 800 San Jose, California 95134 801 USA 803 Email: mportole@cisco.com 805 Fabio Maino 806 Cisco Systems 807 170 Tasman Drive 808 San Jose, California 95134 809 USA 811 Email: fmaino@cisco.com 813 Sanjay Hooda 814 Cisco Systems 815 170 Tasman Drive 816 San Jose, California 95134 817 USA 819 Email: shooda@cisco.com 821 Satish Kondalam 822 Cisco Systems 823 170 West Tasman Drive 824 San Jose, California 95134 825 USA 827 Email: skondala@cisco.com