idnits 2.17.1 draft-ietf-mboned-logical-rp-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 174 has weird spacing: '... Let k = m...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'MSDP' is defined on line 225, but no explicit reference was found in the text == Unused Reference: 'RFC2362' is defined on line 237, but no explicit reference was found in the text == Unused Reference: 'RFC2403' is defined on line 246, but no explicit reference was found in the text -- No information found for draft-ietf-farinacci-anycast-clusters - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CLUSTERS' -- Possible downref: Normative reference to a draft: ref. 'MSDP' == Outdated reference: A later version (-01) exists of draft-ietf-pim-v2-auth-00 -- Possible downref: Normative reference to a draft: ref. 'PIMAUTH' ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Downref: Normative reference to an Historic RFC: RFC 1828 ** Obsolete normative reference: RFC 2362 (Obsoleted by RFC 4601, RFC 5059) ** Downref: Normative reference to an Informational RFC: RFC 2382 ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED Working Group Dorian Kim 3 Internet Draft Verio 4 Henry Kilmer 5 Intermedia/DIGEX 6 Dino Farinacci 7 Cisco Systems 8 David Meyer 9 Cisco Systems 11 Category Informational 12 draft-ietf-mboned-logical-rp-00.txt March, 1999 14 Using MSDP to create Logical RPs 16 1. Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC 2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 2. Abstract 39 This document describes a mechanism to allow for an arbitrary number 40 of RPs per group in a single share-tree PIM-SM domain. 42 This memo is a product of the MBONE Deployment Working Group (MBONED) 43 in the Operations and Management Area of the Internet Engineering 44 Task Force. Submit comments to or the 45 authors. 47 3. Copyright Notice 49 Copyright (C) The Internet Society (1999). All Rights Reserved. 51 4. Introduction 53 PIM-SM as currently defined allows for only a single active RP per 54 group, and as such the decision of optimal RP placement can become 55 problematic for a multi-regional network deploying PIM-SM. 57 The single active RP, or flat RP space design of PIM-SM has several 58 implications, including traffic concentration, lack of scalable load 59 balancing and redundancy between RPs, sub-optimal forwarding of 60 multicast packets, and distant RP dependencies. These properties of 61 PIM-SM have been demonstrated in recent native continental or inter- 62 continental scale multicast deployments. As a result, it became clear 63 that ISP backbones require a mechanism that allows definition of 64 multiple active RPs per group in single PIM-SM domain. Further, any 65 such mechanism should also addresses the issues addressed above. 67 The mechanism described here is intended to address the need for 68 redundancy and load sharing among RPs in a domain. It is primarily 69 intended for application within those networks which are using MBGP, 70 MSDP and PIM-SM protocols for native multicast deployment, although 71 it not limited to those protocols. In particular, the logical RP 72 solution is applicable in any PIM-SM network that also supports MSDP 73 (MSDP is required so that the various RPs in the domain maintain a 74 consistent view of the sources that are active). Note however, a 75 domain deploying this logical RP solution is not required to run 76 MBGP. 78 5. Problem Definition 80 The logical RP solution described here provides a solution for both 81 redundancy and load balancing among any number of active RPs in a 82 domain. 84 5.1. Traffic Concentration and Load Balancing Between RPs 86 While PIM-SM allows for multiple RPs to be defined for a given group, 87 only one group to RP mapping can active at a given time. A 88 traditional deployment mechanism for load balancing between multiple 89 RPs covering the multicast group space is to split up the 224.0.0.0/4 90 space between multiple defined RPs. This is an acceptable solution as 91 long as multicast traffic remains low, but has problems as multicast 92 traffic increases, especially because the network operator defining 93 group space split between RPs does not alway have a priori knowledge 94 of traffic distribution between groups. This can be overcome via 95 periodic reconfigurations, but operational considerations cause this 96 type of solution to scale poorly. The other alternative to periodic 97 reconfiguration is to split 224.0.0.0/4 space more finely between 98 more RPs, but this solution can have the disadvantage of creating 99 more complex RP configurations, along with the attendant operational 100 problems when RPs are configured [CLUSTERS]. 102 5.2. Sub-optimal Forwarding of Multicast Packets 104 When a single RP serves a given multicast group, all joins to that 105 group will be sent to that RP regardless of the topological distance 106 between the RP and the sources and receivers. Initial data will be 107 sent towards the RP also until configured shortest path tree switch 108 threshold is is reached, or the data will always be sent towards the 109 RP if the network is configured to always use RP rooted shared tree. 110 This holds true even if all the sources and the receivers are in any 111 given single region, and RP is topologically distant from the sources 112 and the receivers. This is an artifact of the dynamic nature of 113 multicast group members, and of the fact that operators may not 114 always have a priori knowledge of the topological placement of the 115 group members. 117 Taken together, these effects can mean that (for example) although 118 all the sources and receivers of a given group are in Europe, they 119 are joining towards the RP in USA and the data will be traversing 120 relatively expensive pipe(s) twice, once to get to RP, and back down 121 the RP rooted tree again, creating inefficient use of expensive 122 resources. 124 5.3. Distant RP Dependencies 126 As outlined above, single active RP per group may cause local sources 127 and receivers to become dependent on a topologically distant RP. In 128 case of a scenario where there are backup RPs configured, distant RP 129 dependence can be created due to the failure of the primary RP, which 130 is topologically closer, and may become exacerbated by switching to 131 the backup RP, which may be even more distant topologically, which 132 may lead to inferior performance, if not outright loss of 133 connectivity to an RP serving the group, depending on the network 134 condition at the given moment. 136 6. Solution 138 Given the problem set outlined above, a good solution would allow an 139 operator to define multiple RPs per group, and distribute those RPs 140 in a topologically significant manner to the sources and receivers. 142 6.1. Mechanisms 144 All the RPs serving a given group or set of groups are configured 145 with identical unicast address, using a numbered interface on the RPs 146 (frequently a logical interface such as a loopback is used). RPs then 147 advertise group to RP mappings using this interface address. This 148 will cause group members (senders) to join (register) towards the 149 topologically closest RP. RPs MSDP peer with each other using the 150 unique shared addresses. Note that if the router implementation 151 chooses the shared address for the BGP router ID, then BGP peerings 152 will not be established. As a result, care should be taken to avoid 153 the ambiguity of the BGP router ID with the RP address(for example, 154 if the logical address chosen is the highest IP address configured on 155 the router, and the router implementation that automatically chooses 156 a router ID based upon highest IP address assigned to interfaces). 157 Finally, the solution described here can be implemented without any 158 modification to existing protocols or their implementations. 160 6.2. Further Applications of the Logical RP mechanism 162 The solution described above can also be applied to external MSDP 163 peers that are used to join two PIM-SM domains together. This can 164 provide redundancy to the MSDP peering session, ease operational 165 complexity as well as simplify configuration management. A side 166 effect to be aware of with this design is that which of the 167 configured MSDP sessions comes up will be determined via the unicast 168 topology between two providers, and can be some what unpredictable. 169 If any of the backup peering sessions resets, the active session will 170 also reset. 172 7. Multicast State Scaling 174 Let k = m + r, where 176 r = resistering to an RP 177 m = number internal sources learned through MSDP 178 p = number of internal MSDP peers 180 For p = 1, m = 0 182 0 receivers ==> 1 (*,G) + 0 SAs 183 Greater than 1 receiver ==> k (S,G) + 0 SAs 185 For p > 1, m != 0 187 0 receivers ==> 1 (*,G) + m SAs 188 Greater than 1 receiver ==> k (S,G) + m SAs 190 Importantly, the multicast state growth is O(k), where k is not a 191 function of p, the number of internal (logical) RP peers. 193 8. Security considerations 195 Since the solution described here makes heavy use of logical 196 addressing, care must be taken to avoid spoofing. In particular 197 unicast routing and PIM RPs must be protected. 199 8.1. Unicast Routing 201 Both internal and external unicast routing can be weakly protected 202 with keyed MD5 [RFC1828], as implemented in an internal protocol such 203 as OSPF [RFC2382] or in BGP [RFC2385]. More generally, IPSEC 204 [RFC1825] could be used to provide protocol integrity for the unicast 205 routing system. 207 8.2. Multicast Protocol Integrity 209 The mechanisms described in [PIMAUTH] should be used to provide 210 protocol message integrity protection and group-wise message origin 211 authentication. 213 9. Acknowledgments 215 John Meylor, Dave Thaler and Tom Pusateri provided insightful 216 comments on earlier versions for this idea. 218 10. References 220 [CLUSTERS] D. Farinacci, et. al., "Use of Anycast Clusters for 221 Inter-Domain Multicast Routing", 222 draft-ietf-farinacci-anycast-clusters-01.txt, March, 223 1998. ftp://ftpeng.cisco.com/ipmulticast/internet-drafts 225 [MSDP] D. Farinacci, et. al., "Multicast Source Discovery 226 Protocol (MSDP)", draft-farinacci-msdp-00.txt, 227 June, 1998. 229 [PIMAUTH] L. Wei, et al., "Authenticating PIM version 2 messages", 230 draft-ietf-pim-v2-auth-00.txt, November, 1998. 232 [RFC1825] Atkinson, R., "IP Security Architecture", August 1995. 234 [RFC1828] P. Metzger and W. Simpson, "IP Authentication using Keyed 235 MD5", RFC 1828, August, 1995. 237 [RFC2362] D. Estrin, et. al., "Protocol Independent Multicast- 238 Sparse Mode (PIM-SM): Protocol Specification", RFC 239 2362, June, 1998. 241 [RFC2382] Moy, J., "OSPF Version 2", RFC 2382, April 1998. 243 [RFC2385] Herrernan, A., "Protection of BGP Sessions via the TCP 244 MD5 Signature Option", RFC 2385, August, 1998. 246 [RFC2403] C. Madson and R. Glenn, "The Use of HMAC-MD5-96 within 247 ESP and AH", RFC 2403, November, 1998. 249 11. Author's Address 251 Dorian Kim 252 Verio, Inc. 253 2361 Lancashire Dr. #2A 254 Ann Arbor, MI 48015 255 Email: dorian@blackrose.org 257 Hank Kilmer 258 Intermedia/DIGEX 259 One DIGEX Plaza 260 Beltsville, Maryland 20705 261 Email: hank@digex.net 263 Dino Farinacci 264 Cisco Systems, Inc. 265 170 Tasman Drive 266 San Jose, CA, 95134 267 Email: dino@cisco.com 269 David Meyer 270 Cisco Systems, Inc. 271 170 Tasman Drive 272 San Jose, CA, 95134 273 Email: dmm@cisco.com