draft-acg-mboned-deprecate-interdomain-asm-00-tte.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC1112 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1112.xml">
  <!ENTITY RFC2375 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2375.xml">
  <!ENTITY RFC3170 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3170.xml">
  <!ENTITY RFC3307 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3307.xml">
  <!ENTITY RFC3376 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3376.xml">
  <!ENTITY RFC3569 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3569.xml">
  <!ENTITY RFC3618 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3618.xml">
  <!ENTITY RFC3810 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml">
  <!ENTITY RFC3913 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3913.xml">
  <!ENTITY RFC3956 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3956.xml">
  <!ENTITY RFC3973 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3973.xml">
  <!ENTITY RFC4291 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml">
  <!ENTITY RFC4541 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4541.xml">
  <!ENTITY RFC4604 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4604.xml">
  <!ENTITY RFC4607 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4607.xml">
  <!ENTITY RFC4609 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4609.xml">
  <!ENTITY RFC4610 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4610.xml">
  <!ENTITY RFC4611 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4611.xml">
  <!ENTITY RFC5771 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5771.xml">
  <!ENTITY RFC7761 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml">
  <!ENTITY RFC8085 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml">
  <!ENTITY RFC8313 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8313.xml">
  <!ENTITY I-D.ietf-6man-rfc6434-bis SYSTEM
    "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-rfc6434-bis.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 -->
<!-- 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
     (using these PIs as follows is recommended by the RFC Editor) -->
<!-- do not start each main section on a new page -->
<?rfc compact="yes" ?>
<!-- "no" to keep one blank line between list items (rfced) -->
<?rfc subcompact="no" ?>

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

