Diff: rfc8815xml2.original.xml

	rfc8815xml2.original.xml	rfc8815.xml

	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="utf-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC1112 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.1112.xml">
	<!ENTITY RFC2375 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.2375.xml">
	<!ENTITY RFC3170 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.3170.xml">
	<!ENTITY RFC3307 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.3307.xml">
	<!ENTITY RFC3376 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.3376.xml">
	<!ENTITY RFC3618 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.3618.xml">
	<!ENTITY RFC3810 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.3810.xml">
	<!ENTITY RFC3913 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.3913.xml">
	<!ENTITY RFC3956 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.3956.xml">
	<!ENTITY RFC4291 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.4291.xml">
	<!ENTITY RFC4541 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.4541.xml">
	<!ENTITY RFC4604 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.4604.xml">
	<!ENTITY RFC4607 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.4607.xml">
	<!ENTITY RFC4609 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.4609.xml">
	<!ENTITY RFC4610 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.4610.xml">
	<!ENTITY RFC4611 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.4611.xml">
	<!ENTITY RFC5015 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.5015.xml">
	<!ENTITY RFC5771 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.5771.xml">
	<!ENTITY RFC6763 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.6763.xml">
	<!ENTITY RFC7761 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.7761.xml">
	<!ENTITY RFC8313 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.8313.xml">
	<!ENTITY RFC8504 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.8504.xml">
	]>

	<!-- Use with the following tips & tools:
	http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html
	http://xml.resource.org/authoring/README.html OR
	http://xml.resource.org/authoring/README-dev.html
	http://xml.resource.org/ OR
	http://xml.resource.org/experimental.html
	http://fenron.net/~fenner/ietf/xml2rfc-valid/ link appears to be broken :
	(
	http://tools.ietf.org/tools/idnits/
	http://tools.ietf.org/rfcdiff
	-->

	<!-- Then upload:
	https://datatracker.ietf.org/idst/upload.cgi
	-->

	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<!-- used by XSLT processors -->
	<!-- For a complete list and description of processing instructions (PIs),
	please see http://xml.resource.org/authoring/README.html -->
	<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
	might want to use.
	(Here they are set differently than their defaults in xml2rfc v1.35) -->

	<!-- give errors regarding ID-nits and DTD validation -->
	<?rfc strict="yes"?>

	<!-- control the table of contents (ToC) -->
	<!-- generate a ToC -->
	<?rfc toc="yes"?>
	<!-- the number of levels of subsections in ToC. default: 3 -->
	<?rfc tocdepth="3"?>


	<!-- control references -->	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<!-- use anchors instead of numbers for refs, i.e, [RFC2119] instead of [1] -->
	<?rfc symrefs="yes"?>
	<!-- sort the reference entries alphabetically -->
	<?rfc sortrefs="no" ?>


	<!-- control vertical white space	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
	(using these PIs as follows is recommended by the RFC Editor) -->	category="bcp" consensus="true" ipr="trust200902"
	<!-- do not start each main section on a new page -->	docName="draft-ietf-mboned-deprecate-interdomain-asm-07" number="8815"
	<?rfc compact="yes" ?>	obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3"
	<!-- "no" to keep one blank line between list items (rfced) -->	symRefs="true" sortRefs="false" version="3">
	<?rfc subcompact="no" ?>


	<!-- encourage use of "xml2rfc" tool -->	<!-- xml2rfc v2v3 conversion 2.41.0 -->
	<?rfc rfcprocack="yes" ?>
	<!-- end of list of popular I-D processing instructions -->


	<rfc category="bcp" ipr="trust200902" docName="draft-ietf-mboned-deprecate-inter domain-asm-07">
	<front>	<front>

	<title abbrev="Deprecating Interdomain ASM">Deprecating ASM for Interdomain	<title abbrev="Deprecating Interdomain ASM">Deprecating Any-Source
	Multicast</title>	Multicast (ASM) for Interdomain Multicast</title>
		<seriesInfo name="RFC" value="8815"/>
		<seriesInfo name="BCP" value="229"/>
	<author fullname="Mikael Abrahamsson" initials="M." surname="Abrahamsson">	<author fullname="Mikael Abrahamsson" initials="M." surname="Abrahamsson">
	<address>	<address>
	<postal>	<postal>
	<street> </street>	<street> </street>

	<city> Stockholm </city>	<city>Stockholm</city>
	<country> Sweden </country>	<country>Sweden</country>
	</postal>	</postal>

	<email> swmike@swm.pp.se </email>	<email>swmike@swm.pp.se</email>
	</address>	</address>
	</author>	</author>

	<author fullname="Tim Chown" initials="T." surname="Chown">	<author fullname="Tim Chown" initials="T." surname="Chown">

	<organization> Jisc </organization>	<organization>Jisc</organization>
	<address>	<address>
	<postal>	<postal>

	<street> Lumen House, Library Avenue </street>	<street>Lumen House, Library Avenue</street>
	<city> Harwell Oxford, Didcot</city>	<extaddr>Harwell Oxford</extaddr>
	<code> OX11 0SG </code>	<city>Didcot</city>
	<country> United Kingdom </country>	<code>OX11 0SG</code>
		<country>United Kingdom</country>
	</postal>	</postal>

	<email> tim.chown@jisc.ac.uk </email>	<email>tim.chown@jisc.ac.uk</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Lenny Giuliano" initials="L." surname="Giuliano">	<author fullname="Lenny Giuliano" initials="L." surname="Giuliano">

	<organization> Juniper Networks, Inc. </organization>	<organization>Juniper Networks, Inc.</organization>
	<address>	<address>
	<postal>	<postal>

	<street> 2251 Corporate Park Drive </street>	<street>2251 Corporate Park Drive</street>
	<city> Herndon, Virginia</city>	<city>Herndon</city> <region>Virginia</region>
	<code> 20171 </code>	<code>20171</code>
	<country> United States </country>	<country>United States of America</country>
	</postal>	</postal>

	<email> lenny@juniper.net </email>	<email>lenny@juniper.net</email>
	</address>	</address>
	</author>	</author>

		<author fullname="Toerless Eckert" initials="T." surname="Eckert">
	<author fullname="Toerless Eckert" initials="T.T.E." surname="Eckert">	<organization>Futurewei Technologies Inc.</organization>
	<organization>Futurewei Technologies Inc.</organization>	<address>
	<address>	<postal>
	<postal>	<street>2330 Central Expy</street>
	<street>2330 Central Expy</street>	<city>Santa Clara</city> <region>California</region>
	<city>Santa Clara</city>	<code>95050</code>
	<code>95050</code>	<country>United States of America</country>
	<country>USA</country>	</postal>
	</postal>	<email>tte@cs.fau.de</email>
	<email>tte+ietf@cs.fau.de</email>	</address>
	</address>	</author>
	</author>	<date month="August" year="2020"/>
		<area>Operations</area>
	<date month="March" year="2020"/>	<workgroup>Mboned</workgroup>
	<area> Operations </area>
	<workgroup> Mboned </workgroup>

	<abstract>	<abstract>
	<t>	<t>
	This document recommends deprecation of the use of	This document recommends deprecation of the use of
	Any-Source Multicast (ASM) for interdomain multicast.	Any-Source Multicast (ASM) for interdomain multicast.
	It recommends the use of Source-Specific Multicast (SSM) for	It recommends the use of Source-Specific Multicast (SSM) for
	interdomain multicast applications and recommends that hosts and routers	interdomain multicast applications and recommends that hosts and routers

	in these deployments fully support SSM. The recommendations	in these deployments fully support SSM. The recommendations in this docu
	in this document do not preclude the continued use of ASM	ment do not preclude the continued use of
	within a single organisation or domain and are especially easy to adopt	ASM within a single organization or domain and are especially easy to
	in	adopt in existing deployments of intradomain ASM using PIM Sparse Mode
	existing intradomain ASM/PIM-SM deployments.	(PIM-SM).
	</t>	</t>
	</abstract>	</abstract>


	</front>	</front>
	<middle>	<middle>

		<section numbered="true" toc="default">
	<section title="Introduction">	<name>Introduction</name>
	<t>	<t>
	IP Multicast has been deployed in various forms, within	IP Multicast has been deployed in various forms, within
	private networks, the wider Internet, and federated networks	private networks, the wider Internet, and federated networks
	such as national or regional research networks.	such as national or regional research networks.
	While a number of service models have been published, and in many cases	While a number of service models have been published, and in many cases
	revised over time, there has been no strong recommendation	revised over time, there has been no strong recommendation
	made by the IETF on the appropriateness of those models to certain scenar ios,	made by the IETF on the appropriateness of those models to certain scenar ios,
	even though vendors and federations have often made such recommendations .	even though vendors and federations have often made such recommendations .

	</t>	</t>
	<t>	<t>
	This document addresses this gap by making a BCP-level	This document addresses this gap by making a BCP-level
	recommendation to deprecate the use of Any-Source Multicast (ASM)	recommendation to deprecate the use of Any-Source Multicast (ASM)
	for interdomain	for interdomain
	multicast, leaving Source-Specific Multicast (SSM)	multicast, leaving Source-Specific Multicast (SSM)
	as the recommended interdomain mode of	as the recommended interdomain mode of
	multicast.	multicast.

	This document further recommends that all hosts and routers which support	Therefore, this document recommends that all hosts and routers that suppo rt
	interdomain multicast applications fully support SSM.	interdomain multicast applications fully support SSM.
	</t>	</t>

	<t>	<t>
	This document does not make any statement on the use of ASM	This document does not make any statement on the use of ASM

	within a single domain or organisation, and therefore	within a single domain or organization and, therefore, does not preclude
	does not preclude its use.	its use. Indeed, there are application contexts for
	Indeed, there are application contexts for which ASM is currently still	which ASM is currently still widely considered well suited within a
	widely considered well-suited within a single domain.	single domain.
	</t>	</t>
	<t>	<t>
	The main issue in most cases with moving to SSM is application support.	The main issue in most cases with moving to SSM is application support.
	Many applications are initially deployed for intradomain use and are lat er	Many applications are initially deployed for intradomain use and are lat er

	deployed interdomain. Therefore, this document recommends	deployed interdomain. Therefore, this document recommends that
	applications support SSM, even when they are initially intended for	applications support SSM, even when they are initially intended for
	intradomain use. As explained below, SSM applications are	intradomain use. As explained below, SSM applications are

	readily compatible with existing intradomain ASM deployments as SSM	readily compatible with existing intradomain ASM deployments using PIM-S
	is merely a subset of ASM.	M, as PIM-SSM is merely a subset of PIM-SM.
	</t>	</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Background">	<name>Background</name>
	<section title="Multicast service models">	<section numbered="true" toc="default">
	<t>	<name>Multicast Service Models</name>
		<t>
	Any-Source Multicast (ASM) and Source-Specific Multicast (SSM)	Any-Source Multicast (ASM) and Source-Specific Multicast (SSM)
	are the two multicast service models in use today. In ASM, as original ly	are the two multicast service models in use today. In ASM, as original ly

	described in <xref target="RFC1112"/>, receivers express interest	described in <xref target="RFC1112" format="default"/>, receivers expre
	in joining a multicast group address and routers use multicast	ss interest
		in joining a multicast group address, and routers use multicast
	routing protocols to deliver traffic from	routing protocols to deliver traffic from
	the sender(s) to the receivers. If there are multiple senders	the sender(s) to the receivers. If there are multiple senders
	for a given group, traffic from all senders will be delivered	for a given group, traffic from all senders will be delivered
	to the receivers. Since receivers specify only the group address,	to the receivers. Since receivers specify only the group address,

	the network, and therefore the multicast routing protocols, are	the network -- and therefore the multicast routing protocols -- are
	responsible for source discovery.	responsible for source discovery.

	</t>	</t>
	<t>	<t>
	In SSM, by contrast, receivers specify both group and source when	In SSM, by contrast, receivers specify both group and source when
	expressing interest in joining a multicast stream. Source discovery	expressing interest in joining a multicast stream. Source discovery

	in SSM is handled by some out-of-band mechanism in the application	in SSM is handled by some out-of-band mechanism (typically in the appli
	layer, which drastically simplifies the network and how the multicast	cation
		layer), which drastically simplifies the network and how the multicast
	routing protocols operate.	routing protocols operate.

	</t>	</t>
	<t>	<t>
	IANA has reserved specific ranges of IPv4 and IPv6 address	IANA has reserved specific ranges of IPv4 and IPv6 address
	space for multicast addressing.	space for multicast addressing.
	Guidelines for IPv4 multicast address assignments	Guidelines for IPv4 multicast address assignments

	can be found in <xref target="RFC5771"/>, while	can be found in <xref target="RFC5771" format="default"/>, while
	guidelines for IPv6 multicast address assignments	guidelines for IPv6 multicast address assignments

	can be found in <xref target="RFC2375"/> and	can be found in <xref target="RFC2375" format="default"/> and
	<xref target="RFC3307"/>.	<xref target="RFC3307" format="default"/>.
	The IPv6 multicast address format is described	The IPv6 multicast address format is described

	in <xref target="RFC4291"/>.	in <xref target="RFC4291" format="default"/>.
	</t>	</t>
		</section>
	</section>	<section numbered="true" toc="default">
		<name>ASM Routing Protocols</name>
	<section title="ASM routing protocols">	<section numbered="true" toc="default">
		<name>PIM Sparse Mode (PIM-SM)</name>
	<section title="PIM Sparse Mode (PIM-SM)">	<t>
	<t>
	The most commonly deployed ASM routing protocol is Protocol Independe nt	The most commonly deployed ASM routing protocol is Protocol Independe nt
	Multicast - Sparse Mode (PIM-SM), as	Multicast - Sparse Mode (PIM-SM), as

	detailed in <xref target="RFC7761"/>.	detailed in <xref target="RFC7761" format="default"/>.
	PIM-SM, as the name suggests, was designed to be used in scenarios	PIM-SM, as the name suggests, was designed to be used in scenarios
	where the subnets with receivers are sparsely distributed throughout	where the subnets with receivers are sparsely distributed throughout
	the network.	the network.
	Because receivers do not indicate sender addresses in ASM (but only g roup addresses),	Because receivers do not indicate sender addresses in ASM (but only g roup addresses),

	PIM-SM uses the concept of a Rendezvous Point (RP) as a ‘meeting poin t’	PIM-SM uses the concept of a Rendezvous Point (RP) as a "meeting poin t"
	for sources and receivers, and all routers in a PIM-SM domain are	for sources and receivers, and all routers in a PIM-SM domain are

	configured to use specific RP(s), either explicitly or through	configured to use a specific RP(s), either explicitly or through
	dynamic RP discovery protocols.	dynamic RP-discovery protocols.
	</t>	</t>
	<t>	<t>
	To enable PIM-SM to work between multiple	To enable PIM-SM to work between multiple

	domains, an interdomain, inter-RP signalling protocol known	domains, an interdomain, inter-RP signaling protocol known
	as Multicast Source Discovery Protocol (MSDP)	as Multicast Source Discovery Protocol (MSDP)

	<xref target="RFC3618"/> is used to allow an RP in one	<xref target="RFC3618" format="default"/> is used to allow an RP in o
	domain to learn the existence of a source in another domain.	ne
	Deployment scenarios for MSDP are given in <xref target="RFC4611"/>.	domain to learn of the existence of a source in another domain.
		Deployment scenarios for MSDP are given in <xref target="RFC4611" for
		mat="default"/>.
	MSDP floods information	MSDP floods information
	about all active sources for all multicast streams to all RPs in all	about all active sources for all multicast streams to all RPs in all

	the domains - even if there is no receiver for a given application in a domain.	the domains -- even if there is no receiver for a given application i n a domain.
	As a result of this key scalability and security issue, along with	As a result of this key scalability and security issue, along with
	other deployment challenges with the protocol,	other deployment challenges with the protocol,
	MSDP was never extended to support IPv6 and remains an Experimental p rotocol.	MSDP was never extended to support IPv6 and remains an Experimental p rotocol.

	</t>	</t>
	<t>At the time of writing, there is no IETF Proposed Standard level	<t>At the time of writing, there is no IETF
	interdomain solution for	interdomain solution at the level of
	IPv4 ASM multicast because MSDP was the de facto mechanism for the i	Proposed Standard for IPv4 ASM
	nterdomain	multicast, because MSDP was the de facto mechanism for the
	source discovery problem, and it is Experimental. Other protocol opt	interdomain source discovery problem, and it is
	ions	Experimental. Other protocol options were investigated at
	were investigated at the same time but were never implemented or dep	the same time but were never implemented or deployed and are
	loyed	now historic (e.g., <xref target="RFC3913"
	and are now historic (e.g: <xref target="RFC3913"/>).	format="default"/>).
	</t>	</t>
		</section>
	</section>	<section numbered="true" toc="default">
		<name>Embedded-RP</name>
	<section title="Embedded-RP">	<t>Due to the availability of more bits in an IPv6 address than in IPv
		4,
	<t>Due to the availability of more bits in an IPv6 address than in I
	Pv4,
	an IPv6-specific mechanism was designed in support of interdomain	an IPv6-specific mechanism was designed in support of interdomain

	ASM with PIM-SM leveraging those bits.	ASM, with PIM-SM leveraging those bits.
	Embedded-RP <xref target="RFC3956"/> allows routers supporting the pr	Embedded-RP <xref target="RFC3956" format="default"/> allows routers
	otocol	supporting the protocol
	to determine the RP for the group without any	to determine the RP for the group without any
	prior configuration or discovery protocols, simply by observing the u nicast RP	prior configuration or discovery protocols, simply by observing the u nicast RP
	address that is embedded (included) in the IPv6 multicast group addr ess.	address that is embedded (included) in the IPv6 multicast group addr ess.
	Embedded-RP allows PIM-SM operation across any IPv6 network	Embedded-RP allows PIM-SM operation across any IPv6 network
	in which there is an end-to-end path of routers	in which there is an end-to-end path of routers
	supporting this mechanism, including interdomain deployment.	supporting this mechanism, including interdomain deployment.

	</t>	</t>
		</section>
	</section>	<section numbered="true" toc="default">
		<name>BIDIR-RP</name>
	<section title="Bidir-RP">	<t>BIDIR-PIM <xref target="RFC5015" format="default"/> is
		another protocol to support ASM.
	<t>Bidir-PIM <xref target="RFC5015"/> is another protocol to support	There is no standardized option to operate BIDIR-PIM interdomain. It
	ASM.	is
	There is no standardized option to operate Bidir-PIM interdomain. It
	is
	deployed intradomain for applications where many sources send traffi c	deployed intradomain for applications where many sources send traffi c

	to the same IP multicast groups because unlike PIM-SM it does not	to the same IP multicast groups because, unlike PIM-SM, it does not
	create per-source state. Bidir-PIM is one of the important reasons f	create per-source state. BIDIR-PIM is one of the important reasons f
	or this	or this
	document to not deprecate intradomain ASM.</t>	document to not deprecate intradomain ASM.</t>

		</section>
	</section>	</section>
		<section numbered="true" toc="default">
	</section>	<name>SSM Routing Protocols</name>
		<t>
	<section title="SSM Routing protocols">	SSM is detailed in <xref target="RFC4607" format="default"/>. It mandat
		es the use of
	<t>	PIM-SSM for routing of SSM. PIM-SSM is merely a subset of PIM-SM
	SSM is detailed in <xref target="RFC4607"/>. It mandates the use of	<xref target="RFC7761" format="default"/>.
	PIM-SSM for routing of SSM. PIM-SSM is merely a subset of PIM-SM (<xr	</t>
	ef target="RFC7761"/>).	<t>
	</t>	PIM-SSM expects the sender's source address(es)
	<t>
	PIM-SSM expects the sender’s source address(es)
	to be known in advance by receivers through some out-of-band mechanism (typically	to be known in advance by receivers through some out-of-band mechanism (typically

	in the application layer), and thus the	in the application layer); thus, the
	receiver's designated router can send a PIM JOIN directly towards the	receiver's designated router can send a PIM Join message directly towar
		ds the
	source without needing to use an RP.	source without needing to use an RP.

	</t>	</t>
	<t>	<t>
	IPv4 addresses in the 232/8 (232.0.0.0 to	IPv4 addresses in the 232/8 (232.0.0.0 to

	232.255.255.255) range are designated as source-specific multicast	232.255.255.255) range are designated as Source-Specific Multicast
	(SSM) destination addresses and are reserved for use by	(SSM) destination addresses and are reserved for use by

	source-specific applications and protocols. See <xref target="RFC4607"/ >.	source-specific applications and protocols.
	For IPv6, the address prefix	For IPv6, the address prefix

	ff3x::/32 is reserved for source-specific multicast use.	ff3x::/32 is reserved for source-specific multicast use. See <xref tar
	</t>	get="RFC4607" format="default"/>.
		</t>
	</section>	</section>

	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Discussion">	<name>Discussion</name>
		<section numbered="true" toc="default">
	<section title="Observations on ASM and SSM deployments">	<name>Observations on ASM and SSM Deployments</name>
		<t>
	<t>
	In enterprise and campus scenarios, ASM in the form of PIM-SM is	In enterprise and campus scenarios, ASM in the form of PIM-SM is
	likely the most commonly deployed	likely the most commonly deployed
	multicast protocol. The configuration and	multicast protocol. The configuration and
	management of an RP (including RP redundancy) within a single	management of an RP (including RP redundancy) within a single

	domain is a well understood operational practice. However, if interworki ng	domain is a well-understood operational practice. However, if interworki ng
	with external PIM domains is needed in IPv4 multicast deployments,	with external PIM domains is needed in IPv4 multicast deployments,
	interdomain MSDP is required to	interdomain MSDP is required to
	exchange information about sources between domain RPs.	exchange information about sources between domain RPs.
	Deployment experience has shown MSDP to be a complex and fragile protocol	Deployment experience has shown MSDP to be a complex and fragile protocol
	to manage and troubleshoot. Some of these issues include complex	to manage and troubleshoot. Some of these issues include complex
	Reverse Path Forwarding (RPF)	Reverse Path Forwarding (RPF)
	rules, state attack protection, and filtering of undesired sources.	rules, state attack protection, and filtering of undesired sources.

	</t>	</t>
		<t>
	<t>	PIM-SM is a general-purpose protocol that can handle all
	PIM-SM is a general purpose protocol that can handle all
	use cases. In particular, it was designed for cases such as	use cases. In particular, it was designed for cases such as
	videoconferencing where multiple sources may come and go	videoconferencing where multiple sources may come and go
	during a multicast	during a multicast
	session. But for cases where a single, persistent source for a group	session. But for cases where a single, persistent source for a group
	is used, and receivers can be configured to know of that source,	is used, and receivers can be configured to know of that source,
	PIM-SM has unnecessary complexity. Therefore, SSM removes the need for	PIM-SM has unnecessary complexity. Therefore, SSM removes the need for
	many of the most	many of the most
	complex components of PIM-SM.	complex components of PIM-SM.

	</t>	</t>
	<t>	<t>
	As explained above, MSDP was not extended to support IPv6. Instead,	As explained above, MSDP was not extended to support IPv6. Instead,
	the proposed interdomain ASM solution for PIM-SM with IPv6	the proposed interdomain ASM solution for PIM-SM with IPv6
	is Embedded-RP, which allows the RP address	is Embedded-RP, which allows the RP address
	for a multicast group to be embedded in the group address,	for a multicast group to be embedded in the group address,
	making RP discovery automatic for all routers on the path	making RP discovery automatic for all routers on the path
	between a receiver and a sender.	between a receiver and a sender.

	Embedded-RP can support lightweight ad-hoc deployments.	Embedded-RP can support lightweight ad hoc deployments.
	However, it relies	However, it relies
	on a single RP for an entire group that could only be made resilient	on a single RP for an entire group that could only be made resilient
	within one domain. While this approach solves the MSDP issues, it does	within one domain. While this approach solves the MSDP issues, it does

	not solve the problem of unauthorised sources sending traffic to ASM	not solve the problem of unauthorized sources sending traffic to ASM
	multicast groups; this security issue	multicast groups; this security issue
	is one of biggest problems of interdomain multicast.	is one of biggest problems of interdomain multicast.

	</t>	</t>
	<t>	<t>
	As stated in RFC 4607, SSM is particularly well-suited to	As stated in RFC 4607, SSM is particularly well suited to either
	dissemination-style applications with one or more senders	dissemination-style applications with one or more senders
	whose identities are known (by some out-of-band mechanism) before the	whose identities are known (by some out-of-band mechanism) before the
	application starts running or applications that utilize some	application starts running or applications that utilize some
	signaling to indicate the source address of the	signaling to indicate the source address of the

	multicast stream (e.g., electronic programming guide	multicast stream (e.g., an electronic programming guide
	in IPTV applications).	in IPTV applications).

	PIM-SSM is therefore very well-suited	Therefore, SSM through PIM-SSM is very well suited
	to applications such as classic linear broadcast TV over IP.	to applications such as classic linear-broadcast TV over IP.
	</t>	</t>
		<t>
	<t>	SSM requires applications, host operating systems, and the
	SSM requires applications, host operating systems and the
	designated routers connected to receiving hosts	designated routers connected to receiving hosts
	to support Internet Group Management Protocol, Version 3 (IGMPv3)	to support Internet Group Management Protocol, Version 3 (IGMPv3)

	<xref target="RFC3376"/> and	<xref target="RFC3376" format="default"/> and
	Multicast Listener Discovery, Version 2 (MLDv2)	Multicast Listener Discovery, Version 2 (MLDv2)

	<xref target="RFC3810"/>. While support for	<xref target="RFC3810" format="default"/>. While support for
	IGMPv3 and MLDv2 has been commonplace in routing platforms for	IGMPv3 and MLDv2 has been commonplace in routing platforms for
	a long time, it has also now become widespread in common operating	a long time, it has also now become widespread in common operating

	systems for several years (Windows, MacOS,	systems for several years (Windows, Mac OS,
	Linux/Android) and is no longer an impediment to SSM deployment.	Linux/Android) and is no longer an impediment to SSM deployment.

	</t>	</t>

	</section>	</section>

		<section anchor="advantages" numbered="true" toc="default">
	<section title="Advantages of SSM for interdomain multicast" anchor="advan	<name>Advantages of SSM for Interdomain Multicast</name>
	tages" >

	<t>This section describes the three key benefits that SSM	<t>This section describes the three key benefits that SSM
	with PIM-SSM has over ASM. These benefits also apply	with PIM-SSM has over ASM. These benefits also apply
	to intradomain deployment but are even more important in	to intradomain deployment but are even more important in

	interdomain deployments. See <xref target="RFC4607"/> for	interdomain deployments. See <xref target="RFC4607" format="default"/> f or
	more details.</t>	more details.</t>

		<section numbered="true" toc="default">
	<section title="Reduced network operations complexity">	<name>Reduced Network Operations Complexity</name>
		<t>
	<t>
	A significant benefit of SSM is the reduced complexity that comes throu gh	A significant benefit of SSM is the reduced complexity that comes throu gh
	eliminating the network-based source discovery required in ASM with PIM -SM.	eliminating the network-based source discovery required in ASM with PIM -SM.


	Specifically, SSM eliminates the need for RPs,	Specifically, SSM eliminates the need for RPs,
	shared trees, Shortest Path Tree (SPT) switchovers, PIM registers,	shared trees, Shortest Path Tree (SPT) switchovers, PIM registers,

	MSDP, dynamic RP discovery mechanisms (BSR/AutoRP) and data-driven	MSDP, dynamic RP-discovery mechanisms (Bootstrap Router
		(BSR) / AutoRP), and data-driven
	state creation. SSM simply utilizes a small	state creation. SSM simply utilizes a small
	subset of PIM-SM, alongside the integration with IGMPv3/MLDv2, where th e	subset of PIM-SM, alongside the integration with IGMPv3/MLDv2, where th e
	source address signaled from the receiver is immediately used to	source address signaled from the receiver is immediately used to
	create (S,G) state.	create (S,G) state.
	Eliminating network-based source discovery for interdomain	Eliminating network-based source discovery for interdomain
	multicast means the vast majority of the complexity of multicast goes a way.	multicast means the vast majority of the complexity of multicast goes a way.

	</t>	</t>
		<t>
	<t>
	This reduced complexity makes SSM radically simpler to manage,	This reduced complexity makes SSM radically simpler to manage,

	troubleshoot and operate, particularly for backbone network	troubleshoot, and operate, particularly for backbone network
	operators. This is the main operator motivation for the recommendation	operators. This is the main operator motivation for the recommendation
	to deprecate the use of ASM in interdomain scenarios.	to deprecate the use of ASM in interdomain scenarios.
	</t>	</t>

		<t>Note that this discussion does not apply to BIDIR-PIM, and there is
	<t>Note that this discussion does not apply to Bidir-PIM, and there is	(as mentioned above) no standardized interdomain solution for BIDIR-PI
	(as mentioned above) no standardized interdomain solution for Bidir-PI	M.
	M.	In BIDIR-PIM, traffic is forwarded to the RP instead of building state
	In Bidir-PIM, traffic is forwarded to the RP instead of building state	as in PIM-SM. This occurs even in the absence of receivers.
	as	Therefore, BIDIR-PIM offers a trade-off of state complexity at the cost
	in PIM-SM. This occurs even in the absence of receivers. Bidir-PIM	of
	therefore trades state complexity with	creating unnecessary traffic (potentially a large amount). </t>
	unnecessary traffic (potentially a large amount). </t>

	</section>	</section>

		<section numbered="true" toc="default">
	<section title="No network-wide IP multicast group-address management">	<name>No Network-Wide IP Multicast Group-Address Management</name>

	<t>	<t>
	In ASM, IP multicast group addresses need to be assigned to applicatio ns	In ASM, IP multicast group addresses need to be assigned to applicatio ns
	and instances thereof, so that two simultaneously active application i nstances	and instances thereof, so that two simultaneously active application i nstances
	will not share the same group address and receive IP multicast traffic from	will not share the same group address and receive IP multicast traffic from
	each other.	each other.
	</t>	</t>


	<t>	<t>
	In SSM, no such IP multicast group management is necessary. Instead, t he IP multicast	In SSM, no such IP multicast group management is necessary. Instead, t he IP multicast
	group address simply needs to be assigned locally on a source like a u nicast transport	group address simply needs to be assigned locally on a source like a u nicast transport
	protocol port number: the only coordination required is to ensure that	protocol port number: the only coordination required is to ensure that
	different applications running on the same host don't send to the same group	different applications running on the same host don't send to the same group

	address. This does not require any network operator involvement.	address. This does not require any network-operator involvement.
	</t>	</t>


	</section>	</section>

		<section anchor="source-security" numbered="true" toc="default">
	<section anchor="source-security" title="Intrinsic source-control securi	<name>Intrinsic Source-Control Security</name>
	ty">	<t>

	<t>
	SSM is implicitly secure against off-path unauthorized/undesired source s.	SSM is implicitly secure against off-path unauthorized/undesired source s.
	Receivers only receive packets from the sources they explicitly specify	Receivers only receive packets from the sources they explicitly specify

	in their IGMPv3/MLDv2 membership messages, as opposed to ASM where any host	in their IGMPv3/MLDv2 membership messages, as opposed to ASM, where an y host
	can send traffic to a group address and have it transmitted to all rec eivers.	can send traffic to a group address and have it transmitted to all rec eivers.
	With PIM-SSM, traffic from sources not requested by any receiver will	With PIM-SSM, traffic from sources not requested by any receiver will

	be discarded by the first-hop router (FHR) of that source, minimizing source	be discarded by the First-Hop Router (FHR) of that source, minimizing source
	attacks against shared network bandwidth and receivers.	attacks against shared network bandwidth and receivers.
	</t>	</t>


	<t>	<t>

	This benefit is particularly important in interdomain deployments beca	This benefit is particularly important in interdomain deployments
	use	because there are no standardized solutions for ASM control of
	there are no standardized solutions for ASM control of sources and the	sources and the most common intradomain operational practices such as
	most	Access Control Lists (ACLs) on the sender's FHR are not feasible for
	common intradomain operational practices such as Access Control Lists	interdomain deployments.
	(ACL) on the sender's FHR are not feasible for interdomain deployments
	.
	</t>	</t>


	<t>	<t>

	This topic is expanded upon in <xref target="RFC4609"/>.	This topic is expanded upon in <xref target="RFC4609" format="default"/
	</t>	>.
		</t>
	</section>	</section>


	</section>	</section>


	</section>	</section>

		<section anchor="recommendations" numbered="true" toc="default">
	<section anchor="recommendations" title="Recommendations">	<name>Recommendations</name>
		<t>
	<t>
	This section provides recommendations for a variety of stakeholders in	This section provides recommendations for a variety of stakeholders in

	SSM deployment, including vendors, operators and application developers,	SSM deployment, including vendors, operators, and application developers.
	and also suggests further work that could be undertaken within the IETF.	It also suggests further work that could be undertaken within the IETF.
	</t>	</t>
		<section numbered="true" toc="default">
	<section title="Deprecating use of ASM for interdomain multicast">	<name>Deprecating Use of ASM for Interdomain Multicast</name>
	<t>	<t>
	This document recommends that the use of ASM be deprecated	This document recommends that the use of ASM be deprecated

	for interdomain multicast, and thus implicitly, that hosts and	for interdomain multicast; thus, implicitly, it recommends that hosts and
	routers that support such interdomain applications	routers that support such interdomain applications
	fully support SSM and its associated protocols.	fully support SSM and its associated protocols.
	Best current practices for deploying interdomain multicast using SSM	Best current practices for deploying interdomain multicast using SSM

	are documented in <xref target="RFC8313"/>.	are documented in <xref target="RFC8313" format="default"/>.
	</t>	</t>
	<t>	<t>
	The recommendation applies to the use of ASM between domains where	The recommendation applies to the use of ASM between domains where
	either MSDP (IPv4) or Embedded-RP (IPv6) is used.	either MSDP (IPv4) or Embedded-RP (IPv6) is used.
	</t>	</t>
	<t>	<t>
	An interdomain use of ASM multicast in the context of this document	An interdomain use of ASM multicast in the context of this document
	is one where PIM-SM with RPs/MSDP/Embedded-RP	is one where PIM-SM with RPs/MSDP/Embedded-RP
	is run on routers operated by two or more separate administrative entiti es.	is run on routers operated by two or more separate administrative entiti es.

	</t>	</t>
	<t>	<t>

	The focus of this document is deprecation of inter-domain ASM multicast,	The focus of this document is deprecation of interdomain ASM multicast,
	and while encouraging the use of SSM within domains,	and while encouraging the use of SSM within domains,
	it leaves operators free to choose to use ASM within their own domains.	it leaves operators free to choose to use ASM within their own domains.
	A more inclusive interpretation of this recommendation is that it	A more inclusive interpretation of this recommendation is that it
	also extends to deprecating use of ASM in the case where PIM is	also extends to deprecating use of ASM in the case where PIM is
	operated in a single operator domain, but where	operated in a single operator domain, but where
	user hosts or non-PIM network edge devices are under	user hosts or non-PIM network edge devices are under
	different operator control. A typical example of this case is a	different operator control. A typical example of this case is a
	service provider offering	service provider offering
	IPTV (single operator domain for PIM) to subscribers operating an	IPTV (single operator domain for PIM) to subscribers operating an
	IGMP proxy home gateway and IGMPv3/MLDv2 hosts (computer, tablets, set-t op boxes).	IGMP proxy home gateway and IGMPv3/MLDv2 hosts (computer, tablets, set-t op boxes).

	skipping to change at line 515 ¶	skipping to change at line 429 ¶
	it leaves operators free to choose to use ASM within their own domains.	it leaves operators free to choose to use ASM within their own domains.
	A more inclusive interpretation of this recommendation is that it	A more inclusive interpretation of this recommendation is that it
	also extends to deprecating use of ASM in the case where PIM is	also extends to deprecating use of ASM in the case where PIM is
	operated in a single operator domain, but where	operated in a single operator domain, but where
	user hosts or non-PIM network edge devices are under	user hosts or non-PIM network edge devices are under
	different operator control. A typical example of this case is a	different operator control. A typical example of this case is a
	service provider offering	service provider offering
	IPTV (single operator domain for PIM) to subscribers operating an	IPTV (single operator domain for PIM) to subscribers operating an
	IGMP proxy home gateway and IGMPv3/MLDv2 hosts (computer, tablets, set-t op boxes).	IGMP proxy home gateway and IGMPv3/MLDv2 hosts (computer, tablets, set-t op boxes).
	</t>	</t>


	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Including network support for IGMPv3/MLDv2">	<name>Including Network Support for IGMPv3/MLDv2</name>
		<t>
	<t>	This document recommends that all hosts, router platforms, and
	This document recommends that all hosts, router platforms and
	security appliances used for deploying multicast	security appliances used for deploying multicast

	support the components of IGMPv3 <xref target="RFC3376"/> and MLDv2	support the components of IGMPv3 <xref target="RFC3376" format="default"/
	<xref target="RFC3810"/> necessary to support SSM (i.e., explicitly sendi	> and MLDv2
	ng	<xref target="RFC3810" format="default"/> necessary to support SSM (i.e.,
		explicitly sending
	source-specific reports).	source-specific reports).

	The updated IPv6 Node Requirements RFC <xref target="RFC8504"/>	"IPv6 Node Requirements" <xref target="RFC8504" format="default"/>
	states that MLDv2 must be supported in all implementations.	states that MLDv2 must be supported in all implementations.
	Such support is already widespread in common host and router platforms.	Such support is already widespread in common host and router platforms.

	</t>	</t>
	<t>	<t>
	Further guidance on IGMPv3 and MLDv2 is given in	Further guidance on IGMPv3 and MLDv2 is given in

	<xref target="RFC4604"/>.	<xref target="RFC4604" format="default"/>.
	</t>	</t>
	<t>	<t>
	Multicast snooping is often used to limit the flooding of multicast traf fic	Multicast snooping is often used to limit the flooding of multicast traf fic

	in a layer 2 network. With snooping, a L2 switch will monitor IGMP/MLD	in a Layer 2 network. With snooping, an L2 switch will monitor IGMP/MLD
	messages and only forward multicast traffic out on host ports that have	messages and only forward multicast traffic out on host ports that have
	interested receivers connected.	interested receivers connected.
	Such snooping capability should therefore support IGMPv3 and MLDv2.	Such snooping capability should therefore support IGMPv3 and MLDv2.

	There is further discussion in <xref target="RFC4541"/>.	There is further discussion in <xref target="RFC4541" format="default"/> .
	</t>	</t>


	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Building application support for SSM">	<name>Building Application Support for SSM</name>
	<t>	<t>
	The recommendation to use SSM for interdomain multicast means that	The recommendation to use SSM for interdomain multicast means that
	applications should properly trigger the sending of IGMPv3/MLDv2	applications should properly trigger the sending of IGMPv3/MLDv2
	source-specific report messages.	source-specific report messages.

	It should be noted, however, there is a wide range of applications today	It should be noted, however, that there is a wide range of applications t
	that only support ASM. In many cases this is due to application develope	oday
	rs	that only support ASM. In many cases, this is due to application develop
	being unaware of the operational concerns of networks, and the implicatio	ers
	ns of	being unaware of the operational concerns of networks and the implication
	using ASM versus using SSM. This document serves to	s of
		using ASM versus SSM. This document serves to
	provide clear direction for application developers who might currently on ly	provide clear direction for application developers who might currently on ly
	consider using ASM to instead support SSM, which only requires relatively minor	consider using ASM to instead support SSM, which only requires relatively minor
	changes for many applications, particularly those with single sources.	changes for many applications, particularly those with single sources.

	</t>	</t>
	<t>	<t>
	It is often thought that ASM is required for multicast applications	It is often thought that ASM is required for multicast applications
	where there are multiple sources. However,	where there are multiple sources. However,
	RFC 4607 also describes how SSM can be used instead of PIM-SM	RFC 4607 also describes how SSM can be used instead of PIM-SM
	for multi-party applications:	for multi-party applications:

	</t>	</t>
	<t>
	<list style="empty">	<blockquote>SSM can be used to
	<t>"SSM can be used to
	build multi-source applications where all participants' identities	build multi-source applications where all participants' identities
	are not known in advance, but the multi-source "rendezvous"	are not known in advance, but the multi-source "rendezvous"
	functionality does not occur in the network layer in this case. Just	functionality does not occur in the network layer in this case. Just
	like in an application that uses unicast as the underlying transport,	like in an application that uses unicast as the underlying transport,
	this functionality can be implemented by the application or by an	this functionality can be implemented by the application or by an

	application-layer library."	application-layer library.
	</t>	</blockquote>
	</list>
	</t>


	<t>	<t>
	Some useful considerations for multicast applications can be found	Some useful considerations for multicast applications can be found

	in <xref target="RFC3170"/>.	in <xref target="RFC3170" format="default"/>.
	</t>	</t>


	</section>	</section>

		<section anchor="guidance" numbered="true" toc="default">
	<section anchor="guidance" title="Developing application guidance: SSM, AS	<name>Developing Application Guidance: SSM, ASM, Service Discovery</name
	M, service discovery">	>

	<t>	<t>
	Applications with many-to-many communication patterns can create more	Applications with many-to-many communication patterns can create more
	(S,G) state than is feasible for networks to manage, whether the source discovery is	(S,G) state than is feasible for networks to manage, whether the source discovery is

	done by ASM with PIM-SM or at the application level and SSM/PIM-SM.	done by ASM with PIM-SM or at the application level and SSM/PIM-SSM.
	These applications are not best supported by either SSM/PIM-SSM or ASM/P IM-SM.	These applications are not best supported by either SSM/PIM-SSM or ASM/P IM-SM.
	</t>	</t>


	<t>	<t>
	Instead, these applications are better served by routing protocols	Instead, these applications are better served by routing protocols

	that do not create (S,G), such as Bidir-PIM.	that do not create (S,G), such as BIDIR-PIM.
	Unfortunately, today many applications use ASM solely for service	Unfortunately, many applications today use ASM solely for service
	discovery. One example is where clients send IP multicast packets to	discovery. One example is where clients send IP multicast packets to
	elicit unicast replies from server(s). Deploying any form of IP	elicit unicast replies from server(s). Deploying any form of IP

	multicast solely in support of such service discovery is in general	multicast solely in support of such service discovery is, in general,
	not recommended. Dedicated	not recommended. Dedicated

	service discovery via DNS-SD <xref target="RFC6763"/> should be used fo	service discovery via DNS-based Service
	r this instead.	Discovery (DNS-SD) <xref target="RFC6763" format="default"/> should be used
		for this instead.
	</t>	</t>

		<t>
	<t>	This document describes best practices to explain when to use SSM in
	This document describes best practices to explain when to use SSM in appl	applications -- e.g., when ASM without (S,G) state in the network is
	ications,	better, or when dedicated service-discovery
	e.g, when ASM without (S,G) state in the network is better, or when dedic	mechanisms should be used. However, specifying how applications
	ated service-discovery	can support these practices is
	mechanisms should be used, but specifying these practices is outside the	outside the scope of this document.
	scope of this document.
	Further work on this subject may be expected within the IETF.	Further work on this subject may be expected within the IETF.
	</t>	</t>


	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Preferring SSM applications intradomain">	<name>Preferring SSM Applications Intradomain</name>

	<t>	<t>
	If feasible, it is recommended for applications to use SSM even if they	If feasible, it is recommended for applications to use SSM even if they
	are initially only meant to be used in intradomain environments supporti ng ASM.	are initially only meant to be used in intradomain environments supporti ng ASM.
	Because PIM-SSM is a subset of PIM-SM, existing intradomain PIM-SM networ ks	Because PIM-SSM is a subset of PIM-SM, existing intradomain PIM-SM networ ks
	are automatically compatible with SSM applications. Thus, SSM application s	are automatically compatible with SSM applications. Thus, SSM application s
	can operate alongside existing ASM applications.	can operate alongside existing ASM applications.
	SSM's benefits of simplified address management and significantly reduce d	SSM's benefits of simplified address management and significantly reduce d
	operational complexity apply equally to intradomain use.	operational complexity apply equally to intradomain use.

	</t>	</t>
	<t>However, for some applications it may be prohibitively difficult to	<t>However, for some applications, it may be prohibitively difficult to
	add support for source discovery, so intradomain ASM may still be approp riate.	add support for source discovery, so intradomain ASM may still be approp riate.

	</t>	</t>

	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Documenting an ASM/SSM protocol mapping mechanism">	<name>Documenting an ASM/SSM Protocol Mapping Mechanism</name>
	<t>	<t>
	In the case of existing ASM applications that cannot readily be ported to SSM,	In the case of existing ASM applications that cannot readily be ported to SSM,

	it may be possible to use some form of protocol mapping, i.e., to have a	it may be possible to use some form of protocol mapping -- i.e., to have a
	mechanism to translate a (*,G) join or leave to a (S,G) join or leave for	mechanism to translate a (*,G) join or leave to a (S,G) join or leave for
	a specific source S. The general challenge in performing such mapping is	a specific source S. The general challenge in performing such mapping is
	determining where the configured source address, S, comes from.	determining where the configured source address, S, comes from.

	</t>	</t>
	<t>	<t>
	There are existing vendor-specific mechanisms deployed that achieve this function,	There are existing vendor-specific mechanisms deployed that achieve this function,
	but none are documented in IETF documents. This may be a useful	but none are documented in IETF documents. This may be a useful
	area for the IETF to work on as an interim	area for the IETF to work on as an interim
	transition mechanism. However, these mechanisms would introduce additiona l	transition mechanism. However, these mechanisms would introduce additiona l
	administrative burdens, along with the need for some form of address mana gement,	administrative burdens, along with the need for some form of address mana gement,
	neither of which are required in SSM. Hence, this should not be consider ed a	neither of which are required in SSM. Hence, this should not be consider ed a
	long-term solution.	long-term solution.

	</t>	</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Not filtering ASM addressing between domains">	<name>Not Filtering ASM Addressing between Domains</name>
	<t>	<t>
	A key benefit of SSM is that the receiver specifies the source-group tupl e	A key benefit of SSM is that the receiver specifies the source-group tupl e
	when signaling interest in a multicast stream. Hence, the group address need	when signaling interest in a multicast stream. Hence, the group address need
	not be globally unique, so there is no need for multicast address allocat ion	not be globally unique, so there is no need for multicast address allocat ion
	as long the reserved SSM range is used.	as long the reserved SSM range is used.

	</t>	</t>
	<t>	<t>
	Despite the deprecation of interdomain ASM, it is recommended that operat ors	Despite the deprecation of interdomain ASM, it is recommended that operat ors

	should not filter ASM group ranges at domain boundaries, as some form of	not filter ASM group ranges at domain boundaries, as some form of
	ASM-SSM mappings may continue to be used for some time.	ASM-SSM mappings may continue to be used for some time.

	</t>	</t>
	</section>	</section>

		<section anchor="precluding" numbered="true" toc="default">
	<section anchor="precluding" title="Not precluding Intradomain ASM">	<name>Not Precluding Intradomain ASM</name>
	<t>	<t>
	The use of ASM within a single multicast domain such as a campus or	The use of ASM within a single multicast domain such as a campus or
	enterprise is still relatively common today. There are even global	enterprise is still relatively common today. There are even global
	enterprise networks that have successfully been using	enterprise networks that have successfully been using
	PIM-SM for many years. The operators of such networks most often	PIM-SM for many years. The operators of such networks most often

	use Anycast-RP <xref target="RFC4610"/> or MSDP (with IPv4) for RP	use Anycast-RP <xref target="RFC4610" format="default"/> or MSDP (with I Pv4) for RP
	resilience, at the expense of the extra operational complexity.	resilience, at the expense of the extra operational complexity.
	These existing practices are unaffected by this document.	These existing practices are unaffected by this document.

	</t>	</t>
		<t>In the past decade, some BIDIR-PIM deployments have scaled
	<t>In the past decade, some Bidir-PIM deployments have scaled	interdomain ASM deployments beyond the capabilities of PIM-SM. This, too,
	interdomain ASM deployments beyond the capabilities of PIM-SM. This too	is unaffected by this document; instead, it is encouraged where
	is unaffected by this document, instead it is encouraged where	necessary due to application requirements (see <xref target="guidance" f
	necessary due to application requirements (see <xref target="guidance"/>	ormat="default"/>).</t>
	).</t>	<t>

	<t>
	This document also does not preclude continued use of ASM with multiple	This document also does not preclude continued use of ASM with multiple

	PIM-SM domains inside organisations, such as with IPv4 MSDP or IPv6 Embe	PIM-SM domains inside organizations, such as with IPv4 MSDP or IPv6 Embe
	dded-RP.	dded-RP.
	This includes organizations that are federations and have appropriate, no	This includes organizations that are federations and have appropriate, no
	n-standardized	nstandardized
	mechanisms to deal with the interdomain ASM issues explained in <xref ta	mechanisms to deal with the interdomain ASM issues explained in <xref ta
	rget="advantages"/>.	rget="advantages" format="default"/>.
	</t>	</t>

	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Evolving PIM deployments for SSM">	<name>Evolving PIM Deployments for SSM</name>
		<t>
	<t>
	Existing PIM-SM deployments can usually be used to run SSM	Existing PIM-SM deployments can usually be used to run SSM

	applications with little to no changes. In some widely available	applications with few-to-no changes. In some widely available
	router implementations of PIM-SM, PIM-SSM is simply enabled by default	router implementations of PIM-SM, PIM-SSM is simply enabled by default
	in the designated SSM address spaces whenever PIM-SM is	in the designated SSM address spaces whenever PIM-SM is
	enabled. In other implementations, simple configuration options	enabled. In other implementations, simple configuration options
	exist to enable it. This allows migration of ASM applications	exist to enable it. This allows migration of ASM applications
	to SSM/PIM-SSM solely through application-side development	to SSM/PIM-SSM solely through application-side development
	to handle source-signaling via	to handle source-signaling via
	IGMPv3/MLDv2 and using SSM addresses. No network actions are	IGMPv3/MLDv2 and using SSM addresses. No network actions are
	required for this transition; unchanged ASM applications can	required for this transition; unchanged ASM applications can

	continue to co-exist without issues.	continue to coexist without issues.
	</t>	</t>


	<t>When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also r esult in	<t>When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also r esult in
	the desired PIM-SSM (S,G) operations and bypass any RP procedures. This is not	the desired PIM-SSM (S,G) operations and bypass any RP procedures. This is not
	standardized but depends on implementation and may require additional co nfiguration	standardized but depends on implementation and may require additional co nfiguration
	in available products. In general, it is recommended to always use SSM address space	in available products. In general, it is recommended to always use SSM address space
	for SSM applications. For example, the interaction of IGMPv3/MLDv2 (S,G) membership	for SSM applications. For example, the interaction of IGMPv3/MLDv2 (S,G) membership

	reports and Bidir-PIM is undefined and may not result in forwarding of a ny traffic.	reports and BIDIR-PIM is undefined and may not result in forwarding of a ny traffic.
	</t>	</t>


	<t>	<t>
	Note that these migration recommendations do not include considerations on when	Note that these migration recommendations do not include considerations on when

	or how to evolve those intradomain applications best served by ASM/Bidir	or how to evolve those intradomain applications best served by ASM/BIDIR
	-PIM from PIM-SM	-PIM from PIM-SM
	to Bidir-PIM. This may also be important but is outside the scope of thi	to BIDIR-PIM. This may also be important but is outside the scope of thi
	s document.	s document.
	</t>	</t>


	</section>	</section>


	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Future interdomain ASM work">	<name>Future Interdomain ASM Work</name>

	<t>	<t>
	Future work may attempt to overcome current limitations of ASM solutions,	Future work may attempt to overcome current limitations of ASM solutions,

	such as interdomain deployment solutions for Bidir-PIM, or source access c ontrol	such as interdomain deployment solutions for BIDIR-PIM or source-access-co ntrol
	mechanisms for IPv6 PIM-SM with embedded-RP. Such work could modify or ame nd the	mechanisms for IPv6 PIM-SM with embedded-RP. Such work could modify or ame nd the

	recommendations of this document (like any future IETF standards/BCP work)	recommendations of this document (like any future IETF Standards
	.	Track / BCP work).
	</t>	</t>


	<t>	<t>
	Nevertheless, it is very unlikely that any ASM solution, even with such	Nevertheless, it is very unlikely that any ASM solution, even with such

	future work, can ever provide the same intrinsic security and network and	future work, can ever provide the same intrinsic security and network- an
	address management simplicity as SSM (see <xref target="advantages"/>).	d
	Accordingly, this	address-management simplicity as SSM (see <xref target="advantages"
		format="default"/>). Accordingly, this
	document recommends that future work for general-purpose interdomain IP	document recommends that future work for general-purpose interdomain IP

	multicast focus on SSM items listed in <xref target="recommendations"/>.	multicast focus on SSM items listed in <xref target="recommendations" for mat="default"/>.
	</t>	</t>


	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Security Considerations">	<name>Security Considerations</name>
	<t>	<t>
	This document adds no new security considerations. It instead	This document adds no new security considerations. It instead

	removes security issues incurred by interdomain ASM with PIM-SM/MSDP suc	removes security issues incurred by interdomain ASM with PIM-SM/MSDP, su
	h as	ch as
	infrastructure control plane attacks and application and bandwidth/conge	infrastructure control-plane attacks and application and bandwidth/conge
	stion	stion
	attacks from unauthorised sources sending to ASM multicast groups.	attacks from unauthorized sources sending to ASM multicast groups.
	RFC 4609 describes the additional security benefits of using	RFC 4609 describes the additional security benefits of using
	SSM instead of ASM.	SSM instead of ASM.
	</t>	</t>


	</section>	</section>

		<section numbered="true" toc="default">
	<section title="IANA Considerations">	<name>IANA Considerations</name>
	<t>This document makes no request of IANA.</t>	<t>This document has no IANA actions.</t>
	<t>Note to RFC Editor: this section may be removed upon publication as an
	RFC.</t>
	</section>	</section>

		</middle>
	<section title="Acknowledgments">	<back>
		<references>
		<name>References</name>
		<references>
		<name>Normative References</name>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.1112.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.3307.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.3376.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.3810.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.3956.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.4291.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.4607.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.5771.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.7761.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8313.xml"/>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.2375.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.3170.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.3618.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.3913.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.4541.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.4604.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.4609.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.4610.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.4611.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.5015.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.6763.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8504.xml"/>
		</references>
		</references>
		<section numbered="false" toc="default">
		<name>Acknowledgments</name>
	<t>	<t>

	The authors would like to thank members of the IETF mboned WG for discuss	The authors would like to thank members of the IETF MBONE Deployment
	ions on the	Working Group for discussions on the
	content of this document, with specific thanks to the following people fo r their	content of this document, with specific thanks to the following people fo r their
	contributions to the document:	contributions to the document:

	Hitoshi Asaeda,	<contact fullname="Hitoshi Asaeda"/>,
	Dale Carder,	<contact fullname="Dale Carder"/>,
	Jake Holland,	<contact fullname="Jake Holland"/>,
	Albert Manfredi,	<contact fullname="Albert Manfredi"/>,
	Mike McBride,	<contact fullname="Mike McBride"/>,
	Per Nihlen,	<contact fullname="Per Nihlen"/>,
	Greg Shepherd,	<contact fullname="Greg Shepherd"/>,
	James Stevens,	<contact fullname="James Stevens"/>,
	Stig Venaas,	<contact fullname="Stig Venaas"/>,
	Nils Warnke,	<contact fullname="Nils Warnke"/>,
	and	and

	Sandy Zhang.	<contact fullname="Sandy Zhang"/>.
	</t>	</t>
	</section>	</section>


	<section title="Changelog">

	<t>[RFC-Editor: Please remove this section.]</t>
	<t>02 - Toerless: Attempt to document the issues brought up on the list a
	nd discussion by James Stevens re. use of Bidir-PIM intradomain and IGMP/MLD int
	erop issues.</t>
	<t> - NOTE: Text was not vetted by co-authors, so rev'ed just as discuss
	ion basis.</t>
	<t> - more subsection to highlight content. Added more detailled discuss
	ion about downsides of ASM wrt. address management and intrinsic source-control
	in SSM. Added recommendation to work on guidance when apps are best suited for S
	SM vs. ASM/Bidir vs. service discovery. Added recommendation how to evolve from
	PIM-SM to SSM in existing deployments. Added section on possible future interdom
	ain ASM work (and why not to focus on it).</t>
	<t>01 - Lenny: cleanup of text version, removed redundancies.</t>
	<t>00 - initial IETF WG version.
	See draft-acg-mboned-deprecate-interdomain-asm for work leading to this
	document.</t>

	</section>

	</middle>
	<back>

	<references title="Normative References">
	&RFC1112;
	&RFC3307;
	&RFC3376;
	&RFC3810;
	&RFC3956;
	&RFC4291;
	&RFC4607;
	&RFC5771;
	&RFC7761;
	&RFC8313;
	</references>

	<references title="Informative References">
	&RFC2375;
	&RFC3170;
	&RFC3618;
	&RFC3913;
	&RFC4541;
	&RFC4604;
	&RFC4609;
	&RFC4610;
	&RFC4611;
	&RFC5015;
	&RFC6763;
	&RFC8504;

	</references>
	</back>	</back>
	</rfc>	</rfc>

End of changes. 155 change blocks.
	555 lines changed or deleted	423 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/