idnits 2.17.1 draft-joshi-pim-group-rp-mapping-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 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 311. 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 131: '... o A router MAY use hash function o...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (February 13, 2008) is 5916 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) -- Looks like a reference, but probably isn't: 'PIM-BSR' on line 145 -- Looks like a reference, but probably isn't: 'Cisco' on line 147 ** Obsolete normative reference: RFC 4601 (ref. '1') (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Working Group B. Joshi 3 Internet-Draft Infosys Technologies Ltd. 4 Expires: August 16, 2008 A. Kessler 5 Cisco Systems, Inc. 6 D. McWalter 7 Data Connection Ltd 8 February 13, 2008 10 PIM Group-to-RP Mapping 11 draft-joshi-pim-group-rp-mapping-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 16, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 Each PIM-SM router in a PIM Domain which supports ASM maintains 45 Group-to-RP mappings which are used to identify a RP for a specific 46 multicast group. PIM-SM has defined an algorithm to choose a RP from 47 the Group-to-RP mappings learned using various mechanisms. This 48 algorithm does not allow administrator to override a specific Group- 49 to-RP mapping with the static Group-to-RP mapping which an 50 administrator would want to use. This algorithm also does not 51 consider the PIM mode and the mechanism through which a Group-to-RP 52 mapping was learned. 54 This document first explains the requirements to extend the 55 Group-to-RP mapping algorithm and then proposes the new algorithm. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Existing algorithm . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Proposed algorithm . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Deprecation of MIB Objects . . . . . . . . . . . . . . . . . . 9 65 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 10 66 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 11 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 68 10. Normative References . . . . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 70 Intellectual Property and Copyright Statements . . . . . . . . . . 14 72 1. Introduction 74 Multiple mechanisms exist today to create and distribute Group-to-RP 75 mappings. Each PIM-SM router may learn Group-to-RP mappings through 76 various mechanisms. 78 It is critical that each router select the same 'RP' for a specific 79 multicast group address. This is even true in the case of Anycast RP 80 for redundancy. Routers should select the same RP address to use for 81 a given group address. This RP address may correspond to a different 82 physical router but it is one logical RP address and must be 83 consistent across the PIM domain. This is usually achieved by using 84 the same algorithm to select the RP in all the PIM routers in a 85 domain. 87 PIM-SM[1] has defined an algorithm to select a 'RP' for a given 88 multicast group address but it is not flexible enough for an 89 administrator to apply various policies. Please refer to section 3 90 for more details. 92 PIM-STD-MIB [2] has defined an algorithm that allows administrators 93 to override Group-to-RP mappings with static configuration. But this 94 algorithm is not completely deterministic, because it includes an 95 implementation-specific 'precedence' value. 97 2. Terminology 99 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 100 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 101 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 102 indicate requirement levels for compliant PIM-PING implementations. 103 This document also uses following terms: 105 o PIM Mode 107 PIM Mode is the mode of operation a particular multicast group is 108 used for. Wherever this term in used in this document, it refers to 109 either Sparse Mode or BIDIR Mode. 111 3. Existing algorithm 113 Existing algorithm defined in PIM-SM (Section 4.7.1 in [1]) does not 114 consider following constraints: 116 o It does not consider the origin of a Group-to-RP mapping and 117 therefore will treat all of them equally. 119 o It does not provide the flexibility that a specific statically 120 created Group-to-RP mapping can override any dynamically learned 121 mappings. 123 o It does not provide the flexibility to give higher priority to a 124 specific PIM mode. For example, an entry learned for PIM-BIDIR 125 mode is treated with same priority as an entry learned for PIM-SM. 127 4. Assumptions 129 We have made following assumptions in defining this algorithm: 131 o A router MAY use hash function on Group-to-RP mappings learned 132 through BSR mechanism [3]. This means that only a subset of 133 Group-to-RP mappings will be available which are learned through 134 BSR mechanism. 136 o A static Group-to-RP mapping entry can be configured with 137 override-dynamic flag. If this flag is set, the static 138 Group-to-RP mapping entry will be preferred instead of dynamically 139 learned entries. 141 o A Group-to-RP mapping can be learned from various mechanisms. We 142 assume that following list is in the decreasing preferences of 143 these mechanism: 145 * Bootstrap Router Mechanism [PIM-BSR] 147 * Auto-RP [Cisco] 149 * Embedded Group-to-RP mappings 151 * Static configuration. 153 * Other mapping method 155 o A Group-to-RP mapping learned for PIM-BIDIR mode is preferred to 156 an entry learned for PIM-SM mode. 158 5. Proposed algorithm 160 We propose following algorithm here which addresses the above 161 mentioned short comings in the existing mechanism: 163 1. From the set of all Group-to-RP mapping entries, the subset whose 164 group prefix contains the multicast group that is being looked 165 up, are selected. 167 2. If there are no entries available, then the Group-to-RP mapping 168 is undefined. 170 3. If there are multiple entries available, a subset of those Group- 171 to-RP mapping is selected that are learned using 'static' 172 configuration and are configured with 'override-dynamic' flag. 174 * If there is only one entry available then that is selected as 175 Group-to-RP mapping. 177 * If there are multiple entries available, we continue with the 178 algorithm with this smaller set of Group-to-RP Mappings 180 4. A longest prefix match is performed on the subset of Group-to-RP 181 Mappings. 183 * If there is only one entry available then that is selected as 184 Group-to-RP mapping. 186 * If there are multiple entries available, we continue with the 187 algorithm with this smaller set of Group-to-RP Mappings 189 5. From the remaining set of Group-to-RP Mappings we select the 190 subset of entries based on the preference for the PIM modes which 191 they are assigned. A Group-to-RP mapping entry with PIM Mode 192 'BIDIR' will be preferred to an entry with PIM Mode 'PIM-SM' 194 * If there is only one entry available then that is selected as 195 Group-to-RP mapping. 197 * If there are multiple entries available, we continue with the 198 algorithm with this smaller set of Group-to-RP Mappings 200 6. From the remaining set of Group-to-RP Mappings we select the 201 subset of the entries based on the origin. Origin preference 202 will be 'bsr', 'auto-rp', 'embedded', 'static' and 'other'. 204 * If there is only one entry available then that is selected as 205 Group-to-RP mapping. 207 * If there are multiple entries available, we continue with the 208 algorithm with this smaller set of Group-to-RP Mappings 210 7. From the remaining set of Group-to-RP Mappings we run PIM hash 211 function as suggested by PIM-SM [1]. 213 * If there is only one entry available then that is selected as 214 Group-to-RP mapping. 216 * If there are multiple entries available, we continue with the 217 algorithm with this smaller set of Group-to-RP Mappings 219 8. From the remaining set of Group-to-RP Mappings we will select the 220 RP with the highest IP address. This will serve as a final 221 tiebreaker. 223 6. Deprecation of MIB Objects 225 Group-to-RP mapping algorithm defined in PIM-STD-MIB [2] does not 226 specify the usage of 'pimGroupMappingPrecedence' and 227 'pimStaticRPPrecedence' objects in 'pimGroupMappingTable' table 228 clearly. With the newly proposed algorithm in this document, these 229 MIB objects would not be required. So we propose to deprecate these 230 MIB objects from PIM-STD-MIB. 232 7. Security Consideration 234 This document does not suggest any protocol specific functionality so 235 there is no security related consideration. 237 8. IANA Consideration 239 This draft does not create any namespace for IANA to manage. 241 9. Acknowledgments 243 This draft is created based on the discussion occurred during the 244 PIM-STD-MIB [2] work. Many thanks to Stig Vennas for providing 245 useful comments during that discussion. 247 10. Normative References 249 [1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 250 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 251 Specification (Revised)", RFC 4601, August 2006. 253 [2] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. 254 Kessler, "Protocol Independent Multicast MIB", RFC 5060, 255 January 2008. 257 [3] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap 258 Router (BSR) Mechanism for Protocol Independent Multicast 259 (PIM)", RFC 5059, January 2008. 261 Authors' Addresses 263 Bharat Joshi 264 Infosys Technologies Ltd. 265 44 Electronics City, Hosur Road 266 Bangalore 560 100 267 India 269 Email: bharat_joshi@infosys.com 270 URI: http://www.infosys.com/ 272 Andy Kessler 273 Cisco Systems, Inc. 274 425 E. Tasman Drive 275 San Jose, CA 95134 276 USA 278 Email: kessler@cisco.com 279 URI: http://www.cisco.com/ 281 David McWalter 282 Data Connection Ltd 283 100 Church Street 284 Enfield EN2 6BQ 285 UK 287 Email: dmcw@dataconnection.com 289 Intellectual Property Statement 291 The IETF takes no position regarding the validity or scope of any 292 Intellectual Property Rights or other rights that might be claimed to 293 pertain to the implementation or use of the technology described in 294 this document or the extent to which any license under such rights 295 might or might not be available; nor does it represent that it has 296 made any independent effort to identify any such rights. Information 297 on the procedures with respect to rights in RFC documents can be 298 found in BCP 78 and BCP 79. 300 Copies of IPR disclosures made to the IETF Secretariat and any 301 assurances of licenses to be made available, or the result of an 302 attempt made to obtain a general license or permission for the use of 303 such proprietary rights by implementers or users of this 304 specification can be obtained from the IETF on-line IPR repository at 305 http://www.ietf.org/ipr. 307 The IETF invites any interested party to bring to its attention any 308 copyrights, patents or patent applications, or other proprietary 309 rights that may cover technology that may be required to implement 310 this standard. Please address the information to the IETF at 311 ietf-ipr@ietf.org. 313 Disclaimer of Validity 315 This document and the information contained herein are provided on an 316 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 317 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 318 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 319 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 320 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 321 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 323 Copyright Statement 325 Copyright (C) The IETF Trust (2008). This document is subject to the 326 rights, licenses and restrictions contained in BCP 78, and except as 327 set forth therein, the authors retain all their rights. 329 Acknowledgment 331 Funding for the RFC Editor function is currently provided by the 332 Internet Society.