idnits 2.17.1 draft-ietf-lisp-multicast-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1123 has weird spacing: '...ss (and port)...' -- The document date (May 26, 2009) is 5441 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-05) exists of draft-fuller-lisp-alt-02 == Outdated reference: A later version (-02) exists of draft-lewis-lisp-interworking-00 == Outdated reference: A later version (-06) exists of draft-ietf-pim-join-attributes-03 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-00 == Outdated reference: A later version (-12) exists of draft-ietf-behave-multicast-07 == Outdated reference: A later version (-08) exists of draft-ietf-pim-rpf-vector-06 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft D. Meyer 4 Intended status: Experimental J. Zwiebel 5 Expires: November 27, 2009 S. Venaas 6 cisco Systems 7 May 26, 2009 9 LISP for Multicast Environments 10 draft-ietf-lisp-multicast-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 27, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This draft describes how inter-domain multicast routing will function 49 in an environment where Locator/ID Separation is deployed using the 50 LISP architecture. 52 Table of Contents 54 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 57 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 58 5. Source Addresses versus Group Addresses . . . . . . . . . . . 12 59 6. Locator Reachability Implications on LISP-Multicast . . . . . 13 60 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14 61 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16 62 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 63 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 64 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 17 65 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 18 66 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 18 67 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 19 68 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 20 69 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 21 70 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . 21 71 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 22 72 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 22 73 9.3. Making a Multicast Interworking Decision . . . . . . . . . 24 74 10. Considerations when RP Addresses are Embedded in Group 75 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 25 76 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 26 77 12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 78 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 79 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 80 14.1. Normative References . . . . . . . . . . . . . . . . . . . 29 81 14.2. Informative References . . . . . . . . . . . . . . . . . . 29 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 84 1. Requirements Notation 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 2. Introduction 92 The Locator/ID Separation Architecture [LISP] provides a mechanism to 93 separate out Identification and Location semantics from the current 94 definition of an IP address. By creating two namespaces, an EID 95 namespace used by sites and a Locator (RLOC) namespace used by core 96 routing, the core routing infrastructure can scale by doing 97 topological aggregation of routing information. 99 Since LISP creates a new namespace, a mapping function must exist to 100 map a site's EID prefixes to its associated locators. For unicast 101 packets, both the source address and destination address must be 102 mapped. For multicast packets, only the source address needs to be 103 mapped. The destination group address doesn't need to be mapped 104 because the semantics of an IPv4 or IPv6 group address are logical in 105 nature and not topology-dependent. Therefore, this specifications 106 focuses on to map a source EID address of a multicast flow during 107 distribution tree setup and packet delivery. 109 This specification will address the following scenarios: 111 1. How a multicast source host in a LISP site sends multicast 112 packets to receivers inside of its site as well as to receivers 113 in other sites that are LISP enabled. 115 2. How inter-domain (or between LISP sites) multicast distribution 116 trees are built and how forwarding of multicast packets leaving a 117 source site toward receivers sites is performed. 119 3. What protocols are affected and what changes are required to such 120 multicast protocols. 122 4. How ASM-mode, SSM-mode, and Bidir-mode service models will 123 operate. 125 5. How multicast packet flow will occur for multiple combinations of 126 LISP and non-LISP capable source and receiver sites, for example: 128 A. How multicast packets from a source host in a LISP site are 129 sent to receivers in other sites when they are all non-LISP 130 sites. 132 B. How multicast packets from a source host in a LISP site are 133 sent to receivers in both LISP-enabled sites and non-LISP 134 sites. 136 C. How multicast packets from a source host in a non-LISP site 137 are sent to receivers in other sites when they are all LISP- 138 enabled sites. 140 D. How multicast packets from a source host in a non-LISP site 141 are sent to receivers in both LISP-enabled sites and non-LISP 142 sites. 144 This specification focuses on what changes are needed to the 145 multicast routing protocols to support LISP-Multicast as well as 146 other protocols used for inter-domain multicast, such as Multi- 147 protocol BGP (MBGP) [RFC4760]. The approach proposed in this 148 specification requires no changes to the multicast infrastructure 149 inside of a site when all sources and receivers reside in that site, 150 even when the site is LISP enabled. That is, internal operation of 151 multicast is unchanged regardless of whether or not the site is LISP 152 enabled or whether or not receivers exist in other sites which are 153 LISP-enabled. 155 Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618], 156 and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not 157 run in an inter-domain environment is not addressed in depth in this 158 version of the specification. 160 Also, the current version of this specification does not describe 161 multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR 162 descriptions in [LISP]. 164 3. Definition of Terms 166 The terminology in this section is consistent with the definitions in 167 [LISP] but is extended specifically to deal with the application of 168 the terminology to multicast routing. 170 LISP-Multicast: a reference to the design in this specification. 171 That is, when any site that is participating in multicast 172 communication has been upgraded to be a LISP site, the operation 173 of control-plane and data-plane protocols is considered part of 174 the LISP-Multicast architecture. 176 Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value 177 used in the source address field of the first (most inner) LISP 178 header of a multicast packet. The host obtains a destination 179 group address the same way it obtains one today, as it would when 180 it is a non-LISP site. The source EID is obtained via existing 181 mechanisms used to set a host's "local" IP address. An EID is 182 allocated to a host from an EID prefix block associated with the 183 site the host is located in. An EID can be used by a host to 184 refer to another host, as when it joins an SSM (S-EID,G) route 185 using IGMP version 3 [RFC4604]. LISP uses Provider Independent 186 (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. 187 Note that EID blocks may be assigned in a hierarchical manner, 188 independent of the network topology, to facilitate scaling of the 189 mapping database. In addition, an EID block assigned to a site 190 may have site-local structure (subnetting) for routing within the 191 site; this structure is not visible to the global routing system. 193 Routing Locator (RLOC): the IPv4 or IPv6 address of an ingress 194 tunnel router (ITR), the router in the multicast source host's 195 site that encapsulates multicast packets. It is the output of a 196 EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. 197 Typically, RLOCs are numbered from topologically-aggregatable 198 blocks that are assigned to a site at each point to which it 199 attaches to the global Internet; where the topology is defined by 200 the connectivity of provider networks, RLOCs can be thought of as 201 Provider Assigned (PA) addresses. Multiple RLOCs can be assigned 202 to the same ITR device or to multiple ITR devices at a site. 204 Ingress Tunnel Router (ITR): a router which accepts an IP multicast 205 packet with a single IP header (more precisely, an IP packet that 206 does not contain a LISP header). The router treats this "inner" 207 IP destination multicast address opaquely so it doesn't need to 208 perform a map lookup on the group address because it is 209 topologically insignificant. The router then prepends an "outer" 210 IP header with one of its globally-routable RLOCs as the source 211 address field. This RLOC is known to other multicast receiver 212 sites which have used the mapping database to join a multicast 213 tree for which the ITR is the root. In general, an ITR receives 214 IP packets from site end systems on one side and sends LISP- 215 encapsulated multicast IP packets out all external interfaces 216 which have been joined. 218 An ITR would receive a multicast packet from a source inside of 219 its site when 1) it is on the path from the multicast source to 220 internally joined receivers, or 2) when it is on the path from the 221 multicast source to externally joined receivers. 223 Egress Tunnel Router (ETR): a router that is on the path from a 224 multicast source host in another site to a multicast receiver in 225 its own site. An ETR accepts a PIM Join/Prune message from a site 226 internal PIM router destined for the source's EID in the multicast 227 source site. The ETR maps the source EID in the Join/Prune 228 message to an RLOC address based on the EID-to-RLOC mapping. This 229 sets up the ETR to accept multicast encapsulated packets from the 230 ITR in the source multicast site. A multicast ETR decapsulates 231 multicast encapsulated packets and replicates them on interfaces 232 leading to internal receivers. 234 xTR: is a reference to an ITR or ETR when direction of data flow is 235 not part of the context description. xTR refers to the router that 236 is the tunnel endpoint. Used synonymously with the term "Tunnel 237 Router". For example, "An xTR can be located at the Customer Edge 238 (CE) router", meaning both ITR and ETR functionality can be at the 239 CE router. 241 LISP Header: a term used in this document to refer to the outer 242 IPv4 or IPv6 header, a UDP header, and a LISP header. An ITR 243 prepends headers and an ETR strips headers. A LISP encapsulated 244 multicast packet will have an "inner" header with the source EID 245 in the source field; an "outer" header with the source RLOC in the 246 source field: and the same globally unique group address in the 247 destination field of both the inner and outer header. 249 (S,G) State: the formal definition is in the PIM Sparse Mode 250 [RFC4601] specification. For this specification, the term is used 251 generally to refer to multicast state. Based on its topological 252 location, the (S,G) state resides in routers can be either 253 (S-EID,G) state (at a location where the (S,G) state resides) or 254 (S-RLOC,G) state (in the Internet core). 256 (S-EID,G) State: refers to multicast state in multicast source and 257 receiver sites where S-EID is the IP address of the multicast 258 source host (its EID). An S-EID can appear in an IGMPv3 report, 259 an MSDP SA message or a PIM Join/Prune message that travels inside 260 of a site. 262 (S-RLOC,G) State: refers to multicast state in the core where S is 263 a source locator (the IP address of a multicast ITR) of a site 264 with a multicast source. The (S-RLOC,G) is mapped from (S-EID,G) 265 entry by doing a mapping database lookup for the EID prefix that 266 S-EID maps to. An S-RLOC can appear in a PIM Join/Prune message 267 when it travels from an ETR to an ITR over the Internet core. 269 uLISP Site: a unicast only LISP site according to [LISP] which has 270 not deployed the procedures of this specification and therefore, 271 for multicast purposes, follows the procedures from Section 9. 273 mPTR: this is a multicast PTR that is responsible for advertising a 274 very coarse EID prefix which non-LISP and uLISP sites can target 275 their (S-EID,G) PIM Join/Prune message to. mPTRs are used so LISP 276 source multicast sites can send multicast packets using source 277 addresses from the EID namespace. mPTRs act as Proxy ETRs for 278 supporting multicast routing in a LISP infrastructure. 280 Mixed Locator-Sets: this is a locator-set for a LISP database 281 mapping entry where the RLOC addresses in the locator-set are in 282 both IPv4 and IPv6 format. 284 Unicast PIM Join/Prune Message: this is a standard PIM Join/Prune 285 message (encapsulated in an IP header with protocol number 103) 286 which is sent by ETRs at multicast receiver sites to an ITR at a 287 multicast source site. This message is sent periodically as long 288 as there are interfaces in the oif-list for the (S-EID,G) entry 289 the ETR is joining for. 291 4. Basic Overview 293 LISP, when used for unicast routing, increases the site's ability to 294 control ingress traffic flows. Egress traffic flows are controlled 295 by the IGP in the source site. For multicast, the IGP coupled with 296 PIM can decide which path multicast packets ingress. By using the 297 traffic engineering features of LISP, a multicast source site can 298 control the egress of its multicast traffic. By controlling the 299 priorities of locators from a mapping database entry, a source 300 multicast site can control which way multicast receiver sites join to 301 the source site. 303 At this point in time, we don't see a requirement for different 304 locator-sets, priority, and weight policies for multicast than we 305 have for unicast. 307 The fundamental multicast forwarding model is to encapsulate a 308 multicast packet into another multicast packet. An ITR will 309 encapsulate multicast packets received from sources that it serves in 310 another LISP multicast header. The destination group address from 311 the inner header is copied to the destination address of the outer 312 header. The inner source address is the EID of the multicast source 313 host and the outer source address is the RLOC of the encapsulating 314 ITR. 316 The LISP-Multicast architecture will follow this high-level protocol 317 and operational sequence: 319 1. Receiver hosts in multicast sites will join multicast content the 320 way they do today, they use IGMP. When they use IGMPv3 where 321 they specify source addresses, they use source EIDs, that is they 322 join (S-EID,G). If the S-EID is a local multicast source host. 323 If the multicast source is external to this receiver site, the 324 PIM Join/Prune message flows toward the ETRs, finding the 325 shortest exit (that is the closest exit for the Join/Prune 326 message but it is the closest entrance for the multicast packet 327 to the receiver). 329 2. The ETR does a mapping database lookup for S-EID. If the mapping 330 is cached from a previous lookup (from either a previous Join/ 331 Prune for the source multicast site or a unicast packet that went 332 to the site), it will use the RLOC information from the mapping. 333 The ETR will use the same priority and weighting mechanism as for 334 unicast. So the source site can decide which way multicast 335 packets egress. 337 3. The ETR will build two PIM Join/Prune messages, one that contains 338 a (S-EID,G) entry that is unicast to the ITR that matches the 339 RLOC the ETR selects, and the other which contains a (S-RLOC,G) 340 entry so the core network can create multicast state from this 341 ETR to the ITR. 343 4. When the ITR gets the unicast Join/Prune message (see Section 3 344 for formal definition), it will process (S-EID,G) entries in the 345 message and propagate them inside of the site where it has 346 explicit routing information for EIDs via the IGP. When the ITR 347 receives the (S-RLOC,G) PIM Join/Prune message it will process it 348 like any other join it would get in today's Internet. The S-RLOC 349 address is the IP address of this ITR. 351 5. At this point there is (S-EID,G) state from the joining host in 352 the receiver multicast site to the ETR of the receiver multicast 353 site. There is (S-RLOC,G) state across the core network from the 354 ETR of the multicast receiver site to the ITR in the multicast 355 source site and (S-EID,G) state in the source multicast site. 356 Note, the (S-EID,G) state is the same S-EID in each multicast 357 site. As other ETRs join the same multicast tree, they can join 358 through the same ITR (in which case the packet replication is 359 done in the core) or a different ITR (in which case the packet 360 replication is done at the source site). 362 6. When a packet is originated by the multicast host in the source 363 site, it will flow to one or more ITRs which will prepend a LISP 364 header by copying the group address to the outer destination 365 address field and insert its own locator address in the outer 366 source address field. The ITR will look at its (S-RLOC,G) state, 367 where S-RLOC is its own locator address, and replicate the packet 368 on each interface a (S-RLOC,G) joined was received on. The core 369 has (S-RLOC,G) so where fanout occurs to multiple sites, a core 370 router will do packet replication. 372 7. When either the source site or the core replicates the packet, 373 the ETR will receive a LISP packet with a destination group 374 address. It will also decapsulate packets because it has 375 receivers for the group. Otherwise, it would have not received 376 the packets because it would not have joined. The ETR 377 decapsulates and does a (S-EID,G) lookup in its multicast FIB to 378 forward packets out one or more interfaces to forward the packet 379 to internal receivers. 381 This architecture is consistent and scalable with the architecture 382 presented in [LISP] where multicast state in the core operates on 383 locators and multicast state at the sites operates on EIDs. 385 Alternatively, [LISP] does present a mechanism where (S-EID,G) state 386 can reside in the core through the use of RPF-vectors [RPFV] in PIM 387 Join/Prune messages. However, this will require EID state in core as 388 well as the use of RPF-vector formatted Join/Prune messages which are 389 not the default implementation choice. So we choose a design that 390 can allow the separation of namespaces as unicast LISP provides. It 391 will be at the expense of creating new (S-RLOC,G) state when ITRs go 392 unreachable. See Section 5 for details. 394 However, we have some observations on the algorithm above. We can 395 scale the control plane but at the expense of sending data to sites 396 which may have not joined the distribution tree where the 397 encapsulated data is being delivered. For example, one site joins 398 (S-EID1,G) and another site joins (S-EID2,G). Both EIDs are in the 399 same multicast source site. Both multicast receiver sites join to 400 the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the 401 ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the 402 site. The ITR receives (S-RLOC,G) joins and populates the oif-list 403 state for it. Since both (S-EID1,G) and (S-EID2, G) map to the one 404 (S-RLOC,G) packets will be delivered by the core to both multicast 405 receiver sites even though each have joined a single source-based 406 distribution tree. This behavior is a consequence of the many-to-one 407 mapping between S-EIDs and a S-RLOC. 409 There is a possible solution to this problem which reduces the number 410 of many-to-one occurrences of (S-EID,G) entries aggregating into a 411 single (S-RLOC,G) entry. If a physical ITR can be assigned multiple 412 RLOC addresses and these addresses are advertised in mapping database 413 entries, then ETRs at receiver sites have more RLOC address options 414 and therefore can join different (RLOC,G) entries for each (S-EID,G) 415 entry joined at the receiver site. It would not scale to have a one- 416 to-one relationship between the number of S-EID sources at a source 417 site and the number of RLOCs assigned to all ITRs at the site, but we 418 can reduce the "n" to a smaller number in the "n-to-1" relationship. 419 And in turn, reduce the opportunity for data packets to be delivered 420 to sites for groups not joined. 422 5. Source Addresses versus Group Addresses 424 Multicast group addresses don't have to be associated with either the 425 EID or RLOC namespace. They actually are a namespace of their own 426 that can be treated as logical with relatively opaque allocation. 427 So, by their nature, they don't detract from an incremental 428 deployment of LISP-Multicast. 430 As for source addresses, as in the unicast LISP scenario, there is a 431 decoupling of identification from location. In a LISP site, packets 432 are originated from hosts using their allocated EIDs, those addresses 433 are used to identify the host as well as where in the site's topology 434 the host resides but not how and where it is attached to the 435 Internet. 437 Therefore, when multicast distribution tree state is created anywhere 438 in the network on the path from the any multicast receiver to a 439 multicast source, EID state is maintained at the source and receiver 440 multicast sites, and RLOC state is maintained in the core. That is, 441 a multicast distribution tree will be represented as a 3-tuple of 442 {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the 443 3-tuple is the state stored in routers from the source to one or more 444 ITRs in the source multicast site, the second element of the 3-tuple 445 is the state stored in routers downstream of the ITR, in the core, to 446 all LISP receiver multicast sites, and the third element in the 447 3-tuple is the state stored in the routers downstream of each ETR, in 448 each receiver multicast site, reaching each receiver. Note that 449 (S-EID,G) is the same in both the source and receiver multicast 450 sites. 452 The concatenation/mapping from the first element to the second 453 element of the 3-tuples is done by the ITR and from the second 454 element to the third element is done at the ETRs. 456 6. Locator Reachability Implications on LISP-Multicast 458 Multicast state as it is stored in the core is always (S,G) state as 459 it exists today or (S-RLOC,G) state as it will exist when LISP sites 460 are deployed. The core routers cannot distinguish one from the 461 other. They don't need to because it is state that RPFs against the 462 core routing tables in the RLOC namespace. The difference is where 463 the root of the distribution tree for a particular source is. In the 464 traditional multicast core, the source S is the source host's IP 465 address. For LISP-Multicast the source S is a single ITR of the 466 multicast source site. 468 An ITR is selected based on the LISP EID-to-RLOC mapping used when an 469 ETR propagates a PIM Join/Prune message out of a receiver multicast 470 site. The selection is based on the same algorithm an ITR would use 471 to select an ETR when sending a unicast packet to the site. In the 472 unicast case, the ITR can change on a per-packet basis depending on 473 the reachability of the ETR. So an ITR can change relatively easily 474 using local reachability state. However, in the multicast case, when 475 an ITR goes unreachable, new distribution tree state must be built 476 because the encapsulating root has changed. This is more significant 477 than an RPF-change event, where any router would typically locally 478 change its RPF-interface for its existing tree state. But when an 479 encapsulating LISP-Multicast ITR goes unreachable, new distribution 480 state must be rebuilt and reflect the new encapsulator. Therefore, 481 when an ITR goes unreachable, all ETRs that are currently joined to 482 that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) 483 to the new ITR as well as send a unicast Join/Prune message telling 484 the new ITR which (S-EID,G) is being joined. 486 This issue can be mitigated by using anycast addressing for the ITRs 487 so the problem does reduce to an RPF change in the core, but still 488 requires a unicast Join/Prune message to tell the new ITR about 489 (S-EID,G). The problem with this approach is that the ETR really 490 doesn't know when the ITR has changed so the new anycast ITR will get 491 the (S-EID,G) state only when the ETR sends it the next time during 492 its periodic sending procedures. 494 7. Multicast Protocol Changes 496 A number of protocols are used today for inter-domain multicast 497 routing: 499 IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for 500 LISP-Multicast for two reasons. One being that they are link- 501 local and not used over site boundaries and second they advertise 502 group addresses that don't need translation. Where source 503 addresses are supplied in IGMPv3 and MLDv2 messages, they are 504 semantically regarded as EIDs and don't need to be converted to 505 RLOCs until the multicast tree-building protocol, such as PIM, is 506 received by the ETR at the site boundary. Addresses used for IGMP 507 and MLD come out of the source site's allocated addresses which 508 are therefore from the EID namespace. 510 MBGP: Even though MBGP is not a multicast routing protocol, it is 511 used to find multicast sources when the unicast BGP peering 512 topology and the multicast MBGP peering topology are not 513 congruent. When MBGP is used in a LISP-Multicast environment, the 514 prefixes which are advertised are from the RLOC namespace. This 515 allows receiver multicast sites to find a path to the source 516 multicast site's ITRs. MBGP peering addresses will be from the 517 RLOC namespace. 519 MSDP: MSDP is used to announce active multicast sources to other 520 routing domains (or LISP sites). The announcements come from the 521 PIM Rendezvous Points (RPs) from sites where there are active 522 multicast sources sending to various groups. In the context of 523 LISP-Multicast, the source addresses advertised in MSDP will 524 semantically be from the EID namespace since they describe the 525 identity of a source multicast host. It will be true that the 526 state stored in MSDP caches from core routers will be from the EID 527 namespace. An RP address inside of site will be from the EID 528 namespace so it can be advertised and reached by internal unicast 529 routing mechanism. However, for MSDP peer-RPF checking to work 530 properly across sites, the RP addresses must be converted or 531 mapped into a routable address that is advertised and maintained 532 in the BGP routing tables in the core. MSDP peering addresses can 533 come out of either the EID or a routable address namespace. And 534 the choice can be made unilaterally because the ITR at the site 535 will determine which namespace the destination peer address is out 536 of by looking in the mapping database service. 538 PIM-SSM: In the simplest form of distribution tree building, when 539 PIM operates in SSM mode, a source distribution tree is built and 540 maintained across site boundaries. In this case, there is a small 541 modification to the operation of the PIM protocol (but not to any 542 message format) to support taking a Join/Prune message originated 543 inside of a LISP site with embedded addresses from the EID 544 namespace and converting them to addresses from the RLOC namespace 545 when the Join/Prune message crosses a site boundary. This is 546 similar to the requirements documented in [MNAT]. 548 PIM-Bidir: Bidirectional PIM is typically run inside of a routing 549 domain, but if deployed in an inter-domain environment, one would 550 have to decide if the RP address of the shared-tree would be from 551 the EID namespace or the RLOC namespace. If the RP resides in a 552 site-based router, then the RP address is from the EID namespace. 553 If the RP resides in the core where RLOC addresses are routed, 554 then the RP address is from the RLOC namespace. This could be 555 easily distinguishable if the EID address were well-known address 556 allocation block from the RLOC namespace. Also, when using 557 Embedded-RP for RP determination [RFC3956], the format of the 558 group address could indicate the namespace the RP address is from. 559 However, refer to Section 10 for considerations core routers need 560 to make when using Embedded-RP IPv6 group addresses. With respect 561 to DF-election in Bidir PIM, no changes are required since all 562 messaging and addressing is link-local. 564 PIM-ASM: The way ASM mode PIM, the most popular form of PIM, is 565 deployed in the Internet today is by having shared-trees within a 566 site and using source-trees across sites. By the use of MSDP and 567 PIM-SSM techniques described above, we can get multicast 568 connectivity across LISP sites. Having said that, that means 569 there are no special actions required for processing (*,G) or 570 (S,G,R) Join/Prune messages since they all operate against the 571 shared-tree which is site resident. This is also true for the RP- 572 mapping mechanisms Auto-RP and BSR. 574 Based on the protocol description above, the conclusion is that there 575 are no protocol message format changes, just a translation function 576 performed at the control-plane. This will make for an easier and 577 faster transition for LISP since fewer components in the network have 578 to change. 580 It should also be stated just like it is in [LISP] that no host 581 changes, whatsoever, are required to have a multicast source host 582 send multicast packets and for a multicast receiver host to receive 583 multicast packets. 585 8. LISP-Multicast Data-Plane Architecture 587 The LISP-Multicast data-plane operation conforms to the operation and 588 packet formats specified in [LISP]. However, encapsulating a 589 multicast packet from an ITR is a much simpler process. The process 590 is simply to copy the inner group address to the outer destination 591 address. And to have the ITR use its own IP address (its RLOC), and 592 as the source address. The process is simpler for multicast because 593 there is no EID-to-RLOC mapping lookup performed during packet 594 forwarding. 596 In the decapsulation case, the ETR simply removes the outer header 597 and performs a multicast routing table lookup on the inner header 598 (S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is 599 used to replicate the packet on site-facing interfaces leading to 600 multicast receiver hosts. 602 There is no Data-Probe logic for ETRs as there can be in the unicast 603 forwarding case. 605 8.1. ITR Forwarding Procedure 607 The following procedure is used by an ITR, when it receives a 608 multicast packet from a source inside of its site: 610 1. A multicast data packet sent by a host in a LISP site will have 611 the source address equal to the host's EID and the destination 612 address equal to the group address of the multicast group. It is 613 assumed the group information is obtained by current methods. 614 The same is true for a multicast receiver to obtain the source 615 and group address of a multicast flow. 617 2. When the ITR receives a multicast packet, it will have both S-EID 618 state and S-RLOC state stored. Since the packet was received on 619 a site-facing interface, the RPF lookup is based on the S-EID 620 state. If the RPF check succeeds, then the oif-list contains 621 interfaces that are site-facing and external-facing. For the 622 site-facing interfaces, no LISP header is prepended. For the 623 external-facing interfaces a LISP header is prepended. When the 624 ITR prepends a LISP header, it uses its own RLOC address as the 625 source address and copies the group address supplied by the IP 626 header the host built as the outer destination address. 628 8.2. ETR Forwarding Procedure 630 The following procedure is used by an ETR, when it receives a 631 multicast packet from a source outside of its site: 633 1. When a multicast data packet is received by an ETR on an 634 external-facing interface, it will do an RPF lookup on the S-RLOC 635 state it has stored. If the RPF check succeeds, the interfaces 636 from the oif-list are used for replication to interfaces that are 637 site-facing as well as interfaces that are external-facing (this 638 ETR can also be a transit multicast router for receivers outside 639 of its site). When the packet is to be replicated for an 640 external-facing interface, the LISP encapsulation header are not 641 stripped. When the packet is replicated for a site-facing 642 interface, the encapsulation header is stripped. 644 2. The packet without a LISP header is now forwarded down the 645 (S-EID,G) distribution tree in the receiver multicast site. 647 8.3. Replication Locations 649 Multicast packet replication can happen in the following topological 650 locations: 652 o In an IGP multicast router inside a site which operates on S-EIDs. 654 o In a transit multicast router inside of the core which operates on 655 S-RLOCs. 657 o At one or more ETR routers depending on the path a Join/Prune 658 message exits a receiver multicast site. 660 o At one or more ITR routers in a source multicast site depending on 661 what priorities are returned in a Map-Reply to receiver multicast 662 sites. 664 In the last case the source multicast site can do replication rather 665 than having a single exit from the site. But this only can occur 666 when the priorities in the Map-Reply are modified for different 667 receiver multicast site so that the PIM Join/Prune messages arrive at 668 different ITRs. 670 This policy technique, also used in [ALT] for unicast, is useful for 671 multicast to mitigate the problems of changing distribution tree 672 state as discussed in Section 6. 674 9. LISP-Multicast Interworking 676 This section will describe the multicast corollary to [INTWORK] which 677 describes the interworking of multicast routing among LISP and non- 678 LISP sites. 680 9.1. LISP and non-LISP Mixed Sites 682 Since multicast communication can involve more than two entities to 683 communicate together, the combinations of interworking scenarios are 684 more involved. However, the state maintained for distribution trees 685 at the sites is the same regardless of whether or not the site is 686 LISP enabled or not. So most of the implications are in the core 687 with respect to storing routable EID prefixes from either PA or PI 688 blocks. 690 Before we enumerate the multicast interworking scenarios, we must 691 define 3 deployment states of a site: 693 o A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it 694 does today. The addresses for the site are globally routable. 696 o A site that deploys LISP for unicast routing. The addresses for 697 the site are not globally routable. Let's define the name for 698 this type of site as a uLISP site. 700 o A site that deploys LISP for both unicast and multicast routing. 701 The addresses for the site are not globally routable. Let's 702 define the name for this type of site as a LISP-Multicast site. 704 We will not consider a LISP site enabled for multicast purposes only 705 but do consider a uLISP site as documented in [INTWORK]. In this 706 section we don't discuss how a LISP site sends multicast packets when 707 all receiver sites are LISP-Multicast enabled; that has been 708 discussed in previous sections. 710 The following scenarios exist to make LISP-Multicast sites interwork 711 with non-LISP-Multicast sites: 713 1. A LISP site must be able to send multicast packets to receiver 714 sites which are a mix of non-LISP sites and uLISP sites. 716 2. A non-LISP site must be able to send multicast packets to 717 receiver sites which are a mix of non-LISP sites and uLISP sites. 719 3. A non-LISP site must be able to send multicast packets to 720 receiver sites which are a mix of LISP sites, uLISP sites, and 721 non-LISP sites. 723 4. A uLISP site must be able to send multicast packets to receiver 724 sites which are a mix of LISP sites, uLISP sites, and non-LISP 725 sites. 727 5. A LISP site must be able to send multicast packets to receiver 728 sites which are a mix of LISP sites, uLISP sites, and non-LISP 729 sites. 731 9.1.1. LISP Source Site to non-LISP Receiver Sites 733 In the first scenario, a site is LISP capable for both unicast and 734 multicast traffic and as such operates on EIDs. Therefore there is a 735 possibility that the EID prefix block is not routable in the core. 736 For LISP receiver multicast sites this isn't a problem but for non- 737 LISP or uLISP receiver multicast sites, when a PIM Join/Prune message 738 is received by the edge router, it has no route to propagate the 739 Join/Prune message out of the site. This is no different than the 740 unicast case that LISP-NAT in [INTWORK] solves. 742 LISP-NAT allows a unicast packet that exits a LISP site to get its 743 source address mapped to a globally routable address before the ITR 744 realizes that it should not encapsulate the packet destined to a non- 745 LISP site. For a multicast packet to leave a LISP site, distribution 746 tree state needs to be built so the ITR can know where to send the 747 packet. So the receiver multicast sites need to know about the 748 multicast source host by its routable address and not its EID 749 address. When this is the case, the routable address is the 750 (S-RLOC,G) state that is stored and maintained in the core routers. 751 It is important to note that the routable address for the host cannot 752 be the same as an RLOC for the site. Because we want the ITRs to 753 process a received PIM Join/Prune message from an external-facing 754 interface to be propagated inside of the site so the site-part of the 755 distribution tree is built. 757 Using a globally routable source address allows non-LISP and uLISP 758 multicast receiver to join, create, and maintain a multicast 759 distribution tree. However, the LISP multicast receiver site will 760 want to perform an EID-to-RLOC mapping table lookup when a PIM Join/ 761 Prune message is received on a site-facing interface. It does this 762 because it wants to find a (S-RLOC,G) entry to Join in the core. So 763 we have a conflict of behavior between the two types of sites. 765 The solution to this problem is the same as when an ITR wants to send 766 a unicast packet to a destination site but needs determine if the 767 site is LISP capable or not. When it is not LISP capable, the ITR 768 does not encapsulate the packet. So for the multicast case, when ETR 769 receives a PIM Join/Prune message for (S-EID,G) state, it will do a 770 mapping table lookup on S-EID. In this case, S-EID is not in the 771 mapping database because the source multicast site is using a 772 routable address and not an EID prefix address. So the ETR knows to 773 simply propagate the PIM Join/Prune message to a external-facing 774 interface without converting the (S-EID,G) because it is an (S,G) 775 where S is routable and reachable via core routing tables. 777 Now that the multicast distribution tree is built and maintained from 778 any non-LISP or uLISP receiver multicast site, the way packet 779 forwarding model is performed can be explained. 781 Since the ITR in the source multicast site has never received a 782 unicast PIM Join/Prune message from any ETR in a receiver multicast 783 site, it knows there are no LISP-Multicast receiver sites. 784 Therefore, there is no need for the ITR to encapsulate data. Since 785 it will know a priori (via configuration) that its site's EIDs are 786 not routable, it assumes that the multicast packets from the source 787 host are sent by a routable address. That is, it is the 788 responsibility of the multicast source host's system administrator to 789 ensure that the source host sends multicast traffic using a routable 790 source address. When this happens, the ITR acts simply as a router 791 and forwards the multicast packet like an ordinary multicast router. 793 There is an alternative to using a LISP-NAT scheme just like there is 794 for unicast [INTWORK] forwarding by using Proxy Tunnel Routers 795 (PTRs). This can work the same way for multicast routing as well, 796 but the difference is that non-LISP and uLISP sites will send PIM 797 Join/Prune messages for (S-EID,G) which make their way in the core to 798 PTRs. Let's call this use of a PTR as a "Multicast PTR" (or mPTR). 799 Since the PTRs advertise very coarse EID prefixes, they draw the PIM 800 Join/Prune control traffic making them the target of the distribution 801 tree. To get multicast packets from the LISP source multicast sites, 802 the tree needs to be built on the path from the mPTR to the LISP 803 source multicast site. To make this happen the mPTR acts as a "Proxy 804 ETR" (where in unicast it acts as a "Proxy ITR"). 806 The existence of mPTRs in the core allows LISP source multicast site 807 ITRs to encapsulate multicast packets so the state built between the 808 ITRs and the mPTRs is (S-RLOC,G) state. Then the mPTRs can 809 decapsulate packets and forward natively to the non-LISP and uLISP 810 receiver multicast sites. 812 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites 814 Clearly non-LISP multicast sites can send multicast packets to non- 815 LISP receiver multicast sites. That is what they do today. However, 816 discussion is required to show how non-LISP multicast sites send 817 multicast packets to uLISP receiver multicast sites. 819 Since uLISP receiver multicast sites are not targets of any (S,G) 820 state, they simply send (S,G) PIM Join/Prune messages toward the non- 821 LISP source multicast site. Since the source multicast site, in this 822 case has not been upgraded to LISP, all multicast source host 823 addresses are routable. So this case is simplified to where a uLISP 824 receiver multicast site looks to the source multicast site as a non- 825 LISP receiver multicast site. 827 9.1.3. Non-LISP Source Site to Any Receiver Site 829 When a non-LISP source multicast site has receivers in either a non- 830 LISP/uLISP site or a LISP site, one needs to decide how the LISP 831 receiver multicast site will attach to the distribution tree. We 832 know from Section 9.1.2 that non-LISP and uLISP receiver multicast 833 sites can join the distribution tree, but a LISP receiver multicast 834 site ETR will need to know if the source address of the multicast 835 source host is routable or not. We showed in Section 9.1.1 that an 836 ETR, before it sends a PIM Join/Prune message on an external-facing 837 interface, does a EID-to-RLOC mapping lookup to determine if it 838 should convert the (S,G) state from a PIM Join/Prune message received 839 on a site-facing interface to a (S-RLOC,G). If the lookup fails, the 840 ETR can conclude the source multicast site is a non-LISP site so it 841 simply forwards the Join/Prune message (it also doesn't need to send 842 a unicast Join/Prune message because there is no ITR in a non-LISP 843 site and there is namespace continuity between the ETR and source). 845 9.1.4. Unicast LISP Source Site to Any Receiver Sites 847 In the last section, it was explained how an ETR in a multicast 848 receiver site can determine if a source multicast site is LISP- 849 enabled by looking into the mapping database. When the source 850 multicast site is a uLISP site, it is LISP enabled but the ITR, by 851 definition is not capable of doing multicast encapsulation. So for 852 the purposes of multicast routing, the uLISP source multicast site is 853 treated as non-LISP source multicast site. 855 Non-LISP receiver multicast sites can join distribution trees to a 856 uLISP source multicast site since the source site behaves, from a 857 forwarding perspective, as a non-LISP source site. This is also the 858 case for a uLISP receiver multicast site since the ETR does not have 859 multicast functionality built-in or enabled. 861 Special considerations are required for LISP receiver multicast sites 862 since they think the source multicast site is LISP capable, the ETR 863 cannot know if ITR is LISP-Multicast capable. To solve this problem, 864 each mapping database entry will have a multicast 2-tuple (Mpriority, 865 Mweight) per RLOC. When the Mpriority is set to 255, the site is 866 considered not multicast capable. So an ETR in a LISP receiver 867 multicast site can distinguish whether a LISP source multicast site 868 is LISP-Multicast site from a uLISP site. 870 9.1.5. LISP Source Site to Any Receiver Sites 872 When a LISP source multicast site has receivers in LISP, non-LISP, 873 and uLISP receiver multicast sites, it has a conflict about how it 874 sends multicast packets. The ITR can either encapsulate or natively 875 forward multicast packets. Since the receiver multicast sites are 876 heterogeneous in their behavior, one packet forwarding mechanism 877 cannot satisfy both. However, if a LISP receiver multicast site acts 878 like a uLISP site then it could receive packets like a non-LISP 879 receiver multicast site making all receiver multicast sites have 880 homogeneous behavior. However, this poses the following issues: 882 o LISP-NAT techniques with routable addresses would be required in 883 all cases. 885 o Or alternatively, mPTR deployment would be required forcing coarse 886 EID prefix advertisement in the core. 888 o But what is most disturbing is that when all sites that 889 participate are LISP-Multicast sites but then a non-LISP or uLISP 890 site joins the distribution tree, then the existing joined LISP 891 receiver multicast sites would have to change their behavior. 892 This would create too much dynamic tree-building churn to be a 893 viable alternative. 895 So the solution space options are: 897 1. Make the LISP ITR in the source multicast site send two packets, 898 one that is encapsulated with (S-RLOC,G) to reach LISP receiver 899 multicast sites and another that is not encapsulated with 900 (S-EID,G) to reach non-LISP and uLISP receiver multicast sites. 902 2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to 903 reach LISP-Multicast sites and to reach mPTRs that can 904 decapsulate and forward (S-EID,G) packets to non-LISP and uLISP 905 receiver multicast sites. 907 9.2. LISP Sites with Mixed Address Families 909 A LISP database mapping entry that describes the locator-set, 910 Mpriority and Mweight per locator address (RLOC), for an EID prefix 911 associated with a site could have RLOC addresses in either IPv4 or 912 IPv6 format. When a mapping entry has a mix of RLOC formatted 913 addresses, it is an implicit advertisement by the site that it is a 914 dual-stack site. That is, the site can receive IPv4 or IPv6 unicast 915 packets. 917 To distinguish if the site can receive dual-stack unicast packets as 918 well as dual-stack multicast packets, the Mpriority value setting 919 will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format 920 details. 922 If you consider the combinations of LISP, non-LISP, and uLISP sites 923 sharing the same distribution tree and considering the capabilities 924 of supporting IPv4, IPv6, or dual-stack, the number of total 925 combinations grows beyond comprehension. 927 Using some combinatorial math, we have the following profiles of a 928 site and the combinations that can occur: 930 1. LISP-Multicast IPv4 Site 932 2. LISP-Multicast IPv6 Site 934 3. LISP-Multicast Dual-Stack Site 936 4. uLISP IPv4 Site 938 5. uLISP IPv6 Site 940 6. uLISP Dual-Stack Site 942 7. non-LISP IPv4 Site 944 8. non-LISP IPv6 Site 946 9. non-LISP Dual-Stack Site 948 Lets define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to 949 illustrate some combinatorial math below. 951 When 1 site talks to another site, the combinatorial is (9 2), when 1 952 site talks to another 2 sites, the combinatorial is (9 3). If sum 953 this up to (9 9), we have: 955 (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) = 957 36 + 84 + 126 + 126 + 84 + 36 + 9 + 1 959 Which results in the total number of cases to be considered at 502. 961 This combinatorial gets even worse when you consider a site using one 962 address family inside of the site and the xTRs use the other address 963 family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4 964 RLOCs). 966 To rationalize this combinatorial nightmare, there are some 967 guidelines which need to be put in place: 969 o Each distribution tree shared among sites will either be an IPv4 970 distribution tree or an IPv6 distribution tree. Therefore, we can 971 avoid head-end replication by building and sending packets on each 972 address family based distribution tree. Even though there might 973 be an urge to do multicast packet translation from one address 974 family format to the other, it is a non-viable over-complicated 975 urge. 977 o All LISP sites on a multicast distribution tree must share a 978 common address family which is determined by the source site's 979 locator-set in its LISP database mapping entry. All receiver 980 multicast sites will use the best RLOC priority controlled by the 981 source multicast site. This is true when the source site is 982 either LISP-Multicast or uLISP capable. This means that priority- 983 based policy modification is prohibited. 985 o When the source site is not LISP capable, it is up to how 986 receivers find the source and group information for a multicast 987 flow. That mechanism decides the address family for the flow. 989 9.3. Making a Multicast Interworking Decision 991 This Multicast Interworking section has shown all combinations of 992 multicast connectivity that could occur. As you might have already 993 concluded, this can be quite complicated and if the design is too 994 ambitious, the dynamics of the protocol could cause a lot of 995 instability. 997 The trade-off decisions are hard to make and we want the same single 998 solution to work for both IPv4 and IPv6 multicast. It is imperative 999 to have an incrementally deployable solution for all of IPv4 unicast 1000 and multicast and IPv6 unicast and multicast while minimizing (or 1001 eliminating) both unicast and multicast EID namespace state. 1003 Therefore the design decision to go with PTRs for unicast routing and 1004 mPTRs for multicast routing seems to be the sweet spot in the 1005 solution space so we can optimize state requirements and avoid head- 1006 end data replication at ITRs. 1008 10. Considerations when RP Addresses are Embedded in Group Addresses 1010 When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a 1011 technique exists to embed the unicast address of an RP in a IPv6 1012 group address [RFC3956]. When routers in end sites process a PIM 1013 Join/Prune message which contain an embedded-RP group address, they 1014 extract the RP address from the group address and treat it from the 1015 EID namespace. However, core routers do not have state for the EID 1016 namespace, need to extract an RP address from the RLOC namespace. 1018 Therefore, it is the responsibility of ETRs in multicast receiver 1019 sites to map the group address into a group address where the 1020 embedded-RP address is from the RLOC namespace. The mapped RP- 1021 address is obtained from a EID-to-RLOC mapping database lookup. The 1022 ETR will also send a unicast (*,G) Join/Prune message to the ITR so 1023 the branch of the distribution tree from the source site resident RP 1024 to the ITR is created. 1026 This technique is no different than the techniques described in this 1027 specification for translating (S,G) state and propagating Join/Prune 1028 messages into the core. The only difference is that the (*,G) state 1029 in Join/Prune messages are mapped because they contain unicast 1030 addresses encoded in an Embedded-RP group address. 1032 11. Taking Advantage of Upgrades in the Core 1034 If the core routers are upgraded to support [RPFV] and [JOIN-ATTR], 1035 then we can pass EID specific data through the core without, 1036 possibly, having to store the state in the core. 1038 By doing this we can eliminate the ETR from unicasting PIM Join/Prune 1039 messages to the source site's ITR. 1041 12. Security Considerations 1043 Refer to the [LISP] specification. 1045 13. Acknowledgments 1047 The authors would like to gratefully acknowledge the people who have 1048 contributed discussion, ideas, and commentary to the making of this 1049 proposal and specification. People who provided expert review were 1050 Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from 1051 discussions at Summer 2008 Dublin IETF were Toerless Eckert and 1052 Ijsbrand Wijnands. 1054 We would also like to thank the MBONED working group for constructive 1055 and civil verbal feedback when this draft was presented at the Fall 1056 2008 IETF in Minneapolis. In particular, good commentary came from 1057 Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, 1058 Ron Bonica, and Lenny Guardino. 1060 This work originated in the Routing Research Group (RRG) of the IRTF. 1061 The individual submission [MLISP] was converted into this IETF LISP 1062 working group draft. 1064 14. References 1066 14.1. Normative References 1068 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1069 Requirement Levels", BCP 14, RFC 2119, March 1997. 1071 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 1072 Protocol (MSDP)", RFC 3618, October 2003. 1074 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1075 Point (RP) Address in an IPv6 Multicast Address", 1076 RFC 3956, November 2004. 1078 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1079 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1080 Protocol Specification (Revised)", RFC 4601, August 2006. 1082 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1083 Group Management Protocol Version 3 (IGMPv3) and Multicast 1084 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1085 Specific Multicast", RFC 4604, August 2006. 1087 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1088 IP", RFC 4607, August 2006. 1090 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1091 "Multiprotocol Extensions for BGP-4", RFC 4760, 1092 January 2007. 1094 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1095 "Bidirectional Protocol Independent Multicast (BIDIR- 1096 PIM)", RFC 5015, October 2007. 1098 14.2. Informative References 1100 [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative 1101 Topology (LISP-ALT)", draft-fuller-lisp-alt-02.txt (work 1102 in progress), April 2008. 1104 [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP 1105 with IPv4 and IPv6", draft-lewis-lisp-interworking-00.txt 1106 (work in progress), December 2007. 1108 [JOIN-ATTR] 1109 Wijnands, IJ. and A. Boers, "Format for using TLVs in PIM 1110 messages", draft-ietf-pim-join-attributes-03.txt (work in 1111 progress), May 2007. 1113 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1114 "Locator/ID Separation Protocol (LISP)", 1115 draft-ietf-lisp-00.txt (work in progress), May 2009. 1117 [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, 1118 "LISP for Multicast Environments", 1119 draft-farinacci-lisp-multicast-01.txt (work in progress), 1120 November 2008. 1122 [MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a 1123 Network Address (and port) Translator (NAT)", 1124 draft-ietf-behave-multicast-07.txt (work in progress), 1125 June 2007. 1127 [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector 1128 TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress), 1129 February 2008. 1131 Authors' Addresses 1133 Dino Farinacci 1134 cisco Systems 1135 Tasman Drive 1136 San Jose, CA 1137 USA 1139 Email: dino@cisco.com 1141 Dave Meyer 1142 cisco Systems 1143 Tasman Drive 1144 San Jose, CA 1145 USA 1147 Email: dmm@cisco.com 1149 John Zwiebel 1150 cisco Systems 1151 Tasman Drive 1152 San Jose, CA 1153 USA 1155 Email: jzwiebel@cisco.com 1157 Stig Venaas 1158 cisco Systems 1159 Tasman Drive 1160 San Jose, CA 1161 USA 1163 Email: stig@cisco.com