<rfc category="bcp" ipr="trust200902" docName="draft-acg-mboned-deprecate-interdomain-asm-01">
  <front>
    <title abbrev="Deprecating Interdomain ASM">Deprecating ASM for Interdomain Multicast</title>

    <author fullname="Mikael Abrahamsson" initials="M." surname="Abrahamsson">
      <organization> T-Systems </organization>
      <address>
        <postal>
          <street> </street>
          <city> Stockholm </city>
          <country> Sweden </country>
        </postal>
        <email> mikael.abrahamsson@t-systems.se </email>
      </address>
    </author>

    <author fullname="Tim Chown" initials="T." surname="Chown">
      <organization> Jisc </organization>
      <address>
        <postal>
          <street> Lumen House, Library Avenue </street>
          <city> Harwell Oxford, Didcot</city>
          <code> OX11 0SG </code>
          <country> United Kingdom </country>
        </postal>
        <email> tim.chown@jisc.ac.uk </email>
      </address>
    </author>

    <author fullname="Lenny Giuliano" initials="L." surname="Giuliano">
      <organization> Juniper Networks, Inc. </organization>
      <address>
        <postal>
          <street> 2251 Corporate Park Drive </street>
          <city> Hemdon, Virginia</city>
          <code> 20171 </code>
          <country> United States </country>
        </postal>
        <email> lenny@juniper.net </email>
      </address>
    </author>

    <author fullname="Toerless Eckert" initials="T.T.E." surname="Eckert">
       <organization abbrev="Huawei">Futurewei Technologies Inc.</organization>
       <address>
         <postal>
           <street>2330 Central Expy</street>
           <city>Santa Clara</city>
           <code>95050</code>
           <country>USA</country>
         </postal>
         <email>tte+ietf@cs.fau.de</email>
       </address>
     </author>

    <date month="March" year="2018"/>
    <area> Operations </area>
    <workgroup> Mboned </workgroup>

    <abstract>
      <t>
	This document recommends the deprecation of the use of
	Any-Source Multicast (ASM) for interdomain multicast. 
        It recommends
	the use of Source-Specific Multicast (SSM) for interdomain 
	multicast applications, and that hosts and routers
	that are expected to handle such applications
	fully support SSM.  The recommendations
        in this document do not preclude the continued use of ASM within a single 
	organisation or domain and are especially easy to adopt when
        already using the preferred ASM protocol options there (PIM-SM).
      </t>
    </abstract>

  </front>
  <middle>

    <section title="Introduction">
      <t>
	IP Multicast has been deployed in various forms, both within
	private networks, the wider Internet, and federated networks
        such as national or regional research network federations.
        While a number of service models have been published, and in many cases
	revised over time, there has been no strong recommendation
	made by the IETF on the appropriateness of those models to certain scenarios,
        even though vendors and federations have often done so.
	This document addresses this gap by making a BCP-level
	recommendation to deprecate the use of ASM for interdomain 
	multicast. With SSM being the remaining Interdomain mode of
        multicast, this implies also that all hosts and
	routers that are expected to support such multicast applications
	fully support SSM.
      </t>
	<t>
	This document does not make any statement on the use of ASM
	within a single domain or organisation, and therefore
	does not preclude its use. Indeed, there may
	be a number of application contexts for which ASM is currently
	still considered well-suited within a single domain.
        </t>
        <t>
        The main issue moving to SSM is in most cases application support.
        Many applications will first get used intradomain but only
        later interdomain. Therefore, this document recommendeds to make
        applications support SSM, even when initialy they are meant to be
        just used intradomain. As explained below, SSM applications are
        easily compatible to existing intradomain ASM deployments
        that follow the current IETF standard protocol recommendations.
	</t>
    </section>

    <section title="Multicast routing protocols">
	<t>
	The general IP multicast service model 
	<xref target="RFC1112"/> is that
	sender(s) send to a multicast group address, receivers express 
	an interest in traffic sent to a given multicast group address,
	and that routers use multicast routing protocols to 
	determine how to deliver traffic from the sender(s) to the receivers. 
	</t>
      	<t>
	Two high-level flavours of this service model have
	evolved over time. In Any-Source Multicast (ASM), any
	number of sources may transmit multicast packets,
	and those sources may come and go over the course
	of a multicast session without being known a priori. 
	In ASM, receivers express interest only in a given multicast 
	group address, and the multicast routing protocol facilitates 
	source discovery at the network layer. ASM is simply the name
        given to the 1989 RFC1112 IP Multicast model when in around 2000
        the idea for the alternative SSM model was taking shape:
	In Source-Specific Multicast (SSM) the specific source(s)
	that may send traffic to the group are known in advance by the
        receivers, or may be determined during a session, typically 
	through an out-of-band protocol sitting above the network layer.
	Thus in SSM, receivers express interest in both a multicast group address
	and specific associated source address(es). 
	</t>
      	<t>
	IANA has reserved specific ranges of IPv4 and IPv6 address
	space for multicast addressing.
	Guidelines for IPv4 multicast address assignments
	can be found in <xref target="RFC5771"/>, while
	guidelines for IPv6 multicast address assignments
	can be found in <xref target="RFC2375"/> and
	<xref target="RFC3307"/>.
	The IPv6 multicast address format is described
	in <xref target="RFC4291"/>. 
	</t>

	<section title="ASM routing protocols">

      	<t>
      	The most commonly deployed ASM routing protocol is Protocol Independent
	Multicast - Sparse Mode, or PIM-SM, as 
	detailed in <xref target="RFC7761"/>.
	PIM-SM, as the name suggests, was designed to be used in scenarios
	where the subnets with receivers are sparsely distributed throughout 
	the network. 
	Because it does not know sender addresses in advance,
	PIM-SM uses the concept of a Rendezvous Point (RP) to 'marry up' 
	senders and receivers, and all routers in a PIM-SM domain are 
	configured to use specific RP(s) (either explicitly or through
        dynamic RP discovery protocols). 
	</t>
	<t>
	To enable PIM-SM to work between multiple
	domains, i.e. to allow an RP in one domain to learn the existence
	of a source in another domain, an inter-RP signalling protocol known
	as Multicast Source Discovery Protocol (MSDP)
	<xref target="RFC3618"/> is used.
	Deployment scenarios for MSDP are given in <xref target="RFC4611"/>.
	MSDP has remained an Experimental protocol since its publication in 	
	2003. One core reason for this is the need to flood information
        about all active sources for all active applications to all domains RPs
        - even if there is no receiver for this application in a domain.
        This is the key scalability and security issue
        with MSDP and also the reason why it was not extended to support IPv6.
        </t>
        <t>To this day, there is no IETF standards level interdomain solution for
        IPv4 ASM multicast because MSDP was the "best" component for the interdomain
        discovery problem, and it stayed experimental. Other protocol options
        where investigated at the same time but did achieve at most achieve
        IETF informational status and are now historic (e.g: <xref target="RFC3913"/>).
	</t>
        <t>Due to the availability of more bits in IPv6 addresses than in IPv4
        addresses, an IPv6 
        specific mechanism in support of Interdomain ASM with PIM-SM was 
        developed that was not feasible for IPv4.
	Embedded-RP <xref target="RFC3956"/> allows routers supporting it
	to determine the RP for the group without any
	prior configuration or discovery protocols, simply by observing the RP
        address that is embedded (included) in the IPv6 multicast group address.
	Embedded-RP allows PIM-SM operation across any IPv6 network (intradomain
        but especially interdomain) in which there is an end-to-end path of routers
        supporting the mechanism. 
	</t>

	</section>

      	<section title="SSM Routing protocols">
      	<t>
      	SSM is detailed in <xref target="RFC4607"/>. It is in effect a
        subset of PIM-SM where no RP is used. Note that there is no separate
        document for PIM-SSM, it just leverages a subset of <xref target="RFC7761"/>.
        </t>
        <t>PIM-SSM expects that sender source address(es)
	are known in advance by receivers: I.e. a given source's IP address is
	known (by some out of band mechanism), and thus the 
	receiver's router can 
	send a PIM JOIN directly towards the sender, without 	
	needing to use an RP.
      	</t>
	<t>
	IPv4 addresses in the 232/8 (232.0.0.0 to
   	232.255.255.255) range are designated as source-specific multicast
   	(SSM) destination addresses and are reserved for use by 
	source-specific applications and protocols. See <xref target="RFC4607"/>.
	For IPv6, the address prefix 
	FF3x::/32 is reserved for source-specific multicast use.
	</t>
      	</section>

    </section>

    <section title="Discussion">

      <section title="Observations on ASM and SSM deployments">

	<t>
	In enterprise and campus scenarios, ASM in the form of PIM-SM is 
	likely the most commonly deployed protocol and has generally replaced PIM-DM 
	<xref target="RFC3973"/>, which is an IETF experimental category RFC, while PIM-SM
        is full Internet Standard.  The configuration and
	management of an RP (even with RP redundancy) within a single domain is well understood operational practice.  
	However, if interworking
	with external PIM domains in IPv4 multicast deployments is needed, 
	Interdomain MSDP is required to 
	exchange information between domain RPs about sources. The problems with
        this use of MSDP are as explained above. They are the problems that make
        MSDP an Experimental protocol,
        and that make it (in these deployments) a complex and fragile protocol
        to administer and troubleshoot (flooding RPF rules, state attack
        protection, undesired source filtering, ...). 
	</t>

	<t>
	PIM-SM is a general purpose protocol that can handle all
	use cases. In particular, it was designed for cases such as
	videoconferencing where multiple sources may come and go 
	during a multicast
	session. But for cases where a single, persistent source for a group
        is used, and receivers can be configured to know of that source,
	PIM-SM has unnecessary complexity. In these applications it is
        typically only necessary to extend the configuration or signaling
        for the IP multicast group to be used with also the IP multicast source
        to be used. There are also various techniques to use a single logical
        "anycast" source address supported by two or more redundant senders
        for reliability with SSM and ease of deployment by using that address
        as a "static"/"well-known" address.
	</t>
	<t>
	MSDP was not taken forward to IPv6 as explained above. Instead,
        the proposed Interdomain ASM solution for PIM-SM with IPv6
	is Embedded-RP, which allows the RP address 
	for a multicast group to be embedded in the group address, 
	making RP discovery automatic, if all routers on the path
	between a receiver and a sender support the protocol.
	Embedded-RP can support lightweight ad-hoc deployments.
	However, it relies
	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
        not solve the problem of unauthorized sources sending traffic to ASM
        multicast groups, and this is the biggest problem of Interdomain multicast.
        Embedded-RP was run
	successfully between European and US academic networks during
	the 6NET project in 2004/05. Its usage generally remains
	constrained to academic networks.
	</t>

	<t>
	As stated in RFC 4607, SSM is particularly well-suited to 
	dissemination-style applications with one or more senders 
	whose identities are known (by some mechanism) before the 
	application starts running - or applications that have some
        existing signaling indicating multicast groups, where the
        additional source address can easily be added - for example
        electronic programming guide signalling in IPTV applications.
        PIM-SSM is therefore very well-suited
	to applications such as classic linear broadcast TV over IP.
	</t>

	<t>
	SSM requires applications, host operating systems and their subnet routers using it 
	to support the new(er) IGMPv3 <xref target="RFC3376"/> and 
	MLDv2 <xref target="RFC3810"/> protocols.  While
	delayed delivery of support in some OSes has meant that
	adoption of SSM has also been slower than might have been 
	expected, or hoped, and was a historical reason to use
	ASM rather than SSM, support for IGMPv3 and MLDv2 is now 
	widespread in common OSes since at least 2012 or earlier (Windows, MacOS,
        Linux/Android).
	</t>

      </section>

      <section title="Advantages of SSM for interdomain multicast">

	<t>
	A significant benefit of SSM is its reduced complexity through
	eliminating the network-based source discovery required in ASM. 
	This means there are no RPs,
	shared trees, Shortest Path Tree (SPT) switchovers, PIM registers, 
	MSDP, data-driven 
	state creation elements to support or dynamic RP discover and
        redundancy signaling protocols such as BSR. SSM is really just a small 
	subset of PIM-SM, plus the integration with IGMPv3 / MLDv2 where the
        source address signalled from the receiver is immediately used to
        create (S,G) state. Note that this is all standardized in PIM-SM/RFC7761.
        There is no separate specification for PIM-SSM.
	</t>

	<t>
	This reduced complexity makes SSM radically simpler to manage, 
	troubleshoot and operate, particularly for network backbone
	operators, and this is the main operator motivation for the recommendation
	to deprecate the use of ASM in interdomain scenarios. The overall
        solution motivation is the elimination of the security problem of ASM
        to allow traffic from unauthorized sources which does not exist in SSM
        because receivers directly indicate the source from which they want to
        receive traffic.</t>

        <t>
	Interdomain ASM is widely viewed as complicated and fragile.
	By eliminating network-based source discovery for interdomain 
	multicast, the vast majority of the complexity issues go away.
	</t>

	<t>
	RFC 4607 details many benefits of SSM, including:

	<list style="empty">
	<t>"Elimination of cross-delivery of traffic when two sources
      	simultaneously use the same source-specific destination address;</t>
	
      	<t>Avoidance of the need for inter-host coordination when choosing
      	source-specific addresses, as a consequence of the above;</t>
	
      	<t>Avoidance of many of the router protocols and algorithms that are
      	needed to provide the ASM service model."</t>
	</list>
	</t>

	<t>
	Further discussion can also be found in <xref target="RFC3569"/>.
	</t>

	<t>
	SSM is considered more secure in that it supports access control,
	i.e. you only get packets from the sources you explicitly ask 
	for, as opposed to ASM where anyone can decide to send traffic 
	to a PIM-SM group address. This topic is expanded upon in
	<xref target="RFC4609"/>.
	</t>

      </section>



    </section>

    <section title="Recommendations">

      <section title="Deprecating use of ASM for interdomain multicast">
	<t>
	This document recommends that the use of ASM is deprecated
	for interdomain multicast, and thus implictly that hosts and
	routers that are expected to support such interdomain applications
	fully support SSM.
	Best current practices for deploying interdomain multicast using SSM
	are documented in <xref target="RFC8313"/>.
	</t>
	<t>
	The recommendation applies to the use of ASM between domains where 
	either MSDP (IPv4) or Embedded-RP (IPv6) is used for sharing
	knowledge of remote sources (MSDP) or RPs (Embedded-RP).
        </t>
        <t>This document also recommends against the Inter-domain use of PIM-SM with
        an RP (potentially redundant), where multicast tunnels are used between domains.
	</t>
        <t>An Interdomain use of ASM multicast in the context of this document
        is primarily one where PIM-SM for ASM (e.g.: with RPs/MSDP/Embedded-RP)
        is run on routers operated by two or more separate operational entities
        (domains,organizations).</t>
        <t>The more inclusive interpretation of this recommendation is that it also
        extends to the case where PIM may only be operated in a single operator
        domain, but where user hosts or non-PIM network edge devices are under
        different operator control. The typical case of this is an SP providing
        IPTV (single operator domain for PIM) to subscribers operating an
        IGMP-proxy home-gateway and IGMPv3/MLDv2 hosts (computer, tablets, set-top boxes).
        </t>
	<t>While MSDP is an Experimental category IETF standard, this document does
	not propose making MSDP Historic, given its use may be desirable
	for intradomain multicast use cases (RP redundancy intradomain). This
        may change in future documents when the targeted successor to MSDP for
        intradomain RP redundancy (<xref target="RFC4610"/>) adds better support
        for some operational aspects missing in it compared to MSDP.
        </t>
      </section>

      <section title="Including network support for IGMPv3 / MLDv2">
	<t>
	This document recommends that all host and router platforms supporting
	multicast, and any security appliances that may handle multicast traffic, 
	support IGMPv3 <xref target="RFC3376"/> and MLDv2 <xref target="RFC3810"/>
        (based on the version IP they intend to support).
	The updated IPv6 Node Requirements RFC <xref target="I-D.ietf-6man-rfc6434-bis"/>
	states that MLDv2 support is a MUST in all implementations.
	Such support is already widespread in common host and router platforms.
	</t>
	<t>
	Further guidance on IGMPv3 and MLDv2 is given in
	<xref target="RFC4604"/>.
	</t>
     	<t>
        It is sometimes desirable to limit the propagation of multicast messages
        in a layer 2 network, typically through a layer 2 switch device.  In such cases
        multicast snooping can be used, by which the switch device observes the
        IGMP/MLD traffic passing through it, and then attempts to make intelligent
        decisions on which physical ports to forward multicast.  Typically, ports
        that have not expressed an interest in receiving multicast for a given group
        would not have traffic for that group forwarded through them. Such snooping
	capability should support IGMPv3 and MLDv2.
        There is further discussion in <xref target="RFC4541"/>.
        </t>
      </section>

      <section title="Building application support for SSM">
	<t>
	There is a wide range of applications today that only support ASM (mostly
        for histpric reasons), whether as software packages, or code embedded in
        devices such as set-top boxes.
	</t>
	<t>
	The recommendation to use SSM for interdomain multicast means that 
	applications should use SSM, and operate correctly in an SSM 
	environment, triggering IGMPv3/MLDv2 messages to signal use of SSM.
	</t>
	<t>
	It is often thought that ASM is required for multicast applications
	where there are multiple sources. However,
	RFC 4607 also describes how SSM can be used instead of PIM-SM
	for multi-party applications:
	</t>
	<t>
	<list style="empty">
	<t>"SSM can be used to
   	build multi-source applications where all participants' identities
   	are not known in advance, but the multi-source "rendezvous"
   	functionality does not occur in the network layer in this case.  Just
   	like in an application that uses unicast as the underlying transport,
   	this functionality can be implemented by the application or by an
   	application-layer library."
	</t>
	</list>
	</t>
	<t>
	Given all common OSes support SSM, it is
	then down to the programming language and APIs used as to whether the
	necessary SSM APIs are available. SSM support became first ubiquitous 
	for C/C++/Python, and key exceptions today include websockets used in web-browser 
	based applications (see e.g.: https://github.com/nodejs/node/pull/15735/files
        introducing SSM support there in 2017).
	</t>
	<t>
	Some useful considerations for multicast applications can still be found
	in the relatively old <xref target="RFC3170"/>.
      	</t>
      </section>

      <section title="SSM applications intradomain">
        <t>If feasible, it is recommended to make applications use SSM, even if they
        initially are meant to be used in Intradomain environments supporting ASM. 
	Because PIM-SSM is a subset of PIM-SM, it is typically easily possible
        to make existing PIM-SSM intradomain networks compatible with SSM application
        receivers, therefore allowing to continue the use of existing 
        ASM PIM-SM deployments in a network (with no or very little changes).
        The benefits of no or reduced address management, operational complexity and
        simplified address managmenet equally apply to intradomain use.
      	</t>
        <t>Infeasible application may be those where it is prohibitivey difficult to
        add support for signaling of source (IP addresses) into the application.</t>
      </section>
	
      <section title="Documenting common practices for SSM support in applications.">
        <t>Currently, there is no good document summarizing best current practices
        to convert ASM applications into SSM application - or how to most easily
        support SM in greenfield application designs. This would be useful for the
        IETF to work on.
        </t>
      </section>

      <section title="Documenting an ASM/SSM protocol mapping mechanism">
	<t>
	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 
	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 
	determining where the configured source address, S, comes from.
	</t>
	<t>
	There are existing vendor-specific mechanisms deployed that achieve this function,
	but none are documented in IETF documents.  This appears to be a useful 
	area for the IETF
	to work on, but it should be noted that any such effort would only be an interim
	transition mechanism, and such mappings do not remove the requirement for
	applications to be allocated ASM group addresses for the communications.
        </t>
        <t>
        The reason why these mechanisms should not be considered to be a long-term
        ASM-SSM mechanism is because they introduce network operator management work
        and the need to perform addresss managmenet, both of which is not required in SSM.
        See also next section.
	</t>
      </section>

      <section title="Not filtering ASM addressing between domains">
	<t>
	A key benefit of SSM is that the multicast application does not need to
	be allocated a specific multicast group by the network, rather as SSM
	is inherently source-specific, it can use any group address, G, in the 
	reserved range of IPv4 or IPv6 SSM addresses for its own source address, S.
	</t>
      	<t>
	In principle, if interdomain ASM is deprecated, backbone operators could
	begin filtering the ranges of group addresses used by ASM.  In practice,
	this is not recommended given there will be a transition period from
	ASM to SSM, where some form of ASM-SSM mappings 
	may be used, and filtering may preclude such operations.
	</t>
      </section>

      <section title="Not precluding Intradomain ASM">
      	<t>
	The use of ASM within a single multicast domain, such as a campus or an
	enterprise, with an RP for the site, is still relatively 
	common today. There are even global enterprise networks successfully using
        PIM-SM successfully for many years. The operators of such metworks most often
        use Anycast-RP <xref target="RFC4610"/> or MSDP for RP 
	resilience, at the expense of the extra complexity in managing that
	configuration. These existing practices are unaffected by this document:
	</t>
	<t>
	This document does not preclude continued use of ASM in
	the intradomain scenario.
	If an organisation, or AS, wishes to use multiple multicast
	domains within its own network border, that is a choice for
	that organisation to make, and it may then use MSDP or
	Embedded-RP internally within its own network.
	</t>
      </section>

    </section>


    <section title="Congestion Control Considerations">
      <t>
        Traffic over non-controlled networks, which most Interdomain paths
        are, must support congestion control.  This is
        achievable with rate-adaptation, layered codecs, curcuit breakers
        and/or other appropriate mechanisms. See <xref target="RFC8085"/>.
      </t>

    </section>

    <section title="Security Considerations">
      <t>
	This document adds no new security considerations. It instead
        removes sucurity issues incurred by Interdomain ASM with PIM-SM/MSDP:
        intrastructure control plane attacks and application and bandwidth/congestion
        attacks from unauthorized sources sending to ASM multicast groups.
	RFC 4609 describes the additional security benefits of using
	SSM instead of ASM.
      </t>

    </section>

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

    <section title="Acknowledgments">
      <t>
	The authors would like to thank members of the IETF mboned WG for discussions on the
	content of this document, with specific thanks to the following people for their 
	contributions to the document:
	Hitoshi Asaeda,
	Dale Carder,
	Jake Holland,
	Albert Manfredi,
	Mike McBride,
	Per Nihlen,
	Greg Shepherd,
	James Stevens,
	Stig Venaas,
	Nils Warnke,
	and
	Sandy Zhang.
      </t>
    </section>
  </middle>
  <back>

    <references title="Normative References">
	&RFC1112;
	&RFC2375;
	&RFC3170;
	&RFC3307;
      	&RFC3376;
      	&RFC3569;
	&RFC3618;
	&RFC3810;
	&RFC3956;
	&RFC3973;
	&RFC4291;
	&RFC4607;
	&RFC4610;
	&RFC5771;
      	&RFC7761;
    </references>

    <references title="Informative References">
	&RFC3913;
	&RFC4541;
	&RFC4604;
	&RFC4609;
	&RFC4611;
	&RFC8085;
	&RFC8313;
      &I-D.ietf-6man-rfc6434-bis;

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