draft-ietf-lisp-multicast-07.txt		draft-ietf-lisp-multicast-08.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: January 10, 2012 S. Venaas		Expires: March 12, 2012 S. Venaas
	cisco Systems		cisco Systems
	July 9, 2011		September 9, 2011
	LISP for Multicast Environments		LISP for Multicast Environments
	draft-ietf-lisp-multicast-07		draft-ietf-lisp-multicast-08
	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 in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on January 10, 2012.		This Internet-Draft will expire on March 12, 2012.
	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 14		skipping to change at page 2, line 14
	Table of Contents		Table of Contents
	1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3		1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6		3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6
	4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Source Addresses versus Group Addresses . . . . . . . . . . . 12		5. Source Addresses versus Group Addresses . . . . . . . . . . . 12
	6. Locator Reachability Implications on LISP-Multicast . . . . . 13		6. Locator Reachability Implications on LISP-Multicast . . . . . 13
	7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14		7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14
	8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16		8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 17
	8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16		8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 17
	8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 16		8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 17
	8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 17		8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 18
	8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 17		8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 18
	8.3. Replication Locations . . . . . . . . . . . . . . . . . . 18		8.3. Replication Locations . . . . . . . . . . . . . . . . . . 19
	9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 19		9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 20
	9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 19		9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 20
	9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 20		9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 21
	9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 21		9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 22
	9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 22		9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 23
	9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 23		9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 24
	9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 23		9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 24
	9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 24		9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 25
	9.3. Making a Multicast Interworking Decision . . . . . . . . . 26		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 . . . . . . . . . . . . . . . . . . . . . . . . . . 27		Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 28		11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 29
	12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 29		12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 30
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 30		13. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31		14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33		16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	16.1. Normative References . . . . . . . . . . . . . . . . . . . 33		16.1. Normative References . . . . . . . . . . . . . . . . . . . 34
	16.2. Informative References . . . . . . . . . . . . . . . . . . 34		16.2. Informative References . . . . . . . . . . . . . . . . . . 35
	Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 35		Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 36
	A.1. Changes to draft-ietf-lisp-multicast-07.txt . . . . . . . 35		A.1. Changes to draft-ietf-lisp-multicast-08.txt . . . . . . . 36
	A.2. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 35		A.2. Changes to draft-ietf-lisp-multicast-07.txt . . . . . . . 36
	A.3. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 35		A.3. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 36
	A.4. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 35		A.4. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 36
	A.5. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 35		A.5. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 36
	A.6. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 36		A.6. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 36
	A.7. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 36		A.7. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 37
	A.8. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 36		A.8. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 37
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37		A.9. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 37
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
	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
	The Locator/ID Separation Architecture [LISP] provides a mechanism to		The Locator/ID Separation Architecture [LISP] provides a mechanism to
	separate out Identification and Location semantics from the current		separate out Identification and Location semantics from the current
	definition of an IP address. By creating two namespaces, an EID		definition of an IP address. By creating two namespaces, an Endpoint
	namespace used by sites and a Locator (RLOC) namespace used by core		ID (EID) namespace used by sites and a Routing Locator (RLOC)
	routing, the core routing infrastructure can scale by doing		namespace used by core routing, the core routing infrastructure can
	topological aggregation of routing information.		scale by doing topological aggregation of routing information.
	Since LISP creates a new namespace, a mapping function must exist to		Since LISP creates a new namespace, a mapping function must exist to
	map a site's EID prefixes to its associated locators. For unicast		map a site's EID prefixes to its associated locators. For unicast
	packets, both the source address and destination address must be		packets, both the source address and destination address must be
	mapped. For multicast packets, only the source address needs to be		mapped. For multicast packets, only the source address needs to be
	mapped. The destination group address doesn't need to be mapped		mapped. The destination group address doesn't need to be mapped
	because the semantics of an IPv4 or IPv6 group address are logical in		because the semantics of an IPv4 or IPv6 group address are logical in
	nature and not topology-dependent. Therefore, this specifications		nature and not topology-dependent. Therefore, this specification
	focuses on to map a source EID address of a multicast flow during		focuses on to map a source EID address of a multicast flow during
	distribution tree setup and packet delivery.		distribution tree setup and packet delivery.
	This specification will address the following scenarios:		This specification will address the following scenarios:
	1. How a multicast source host in a LISP site sends multicast		1. How a multicast source host in a LISP site sends multicast
	packets to receivers inside of its site as well as to receivers		packets to receivers inside of its site as well as to receivers
	in other sites that are LISP enabled.		in other sites that are LISP enabled.
	2. How inter-domain (or between LISP sites) multicast distribution		2. How inter-domain (or between LISP sites) multicast distribution
	trees are built and how forwarding of multicast packets leaving a		trees are built and how forwarding of multicast packets leaving a
	source site toward receivers sites is performed.		source site toward receivers sites is performed.
	3. What protocols are affected and what changes are required to such		3. What protocols are affected and what changes are required to such
	multicast protocols.		multicast protocols.
	4. How ASM-mode, SSM-mode, and Bidir-mode service models will		4. How ASM-mode (Any Source Multicast), SSM-mode (Single Source
	operate.		Multicast), and Bidir-mode (Bidirectional Shared Trees) service
			models will operate.
	5. How multicast packet flow will occur for multiple combinations of		5. How multicast packet flow will occur for multiple combinations of
	LISP and non-LISP capable source and receiver sites, for example:		LISP and non-LISP capable source and receiver sites, for example:
	A. How multicast packets from a source host in a LISP site are		A. How multicast packets from a source host in a LISP site are
	sent to receivers in other sites when they are all non-LISP		sent to receivers in other sites when they are all non-LISP
	sites.		sites.
	B. How multicast packets from a source host in a LISP site are		B. How multicast packets from a source host in a LISP site are
	sent to receivers in both LISP-enabled sites and non-LISP		sent to receivers in both LISP-enabled sites and non-LISP
	skipping to change at page 5, line 14		skipping to change at page 5, line 17
	enabled sites.		enabled sites.
	D. How multicast packets from a source host in a non-LISP site		D. How multicast packets from a source host in a non-LISP site
	are sent to receivers in both LISP-enabled sites and non-LISP		are sent to receivers in both LISP-enabled sites and non-LISP
	sites.		sites.
	This specification focuses on what changes are needed to the		This specification focuses on what changes are needed to the
	multicast routing protocols to support LISP-Multicast as well as		multicast routing protocols to support LISP-Multicast as well as
	other protocols used for inter-domain multicast, such as Multi-		other protocols used for inter-domain multicast, such as Multi-
	protocol BGP (MBGP) [RFC4760]. The approach proposed in this		protocol BGP (MBGP) [RFC4760]. The approach proposed in this
	specification requires no changes to the multicast infrastructure		specification requires no packet format changes to the protocol and
			no operational procedural changes to the multicast infrastructure
	inside of a site when all sources and receivers reside in that site,		inside of a site when all sources and receivers reside in that site,
	even when the site is LISP enabled. That is, internal operation of		even when the site is LISP enabled. That is, internal operation of
	multicast is unchanged regardless of whether or not the site is LISP		multicast is unchanged regardless of whether or not the site is LISP
	enabled or whether or not receivers exist in other sites which are		enabled or whether or not receivers exist in other sites which are
	LISP-enabled.		LISP-enabled.
	Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618],		Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618],
	and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not		and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not
	run in an inter-domain environment is not addressed in depth in this		run in an inter-domain environment is not addressed in depth in this
	version of the specification.		version of the specification.
	Also, the current version of this specification does not describe		Also, the current version of this specification does not describe
	multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR		multicast-based Traffic Engineering relative to the TE-ITR (Traffic
	descriptions in [LISP].		Engineering based Ingress Tunnel Router) and TE-ETR (Traffic
			Engineering based Egress Tunnel Router) descriptions in [LISP].
			Futher work is also needed to determine the detailed behavior for
			multicast proxy ITRs (mPITRs) (Section 9.1.3), mtrace (Section 12),
			and locator reachability (Section 6). Finally, further deployment
			and experimentation would be useful to understand the real-life
			performance of the LISP-Multicast solution. For instance, the design
			optimizes for minimal state and control traffic in the core, but can
			in some cases cause extra multicast traffic to be sent Section 8.1.2.
	3. Definition of Terms		3. Definition of Terms
	The terminology in this section is consistent with the definitions in		The terminology in this section is consistent with the definitions in
	[LISP] but is extended specifically to deal with the application of		[LISP] but is extended specifically to deal with the application of
	the terminology to multicast routing.		the terminology to multicast routing.
	LISP-Multicast: a reference to the design in this specification.		LISP-Multicast: a reference to the design in this specification.
	That is, when any site that is participating in multicast		That is, when any site that is participating in multicast
	communication has been upgraded to be a LISP site, the operation		communication has been upgraded to be a LISP site, the operation
	skipping to change at page 9, line 26		skipping to change at page 9, line 26
	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. However, when traffic engineering policies are		have for unicast. However, when traffic engineering policies are
	different for unicast versus multicast flows, it will be desirable to		different for unicast versus multicast flows, it will be desirable to
	use multicast-based priority and weight values in Map-Reply messages.		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		a LISP multicast header. The destination group address from the
	the inner header is copied to the destination address of the outer		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.
	The LISP-Multicast architecture will follow this high-level protocol		The LISP-Multicast architecture will follow this high-level protocol
	and operational sequence:		and operational sequence:
	1. Receiver hosts in multicast sites will join multicast content the		1. Receiver hosts in multicast sites will join multicast content the
	way they do today, they use IGMP. When they use IGMPv3 where		way they do today, they use IGMP. When they use IGMPv3 where
	they specify source addresses, they use source EIDs, that is they		they specify source addresses, they use source EIDs, that is they
	skipping to change at page 14, line 28		skipping to change at page 14, line 28
	and MLD come out of the source site's allocated addresses which		and MLD come out of the source site's allocated addresses which
	are therefore from the EID namespace.		are therefore from the EID namespace.
	MBGP: Even though MBGP is not a multicast routing protocol, it is		MBGP: Even though MBGP is not a multicast routing protocol, it is
	used to find multicast sources when the unicast BGP peering		used to find multicast sources when the unicast BGP peering
	topology and the multicast MBGP peering topology are not		topology and the multicast MBGP peering topology are not
	congruent. When MBGP is used in a LISP-Multicast environment, the		congruent. When MBGP is used in a LISP-Multicast environment, the
	prefixes which are advertised are from the RLOC namespace. This		prefixes which are advertised are from the RLOC namespace. This
	allows receiver multicast sites to find a path to the source		allows receiver multicast sites to find a path to the source
	multicast site's ITRs. MBGP peering addresses will be from the		multicast site's ITRs. MBGP peering addresses will be from the
	RLOC namespace.		RLOC namespace. There are no MBGP protocol changes required to
			support LISP-Multicast.
	MSDP: MSDP is used to announce active multicast sources to other		MSDP: MSDP is used to announce active multicast sources to other
	routing domains (or LISP sites). The announcements come from the		routing domains (or LISP sites). The announcements come from the
	PIM Rendezvous Points (RPs) from sites where there are active		PIM Rendezvous Points (RPs) from sites where there are active
	multicast sources sending to various groups. In the context of		multicast sources sending to various groups. In the context of
	LISP-Multicast, the source addresses advertised in MSDP will		LISP-Multicast, the source addresses advertised in MSDP will
	semantically be from the EID namespace since they describe the		semantically be from the EID namespace since they describe the
	identity of a source multicast host. It will be true that the		identity of a source multicast host. It will be true that the
	state stored in MSDP caches from core routers will be from the EID		state stored in MSDP caches from core routers will be from the EID
	namespace. An RP address inside of site will be from the EID		namespace. An RP address inside of site will be from the EID
	namespace so it can be advertised and reached by internal unicast		namespace so it can be advertised and reached by internal unicast
	routing mechanism. However, for MSDP peer-RPF checking to work		routing mechanism. However, for MSDP peer-RPF checking to work
	properly across sites, the RP addresses must be converted or		properly across sites, the RP addresses must be converted or
	mapped into a routable address that is advertised and maintained		mapped into a routable address that is advertised and maintained
	in the BGP routing tables in the core. MSDP peering addresses can		in the BGP routing tables in the core. MSDP peering addresses can
	come out of either the EID or a routable address namespace. And		come out of either the EID or a routable address namespace. And
	the choice can be made unilaterally because the ITR at the site		the choice can be made unilaterally because the ITR at the site
	will determine which namespace the destination peer address is out		will determine which namespace the destination peer address is out
	of by looking in the mapping database service.		of by looking in the mapping database service. There are no MSDP
			protocol changes required to support LISP-Multicast.
	PIM-SSM: In the simplest form of distribution tree building, when		PIM-SSM: In the simplest form of distribution tree building, when
	PIM operates in SSM mode, a source distribution tree is built and		PIM operates in SSM mode, a source distribution tree is built and
	maintained across site boundaries. In this case, there is a small		maintained across site boundaries. In this case, there is a small
	modification to the operation of the PIM protocol (but not to any		modification to the operation of the PIM protocol (but not to any
	message format) to support taking a Join/Prune message originated		message format) to support taking a Join/Prune message originated
	inside of a LISP site with embedded addresses from the EID		inside of a LISP site with embedded addresses from the EID
	namespace and converting them to addresses from the RLOC namespace		namespace and converting them to addresses from the RLOC namespace
	when the Join/Prune message crosses a site boundary. This is		when the Join/Prune message crosses a site boundary. This is
	similar to the requirements documented in [RFC5135].		similar to the requirements documented in [RFC5135].
	skipping to change at page 16, line 11		skipping to change at page 17, line 11
	changes, whatsoever, are required to have a multicast source host		changes, whatsoever, are required to have a multicast source host
	send multicast packets and for a multicast receiver host to receive		send multicast packets and for a multicast receiver host to receive
	multicast packets.		multicast packets.
	8. LISP-Multicast Data-Plane Architecture		8. LISP-Multicast Data-Plane Architecture
	The LISP-Multicast data-plane operation conforms to the operation and		The LISP-Multicast data-plane operation conforms to the operation and
	packet formats specified in [LISP]. However, encapsulating a		packet formats specified in [LISP]. However, encapsulating a
	multicast packet from an ITR is a much simpler process. The process		multicast packet from an ITR is a much simpler process. The process
	is simply to copy the inner group address to the outer destination		is simply to copy the inner group address to the outer destination
	address. And to have the ITR use its own IP address (its RLOC), and		address. And to have the ITR use its own IP address (its RLOC) as
	as the source address. The process is simpler for multicast because		the source address. The process is simpler for multicast because
	there is no EID-to-RLOC mapping lookup performed during packet		there is no EID-to-RLOC mapping lookup performed during packet
	forwarding.		forwarding.
	In the decapsulation case, the ETR simply removes the outer header		In the decapsulation case, the ETR simply removes the outer header
	and performs a multicast routing table lookup on the inner header		and performs a multicast routing table lookup on the inner header
	(S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is		(S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is
	used to replicate the packet on site-facing interfaces leading to		used to replicate the packet on site-facing interfaces leading to
	multicast receiver hosts.		multicast receiver hosts.
	There is no Data-Probe logic for ETRs as there can be in the unicast		There is no Data-Probe logic for ETRs as there can be in the unicast
	skipping to change at page 21, line 48		skipping to change at page 22, line 48
	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 [INTWORK]).		"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
	Clearly non-LISP multicast sites can send multicast packets to non-		Clearly non-LISP multicast sites can send multicast packets to non-
	LISP receiver multicast sites. That is what they do today. However,		LISP receiver multicast sites. That is what they do today. However,
	discussion is required to show how non-LISP multicast sites send		discussion is required to show how non-LISP multicast sites send
	multicast packets to uLISP receiver multicast sites.		multicast packets to uLISP receiver multicast sites.
	Since uLISP receiver multicast sites are not targets of any (S,G)		Since uLISP receiver multicast sites are not targets of any (S,G)
	state, they simply send (S,G) PIM Join/Prune messages toward the non-		state, they simply send (S,G) PIM Join/Prune messages toward the non-
	LISP source multicast site. Since the source multicast site, in this		LISP source multicast site. Since the source multicast site, in this
	case has not been upgraded to LISP, all multicast source host		case has not been upgraded to LISP, all multicast source host
	skipping to change at page 26, line 5		skipping to change at page 27, line 5
	o All LISP sites on a multicast distribution tree must share a		o All LISP sites on a multicast distribution tree must share a
	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 When a multicast locator-set has more than one locator, only
	values MUST NOT be configured on multicast ITRs. A mixed locator-		locators from the same address-family MUST be set to the same best
	set can exist (for unicast use), but the multicast priorities MUST		priority value. A mixed locator-set can exist (for unicast use),
	be the set for the same address family locators.		but the multicast priorities MUST 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
	multicast connectivity that could occur. As you might have already		multicast connectivity that could occur. As you might have already
	concluded, this can be quite complicated and if the design is too		concluded, this can be quite complicated and if the design is too
	skipping to change at page 31, 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, Lenny Guardino, Alia Atlas, and Jesus Arango.		Ron Bonica, Lenny Guardino, Alia Atlas, Jesus Arango, and Jari Arkko.
	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. IANA Considerations		15. IANA Considerations
	This document makes no request of the IANA.		This document makes no request of the IANA.
	16. References		16. References
	16.1. Normative References		16.1. Normative References
			[INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP
			with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt
			(work in progress).
	[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,		[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol (LISP)",		"Locator/ID Separation Protocol (LISP)",
	draft-ietf-lisp-15.txt (work in progress).		draft-ietf-lisp-15.txt (work in progress).
	[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.
	skipping to change at page 34, line 8		skipping to change at page 35, line 8
	[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a		[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a
	Network Address Translator (NAT) and a Network Address		Network Address Translator (NAT) and a Network Address
	Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.		Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.
	[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.
	16.2. Informative References		16.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-07.txt (work in		Topology (LISP-ALT)", draft-ietf-lisp-alt-08.txt (work in
	progress).		progress).
	[INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP
	with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt
	(work in progress).
	[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).
	[MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace		[MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace
	Version 2: Traceroute Facility for IP Multicast",		Version 2: Traceroute Facility for IP Multicast",
	draft-ietf-mboned-mtrace-v2-08.txt (work in progress).		draft-ietf-mboned-mtrace-v2-08.txt (work in progress).
	Appendix A. Document Change Log		Appendix A. Document Change Log
	A.1. Changes to draft-ietf-lisp-multicast-07.txt		A.1. Changes to draft-ietf-lisp-multicast-08.txt
			o Posted September 2011. Minor editorial changes from Jari's
			commentary.
			A.2. Changes to draft-ietf-lisp-multicast-07.txt
	o Posted July 2011. Fixing IDnits errors.		o Posted July 2011. Fixing IDnits errors.
	A.2. Changes to draft-ietf-lisp-multicast-06.txt		A.3. Changes to draft-ietf-lisp-multicast-06.txt
	o Posted June 2011 to complete working group last call.		o Posted June 2011 to complete working group last call.
	o Added paragraph to section 8.1.2 based on Jesus comment about		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		making it more clear what happens when two (S-EID,G) trees use the
	same (RLOC,G) tree.		same (RLOC,G) tree.
	o Make more references to [INTWORK] when mentioning uPITRs and		o Make more references to [INTWORK] when mentioning uPITRs and
	uPETRs.		uPETRs.
	o Made many changes based on editorial and wordsmithing comments		o Made many changes based on editorial and wordsmithing comments
	from Alia.		from Alia.
	A.3. Changes to draft-ietf-lisp-multicast-05.txt		A.4. 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.4. Changes to draft-ietf-lisp-multicast-04.txt		A.5. 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.5. Changes to draft-ietf-lisp-multicast-03.txt		A.6. 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 36, line 10		skipping to change at page 37, line 15
	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.6. Changes to draft-ietf-lisp-multicast-02.txt		A.7. 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.7. Changes to draft-ietf-lisp-multicast-01.txt		A.8. 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.8. Changes to draft-ietf-lisp-multicast-00.txt		A.9. 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. 29 change blocks.
	73 lines changed or deleted		92 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/