idnits 2.17.1 draft-ietf-mboned-anycast-rp-02.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 7 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 8 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 -- 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: 'RFC2362' is defined on line 270, but no explicit reference was found in the text == Unused Reference: 'RFC2403' is defined on line 279, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-msdp-spec-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-msdp-spec (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: 13 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBONED Working Group Dorian Kim 2 Internet Draft Verio 3 David Meyer 4 Cisco Systems 5 Henry Kilmer 6 Dino Farinacci 7 Procket Networks 9 Category Informational 10 November, 1999 12 Anycast RP mechanism using PIM and MSDP 13 15 1. Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 2. Abstract 38 This document describes a mechanism to allow for an arbitrary number 39 of RPs per group in a single shared-tree PIM-SM domain. 41 This memo is a product of the MBONE Deployment Working Group (MBONED) 42 in the Operations and Management Area of the Internet Engineering 43 Task Force. Submit comments to or the 44 authors. 46 3. Copyright Notice 48 Copyright (C) The Internet Society (1999). All Rights Reserved. 50 4. Introduction 52 PIM-SM as defined in RFC 2352 allows for only a single active RP per 53 group, and as such the decision of optimal RP placement can become 54 problematic for a multi-regional network deploying PIM-SM. 56 Anycast RP relaxes an important constraint in PIM-SM, namely, that 57 there can be only one group to RP mapping active at any time. The 58 single mapping property has several implications, including traffic 59 concentration, lack of scalable register decapsulation (when using 60 the shared tree), slow convergence when an active RP fails, possible 61 sub-optimal forwarding of multicast packets, and distant RP 62 dependencies. These properties of PIM-SM have been demonstrated in 63 native continental or inter-continental scale multicast deployments. 64 As a result, it is clear that ISP backbones require a mechanism that 65 allows definition of multiple active RPs per group in single PIM-SM 66 domain. Further, any such mechanism should also address the issues 67 addressed above. 69 The mechanism described here is intended to address the need for 70 better fail-over (convergence time) and sharing of the register 71 decapsulation load (again, when using the shared-tree) among RPs in a 72 domain. It is primarily intended for applications within those 73 networks which are using MBGP, Multicast Source Discovery Protocol 74 [MSDP] and PIM-SM protocols for native multicast deployment, although 75 it not limited to those protocols. In particular, Anycast RP is 76 applicable in any PIM-SM network that also supports MSDP (MSDP is 77 required so that the various RPs in the domain maintain a consistent 78 view of the sources that are active). Note however, a domain 79 deploying Anycast RP is not required to run MBGP. 81 5. Problem Definition 83 The anycast RP solution provides a solution for both fast fail-over 84 and shared-tree load balancing among any number of active RPs in a 85 domain. 87 5.1. Traffic Concentration and Distributing Decapsulation Load Among RPs 89 While PIM-SM allows for multiple RPs to be defined for a given group, 90 only one group to RP mapping can active at a given time. A 91 traditional deployment mechanism for balancing register decapsulation 92 load between multiple RPs covering the multicast group space is to 93 split up the 224.0.0.0/4 space between multiple defined RPs. This is 94 an acceptable solution as long as multicast traffic remains low, but 95 has problems as multicast traffic increases, especially because the 96 network operator defining group space split between RPs does not 97 alway have a priori knowledge of traffic distribution between groups. 98 This can be overcome via periodic reconfigurations, but operational 99 considerations cause this type of solution to scale poorly. 101 5.2. Sub-optimal Forwarding of Multicast Packets 103 When a single RP serves a given multicast group, all joins to that 104 group will be sent to that RP regardless of the topological distance 105 between the RP and the sources and receivers. Initial data will be 106 sent towards the RP also until configured shortest path tree switch 107 threshold is reached, or the data will always be sent towards the RP 108 if the network is configured to always use RP rooted shared tree. 109 This holds true even if all the sources and the receivers are in any 110 given single region, and RP is topologically distant from the sources 111 and the receivers. This is an artifact of the dynamic nature of 112 multicast group members, and of the fact that operators may not 113 always have a priori knowledge of the topological placement of the 114 group members. 116 Taken together, these effects can mean that (for example) although 117 all the sources and receivers of a given group are in Europe, they 118 are joining towards the RP in USA and the data will be traversing 119 relatively expensive pipe(s) twice, once to get to RP, and back down 120 the RP rooted tree again, creating inefficient use of expensive 121 resources. 123 5.3. Distant RP Dependencies 125 As outlined above, a single active RP per group may cause local 126 sources and receivers to become dependent on a topologically distant 127 RP. In case of a scenario where there are backup RPs configured, 128 distant RP dependence can be created due to the failure of the 129 primary RP, which is topologically closer, and may become exacerbated 130 by switching to the backup RP, which may be even more distant 131 topologically, which may lead to inferior performance, if not 132 outright loss of connectivity to an RP serving the group, depending 133 on the network condition at the given moment. 135 6. Solution 137 Given the problem set outlined above, a good solution would allow an 138 operator to configure multiple RPs per group, and distribute those 139 RPs in a topologically significant manner to the sources and 140 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 an 150 address unique to each RP. Note that if the router implementation 151 chooses the anycast address as the router ID, then peerings and/or 152 adjacencies may not be established. 154 Operationally, the following steps are required: 156 6.1.1. Create the set of group-to-anycast-RP-address mappings 158 The first step is to create the set of group-to-anycast-RP-address 159 mappings to be used in the domain. Each RP participating in a anycast 160 RP set must be configured with a consistent set of group to RP 161 address mappings. This mapping will be used by the non-RP routers in 162 the domain. 164 6.1.2. Configure each RP for the group range with the anycast RP address 166 The next step is to configure each RP for the group range with the 167 anycast RP address. If a dynamic mechanism such as auto-RP or the 168 PIMv2 bootstrap mechanism is being used to advertise group to RP 169 mappings, the anycast IP address should be used for the RP address. 171 6.1.3. Configure MSDP peerings between each of the anycast RPs in the 172 set 174 Unlike the group to RP mapping advertisements, MSDP peerings must use 175 an IP address that is unique to the endpoints. A general guideline is 176 to follow the addressing of the BGP peerings, e.g., loopbacks for 177 iBGP peering, physical interface addresses for eBGP peering. 179 6.1.4. Configure the non-RP's with the group-to-anycast-RP-address 180 mappings 182 Finally, each non-RP router must learn the set of group to RP 183 mappings. This could be done via static configuration, auto-RP, or by 184 PIMv2 bootstrap mechanism. 186 6.1.5. Ensure that the anycast IP address is reachable by all routers in 187 the domain 189 This is typically accomplished by injecting the /32 into the domain's 190 IGP. 192 6.2. Interaction with MSDP Peer-RPF check 194 Each MSDP peer receives and forwards the message away from the RP 195 address in a "peer-RPF flooding" fashion. The notion of peer-RPF 196 flooding is with respect to forwarding SA messages [MSDP]. The BGP 197 routing tables are examined to determine which peer is the next hop 198 towards the originating RP of the SA message. Such a peer is called 199 an "RPF peer". See [MSDP] for details of the Peer-RPF check. 201 6.3. State Implications 203 It should be noted that using MSDP in this way forces the creation of 204 (S,G) state along the path from the receiver to the source. This 205 state may not be present if a single RP was used and receivers were 206 forced to stay on the shared tree. 208 6.4. Further Applications of Anycast RP mechanism 210 The solution described above can also be applied to external MSDP 211 peers that are used to join two PIM-SM domains together. This can 212 provide redundancy to the MSDP peering session, ease operational 213 complexity as well as simplify configuration management. A side 214 effect to be aware of with this design is that which of the 215 configured MSDP sessions comes up will be determined via the unicast 216 topology between two providers, and can be somewhat unpredictable. If 217 any of the backup peering sessions resets, the active session will 218 also reset. 220 7. Security considerations 222 Since the solution described here makes heavy use of anycast 223 addressing, care must be taken to avoid spoofing. In particular 224 unicast routing and PIM RPs must be protected. 226 7.1. Unicast Routing 228 Both internal and external unicast routing can be weakly protected 229 with keyed MD5 [RFC1828], as implemented in an internal protocol such 230 as OSPF [RFC2382] or in BGP [RFC2385]. More generally, IPSEC 231 [RFC1825] could be used to provide protocol integrity for the unicast 232 routing system. 234 7.1.1. Effects of Unicast Routing Instability 236 While not a security issue, it is worth noting that if unicast 237 routing is unstable, then the actual RP that source or receiver is 238 using will be subject to the same instability. 240 7.2. Multicast Protocol Integrity 242 The mechanisms described in [PIMAUTH] should be used to provide 243 protocol message integrity protection and group-wise message origin 244 authentication. 246 7.3. MSDP Peer Integrity 248 As is the the case for BGP, MSDP peers can be protected using keyed 249 MD5 [RFC1828]. 251 8. Acknowledgments 253 John Meylor, Dave Thaler and Tom Pusateri provided insightful 254 comments on earlier versions for this idea. 256 9. References 258 [MSDP] D. Farinacci, et. al., "Multicast Source Discovery 259 Protocol (MSDP)", draft-ietf-msdp-spec-02.txt, 260 November, 1999. 262 [PIMAUTH] L. Wei, et al., "Authenticating PIM version 2 messages", 263 draft-ietf-pim-v2-auth-00.txt, November, 1998. 265 [RFC1825] Atkinson, R., "IP Security Architecture", August 1995. 267 [RFC1828] P. Metzger and W. Simpson, "IP Authentication using Keyed 268 MD5", RFC 1828, August, 1995. 270 [RFC2362] D. Estrin, et. al., "Protocol Independent Multicast- 271 Sparse Mode (PIM-SM): Protocol Specification", RFC 272 2362, June, 1998. 274 [RFC2382] Moy, J., "OSPF Version 2", RFC 2382, April 1998. 276 [RFC2385] Herrernan, A., "Protection of BGP Sessions via the TCP 277 MD5 Signature Option", RFC 2385, August, 1998. 279 [RFC2403] C. Madson and R. Glenn, "The Use of HMAC-MD5-96 within 280 ESP and AH", RFC 2403, November, 1998. 282 10. Author's Address 284 Dorian Kim 285 Verio, Inc. 286 2361 Lancashire Dr. #2A 287 Ann Arbor, MI 48015 288 Email: dorian@blackrose.org 290 Hank Kilmer 291 Email: hank@rem.com 293 Dino Farinacci 294 Procket Networks 295 Email: dino@procket.com 297 David Meyer 298 Cisco Systems, Inc. 299 170 Tasman Drive 300 San Jose, CA, 95134 301 Email: dmm@cisco.com