idnits 2.17.1 draft-ietf-pim-proposed-req-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 323. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 336. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (March 5, 2006) is 6625 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-pim-sm-v2-new' is defined on line 267, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-11 ** Downref: Normative reference to an Experimental RFC: RFC 2934 -- Obsolete informational reference (is this intentional?): RFC 1264 (Obsoleted by RFC 4794) -- Obsolete informational reference (is this intentional?): RFC 2117 (Obsoleted by RFC 2362) -- Obsolete informational reference (is this intentional?): RFC 2362 (Obsoleted by RFC 4601, RFC 5059) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Pusateri 2 Internet-Draft Juniper Networks 3 Expires: September 6, 2006 March 5, 2006 5 PIM Sparse-Mode IETF Proposed Standard Requirements Analysis 6 draft-ietf-pim-proposed-req-02 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 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. 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 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 6, 2006. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). 37 Abstract 39 This document provides supporting documentation to advance the 40 Protocol Independent Multicast (PIM) Sparse-Mode routing protocol 41 from the IETF Experimental status to Proposed Standard. 43 Requirements Language 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [RFC2119]. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. RFC 1264 Requirements . . . . . . . . . . . . . . . . . . . . 3 53 2.1 Documents specifying the Protocol and its Usage . . . . . 3 54 2.2 Management Information Base . . . . . . . . . . . . . . . 3 55 2.3 Explicit Security Architecture . . . . . . . . . . . . . . 3 56 2.4 Implementation Existence . . . . . . . . . . . . . . . . . 3 57 2.4.1 XORP . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.4.2 Cisco IOS/IOX . . . . . . . . . . . . . . . . . . . . 4 59 2.4.3 Infosys Technologies, Ltd. . . . . . . . . . . . . . . 4 60 2.4.4 Procket Networks . . . . . . . . . . . . . . . . . . . 4 61 2.5 Evidence of Testing . . . . . . . . . . . . . . . . . . . 4 62 2.5.1 Cisco . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.5.2 XORP . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.5.3 Procket Networks . . . . . . . . . . . . . . . . . . . 6 65 2.6 Suitability . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.7 Authentication Mechanisms . . . . . . . . . . . . . . . . 6 67 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 6.1 Normative References . . . . . . . . . . . . . . . . . . . 7 72 6.2 Informative References . . . . . . . . . . . . . . . . . . 7 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 74 Intellectual Property and Copyright Statements . . . . . . . . 9 76 1. Introduction 78 This analysis provides supporting documentation to advance the 79 Protocol Independent Multicast (PIM) Sparse-Mode routing protocol 80 from the IETF Experimental status to Proposed Standard. PIM Sparse- 81 Mode was first published as RFC 2117 [RFC2117] in 1997 and then again 82 as RFC 2362 [RFC2362] in 1998. The protocol was classified as 83 Experimental in both of these documents. The PIM Sparse-Mode 84 protocol specification was then rewritten in whole in order to more 85 fully specify the protocol. It is this new specification that is to 86 be advanced to Proposed Standard. 88 2. RFC 1264 Requirements 90 Section 4.0 of RFC 1264 [RFC1264] describes the requirements for 91 routing protocols to advance to Proposed Standard. Each requirement 92 is listed below along with an explanation of how the requirement has 93 been satisfied. 95 2.1 Documents specifying the Protocol and its Usage 97 The authors of the new PIM Sparse-Mode specification [I-D.ietf-pim- 98 sm-v2-new] have taken considerable care to fully specify the protocol 99 operation. It removes all known ambiguities and tries to normalize 100 corner cases that existed in the previous specification. It has been 101 used to provide several interoperable implementations by developers 102 that were not authors of the specification. These implementations 103 will be described below. 105 2.2 Management Information Base 107 A Management Information Base for PIM is currently specified in RFC 108 2934 [RFC2934]. This MIB has many implementations and has been used 109 by network management applications for several years. Updates to 110 this MIB to support IPv6 and other improvements based on operation 111 experience are in progress in the PIM Working Group of the IETF. 113 2.3 Explicit Security Architecture 115 The new PIM Sparse-Mode protocol specification contains an extensive 116 security section explaining its security features and limitations. 117 Data integrity protection and groupwise data origin authentication is 118 provided for PIM protocol messages. 120 2.4 Implementation Existence 122 There are at least 4 known independent implementations of the new 123 protocol specification and there are over 6 independent 124 implementations of a previous version (RFC 2362) of the 125 specification. The new specification was carefully written to be 126 backward compatible with the old specification allowing 127 implementations compliant with RFC 2362 to also be compliant with the 128 new specification. 130 The 4 implementations of the new version are described below: 132 2.4.1 XORP 134 The XORP project [XORP] has an open-source implementation of PIM-SM 135 v2 as specified in the draft-ietf-pim-sm-v2-new-11.txt. It was 136 written by Pavlin Radoslavov and has been available 137 to the public since December 2002. Pavlin is not an author of the 138 protocol specification. It does not use any other existing code as a 139 base. 141 2.4.2 Cisco IOS/IOX 143 Cisco Systems, Inc. has written an implementation of the new protocol 144 specification which has been deployed in production routers. There 145 exists an IOS implementation for IPv6 only. There exists an IOX 146 implementation for both IPv4 and IPv6. This code was initially 147 written by Isidor Kouvelas . It does not depend 148 on any existing code base. Isidor is a co-author of the protocol 149 specification. 151 2.4.3 Infosys Technologies, Ltd. 153 Infosys Technologies, Ltd. (www.infosys.com) have developed a limited 154 shared tree implementation of the new Sparse-Mode specification 155 including PIM Hello messages, DR election, PIM join/prune messages, 156 join suppression, and prune override. It was written by Bharat Joshi 157 and is used in commercial products. 158 Bharat is not an author of the protocol specification. 160 2.4.4 Procket Networks 162 An implementation was written from scratch at Procket Networks by 163 Dino Farinacci . This implementation is now owned by 164 Cisco Systems, Inc. Dino is not an author of the new protocol 165 specification. 167 2.5 Evidence of Testing 169 2.5.1 Cisco 171 The Cisco implementation has undergone extensive laboratory testing 172 as well as testing in production deployments. It is found to 173 interoperate with implementations of earlier versions of the PIM 174 Sparse-Mode protocol specification. 176 2.5.2 XORP 178 The XORP PIM-SM implementation has been thoughtfully tested 179 internally by the XORP project. The emphasis during testing has been 180 on correctness. In a typical setup, a PIM-SM router's behavior is 181 tested by connecting it to external packet generators and observers. 182 The packet generators are used to generate messages such as IGMP and 183 PIM-SM control packets, and multicast data packets. The packet 184 observers are used to observe the PIM-SM control packets generated by 185 the PIM-SM router under test, and to observe the data packets that 186 may be forwarded by that router. In addition, the router's command- 187 line interface has been used to observe its internal state during 188 some of the tests. 190 The test scenarios have been designed to closely follow the protocol 191 specification (e.g., a separate test has been created for each event 192 in the various protocol state machines, etc). All test scenarios are 193 described in detail in the XORP PIM-SM Test Suite [XORP-TEST]. 195 The major tested features are: 197 1. Multicast data forwarding. 199 2. PIM Hello messages exchange, PIM router neighbor discovery, 200 option exchange, and DR election. 202 3. PIM Register messages transmission and reception, PIM Register 203 state machine, multicast data packets encapsulation and 204 decapsulation. 206 4. Transmission and reception of PIM Join/Prune messages, upstream 207 and downstream protocol state machines. The tests consider the 208 following state: (*,*,RP), (*,G), (S,G) and (S,G,rpt). 210 5. Transmission and reception of PIM Assert messages and the per- 211 interface (*,G) and (S,G) Assert state machines. 213 6. PIM Bootstrap mechanism: transmission, reception and forwarding 214 of PIM Bootstrap messages, transmission and reception of PIM 215 Cand-RP-Adv messages, candidate and non-candidate BSR state 216 machines, creating the RP-Set at the BSR, receiving and using the 217 RP-Set, semantic fragmentation of BSMs. 219 In the final tests, the tested router behaved as specified in the 220 PIM-SM protocol specification. All issues found in the protocol 221 specification itself have been corrected in earlier versions of the 222 Internet Draft. 224 2.5.3 Procket Networks 226 The Procket Networks implementation was deployed in many research and 227 service provider networks and showed interoperability with new and 228 old Cisco Systems implementations as well as Juniper Networks 229 implementations. 231 2.6 Suitability 233 PIM Sparse-Mode is a protocol for efficiently routing multicast 234 groups that may span wide-area (and inter-domain) Internets. PIM 235 uses the underlying unicast routing to provide reverse-path 236 information for multicast tree building but it is not dependent on 237 any particular unicast routing protocol. 239 2.7 Authentication Mechanisms 241 PIM specifies the use of the IP security (IPsec) authentication 242 header (AH) to provide data integrity protection and groupwise data 243 origin authentication of protocol messages. The specific AH 244 authentication algorithm and parameters, including the choice of 245 authentication algorithm and the choice of key, are configured by the 246 network administrator. The threats associated with receiving forged 247 PIM messages are outlined in the security considerations section of 248 the protocol specification. 250 3. IANA Considerations 252 This document makes no request of IANA. 254 4. Security Considerations 256 No considerations apply to a requirements analysis about a routing 257 protocol, only to a specification for that routing protocol. 259 5. Acknowledgments 261 Pavlin Radoslavov provided text for the section on XORP testing. 262 Dino Farinacci provided text for the Procket Networks testing. 264 6. References 265 6.1 Normative References 267 [I-D.ietf-pim-sm-v2-new] 268 Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 269 "Protocol Independent Multicast - Sparse Mode PIM-SM): 270 Protocol Specification (Revised)", 271 draft-ietf-pim-sm-v2-new-11 (work in progress), 272 October 2004. 274 [RFC2934] McCloghrie, K., Farinacci, D., Thaler, D., and B. Fenner, 275 "Protocol Independent Multicast MIB for IPv4", RFC 2934, 276 October 2000. 278 6.2 Informative References 280 [RFC1264] Hinden, R., "Internet Engineering Task Force Internet 281 Routing Protocol Standardization Criteria", RFC 1264, 282 October 1991. 284 [RFC2117] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, 285 S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. 286 Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): 287 Protocol Specification", RFC 2117, June 1997. 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, 293 S., Handley, M., and V. Jacobson, "Protocol Independent 294 Multicast-Sparse Mode (PIM-SM): Protocol Specification", 295 RFC 2362, June 1998. 297 [XORP] "XORP Project", . 299 [XORP-TEST] 300 "XORP PIM-SM Test Suite", . 303 Author's Address 305 Tom Pusateri 306 Juniper Networks 307 1194 North Mathilda Avenue 308 Sunnyvale, CA 94089 309 USA 311 Phone: +1 408 745 2000 312 Email: pusateri@juniper.net 314 Intellectual Property Statement 316 The IETF takes no position regarding the validity or scope of any 317 Intellectual Property Rights or other rights that might be claimed to 318 pertain to the implementation or use of the technology described in 319 this document or the extent to which any license under such rights 320 might or might not be available; nor does it represent that it has 321 made any independent effort to identify any such rights. Information 322 on the procedures with respect to rights in RFC documents can be 323 found in BCP 78 and BCP 79. 325 Copies of IPR disclosures made to the IETF Secretariat and any 326 assurances of licenses to be made available, or the result of an 327 attempt made to obtain a general license or permission for the use of 328 such proprietary rights by implementers or users of this 329 specification can be obtained from the IETF on-line IPR repository at 330 http://www.ietf.org/ipr. 332 The IETF invites any interested party to bring to its attention any 333 copyrights, patents or patent applications, or other proprietary 334 rights that may cover technology that may be required to implement 335 this standard. Please address the information to the IETF at 336 ietf-ipr@ietf.org. 338 Disclaimer of Validity 340 This document and the information contained herein are provided on an 341 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 342 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 343 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 344 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 345 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 346 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 348 Copyright Statement 350 Copyright (C) The Internet Society (2006). This document is subject 351 to the rights, licenses and restrictions contained in BCP 78, and 352 except as set forth therein, the authors retain all their rights. 354 Acknowledgment 356 Funding for the RFC Editor function is currently provided by the 357 Internet Society.