idnits 2.17.1 draft-ietf-pim-group-rp-mapping-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 1 instance 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 278: '...mappings from BSR SHOULD be preferred....' RFC 2119 keyword, line 320: '... this document MUST be preferred ove...' RFC 2119 keyword, line 343: '...of BSR and Auto-RP is OPTIONAL and not...' RFC 2119 keyword, line 349: '... this document MUST be used. This c...' RFC 2119 keyword, line 354: '...p-to-RP mappings SHOULD also use this ...' (2 more instances...) 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 (April 26, 2010) is 5111 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) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 3 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: October 28, 2010 A. Kessler 5 Cisco Systems, Inc. 6 D. McWalter 7 Metaswitch Networks 8 April 26, 2010 10 PIM Group-to-RP Mapping 11 draft-ietf-pim-group-rp-mapping-04.txt 13 Abstract 15 Each PIM-SM router in a PIM Domain which supports ASM maintains 16 Group-to-RP mappings which are used to identify a RP for a specific 17 multicast group. PIM-SM has defined an algorithm to choose a RP from 18 the Group-to-RP mappings learned using various mechanisms. This 19 algorithm does not consider the PIM mode and the mechanism through 20 which a Group-to-RP mapping was learned. 22 This document defines a standard algorithm to deterministically 23 choose between several group-to-rp mappings for a specific group. 24 This document first explains the requirements to extend the 25 Group-to-RP mapping algorithm and then proposes the new algorithm. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 28, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Existing algorithm . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Common use cases . . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Proposed algorithm . . . . . . . . . . . . . . . . . . . . . . 8 67 7. Deprecation of MIB Objects . . . . . . . . . . . . . . . . . . 10 68 8. Clarification for MIB Objects . . . . . . . . . . . . . . . . 11 69 9. Use of dynamic group-to-rp mapping protocols . . . . . . . . . 12 70 10. Consideration for Bidirectional-PIM and BSR hash . . . . . . . 13 71 11. Filtering Group-to-RP mappings at domain boundaries . . . . . 14 72 12. Security Consideration . . . . . . . . . . . . . . . . . . . . 15 73 13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 74 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 75 15. Normative References . . . . . . . . . . . . . . . . . . . . . 18 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 Multiple mechanisms exist today to create and distribute Group-to-RP 81 mappings. Each PIM-SM router may learn Group-to-RP mappings through 82 various mechanisms. 84 It is critical that each router select the same 'RP' for a specific 85 multicast group address. This is even true in the case of Anycast RP 86 for redundancy. This RP address may correspond to a different 87 physical router but it is one logical RP address and must be 88 consistent across the PIM domain. This is usually achieved by using 89 the same algorithm to select the RP in all the PIM routers in a 90 domain. 92 PIM-SM [RFC4601] has defined an algorithm to select a 'RP' for a 93 given multicast group address but it is not flexible enough for an 94 administrator to apply various policies. Please refer to section 3 95 for more details. 97 PIM-STD-MIB [RFC5060] has defined an algorithm that allows 98 administrators to override Group-to-RP mappings with static 99 configuration. But this algorithm is not completely deterministic, 100 because it includes an implementation-specific 'precedence' value. 102 Embedded-RP as defined in section-7.1 of Embedded-RP address in IPv6 103 Multicast address [RFC3956], mentions that to avoid loops and 104 inconsistencies, for addresses in the range FF70::/12, the 105 Embedded-RP mapping must be considered the longest possible match and 106 higher priority than any other mechanism. 108 2. Terminology 110 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 111 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 112 and "OPTIONAL" are to be interpreted as described in RFC 2119. This 113 document also uses following terms: 115 o PIM Mode 117 PIM Mode is the mode of operation a particular multicast group is 118 used for. Wherever this term in used in this document, it refers to 119 either Sparse Mode or BIDIR Mode. 121 o Dynamic group-to-RP mapping mechanisms 123 The term Dynamic group-to-RP mapping mechanisms in this document 124 refers to BSR and Auto-RP. 126 o Dynamic mappings or Dynamically learned mappings 128 The terms Dynamic mappings or Dynamically learned mappings refer to 129 group-to-RP mappings that have been learned by BSR or Auto-RP. 130 Group-to-RP mappings that have been learned by embedded RP are 131 referred to as Embedded Group-to-RP mappings. 133 o Filtering 135 Filtering is selective discarding of dynamic Group-to-RP mapping 136 information, based on the group address, the type of Group-to-RP 137 mapping message and the interface on which the mapping message was 138 received. 140 o Multicast Domain and Boundaries 142 The term multicast domain used in this document refers to a network 143 topology that has a consistent set of Group-to-RP Mappings. The 144 interface between two or more multicast domains is a multicast domain 145 boundary. The multicast boundaries are usually enforced by filtering 146 the dynamic mapping messages and/or configuring different static RP 147 mappings. 149 3. Existing algorithm 151 Existing algorithm defined in PIM-SM (Section 4.7.1 in [RFC4601]) 152 does not consider following constraints: 154 o It does not consider the origin of a Group-to-RP mapping and 155 therefore will treat all of them equally. 157 o It does not provide the flexibility to give higher priority to a 158 specific PIM mode. For example, an entry learned for PIM-BIDIR 159 mode is treated with same priority as an entry learned for PIM-SM. 161 4. Assumptions 163 We have made following assumptions in defining this algorithm: 165 o Embedded Group-to-RP mappings are special and always have the 166 highest priority. They cannot be overridden either by static 167 configuration or by dynamic Group-to-RP mappings. 169 o Dynamic mappings will override a static RP config if they have 170 overlapping ranges. However, it is possible to override dynamic 171 Group-to-RP mappings with static configurations, either by 172 filtering, or by configuring longer static group addresses that 173 override dynamic mappings when longest prefix matching is applied. 175 o A Group-to-RP mapping can be learned from various mechanisms. We 176 assume that following list is in the decreasing preferences of 177 these mechanism: 179 * Embedded Group-to-RP mappings 181 * Dynamically learned mappings 183 * Static configuration. 185 * Other mapping method 187 o A Group-to-RP mapping learned for PIM-BIDIR mode is preferred to 188 an entry learned for PIM-SM mode. 190 o Dynamic group-to-RP mapping mechanisms are filtered at domain 191 boundaries or for policy enforcement inside a domain. 193 5. Common use cases 195 o Default static Group-to-RP mappings with dynamically learned 196 entries 198 Many network operators will have a dedicated infrastructure for the 199 standard multicast group range (224/4) and so might be using 200 statically configured Group-to-RP mappings for this range. In this 201 case, to support some specific applications, they might like to learn 202 Group-to-RP mappings dynamically using either BSR or Auto-RP 203 mechanism. In this case to select Group-to-RP mappings for these 204 specific applications, a longer prefix match should be given 205 preference over statically configured Group-to-RP mappings. For 206 example 239.100.0.0/16 could be learned for a corporate 207 communications application. Network operators may change the Group- 208 to-RP mappings for these applications more often and would need to be 209 learned dynamically. 211 o Migration situations 213 Network operators occasionally go through a migration due to an 214 acquisition or a change in their network design. In order to 215 facilitate this migration there is a need to have a deterministic 216 behaviour of Group-to-RP mapping selection for entries learned using 217 BSR and Auto-RP mechanism. This will help in avoiding any unforeseen 218 interoperability issues between different vendor's network elements. 220 o Use by management systems 222 A network management station can determine the RP for a specific 223 group in a specific router by running this algorithm on the 224 Group-to-RP mapping table fetched using SNMP MIB objects. 226 o More use cases 228 By no means, the above list is complete. Please drop a mail to 229 'authors' if you see any other use case for this. 231 6. Proposed algorithm 233 The following algorithm addresses the above mentioned shortcomings in 234 the existing mechanism: 236 1. If the Multicast Group Address being looked up contains an 237 embedded RP, RP address extracted from the Group address is 238 selected as Group-to-RP mapping. 240 2. If the Multicast Group Address being looked up is in the SSM 241 range or is configured for Dense mode, no Group-to-RP mapping is 242 selected, and this algorithm terminates. Alternatively, a RP 243 with address type 'unknown' can be selected. Please look at 244 section #8 for more details on this. 246 3. From the set of all Group-to-RP mapping entries, the subset 247 whose group prefix contains the multicast group that is being 248 looked up, are selected. 250 4. If there are no entries available, then the Group-to-RP mapping 251 is undefined. 253 5. A longest prefix match is performed on the subset of Group-to-RP 254 Mappings. 256 * If there is only one entry available then that is selected as 257 Group-to-RP mapping. 259 * If there are multiple entries available, we continue with the 260 algorithm with this smaller set of Group-to-RP Mappings. 262 6. From the remaining set of Group-to-RP Mappings we select the 263 subset of entries based on the preference for the PIM modes 264 which they are assigned. A Group-to-RP mapping entry with PIM 265 Mode 'BIDIR' will be preferred to an entry with PIM Mode 266 'PIM-SM' 268 * If there is only one entry available then that is selected as 269 Group-to-RP mapping. 271 * If there are multiple entries available, we continue with the 272 algorithm with this smaller set of Group-to-RP Mappings 274 7. From the remaining set of Group-to-RP Mappings we select the 275 subset of the entries based on the origin. Group-to-RP mappings 276 learned dynamically are preferred over static mappings. If the 277 remaining dynamic Group-to-RP mappings are from BSR and Auto-RP 278 then the mappings from BSR SHOULD be preferred. 280 * If there is only one entry available then that is selected as 281 Group-to-RP mapping. 283 * If there are multiple entries available, we continue with the 284 algorithm with this smaller set of Group-to-RP Mappings. 286 8. If the remaining Group-to-RP mappings were learned through BSR 287 then the RP will be selected by comparing the RP Priority in the 288 Candidate-RP-Advertisement messages. The RP mapping with the 289 lowest value indicates the highest priority [RFC5059]. 291 * If more than one RP has the same highest priority value we 292 continue with the algorithm with those Group-to-RP mappings. 294 * If the remaining Group-to-RP mappings were NOT learned from 295 BSR we continue the algorithm with the next step. 297 9. If the remaining Group-to-RP mappings were learned through BSR 298 and the PIM Mode of the Group is 'PIM-SM' then the hash function 299 will be used to choose the RP. The RP with the highest 300 resulting hash value will be selected. 302 * If more than one RP has the same highest hash value we 303 continue with the algorithm with those Group-to-RP mappings. 305 * If the remaining Group-to-RP mappings were NOT learned from 306 BSR we continue the algorithm with the next step. 308 10. From the remaining set of Group-to-RP Mappings we will select 309 the RP with the highest IP address. This will serve as a final 310 tiebreaker. 312 7. Deprecation of MIB Objects 314 Group-to-RP mapping algorithm defined in PIM-STD-MIB [RFC5060] does 315 not specify the usage of 'pimGroupMappingPrecedence' and 316 'pimStaticRPPrecedence' objects in 'pimGroupMappingTable' table 317 clearly. With the newly proposed algorithm in this document, these 318 MIB objects would not be required. So we propose to deprecate these 319 MIB objects from PIM-STD-MIB. Also the newly proposed algorithm in 320 this document MUST be preferred over Group-to-RP mapping algorithm 321 defined in either PIM-SM[RFC4601] or in PIM-STD-MIB[RFC5060]. 323 8. Clarification for MIB Objects 325 When an Group-to-RP mapping entry is created in the 326 pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be 327 acceptable to have an entry with an RP with address type 'unknown' 328 and a PimMode of Dense Mode or SSM. These entries would represent 329 group ranges for Dense mode or SSM. 331 Also all the entries which are already included in the SSM Range 332 table in the IP Mcast MIB would be copied over to 333 pimGroupMappingTable. They would have a type of configSSM and an RP 334 with address type 'unknown' as described above. 336 The advantage of keeping all the ranges in the table would be that 337 this table will contain all the known multicast group ranges. 339 9. Use of dynamic group-to-rp mapping protocols 341 In practice, it is not usually necessary to run several dynamic 342 Group-to-RP mapping mechanisms in one administrative domain. 343 Specifically, interoperation of BSR and Auto-RP is OPTIONAL and not 344 recommended by this document. 346 However, if a router does receive two overlapping sets of Group-to-RP 347 mappings, for example from Auto-RP and BSR, then some algorithm is 348 needed to deterministically resolve the situation. The algorithm in 349 this document MUST be used. This can be important at domain border 350 routers, and is likely to improve stability under misconfiguration 351 and when configuration is changing. 353 An implementation of PIM that supports only one mechanism for 354 learning Group-to-RP mappings SHOULD also use this algorithm. The 355 algorithm has been chosen so that existing standard implementations 356 are already compliant. 358 10. Consideration for Bidirectional-PIM and BSR hash 360 Bidir-PIM [RFC5015] is designed to avoid any data driven events. 361 This is especially true in the case of a source only branch. The RP 362 mapping is determined based on a group mask when the mapping is 363 received through a dynamic mapping protocol or statically configured. 365 Therefore the hash in BSR is ignored for PIM-Bidir RP mappings based 366 on the algorithm defined in this document. It is RECOMMENDED that 367 network operators configure only one PIM-Bidir RP for each RP 368 Priority. 370 11. Filtering Group-to-RP mappings at domain boundaries 372 An implementation of PIM SHOULD support configuration to block 373 specific dynamic mechanism for a valid group prefix range. For 374 example, it should be possible to allow 239/8 range for Auto-RP 375 protocol but block the BSR advertisement for the same range. 376 Similarly it should be possible to filter out all Group-to-RP 377 mappings learned from BSR or Auto-RP protocol. 379 12. Security Consideration 381 This document does not suggest any protocol specific functionality so 382 there is no security related consideration. 384 13. IANA Consideration 386 This draft does not create any namespace for IANA to manage. 388 14. Acknowledgements 390 This draft is created based on the discussion occurred during the 391 PIM-STD-MIB [RFC5060] work. Many thanks to Stig Vennas, Yiqun Cai 392 and Toerless Eckert for providing useful comments. 394 15. Normative References 396 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 397 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 398 Protocol Specification (Revised)", RFC 4601, August 2006. 400 [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. 401 Kessler, "Protocol Independent Multicast MIB", RFC 5060, 402 January 2008. 404 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 405 Point (RP) Address in an IPv6 Multicast Address", 406 RFC 3956, November 2004. 408 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 409 "Bidirectional Protocol Independent Multicast (BIDIR- 410 PIM)", RFC 5015, October 2007. 412 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 413 "Bootstrap Router (BSR) Mechanism for Protocol Independent 414 Multicast (PIM)", RFC 5059, January 2008. 416 Authors' Addresses 418 Bharat Joshi 419 Infosys Technologies Ltd. 420 44 Electronics City, Hosur Road 421 Bangalore 560 100 422 India 424 Email: bharat_joshi@infosys.com 425 URI: http://www.infosys.com/ 427 Andy Kessler 428 Cisco Systems, Inc. 429 425 E. Tasman Drive 430 San Jose, CA 95134 431 USA 433 Email: kessler@cisco.com 434 URI: http://www.cisco.com/ 436 David McWalter 437 Metaswitch Networks 438 100 Church Street 439 Enfield EN2 6BQ 440 UK 442 Email: dmcw@metaswitch.com