idnits 2.17.1 draft-ietf-pim-group-rp-mapping-05.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 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 21, 2010) is 5026 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 (~~), 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 Intended status: Standards Track A. Kessler 5 Expires: January 22, 2011 Cisco Systems, Inc. 6 D. McWalter 7 July 21, 2010 9 PIM Group-to-RP Mapping 10 draft-ietf-pim-group-rp-mapping-05.txt 12 Abstract 14 Each PIM-SM router in a PIM Domain which supports ASM maintains 15 Group-to-RP mappings which are used to identify a RP for a specific 16 multicast group. PIM-SM has defined an algorithm to choose a RP from 17 the Group-to-RP mappings learned using various mechanisms. This 18 algorithm does not consider the PIM mode and the mechanism through 19 which a Group-to-RP mapping was learned. 21 This document defines a standard algorithm to deterministically 22 choose between several group-to-rp mappings for a specific group. 23 This document first explains the requirements to extend the 24 Group-to-RP mapping algorithm and then proposes the new algorithm. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 22, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Existing algorithm . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Common use cases . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Proposed algorithm . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Deprecation of MIB Objects . . . . . . . . . . . . . . . . . . 10 67 8. Clarification for MIB Objects . . . . . . . . . . . . . . . . 11 68 9. Use of dynamic group-to-rp mapping protocols . . . . . . . . . 12 69 10. Consideration for Bidirectional-PIM and BSR hash . . . . . . . 13 70 11. Filtering Group-to-RP mappings at domain boundaries . . . . . 14 71 12. Security Consideration . . . . . . . . . . . . . . . . . . . . 15 72 13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 73 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 74 15. Normative References . . . . . . . . . . . . . . . . . . . . . 18 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 77 1. Introduction 79 Multiple mechanisms exist today to create and distribute Group-to-RP 80 mappings. Each PIM-SM router may learn Group-to-RP mappings through 81 various mechanisms. 83 It is critical that each router select the same 'RP' for a specific 84 multicast group address. This is even true in the case of Anycast RP 85 for redundancy. This RP address may correspond to a different 86 physical router but it is one logical RP address and must be 87 consistent across the PIM domain. This is usually achieved by using 88 the same algorithm to select the RP in all the PIM routers in a 89 domain. 91 PIM-SM [RFC4601] has defined an algorithm to select a 'RP' for a 92 given multicast group address but it is not flexible enough for an 93 administrator to apply various policies. Please refer to section 3 94 for more details. 96 PIM-STD-MIB [RFC5060] has defined an algorithm that allows 97 administrators to override Group-to-RP mappings with static 98 configuration. But this algorithm is not completely deterministic, 99 because it includes an implementation-specific 'precedence' value. 101 Embedded-RP as defined in section-7.1 of Embedded-RP address in IPv6 102 Multicast address [RFC3956], mentions that to avoid loops and 103 inconsistencies, for addresses in the range FF70::/12, the 104 Embedded-RP mapping must be considered the longest possible match and 105 higher priority than any other mechanism. 107 2. Terminology 109 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 110 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 111 and "OPTIONAL" are to be interpreted as described in RFC 2119 112 [RFC2119]. This document also uses following terms: 114 o PIM Mode 116 PIM Mode is the mode of operation a particular multicast group is 117 used for. Wherever this term in used in this document, it refers to 118 either Sparse Mode or BIDIR Mode. 120 o Dynamic group-to-RP mapping mechanisms 122 The term Dynamic group-to-RP mapping mechanisms in this document 123 refers to BSR and Auto-RP. 125 o Dynamic mappings or Dynamically learned mappings 127 The terms Dynamic mappings or Dynamically learned mappings refer to 128 group-to-RP mappings that have been learned by BSR or Auto-RP. 129 Group-to-RP mappings that have been learned by embedded RP are 130 referred to as Embedded Group-to-RP mappings. 132 o Filtering 134 Filtering is selective discarding of dynamic Group-to-RP mapping 135 information, based on the group address, the type of Group-to-RP 136 mapping message and the interface on which the mapping message was 137 received. 139 o Multicast Domain and Boundaries 141 The term multicast domain used in this document refers to a network 142 topology that has a consistent set of Group-to-RP Mappings. The 143 interface between two or more multicast domains is a multicast domain 144 boundary. The multicast boundaries are usually enforced by filtering 145 the dynamic mapping messages and/or configuring different static RP 146 mappings. 148 3. Existing algorithm 150 Existing algorithm defined in PIM-SM (Section 4.7.1 in [RFC4601]) 151 does not consider following constraints: 153 o It does not consider the origin of a Group-to-RP mapping and 154 therefore will treat all of them equally. 156 o It does not provide the flexibility to give higher priority to a 157 specific PIM mode. For example, an entry learned for PIM-BIDIR 158 mode is treated with same priority as an entry learned for PIM-SM. 160 4. Assumptions 162 We have made following assumptions in defining this algorithm: 164 o Embedded Group-to-RP mappings are special and always have the 165 highest priority. They cannot be overridden either by static 166 configuration or by dynamic Group-to-RP mappings. 168 o Dynamic mappings will override a static RP config if they have 169 overlapping ranges. However, it is possible to override dynamic 170 Group-to-RP mappings with static configurations, either by 171 filtering, or by configuring longer static group addresses that 172 override dynamic mappings when longest prefix matching is applied. 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 A Group-to-RP mapping learned for PIM-BIDIR mode is preferred to 187 an entry learned for PIM-SM mode. 189 o Dynamic group-to-RP mapping mechanisms are filtered at domain 190 boundaries or for policy enforcement inside a domain. 192 5. Common use cases 194 o Default static Group-to-RP mappings with dynamically learned 195 entries 197 Many network operators will have a dedicated infrastructure for the 198 standard multicast group range (224/4) and so might be using 199 statically configured Group-to-RP mappings for this range. In this 200 case, to support some specific applications, they might like to learn 201 Group-to-RP mappings dynamically using either BSR or Auto-RP 202 mechanism. In this case to select Group-to-RP mappings for these 203 specific applications, a longer prefix match should be given 204 preference over statically configured Group-to-RP mappings. For 205 example 239.100.0.0/16, an administratively scoped multicast address 206 range, could be learned for a corporate communications application. 207 Network operators may change the Group-to-RP mappings for these 208 applications more often and would need to be learned dynamically. 210 o Migration situations 212 Network operators occasionally go through a migration due to an 213 acquisition or a change in their network design. In order to 214 facilitate this migration there is a need to have a deterministic 215 behaviour of Group-to-RP mapping selection for entries learned using 216 BSR and Auto-RP mechanism. This will help in avoiding any unforeseen 217 interoperability issues between different vendor's network elements. 219 o Use by management systems 221 A network management station can determine the RP for a specific 222 group in a specific router by running this algorithm on the 223 Group-to-RP mapping table fetched using SNMP MIB objects. 225 o More use cases 227 By no means, the above list is complete. Please drop a mail to 228 'authors' if you see any other use case for this. 230 6. Proposed algorithm 232 The following algorithm addresses the above mentioned shortcomings in 233 the existing mechanism: 235 1. If the Multicast Group Address being looked up contains an 236 embedded RP, RP address extracted from the Group address is 237 selected as Group-to-RP mapping. 239 2. If the Multicast Group Address being looked up is in the SSM 240 range or is configured for Dense mode, no Group-to-RP mapping is 241 selected, and this algorithm terminates. Alternatively, a RP 242 with address type 'unknown' can be selected. Please look at 243 section #8 for more details on this. 245 3. From the set of all Group-to-RP mapping entries, the subset 246 whose group prefix contains the multicast group that is being 247 looked up, are selected. 249 4. If there are no entries available, then the Group-to-RP mapping 250 is undefined. 252 5. A longest prefix match is performed on the subset of Group-to-RP 253 Mappings. 255 * If there is only one entry available then that is selected as 256 Group-to-RP mapping. 258 * If there are multiple entries available, we continue with the 259 algorithm with this smaller set of Group-to-RP Mappings. 261 6. From the remaining set of Group-to-RP Mappings we select the 262 subset of entries based on the preference for the PIM modes 263 which they are assigned. A Group-to-RP mapping entry with PIM 264 Mode 'BIDIR' will be preferred to an entry with PIM Mode 265 'PIM-SM' 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 7. From the remaining set of Group-to-RP Mappings we select the 274 subset of the entries based on the origin. Group-to-RP mappings 275 learned dynamically are preferred over static mappings. If the 276 remaining dynamic Group-to-RP mappings are from BSR and Auto-RP 277 then the mappings from BSR SHOULD be preferred. 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 8. If the remaining Group-to-RP mappings were learned through BSR 286 then the RP will be selected by comparing the RP Priority in the 287 Candidate-RP-Advertisement messages. The RP mapping with the 288 lowest value indicates the highest priority [RFC5059]. 290 * If more than one RP has the same highest priority value we 291 continue with the algorithm with those Group-to-RP mappings. 293 * If the remaining Group-to-RP mappings were NOT learned from 294 BSR we continue the algorithm with the next step. 296 9. If the remaining Group-to-RP mappings were learned through BSR 297 and the PIM Mode of the Group is 'PIM-SM' then the hash function 298 will be used to choose the RP. The RP with the highest 299 resulting hash value will be selected. 301 * If more than one RP has the same highest hash value we 302 continue with the algorithm with those Group-to-RP mappings. 304 * If the remaining Group-to-RP mappings were NOT learned from 305 BSR we continue the algorithm with the next step. 307 10. From the remaining set of Group-to-RP Mappings we will select 308 the RP with the highest IP address. This will serve as a final 309 tiebreaker. 311 7. Deprecation of MIB Objects 313 Group-to-RP mapping algorithm defined in PIM-STD-MIB [RFC5060] does 314 not specify the usage of 'pimGroupMappingPrecedence' and 315 'pimStaticRPPrecedence' objects in 'pimGroupMappingTable' table 316 clearly. With the newly proposed algorithm in this document, these 317 MIB objects would not be required. So we propose to deprecate these 318 MIB objects from PIM-STD-MIB. Also the newly proposed algorithm in 319 this document MUST be preferred over Group-to-RP mapping algorithm 320 defined in either PIM-SM[RFC4601] or in PIM-STD-MIB[RFC5060]. 322 8. Clarification for MIB Objects 324 When an Group-to-RP mapping entry is created in the 325 pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be 326 acceptable to have an entry with an RP with address type 'unknown' 327 and a PimMode of Dense Mode or SSM. These entries would represent 328 group ranges for Dense mode or SSM. 330 Also all the entries which are already included in the SSM Range 331 table in the IP Mcast MIB would be copied over to 332 pimGroupMappingTable. They would have a type of configSSM and an RP 333 with address type 'unknown' as described above. 335 The advantage of keeping all the ranges in the table would be that 336 this table will contain all the known multicast group ranges. 338 9. Use of dynamic group-to-rp mapping protocols 340 In practice, it is not usually necessary to run several dynamic 341 Group-to-RP mapping mechanisms in one administrative domain. 342 Specifically, interoperation of BSR and Auto-RP is OPTIONAL and not 343 recommended by this document. 345 However, if a router does receive two overlapping sets of Group-to-RP 346 mappings, for example from Auto-RP and BSR, then some algorithm is 347 needed to deterministically resolve the situation. The algorithm in 348 this document MUST be used. This can be important at domain border 349 routers, and is likely to improve stability under misconfiguration 350 and when configuration is changing. 352 An implementation of PIM that supports only one mechanism for 353 learning Group-to-RP mappings SHOULD also use this algorithm. The 354 algorithm has been chosen so that existing standard implementations 355 are already compliant. 357 10. Consideration for Bidirectional-PIM and BSR hash 359 Bidir-PIM [RFC5015] is designed to avoid any data driven events. 360 This is especially true in the case of a source only branch. The RP 361 mapping is determined based on a group mask when the mapping is 362 received through a dynamic mapping protocol or statically configured. 364 Therefore the hash in BSR is ignored for PIM-Bidir RP mappings based 365 on the algorithm defined in this document. It is RECOMMENDED that 366 network operators configure only one PIM-Bidir RP for each RP 367 Priority. 369 11. Filtering Group-to-RP mappings at domain boundaries 371 An implementation of PIM SHOULD support configuration to block 372 specific dynamic mechanism for a valid group prefix range. For 373 example, it should be possible to allow an administratively scoped 374 address range, such as 239/8 range, for Auto-RP protocol but block 375 the BSR advertisement for the same range. Similarly it should be 376 possible to filter out all Group-to-RP mappings learned from BSR or 377 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 400 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 401 Protocol Specification (Revised)", RFC 4601, August 2006. 403 [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. 404 Kessler, "Protocol Independent Multicast MIB", RFC 5060, 405 January 2008. 407 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 408 Point (RP) Address in an IPv6 Multicast Address", 409 RFC 3956, November 2004. 411 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 412 "Bidirectional Protocol Independent Multicast (BIDIR- 413 PIM)", RFC 5015, October 2007. 415 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 416 "Bootstrap Router (BSR) Mechanism for Protocol Independent 417 Multicast (PIM)", RFC 5059, January 2008. 419 Authors' Addresses 421 Bharat Joshi 422 Infosys Technologies Ltd. 423 44 Electronics City, Hosur Road 424 Bangalore 560 100 425 India 427 Email: bharat_joshi@infosys.com 428 URI: http://www.infosys.com/ 430 Andy Kessler 431 Cisco Systems, Inc. 432 425 E. Tasman Drive 433 San Jose, CA 95134 434 USA 436 Email: kessler@cisco.com 437 URI: http://www.cisco.com/ 439 David McWalter 441 Email: david@mcwalter.eu