idnits 2.17.1 draft-ietf-pim-proposed-req-00.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.a on line 13. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations 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.) ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (January 2005) is 7034 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) ** Downref: Normative reference to an Experimental RFC: RFC 2934 (ref. 'PIMMIB') -- Obsolete informational reference (is this intentional?): RFC 1264 (ref. 'ROUTESTD') (Obsoleted by RFC 4794) Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tom Pusateri 2 Internet-Draft Juniper Networks 3 Expires: July 11, 2005 January 2005 5 PIM IETF Proposed Standard Requirements Analysis 6 draft-ietf-pim-proposed-req-00.txt 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 RFC 3668. 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 1. Introduction 33 This analysis provides supporting documentation to advance the 34 Protocol Independent Multicast (PIM) routing protocol from the IETF 35 Experimental status to Proposed Standard. PIM was first published as 36 RFC 2117 in 1997 and then again as RFC 2362 in 1998. The protocol was 37 classified as Experimental in both of these documents. The PIM 38 protocol specification was then rewritten in whole in order to more 39 fully specify the protocol. It is this new specification that is to 40 be advanced to Proposed Standard. 42 2. RFC 1264 Requirements 44 Section 4.0 of RFC 1264 [ROUTESTD] describes the requirements for 45 routing protocols to advance to Proposed Standard. Each requirement 46 is listed below along with an explanation of how the requirement has 47 been satisfied. 49 2.1. Documents specifying the Protocol and its Usage 51 The authors of the new PIM specification have taken considerable care 52 to fully specify the protocol operation. It removes all known 53 ambiguities and tries to normalize corner cases that existed in the 54 previous specification. It has been used to provide several 55 interoperable implementations by developers that were not authors of 56 the specification. These implementations will be described below. 58 2.2. Management Information Base 60 A Management Information Base for PIM is currently specified in RFC 61 2934 [PIMMIB]. This MIB has many implementations and has been used 62 by network management applications for several years. Updates to this 63 MIB to support IPv6 and other improvements based on operation 64 experience are in progress in the PIM Working Group of the IETF. 66 2.3. Explicit Security Architecture 68 The new PIM protocol specification contains an extensive security 69 section explaining its security features and limitations. Data 70 integrity protection and groupwise data origin authentication is 71 provided for PIM protocol messages. 73 2.4. Implementation Existence 75 There are at least 4 known independent implementations of the new 76 protocol specification and there are over 6 independent 77 implementations of a previous version (RFC 2362) of the 78 specification. The new specification was carefully written to be 79 backward compatible with the old specification allowing 80 implementations compliant with RFC 2362 to also be compliant with the 81 new specification. 83 The 4 implementations of the new version are described below: 85 XORP 86 The XORP project [XORP] has an open-source implementation of PIM- 87 SMv2 as specified in the draft-ietf-pim-sm-v2-new-11.txt. It was 88 written by Pavlin Radoslavov and has been 89 available to the public since December 2002. Pavlin is not an 90 author of the protocol specification. It does not use any other 91 existing code as a base. 93 Cisco IOS/IOX 94 Cisco Systems, Inc. has written an implementation of the new 95 protocol specification which has been deployed in production 96 routers. There exists an IOS implementation for IPv6 only. There 97 exists an IOX implementation for both IPv4 and IPv6. This code was 98 initially written by Isidor Kouvelas . It does 99 not depend on any existing code base. Isidor is a co-author of 100 the protocol specification. 102 Infosys Technologies, Ltd. 103 Infosys Technologies, Ltd. (www.infosys.com) have developed a 104 limited shared tree implementation of the new specification 105 including PIM Hello messages, DR election, PIM join/prune 106 messages, join suppression, and prune override. It was written by 107 Bharat Joshi < and is used in commercial 108 products. Bharat is not an author of the protocol specification. 110 Procket Networks 111 An implementation was written from scratch at Procket Networks by 112 Dino Farinacci . This implementation is now owned 113 by Cisco Systems, Inc. Dino is not an author of the new protocol 114 speicfication. 116 2.5. Evidence of Testing 118 Cisco 119 The Cisco implementation has undergone extensive laboratory 120 testing as well as testing in production deployments. It is found 121 to interoperate with implementations of earlier versions of the 122 PIM protocol specification. 124 XORP 125 The XORP PIM-SM implementation has been thoughtfully tested 126 internally by the XORP project. The emphasis during testing has 127 been on correctness. In a typical setup, a PIM-SM router's 128 behavior is tested by connecting it to external packet generators 129 and observers. The packet generators are used to generate messages 130 such as IGMP and PIM-SM control packets, and multicast data 131 packets. The packet observers are used to observe the PIM-SM 132 control packets generated by the PIM-SM router under test, and to 133 observe the data packets that may be forwarded by that router. In 134 addition, the router's command-line interface has been used to 135 observe its internal state during some of the tests. 137 The test scenarios have been designed to closely follow the 138 protocol specification (e.g., a separate test has been created for 139 each event in the various protocol state machines, etc). All test 140 scenarios are described in detail in [XORP-Test]. 142 The major tested features are: 144 1. Multicast data forwarding. 146 2. PIM Hello messages exchange, PIM router neighbor discovery, 147 option exchange, and DR election. 149 3. PIM Register messages transmission and reception, PIM Register 150 state machine, multicast data packets encapsulation and 151 decapsulation. 153 4. Transmission and reception of PIM Join/Prune messages, upstream 154 and downstream protocol state machines. The tests consider the 155 following state: (*,*,RP), (*,G), (S,G) and (S,G,rpt). 157 5. Transmission and reception of PIM Assert messages and the per- 158 interface (*,G) and (S,G) Assert state machines. 160 6. PIM Bootstrap mechanism: transmission, reception and forwarding 161 of PIM Bootstrap messages, transmission and reception of PIM 162 Cand-RP-Adv messages, candidate and non-candidate BSR state 163 machines, creating the RP-Set at the BSR, receiving and using 164 the RP-Set, semantic fragmentation of BSMs. 166 In the final tests, the tested router behaved as specified in the 167 PIM-SM protocol specification. All issues found in the protocol 168 specification itself have been corrected in earlier versions of 169 the Internet Draft. 171 Procket Networks 172 The Procket Networks implementation was deployed in many research 173 and service provider networks and showed interoperability with new 174 and old Cisco Systems implementations as well as Juniper Networks 175 implementations. 177 2.6. Suitability 179 PIM Sparse-Mode is a protocol for efficiently routing multicast 180 groups that may span wide-area (and inter-domain) Internets. PIM 181 uses the underlying unicast routing to provide reverse-path 182 information for multicast tree building but it is not dependent on 183 any particular unicast routing protocol. 185 2.7. Authentication Mechanisms 187 PIM specifies the use of the IP security authentication header to 188 provide data integrity protection and groupwise data origin 189 authentication of protocol messages. The specific AH authentication 190 algorithm and parameters, including the choice of authentication 191 algorithm and the choice of key, are configured by the network 192 administrator. The threats associated with receiving forged PIM 193 messages are outlined in the security considerations section of the 194 protocol specification. 196 3. Acknowledgments 198 Pavlin Radoslavov provided text for the section on XORP testing. 199 Dino Farinacci provided text for the Procket Networks testing. 201 4. Normative References 203 [PIMMIB] McCloghrie, K., Farinacci, D., Thaler, D., Fenner, B., 204 "Protocol Independent Multicast MIB for IPv4", RFC 2934, 205 October 2000. 207 5. Informative References 209 [ROUTESTD] Hinden, R., "Internet Routing Protocol Standardization 210 Criteria", RFC 1264, October 1991. 212 [XORP] XORP Project, http://www.xorp.org/ 214 [XORP-Test] XORP PIM-SM Test Suite, 215 http://www.xorp.org/releases/current/docs/pim_test- 216 suite/pim_testsuite.pdf 218 6. Author's Address 220 Tom Pusateri 221 Juniper Networks, Inc. 222 1194 North Mathilda Avenue 223 Sunnyvale, CA 94089 USA 224 Phone: (408) 745-2000 225 EMail: pusateri@juniper.net 227 7. Full Copyright Statement 229 Copyright (C) The Internet Society (2005). This document is subject 230 to the rights, licenses and restrictions contained in BCP 78, and 231 except as set forth therein, the authors retain all their rights. 233 8. Disclaimer 235 This document and the information contained herein are provided on an 236 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 237 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 238 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 239 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 240 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 241 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 242 Table of Contents 244 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1 245 2. RFC 1264 Requirements . . . . . . . . . . . . . . . . . . . . 2 246 2.1. Documents specifying the Protocol and its Usage . . . . . . 2 247 2.2. Management Information Base . . . . . . . . . . . . . . . . 2 248 2.3. Explicit Security Architecture . . . . . . . . . . . . . . . 2 249 2.4. Implementation Existence . . . . . . . . . . . . . . . . . . 2 250 2.5. Evidence of Testing . . . . . . . . . . . . . . . . . . . . 3 251 2.6. Suitability . . . . . . . . . . . . . . . . . . . . . . . . 5 252 2.7. Authentication Mechanisms . . . . . . . . . . . . . . . . . 5 253 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 254 4. Normative References . . . . . . . . . . . . . . . . . . . . . 5 255 5. Informative References . . . . . . . . . . . . . . . . . . . . 5 256 6. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 257 7. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 6 258 8. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 6