idnits 2.17.1 draft-ietf-mboned-anycast-rp-07.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 Internet-Drafts being working documents. == 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 == Line 60 has weird spacing: '...ossible sub-o...' == 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.) -- 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 275, 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: 13 errors (**), 0 flaws (~~), 8 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 Experimental 10 July, 2001 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 2026. 20 Internet Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups 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 2362 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 can be active at any time. 57 The single mapping property has several implications, including 58 traffic concentration, lack of scalable register decapsulation (when 59 using the shared tree), slow convergence when an active RP fails, 60 possible 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. Finally, a general 79 requirement of the Anycast RP scheme is that the anycast address MUST 80 NOT be used as the RP address in the RP's SA messages. 82 The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, 83 SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined 84 in RFC 2119 [RFC2119]. 86 5. Problem Definition 88 The anycast RP solution provides a solution for both fast fail-over 89 and shared-tree load balancing among any number of active RPs in a 90 domain. 92 5.1. Traffic Concentration and Distributing Decapsulation Load Among RPs 94 While PIM-SM allows for multiple RPs to be defined for a given group, 95 only one group to RP mapping can active at a given time. A 96 traditional deployment mechanism for balancing register decapsulation 97 load between multiple RPs covering the multicast group space is to 98 split up the 224.0.0.0/4 space between multiple defined RPs. This is 99 an acceptable solution as long as multicast traffic remains low, but 100 has problems as multicast traffic increases, especially because the 101 network operator defining group space split between RPs does not 102 always have a priori knowledge of traffic distribution between 103 groups. This can be overcome via periodic reconfigurations, but 104 operational considerations cause this type of solution to scale 105 poorly. 107 5.2. Sub-optimal Forwarding of Multicast Packets 109 When a single RP serves a given multicast group, all joins to that 110 group will be sent to that RP regardless of the topological distance 111 between the RP and the sources and receivers. Initial data will be 112 sent towards the RP also until configured shortest path tree switch 113 threshold is reached, or the data will always be sent towards the RP 114 if the network is configured to always use RP rooted shared tree. 115 This holds true even if all the sources and the receivers are in any 116 given single region, and RP is topologically distant from the sources 117 and the receivers. This is an artifact of the dynamic nature of 118 multicast group members, and of the fact that operators may not 119 always have a priori knowledge of the topological placement of the 120 group members. 122 Taken together, these effects can mean that (for example) although 123 all the sources and receivers of a given group are in Europe, they 124 are joining towards the RP in USA and the data will be traversing 125 relatively expensive pipe(s) twice, once to get to RP, and back down 126 the RP rooted tree again, creating inefficient use of expensive 127 resources. 129 5.3. Distant RP Dependencies 131 As outlined above, a single active RP per group may cause local 132 sources and receivers to become dependent on a topologically distant 133 RP. In addition, when multiple RPs are configured, there can be 134 considerable convergence delay involved in switching to the backup 135 RP. This delay may exist independent of the toplogical location of 136 the primary and backup RPs. 138 6. Solution 140 Given the problem set outlined above, a good solution would allow an 141 operator to configure multiple RPs per group, and distribute those 142 RPs in a topologically significant manner to the sources and 143 receivers. 145 6.1. Mechanisms 147 All the RPs serving a given group or set of groups are configured 148 with identical anycast address, using a numbered interface on the RPs 149 (frequently a logical interface such as a loopback is used). RPs then 150 advertise group to RP mappings using this interface address. This 151 will cause group members (senders) to join (register) towards the 152 topologically closest RP. RPs MSDP peer with each other using an 153 address unique to each RP. Since the anycast address is not a unique 154 address (by definition), a router MUST NOT choose the anycast unicast 155 address as the router ID as this can prevent peerings and/or 156 adjacencies from being established. 158 In summary then, the following steps are required: 160 6.1.1. Create the set of group-to-anycast-RP-address mappings 162 The first step is to create the set of group-to-anycast-RP-address 163 mappings to be used in the domain. Each RP participating in a anycast 164 RP set must be configured with a consistent set of group to RP 165 address mappings. This mapping will be used by the non-RP routers in 166 the domain. 168 6.1.2. Configure each RP for the group range with the anycast RP address 170 The next step is to configure each RP for the group range with the 171 anycast RP address. If a dynamic mechanism such as auto-RP or the 172 PIMv2 bootstrap mechanism is being used to advertise group to RP 173 mappings, the anycast IP address should be used for the RP address. 175 6.1.3. Configure MSDP peerings between each of the anycast RPs in the 176 set 178 Unlike the group to RP mapping advertisements, MSDP peerings must use 179 an IP address that is unique to the endpoints; that is, the MSDP 180 peering endpoints MUST use a unicast rather than anycast address. A 181 general guideline is to follow the addressing of the BGP peerings, 182 e.g., loopbacks for iBGP peering, physical interface addresses for 183 eBGP peering. Note that the anycast address MUST NOT be used as the 184 RP address in SA messages (as this would case the peer-RPF check to 185 fail). 187 6.1.4. Configure the non-RP's with the group-to-anycast-RP-address 188 mappings 190 Finally, each non-RP router must learn the set of group to RP 191 mappings. This could be done via static configuration, auto-RP, or by 192 PIMv2 bootstrap mechanism. 194 6.1.5. Ensure that the anycast IP address is reachable by all routers in 195 the domain 197 This is typically accomplished by causing each RP to inject the /32 198 into the domain's IGP. 200 6.2. Interaction with MSDP Peer-RPF check 202 Each MSDP peer receives and forwards the message away from the RP 203 address in a "peer-RPF flooding" fashion. The notion of peer-RPF 204 flooding is with respect to forwarding SA messages [MSDP]. The BGP 205 routing tables are examined to determine which peer is the next hop 206 towards the originating RP of the SA message. Such a peer is called 207 an "RPF peer". See [MSDP] for details of the Peer-RPF check. 209 6.3. State Implications 211 It should be noted that using MSDP in this way forces the creation of 212 (S,G) state along the path from the receiver to the source. This 213 state may not be present if a single RP was used and receivers were 214 forced to stay on the shared tree. 216 7. Security considerations 218 Since the solution described here makes heavy use of anycast 219 addressing, care must be taken to avoid spoofing. In particular 220 unicast routing and PIM RPs must be protected. 222 7.1. Unicast Routing 224 Both internal and external unicast routing can be weakly protected 225 with keyed MD5 [RFC1828], as implemented in an internal protocol such 226 as OSPF [RFC2382] or in BGP [RFC2385]. More generally, IPSEC 227 [RFC1825] could be used to provide protocol integrity for the unicast 228 routing system. 230 7.1.1. Effects of Unicast Routing Instability 232 While not a security issue, it is worth noting that if unicast 233 routing is unstable, then the actual RP that source or receiver is 234 using will be subject to the same instability. 236 7.2. Multicast Protocol Integrity 238 The mechanisms described in [RFC2362] should be used to provide 239 protocol message integrity protection and group-wise message origin 240 authentication. 242 7.3. MSDP Peer Integrity 244 As is the the case for BGP, MSDP peers can be protected using keyed 245 MD5 [RFC1828]. 247 8. Acknowledgments 249 John Meylor, Bill Fenner, Dave Thaler and Tom Pusateri provided 250 insightful comments on earlier versions for this idea. 252 9. References 254 [MSDP] D. Farinacci, et. al., "Multicast Source Discovery 255 Protocol (MSDP)", draft-ietf-msdp-spec-02.txt, 256 January, 2000. Work in Progress. 258 [RFC1825] Atkinson, R., "IP Security Architecture", August 1995. 260 [RFC1828] P. Metzger and W. Simpson, "IP Authentication using Keyed 261 MD5", RFC 1828, August, 1995. 263 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 264 Requirement Levels", RFC 2119, March, 1997. 266 [RFC2362] D. Estrin, et. al., "Protocol Independent Multicast- 267 Sparse Mode (PIM-SM): Protocol Specification", RFC 268 2362, June, 1998. 270 [RFC2382] Moy, J., "OSPF Version 2", RFC 2382, April 1998. 272 [RFC2385] Herrernan, A., "Protection of BGP Sessions via the TCP 273 MD5 Signature Option", RFC 2385, August, 1998. 275 [RFC2403] C. Madson and R. Glenn, "The Use of HMAC-MD5-96 within 276 ESP and AH", RFC 2403, November, 1998. 278 10. Author's Address 280 Dorian Kim 281 Verio, Inc. 282 2361 Lancashire Dr. #2A 283 Ann Arbor, MI 48015 284 Email: dorian@blackrose.org 286 Hank Kilmer 287 Email: hank@rem.com 289 Dino Farinacci 290 Procket Networks 291 Email: dino@procket.com 293 David Meyer 294 Cisco Systems, Inc. 295 170 Tasman Drive 296 San Jose, CA, 95134 297 Email: dmm@cisco.com