idnits 2.17.1 draft-tsenevir-pim-sm-snoop-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 300 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 1. Intercept Join/Prune messages [3] 2. Ability to create IP Multicast scope per VLAN (Virtual LAN) basis. 3. MUST not have impact on other Multicast traffic 4. MUST not modify packet content (such as TTL..) or in other words MUST be forwarded using Layer 2 forwarding rules. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 14 looks like a reference -- Missing reference section? '2' on line 47 looks like a reference -- Missing reference section? '3' on line 87 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDMR Working Group Tissa Senevirathne 3 Internet Draft Sridhar Vallepali 4 Document: draft-tsenevir-pim-sm-snoop-00.txt 5 Category: Informational Force10 Networks 6 April, 2002 8 Protocol Independent Multicast-Sparse Mode (PIM-SM) Snooping 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- Drafts 21 as reference material or to cite them other than as "work in 22 progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 For potential updates to the above required-text see: 29 http://www.ietf.org/ietf/1id-guidelines.txt 31 Abstract 33 This document provides PIM-SM snooping solution. In the document we 34 present the framework and reference model and required PIM-SM 35 messages for PIM-SM snooping solutions. Also we attempt to discuss 36 related issues to PIM-SM snooping. 38 Senevirathne Informational - Expiration October 2002 1 40 draft-tsenevir-pim-sm-snooping-00.txt April 2002 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 46 this document are to be interpreted as described in RFC-2119 [2]. 48 1. Introduction 50 IGMP snooping is popularly used to limit the scope of IP multicast 51 traffic in enterprise Local Area Networks (LAN). With the recent 52 popularity of Layer 2 Networks in core of the networks, PIM-SM 53 snooping is gaining popularity as a way of constraining IP multicast 54 traffic to the section of network that is interested in receiving 55 such traffic. 57 | | 58 | | 59 ------ -------- 60 | | | | 61 | PIM-R | | PIM-R | 62 ------- \ / -------- 63 \ Multicast Routed / 64 ---------\-------------------- / ----------- 65 ----- ------/ 66 | S | | S | Layer 2 Switched/Bridged 67 | |-------| | 68 / ----- ------ \ 69 -------- / --------------------- \--------------- 70 ------- / Multicast Routed \ -------- 71 | | | | 72 | PIM-R | | PIM-R | 73 ------- -------- 74 | | 75 | | 77 PIM-R - PIM-SM Routers 79 S - PIM-SM Snooping Device 81 Fig: Reference Model of PIM-SM snooping 83 2. PIM-SM Snooping Framework 85 Devices that implement PIM-SM snooping are required have ability to 87 1. Intercept Join/Prune messages [3] 88 2. Ability to create IP Multicast scope per VLAN (Virtual LAN) 89 basis. 90 3. MUST not have impact on other Multicast traffic 91 4. MUST not modify packet content (such as TTL..) or in other words 92 MUST be forwarded using Layer 2 forwarding rules. 94 Senevirathne Informational - Expiration October 2002 2 96 draft-tsenevir-pim-sm-snooping-00.txt April 2002 98 3. Theory of Operation 100 Let assume that 102 VLAN V has interfaces I == {i1, i2, ..ij...in} 104 Let assume we identified, by snooping PIM-SM join messages, that 105 interface set G need to join (*,G) or (S,G). These interfaces Let 106 call outgoing interfaces. 108 G == {o1, o2, ..oj..om}; G subset of I. 110 Now create a sub-scope S within the VLAN such that 112 input interfaces == I and 113 out put interfaces == G 115 3.1 Maintaining outgoing interfaces 117 outgoing interface (o) is added to the list when a join message is 118 received from that interface. 120 When an interface is added to the G a Hold timer is created for each 121 interface. Periodic Join messages update the life. 123 When there are more than on Join is received from a given interface 124 the largest hold time MUST be used. 126 When hold time expires the interface SHOULD be removed from that 127 group for that VLAN. 129 When a Prune message is received the interface SHOULD be removed 130 from that group for that VLAN. 132 If more than one Join message was received from an interface and a 133 Prune message is received the Hold timer MUST be update according to 134 the other active Joins. 136 3.2 (*,G) vs (S,G) 138 Devices that perform PIM-SM snooping is practically operating as a 139 Layer 2 device. When PIM-SM is not implemented entire VLAN is the IP 140 Multicast scope. The scope of PIM-SM snooping is to constrain the IP 141 Multicast data flooding. As such, PIM-SM snooping does not attempt 142 to disnguish between (*,G) and (S,G). In effect PIM-SM snooping 143 implement (V,G). Where V is all interface of the VLAN V. Such 144 generalization, simplify the implementation; servers the purpose and 145 avoid blackholes when IP routing changes the RPF inetrfaces. 147 4. Security Considerations 149 PIM-SM snooping does not affect the security aspects of PIM-SM. 151 Senevirathne Informational - Expiration October 2002 3 153 draft-tsenevir-pim-sm-snooping-00.txt April 2002 155 5. References 157 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 158 9, RFC 2026, October 1996. 160 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 161 Levels", BCP 14, RFC 2119, March 1997 163 3 Estrin, D., et.al, Protocol Independent Multicast-Sparse Mode 164 (PIM-SM): Protocol Specification, RFC 2362, June 1998. 166 10. Acknowledgments 168 11. Author's Addresses 170 Tissa Senevirathne 171 1440 McCarthy Blvd 172 Milpitas, CA 173 Phone: 408-965-5103 174 Email: tsenevir@force10networks.com 176 Sridhar Vallepali 177 1440 McCarthy Blvd 178 Milpitas, CA 179 Phone: 408-571-3500 181 Senevirathne Informational - Expiration October 2002 4 183 draft-tsenevir-pim-sm-snooping-00.txt April 2002 185 Full Copyright Statement 187 "Copyright (C) The Internet Society (2002). All Rights Reserved. 188 This document and translations of it may be copied and furnished to 189 others, and derivative works that comment on or otherwise explain it 190 or assist in its implmentation may be prepared, copied, published 191 and distributed, in whole or in part, without restriction of any 192 kind, provided that the above copyright notice and this paragraph 193 are included on all such copies and derivative works. However, this 194 document itself may not be modified in any way, such as by removing 195 the copyright notice or references to the Internet Society or other 196 Internet organizations, except as needed for the purpose of 197 developing Internet standards in which case the procedures for 198 copyrights defined in the Internet Standards process must be 199 followed, or as required to translate it into 201 Senevirathne Informational - Expiration October 2002 5