idnits 2.17.1 draft-ietf-pim-group-rp-mapping-06.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 6, 2010) is 4888 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 9, 2011 D. McWalter 7 December 6, 2010 9 PIM Group-to-RP Mapping 10 draft-ietf-pim-group-rp-mapping-06.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 9, 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. 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 This 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 Bidirectional (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 Bootstrap Router (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 The 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 The algorithm defined in this document updates algorithm defined in 162 PIM-SM ( Section 4.7.1 in [RFC4601]). The new algorithm is backward 163 compatible and will produce the same result only if the Group-to-RP 164 mappings are learned from a single mapping source. 166 4. Assumptions 168 We have made following assumptions in defining this algorithm: 170 o A Group-to-RP mapping can be learned from various mechanisms. We 171 assume that following list is in the decreasing preferences of 172 these mechanism: 174 * Embedded Group-to-RP mappings 176 * Dynamically learned mappings 178 * Static configuration. 180 * Other mapping method 182 o Embedded Group-to-RP mappings are special and always have the 183 highest priority. They cannot be overridden either by static 184 configuration or by dynamic Group-to-RP mappings. 186 o Dynamic mappings will override a static RP config if they have 187 overlapping ranges. However, it is possible to override dynamic 188 Group-to-RP mappings with static configurations, either by 189 filtering, or by configuring longer static group addresses that 190 override dynamic mappings when longest prefix matching is applied. 192 o A Group-to-RP mapping learned for PIM-BIDIR mode is preferred to 193 an entry learned for PIM-SM mode. 195 o Dynamic group-to-RP mapping mechanisms are filtered at domain 196 boundaries or for policy enforcement inside a domain. 198 5. Common use cases 200 o Default static Group-to-RP mappings with dynamically learned 201 entries 203 Many network operators will have a dedicated infrastructure for the 204 standard multicast group range (224/4) and so might be using 205 statically configured Group-to-RP mappings for this range. In this 206 case, to support some specific applications, they might like to learn 207 Group-to-RP mappings dynamically using either BSR or Auto-RP 208 mechanism. In this case to select Group-to-RP mappings for these 209 specific applications, a longer prefix match should be given 210 preference over statically configured Group-to-RP mappings. For 211 example 239.100.0.0/16, an administratively scoped multicast address 212 range, could be learned for a corporate communications application. 213 Network operators may change the Group-to-RP mappings for these 214 applications more often and would need to be learned dynamically. 216 o Migration situations 218 Network operators occasionally go through a migration due to an 219 acquisition or a change in their network design. In order to 220 facilitate this migration there is a need to have a deterministic 221 behaviour of Group-to-RP mapping selection for entries learned using 222 BSR and Auto-RP mechanism. This will help in avoiding any unforeseen 223 interoperability issues between different vendor's network elements. 225 o Use by management systems 227 A network management station can determine the RP for a specific 228 group in a specific router by running this algorithm on the 229 Group-to-RP mapping table fetched using SNMP MIB objects. 231 o More use cases 233 By no means, the above list is complete. Please drop a mail to 234 'authors' if you see any other use case for this. 236 6. Proposed algorithm 238 The following algorithm addresses the above mentioned shortcomings in 239 the existing mechanism: 241 1. If the Multicast Group Address being looked up contains an 242 embedded RP, RP address extracted from the Group address is 243 selected as Group-to-RP mapping. 245 2. If the Multicast Group Address being looked up is in the Source 246 Specific Multicast (SSM) range or is configured for Dense mode, 247 no Group-to-RP mapping is selected, and this algorithm 248 terminates. The fact that no Group-to-RP mapping has been 249 selected can be represented in the PIM-STD-MIB module by setting 250 the address type of the RP to 'unknown' as described in Section 251 8. 253 3. From the set of all Group-to-RP mapping entries, the subset 254 whose group prefix contains the multicast group that is being 255 looked up, is selected. 257 4. If there are no entries available, then the Group-to-RP mapping 258 is undefined and this algorithm terminates. 260 5. A longest prefix match is performed on the subset of Group-to-RP 261 Mappings. 263 * If there is only one entry available then that is selected as 264 Group-to-RP mapping. 266 * If there are multiple entries available, we continue with the 267 algorithm with this smaller set of Group-to-RP Mappings. 269 6. From the remaining set of Group-to-RP Mappings we select the 270 subset of entries based on the preference for the PIM modes 271 which they are assigned. A Group-to-RP mapping entry with PIM 272 Mode 'BIDIR' will be preferred to an entry with PIM Mode 273 'PIM-SM' 275 * If there is only one entry available then that is selected as 276 Group-to-RP mapping. 278 * If there are multiple entries available, we continue with the 279 algorithm with this smaller set of Group-to-RP Mappings 281 7. From the remaining set of Group-to-RP Mappings we select the 282 subset of the entries based on the origin. Group-to-RP mappings 283 learned dynamically are preferred over static mappings. If the 284 remaining dynamic Group-to-RP mappings are from BSR and Auto-RP 285 then the mappings from BSR is preferred. 287 * If there is only one entry available then that is selected as 288 Group-to-RP mapping. 290 * If there are multiple entries available, we continue with the 291 algorithm with this smaller set of Group-to-RP Mappings. 293 8. If the remaining Group-to-RP mappings were learned through BSR 294 then the RP will be selected by comparing the RP Priority in the 295 Candidate-RP-Advertisement messages. The RP mapping with the 296 lowest value indicates the highest priority [RFC5059]. 298 * If more than one RP has the same highest priority value we 299 continue with the algorithm with those Group-to-RP mappings. 301 * If the remaining Group-to-RP mappings were NOT learned from 302 BSR we continue the algorithm with the next step. 304 9. If the remaining Group-to-RP mappings were learned through BSR 305 and the PIM Mode of the Group is 'PIM-SM' then the hash function 306 will be used to choose the RP. The RP with the highest 307 resulting hash value will be selected. Please look at section 308 10 for consideration of hash for BIDIR-PIM and BSR. 310 * If more than one RP has the same highest hash value we 311 continue with the algorithm with those Group-to-RP mappings. 313 * If the remaining Group-to-RP mappings were NOT learned from 314 BSR we continue the algorithm with the next step. 316 10. From the remaining set of Group-to-RP Mappings we will select 317 the RP with the highest IP address. This will serve as a final 318 tiebreaker. 320 7. Deprecation of MIB Objects 322 Group-to-RP mapping algorithm defined in PIM-STD-MIB [RFC5060] does 323 not specify the usage of 'pimGroupMappingPrecedence' and 324 'pimStaticRPPrecedence' objects in 'pimGroupMappingTable' table 325 clearly. With the newly proposed algorithm in this document, these 326 MIB objects would not be required. So we propose to deprecate these 327 MIB objects from PIM-STD-MIB. Also the algorithm defined in this 328 document MUST be preferred over Group-to-RP mapping algorithm defined 329 in either PIM-SM[RFC4601] or in PIM-STD-MIB[RFC5060]. 331 8. Clarification for MIB Objects 333 When a Group-to-RP mapping entry is created in the 334 pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be 335 acceptable to have an entry with an RP with address type 'unknown' 336 and a PimMode of Dense Mode or SSM. These entries would represent 337 group ranges for Dense mode or SSM. 339 Also all the entries which are already included in the SSM Range 340 table in the IP Mcast MIB would be copied over to 341 pimGroupMappingTable. They would have a type of configSSM and an RP 342 with address type 'unknown' as described above. 344 The advantage of keeping all the ranges in the table would be that 345 this table will contain all the known multicast group ranges. 347 9. Use of dynamic group-to-rp mapping protocols 349 It is not usually necessary to run several dynamic Group-to-RP 350 mapping mechanisms in one administrative domain. Specifically, 351 interoperation of BSR and Auto-RP is OPTIONAL. 353 However, if a router does receive two overlapping sets of Group-to-RP 354 mappings, for example from Auto-RP and BSR, then some algorithm is 355 needed to deterministically resolve the situation. The algorithm in 356 this document MUST be used. This can be important at domain border 357 routers, and is likely to improve stability under misconfiguration 358 and when configuration is changing. 360 An implementation of PIM that supports only one mechanism for 361 learning Group-to-RP mappings MUST also use this algorithm. The 362 algorithm has been chosen so that existing standard implementations 363 are already compliant. 365 10. Consideration for Bidirectional-PIM and BSR hash 367 BIDIR-PIM [RFC5015] is designed to avoid any data driven events. 368 This is especially true in the case of a source only branch. The RP 369 mapping is determined based on a group mask when the mapping is 370 received through a dynamic mapping protocol or statically configured. 372 Therefore the hash in BSR is ignored for PIM-Bidir RP mappings based 373 on the algorithm defined in this document. It is RECOMMENDED that 374 network operators configure only one PIM-Bidir RP for each RP 375 Priority. 377 11. Filtering Group-to-RP mappings at domain boundaries 379 An implementation of PIM SHOULD support configuration to block 380 specific dynamic mechanism for a valid group prefix range. For 381 example, it should be possible to allow an administratively scoped 382 address range, such as 239/8 range, for Auto-RP protocol but block 383 the BSR advertisement for the same range. Similarly it should be 384 possible to filter out all Group-to-RP mappings learned from BSR or 385 Auto-RP protocol. 387 12. Security Consideration 389 This document enhances an existing algorithm to deterministically 390 choose between several group-to-rp mappings for a specific group. 391 The updated algorithm will not completely prevent the possibility of 392 different routers selecting different group-to-rp mappings for the 393 same group. Such situations can be avoided if various mechanisms 394 used to learn group-to-rp mappings are secure and consistent across 395 the network. 397 13. IANA Consideration 399 This draft does not create any namespace for IANA to manage. 401 14. Acknowledgements 403 This draft is created based on the discussion occurred during the 404 PIM-STD-MIB [RFC5060] work. Many thanks to Stig Vennas, Yiqun Cai 405 and Toerless Eckert for providing useful comments. 407 15. Normative References 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 413 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 414 Protocol Specification (Revised)", RFC 4601, August 2006. 416 [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. 417 Kessler, "Protocol Independent Multicast MIB", RFC 5060, 418 January 2008. 420 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 421 Point (RP) Address in an IPv6 Multicast Address", 422 RFC 3956, November 2004. 424 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 425 "Bidirectional Protocol Independent Multicast (BIDIR- 426 PIM)", RFC 5015, October 2007. 428 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 429 "Bootstrap Router (BSR) Mechanism for Protocol Independent 430 Multicast (PIM)", RFC 5059, January 2008. 432 Authors' Addresses 434 Bharat Joshi 435 Infosys Technologies Ltd. 436 44 Electronics City, Hosur Road 437 Bangalore 560 100 438 India 440 Email: bharat_joshi@infosys.com 441 URI: http://www.infosys.com/ 443 Andy Kessler 444 Cisco Systems, Inc. 445 425 E. Tasman Drive 446 San Jose, CA 95134 447 USA 449 Email: kessler@cisco.com 450 URI: http://www.cisco.com/ 452 David McWalter 454 Email: david@mcwalter.eu