idnits 2.17.1 draft-ietf-mboned-anycast-rp-05.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 47 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 174: '... anycast address MUST NOT be used as t...' RFC 2119 keyword, line 198: '... anycast address MUST NOT be used as t...' 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: 'RFC2403' is defined on line 264, 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') ** 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: 15 errors (**), 0 flaws (~~), 6 warnings (==), 2 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 January, 2000 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 RFC Internet-Drafts. 20 2026 are working documents of the Internet Engineering Task Force 21 (IETF), its areas, and its working groups. Note that other groups 22 may also distribute working documents as Internet- Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 2. Abstract 37 This document describes a mechanism to allow for an arbitrary number 38 of RPs per group in a single shared-tree PIM-SM domain. 40 This memo is a product of the MBONE Deployment Working Group (MBONED) 41 in the Operations and Management Area of the Internet Engineering 42 Task Force. Submit comments to or the 43 authors. 45 3. Copyright Notice 47 Copyright (C) The Internet Society (2000). All Rights Reserved. 49 4. Introduction 51 PIM-SM as defined in RFC 2352 allows for only a single active RP per 52 group, and as such the decision of optimal RP placement can become 53 problematic for a multi-regional network deploying PIM-SM. 55 Anycast RP relaxes an important constraint in PIM-SM, namely, that 56 there can be only one group to RP mapping active at any time. The 57 single mapping property has several implications, including traffic 58 concentration, lack of scalable register decapsulation (when using 59 the shared tree), slow convergence when an active RP fails, possible 60 sub-optimal forwarding of multicast packets, and distant RP 61 dependencies. These properties of PIM-SM have been demonstrated in 62 native continental or inter-continental scale multicast deployments. 63 As a result, it is clear that ISP backbones require a mechanism that 64 allows definition of multiple active RPs per group in single PIM-SM 65 domain. Further, any such mechanism should also address the issues 66 addressed above. 68 The mechanism described here is intended to address the need for 69 better fail-over (convergence time) and sharing of the register 70 decapsulation load (again, when using the shared-tree) among RPs in a 71 domain. It is primarily intended for applications within those 72 networks which are using MBGP, Multicast Source Discovery Protocol 73 [MSDP] and PIM-SM protocols for native multicast deployment, although 74 it not limited to those protocols. In particular, Anycast RP is 75 applicable in any PIM-SM network that also supports MSDP (MSDP is 76 required so that the various RPs in the domain maintain a consistent 77 view of the sources that are active). Note however, a domain 78 deploying Anycast RP is not required to run MBGP. 80 5. Problem Definition 82 The anycast RP solution provides a solution for both fast fail-over 83 and shared-tree load balancing among any number of active RPs in a 84 domain. 86 5.1. Traffic Concentration and Distributing Decapsulation Load Among RPs 88 While PIM-SM allows for multiple RPs to be defined for a given group, 89 only one group to RP mapping can active at a given time. A 90 traditional deployment mechanism for balancing register decapsulation 91 load between multiple RPs covering the multicast group space is to 92 split up the 224.0.0.0/4 space between multiple defined RPs. This is 93 an acceptable solution as long as multicast traffic remains low, but 94 has problems as multicast traffic increases, especially because the 95 network operator defining group space split between RPs does not 96 alway have a priori knowledge of traffic distribution between groups. 97 This can be overcome via periodic reconfigurations, but operational 98 considerations cause this type of solution to scale poorly. 100 5.2. Sub-optimal Forwarding of Multicast Packets 102 When a single RP serves a given multicast group, all joins to that 103 group will be sent to that RP regardless of the topological distance 104 between the RP and the sources and receivers. Initial data will be 105 sent towards the RP also until configured shortest path tree switch 106 threshold is reached, or the data will always be sent towards the RP 107 if the network is configured to always use RP rooted shared tree. 108 This holds true even if all the sources and the receivers are in any 109 given single region, and RP is topologically distant from the sources 110 and the receivers. This is an artifact of the dynamic nature of 111 multicast group members, and of the fact that operators may not 112 always have a priori knowledge of the topological placement of the 113 group members. 115 Taken together, these effects can mean that (for example) although 116 all the sources and receivers of a given group are in Europe, they 117 are joining towards the RP in USA and the data will be traversing 118 relatively expensive pipe(s) twice, once to get to RP, and back down 119 the RP rooted tree again, creating inefficient use of expensive 120 resources. 122 5.3. Distant RP Dependencies 124 As outlined above, a single active RP per group may cause local 125 sources and receivers to become dependent on a topologically distant 126 RP. In addition, when multiple RPs are configured, there can be 127 considerable convergence delay involved in switching to the backup 128 RP. This delay may exist independent of the toplogical location of 129 the primary and backup RPs. 131 6. Solution 133 Given the problem set outlined above, a good solution would allow an 134 operator to configure multiple RPs per group, and distribute those 135 RPs in a topologically significant manner to the sources and 136 receivers. 138 6.1. Mechanisms 140 All the RPs serving a given group or set of groups are configured 141 with identical unicast address, using a numbered interface on the RPs 142 (frequently a logical interface such as a loopback is used). RPs then 143 advertise group to RP mappings using this interface address. This 144 will cause group members (senders) to join (register) towards the 145 topologically closest RP. RPs MSDP peer with each other using an 146 address unique to each RP. Note that if the router implementation 147 chooses the anycast address as the router ID, then peerings and/or 148 adjacencies may not be established. 150 In summary then, the following steps are required: 152 6.1.1. Create the set of group-to-anycast-RP-address mappings 154 The first step is to create the set of group-to-anycast-RP-address 155 mappings to be used in the domain. Each RP participating in a anycast 156 RP set must be configured with a consistent set of group to RP 157 address mappings. This mapping will be used by the non-RP routers in 158 the domain. 160 6.1.2. Configure each RP for the group range with the anycast RP address 162 The next step is to configure each RP for the group range with the 163 anycast RP address. If a dynamic mechanism such as auto-RP or the 164 PIMv2 bootstrap mechanism is being used to advertise group to RP 165 mappings, the anycast IP address should be used for the RP address. 167 6.1.3. Configure MSDP peerings between each of the anycast RPs in the 168 set 170 Unlike the group to RP mapping advertisements, MSDP peerings must use 171 an IP address that is unique to the endpoints. A general guideline is 172 to follow the addressing of the BGP peerings, e.g., loopbacks for 173 iBGP peering, physical interface addresses for eBGP peering. Note 174 that the anycast address MUST NOT be used as the RP address in SA 175 messages (as this would case the peer-RPF check to fail). 177 6.1.4. Configure the non-RP's with the group-to-anycast-RP-address 178 mappings 180 Finally, each non-RP router must learn the set of group to RP 181 mappings. This could be done via static configuration, auto-RP, or by 182 PIMv2 bootstrap mechanism. 184 6.1.5. Ensure that the anycast IP address is reachable by all routers in 185 the domain 187 This is typically accomplished by causing each RP to inject the /32 188 into the domain's IGP. 190 6.2. Interaction with MSDP Peer-RPF check 192 Each MSDP peer receives and forwards the message away from the RP 193 address in a "peer-RPF flooding" fashion. The notion of peer-RPF 194 flooding is with respect to forwarding SA messages [MSDP]. The BGP 195 routing tables are examined to determine which peer is the next hop 196 towards the originating RP of the SA message. Such a peer is called 197 an "RPF peer". See [MSDP] for details of the Peer-RPF check. Not 198 finally that the anycast address MUST NOT be used as the RP address 199 in the RP's SA messages. 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 7. Security considerations 210 Since the solution described here makes heavy use of anycast 211 addressing, care must be taken to avoid spoofing. In particular 212 unicast routing and PIM RPs must be protected. 214 7.1. Unicast Routing 216 Both internal and external unicast routing can be weakly protected 217 with keyed MD5 [RFC1828], as implemented in an internal protocol such 218 as OSPF [RFC2382] or in BGP [RFC2385]. More generally, IPSEC 219 [RFC1825] could be used to provide protocol integrity for the unicast 220 routing system. 222 7.1.1. Effects of Unicast Routing Instability 224 While not a security issue, it is worth noting that if unicast 225 routing is unstable, then the actual RP that source or receiver is 226 using will be subject to the same instability. 228 7.2. Multicast Protocol Integrity 230 The mechanisms described in [RFC2362] should be used to provide 231 protocol message integrity protection and group-wise message origin 232 authentication. 234 7.3. MSDP Peer Integrity 236 As is the the case for BGP, MSDP peers can be protected using keyed 237 MD5 [RFC1828]. 239 8. Acknowledgments 241 John Meylor, Bill Fenner, Dave Thaler and Tom Pusateri provided 242 insightful comments on earlier versions for this idea. 244 9. References 246 [MSDP] D. Farinacci, et. al., "Multicast Source Discovery 247 Protocol (MSDP)", draft-ietf-msdp-spec-02.txt, 248 January, 2000. Work in Progress. 250 [RFC1825] Atkinson, R., "IP Security Architecture", August 1995. 252 [RFC1828] P. Metzger and W. Simpson, "IP Authentication using Keyed 253 MD5", RFC 1828, August, 1995. 255 [RFC2362] D. Estrin, et. al., "Protocol Independent Multicast- 256 Sparse Mode (PIM-SM): Protocol Specification", RFC 257 2362, June, 1998. 259 [RFC2382] Moy, J., "OSPF Version 2", RFC 2382, April 1998. 261 [RFC2385] Herrernan, A., "Protection of BGP Sessions via the TCP 262 MD5 Signature Option", RFC 2385, August, 1998. 264 [RFC2403] C. Madson and R. Glenn, "The Use of HMAC-MD5-96 within 265 ESP and AH", RFC 2403, November, 1998. 267 10. Author's Address 269 Dorian Kim 270 Verio, Inc. 271 2361 Lancashire Dr. #2A 272 Ann Arbor, MI 48015 273 Email: dorian@blackrose.org 275 Hank Kilmer 276 Email: hank@rem.com 278 Dino Farinacci 279 Procket Networks 280 Email: dino@procket.com 282 David Meyer 283 Cisco Systems, Inc. 284 170 Tasman Drive 285 San Jose, CA, 95134 286 Email: dmm@cisco.com