idnits 2.17.1 draft-ietf-pim-group-rp-mapping-07.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 issues found here. 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 draft header indicates that this document updates RFC4601, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4601, updated by this document, for RFC5378 checks: 2000-07-17) -- 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 (December 9, 2010) is 4879 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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 Updates: 4601 (if approved) A. Kessler 5 Intended status: Standards Track Cisco Systems, Inc. 6 Expires: June 12, 2011 D. McWalter 7 December 9, 2010 9 PIM Group-to-RP Mapping 10 draft-ietf-pim-group-rp-mapping-07.txt 12 Abstract 14 Each PIM-SM router in a Protocol Independent Multicast (PIM) Domain 15 which supports Any Source Multicast (ASM) maintains Group-to-RP 16 mappings which are used to identify a Rendezvous Point(RP) for a 17 specific multicast group. PIM-SM has defined an algorithm to choose 18 a RP from the Group-to-RP mappings learned using various mechanisms. 19 This algorithm does not consider the PIM mode and the mechanism 20 through 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 June 12, 2011. 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. Interpretation 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] includes a number of objects to allow an 98 administrator to set the precedence for Group-to-RP mappings which 99 are learned statically or dynamically and stored in the 100 'pimGroupMappingTable'. The MIB module also defines an algorithm 101 that can be applied to the data contained in the 102 'pimGroupMappingTable' to determine Group-to-RP mappings. However, 103 this algorithm is not completely deterministic, because it includes 104 an implementation-specific 'precedence' value. 106 Embedded-RP as defined in section-7.1 of Embedded-RP address in IPv6 107 Multicast address [RFC3956], mentions that to avoid loops and 108 inconsistencies, for addresses in the range FF70::/12, the 109 Embedded-RP mapping must be considered the longest possible match and 110 higher priority than any other mechanism. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 This document also uses following terms: 119 o PIM Mode 121 PIM Mode is the mode of operation a particular multicast group is 122 used for. Wherever this term in used in this document, it refers to 123 either Sparse Mode or Bidirectional (BIDIR) Mode. 125 o Dynamic group-to-RP mapping mechanisms 127 The term Dynamic group-to-RP mapping mechanisms in this document 128 refers to Bootstrap Router (BSR) and Auto-RP. 130 o Dynamic mappings or Dynamically learned mappings 132 The terms Dynamic mappings or Dynamically learned mappings refer to 133 group-to-RP mappings that have been learned by BSR or Auto-RP. 134 Group-to-RP mappings that have been learned by embedded RP are 135 referred to as Embedded Group-to-RP mappings. 137 o Filtering 139 Filtering is selective discarding of dynamic Group-to-RP mapping 140 information, based on the group address, the type of Group-to-RP 141 mapping message and the interface on which the mapping message was 142 received. 144 o Multicast Domain and Boundaries 146 The term multicast domain used in this document refers to a network 147 topology that has a consistent set of Group-to-RP Mappings. The 148 interface between two or more multicast domains is a multicast domain 149 boundary. The multicast boundaries are usually enforced by filtering 150 the dynamic mapping messages and/or configuring different static RP 151 mappings. 153 3. Existing algorithm 155 The existing algorithm defined in PIM-SM (Section 4.7.1 in [RFC4601]) 156 does not consider following constraints: 158 o It does not consider the origin of a Group-to-RP mapping and 159 therefore will treat all of them equally. 161 o It does not provide the flexibility to give higher priority to a 162 specific PIM mode. For example, an entry learned for PIM-BIDIR 163 mode is treated with same priority as an entry learned for PIM-SM. 165 The algorithm defined in this document updates algorithm defined in 166 PIM-SM ( Section 4.7.1 in [RFC4601]). The new algorithm is backward 167 compatible and will produce the same result only if the Group-to-RP 168 mappings are learned from a single mapping source. 170 4. Assumptions 172 We have made following assumptions in defining this algorithm: 174 o A Group-to-RP mapping can be learned from various mechanisms. We 175 assume that following list is in the decreasing preferences of 176 these mechanism: 178 * Embedded Group-to-RP mappings 180 * Dynamically learned mappings 182 * Static configuration. 184 * Other mapping method 186 o Embedded Group-to-RP mappings are special and always have the 187 highest priority. They cannot be overridden either by static 188 configuration or by dynamic Group-to-RP mappings. 190 o Dynamic mappings will override a static RP config if they have 191 overlapping ranges. However, it is possible to override dynamic 192 Group-to-RP mappings with static configurations, either by 193 filtering, or by configuring longer static group addresses that 194 override dynamic mappings when longest prefix matching is applied. 196 o A Group-to-RP mapping learned for PIM-BIDIR mode is preferred to 197 an entry learned for PIM-SM mode. 199 o Dynamic group-to-RP mapping mechanisms are filtered at domain 200 boundaries or for policy enforcement inside a domain. 202 5. Common use cases 204 o Default static Group-to-RP mappings with dynamically learned 205 entries 207 Many network operators will have a dedicated infrastructure for the 208 standard multicast group range (224/4) and so might be using 209 statically configured Group-to-RP mappings for this range. In this 210 case, to support some specific applications, they might like to learn 211 Group-to-RP mappings dynamically using either BSR or Auto-RP 212 mechanism. In this case to select Group-to-RP mappings for these 213 specific applications, a longer prefix match should be given 214 preference over statically configured Group-to-RP mappings. For 215 example 239.100.0.0/16, an administratively scoped multicast address 216 range, could be learned for a corporate communications application. 217 Network operators may change the Group-to-RP mappings for these 218 applications more often and would need to be learned dynamically. 220 o Migration situations 222 Network operators occasionally go through a migration due to an 223 acquisition or a change in their network design. In order to 224 facilitate this migration there is a need to have a deterministic 225 behaviour of Group-to-RP mapping selection for entries learned using 226 BSR and Auto-RP mechanism. This will help in avoiding any unforeseen 227 interoperability issues between different vendor's network elements. 229 o Use by management systems 231 A network management station can determine the RP for a specific 232 group in a specific router by running this algorithm on the 233 Group-to-RP mapping table fetched using SNMP MIB objects. 235 o More use cases 237 By no means, the above list is complete. Please drop a mail to 238 'authors' if you see any other use case for this. 240 6. Proposed algorithm 242 The following algorithm addresses the above mentioned shortcomings in 243 the existing mechanism: 245 1. If the Multicast Group Address being looked up contains an 246 embedded RP, RP address extracted from the Group address is 247 selected as Group-to-RP mapping. 249 2. If the Multicast Group Address being looked up is in the Source 250 Specific Multicast (SSM) range or is configured for Dense mode, 251 no Group-to-RP mapping is selected, and this algorithm 252 terminates. The fact that no Group-to-RP mapping has been 253 selected can be represented in the PIM-STD-MIB module by setting 254 the address type of the RP to 'unknown' as described in Section 255 8. 257 3. From the set of all Group-to-RP mapping entries, the subset 258 whose group prefix contains the multicast group that is being 259 looked up, is selected. 261 4. If there are no entries available, then the Group-to-RP mapping 262 is undefined and this algorithm terminates. 264 5. A longest prefix match is performed on the subset of Group-to-RP 265 Mappings. 267 * If there is only one entry available then that is selected as 268 Group-to-RP mapping. 270 * If there are multiple entries available, we continue with the 271 algorithm with this smaller set of Group-to-RP Mappings. 273 6. From the remaining set of Group-to-RP Mappings we select the 274 subset of entries based on the preference for the PIM modes 275 which they are assigned. A Group-to-RP mapping entry with PIM 276 Mode 'BIDIR' will be preferred to an entry with PIM Mode 277 'PIM-SM' 279 * If there is only one entry available then that is selected as 280 Group-to-RP mapping. 282 * If there are multiple entries available, we continue with the 283 algorithm with this smaller set of Group-to-RP Mappings 285 7. From the remaining set of Group-to-RP Mappings we select the 286 subset of the entries based on the origin. Group-to-RP mappings 287 learned dynamically are preferred over static mappings. If the 288 remaining dynamic Group-to-RP mappings are from BSR and Auto-RP 289 then the mappings from BSR is preferred. 291 * If there is only one entry available then that is selected as 292 Group-to-RP mapping. 294 * If there are multiple entries available, we continue with the 295 algorithm with this smaller set of Group-to-RP Mappings. 297 8. If the remaining Group-to-RP mappings were learned through BSR 298 then the RP will be selected by comparing the RP Priority in the 299 Candidate-RP-Advertisement messages. The RP mapping with the 300 lowest value indicates the highest priority [RFC5059]. 302 * If more than one RP has the same highest priority 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 9. If the remaining Group-to-RP mappings were learned through BSR 309 and the PIM Mode of the Group is 'PIM-SM' then the hash function 310 will be used to choose the RP. The RP with the highest 311 resulting hash value will be selected. Please look at section 312 10 for consideration of hash for BIDIR-PIM and BSR. 314 * If more than one RP has the same highest hash value we 315 continue with the algorithm with those Group-to-RP mappings. 317 * If the remaining Group-to-RP mappings were NOT learned from 318 BSR we continue the algorithm with the next step. 320 10. From the remaining set of Group-to-RP Mappings we will select 321 the RP with the highest IP address. This will serve as a final 322 tiebreaker. 324 7. Interpretation of MIB Objects 326 The algorithm defined in this document does not use the concept of 327 precedence and therefore the values configured in the 328 'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence' objects of 329 the 'pimGroupMappingTable' table in the PIM-STD-MIB module [RFC5060] 330 are not applicable to the new algorithm. The objects still retain 331 their meaning for 'legacy' implementations, but since the algorithm 332 defined in this document is to be used in preference to that found in 333 PIM-SM [RFC4601] and PIM-STD-MIB [RFC5060], the usage of these fields 334 will decline as implementations are upgraded to support the new 335 algorithm. 337 8. Clarification for MIB Objects 339 When a Group-to-RP mapping entry is created in the 340 pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be 341 acceptable to have an entry with an RP with address type 'unknown' 342 and a PimMode of Dense Mode or SSM. These entries would represent 343 group ranges for Dense mode or SSM. 345 Also all the entries which are already included in the SSM Range 346 table in the IP Mcast MIB would be copied over to 347 pimGroupMappingTable. They would have a type of configSSM and an RP 348 with address type 'unknown' as described above. 350 The advantage of keeping all the ranges in the table would be that 351 this table will contain all the known multicast group ranges. 353 9. Use of dynamic group-to-rp mapping protocols 355 It is not usually necessary to run several dynamic Group-to-RP 356 mapping mechanisms in one administrative domain. Specifically, 357 interoperation of BSR and Auto-RP is OPTIONAL. 359 However, if a router does receive two overlapping sets of Group-to-RP 360 mappings, for example from Auto-RP and BSR, then some algorithm is 361 needed to deterministically resolve the situation. The algorithm in 362 this document MUST be used. This can be important at domain border 363 routers, and is likely to improve stability under misconfiguration 364 and when configuration is changing. 366 An implementation of PIM that supports only one mechanism for 367 learning Group-to-RP mappings MUST also use this algorithm. The 368 algorithm has been chosen so that existing standard implementations 369 are already compliant. 371 10. Consideration for Bidirectional-PIM and BSR hash 373 BIDIR-PIM [RFC5015] is designed to avoid any data driven events. 374 This is especially true in the case of a source only branch. The RP 375 mapping is determined based on a group mask when the mapping is 376 received through a dynamic mapping protocol or statically configured. 378 Therefore the hash in BSR is ignored for PIM-Bidir RP mappings based 379 on the algorithm defined in this document. It is RECOMMENDED that 380 network operators configure only one PIM-Bidir RP for each RP 381 Priority. 383 11. Filtering Group-to-RP mappings at domain boundaries 385 An implementation of PIM SHOULD support configuration to block 386 specific dynamic mechanism for a valid group prefix range. For 387 example, it should be possible to allow an administratively scoped 388 address range, such as 239/8 range, for Auto-RP protocol but block 389 the BSR advertisement for the same range. Similarly it should be 390 possible to filter out all Group-to-RP mappings learned from BSR or 391 Auto-RP protocol. 393 12. Security Consideration 395 This document enhances an existing algorithm to deterministically 396 choose between several group-to-rp mappings for a specific group. 397 The updated algorithm will not completely prevent the possibility of 398 different routers selecting different group-to-rp mappings for the 399 same group. Such situations can be avoided if various mechanisms 400 used to learn group-to-rp mappings are secure and consistent across 401 the network. 403 13. IANA Consideration 405 This draft does not create any namespace for IANA to manage. 407 14. Acknowledgements 409 This draft is created based on the discussion occurred during the 410 PIM-STD-MIB [RFC5060] work. Many thanks to Stig Vennas, Yiqun Cai 411 and Toerless Eckert for providing useful comments. 413 15. Normative References 415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, March 1997. 418 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 419 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 420 Protocol Specification (Revised)", RFC 4601, August 2006. 422 [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. 423 Kessler, "Protocol Independent Multicast MIB", RFC 5060, 424 January 2008. 426 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 427 Point (RP) Address in an IPv6 Multicast Address", 428 RFC 3956, November 2004. 430 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 431 "Bidirectional Protocol Independent Multicast (BIDIR- 432 PIM)", RFC 5015, October 2007. 434 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 435 "Bootstrap Router (BSR) Mechanism for Protocol Independent 436 Multicast (PIM)", RFC 5059, January 2008. 438 Authors' Addresses 440 Bharat Joshi 441 Infosys Technologies Ltd. 442 44 Electronics City, Hosur Road 443 Bangalore 560 100 444 India 446 Email: bharat_joshi@infosys.com 447 URI: http://www.infosys.com/ 449 Andy Kessler 450 Cisco Systems, Inc. 451 425 E. Tasman Drive 452 San Jose, CA 95134 453 USA 455 Email: kessler@cisco.com 456 URI: http://www.cisco.com/ 458 David McWalter 460 Email: david@mcwalter.eu