--- 1/draft-ietf-mboned-deprecate-interdomain-asm-04.txt 2019-09-04 17:13:05.353562843 -0700 +++ 2/draft-ietf-mboned-deprecate-interdomain-asm-05.txt 2019-09-04 17:13:05.389563759 -0700 @@ -1,23 +1,23 @@ Mboned M. Abrahamsson Internet-Draft T-Systems Intended status: Best Current Practice T. Chown -Expires: March 1, 2020 Jisc +Expires: March 7, 2020 Jisc L. Giuliano Juniper Networks, Inc. T. Eckert Huawei - August 29, 2019 + September 4, 2019 Deprecating ASM for Interdomain Multicast - draft-ietf-mboned-deprecate-interdomain-asm-04 + draft-ietf-mboned-deprecate-interdomain-asm-05 Abstract This document recommends 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 in these deployments 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 in existing intradomain ASM/PIM-SM @@ -39,21 +39,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 1, 2020. + This Internet-Draft will expire on March 7, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -206,21 +206,21 @@ Bidir-PIM [RFC5015] is another protocol to support ASM. There is no standardized option to operate Bidir-PIM interdomain. It is deployed intradomain for applications where many sources send traffic to the same IP multicast groups because unlike PIM-SM it does not create per-source state. Bidir-PIM is one of the important reasons for this document to not deprecate intradomain ASM. 2.3. SSM Routing protocols SSM is detailed in [RFC4607]. It mandates the use of PIM-SSM for - routing of SSM. PIM-SSM as merely a subset of PIM-SM ([RFC7761]). + routing of SSM. PIM-SSM is merely a subset of PIM-SM ([RFC7761]). PIM-SSM expects that the sender's source address(es) is known in advance by receivers through some out-of-band mechanism (typically in the application layer), and thus the receiver's designated router can send a PIM JOIN directly towards the source without needing to use an RP. 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 @@ -301,21 +301,21 @@ This reduced complexity makes SSM radically simpler to manage, troubleshoot and operate, particularly for backbone network operators. This is the main operator motivation for the recommendation to deprecate the use of ASM in interdomain scenarios. Note that this discussion does not apply to Bidir-PIM, and there is (as mentioned above) no standardized interdomain solution for Bidir- 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 receivers. Bidir-PIM therefore trades state complexity with - (potentially large amounts) of unnecessary traffic. + unnecessary traffic (potentially a large amount). 3.2.2. No network wide IP multicast group-address management In ASM, IP multicast group addresses need to be assigned to applications and instances thereof, so that two simultaneously active application instances will not share the same group address and receive each others IP multicast traffic. In SSM, no such IP multicast group management is necessary. Instead, the IP multicast group address simply needs to be assigned locally on @@ -483,21 +483,21 @@ enterprise is still relatively common today. There are even global enterprise networks that have successfully been using PIM-SM for many years. The operators of such networks most often use Anycast-RP [RFC4610] or MSDP (with IPv4) for RP resilience, at the expense of the extra operational complexity. These existing practices are unaffected by this document. In the past decade, Bidir-PIM too has seen deployments to scale interdomain ASM deployments beyond the capabilities of PIM-SM. This 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 multiple PIM-SM domains inside organisations, such as with IPv4 MSDP or IPv6 Embedded-RP. This includes organizations that are federations and have appropriate, non-standardized mechanisms to deal with the interdomain ASM issues explained in Section 3.2. 4.9. Evolving PIM deployments for SSM Existing PIM-SM deployments can usually be used to run SSM @@ -522,21 +522,21 @@ Note that these migration recommendations do not include the considerations when or how to evolve those intradomain applications 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. 5. Future interdomain ASM work Future work may attempt to overcome current limitations of ASM solutions, such as interdomain deployment solutions for Bidir-PIM, or - source access control mechaisms for IPv6 PIM-SM with embedded-RP. + source access control mechanisms for IPv6 PIM-SM with embedded-RP. Such work could modify or amend the recommendations of this document (like any future IETF standards/BCP work). Nevertheless, it is very unlikely that any ASM solution, even with such future work, can ever provide the same intrinsic security and network and address management simplicity as SSM (see Section 3.2). Accordingly, this document recommends that future work for general purpose interdomain IP multicast focus on SSM items listed in Section 4.