draft-ietf-mboned-deprecate-interdomain-asm-05.txt   draft-ietf-mboned-deprecate-interdomain-asm-06.txt 
Mboned M. Abrahamsson Mboned M. Abrahamsson
Internet-Draft T-Systems Internet-Draft
Intended status: Best Current Practice T. Chown Intended status: Best Current Practice T. Chown
Expires: March 7, 2020 Jisc Expires: July 6, 2020 Jisc
L. Giuliano L. Giuliano
Juniper Networks, Inc. Juniper Networks, Inc.
T. Eckert T. Eckert
Huawei Futurewei Technologies Inc.
September 4, 2019 January 3, 2020
Deprecating ASM for Interdomain Multicast Deprecating ASM for Interdomain Multicast
draft-ietf-mboned-deprecate-interdomain-asm-05 draft-ietf-mboned-deprecate-interdomain-asm-06
Abstract Abstract
This document recommends deprecation of the use of Any-Source This document recommends deprecation of the use of Any-Source
Multicast (ASM) for interdomain multicast. It recommends the use of Multicast (ASM) for interdomain multicast. It recommends the use of
Source-Specific Multicast (SSM) for interdomain multicast Source-Specific Multicast (SSM) for interdomain multicast
applications and that hosts and routers in these deployments fully applications and recommends that hosts and routers in these
support SSM. The recommendations in this document do not preclude deployments fully support SSM. The recommendations in this document
the continued use of ASM within a single organisation or domain and do not preclude the continued use of ASM within a single organisation
are especially easy to adopt in existing intradomain ASM/PIM-SM or domain and are especially easy to adopt in existing intradomain
deployments. ASM/PIM-SM deployments.
Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [RFC2119].
The term IP and IP multicast are used to refer to both IPv4 and IPv6.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 7, 2020.
This Internet-Draft will expire on July 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Multicast service models . . . . . . . . . . . . . . . . 3 2.1. Multicast service models . . . . . . . . . . . . . . . . 3
2.2. ASM routing protocols . . . . . . . . . . . . . . . . . . 4 2.2. ASM routing protocols . . . . . . . . . . . . . . . . . . 4
2.2.1. PIM Sparse Mode (PIM-SM) . . . . . . . . . . . . . . 4 2.2.1. PIM Sparse Mode (PIM-SM) . . . . . . . . . . . . . . 4
2.2.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 4
2.2.3. Bidir-RP . . . . . . . . . . . . . . . . . . . . . . 5 2.2.3. Bidir-RP . . . . . . . . . . . . . . . . . . . . . . 5
2.3. SSM Routing protocols . . . . . . . . . . . . . . . . . . 5 2.3. SSM Routing protocols . . . . . . . . . . . . . . . . . . 5
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Observations on ASM and SSM deployments . . . . . . . . . 5 3.1. Observations on ASM and SSM deployments . . . . . . . . . 5
3.2. Advantages of SSM for interdomain multicast . . . . . . . 6 3.2. Advantages of SSM for interdomain multicast . . . . . . . 6
3.2.1. Reduced network operations complexity . . . . . . . . 7 3.2.1. Reduced network operations complexity . . . . . . . . 7
3.2.2. No network wide IP multicast group-address management 7 3.2.2. No network wide IP multicast group-address management 7
3.2.3. Intrinsic source-control security . . . . . . . . . . 7 3.2.3. Intrinsic source-control security . . . . . . . . . . 7
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Deprecating use of ASM for interdomain multicast . . . . 8 4.1. Deprecating use of ASM for interdomain multicast . . . . 8
4.2. Including network support for IGMPv3 / MLDv2 . . . . . . 8 4.2. Including network support for IGMPv3/MLDv2 . . . . . . . 8
4.3. Building application support for SSM . . . . . . . . . . 9 4.3. Building application support for SSM . . . . . . . . . . 9
4.4. Developing application guidance: SSM, ASM, service 4.4. Developing application guidance: SSM, ASM, service
discovery . . . . . . . . . . . . . . . . . . . . . . . . 9 discovery . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Preferring SSM applications intradomain . . . . . . . . . 10 4.5. Preferring SSM applications intradomain . . . . . . . . . 10
4.6. Documenting an ASM/SSM protocol mapping mechanism . . . . 10 4.6. Documenting an ASM/SSM protocol mapping mechanism . . . . 10
4.7. Not filtering ASM addressing between domains . . . . . . 10 4.7. Not filtering ASM addressing between domains . . . . . . 10
4.8. Not precluding Intradomain ASM . . . . . . . . . . . . . 11 4.8. Not precluding Intradomain ASM . . . . . . . . . . . . . 11
4.9. Evolving PIM deployments for SSM . . . . . . . . . . . . 11 4.9. Evolving PIM deployments for SSM . . . . . . . . . . . . 11
5. Future interdomain ASM work . . . . . . . . . . . . . . . . . 12 5. Future interdomain ASM work . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 3, line 21 skipping to change at page 3, line 16
IP Multicast has been deployed in various forms, within private IP Multicast has been deployed in various forms, within private
networks, the wider Internet, and federated networks such as national networks, the wider Internet, and federated networks such as national
or regional research networks. While a number of service models have or regional research networks. While a number of service models have
been published, and in many cases revised over time, there has been been published, and in many cases revised over time, there has been
no strong recommendation made by the IETF on the appropriateness of no strong recommendation made by the IETF on the appropriateness of
those models to certain scenarios, even though vendors and those models to certain scenarios, even though vendors and
federations have often made such recommendations. federations have often made such recommendations.
This document addresses this gap by making a BCP-level recommendation This document addresses this gap by making a BCP-level recommendation
to deprecate the use of ASM for interdomain multicast, leaving SSM as to deprecate the use of Any-Source Multicast (ASM) for interdomain
the recommended interdomain mode of multicast. This document further multicast, leaving Source-Specific Multicast (SSM) as the recommended
recommends that all hosts and routers which support interdomain interdomain mode of multicast. This document further recommends that
multicast applications fully support SSM. all hosts and routers which support interdomain multicast
applications fully support SSM.
This document does not make any statement on the use of ASM within a This document does not make any statement on the use of ASM within a
single domain or organisation, and therefore does not preclude its single domain or organisation, and therefore does not preclude its
use. Indeed, there are application contexts for which ASM is use. Indeed, there are application contexts for which ASM is
currently still widely considered well-suited within a single domain. currently still widely considered well-suited within a single domain.
The main issue in most cases with moving to SSM is application The main issue in most cases with moving to SSM is application
support. Many applications are initially deployed for intradomain support. Many applications are initially deployed for intradomain
use and are later deployed interdomain. Therefore, this document use and are later deployed interdomain. Therefore, this document
recommends applications support SSM, even when they are initially recommends applications support SSM, even when they are initially
skipping to change at page 4, line 7 skipping to change at page 3, line 51
described in [RFC1112], receivers express interest in joining a described in [RFC1112], receivers express interest in joining a
multicast group address and routers use multicast routing protocols multicast group address and routers use multicast routing protocols
to deliver traffic from the sender(s) to the receivers. If there are to deliver traffic from the sender(s) to the receivers. If there are
multiple senders for a given group, traffic from all senders will be multiple senders for a given group, traffic from all senders will be
delivered to the receiver. Since receivers specify only the group delivered to the receiver. Since receivers specify only the group
address, the network, and therefore the multicast routing protocols, address, the network, and therefore the multicast routing protocols,
are responsible for source discovery. are responsible for source discovery.
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 (ie, the application in SSM is handled by some out-of-band mechanism (i.e., the
layer), which drastically simplifies the network and how the application layer), which drastically simplifies the network and how
multicast routing protocols operate. the multicast routing protocols operate.
IANA has reserved specific ranges of IPv4 and IPv6 address space for IANA has reserved specific ranges of IPv4 and IPv6 address space for
multicast addressing. Guidelines for IPv4 multicast address multicast addressing. Guidelines for IPv4 multicast address
assignments can be found in [RFC5771], while guidelines for IPv6 assignments can be found in [RFC5771], while guidelines for IPv6
multicast address assignments can be found in [RFC2375] and multicast address assignments can be found in [RFC2375] and
[RFC3307]. The IPv6 multicast address format is described in [RFC3307]. The IPv6 multicast address format is described in
[RFC4291]. [RFC4291].
2.2. ASM routing protocols 2.2. ASM routing protocols
skipping to change at page 5, line 40 skipping to change at page 5, line 34
PIM-SSM expects that the sender's source address(es) is known in PIM-SSM expects that the sender's source address(es) is known in
advance by receivers through some out-of-band mechanism (typically in advance by receivers through some out-of-band mechanism (typically in
the application layer), and thus the receiver's designated router can the application layer), and thus the receiver's designated router can
send a PIM JOIN directly towards the source without needing to use an send a PIM JOIN directly towards the source without needing to use an
RP. RP.
IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 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 designated as source-specific multicast (SSM) destination addresses
and are reserved for use by source-specific applications and and are reserved for use by source-specific applications and
protocols. See [RFC4607]. For IPv6, the address prefix FF3x::/32 is protocols. See [RFC4607]. For IPv6, the address prefix ff3x::/32 is
reserved for source-specific multicast use. reserved for source-specific multicast use.
3. Discussion 3. Discussion
3.1. Observations on ASM and SSM deployments 3.1. Observations on ASM and SSM deployments
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 multicast protocol. The likely the most commonly deployed multicast protocol. The
configuration and management of an RP (including RP redundancy) configuration and management of an RP (including RP redundancy)
within a single domain is a well understood operational practice. within a single domain is a well understood operational practice.
However, if interworking with external PIM domains is needed in IPv4 However, if interworking with external PIM domains is needed in IPv4
multicast deployments, interdomain MSDP is required to exchange multicast deployments, interdomain MSDP is required to exchange
information about sources between domain RPs. Deployment experience information about sources between domain RPs. Deployment experience
has shown MSDP to be a complex and fragile protocol to manage and has shown MSDP to be a complex and fragile protocol to manage and
troubleshoot. Some of these issues include complex flooding RPF troubleshoot. Some of these issues include complex flooding Reverse
rules, state attack protection, and filtering of undesired sources. Path Forwarding (RPF) rules, state attack protection, and filtering
of undesired sources.
PIM-SM is a general purpose protocol that can handle all use cases. PIM-SM is a general purpose protocol that can handle all use cases.
In particular, it was designed for cases such as videoconferencing In particular, it was designed for cases such as videoconferencing
where multiple sources may come and go during a multicast session. where multiple sources may come and go during a multicast session.
But for cases where a single, persistent source for a group is used, 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 and receivers can be configured to know of that source, PIM-SM has
unnecessary complexity. Therefore, SSM removes the need for many of unnecessary complexity. Therefore, SSM removes the need for many of
the most complex components of PIM-SM. the most complex components of PIM-SM.
As explained above, MSDP was not extended to support IPv6. Instead, As explained above, MSDP was not extended to support IPv6. Instead,
skipping to change at page 6, line 39 skipping to change at page 6, line 35
As stated in RFC 4607, SSM is particularly well-suited to As stated in RFC 4607, SSM is particularly well-suited to
dissemination-style applications with one or more senders whose dissemination-style applications with one or more senders whose
identities are known (by some out-of-band mechanism) before the 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 multicast stream signaling to indicate the source address of the multicast stream
(e.g., electronic programming guide in IPTV applications). PIM-SSM (e.g., electronic programming guide in IPTV applications). PIM-SSM
is therefore very well-suited to applications such as classic linear is therefore very well-suited to applications such as classic linear
broadcast TV over IP. broadcast TV over IP.
SSM requires applications, host operating systems and the designated SSM requires applications, host operating systems and the designated
routers connected to receiving hosts to support IGMPv3 [RFC3376] and routers connected to receiving hosts to support Internet Group
MLDv2 [RFC3810]. Support for IGMPv3 and MLDv2 has become widespread Management Protocol, Version 3 (IGMPv3) [RFC3376] and Multicast
in common OSes for several years (Windows, MacOS, Linux/Android) and Listener Discovery, Version 2 (MLDv2) [RFC3810]. While support for
is no longer an impediment to SSM deployment. IGMPv3 and MLDv2 has been commonplace in routing platforms for a long
time, it has also now become widespread in common operating systems
for several years (Windows, MacOS, Linux/Android) and is no longer an
impediment to SSM deployment.
3.2. Advantages of SSM for interdomain multicast 3.2. Advantages of SSM for interdomain multicast
This section describes the three key benefits that SSM with PIM-SSM This section describes the three key benefits that SSM with PIM-SSM
has over ASM. These benefits also apply to intradomain deployment has over ASM. These benefits also apply to intradomain deployment
but are even more important in interdomain deployments. See but are even more important in interdomain deployments. See
[RFC4607] for more details. [RFC4607] for more details.
3.2.1. Reduced network operations complexity 3.2.1. Reduced network operations complexity
A significant benefit of SSM is the reduced complexity that comes A significant benefit of SSM is the reduced complexity that comes
through eliminating the network-based source discovery required in through eliminating the network-based source discovery required in
ASM with PIM-SM. Specifically, SSM eliminates the need for RPs, ASM with PIM-SM. 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 (BSR/AutoRP) and data-driven
state creation. SSM simply utilizes a small subset of PIM-SM, state creation. SSM simply utilizes a small subset of PIM-SM,
alongside the integration with IGMPv3 / MLDv2, where the source alongside the integration with IGMPv3/MLDv2, where the source address
address signaled from the receiver is immediately used to create signaled from the receiver is immediately used to create (S,G) state.
(S,G) state. Eliminating network-based source discovery for Eliminating network-based source discovery for interdomain multicast
interdomain multicast means the vast majority of the complexity of means the vast majority of the complexity of multicast goes away.
multicast goes away.
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 operators. This is the main operator motivation for the
recommendation to deprecate the use of ASM in interdomain scenarios. recommendation to deprecate the use of ASM in interdomain scenarios.
Note that this discussion does not apply to Bidir-PIM, and there is Note that this discussion does not apply to Bidir-PIM, and there is
(as mentioned above) no standardized interdomain solution for Bidir- (as mentioned above) no standardized interdomain solution for Bidir-
PIM. In Bidir-PIM, traffic is forwarded to the RP instead of PIM. In Bidir-PIM, traffic is forwarded to the RP instead of
building state as in PIM-SM. This occurs even in the absence of building state as in PIM-SM. This occurs even in the absence of
receivers. Bidir-PIM therefore trades state complexity with receivers. Bidir-PIM therefore trades state complexity with
unnecessary traffic (potentially a large amount). unnecessary traffic (potentially a large amount).
3.2.2. No network wide IP multicast group-address management 3.2.2. No network wide IP multicast group-address management
In ASM, IP multicast group addresses need to be assigned to In ASM, IP multicast group addresses need to be assigned to
applications and instances thereof, so that two simultaneously active applications and instances thereof, so that two simultaneously active
application instances will not share the same group address and application instances will not share the same group address and
receive each others IP multicast traffic. receive IP multicast traffic from each other.
In SSM, no such IP multicast group management is necessary. Instead, In SSM, no such IP multicast group management is necessary. Instead,
the IP multicast group address simply needs to be assigned locally on the IP multicast group address simply needs to be assigned locally on
a source like a unicast transport protocol port number: the only a source like a unicast transport protocol port number: the only
coordination required is to ensure that different applications coordination required is to ensure that different applications
running on the same host don't send to the same group address. This running on the same host don't send to the same group address. This
does not require any network operator involvement. does not require any network operator involvement.
3.2.3. Intrinsic source-control security 3.2.3. Intrinsic source-control security
SSM is implicitly secure against off-path unauthorized/undesired SSM is implicitly secure against off-path unauthorized/undesired
sources. Receivers only receive packets from the sources they sources. Receivers only receive packets from the sources they
explicitly specify in their IGMP/MLD membership messages, as opposed explicitly specify in their IGMPv3/MLDv2 membership messages, as
to ASM where any host can send traffic to a group address and have it opposed to ASM where any host can send traffic to a group address and
transmitted to all receivers. With PIM-SSM, traffic from sources not have it transmitted to all receivers. With PIM-SSM, traffic from
requested by any receiver will be discarded by the first-hop router sources not requested by any receiver will be discarded by the first-
(FHR) of that source, minimizing source attacks against shared hop router (FHR) of that source, minimizing source attacks against
network bandwidth and receivers. shared network bandwidth and receivers.
This benefit is particularily important in interdomain deployments This benefit is particularily important in interdomain deployments
because there are no standardized solutions for ASM control of because there are no standardized solutions for ASM control of
sources and the most common intradomain operational practices such as sources and the most common intradomain operational practices such as
Access Control Lists (ACL) on the sender's FHR are not feasible for Access Control Lists (ACL) on the sender's FHR are not feasible for
interdomain deployments. interdomain deployments.
This topic is expanded upon in [RFC4609]. This topic is expanded upon in [RFC4609].
4. Recommendations 4. Recommendations
skipping to change at page 8, line 33 skipping to change at page 8, line 33
interdomain multicast using SSM are documented in [RFC8313]. interdomain multicast using SSM are documented in [RFC8313].
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.
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 run on routers is one where PIM-SM with RPs/MSDP/Embedded-RP is run on routers
operated by two or more separate administrative entities. operated by two or more separate administrative entities.
The more inclusive interpretation of this recommendation is that it The more inclusive interpretation of this recommendation is that it
also extends to the case where PIM may only be operated in a single also extends to deprecating use of ASM in the case where PIM is
operator domain, but where user hosts or non-PIM network edge devices operated in a single operator domain, but where user hosts or non-PIM
are under different operator control. A typical example of this case network edge devices are under different operator control. A typical
is a service provider offering IPTV (single operator domain for PIM) example of this case is a service provider offering IPTV (single
to subscribers operating an IGMP proxy home gateway and IGMPv3/MLDv2 operator domain for PIM) to subscribers operating an IGMP proxy home
hosts (computer, tablets, set-top boxes). gateway and IGMPv3/MLDv2 hosts (computer, tablets, set-top boxes).
4.2. Including network support for IGMPv3 / MLDv2 4.2. Including network support for IGMPv3/MLDv2
This document recommends that all hosts, router platforms and This document recommends that all hosts, router platforms and
security appliances used for deploying multicast support the security appliances used for deploying multicast support the
components of IGMPv3 [RFC3376] and MLDv2 [RFC3810] necessary to components of IGMPv3 [RFC3376] and MLDv2 [RFC3810] necessary to
support SSM (i.e., explicitly sending source-specific reports). The support SSM (i.e., explicitly sending source-specific reports). The
updated IPv6 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] states updated IPv6 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] states
that MLDv2 support is a MUST in all implementations. Such support is that MLDv2 must be supported in all implementations. Such support is
already widespread in common host and router platforms. already widespread in common host and router platforms.
Further guidance on IGMPv3 and MLDv2 is given in [RFC4604]. Further guidance on IGMPv3 and MLDv2 is given in [RFC4604].
Multicast snooping is often used to limit the flooding of multicast Multicast snooping is often used to limit the flooding of multicast
traffic in a layer 2 network. With snooping, a L2 switch will traffic in a layer 2 network. With snooping, a L2 switch will
monitor IGMP/MLD messages and only forward multicast traffic out on monitor IGMP/MLD messages and only forward multicast traffic out on
host ports that have interested receivers connected. Such snooping host ports that have interested receivers connected. Such snooping
capability should therefore support IGMPv3 and MLDv2. There is capability should therefore support IGMPv3 and MLDv2. There is
further discussion in [RFC4541]. further discussion in [RFC4541].
skipping to change at page 9, line 39 skipping to change at page 9, line 39
layer in this case. Just like in an application that uses unicast layer in this case. Just like in an application that uses unicast
as the underlying transport, this functionality can be implemented as the underlying transport, this functionality can be implemented
by the application or by an application-layer library." by the application or by an application-layer library."
Some useful considerations for multicast applications can be found in Some useful considerations for multicast applications can be found in
[RFC3170]. [RFC3170].
4.4. Developing application guidance: SSM, ASM, service discovery 4.4. Developing application guidance: SSM, ASM, service discovery
Applications with many-to-many communication patterns can create more Applications with many-to-many communication patterns can create more
(S,G) state than feasible for networks, whether the source discovery (S,G) state than is feasible for networks to manage, whether the
is done by ASM with PIM-SM or at the application level and SSM/PIM- source discovery is done by ASM with PIM-SM or at the application
SM. These applications are not best supported by either SSM/PIM-SSM level and SSM/PIM-SM. These applications are not best supported by
or ASM/PIM-SM. either SSM/PIM-SSM or ASM/PIM-SM.
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. Unfortunately, today that do not create (S,G), such as Bidir-PIM. Unfortunately, today
many applications simply use ASM for service discovery. One example many applications use ASM solely for service discovery. One example
is where clients send IP multicast packets to elicit unicast replies is where clients send IP multicast packets to elicit unicast replies
from server(s). Deploying any form of IP multicast solely in support from server(s). Deploying any form of IP multicast solely in support
of such service discovery is in general not recommended. Dedicated of such service discovery is in general not recommended. Dedicated
service discovery via DNS-SD [RFC6763] should be used for this service discovery via DNS-SD [RFC6763] should be used for this
instead. instead.
While the WG discussions had consensus that best practices should be While the WG discussions had consensus that best practices should be
developed to explain when to use SSM in applications, e.g, when ASM developed to explain when to use SSM in applications, e.g, when ASM
without (S,G) state in the network is better, or when dedicated without (S,G) state in the network is better, or when dedicated
service-discovery mechanisms should be used, it was agreed that service-discovery mechanisms should be used, it was agreed that
skipping to change at page 11, line 15 skipping to change at page 11, line 15
4.8. Not precluding Intradomain ASM 4.8. Not precluding Intradomain ASM
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 PIM-SM for many enterprise networks that have successfully been using PIM-SM for many
years. The operators of such networks most often use Anycast-RP years. The operators of such networks most often use Anycast-RP
[RFC4610] or MSDP (with IPv4) for RP resilience, at the expense of [RFC4610] or MSDP (with IPv4) for RP resilience, at the expense of
the extra operational complexity. These existing practices are the extra operational complexity. These existing practices are
unaffected by this document. unaffected by this document.
In the past decade, Bidir-PIM too has seen deployments to scale In the past decade, some Bidir-PIM deployments have scaled
interdomain ASM deployments beyond the capabilities of PIM-SM. This interdomain ASM deployments beyond the capabilities of PIM-SM. This
too is unaffected by this document, instead it is encouraged where too is unaffected by this document, instead it is encouraged where
necessary due to application requirements (see Section 4.4). necessary due to application requirements (see Section 4.4).
This document also does not preclude continued use of ASM with This document also does not preclude continued use of ASM with
multiple PIM-SM domains inside organisations, such as with IPv4 MSDP multiple PIM-SM domains inside organisations, such as with IPv4 MSDP
or IPv6 Embedded-RP. This includes organizations that are or IPv6 Embedded-RP. This includes organizations that are
federations and have appropriate, non-standardized mechanisms to deal federations and have appropriate, non-standardized mechanisms to deal
with the interdomain ASM issues explained in Section 3.2. with the interdomain ASM issues explained in Section 3.2.
skipping to change at page 13, line 29 skipping to change at page 13, line 29
interdomain-asm for work leading to this document. interdomain-asm for work leading to this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989, RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>. <https://www.rfc-editor.org/info/rfc1112>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002,
<https://www.rfc-editor.org/info/rfc3307>. <https://www.rfc-editor.org/info/rfc3307>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>. <https://www.rfc-editor.org/info/rfc3376>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
skipping to change at page 14, line 29 skipping to change at page 14, line 25
IPv4 Multicast Address Assignments", BCP 51, RFC 5771, IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
DOI 10.17487/RFC5771, March 2010, DOI 10.17487/RFC5771, March 2010,
<https://www.rfc-editor.org/info/rfc5771>. <https://www.rfc-editor.org/info/rfc5771>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>. 2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T.,
Ed., and R. Krishnan, "Use of Multicast across Inter-
domain Peering Points", BCP 213, RFC 8313,
DOI 10.17487/RFC8313, January 2018,
<https://www.rfc-editor.org/info/rfc8313>.
10.2. Informative References 10.2. Informative References
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998, Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998,
<https://www.rfc-editor.org/info/rfc2375>. <https://www.rfc-editor.org/info/rfc2375>.
[RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications:
Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170, Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170,
September 2001, <https://www.rfc-editor.org/info/rfc3170>. September 2001, <https://www.rfc-editor.org/info/rfc3170>.
skipping to change at page 15, line 31 skipping to change at page 15, line 37
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<https://www.rfc-editor.org/info/rfc5015>. <https://www.rfc-editor.org/info/rfc5015>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T.,
Ed., and R. Krishnan, "Use of Multicast across Inter-
domain Peering Points", BCP 213, RFC 8313,
DOI 10.17487/RFC8313, January 2018,
<https://www.rfc-editor.org/info/rfc8313>.
[I-D.ietf-6man-rfc6434-bis] [I-D.ietf-6man-rfc6434-bis]
Chown, T., Loughney, J., and T. Winters, "IPv6 Node Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", draft-ietf-6man-rfc6434-bis-09 (work in Requirements", draft-ietf-6man-rfc6434-bis-09 (work in
progress), July 2018. progress), July 2018.
Authors' Addresses Authors' Addresses
Mikael Abrahamsson Mikael Abrahamsson
T-Systems
Stockholm
Sweden
Email: mikael.abrahamsson@t-systems.se Stockholm
Sweden
Email: swmike@swm.pp.se
Tim Chown Tim Chown
Jisc Jisc
Lumen House, Library Avenue Lumen House, Library Avenue
Harwell Oxford, Didcot OX11 0SG Harwell Oxford, Didcot OX11 0SG
United Kingdom United Kingdom
Email: tim.chown@jisc.ac.uk Email: tim.chown@jisc.ac.uk
Lenny Giuliano Lenny Giuliano
Juniper Networks, Inc. Juniper Networks, Inc.
2251 Corporate Park Drive 2251 Corporate Park Drive
Herndon, Virginia 20171 Herndon, Virginia 20171
United States United States
Email: lenny@juniper.net Email: lenny@juniper.net
Toerless Eckert Toerless Eckert
Futurewei Technologies Inc. Futurewei Technologies Inc.
2330 Central Expy 2330 Central Expy
Santa Clara 95050 Santa Clara 95050
USA USA
Email: tte+ietf@cs.fau.de Email: tte+ietf@cs.fau.de
 End of changes. 32 change blocks. 
87 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/