idnits 2.17.1 draft-ietf-pim-group-rp-mapping-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 310: '... this document MUST be preferred ove...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (June 25, 2009) is 5418 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 168, but not defined == Missing Reference: 'Cisco' is mentioned on line 170, but not defined ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 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: December 27, 2009 A. Kessler 5 Cisco Systems, Inc. 6 D. McWalter 7 Data Connection Ltd 8 June 25, 2009 10 PIM Group-to-RP Mapping 11 draft-ietf-pim-group-rp-mapping-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 27, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 Each PIM-SM router in a PIM Domain which supports ASM maintains 50 Group-to-RP mappings which are used to identify a RP for a specific 51 multicast group. PIM-SM has defined an algorithm to choose a RP from 52 the Group-to-RP mappings learned using various mechanisms. This 53 algorithm does not allow administrator to override a specific Group- 54 to-RP mapping with the static Group-to-RP mapping which an 55 administrator would want to use. This algorithm also does not 56 consider the PIM mode and the mechanism through which a Group-to-RP 57 mapping was learned. 59 The intention of this document is to suggest a standard algorithm to 60 deterministically choose between several group-to-rp mappings for a 61 specific group. This document first explains the requirements to 62 extend the Group-to-RP mapping algorithm and then proposes the new 63 algorithm. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Existing algorithm . . . . . . . . . . . . . . . . . . . . . . 6 70 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Common use cases . . . . . . . . . . . . . . . . . . . . . . . 8 72 6. Proposed algorithm . . . . . . . . . . . . . . . . . . . . . . 10 73 7. Deprecation of MIB Objects . . . . . . . . . . . . . . . . . . 12 74 8. Clarification for MIB Objects . . . . . . . . . . . . . . . . 13 75 9. Migration to the new algorithm . . . . . . . . . . . . . . . . 14 76 10. Security Consideration . . . . . . . . . . . . . . . . . . . . 15 77 11. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 78 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 79 13. Normative References . . . . . . . . . . . . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 82 1. Introduction 84 Multiple mechanisms exist today to create and distribute Group-to-RP 85 mappings. Each PIM-SM router may learn Group-to-RP mappings through 86 various mechanisms. 88 It is critical that each router select the same 'RP' for a specific 89 multicast group address. This is even true in the case of Anycast RP 90 for redundancy. Routers should select the same RP address to use for 91 a given group address. This RP address may correspond to a different 92 physical router but it is one logical RP address and must be 93 consistent across the PIM domain. This is usually achieved by using 94 the same algorithm to select the RP in all the PIM routers in a 95 domain. 97 PIM-SM[RFC4601] has defined an algorithm to select a 'RP' for a given 98 multicast group address but it is not flexible enough for an 99 administrator to apply various policies. Please refer to section 3 100 for more details. 102 PIM-STD-MIB [RFC5060] has defined an algorithm that allows 103 administrators to override Group-to-RP mappings with static 104 configuration. But this algorithm is not completely deterministic, 105 because it includes an implementation-specific 'precedence' value. 107 Embedded-RP as defined in section-7.1 of Embedded-RP address in IPv6 108 Multicast address [RFC3956], mentions that to avoid loops and 109 inconsistencies, for addresses in the range FF70::/12, the 110 Embedded-RP mapping must be considered the longest possible match and 111 higher priority than any other mechanism. 113 2. Terminology 115 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 116 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 117 and "OPTIONAL" are to be interpreted as described in RFC 2119. This 118 document also uses following terms: 120 o PIM Mode 122 PIM Mode is the mode of operation a particular multicast group is 123 used for. Wherever this term in used in this document, it refers to 124 either Sparse Mode or BIDIR Mode. 126 3. Existing algorithm 128 Existing algorithm defined in PIM-SM (Section 4.7.1 in [RFC4601]) 129 does not consider following constraints: 131 o It does not consider the origin of a Group-to-RP mapping and 132 therefore will treat all of them equally. 134 o It does not provide the flexibility that a specific statically 135 created Group-to-RP mapping can override any dynamically learned 136 mappings. 138 o It does not provide the flexibility to give higher priority to a 139 specific PIM mode. For example, an entry learned for PIM-BIDIR 140 mode is treated with same priority as an entry learned for PIM-SM. 142 4. Assumptions 144 We have made following assumptions in defining this algorithm: 146 o PIM-SM [RFC4601] and BSR [RFC5059] suggested use of a hash 147 function as the last step to select a RP from multiple Group-to-RP 148 mappings. There seems to be no requirement for this function, so 149 this draft assumes that the step to apply hash function can be 150 removed. 152 o A static Group-to-RP mapping entry can be configured with 153 override-dynamic flag. If this flag is set, the static 154 Group-to-RP mapping entry will be preferred instead of dynamically 155 learned entries. 157 o Group-to-RP mappings created with the embedded RP extracted from 158 Multicast Group addresses are special and always has the highest 159 priority. These mappings can not be overridden by a static Group- 160 to-RP mapping with override-dynamic flag set. 162 o A Group-to-RP mapping can be learned from various mechanisms. We 163 assume that following list is in the decreasing preferences of 164 these mechanism: 166 * Embedded Group-to-RP mappings 168 * Bootstrap Router Mechanism [PIM-BSR] 170 * Auto-RP [Cisco] 172 * Static configuration. 174 * Other mapping method 176 o A Group-to-RP mapping learned for PIM-BIDIR mode is preferred to 177 an entry learned for PIM-SM mode. 179 5. Common use cases 181 o Default static Group-to-RP mappings with dynamically learned 182 entries 184 Many network operators will have a dedicated infrastructure for the 185 standard multicast group range (224/4) and so might be using 186 statically configured Group-to-RP mappings for this range. In this 187 case, to support some specific applications, they might like to learn 188 Group-to-RP mappings dynamically using either BSR or Auto-RP 189 mechanism. In this case to select Group-to-RP mappings for these 190 specific applications, a longer prefix match should be given 191 preference over statically configured Group-to-RP mappings. For 192 example 239.100.0.0/16 could be learned for a corporate 193 communications application. Network operators may change the Group- 194 to-RP mappings for these applications more often and would need to be 195 learned dynamically. 197 o Static Group-to-RP mappings with override-dynamic flag 199 Many Network operators would like to statically configure one or 200 multiple Group-to-RP mappings and would always want to ignore any 201 dynamically learned mappings through either BSR, AutoRP or embedded 202 RP for these group prefixes. This is accomplished by providing a 203 'override-dynamic' flag for Group-to-RP mapping configuration. When 204 this flag is enabled for a static Group-to-RP mapping, it will have 205 the highest precedence and would always be use for the specified 206 group prefix. For example: 224.1.0.0/16 is configured with override- 207 dynamic flag enabled and uses RP address RP1. If the router learns 208 the more specific group prefix 224.1.1.0/24 which uses RP2 through 209 BSR, it will choose the RP1 for any group falling under 224.1.0.0/16 210 range. 212 o Migration situations 214 Network operators occasionally go through a migration due to an 215 acquisition or a change in their network design. In order to 216 facilitate this migration there is a needs to have a deterministic 217 behavior of Group-to-RP mapping selection for entries learned using 218 BSR and AutoRP mechanism. This will help in avoiding any unforeseen 219 interoperability issues between different vendor's network elements. 221 o Use by management systems 223 A network management system [or a stand alone box] can find out RP 224 for a specific group in a specific router by running this algorithm 225 on the Group-to-RP mapping table fetched using SNMP MIB objects. 227 o More use cases 229 By no means, the above list is complete. Please drop a mail to 230 'authors' if you see any other use case for this. 232 6. Proposed algorithm 234 We propose following algorithm here which addresses the above 235 mentioned shortcomings in the existing mechanism: 237 1. If the Multicast Group Address being looked up contains an 238 embedded RP, RP address extracted from the Group address is 239 selected as Group-to-RP mapping. 241 2. If the Multicast Group Address being looked up is in the SSM 242 range or is configured for Dense mode, no Group-to-RP mapping is 243 selected, and this algorithm terminates. Alternatively, a RP 244 with address type 'unknown' can be selected. Please look at 245 section #8 for more details on this. 247 3. From the set of all Group-to-RP mapping entries, the subset whose 248 group prefix contains the multicast group that is being looked 249 up, are selected. 251 4. If there are no entries available, then the Group-to-RP mapping 252 is undefined. 254 5. If there are multiple entries available, a subset of those Group- 255 to-RP mapping is selected that are learned using 'static' 256 configuration and are configured with 'override-dynamic' flag. 258 * If there is only one entry available then that is selected as 259 Group-to-RP mapping. 261 * If there are multiple entries available, we continue with the 262 algorithm with this smaller set of Group-to-RP Mappings 264 * If there are no static entries with 'override-dynamic' flag 265 set then we continue with the original subset of Group-to-RP 266 Mappings from step 2. 268 6. A longest prefix match is performed on the subset of Group-to-RP 269 Mappings. 271 * If there is only one entry available then that is selected as 272 Group-to-RP mapping. 274 * If there are multiple entries available, we continue with the 275 algorithm with this smaller set of Group-to-RP Mappings 277 7. From the remaining set of Group-to-RP Mappings we select the 278 subset of entries based on the preference for the PIM modes which 279 they are assigned. A Group-to-RP mapping entry with PIM Mode 280 'BIDIR' will be preferred to an entry with PIM Mode 'PIM-SM' 282 * If there is only one entry available then that is selected as 283 Group-to-RP mapping. 285 * If there are multiple entries available, we continue with the 286 algorithm with this smaller set of Group-to-RP Mappings 288 8. From the remaining set of Group-to-RP Mappings we select the 289 subset of the entries based on the origin. Origin preference 290 will be 'bsr', 'auto-rp', 'static' and 'other'. 292 * If there is only one entry available then that is selected as 293 Group-to-RP mapping. 295 * If there are multiple entries available, we continue with the 296 algorithm with this smaller set of Group-to-RP Mappings 298 9. From the remaining set of Group-to-RP Mappings we will select the 299 RP with the highest IP address. This will serve as a final 300 tiebreaker. 302 7. Deprecation of MIB Objects 304 Group-to-RP mapping algorithm defined in PIM-STD-MIB [RFC5060] does 305 not specify the usage of 'pimGroupMappingPrecedence' and 306 'pimStaticRPPrecedence' objects in 'pimGroupMappingTable' table 307 clearly. With the newly proposed algorithm in this document, these 308 MIB objects would not be required. So we propose to deprecate these 309 MIB objects from PIM-STD-MIB. Also the newly proposed algorithm in 310 this document MUST be preferred over Group-to-RP mapping algorithm 311 defined in either PIM-SM[RFC4601] or in PIM-STD-MIB[RFC5060]. 313 8. Clarification for MIB Objects 315 When an Group-to-RP mapping entry is created in the 316 pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be 317 acceptable to have an entry with an RP with address type 'unknown' 318 and a PimMode of Dense Mode or SSM. These entries would represent 319 group ranges for Dense mode or SSM. 321 Also all the entries which are already included in the SSM Range 322 table in the IP Mcast MIB would be copied over to 323 pimGroupMappingTable. They would have a type of configSSM and an RP 324 with address type 'unknown' as described above. 326 The advantage of keeping all the ranges in the table would be that 327 this table will contain all the known multicast group ranges. 329 9. Migration to the new algorithm 331 The Group-to-RP mapping algorithm proposed in this document obsoletes 332 the use of the hash function. With this change, there will be no 333 interoperability between the old and the new algorithm. So networks 334 that use multiple RP addresses for a Group Range and use the hash 335 function for load sharing will need to be migrated to the new 336 algorithm proposed in this document. A seamless migration to the new 337 Group-to-RP algorithm can be accomplished by using one RP address 338 with Anycast RP. 340 10. Security Consideration 342 This document does not suggest any protocol specific functionality so 343 there is no security related consideration. 345 11. IANA Consideration 347 This draft does not create any namespace for IANA to manage. 349 12. Acknowledgments 351 This draft is created based on the discussion occurred during the 352 PIM-STD-MIB [RFC5060] work. Many thanks to Stig Vennas and Toerless 353 Eckert for providing useful comments during that discussion. 355 13. Normative References 357 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 358 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 359 Protocol Specification (Revised)", RFC 4601, August 2006. 361 [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. 362 Kessler, "Protocol Independent Multicast MIB", RFC 5060, 363 January 2008. 365 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 366 Point (RP) Address in an IPv6 Multicast Address", 367 RFC 3956, November 2004. 369 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 370 "Bootstrap Router (BSR) Mechanism for Protocol Independent 371 Multicast (PIM)", RFC 5059, January 2008. 373 Authors' Addresses 375 Bharat Joshi 376 Infosys Technologies Ltd. 377 44 Electronics City, Hosur Road 378 Bangalore 560 100 379 India 381 Email: bharat_joshi@infosys.com 382 URI: http://www.infosys.com/ 384 Andy Kessler 385 Cisco Systems, Inc. 386 425 E. Tasman Drive 387 San Jose, CA 95134 388 USA 390 Email: kessler@cisco.com 391 URI: http://www.cisco.com/ 393 David McWalter 394 Data Connection Ltd 395 100 Church Street 396 Enfield EN2 6BQ 397 UK 399 Email: dmcw@dataconnection.com