idnits 2.17.1 draft-ietf-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 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 419. 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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** 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 301: '... this document MUST be preferred ove...' 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 (October 21, 2008) is 5660 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) == Missing Reference: 'PIM-BSR' is mentioned on line 159, but not defined == Missing Reference: 'Cisco' is mentioned on line 161, but not defined ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 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: April 24, 2009 A. Kessler 5 Cisco Systems, Inc. 6 D. McWalter 7 Data Connection Ltd 8 October 21, 2008 10 PIM Group-to-RP Mapping 11 draft-ietf-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 April 24, 2009. 38 Abstract 40 Each PIM-SM router in a PIM Domain which supports ASM maintains 41 Group-to-RP mappings which are used to identify a RP for a specific 42 multicast group. PIM-SM has defined an algorithm to choose a RP from 43 the Group-to-RP mappings learned using various mechanisms. This 44 algorithm does not allow administrator to override a specific Group- 45 to-RP mapping with the static Group-to-RP mapping which an 46 administrator would want to use. This algorithm also does not 47 consider the PIM mode and the mechanism through which a Group-to-RP 48 mapping was learned. 50 The intention of this document is to suggest a standard algorithm to 51 deterministically choose between several group-to-rp mappings for a 52 specific group. This document first explains the requirements to 53 extend the Group-to-RP mapping algorithm and then proposes the new 54 algorithm. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Existing algorithm . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Common use cases . . . . . . . . . . . . . . . . . . . . . . . 8 63 6. Proposed algorithm . . . . . . . . . . . . . . . . . . . . . . 10 64 7. Deprecation of MIB Objects . . . . . . . . . . . . . . . . . . 12 65 8. Clarification for MIB Objects . . . . . . . . . . . . . . . . 13 66 9. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 67 10. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 15 68 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 69 12. Normative References . . . . . . . . . . . . . . . . . . . . . 17 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 71 Intellectual Property and Copyright Statements . . . . . . . . . . 19 73 1. Introduction 75 Multiple mechanisms exist today to create and distribute Group-to-RP 76 mappings. Each PIM-SM router may learn Group-to-RP mappings through 77 various mechanisms. 79 It is critical that each router select the same 'RP' for a specific 80 multicast group address. This is even true in the case of Anycast RP 81 for redundancy. Routers should select the same RP address to use for 82 a given group address. This RP address may correspond to a different 83 physical router but it is one logical RP address and must be 84 consistent across the PIM domain. This is usually achieved by using 85 the same algorithm to select the RP in all the PIM routers in a 86 domain. 88 PIM-SM[RFC4601] has defined an algorithm to select a 'RP' for a given 89 multicast group address but it is not flexible enough for an 90 administrator to apply various policies. Please refer to section 3 91 for more details. 93 PIM-STD-MIB [RFC5060] has defined an algorithm that allows 94 administrators to override Group-to-RP mappings with static 95 configuration. But this algorithm is not completely deterministic, 96 because it includes an implementation-specific 'precedence' value. 98 Embedded-RP as defined in section-7.1 of Embedded-RP address in IPv6 99 Multicast address [RFC3956], mentions that to avoid loops and 100 inconsistencies, for addresses in the range FF70::/12, the 101 Embedded-RP mapping must be considered the longest possible match and 102 higher priority than any other mechanism. 104 2. Terminology 106 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 107 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 108 and "OPTIONAL" are to be interpreted as described in RFC 2119. This 109 document also uses following terms: 111 o PIM Mode 113 PIM Mode is the mode of operation a particular multicast group is 114 used for. Wherever this term in used in this document, it refers to 115 either Sparse Mode or BIDIR Mode. 117 3. Existing algorithm 119 Existing algorithm defined in PIM-SM (Section 4.7.1 in [RFC4601]) 120 does not consider following constraints: 122 o It does not consider the origin of a Group-to-RP mapping and 123 therefore will treat all of them equally. 125 o It does not provide the flexibility that a specific statically 126 created Group-to-RP mapping can override any dynamically learned 127 mappings. 129 o It does not provide the flexibility to give higher priority to a 130 specific PIM mode. For example, an entry learned for PIM-BIDIR 131 mode is treated with same priority as an entry learned for PIM-SM. 133 4. Assumptions 135 We have made following assumptions in defining this algorithm: 137 o PIM-SM [RFC4601] and BSR [RFC5059] suggested use of a hash 138 function as the last step to select a RP from multiple Group-to-RP 139 mappings. There seems to be no requirement for this function, so 140 this draft assumes that the step to apply hash function can be 141 removed. 143 o A static Group-to-RP mapping entry can be configured with 144 override-dynamic flag. If this flag is set, the static 145 Group-to-RP mapping entry will be preferred instead of dynamically 146 learned entries. 148 o Group-to-RP mappings created with the embedded RP extracted from 149 Multicast Group addresses are special and always has the highest 150 priority. These mappings can not be overridden by a static Group- 151 to-RP mapping with override-dynamic flag set. 153 o A Group-to-RP mapping can be learned from various mechanisms. We 154 assume that following list is in the decreasing preferences of 155 these mechanism: 157 * Embedded Group-to-RP mappings 159 * Bootstrap Router Mechanism [PIM-BSR] 161 * Auto-RP [Cisco] 163 * Static configuration. 165 * Other mapping method 167 o A Group-to-RP mapping learned for PIM-BIDIR mode is preferred to 168 an entry learned for PIM-SM mode. 170 5. Common use cases 172 o Default static Group-to-RP mappings with dynamically learned 173 entries 175 Many network operators will have a dedicated infrastructure for the 176 standard multicast group range (224/4) and so might be using 177 statically configured Group-to-RP mappings for this range. In this 178 case, to support some specific applications, they might like to learn 179 Group-to-RP mappings dynamically using either BSR or Auto-RP 180 mechanism. In this case to select Group-to-RP mappings for these 181 specific applications, a longer prefix match should be given 182 preference over statically configured Group-to-RP mappings. For 183 example 239.100.0.0/16 could be learned for a corporate 184 communications application. Network operators may change the Group- 185 to-RP mappings for these applications more often and would need to be 186 learned dynamically. 188 o Static Group-to-RP mappings with override-dynamic flag 190 Many Network operators would like to statically configure one or 191 multiple Group-to-RP mappings and would always want to ignore any 192 dynamically learned mappings through either BSR, AutoRP or embedded 193 RP for these group prefixes. This is accomplished by providing a 194 'override-dynamic' flag for Group-to-RP mapping configuration. When 195 this flag is enabled for a static Group-to-RP mapping, it will have 196 the highest precedence and would always be use for the specified 197 group prefix. For example: 224.1.0.0/16 is configured with override- 198 dynamic flag enabled and uses RP address RP1. If the router learns 199 the more specific group prefix 224.1.1.0/24 which uses RP2 through 200 BSR, it will choose the RP1 for any group falling under 224.1.0.0/16 201 range. 203 o Migration situations 205 Network operators occasionally go through a migration due to an 206 acquisition or a change in their network design. In order to 207 facilitate this migration there is a needs to have a deterministic 208 behavior of Group-to-RP mapping selection for entries learned using 209 BSR and AutoRP mechanism. This will help in avoiding any unforeseen 210 interoperability issues between different vendor's network elements. 212 o Use by management systems 214 A network management system [or a stand alone box] can find out RP 215 for a specific group in a specific router by running this algorithm 216 on the Group-to-RP mapping table fetched using SNMP MIB objects. 218 o More use cases 220 By no means, the above list is complete. Please drop a mail to 221 'authors' if you see any other use case for this. 223 6. Proposed algorithm 225 We propose following algorithm here which addresses the above 226 mentioned shortcomings in the existing mechanism: 228 1. If the Multicast Group Address being looked up contains an 229 embedded RP, RP address extracted from the Group address is 230 selected as Group-to-RP mapping. 232 2. If the Multicast Group Address being looked up is in the SSM 233 range or is configured for Dense mode, no Group-to-RP mapping is 234 selected, and this algorithm terminates. Alternatively, a RP 235 with address type 'unknown' can be selected. Please look at 236 section #8 for more details on this. 238 3. From the set of all Group-to-RP mapping entries, the subset whose 239 group prefix contains the multicast group that is being looked 240 up, are selected. 242 4. If there are no entries available, then the Group-to-RP mapping 243 is undefined. 245 5. If there are multiple entries available, a subset of those Group- 246 to-RP mapping is selected that are learned using 'static' 247 configuration and are configured with 'override-dynamic' flag. 249 * If there is only one entry available then that is selected as 250 Group-to-RP mapping. 252 * If there are multiple entries available, we continue with the 253 algorithm with this smaller set of Group-to-RP Mappings 255 * If there are no static entries with 'override-dynamic' flag 256 set then we continue with the original subset of Group-to-RP 257 Mappings from step 2. 259 6. A longest prefix match is performed on the subset of Group-to-RP 260 Mappings. 262 * If there is only one entry available then that is selected as 263 Group-to-RP mapping. 265 * If there are multiple entries available, we continue with the 266 algorithm with this smaller set of Group-to-RP Mappings 268 7. From the remaining set of Group-to-RP Mappings we select the 269 subset of entries based on the preference for the PIM modes which 270 they are assigned. A Group-to-RP mapping entry with PIM Mode 271 'BIDIR' will be preferred to an entry with PIM Mode 'PIM-SM' 273 * If there is only one entry available then that is selected as 274 Group-to-RP mapping. 276 * If there are multiple entries available, we continue with the 277 algorithm with this smaller set of Group-to-RP Mappings 279 8. From the remaining set of Group-to-RP Mappings we select the 280 subset of the entries based on the origin. Origin preference 281 will be 'bsr', 'auto-rp', 'static' and 'other'. 283 * If there is only one entry available then that is selected as 284 Group-to-RP mapping. 286 * If there are multiple entries available, we continue with the 287 algorithm with this smaller set of Group-to-RP Mappings 289 9. From the remaining set of Group-to-RP Mappings we will select the 290 RP with the highest IP address. This will serve as a final 291 tiebreaker. 293 7. Deprecation of MIB Objects 295 Group-to-RP mapping algorithm defined in PIM-STD-MIB [RFC5060] does 296 not specify the usage of 'pimGroupMappingPrecedence' and 297 'pimStaticRPPrecedence' objects in 'pimGroupMappingTable' table 298 clearly. With the newly proposed algorithm in this document, these 299 MIB objects would not be required. So we propose to deprecate these 300 MIB objects from PIM-STD-MIB. Also the newly proposed algorithm in 301 this document MUST be preferred over Group-to-RP mapping algorithm 302 defined in either PIM-SM[RFC4601] or in PIM-STD-MIB[RFC5060]. 304 8. Clarification for MIB Objects 306 When an Group-to-RP mapping entry is created in the 307 pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be 308 acceptable to have an entry with an RP with address type 'unknown' 309 and a PimMode of Dense Mode or SSM. These entries would represent 310 group ranges for Dense mode or SSM. 312 Also all the entries which are already included in the SSM Range 313 table in the IP Mcast MIB would be copied over to 314 pimGroupMappingTable. They would have a type of configSSM and an RP 315 with address type 'unknown' as described above. 317 The advantage of keeping all the ranges in the table would be that 318 this table will contain all the known multicast group ranges. 320 9. Security Consideration 322 This document does not suggest any protocol specific functionality so 323 there is no security related consideration. 325 10. IANA Consideration 327 This draft does not create any namespace for IANA to manage. 329 11. Acknowledgments 331 This draft is created based on the discussion occurred during the 332 PIM-STD-MIB [RFC5060] work. Many thanks to Stig Vennas and Toerless 333 Eckert for providing useful comments during that discussion. 335 12. Normative References 337 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 338 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 339 Protocol Specification (Revised)", RFC 4601, August 2006. 341 [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. 342 Kessler, "Protocol Independent Multicast MIB", RFC 5060, 343 January 2008. 345 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 346 Point (RP) Address in an IPv6 Multicast Address", 347 RFC 3956, November 2004. 349 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 350 "Bootstrap Router (BSR) Mechanism for Protocol Independent 351 Multicast (PIM)", RFC 5059, January 2008. 353 Authors' Addresses 355 Bharat Joshi 356 Infosys Technologies Ltd. 357 44 Electronics City, Hosur Road 358 Bangalore 560 100 359 India 361 Email: bharat_joshi@infosys.com 362 URI: http://www.infosys.com/ 364 Andy Kessler 365 Cisco Systems, Inc. 366 425 E. Tasman Drive 367 San Jose, CA 95134 368 USA 370 Email: kessler@cisco.com 371 URI: http://www.cisco.com/ 373 David McWalter 374 Data Connection Ltd 375 100 Church Street 376 Enfield EN2 6BQ 377 UK 379 Email: dmcw@dataconnection.com 381 Full Copyright Statement 383 Copyright (C) The IETF Trust (2008). 385 This document is subject to the rights, licenses and restrictions 386 contained in BCP 78, and except as set forth therein, the authors 387 retain all their rights. 389 This document and the information contained herein are provided on an 390 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 391 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 392 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 393 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 394 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 395 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 397 Intellectual Property 399 The IETF takes no position regarding the validity or scope of any 400 Intellectual Property Rights or other rights that might be claimed to 401 pertain to the implementation or use of the technology described in 402 this document or the extent to which any license under such rights 403 might or might not be available; nor does it represent that it has 404 made any independent effort to identify any such rights. Information 405 on the procedures with respect to rights in RFC documents can be 406 found in BCP 78 and BCP 79. 408 Copies of IPR disclosures made to the IETF Secretariat and any 409 assurances of licenses to be made available, or the result of an 410 attempt made to obtain a general license or permission for the use of 411 such proprietary rights by implementers or users of this 412 specification can be obtained from the IETF on-line IPR repository at 413 http://www.ietf.org/ipr. 415 The IETF invites any interested party to bring to its attention any 416 copyrights, patents or patent applications, or other proprietary 417 rights that may cover technology that may be required to implement 418 this standard. Please address the information to the IETF at 419 ietf-ipr@ietf.org.