idnits 2.17.1 draft-farinacci-anycast-clusters-01.txt: 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. Expected boilerplate is as follows today (2024-04-26) 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ietf-farinacci-anycast-clusters-01', but the file name used is 'draft-farinacci-anycast-clusters-01' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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. ** There are 11 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances 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: ---------------------------------------------------------------------------- == Line 185 has weird spacing: '...rt (or data ...' == Line 187 has weird spacing: '... (or if the ...' == Line 188 has weird spacing: '...ast.net to re...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (March 3, 1998) is 9551 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) == Unused Reference: '1' is defined on line 232, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 237, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 241, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental draft: draft-ietf-idmr-pim-sm-specv2 (ref. '1') == Outdated reference: A later version (-04) exists of draft-ietf-idmr-gum-01 -- Possible downref: Normative reference to a draft: ref. '2' Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dino Farinacci 2 INTERNET DRAFT Liming Wei 3 John Meylor 4 cisco Systems 5 March 3, 1998 7 Use of Anycast Clusters for Inter-Domain Multicast Routing 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 Anycast Clusters is a proposal to connect multiple ISP sparse-mode 31 PIM domains together. The environment we anticipate is multiple 32 interconnection points among a set of ISPs when they are unable to 33 colocate their respective RPs at the same dense-mode interconnect 34 point. This is an alternative to the Multi-Level RP design and 35 requires less new code in routers. 37 This proposal is being submitted as a method for the initial phase of 38 Inter-Domain Multicast deployment and is upward compatible with the 39 IDMR protocols being proposed for subsequent phases. 41 1.0 Introduction 43 Anycast Clusters is a proposal to connect multiple ISP sparse-mode 44 PIM domains together. The environment we anticipate is multiple 45 interconnection points among a set of ISPs when they are unable to 46 colocate their respective RPs at the same dense-mode interconnect 47 point. This is an alternative to the Multi-Level RP design and 48 requires less new code in routers. 50 This proposal uses an adminstrative approach to solve the problem of 51 connecting shared trees together across domains. To expedite 52 deployment with minimal risk, changes to architecture or protocols 53 are not considered. 55 It is known that there is a 3rd party RP problem when an ISP must 56 depend on another ISP's RP to 1) get their own sources' traffic on 57 the shared tree and 2) to receive multicast traffic from sources 58 inside and outside of their domain. This proposal reduces the 59 probability that a 3rd party RP is used but doesn't eliminate it all 60 together. 62 1.1 Terminology 64 Multicast Cluster 65 A Multicast Cluster is an interconnect or dense-mode region where 66 there are two or more multicast peering agreements among ISPs. The 67 Multicast Cluster runs dense-mode PIM. 69 Anycast Cluster Address 70 A single IP unicast address that every router on a Multicast 71 Cluster interconnect has assigned to it. The address is assigned 72 to a loopback interface on each multicast router. The same address 73 is used on the loopback interface of each router. 75 Cluster RP Address 76 Is the address routers use to Register and Join to an RP. The RP 77 address is the assigned Anycast Cluster Address. 79 2.0 Overview 81 There will be N Multicast Cluster interconnects configured in the 82 Internet. The number of interconnects may change but we anticipate 83 it will not change often. The global multicast group address space 84 will be divided among the N Multicast Clusters. That is, 1/Nth of the 85 group address space will use the Cluster RP Address associated with 86 each Multicast Cluster. This allows traffic distribution for 87 different groups on each of their shared-trees to be split across all 88 Multicast Clusters. 90 Receivers in any domain join a single shared tree. The leaf routers 91 that hear IGMP reports for a specific group will do a DNS lookup to 92 obtain the Cluster RP Address. By converting the dotted decimal group 93 address, obtained from the IGMP report, into a DNS domain name 94 string, a name is created for the DNS lookup. 96 The Joins that are propagated toward the RP will hit the first 97 Cluster RP Address for the group, and hence why we call it an Anycast 98 Cluster Address. For the same group that is joined, many border 99 routers at the Multicast Cluster interconnect can act as the RP for 100 the group. This is how a domain can pull down data for receivers in 101 its domain. 103 Many shared trees can be built if receivers in other domains use a 104 different router as the RP on the Multicast Cluster. Each shared tree 105 is joined together at the Multicast Cluster interconnect since it is 106 a dense-mode interconnect. 108 Similarly, Register messages from leaf routers use the dotted decimal 109 group address to DNS string mapping and the closest router with the 110 Cluster RP Address is used. This allows sources in the same domain to 111 get their packets to the shared tree for receivers in other domains. 113 Requiring the Multicast Cluster interconnect to run dense-mode PIM 114 allows any RP that receives data via Register messages to forward on 115 the interconnect so the other RPs in the Multicast Cluster can 116 forward down their respective shared trees. 118 3.0 Group Allocation 120 Since a global group address subrange is assigned to a Multicast 121 Cluster interconnect and not to a domain, there is no address 122 ownership or leasing algorithm issues to deal with. We anticipate the 123 number of subranges be less than or equal to 256. So we believe it is 124 easily manageable in DNS because of the small number and the 125 infrequent changes to the allocation. The DNS records only need 126 change when there is a new Multicast Cluster configured. This occurs 127 at the rate when new multicast peering interconnects are deployed by 128 ISPs. 130 4.0 Example Multicast Cluster Design 132 Let's say, initially, there are 12 ISPs that will multicast peer at 8 133 different public interconnects. Therefore, there will be 8 Multicast 134 Clusters. Let's say the 224.2.0.0/16 range of group addresses are 135 used for global multicast addressing. 137 Let's allocate a class C network for the Cluster RP Addresses with 138 the following address convention: 140 223.255.255.x where x defines the Cluster RP Address. The host address 141 for all RPs at a Multicast Cluster will be 1 by convention. So: 143 223.255.255.1 = Cluster 1 144 223.255.255.3 = Cluster 2 145 223.255.255.5 = Cluster 3 146 223.255.255.7 = Cluster 4 147 ... 148 223.255.255.255 = Cluster 128 150 Each ISP router that wishes to be the RP on the Multicast Cluster 1 151 will do the following: 153 interface loopback0 154 ip address 223.255.255.1 255.255.255.255 156 It is required that at least two RPs are present at any interconnect 157 so a single ISP doesn't have to carry the load for the the entire 158 group subrange allocated to the Multicast Cluster. 160 A single ISP can provide an RP for all or some of the Multicast 161 Clusters it is attached to but is required to provide an RP on at 162 least one interconnect. 164 In the DNS the 224.2.0.0/16 range could be divided as follows: 166 Cluster Group Range DNS Mapping RP Address 167 ------- ----------- ----------- ---------- 168 000 224.2.x.0/24 -> x.2.224.mcast.net IN A 223.255.255.1 169 where 0 <= x <= 31 170 001 224.2.x.0/24 -> x.2.224.mcast.net IN A 223.255.255.3 171 where 32 <= x <= 63 172 010 224.2.x.0/24 -> x.2.224.mcast.net IN A 223.255.255.5 173 where 64 <= x <= 95 174 011 224.2.x.0/24 -> x.2.224.mcast.net IN A 223.255.255.7 175 where 96 <= x <= 127 176 100 224.2.x.0/24 -> x.2.224.mcast.net IN A 223.255.255.9 177 where 128 <= x <= 159 178 101 224.2.x.0/24 -> x.2.224.mcast.net IN A 223.255.255.11 179 where 160 <= x <= 191 180 110 224.2.x.0/24 -> x.2.224.mcast.net IN A 223.255.255.13 181 where 192 <= x <= 223 182 111 224.2.x.0/24 -> x.2.224.mcast.net IN A 223.255.255.15 183 where 224 <= x <= 255 185 So if a leaf router received an IGMP report (or data packet) for 186 group 224.2.129.5, it would do a DNS lookup for 5.129.2.224.mcast.net 187 (or if the /24 convention is accepted it could simply lookup 188 129.2.224.mcast.net to reduce DNS entries) and get 223.255.255.9 re- 189 turned. It would Join or Register to the closest RP 223.255.255.9. 191 5.0 Observation 193 By using Anycast Cluster RP Addresses, no single ISP will have to be 194 RP for the entire group subrange allocated to the Multicast Cluster. 195 The workload and responsibility can be shared among the RPs (and 196 different ISPs) on that Multicast Cluster. 198 If an ISP doesn't configure an RP on a Multicast Cluster, it must do 199 so on another Multicast Cluster so it can be a good citizen and share 200 responsibilty. Since group addresses are mostly randomly allocated, 201 the RP load can be shared across Multicast Clusters and depending on 202 the source and receiver location may be load shared across routers 203 within a Multicast Cluster. 205 6.0 Acknowledgements 207 The authors would like to thank David Meyer and Steve Deering for 208 their insightful comments. 210 7.0 Author's Address: 212 Dino Farinacci 213 Cisco Systems, Inc. 214 170 Tasman Drive 215 San Jose, CA, 95134 216 Email: dino@cisco.com 218 Liming Wei 219 Cisco Systems, Inc. 220 170 Tasman Drive 221 San Jose, CA, 95134 222 Email: lwei@cisco.com 224 John Meylor 225 Cisco Systems, Inc. 226 170 Tasman Drive 227 San Jose, CA, 95134 228 Email: jmeylor@cisco.com 230 8.0 References 232 [1] Estrin D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., 233 Handley M., Jacobson, V., Liu C., Sharma, P., Wei, L., "Protocol 234 Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification", 235 draft-ietf-idmr-pim-sm-specv2-00.txt, September 9, 1997. 237 [2] Thaler, D., Estrin, D., Meyer, D., "Border Gateway Multicast 238 Protocol (BGMP): Protocol Specification", draft-ietf-idmr-gum-01.txt, 239 October 30, 1997. 241 [3] Bates, T., Chandra, R., Katz, D., and Y. Rekhter., "Multiprotocol 242 Extensions for BGP-4", draft-ietf-idr-bgp4-multiprotocol-01.txt, 243 September 1997.