idnits 2.17.1 draft-moreno-lisp-uberlay-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 18, 2019) is 1620 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3618' is defined on line 807, but no explicit reference was found in the text == Unused Reference: 'RFC4601' is defined on line 812, but no explicit reference was found in the text == Unused Reference: 'RFC4607' is defined on line 818, but no explicit reference was found in the text == Unused Reference: 'RFC6407' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'RFC6831' is defined on line 868, but no explicit reference was found in the text == Unused Reference: 'RFC7348' is defined on line 878, but no explicit reference was found in the text == Unused Reference: 'RFC8060' is defined on line 885, but no explicit reference was found in the text == Unused Reference: 'RFC8061' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'RFC8111' is defined on line 894, 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-04 == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-04 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-04 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-27 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-25 == Outdated reference: A later version (-12) exists of draft-ietf-lisp-vpn-04 -- 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: May 21, 2020 lispers.net 6 A. Rodriguez-Natal 7 M. Portoles-Comeras 8 F. Maino 9 S. Hooda 10 S. Kondalam 11 Cisco Systems 12 November 18, 2019 14 Uberlay Interconnection of Multiple LISP overlays 15 draft-moreno-lisp-uberlay-02 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 May 21, 2020. 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 3.1. Logical Topology Considerations . . . . . . . . . . . . . 7 82 4. General Procedures . . . . . . . . . . . . . . . . . . . . . 9 83 4.1. Control Plane Procedures . . . . . . . . . . . . . . . . 10 84 4.1.1. Split-horizon at the Border xTRs . . . . . . . . . . 11 85 4.1.2. Border-xTR Resiliency . . . . . . . . . . . . . . . . 12 86 4.2. Resolution and Forwarding Procedures . . . . . . . . . . 12 87 4.2.1. Multi-overlay requests at border xTR . . . . . . . . 13 88 4.3. Default EID registration and treatment . . . . . . . . . 14 89 5. Multicast Specific Procedures . . . . . . . . . . . . . . . . 15 90 5.1. Inter-site-overlay Control Plane Procedures for Signal- 91 free multicast . . . . . . . . . . . . . . . . . . . . . 15 92 5.2. Border xTR Resolution and Forwarding procedures for 93 Signal-free multicast . . . . . . . . . . . . . . . . . . 16 94 6. Inter site-overlay Mobility Procedures . . . . . . . . . . . 16 95 7. Virtual Private Network (VPN) Considerations . . . . . . . . 18 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 100 10.2. Informative References . . . . . . . . . . . . . . . . . 19 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 103 1. Introduction 105 The main motivation for this specification is to provide a 106 methodology for the interconnection of LISP domains that may use 107 disparate control and/or data plane approaches. For instance, one 108 domain may use native LISP encapsulation for its data plane and a DDT 109 based mapping system, while another domain may use VXLAN-GPE 110 encapsulation and a mapping system based on 111 [I-D.farinacci-lisp-decent]. Furthermore, one domain may use an IPv4 112 RLOC space and the other domain may use an IPv6 RLOC space and there 113 may not be connectivity between the domains at the RLOC level. We 114 propose a method to interconnect and enable interoperability between 115 these disparate LISP overlay networks by connecting them to a common 116 transit LISP overlay. 118 In order to provide interworking across implementations of overlays 119 that may use different control and data plane approaches, a LISP 120 network may be structured as a collection of site-overlays 121 interconnected by a transit area. Each site-overlay is a fully 122 functional overlay network and has its own set of Map Servers and Map 123 Resolvers. Site-overlays share a border xTR with a transit area. 124 Connectivity between site-overlays is provided via the transit area 125 which we will refer to as "The Uberlay". This specification 126 describes the Control Plane and Forwarding procedures for the 127 implementation of an Uberlay connected multi-overlay LISP network. 128 This approach to the structure of a LISP network may also enable 129 regional failure survivability and fault isolation. 131 2. Definition of Terms 133 LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel 134 Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map- 135 Resolver (MR) are defined in the LISP specification [RFC6830]. 137 Terms defining interactions with the LISP Mapping System are defined 138 in [RFC6833]. 140 Terms related to the procedures for signal free multicast are defined 141 in [RFC8378]. 143 The following terms are here defined to facilitate the descriptions 144 and discussions within this particular document. 146 Site-Overlay - Overlay network at a specific area or domain. This 147 overlay network has a dedicated Mapping System. 149 Border-xTR - xTR that connects a site-overlay to one or more 150 uberlays. 152 xTR - LISP Tunnel Router as defined in [RFC6833]. An xTR connects 153 end-points to the site-overlay. 155 Local Mapping System - Mapping system of the site-overlay 157 Uberlay - Overlay network that interconnects different site-overlays 158 to each other. The Uberlay has a dedicated Mapping System and 159 creates an overlay amongst the border xTRs which connect different 160 site-overlays. 162 Uberlay Mapping System - Autonomous mapping system dedicated to the 163 uberlay. 165 Site-Overlay EIDs - Also referred to as local site-overlay EIDs, 166 these are the EIDs that are connected to xTRs in a particular site- 167 overlay and are registered in their own local site-overlay mapping 168 system. These EIDs will also be registered in the uberlay but not in 169 the remote site-overlay mapping systems. 171 Remote site-overlay EIDs - These are EIDs connected and registered in 172 site-overlays other than the local site-overlay. 174 Local site-overlay EIDs - These are EIDs connected and registered in 175 the local site-overlay. 177 3. Interconnecting multiple LISP site-overlays via the Uberlay 179 A LISP network can be structured as a collection of LISP site- 180 overlays that are interconnected by one or more LISP Uberlays. 182 A LISP site-overlay is an overlay network that has its own set of 183 xTRs, its own dedicated Mapping System and it may have a dedicated 184 RLOC space, separate from that of other site-overlays or the uberlay. 185 A LISP uberlay is also an overlay network with its own set of xTRs, 186 its own dedicated Mapping System and it may have its own dedicated 187 RLOC space. When the RLOC spaces are dedicated, RLOC routes in the 188 local underlay do not leak across to the underlay of other site- 189 overlays. 191 A site-overlay will have xTRs and Border xTRs. The xTRs provide 192 connectivity to the local site-overlay EIDs, which are the EIDs that 193 are locally connected to the overlay-site. The Border xTRs are Re- 194 encapsulating Tunnel Routers (RTRs) that connect the site-overlays to 195 the LISP Uberlay in the transit network. xTRs participate in one 196 site-overlay and one site-overlay only. Border xTRs participate in 197 the mapping system of the site-overlay it resides in and the mapping 198 system of the uberlay it connects the site-overlay to. Border xTRs 199 may be shared by more than one site-overlay. 201 The different site-overlays can be interconnected by an uberlay. The 202 uberlay consists of a dedicated Mapping System and the set of Border 203 xTRs that connect the participating site-overlays to the Uberlay and 204 the Uberlay Mapping System. 206 Each site-overlay will have its own set of Map Servers and Map 207 Resolvers (MS/MRs) which operate as an autonomous Mapping System. 208 The Uberlay Mapping System is also autonomous and includes all 209 necessary Map Servers and Map Resolvers. Any of the Mapping Systems, 210 in site-overlays or in the Uberlay, follow the control plane 211 specification in [RFC6833] and may be structured as a Distributed 212 Delegation Tree (DDT) per [RFC8111]for the purposes of horizontal 213 scaling or other optimizations within each Mapping System. 215 The MS/MRs can be co-located with the border-xTRs of the site-overlay 216 When a Border xTR services more than one site-overlay, and the MS/MRs 217 are instantiated on the Border xTR, logical instances of MS/MRs must 218 be dedicated to each site-overlay. 220 This specification defines the interaction between the Mapping 221 Systems of the site-overlays and the uberlay to deliver a multi- 222 overlay hierarchical network. The forwarding procedures relevant to 223 the border xTRs are also specified. Figure 1 illustrates the multi- 224 overlay network. 226 +-------------------------------+ 227 | +-----+ +-----+ +-----+ | 228 | | xTR | | xTR | | xTR | | 229 | +-----+ +-----+ +-----+ | 230 | | 231 | +-------+ | RLOC space 1 232 | Site Overlay 1 | MS/MR | | (underlay 1) 233 | +-------+ | 234 | | 235 | | 236 | +--------+ +--------+ | 237 +-----| Border |--| Border |----+ 238 +-----| xTR |--| xTR |----+ 239 | +--------+ +--------+ | 240 | | 241 | | 242 | | 243 | +-------+ | Uberlay 244 | Uberlay | MS/MR | | RLOC Space 245 | +-------+ | (Transit Underlay) 246 | | 247 | | 248 | +----------+ | 249 +---------| Border |----------+ 250 +---------| xTR |----------+ 251 | +----------+ | 252 | | 253 | +-------+ | RLOC space 2 254 | Site Overlay 2 | MS/MR | | (underlay 2) 255 | +-------+ | 256 | | 257 | +-----+ +-----+ +-----+ | 258 | | xTR | | xTR | | xTR | | 259 | +-----+ +-----+ +-----+ | 260 +-------------------------------+ 262 Figure 1. Site-overlays connected via Uberlay 264 Structuring the LISP network as multiple site-overlays interconnected 265 by an uberlay delivers the following benefits: 267 o Enable the interworking of diverse site-overlay implementations in 268 which different mapping systems and encapsulations may be used. 270 o Enhanced resiliency through regional failure survivability. 271 Failures in one site-overlay or failures in a portion of the 272 underlay should not affect other site-overlays. 274 o Reduce the state of the site-overlay control plane. The site- 275 overlay control plane will only maintain state for EIDs that are 276 connected to xTRs within the site-overlay These EIDs are referred 277 to as local site-overlay EIDs in this specification. Remote site- 278 overlay EIDs will not be explicitly registered within the site- 279 overlay. 281 o Separate the RLOC space of the different site-overlays as well as 282 the uberlay RLOC space. Each site-overlay will only need 283 reachability to its own RLOCs, making the RLOCs private to the 284 site-overlay Similarly, the uberlay RLOC space does not require 285 knowledge of site-overlay specific RLOCs. This simplifies the 286 underlay routing protocol structure and reduces the state that 287 must be handled and maintained by the underlay routing protocols. 289 o Reduced latency for local site-overlay EID registrations may be 290 achieved when xTRs and Map Servers are topologically close. 291 Topological proximity is expected when the RLOC spaces for the 292 different overlays are kept separate. 294 o Reduced latency for local site-overlay EID lookups may be achieved 295 when xTRs, Map Resolvers and Map Servers are topologically close. 296 Topological proximity is expected when the RLOC spaces for the 297 different overlays are kept separate. 299 o Creates a multicast replication hierarchy where the Border RTRs 300 serve as the points of multicast replication for multicast traffic 301 that spans multiple site-overlays. 303 o Creates a distributed structure of RTRs that can be leveraged for 304 the deployment of NAT traversal in the RLOC space. 306 o 308 3.1. Logical Topology Considerations 310 xTRs as defined in RFC6833bis connect a network to the LISP overlay 311 and register the EID prefixes from the connected network to the LISP 312 mapping system. Border xTRs, as defined in this document, will 313 connect site-overlays to the Uberlay and register the EID prefixes 314 that originate in a site-overlay in the Mapping System of the 315 Uberlay. Conversely, a border xTR may register EID prefixes present 316 in the Uberlay Mapping System into the Mapping System of a particular 317 site-overlay. Furthermore, border xTRs may connect Uberlays to each 318 other and register the EID prefixes from one Uberlay into the other. 319 There is no provision for the detection of registration loops when 320 concatenating site-overlays and Uberlays, thus any interconnection of 321 overlay domains (site-overlays or Uberlays) must be done in a loop 322 free topology. 324 A loop free topology is hereby defined for reference. This is a 325 general concept and is not encoded into any of the protocol messages 326 in LISP. A loop free topology limits the peerings between Uberlays 327 and/or overlays to a strict hierarchy. At the top of the hierarchy 328 is a single central Uberlay or Core Uberlay. The loop free topology 329 is defined by two simple rules: Uberlays must only connect to 330 Uberlays in the next consecutive level of hierarchy (no level 331 skipping) and uberlays within the same level of hierarchy must not 332 connect to each other. The loop-free topology hierarchy is 333 illustrated in Figure 2. 335 +----------------+ +----------------+ 336 | site-overlay 1 | | site-overlay 2 | 337 | (Level 2) | | (Level 2) | 338 +----------------+ +----------------+ 339 +---+ +---+ 340 |RTR| |RTR| 341 +---+ +---+ 342 +-----------+ +-----------+ 343 | Uberlay 1 | | Uberlay 2 | 344 | (Level 1) | | (Level 1) | 345 +-----------+ +-----------+ 346 +---+ +---+ 347 |RTR+---------+RTR| 348 +--++ ++--+ 349 | Core | 350 | Uberlay | 351 | (Level 0) | 352 +--++ ++--+ 353 |RTR+---------+RTR| 354 +---+ +---+ 355 +-----------+ +-----------+ 356 | Uberlay 3 | | Uberlay 4 | 357 | (Level 1) | | (Level 1) | 358 +-----------+ +-----------+ 359 +---+ +---+ 360 |RTR| |RTR| 361 +---+ +---+ 362 +----------------+ +----------------+ 363 | site-overlay 3 | | site-overlay 4 | 364 | (Level 2) | | (Level 2) | 365 +----------------+ +----------------+ 367 Figure 2. Loop-free topology hierarchy 369 4. General Procedures 371 A site-overlay maintains state only for its local site-overlay EIDs 372 and RLOCs. Tunnels never cross site-overlay or uberlay boundaries. 373 Remote site-overlay EIDs are reachable at the source site-overlay via 374 a default mapping which will steer all traffic destined to remote 375 site-overlay EIDs to the border xTRs where it can be handed off to 376 the uberlay. Traffic will be decapsulated at the border xTRs and a 377 lookup in the uberlay mapping system will determine the site-overlay 378 to which traffic is to be re-encapsulated. The uberlay maintains 379 state for the EIDs of all interconnected site-overlays and will steer 380 traffic from the source site-overlay to the destination site-overlay 381 by encapsulating the traffic from the source site-overlay border xTR 382 to the destination site-overlay border xTR. At the border xTR of the 383 destination site-overlay, traffic will be de-capsulated, a lookup in 384 the local destination site-overlay Mapping System will take place and 385 traffic will be re-encapsulated to the xTR that connects to the 386 destination EID. Thus, forwarding is achieved by concatenating 387 overlays and doing Re-encapsulation at the border xTRs to forward the 388 traffic from the Ingress site-overlay to the Egress site-overlay via 389 the Uberlay. 391 Traffic for non-LISP sites, or for EIDs not registered in any site- 392 overlay, will also be forwarded to the border xTR where it will be 393 forwarded or dropped as appropriate. 395 4.1. Control Plane Procedures 397 Local EIDs must be registered by the xTRs into the local Mapping 398 System of the site-overlay. Intra-site communication follows the 399 standard procedures of registration, resolution, caching and 400 encapsulation defined in [I-D.ietf-lisp-rfc6830bis] and 401 [I-D.ietf-lisp-rfc6833bis] amongst the xTRs within the local site- 402 overlay. 404 The border xTRs at a site-overlay should have a local site-overlay 405 RLOC-set and will also have an uberlay RLOC-set. The local site- 406 overlay RLOC-set is in the private site-overlay RLOC space and is 407 used by the border xTRs as the RLOC set for any mappings it may 408 register with the site-overlay Mapping System. The uberlay RLOC-set 409 for the border-xTRs of a particular site-overlay are the RLOCs to 410 reach the site-overlay in the uberlay RLOC space. The border xTR 411 will use the uberlay RLOC-set in any mappings it may register with 412 the uberlay Mapping System. It is possible for a deployment to 413 connect the RLOC spaces of the site-overlays and the uberlay, it is 414 also possible in the scenario of a common RLOC space for the uberlay 415 and local site-overlay RLOC sets to be one and the same. Any 416 implementation of this specification should support disjoint RLOC 417 spaces or joint RLOC spaces. 419 The border xTRs must register a default EID-prefix as specified in 420 Section 4.3 with the local site-overlay Mapping System. Remote EIDs 421 will be generally reachable by xTRs in a site-overlay using the 422 default EID mapping registered by the border xTRs. This is expected 423 to be the mapping used for most communications to remote site-overlay 424 EIDs. Remote site-overlay EIDs may be registered with the local 425 site-overlay Mapping System for the purposes of supporting inter- 426 overlay EID mobility as specified in Section 6, these mappings will 427 be preferred over the default EID mapping whenever present. 429 Local EIDs registered with the site-overlay mapping system must also 430 be registered with the Uberlay Mapping System. The registration of 431 the local site-overlay EIDs with the uberlay Mapping System is 432 originated by the Border xTRs. The local site-overlay EIDs SHOULD be 433 aggregated into the shortest covering prefix possible before being 434 registered with the uberlay Mapping System. How this aggregation is 435 achieved is implementation specific. 437 In order to be able to register the local site-overlay EIDs with the 438 uberlay Mapping System, the border xTRs must subscribe to all EIDs 439 registered in their local site-overlay Mapping System. This is a 440 subscription to 0.0.0.0/0 (or 0::/0) with the N-bit set as specified 441 in [I-D.ietf-lisp-pubsub]. The subscription populates all local 442 site-overlay EID mappings in the map-cache of the border xTRs. 444 Once received through the subscription, the local site-overlay EIDs 445 in the map-cache at the border xTRs must be registered by the border 446 xTRs with the uberlay Mapping System. The local site-overlay EIDs 447 will be registered using the 'uberlay' RLOC-set for the registering 448 border xTR. 450 Following [I-D.ietf-lisp-eid-mobility], the border xTRs will also 451 subscribe to any EID prefixes it registers with the uberlay Mapping 452 System. This allows the border xTRs to get Map Notify messages from 453 the uberlay Mapping System for EID prefixes that may move from their 454 local site-overlay to a remote site-overlay. 456 4.1.1. Split-horizon at the Border xTRs 458 Remote site-overlay EIDs may be learnt at a border xTR due to 459 resolution of a remote destination EID or due to a mobility event as 460 specified in Section 6. Remote site-overlay EIDs learnt from the 461 uberlay will be installed in the map-cache of the border xTR with the 462 corresponding remote uberlay RLOC-set for the remote border xTR. 463 When these remote site-overlay EIDs are learnt as a consequence of 464 the map-notify messages defined in the Inter-overlay mobility 465 procedures in Section 6, the EIDs will also be registered with the 466 local site-overlay mapping system using the local site-overlay RLOC- 467 set for the border-xTR. The remote site-overlay EIDs registered with 468 the local site-overlay mapping system will be learnt back at the 469 border xTR because of the border xTR's subscription to all local 470 site-overlay EIDs. This can cause the mapping for the remote EID 471 that is installed in the border xTR map-cache to flip flop between 472 the uberlay RLOC-set and the local site-overlay RLOC-set. 474 In order to avoid this flip flopping a split horizon procedure must 475 be implemented. When a mapping received at the border xTR (as part 476 of its subscription to all local site-overlay EID prefixes) has the 477 local site-overlay RLOC-set for the border xTR, the mapping received 478 in the subscription corresponds to a remote site-overlay EID and 479 should be ignored by the border xTR. The mapping should not be 480 installed in the map-cache of the border xTR and the EIDs in the 481 mapping should not be advertised to the uberlay. More robust split 482 horizon mechanisms can be proposed in future revisions of this 483 specification. 485 4.1.2. Border-xTR Resiliency 487 Redundancy at the border xTRs requires that border xTRs be logically 488 grouped so that the redundant array doesn't create a registration 489 loop. As border xTRs interconnect overlay domains, the border xTRs 490 will register the EID prefixes from one domain into the neighboring 491 domain. From the perspective of the border xTR, the EID prefixes to 492 be registered in one domain are learnt from a neighbor domain which 493 we will refer to as the "site-of-origin". The site-of-origin may be 494 an overlay-site, an Uberlay or an IP network. 496 Border xTRs should be logically grouped in Border Sets. A border set 497 is a group of border xTRs that register EID prefixes from the same 498 site-of-origin. Members of a border set will register the EIDs from 499 a particular site-of-origin into the neighboring overlay (site- 500 overlay or uberlay) using a common site-id. The use of the site-ID 501 namespace is locally significant to each overlay domain (site-overlay 502 or Uberlay) and does not require cross-domain synchronization or 503 dispersion. A border-xTR may be a member of multiple border sets to 504 allow different site-of-origin domains to be serviced by the border- 505 xTR. Note that not all site-of-origin domains will connect to the 506 same combination of border-xTRs. 508 EID Mappings will be tagged with a site-ID according to their site- 509 of-origin when they are registered by the border-xTR. The site-ID 510 must be maintained in the Mapping System as part of the registration 511 record. EID Mappings published and received at the border xTR must 512 include the site-ID for the EID Mapping. If the border-xTR receives 513 a mapping for an EID with a site-ID that matches the site-ID for one 514 of its border sets (site-of-origin), the Border xTR will not register 515 that information to the site-of-origin associated with that site-ID 516 and thus prevent any registration loops from occurring. 518 4.2. Resolution and Forwarding Procedures 520 Intra-site communication follows the standard procedures of 521 registration, resolution, caching and encapsulation defined in 522 [I-D.ietf-lisp-rfc6830bis] and [I-D.ietf-lisp-rfc6833bis] amongst the 523 xTRs within the local site-overlay. 525 Inter-site communication is achieved by encapsulating traffic 526 destined to remote site-overlay EIDs from the xTRs to the border 527 xTRs. Traffic will be decapsulated at the border xTRs and a lookup 528 in the uberlay mapping system will determine the site-overlay to 529 which traffic is to be re-encapsulated. The lookup should return the 530 uberlay RLOCs for the border xTRs of the site-overlay where the 531 destination EID is located. At the border xTR of the destination 532 overlay-site, traffic will be de-capsulated, and re-encapsulated to 533 the destination xTR, just like an RTR does. The border xTR already 534 has the destination EID in its cache per its subscription to all 535 local site-overlay EIDs. 537 When receiving encapsulated traffic, a border xTR will de-capsulate 538 the traffic and will do a lookup for the destination EID in its map 539 cache. If the destination EID is present in the map cache, the 540 traffic is forwarded and no lookup takes place. If the destination 541 EID is not present in the cache, the destination EID is not in any 542 local site-overlay connected to the border xTR, in which case the 543 border xTR will issue a map-request to all Uberlay Mapping Systems it 544 is connected to. The criteria to determine which Mapping Systems are 545 Uberlay Mapping Systems is simply to select those Mapping Systems 546 with which the border xTR doesn't hold a subscription to 0.0.0.0/0 547 (or 0::/0). 549 4.2.1. Multi-overlay requests at border xTR 551 A Border xTR may query all Mapping Systems in all uberlays it 552 participates in. The border xTR will then chose based on longest 553 prefix match the more specific EID mapping provided by any of the 554 Mapping Systems. This procedure could also include site-overlay 555 Mapping Systems, however those are not expected to be queried as the 556 border xTR subscribes to all EIDs in the site-overlays and the 557 presence of the mappings in the cache will prevent any lookups. The 558 processing of Map Requests following the multi-domain request logic 559 works as follows: 561 1. The Border xTR sends a map request for the prefix that it intends 562 to resolve to each of the uberlay Mapping Systems it participates 563 in. 565 2. The Border xTR receives Map Replies from each of the different 566 uberlay Mapping Systems it sent requests to. The Border xTR will 567 treat the replies differently depending on their contents: 569 * Negative Map Replies (NMR) are ignored and discarded unless 570 all Map Replies received are Negative, then the border xTR 571 follows the procedures specified in [RFC6833] for Negative Map 572 Replies. 574 * Map Replies with RLOCs that belong to the requesting border 575 xTR are ignored. 577 * Map Replies with EID prefixes that are not already in the map 578 cache of the border xTR are accepted and cached. 580 * If the EID prefix received in the Map-Reply already exists in 581 the cache/routing table, but the Map-Reply contains a 582 different RLOC-set than the one cached, the mappings are 583 merged so that the RLOCs received in the Map-Reply are added 584 to the RLOC-set previously cached for the EID prefix. 586 * If the EID prefix received in the Map-Reply is more specific 587 or less specific than an EID prefix already cached, the 588 mapping received MUST be cached. 590 It is expected that a deployment of the uberlay would include the 591 dynamic registration of default EIDs. It is also recommended that an 592 implementation adopts mechanisms for the dynamic resolution of 593 default EIDs. In an environment leveraging the dynamic registration 594 and resolution of default EIDs, the border xTR should not receive 595 Negative Map-Replies, but all replies (including those in response to 596 requests for destinations that are external to the EID space) will be 597 Map-replies with a non-zero locator count. Nevertheless, an 598 implementation could opt to not use dynamic default-EID handling. In 599 these cases, the border xTR will receive NMRs. The implementation of 600 the Border xTR should defer the decision on caching an NMR until all 601 relevant Map-replies are received. To this effect, the 602 implementation should implement mechanisms to ensure that sufficient 603 replies are received before programming the map-cache. The 604 mechanisms by which this is achieved are an implementation specific 605 matter and therefore not specified in this document. 607 When following these rules to process multi-domain requests, the 608 Border xTR guarantees proper discovery and use of destination 609 prefixes that will be associated with their corresponding overlay- 610 site. By ignoring the negative replies the procedure works 611 regardless of whether the Mapping Systems of multiple uberlays have 612 consistent configurations or operate individually without being aware 613 of the whole addressing space in the overlay fabric. 615 4.3. Default EID registration and treatment 617 Border xTRs will register a mapping to be used as a default mapping 618 to handle the forwarding of traffic destined to any EIDs that are not 619 explicitly registered. These mappings will be registered in the 620 local site-overlay Mapping System of each site-overlay. The RLOCs 621 for the mappings will be the site-overlay RLOCs of the border xTR. 623 This registration is intended to instruct the Mapping System to 624 follow the procedures in [RFC6833] for Negative Map Replies and 625 calculate the broadest non-registered EID prefix that includes the 626 requested destination EID and issue a map-reply with the calculated 627 EID and the RLOCs registered by the border xTRs. The map-reply for 628 this default mapping will have a shorter TTL to accommodate any 629 changes in the registrations. 631 The instruction to the Mapping System can be encoded as the 632 registration of an agreed upon distinguished name such as "Default". 633 The registration will contain the RLOC set desired for the default 634 handling. 636 5. Multicast Specific Procedures 638 This specification will focus on the procedures necessary to extend 639 signal-free multicast [RFC8378] across multiple site-overlays 640 interconnected with an uberlay. The specification will focus on the 641 extensions of the Sender and Receiver site procedures 643 5.1. Inter-site-overlay Control Plane Procedures for Signal-free 644 multicast 646 1. At the listener sites, xTRs with multicast listeners will follow 647 the receiver site procedures described in [RFC8378]. A 648 replication list will be built and registered on the site-overlay 649 Mapping System for the multicast channel being joined by the 650 listeners. 652 2. The Mapping System for the listener site-overlay will send Map- 653 Notify messages towards the multicast source or RP per [RFC8378]. 654 The multicast source or RP is reachable via the border-xTRs of 655 the listener site-overlay via the default EID mapping registered 656 in the listener site-overlay. 658 3. Upon reception of the Map-Notify in the previous step, the 659 listener site-overlay border-xTR will register the multicast EID 660 with the uberlay Mapping System using the uberlay RLOCs for its 661 site-overlay as the RLOC set for the mapping being registered. 662 Only one of the RLOCs in the set should be active in the 663 registration per the procedures in [RFC8378]. A replication tree 664 is built in the uberlay as specified in [RFC8378]. 666 4. After the listener site-overlay border-xTR registers the 667 multicast EID with the uberlay Mapping system, the uberlay MS 668 will send a Map-Notify toward the multicast source per [RFC8378] 670 5. Upon reception of the Map-Notify in the previous step, the border 671 xTR at the source site-overlay registers its interest in the 672 multicast EID with the source site-overlay Mapping System 673 following the procedures described in [RFC8378]. 675 5.2. Border xTR Resolution and Forwarding procedures for Signal-free 676 multicast 678 The mapping resolution procedures for multicast EIDs at border xTRs 679 fall within the scope of the mechanisms specified in Section 4. The 680 Map-replies obtained from the lookup will follow the behavior 681 specified in [RFC8378] for signal-free multicast. 683 Forwarding will also follow the General Procedures specified in 684 Section 4 without alteration. It is worth noting that the 685 concatenation of overlays between listener sites, uberlay and sender 686 site-overlays creates a convenient replication structure where the 687 border xTRs act as the replication points to form an optimized end- 688 to-end multi-level replication tree. 690 6. Inter site-overlay Mobility Procedures 692 The receiver and sender site procedures defined in 693 [I-D.ietf-lisp-eid-mobility] apply without change to each site- 694 overlay and to the uberlay. Border xTRs are connected to two or more 695 overlay networks which are following the mobility procedures. An 696 away table is defined at the border xTR for each overlay network it 697 participates in. In order to illustrate the procedures required, 698 this specification describes a scenario where a border xTR has one 699 local site-overlay away table and one uberlay facing away table. The 700 procedures for mobility described in this section are extensible to 701 border xTRs participating in more than two overlays. 703 When a map notify for an EID is received at an xTR, an away entry is 704 created on the receiving side table. Any away entries for the 705 specific EID in other tables on the same LISP node (xTR or RTR) must 706 be removed. This general rule addresses convergence necessary for a 707 first move as well as any subsequent moves (moves that take place 708 after the away tables are already populated with entries for the 709 moving EID due to previous moves). 711 The following set of procedures highlights any additions to the 712 mobility procedures defined in [I-D.ietf-lisp-eid-mobility]: 714 1. Detect the roaming EID per the mechanisms described in 715 [I-D.ietf-lisp-eid-mobility] and register the EID with the site- 716 overlay Mapping System at the landing site-overlay 718 2. The site-overlay Mapping System at the landing site-overlay must 719 send a Map-Notify to the last registrant xTR (if it is local to 720 the site-overlay) and to the border xTR as the border xTR 721 subscribes to all EIDs in the site-overlay. 723 3. The border xTR will install an entry for the moved host in the 724 local away table of the border xTR. 726 4. The border xTR from the landing site-overlay will register the 727 roaming EID with the uberlay Mapping System using the uberlay 728 RLOC-set for the landing site-overlay 730 5. The Uberlay Map Server will send Map-Notify messages to the 731 border xTRs at the departure site-overlay as specified in 732 [I-D.ietf-lisp-eid-mobility] (border xTR with the previously 733 registered RLOCs). 735 6. Upon reception of the Map-Notify, the border xTR must check if 736 the Map-Notify is for an EID-prefix that is covered by a broader 737 or equal EID-prefix that is locally registered. Local 738 registration is determined by the presence of the broader or 739 equal EID prefix in the map-cache of the border xTR. 741 7. If the roaming EID-prefix received in the Map-Notify is not 742 covered under a previously registered EID-prefix in the local 743 site-overlay, the EID-prefix is a newly registered prefix and no 744 further action is required. 746 8. If the roaming EID-prefix received in the Map-Notify is covered 747 under a registered EID-prefix, the Map-Notify is due to a move 748 event. In this case, the site-overlay border xTR must register 749 the roaming EID prefix in the site-overlay mapping system using 750 the site-overlay facing RLOC-set of the border-xTRs. The 751 roaming EID-prefix must also be installed in the uberlay facing 752 away table of the border xTR at the departure site-overlay. 754 9. The departure site-overlay Map-Server will send Map-Notify 755 messages to the xTRs at the departure site-overlay as specified 756 in [I-D.ietf-lisp-eid-mobility] (edge xTRs with the previously 757 registered RLOCs). 759 10. When the site-overlay xTR at the departure site-overlay receives 760 the Map-Notify from the border xTR, it will include the EID 761 prefix received in the Map-Notify in its away table per the 762 procedures described in [I-D.ietf-lisp-eid-mobility]. 764 11. Data triggered Solicit Map Requests (SMRs) will be initiated in 765 the different site-overlays and the uberlay as traffic matches 766 the different away tables. As specified in 767 [I-D.ietf-lisp-eid-mobility], these SMRs notify the different 768 ITRs involved in communications with the roaming EID that they 769 must issue a new Map-Request to the mapping system to renew 770 their mappings for the roaming EID. 772 7. Virtual Private Network (VPN) Considerations 774 When supporting multiple Instance IDs as specified in 775 [I-D.ietf-lisp-vpn] the Instance IDs range is divided in two sets. A 776 reuse-set that can be used in each site-overlay and a global-set used 777 across site-overlays and the uberlay. 779 Instance-IDs that are local to a site-overlay should only provide 780 intra-overlay connectivity and are in the site-overlay mapping system 781 only for VPN use for the xTRs in the site-overlay. When the VPN 782 reaches across site-overlays, then the global-set instance-IDs are in 783 the uberlay mapping system as well as each site-overlay mapping 784 system where the VPN members exist. 786 8. IANA Considerations 788 This document has no IANA implications 790 9. Acknowledgements 792 The authors want to thank Kedar Karamarkar, Prakash Jain and Vina 793 Ermagan for their insightful contribution to shaping the ideas in 794 this document. We would also like to acknowledge the valuable input 795 from the workgroup chairs Joel Halpern and Luigi Iannone in refining 796 the objectives of the document. 798 10. References 800 10.1. Normative References 802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 803 Requirement Levels", BCP 14, RFC 2119, 804 DOI 10.17487/RFC2119, March 1997, 805 . 807 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 808 Discovery Protocol (MSDP)", RFC 3618, 809 DOI 10.17487/RFC3618, October 2003, 810 . 812 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 813 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 814 Protocol Specification (Revised)", RFC 4601, 815 DOI 10.17487/RFC4601, August 2006, 816 . 818 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 819 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 820 . 822 10.2. Informative References 824 [I-D.farinacci-lisp-decent] 825 Farinacci, D. and C. Cantrell, "A Decent LISP Mapping 826 System (LISP-Decent)", draft-farinacci-lisp-decent-04 827 (work in progress), September 2019. 829 [I-D.ietf-lisp-eid-mobility] 830 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 831 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 832 Unified Control Plane", draft-ietf-lisp-eid-mobility-04 833 (work in progress), May 2019. 835 [I-D.ietf-lisp-pubsub] 836 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 837 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 838 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 839 Subscribe Functionality for LISP", draft-ietf-lisp- 840 pubsub-04 (work in progress), September 2019. 842 [I-D.ietf-lisp-rfc6830bis] 843 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 844 Cabellos-Aparicio, "The Locator/ID Separation Protocol 845 (LISP)", draft-ietf-lisp-rfc6830bis-27 (work in progress), 846 June 2019. 848 [I-D.ietf-lisp-rfc6833bis] 849 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 850 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 851 Plane", draft-ietf-lisp-rfc6833bis-25 (work in progress), 852 June 2019. 854 [I-D.ietf-lisp-vpn] 855 Moreno, V. and D. Farinacci, "LISP Virtual Private 856 Networks (VPNs)", draft-ietf-lisp-vpn-04 (work in 857 progress), May 2019. 859 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 860 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 861 October 2011, . 863 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 864 Locator/ID Separation Protocol (LISP)", RFC 6830, 865 DOI 10.17487/RFC6830, January 2013, 866 . 868 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 869 Locator/ID Separation Protocol (LISP) for Multicast 870 Environments", RFC 6831, DOI 10.17487/RFC6831, January 871 2013, . 873 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 874 Protocol (LISP) Map-Server Interface", RFC 6833, 875 DOI 10.17487/RFC6833, January 2013, 876 . 878 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 879 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 880 eXtensible Local Area Network (VXLAN): A Framework for 881 Overlaying Virtualized Layer 2 Networks over Layer 3 882 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 883 . 885 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 886 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 887 February 2017, . 889 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 890 (LISP) Data-Plane Confidentiality", RFC 8061, 891 DOI 10.17487/RFC8061, February 2017, 892 . 894 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 895 Smirnov, "Locator/ID Separation Protocol Delegated 896 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 897 May 2017, . 899 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 900 Separation Protocol (LISP) Multicast", RFC 8378, 901 DOI 10.17487/RFC8378, May 2018, 902 . 904 Authors' Addresses 906 Victor Moreno 907 Cisco Systems 908 170 Tasman Drive 909 San Jose, California 95134 910 USA 912 Email: vimoreno@cisco.com 914 Dino Farinacci 915 lispers.net 916 San Jose, CA 95120 917 USA 919 Email: farinacci@gmail.com 921 Alberto Rodriguez-Natal 922 Cisco Systems 923 170 Tasman Drive 924 San Jose, California 95134 925 USA 927 Email: natal@cisco.com 929 Marc Portoles-Comeras 930 Cisco Systems 931 170 Tasman Drive 932 San Jose, California 95134 933 USA 935 Email: mportole@cisco.com 937 Fabio Maino 938 Cisco Systems 939 170 Tasman Drive 940 San Jose, California 95134 941 USA 943 Email: fmaino@cisco.com 944 Sanjay Hooda 945 Cisco Systems 946 170 Tasman Drive 947 San Jose, California 95134 948 USA 950 Email: shooda@cisco.com 952 Satish Kondalam 953 Cisco Systems 954 170 West Tasman Drive 955 San Jose, California 95134 956 USA 958 Email: skondala@cisco.com