draft-ietf-mboned-deprecate-interdomain-asm-02.txt   draft-ietf-mboned-deprecate-interdomain-asm-03.txt 
Mboned M. Abrahamsson Mboned M. Abrahamsson
Internet-Draft T-Systems Internet-Draft T-Systems
Intended status: Best Current Practice T. Chown Intended status: Best Current Practice T. Chown
Expires: April 25, 2019 Jisc Expires: August 15, 2019 Jisc
L. Giuliano L. Giuliano
Juniper Networks, Inc. Juniper Networks, Inc.
T. Eckert T. Eckert
Huawei Huawei
October 22, 2018 February 11, 2019
Deprecating ASM for Interdomain Multicast Deprecating ASM for Interdomain Multicast
draft-ietf-mboned-deprecate-interdomain-asm-02 draft-ietf-mboned-deprecate-interdomain-asm-03
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 that hosts and routers in these deployments fully
support SSM. The recommendations in this document do not preclude support SSM. The recommendations in this document do not preclude
the continued use of ASM within a single organisation or domain and the continued use of ASM within a single organisation or domain and
are especially easy to adopt in existing intradomain ASM/PIM-SM are especially easy to adopt in existing intradomain ASM/PIM-SM
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 April 25, 2019. This Internet-Draft will expire on August 15, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
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 . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . 8 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 . . . . . . 9 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 . . . . . . 11 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
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
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
skipping to change at page 6, line 14 skipping to change at page 6, line 14
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 (complex flooding RPF rules, state attack protection, troubleshoot (complex flooding RPF rules, state attack protection,
filtering of undesired sources, ...). 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 eliminates the most unnecessary complexity. Therefore, SSM removes the need for many of
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,
the proposed interdomain ASM solution for PIM-SM with IPv6 is 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-RP, which allows the RP address for a multicast group to be
embedded in the group address, making RP discovery automatic for all embedded in the group address, making RP discovery automatic for all
routers on the path between a receiver and a sender. Embedded-RP can routers on the path between a receiver and a sender. Embedded-RP can
support lightweight ad-hoc deployments. However, it relies on a support lightweight ad-hoc deployments. However, it relies on a
single RP for an entire group that could only be made resilient single RP for an entire group that could only be made resilient
within one domain. While this approach solves the MSDP issues, it within one domain. While this approach solves the MSDP issues, it
does not solve the problem of unauthorised sources sending traffic to does not solve the problem of unauthorised sources sending traffic to
ASM multicast groups; this security issues is one of biggest problem ASM multicast groups; this security issue is one of biggest problems
of interdomain multicast. of interdomain multicast.
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 oob mechanism) before the application identities are known (by some out-of-band mechanism) before the
starts running or applications that utilize some signaling to application starts running or applications that utilize some
indicate the source address of the multicast stream (eg, electronic signaling to indicate the source address of the multicast stream
programming guide in IPTV applications). PIM-SSM is therefore very (e.g., electronic programming guide in IPTV applications). PIM-SSM
well-suited to applications such as classic linear broadcast TV over is therefore very well-suited to applications such as classic linear
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 IGMPv3 [RFC3376] and
MLDv2 [RFC3810]. Support for IGMPv3 and MLDv2 has become widespread MLDv2 [RFC3810]. Support for IGMPv3 and MLDv2 has become widespread
in common OSes for several years (Windows, MacOS, Linux/Android) and in common OSes for several years (Windows, MacOS, Linux/Android) and
is no longer an impediment to SSM deployment. 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 area of benefits that SSM with This section describes the three key benefits that SSM with PIM-SSM
PIM-SSM has over ASM. These benefits also apply to intradomain has over ASM. These benefits also apply to intradomain deployment
deployment but are even more important in interdomain deployments. but are even more important in interdomain deployments. See
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
skipping to change at page 7, line 38 skipping to change at page 7, line 38
therefore trades state complexity with (potentially large amounts) of therefore trades state complexity with (potentially large amounts) of
unnecessary traffic. unnecessary traffic.
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 each others IP multicast traffic.
Protocols to automate ASM IP multicast group allocations to
application instances where defined in the 1990'ths, but never widely
deployed: MADCAP [RFC2730], MASC [RFC2909] and MZAP [RFC2776].
Today, all ASM IP multicast group allocation are based on per-
operator, non-standardized and mostly manual assignment practices
which adds to the operational overhead of supporting ASM.
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: No two a source like a unicast transport protocol port number: No two
independent applications on the host must use same IP multicast group independent applications on the host must use same IP multicast group
number. This does not require any network operator involvement. number. This 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 unauthorized/undesired sources. SSM is implicitly secure against unauthorized/undesired sources.
Receivers only receive packets from the sources they explicitly Receivers only receive packets from the sources they explicitly
specify in their IGMP/MLD membreship messages, as opposed to ASM specify in their IGMP/MLD membership messages, as opposed to ASM
where any host can send traffic to a group address and have it where any host can send traffic to a group address and have it
transmitted to all receivers. With PIM-SSM, traffic from sources not transmitted to all receivers. With PIM-SSM, traffic from sources not
requested by any receiver will be discarded by the first-hop router requested by any receiver will be discarded by the first-hop router
(FHR) of that source, minimizing source attacks against shared (FHR) of that source, minimizing source attacks against shared
network bandwidth and receivers. 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 senders 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
4.1. Deprecating use of ASM for interdomain multicast 4.1. Deprecating use of ASM for interdomain multicast
This document recommends that the use of ASM is deprecated for This document recommends that the use of ASM is deprecated for
interdomain multicast, and thus implicitly, that hosts and routers interdomain multicast, and thus implicitly, that hosts and routers
skipping to change at page 9, line 8 skipping to change at page 8, line 44
also extends to the case where PIM may only be operated in a single 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 operator domain, but where user hosts or non-PIM network edge devices
are under different operator control. A typical example of this case are under different operator control. A typical example of this case
is an SP providing IPTV (single operator domain for PIM) to is an SP providing IPTV (single operator domain for PIM) to
subscribers operating an IGMP proxy home gateway and IGMPv3/MLDv2 subscribers operating an IGMP proxy home gateway and IGMPv3/MLDv2
hosts (computer, tablets, set-top boxes). 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 supporting multicast support IGMPv3 [RFC3376] and security appliances used for deploying multicast support the
MLDv2 [RFC3810] (based on the version IP they intend to support). components of IGMPv3 [RFC3376] and MLDv2 [RFC3810] necessary to
The updated IPv6 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] support SSM (i.e., explicitly sending source-specific reports). The
states that MLDv2 support is a MUST in all implementations. Such updated IPv6 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] states
support is already widespread in common host and router platforms. that MLDv2 support is a MUST in all implementations. Such support is
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 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 host monitor IGMP/MLD messages and only forward multicast traffic out on
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].
4.3. Building application support for SSM 4.3. Building application support for SSM
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
messages. It should be noted, however, there is a wide range of source-specific report messages. It should be noted, however, there
applications today that only support ASM. In many cases this is due is a wide range of applications today that only support ASM. In many
to application developers being unaware of the operational concerns cases this is due to application developers being unaware of the
of networks. This document serves to provide clear direction for operational concerns of networks. This document serves to provide
application developers to support SSM. clear direction for application developers to support SSM.
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, RFC 4607 also describes where there are multiple sources. However, RFC 4607 also describes
how SSM can be used instead of PIM-SM for multi-party applications: how SSM can be used instead of PIM-SM for multi-party applications:
"SSM can be used to build multi-source applications where all "SSM can be used to build multi-source applications where all
participants' identities are not known in advance, but the multi- participants' identities are not known in advance, but the multi-
source "rendezvous" functionality does not occur in the network source "rendezvous" functionality does not occur in the network
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 feasible for networks, whether the source discovery
is done by ASM with PIM-SM or at the application level and SSM/PIM- is done by ASM with PIM-SM or at the application level and SSM/PIM-
SM. These applications are not best supported by neithre SSM/PIM-SSM SM. These applications are not best supported by either SSM/PIM-SSM
nor ASM/PIM-SM. 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. As of today, that do not create (S,G) such as Bidir-PIM. As of today,
Unfortunately, many applications simply use ASM for service Unfortunately, many applications simply use ASM for service
discovery, for example by clients sending IP multicast packets to discovery, for example by clients sending 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 (complexity, control, ...) but instead dedicated not recommended (complexity, control, ...) but instead dedicated
service discovery via DNS [RFC6763] service discovery via DNS [RFC6763]
Best practices should be developed to explain when to use SSM in Best practices should be developed to explain when to use SSM in
application, when ASM without (S,G) state in the network is better, applications, when ASM without (S,G) state in the network is better,
or when dedicated service-discovery mechanisms should be used. or when dedicated service-discovery mechanisms should be used.
4.5. Preferring SSM applications intradomain 4.5. Preferring SSM applications intradomain
If feasible, it is recommended for applications to use SSM even if If feasible, it is recommended for applications to use SSM even if
they are initially only meant to be used in intradomain environments they are initially only meant to be used in intradomain environments
supporting ASM. Because PIM-SSM is a subset of PIM-SM, existing supporting ASM. Because PIM-SSM is a subset of PIM-SM, existing
intradomain PIM-SM networks are automatically compatible with SSM intradomain PIM-SM networks are automatically compatible with SSM
applications. Thus, SSM applications can operate alongside existing applications. Thus, SSM applications can operate alongside existing
ASM applications. SSM's benefits of simplified address management ASM applications. SSM's benefits of simplified address management
skipping to change at page 10, line 50 skipping to change at page 10, line 38
to a (S,G) join or leave, for a specific source, S. The general to a (S,G) join or leave, for a specific source, S. The general
challenge in performing such mapping is determining where the challenge in performing such mapping is determining where the
configured source address, S, comes from. configured source address, S, comes from.
There are existing vendor-specific mechanisms deployed that achieve There are existing vendor-specific mechanisms deployed that achieve
this function, but none are documented in IETF documents. This may this function, but none are documented in IETF documents. This may
be a useful area for the IETF to work on as an interim transition be a useful area for the IETF to work on as an interim transition
mechanism. However, these mechanisms would introduce additional mechanism. However, these mechanisms would introduce additional
administrative burdens, along with the need for some form of address administrative burdens, along with the need for some form of address
management, neither of which are required in SSM. Hence, this should management, neither of which are required in SSM. Hence, this should
not be considered a a long-term solution. not be considered a long-term solution.
4.7. Not filtering ASM addressing between domains 4.7. Not filtering ASM addressing between domains
A key benefit of SSM is that the receiver specifies the source-group A key benefit of SSM is that the receiver specifies the source-group
tuple when signaling interest in a multicast stream. Hence, the tuple when signaling interest in a multicast stream. Hence, the
group address need not be globally unique, so there is no need for group address need not be globally unique, so there is no need for
multicast address allocation as long the reserved SSM range is used. multicast address allocation as long the reserved SSM range is used.
Despite the deprecation of interdomain ASM, it is recommended that Despite the deprecation of interdomain ASM, it is recommended that
operators should not filter ASM group ranges at domain boundaries, as operators should not filter ASM group ranges at domain boundaries, as
skipping to change at page 12, line 11 skipping to change at page 11, line 49
When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also
result in the desired PIM-SSM (S,G) operations and bypass any RP result in the desired PIM-SSM (S,G) operations and bypass any RP
procedures, but this is not standardized but depends on procedures, but this is not standardized but depends on
implementation and may require additional configuration in available implementation and may require additional configuration in available
products. In general, it is recommended to always use SSM address products. In general, it is recommended to always use SSM address
space for SSM applications. For example, the interaction of IGMPv3/ space for SSM applications. For example, the interaction of IGMPv3/
MLDv2 (S,G) membership reports and Bidir-PIM is undefined and may not MLDv2 (S,G) membership reports and Bidir-PIM is undefined and may not
result in forwarding of any traffic. result in forwarding of any traffic.
Note that this migration recommendations do not include the Note that these migration recommendations do not include the
considerations when or how to evolve those intradomain applications considerations when or how to evolve those intradomain applications
best served by ASM/Bidir-PIM from PIM-SM to Bidir-PIM. This may also best served by ASM/Bidir-PIM from PIM-SM to Bidir-PIM. This may also
be important but is outside the scope of this document. be important but is outside the scope of this document.
5. Future interdomain ASM work 5. Future interdomain ASM work
Future work may attempt to overcome current limitations of ASM Future work may attempt to overcome current limitations of ASM
solutions, such as interdomain deployment solutions for Bidir-PIM, or solutions, such as interdomain deployment solutions for Bidir-PIM, or
source access control mechaisms for IPv6 PIM-SM with embedded-RP. source access control mechaisms for IPv6 PIM-SM with embedded-RP.
Such work could modify or amend the recommendations of this document Such work could modify or amend the recommendations of this document
 End of changes. 25 change blocks. 
50 lines changed or deleted 43 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/