idnits 2.17.1 draft-ietf-mboned-pruning-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([DATE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (30 July 1997) is 9760 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DATE' is mentioned on line 60, but not defined == Unused Reference: 'IPMULTI' is defined on line 91, but no explicit reference was found in the text == Unused Reference: 'MREQ' is defined on line 94, but no explicit reference was found in the text == Unused Reference: 'DVMRP' is defined on line 97, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1458 (ref. 'MREQ') -- Possible downref: Non-RFC (?) normative reference: ref. 'DVMRP' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Hawkinson 2 draft-ietf-mboned-pruning-02.txt BBN Planet 3 Category: Best Current Practice 30 July 1997 5 Multicast pruning a necessity 7 Status of this Memo 9 This document specifies a Best Current Practice for the Internet 10 Community, and requests discussion and suggestions for improvements. 11 Distribution of this memo is unlimited. 13 Internet Drafts 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 This document calls for the MBone to be free of non-pruning multicast 34 as soon as possible, due to the high cost to the Internet of the 35 traffic resulting from them. Consensus is that [DATE 1 month from RFC 36 publication] is the goal date for elimating non-pruning multicast 37 routers. 39 It cites several ways to eliminate non-pruning multicast from a 40 network, allowing per-site flexibility. 42 This is a product of the Multicast Deployment Working Group in the 43 Operational Requirements area of the Internet Engineering Task Force. 44 Submit comments to or the author. 46 Discussion 48 The MBone (Multicast Backbone) of the Internet is composed of a DVMRP 49 backbone connected to regions that may be running other multicast 50 routing protocols. 52 DVMRP versions prior to 3 do not support pruning. Every multicast 53 packet transmitted is delivered to every non-pruning router (subject 54 to scoping rules), regardless of the presence of members of that 55 group. Network paths between each source and each non-pruning router 56 are thus forced to carry all multicast traffic from those sources. 57 This behavior is fundamentally incompatible with a scalable multicast 58 backbone. 60 Effective [DATE], the MBone community will no longer accept such 61 non-pruning implementations as a part of the MBone. Such 62 implementations should be upgraded or disconnected from the MBone 63 prior to that date. Service providers should assist their customers 64 in these processes. 66 DVMRP implementations that do not support pruning include mrouted 67 versions prior to 3, and Cisco Systems IOS prior to version 11.0(3). 68 3Com's NETBuilder routers and LANplex switches have supported pruning 69 as long as DVMRP has been available for them (releases 8.3 and 7.0, 70 respectively). Bay Networks' implementation supports pruning in 71 version 9.00 and up. 73 In the case where the existing infrastructure cannot be upgraded to 74 support pruning, sites may wish to consider deploying lightweight 75 multicast routers instead. For instance, popular free unixes (e.g. 76 FreeBSD, NetBSD, and Linux) that run on cheap PC hardware all support 77 pruning multicast using mrouted. 79 Within non-DVMRP regions, software that does not support DVMRP 80 pruning but does support a similar mechanism of a different protocol 81 (such as CBT, MOSPF, or PIM) is acceptable, as long as the border 82 routers of such a region can translate that mechansism into DVMRP 83 pruning. 85 Security Considerations 87 Security considerations are not addressed in this memo. 89 References 91 [IPMULTI] S.E. Deering, "Host extensions for IP multicasting", RFC1112, 92 1 August 1989. 94 [MREQ] R. Braudes, S. Zabele, "Requirements for Multicast Protocols", 95 RFC1458, 26 May 1993. 97 [DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol", 98 Work in progress (internet-draft). 100 Author's Address 102 John Hawkinson 103 BBN Planet 104 150 CambridgePark Drive 105 Cambridge, MA 02140 107 phone: +1 617 873 3180 108 email: jhawk@bbnplanet.com