idnits 2.17.1 draft-ietf-pim-group-rp-mapping-02.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 322: '... this document MUST be preferred ove...' RFC 2119 keyword, line 345: '... of BSR and AutoRP is OPTIONAL and not...' RFC 2119 keyword, line 351: '... this document MUST be used. This c...' RFC 2119 keyword, line 356: '...p-to-RP mappings SHOULD also use this ...' 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 (September 22, 2009) is 5324 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: March 26, 2010 A. Kessler 5 Cisco Systems, Inc. 6 D. McWalter 7 Data Connection Ltd 8 September 22, 2009 10 PIM Group-to-RP Mapping 11 draft-ietf-pim-group-rp-mapping-02.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 March 26, 2010. 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. Use of dynamic group-to-rp mapping protocols . . . . . . . . . 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 248 whose group prefix contains the multicast group that is being 249 looked 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 255 Group-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 279 which they are assigned. A Group-to-RP mapping entry with PIM 280 Mode 'BIDIR' will be preferred to an entry with PIM Mode 281 'PIM-SM' 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 8. From the remaining set of Group-to-RP Mappings we select the 290 subset of the entries based on the origin. Origin preference 291 will be 'bsr', 'auto-rp', 'static' and 'other'. 293 * If there is only one entry available then that is selected as 294 Group-to-RP mapping. 296 * If there are multiple entries available, we continue with the 297 algorithm with this smaller set of Group-to-RP Mappings 299 9. If the remaining Group-to-RP mappings were learned through BSR 300 and the PIM Mode of the Group is 'PIM-SM' then the hash function 301 will be used to choose the RP. The RP with the highest 302 resulting hash value will be selected. 304 * If more than one RP has the same highest hash value we 305 continue with the algorithm with those Group-to-RP mappings. 307 * If the remaining Group-to-RP mappings were NOT learned from 308 BSR we continue the algorithm with the next step 310 10. From the remaining set of Group-to-RP Mappings we will select 311 the RP with the highest IP address. This will serve as a final 312 tiebreaker. 314 7. Deprecation of MIB Objects 316 Group-to-RP mapping algorithm defined in PIM-STD-MIB [RFC5060] does 317 not specify the usage of 'pimGroupMappingPrecedence' and 318 'pimStaticRPPrecedence' objects in 'pimGroupMappingTable' table 319 clearly. With the newly proposed algorithm in this document, these 320 MIB objects would not be required. So we propose to deprecate these 321 MIB objects from PIM-STD-MIB. Also the newly proposed algorithm in 322 this document MUST be preferred over Group-to-RP mapping algorithm 323 defined in either PIM-SM[RFC4601] or in PIM-STD-MIB[RFC5060]. 325 8. Clarification for MIB Objects 327 When an Group-to-RP mapping entry is created in the 328 pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be 329 acceptable to have an entry with an RP with address type 'unknown' 330 and a PimMode of Dense Mode or SSM. These entries would represent 331 group ranges for Dense mode or SSM. 333 Also all the entries which are already included in the SSM Range 334 table in the IP Mcast MIB would be copied over to 335 pimGroupMappingTable. They would have a type of configSSM and an RP 336 with address type 'unknown' as described above. 338 The advantage of keeping all the ranges in the table would be that 339 this table will contain all the known multicast group ranges. 341 9. Use of dynamic group-to-rp mapping protocols 343 In practice, it is not usually necessary to run several dynamic 344 Group-to-RP mapping mechanisms in one administrative domain. 345 Specifically, interoperation of BSR and AutoRP is OPTIONAL and not 346 recommended by this document. 348 However, if a router does receive two overlapping sets of Group-to-RP 349 mappings, for example from AutoRP and BSR, then some algorithm is 350 needed to deterministically resolve the situation. The algorithm in 351 this document MUST be used. This can be important at domain border 352 routers, and is likely to improve stability under misconfiguration 353 and when configuration is changing. 355 An implementation of PIM that supports only one mechanism for 356 learning Group-to-RP mappings SHOULD also use this algorithm. The 357 algorithm has been chosen so that existing standard implementations 358 are already compliant. 360 10. Security Consideration 362 This document does not suggest any protocol specific functionality so 363 there is no security related consideration. 365 11. IANA Consideration 367 This draft does not create any namespace for IANA to manage. 369 12. Acknowledgments 371 This draft is created based on the discussion occurred during the 372 PIM-STD-MIB [RFC5060] work. Many thanks to Stig Vennas and Toerless 373 Eckert for providing useful comments during that discussion. 375 13. Normative References 377 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 378 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 379 Protocol Specification (Revised)", RFC 4601, August 2006. 381 [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. 382 Kessler, "Protocol Independent Multicast MIB", RFC 5060, 383 January 2008. 385 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 386 Point (RP) Address in an IPv6 Multicast Address", 387 RFC 3956, November 2004. 389 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 390 "Bootstrap Router (BSR) Mechanism for Protocol Independent 391 Multicast (PIM)", RFC 5059, January 2008. 393 Authors' Addresses 395 Bharat Joshi 396 Infosys Technologies Ltd. 397 44 Electronics City, Hosur Road 398 Bangalore 560 100 399 India 401 Email: bharat_joshi@infosys.com 402 URI: http://www.infosys.com/ 404 Andy Kessler 405 Cisco Systems, Inc. 406 425 E. Tasman Drive 407 San Jose, CA 95134 408 USA 410 Email: kessler@cisco.com 411 URI: http://www.cisco.com/ 413 David McWalter 414 Data Connection Ltd 415 100 Church Street 416 Enfield EN2 6BQ 417 UK 419 Email: dmcw@dataconnection.com