draft-ietf-lisp-multicast-05.txt		draft-ietf-lisp-multicast-06.txt
	Network Working Group D. Farinacci		Network Working Group D. Farinacci
	Internet-Draft D. Meyer		Internet-Draft D. Meyer
	Intended status: Experimental J. Zwiebel		Intended status: Experimental J. Zwiebel
	Expires: October 7, 2011 S. Venaas		Expires: December 22, 2011 S. Venaas
	cisco Systems		cisco Systems
	April 5, 2011		June 20, 2011
	LISP for Multicast Environments		LISP for Multicast Environments
	draft-ietf-lisp-multicast-05		draft-ietf-lisp-multicast-06
	Abstract		Abstract
	This draft describes how inter-domain multicast routing will function		This draft describes how inter-domain multicast routing will function
	in an environment where Locator/ID Separation is deployed using the		in an environment where Locator/ID Separation is deployed using the
	LISP architecture.		LISP architecture.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	skipping to change at page 1, line 40		skipping to change at page 1, line 40
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on October 7, 2011.		This Internet-Draft will expire on December 22, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 25		skipping to change at page 2, line 25
	3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7		3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7
	4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 10		4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
	5. Source Addresses versus Group Addresses . . . . . . . . . . . 13		5. Source Addresses versus Group Addresses . . . . . . . . . . . 13
	6. Locator Reachability Implications on LISP-Multicast . . . . . 14		6. Locator Reachability Implications on LISP-Multicast . . . . . 14
	7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 15		7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 15
	8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 17		8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 17
	8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 17		8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 17
	8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 17		8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 17
	8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 18		8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 18
	8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 18		8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 18
	8.3. Replication Locations . . . . . . . . . . . . . . . . . . 18		8.3. Replication Locations . . . . . . . . . . . . . . . . . . 19
	9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 20		9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 20
	9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 20		9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 20
	9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 21		9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 21
	9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 22		9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 22
	9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 23		9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 23
	9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 24		9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 24
	9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 24		9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 24
	9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 25		9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 25
	9.3. Making a Multicast Interworking Decision . . . . . . . . . 27		9.3. Making a Multicast Interworking Decision . . . . . . . . . 27
	10. Considerations when RP Addresses are Embedded in Group		10. Considerations when RP Addresses are Embedded in Group
	Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 28		Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 29		11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 29
	12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 30		12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 30
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 31		13. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32		14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33		15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
	15.1. Normative References . . . . . . . . . . . . . . . . . . . 33		15.1. Normative References . . . . . . . . . . . . . . . . . . . 33
	15.2. Informative References . . . . . . . . . . . . . . . . . . 33		15.2. Informative References . . . . . . . . . . . . . . . . . . 33
	Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 35		Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 35
	A.1. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 35		A.1. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 35
	A.2. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 35		A.2. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 35
	A.3. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 35		A.3. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 35
	A.4. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 35		A.4. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 35
	A.5. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 36		A.5. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 36
	A.6. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 36		A.6. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 36
			A.7. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
	1. Requirements Notation		1. Requirements Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	skipping to change at page 9, line 23		skipping to change at page 9, line 23
	uLISP Site: a unicast only LISP site according to [LISP] which has		uLISP Site: a unicast only LISP site according to [LISP] which has
	not deployed the procedures of this specification and therefore,		not deployed the procedures of this specification and therefore,
	for multicast purposes, follows the procedures from Section 9.		for multicast purposes, follows the procedures from Section 9.
	mPETR: this is a multicast proxy-ETR that is responsible for		mPETR: this is a multicast proxy-ETR that is responsible for
	advertising a very coarse EID prefix which non-LISP and uLISP		advertising a very coarse EID prefix which non-LISP and uLISP
	sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs		sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs
	are used so LISP source multicast sites can send multicast packets		are used so LISP source multicast sites can send multicast packets
	using source addresses from the EID namespace. mPETRs act as Proxy		using source addresses from the EID namespace. mPETRs act as Proxy
	ETRs for supporting multicast routing in a LISP infrastructure.		ETRs for supporting multicast routing in a LISP infrastructure.
	It is likely an uPITR and a mPETR will be co-loacted since the		It is likely an uPITR [INTWORK] and a mPETR will be co-located
	single device advertises a coarse EID-prefix in the underlying		since the single device advertises a coarse EID-prefix in the
	unicast routing system.		underlying unicast routing system.
	Mixed Locator-Sets: this is a locator-set for a LISP database		Mixed Locator-Sets: this is a locator-set for a LISP database
	mapping entry where the RLOC addresses in the locator-set are in		mapping entry where the RLOC addresses in the locator-set are in
	both IPv4 and IPv6 format.		both IPv4 and IPv6 format.
	Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM		Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM
	Join/Prune message (encapsulated in a LISP Encapsulated Control		Join/Prune message (encapsulated in a LISP Encapsulated Control
	Message with destination UDP port 4342) which is sent by ETRs at		Message with destination UDP port 4342) which is sent by ETRs at
	multicast receiver sites to an ITR at a multicast source site.		multicast receiver sites to an ITR at a multicast source site.
	This message is sent periodically as long as there are interfaces		This message is sent periodically as long as there are interfaces
	skipping to change at page 10, line 19		skipping to change at page 10, line 19
	by the IGP in the source site. For multicast, the IGP coupled with		by the IGP in the source site. For multicast, the IGP coupled with
	PIM can decide which path multicast packets ingress. By using the		PIM can decide which path multicast packets ingress. By using the
	traffic engineering features of LISP, a multicast source site can		traffic engineering features of LISP, a multicast source site can
	control the egress of its multicast traffic. By controlling the		control the egress of its multicast traffic. By controlling the
	priorities of locators from a mapping database entry, a source		priorities of locators from a mapping database entry, a source
	multicast site can control which way multicast receiver sites join to		multicast site can control which way multicast receiver sites join to
	the source site.		the source site.
	At this point in time, we don't see a requirement for different		At this point in time, we don't see a requirement for different
	locator-sets, priority, and weight policies for multicast than we		locator-sets, priority, and weight policies for multicast than we
	have for unicast.		have for unicast. However, when traffic engineering policies are
			different for unicast versus multicast flows, it will be desirable to
			use multicast-based priority and weight values in Map-Reply messages.
	The fundamental multicast forwarding model is to encapsulate a		The fundamental multicast forwarding model is to encapsulate a
	multicast packet into another multicast packet. An ITR will		multicast packet into another multicast packet. An ITR will
	encapsulate multicast packets received from sources that it serves in		encapsulate multicast packets received from sources that it serves in
	another LISP multicast header. The destination group address from		another LISP multicast header. The destination group address from
	the inner header is copied to the destination address of the outer		the inner header is copied to the destination address of the outer
	header. The inner source address is the EID of the multicast source		header. The inner source address is the EID of the multicast source
	host and the outer source address is the RLOC of the encapsulating		host and the outer source address is the RLOC of the encapsulating
	ITR.		ITR.
	skipping to change at page 18, line 26		skipping to change at page 18, line 26
	Note when ETRs from different multicast receiver sites receive		Note when ETRs from different multicast receiver sites receive
	(S-EID,G) joins, they may select a different S-RLOC for a multicast		(S-EID,G) joins, they may select a different S-RLOC for a multicast
	source site due to policy (the multicast ITR can return different		source site due to policy (the multicast ITR can return different
	multicast priority and weight values per ETR Map-Request). In this		multicast priority and weight values per ETR Map-Request). In this
	case, the same (S-EID,G) is being realized by different (S-RLOC,G)		case, the same (S-EID,G) is being realized by different (S-RLOC,G)
	state in the core. This will not result in duplicate packets because		state in the core. This will not result in duplicate packets because
	each ITR in the multicast source site will choose their own RLOC for		each ITR in the multicast source site will choose their own RLOC for
	the source address for encapsulated multicast traffic. The RLOC		the source address for encapsulated multicast traffic. The RLOC
	addresses are the ones joined by remote multicast ETRs.		addresses are the ones joined by remote multicast ETRs.
			When different (S-EID,G) traffic is combined into a single (RLOC,G)
			core distribution tree, this may cause traffic to go to a receiver
			multicast site when it does not need to. This happens when one
			receiver multicast site joins (S1-EID,Gi) through a core distribution
			tree of (RLOC1,Gi) and another multicast receiver site joins (S2-
			EID,Gi) through the same core distribution tree of (RLOC1,Gi). When
			ETRs decapsulate such traffic, they should know from their local
			(S-EID,G) state if the packet should be forwarded. If there is no
			(S-EID,G) state that matches the inner packet header, the packet is
			discarded.
	8.2. ETR Forwarding Procedure		8.2. ETR Forwarding Procedure
	The following procedure is used by an ETR, when it receives a		The following procedure is used by an ETR, when it receives a
	multicast packet from a source outside of its site:		multicast packet from a source outside of its site:
	1. When a multicast data packet is received by an ETR on an		1. When a multicast data packet is received by an ETR on an
	external-facing interface, it will do an RPF lookup on the S-RLOC		external-facing interface, it will do an RPF lookup on the S-RLOC
	state it has stored. If the RPF check succeeds, the interfaces		state it has stored. If the RPF check succeeds, the interfaces
	from the oif-list are used for replication to interfaces that are		from the oif-list are used for replication to interfaces that are
	site-facing as well as interfaces that are external-facing (this		site-facing as well as interfaces that are external-facing (this
	skipping to change at page 21, line 34		skipping to change at page 21, line 34
	LISP-NAT allows a unicast packet that exits a LISP site to get its		LISP-NAT allows a unicast packet that exits a LISP site to get its
	source address mapped to a globally routable address before the ITR		source address mapped to a globally routable address before the ITR
	realizes that it should not encapsulate the packet destined to a non-		realizes that it should not encapsulate the packet destined to a non-
	LISP site. For a multicast packet to leave a LISP site, distribution		LISP site. For a multicast packet to leave a LISP site, distribution
	tree state needs to be built so the ITR can know where to send the		tree state needs to be built so the ITR can know where to send the
	packet. So the receiver multicast sites need to know about the		packet. So the receiver multicast sites need to know about the
	multicast source host by its routable address and not its EID		multicast source host by its routable address and not its EID
	address. When this is the case, the routable address is the		address. When this is the case, the routable address is the
	(S-RLOC,G) state that is stored and maintained in the core routers.		(S-RLOC,G) state that is stored and maintained in the core routers.
	It is important to note that the routable address for the host cannot		It is important to note that the routable address for the host cannot
	be the same as an RLOC for the site. Because we want the ITRs to		be the same as an RLOC for the site because we want the ITRs to
	process a received PIM Join/Prune message from an external-facing		process a received PIM Join/Prune message from an external-facing
	interface to be propagated inside of the site so the site-part of the		interface to be propagated inside of the site so the site-part of the
	distribution tree is built.		distribution tree is built.
	Using a globally routable source address allows non-LISP and uLISP		Using a globally routable source address allows non-LISP and uLISP
	multicast receiver to join, create, and maintain a multicast		multicast receiver to join, create, and maintain a multicast
	distribution tree. However, the LISP multicast receiver site will		distribution tree. However, the LISP multicast receiver site will
	want to perform an EID-to-RLOC mapping table lookup when a PIM Join/		want to perform an EID-to-RLOC mapping table lookup when a PIM Join/
	Prune message is received on a site-facing interface. It does this		Prune message is received on a site-facing interface. It does this
	because it wants to find a (S-RLOC,G) entry to Join in the core. So		because it wants to find a (S-RLOC,G) entry to Join in the core. So
	skipping to change at page 22, line 19		skipping to change at page 22, line 19
	Now that the multicast distribution tree is built and maintained from		Now that the multicast distribution tree is built and maintained from
	any non-LISP or uLISP receiver multicast site, the way packet		any non-LISP or uLISP receiver multicast site, the way packet
	forwarding model is performed can be explained.		forwarding model is performed can be explained.
	Since the ITR in the source multicast site has never received a		Since the ITR in the source multicast site has never received a
	unicast encapsulated PIM Join/Prune message from any ETR in a		unicast encapsulated PIM Join/Prune message from any ETR in a
	receiver multicast site, it knows there are no LISP-Multicast		receiver multicast site, it knows there are no LISP-Multicast
	receiver sites. Therefore, there is no need for the ITR to		receiver sites. Therefore, there is no need for the ITR to
	encapsulate data. Since it will know a priori (via configuration)		encapsulate data. Since it will know a priori (via configuration)
	that its site's EIDs are not routable, it assumes that the multicast		that its site's EIDs are not routable (and not registered to the
	packets from the source host are sent by a routable address. That		mapping database system), it assumes that the multicast packets from
	is, it is the responsibility of the multicast source host's system		the source host are sent by a routable address. That is, it is the
	administrator to ensure that the source host sends multicast traffic		responsibility of the multicast source host's system administrator to
	using a routable source address. When this happens, the ITR acts		ensure that the source host sends multicast traffic using a routable
	simply as a router and forwards the multicast packet like an ordinary		source address. When this happens, the ITR acts simply as a router
	multicast router.		and forwards the multicast packet like an ordinary multicast router.
	There is an alternative to using a LISP-NAT scheme just like there is		There is an alternative to using a LISP-NAT scheme just like there is
	for unicast [INTWORK] forwarding by using Proxy Tunnel Routers		for unicast [INTWORK] forwarding by using Proxy Tunnel Routers
	(PxTRs). This can work the same way for multicast routing as well,		(PxTRs). This can work the same way for multicast routing as well,
	but the difference is that non-LISP and uLISP sites will send PIM		but the difference is that non-LISP and uLISP sites will send PIM
	Join/Prune messages for (S-EID,G) which make their way in the core to		Join/Prune messages for (S-EID,G) which make their way in the core to
	multicast PxTRs. Let's call this use of a PxTR as a "Multicast		multicast PxTRs. Let's call this use of a PxTR as a "Multicast
	Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID		Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID
	prefixes, they draw the PIM Join/Prune control traffic making them		prefixes, they draw the PIM Join/Prune control traffic making them
	the target of the distribution tree. To get multicast packets from		the target of the distribution tree. To get multicast packets from
	the LISP source multicast sites, the tree needs to be built on the		the LISP source multicast sites, the tree needs to be built on the
	path from the mPETR to the LISP source multicast site. To make this		path from the mPETR to the LISP source multicast site. To make this
	happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a		happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a
	"Proxy ITR", or an uPITR).		"Proxy ITR", or an uPITR [INTWORK]).
	The existence of mPETRs in the core allows source multicast site ITRs		The existence of mPETRs in the core allows source multicast site ITRs
	to encapsulate multicast packets according to (S-RLOC,G) state. The		to encapsulate multicast packets according to (S-RLOC,G) state. The
	(S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The		(S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The
	encapsulated multicast packets are decapsulated by mPETRs and then		encapsulated multicast packets are decapsulated by mPETRs and then
	forwarded according to (S-EID,G) state. The (S-EID,G) state is built		forwarded according to (S-EID,G) state. The (S-EID,G) state is built
	from the non-LISP and uLISP receiver multicast sites to the mPETRs.		from the non-LISP and uLISP receiver multicast sites to the mPETRs.
	9.1.2. Non-LISP Source Site to non-LISP Receiver Sites		9.1.2. Non-LISP Source Site to non-LISP Receiver Sites
	skipping to change at page 23, line 44		skipping to change at page 23, line 44
	For a non-LISP source multicast site, (S-EID,G) state could be		For a non-LISP source multicast site, (S-EID,G) state could be
	limited to the edges of the network with the use of multicast proxy-		limited to the edges of the network with the use of multicast proxy-
	ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast		ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast
	packets from non-LISP source multicast and uLISP sites and		packets from non-LISP source multicast and uLISP sites and
	encapsulate them to ETRs in receiver multicast sites or to mPETRs		encapsulate them to ETRs in receiver multicast sites or to mPETRs
	that can decapsulate for non-LISP receiver multicast or uLISP sites.		that can decapsulate for non-LISP receiver multicast or uLISP sites.
	The mPITRs are responsible for sending (S-EID,G) joins to the non-		The mPITRs are responsible for sending (S-EID,G) joins to the non-
	LISP source multicast site. To connect the distribution trees		LISP source multicast site. To connect the distribution trees
	together, multicast ETRs will need to be configured with the mPITR's		together, multicast ETRs will need to be configured with the mPITR's
	RLOC addresses so they can send both (S-RLOC,G) joins to build a		RLOC addresses so they can send both (S-RLOC,G) joins to build a
	distribution tree to the mPITR as well as for sending unicast oins to		distribution tree to the mPITR as well as for sending unicast joins
	mPITRs so they can propogate (S-EID,G) joins into source multicast		to mPITRs so they can propogate (S-EID,G) joins into source multicast
	sites. The use of mPITRs is undergoing more study and is work in		sites. The use of mPITRs is undergoing more study and is work in
	progress.		progress.
	9.1.4. Unicast LISP Source Site to Any Receiver Sites		9.1.4. Unicast LISP Source Site to Any Receiver Sites
	In the last section, it was explained how an ETR in a multicast		In the last section, it was explained how an ETR in a multicast
	receiver site can determine if a source multicast site is LISP-		receiver site can determine if a source multicast site is LISP-
	enabled by looking into the mapping database. When the source		enabled by looking into the mapping database. When the source
	multicast site is a uLISP site, it is LISP enabled but the ITR, by		multicast site is a uLISP site, it is LISP enabled but the ITR, by
	definition is not capable of doing multicast encapsulation. So for		definition is not capable of doing multicast encapsulation. So for
	skipping to change at page 27, line 6		skipping to change at page 27, line 6
	common address family which is determined by the source site's		common address family which is determined by the source site's
	locator-set in its LISP database mapping entry. All receiver		locator-set in its LISP database mapping entry. All receiver
	multicast sites will use the best RLOC priority controlled by the		multicast sites will use the best RLOC priority controlled by the
	source multicast site. This is true when the source site is		source multicast site. This is true when the source site is
	either LISP-Multicast or uLISP capable. This means that priority-		either LISP-Multicast or uLISP capable. This means that priority-
	based policy modification is prohibited. When a receiver		based policy modification is prohibited. When a receiver
	multicast site ETR receives a (S-EID,G) join, it must select a		multicast site ETR receives a (S-EID,G) join, it must select a
	S-RLOC for the same address family as S-EID.		S-RLOC for the same address family as S-EID.
	o A mixed multicast locator-set with the best multicast priority		o A mixed multicast locator-set with the best multicast priority
	values MUST not be configured on multicast ITRs. A mixed locator-		values MUST NOT be configured on multicast ITRs. A mixed locator-
	set can exist (for unicast use), but the multicast priorities MUST		set can exist (for unicast use), but the multicast priorities MUST
	be the set for the same address family locators.		be the set for the same address family locators.
	o When the source site is not LISP capable, it is up to how		o When the source site is not LISP capable, it is up to how
	receivers find the source and group information for a multicast		receivers find the source and group information for a multicast
	flow. That mechanism decides the address family for the flow.		flow. That mechanism decides the address family for the flow.
	9.3. Making a Multicast Interworking Decision		9.3. Making a Multicast Interworking Decision
	This Multicast Interworking section has shown all combinations of		This Multicast Interworking section has shown all combinations of
	skipping to change at page 27, line 28		skipping to change at page 27, line 28
	concluded, this can be quite complicated and if the design is too		concluded, this can be quite complicated and if the design is too
	ambitious, the dynamics of the protocol could cause a lot of		ambitious, the dynamics of the protocol could cause a lot of
	instability.		instability.
	The trade-off decisions are hard to make and we want the same single		The trade-off decisions are hard to make and we want the same single
	solution to work for both IPv4 and IPv6 multicast. It is imperative		solution to work for both IPv4 and IPv6 multicast. It is imperative
	to have an incrementally deployable solution for all of IPv4 unicast		to have an incrementally deployable solution for all of IPv4 unicast
	and multicast and IPv6 unicast and multicast while minimizing (or		and multicast and IPv6 unicast and multicast while minimizing (or
	eliminating) both unicast and multicast EID namespace state.		eliminating) both unicast and multicast EID namespace state.
	Therefore the design decision to go with uPITRs for unicast routing		Therefore the design decision to go with uPITRs [INTWORK] for unicast
	and mPETRs for multicast routing seems to be the sweet spot in the		routing and mPETRs for multicast routing seems to be the sweet spot
	solution space so we can optimize state requirements and avoid head-		in the solution space so we can optimize state requirements and avoid
	end data replication at ITRs.		head-end data replication at ITRs.
	10. Considerations when RP Addresses are Embedded in Group Addresses		10. Considerations when RP Addresses are Embedded in Group Addresses
	When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a		When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a
	technique exists to embed the unicast address of an RP in a IPv6		technique exists to embed the unicast address of an RP in a IPv6
	group address [RFC3956]. When routers in end sites process a PIM		group address [RFC3956]. When routers in end sites process a PIM
	Join/Prune message which contain an embedded-RP group address, they		Join/Prune message which contain an embedded-RP group address, they
	extract the RP address from the group address and treat it from the		extract the RP address from the group address and treat it from the
	EID namespace. However, core routers do not have state for the EID		EID namespace. However, core routers do not have state for the EID
	namespace, need to extract an RP address from the RLOC namespace.		namespace, need to extract an RP address from the RLOC namespace.
	skipping to change at page 29, line 16		skipping to change at page 29, line 16
	If the core routers are upgraded to support [RPFV] and [RFC5496],		If the core routers are upgraded to support [RPFV] and [RFC5496],
	then we can pass EID specific data through the core without,		then we can pass EID specific data through the core without,
	possibly, having to store the state in the core.		possibly, having to store the state in the core.
	By doing this we can eliminate the ETR from unicast encapsulating PIM		By doing this we can eliminate the ETR from unicast encapsulating PIM
	Join/Prune messages to the source site's ITR.		Join/Prune messages to the source site's ITR.
	However, this solution is restricted to a small set of workable cases		However, this solution is restricted to a small set of workable cases
	which would not be good for general use of LISP-Multicast. In		which would not be good for general use of LISP-Multicast. In
	addition to slow convergence properties, it is not being recommended		addition due to slow convergence properties, it is not being
	for LISP-Multicast.		recommended for LISP-Multicast.
	12. Mtrace Considerations		12. Mtrace Considerations
	Mtrace functionality must be consistent with unicast traceroute		Mtrace functionality must be consistent with unicast traceroute
	functionality where all hops from multicast receiver to multicast		functionality where all hops from multicast receiver to multicast
	source are visible.		source are visible.
	The design for mtrace for use in LISP-Multicast environments is to be		The design for mtrace for use in LISP-Multicast environments is to be
	determined but should build upon the mtrace version 2 specified in		determined but should build upon the mtrace version 2 specified in
	[MTRACE].		[MTRACE].
	skipping to change at page 32, line 18		skipping to change at page 32, line 18
	contributed discussion, ideas, and commentary to the making of this		contributed discussion, ideas, and commentary to the making of this
	proposal and specification. People who provided expert review were		proposal and specification. People who provided expert review were
	Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from		Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from
	discussions at Summer 2008 Dublin IETF were Toerless Eckert and		discussions at Summer 2008 Dublin IETF were Toerless Eckert and
	Ijsbrand Wijnands.		Ijsbrand Wijnands.
	We would also like to thank the MBONED working group for constructive		We would also like to thank the MBONED working group for constructive
	and civil verbal feedback when this draft was presented at the Fall		and civil verbal feedback when this draft was presented at the Fall
	2008 IETF in Minneapolis. In particular, good commentary came from		2008 IETF in Minneapolis. In particular, good commentary came from
	Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou,		Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou,
	Ron Bonica, and Lenny Guardino.		Ron Bonica, Lenny Guardino, Alia Atlas, and Jesus Arango.
	An expert review of this specification was done by Yiqun Cai and		An expert review of this specification was done by Yiqun Cai and
	Liming Wei. We thank them for their detailed comments.		Liming Wei. We thank them for their detailed comments.
	This work originated in the Routing Research Group (RRG) of the IRTF.		This work originated in the Routing Research Group (RRG) of the IRTF.
	The individual submission [MLISP] was converted into this IETF LISP		The individual submission [MLISP] was converted into this IETF LISP
	working group draft.		working group draft.
	15. References		15. References
	15.1. Normative References		15.1. Normative References
			[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
			"Locator/ID Separation Protocol (LISP)",
			draft-ietf-lisp-13.txt (work in progress), June 2011.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery		[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
	Protocol (MSDP)", RFC 3618, October 2003.		Protocol (MSDP)", RFC 3618, October 2003.
	[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous		[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
	Point (RP) Address in an IPv6 Multicast Address",		Point (RP) Address in an IPv6 Multicast Address",
	RFC 3956, November 2004.		RFC 3956, November 2004.
	skipping to change at page 33, line 49		skipping to change at page 34, line 4
	[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path		[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
	Forwarding (RPF) Vector TLV", RFC 5496, March 2009.		Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
	15.2. Informative References		15.2. Informative References
	[ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative		[ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative
	Topology (LISP-ALT)", draft-ietf-lisp-alt-06.txt (work in		Topology (LISP-ALT)", draft-ietf-lisp-alt-06.txt (work in
	progress), March 2011.		progress), March 2011.
	[INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP		[INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP
	with IPv4 and IPv6", draft-ietf-lisp-interworking-01.txt		with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt
	(work in progress), March 2010.		(work in progress), March 2011.
	[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol (LISP)",
	draft-ietf-lisp-12.txt (work in progress), April 2011.
	[MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,		[MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
	"LISP for Multicast Environments",		"LISP for Multicast Environments",
	draft-farinacci-lisp-multicast-01.txt (work in progress),		draft-farinacci-lisp-multicast-01.txt (work in progress),
	November 2008.		November 2008.
	[MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a		[MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a
	Network Address (and port) Translator (NAT)",		Network Address (and port) Translator (NAT)",
	draft-ietf-behave-multicast-07.txt (work in progress),		draft-ietf-behave-multicast-07.txt (work in progress),
	June 2007.		June 2007.
	skipping to change at page 35, line 7		skipping to change at page 35, line 7
	Version 2: Traceroute Facility for IP Multicast",		Version 2: Traceroute Facility for IP Multicast",
	draft-ietf-mboned-mtrace-v2-03.txt (work in progress),		draft-ietf-mboned-mtrace-v2-03.txt (work in progress),
	March 2009.		March 2009.
	[RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector		[RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector
	TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress),		TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress),
	February 2008.		February 2008.
	Appendix A. Document Change Log		Appendix A. Document Change Log
	A.1. Changes to draft-ietf-lisp-multicast-05.txt		A.1. Changes to draft-ietf-lisp-multicast-06.txt
			o Posted June 2011 to complete working group last call.
			o Added paragraph to section 8.1.2 based on Jesus comment about
			making it more clear what happens when two (S-EID,G) trees use the
			same (RLOC,G) tree.
			o Make more references to [INTWORK] when mentioning uPITRs and
			uPETRs.
			o Made many changes based on editorial and wordsmithing comments
			from Alia.
			A.2. Changes to draft-ietf-lisp-multicast-05.txt
	o Posted April 2011 to reset expiration timer.		o Posted April 2011 to reset expiration timer.
	o Updated references.		o Updated references.
	A.2. Changes to draft-ietf-lisp-multicast-04.txt		A.3. Changes to draft-ietf-lisp-multicast-04.txt
	o Posted October 2010 to reset expiration timer.		o Posted October 2010 to reset expiration timer.
	o Updated references.		o Updated references.
	A.3. Changes to draft-ietf-lisp-multicast-03.txt		A.4. Changes to draft-ietf-lisp-multicast-03.txt
	o Posted April 2010.		o Posted April 2010.
	o Added section 8.1.2 to address Joel Halpern's comment about		o Added section 8.1.2 to address Joel Halpern's comment about
	receiver sites joining the same source site via 2 different RLOCs,		receiver sites joining the same source site via 2 different RLOCs,
	each being a separate ITR.		each being a separate ITR.
	o Change all occurences of "mPTR" to "mPETR" to become more		o Change all occurences of "mPTR" to "mPETR" to become more
	consistent with uPITRs and uPETRs described in [INTWORK]. That		consistent with uPITRs and uPETRs described in [INTWORK]. That
	is, an mPETR is a LISP multicast router that decapsulates		is, an mPETR is a LISP multicast router that decapsulates
	skipping to change at page 35, line 41		skipping to change at page 36, line 8
	source sites.		source sites.
	o Add clarifications in section 9 about how homogeneous multicast		o Add clarifications in section 9 about how homogeneous multicast
	encapsulation should occur. As well as describing in this		encapsulation should occur. As well as describing in this
	section, how to deal with mixed-locator sets to avoid		section, how to deal with mixed-locator sets to avoid
	heterogeneous encapsulation.		heterogeneous encapsulation.
	o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges		o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges
	of LISP global multicast network.		of LISP global multicast network.
	A.4. Changes to draft-ietf-lisp-multicast-02.txt		A.5. Changes to draft-ietf-lisp-multicast-02.txt
	o Posted September 2009.		o Posted September 2009.
	o Added Document Change Log appendix.		o Added Document Change Log appendix.
	o Specify that the LISP Encapsulated Control Message be used for		o Specify that the LISP Encapsulated Control Message be used for
	unicasting PIM Join/Prune messages from ETRs to ITRs.		unicasting PIM Join/Prune messages from ETRs to ITRs.
	A.5. Changes to draft-ietf-lisp-multicast-01.txt		A.6. Changes to draft-ietf-lisp-multicast-01.txt
	o Posted November 2008.		o Posted November 2008.
	o Specified that PIM Join/Prune unicast messages that get sent from		o Specified that PIM Join/Prune unicast messages that get sent from
	ETRs to ITRs of a source multicast site get LISP encapsulated in		ETRs to ITRs of a source multicast site get LISP encapsulated in
	destination UDP port 4342.		destination UDP port 4342.
	o Add multiple RLOCs per ITR per Yiqun's comments.		o Add multiple RLOCs per ITR per Yiqun's comments.
	o Indicate how static RPs can be used when LISP is run using Bidir-		o Indicate how static RPs can be used when LISP is run using Bidir-
	PIM in the core.		PIM in the core.
	o Editorial changes per Liming comments.		o Editorial changes per Liming comments.
	o Add Mttrace Considersations section.		o Add Mttrace Considersations section.
	A.6. Changes to draft-ietf-lisp-multicast-00.txt		A.7. Changes to draft-ietf-lisp-multicast-00.txt
	o Posted April 2008.		o Posted April 2008.
	o Renamed from draft-farinacci-lisp-multicast-01.txt.		o Renamed from draft-farinacci-lisp-multicast-01.txt.
	Authors' Addresses		Authors' Addresses
	Dino Farinacci		Dino Farinacci
	cisco Systems		cisco Systems
	Tasman Drive		Tasman Drive
End of changes. 25 change blocks.
	47 lines changed or deleted		74 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/