idnits 2.17.1 draft-ietf-mboned-imrp-some-issues-00.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-24) 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? ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 8) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages -- Found 9 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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 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.) -- The document date (February 1997) is 9930 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) == Outdated reference: A later version (-09) exists of draft-ietf-idmr-cbt-spec-06 ** Downref: Normative reference to an Historic draft: draft-ietf-idmr-cbt-spec (ref. 'CBT') == Outdated reference: A later version (-11) exists of draft-ietf-idmr-dvmrp-v3-03 ** Downref: Normative reference to an Informational draft: draft-ietf-idmr-dvmrp-v3 (ref. 'DVMRP') -- Possible downref: Non-RFC (?) normative reference: ref. 'HDVMRP' -- Possible downref: Non-RFC (?) normative reference: ref. 'LABOV97' == Outdated reference: A later version (-05) exists of draft-ietf-idmr-pim-arch-04 -- Possible downref: Normative reference to a draft: ref. 'PIMARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'PIM-DM' -- No information found for draft-ietf-idmr-PIMBR-spec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PIMMBR' -- No information found for draft-ietf-idmr-PIM-SM-spec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PIM-SM' -- No information found for draft-thaler-interop - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'THALER96' -- No information found for draft-ietf-idr-rout-dampen - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'VILLAM95' Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONE Deployment Working Group David Meyer 3 Internet Draft University of Oregon 5 Expiration Date: August 1997 February 1997 7 Some Issues for an Inter-domain Multicast Routing Protocol 9 draft-ietf-mboned-imrp-some-issues-00.txt 11 1. Status Of This Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 2. Introduction 31 The IETF's Inter-Domain Multicast Routing (IDMR) working group has 32 produced several multicast routing protocols, including Core Based 33 Trees [CBT] and Protocol Independent Multicasting [PIMARCH]. In 34 addition, the IDMR WG has formalized the specification of the 35 Distance Vector Multicast Routing Protocol [DVMRP]. Various 36 specifications for protocol inter-operation have also been produced 37 (see, for example, [THALER96] and [PIMMBR]). However, none of these 38 protocols seems ideally suited to the inter-domain routing case; that 39 is, while these protocols are appropriate for the intra-domain 40 routing environment, they break down in various ways when applied in 41 to the multi-provider inter-domain case. 43 This document considers some of the scaling, stability and policy 44 issues that are of primary importance in a inter-domain, multi- 45 provider multicast environment. 47 3. Forwarding State Requirements 49 Any scalable protocol will have to minimize forwarding state 50 requirements. In the case of dense mode protocols [DVMRP][PIM-DM], 51 routers may carry forwarding or prune state for every (S,G) pair in 52 the Internet. This is true even for routers that may not be on any 53 delivery tree. It seems likely that as multicast deployment scales to 54 the size of the Internet, maintenance of (S,G) state will become 55 intractable. 57 Shared tree protocols, on the other hand, have the advantage of 58 maintaining a single (*,G) entry for a group's receivers (thus 59 relaxing the requirement of maintaining (S,G) for the entire 60 Internet). However, this is not without its own disadvantages; see 61 the section on "Third-party Resource Dependencies" below. 63 4. Forwarding State Distribution 65 The objective of a multicast forwarding state distribution mechanism 66 is to ensure that multicast traffic is efficiently distributed to 67 those parts of the topology where there are receivers. Dense and 68 sparse mode protocols will accept differing overheads based on design 69 tradeoffs. In the dense mode case, the data-driven nature state 70 distribution has disadvantage that data is periodically distributed 71 to branches of the distribution tree which don't have receivers 72 ("Flood and Prune" behavior). It seems unlikely that this mechanism 73 will be scalable to Internet-wide case. 75 On the other hand, sparse mode protocols use receiver-initiated, 76 explicit joins to establish a forwarding path along a shared 77 distribution tree. While the on-demand nature of sparse mode 78 protocols have favorable properties with respect to distribution of 79 forwarding state, it also has the possible disadvantage of creating 80 dependencies on shared resources (again, see the section on "Third- 81 Party Resource Dependencies" below). 83 5. Forwarding State Maintenance 85 The many current multicast protocols attempt to accurately and 86 rapidly maintain distribution trees that are as close to optimal as 87 possible. This means that the shape of a distribution tree can be 88 rapidly changing. In addition, since distribution trees can be 89 global, they can be subject to high frequency control traffic. 91 In contrast, the focus in the inter-domain unicast routing 92 environment is on minimizing routing traffic (see, for example, 93 [VILLAM95]), and controlling stability [LABOV97]. The implication is 94 that protocol overhead and stability must be controlled if we hope 95 multicast to scale to Internet sizes. Thus it seems likely that 96 Inter-domain multicast routing protocols will have to do less 97 forwarding state maintenance, and hence be less aggressive in 98 reshaping distribution trees. Note that this reshaping is related to 99 what has been termed "routing flux" (again, see [LABOV97]), since the 100 routing traffic does not directly affect path selection. Rather, the 101 primary effect is to require significant processing resources in a 102 border router. Finally, note that unlike the unicast case, we do not 103 have good data characterizing this effect for multicast routers. 105 5.1. Bursty Source Problem 107 The "Bursty Source Problem" can be described as those cases in which 108 sources loose data because there is very long join latency and/or 109 initial send latency. The current set of multicast routing protocols 110 attempt, where possible, to avoid this problem (i.e., maximize 111 response to bursty sources). Further, the combination of long 112 latencies with flooding joins can become a problem where a large 113 number of groups are joined and left at high frequency. 115 6. Mixed Control 117 Mixing control of topology discovery and distribution tree 118 construction can lead to efficiencies but also imposes various 119 constraints on topology discovery mechanisms. For example, DVMRP 120 [DVMRP] uses topology discovery facilities ("split horizon with 121 poison reverse") to eliminate duplicate packets on a LAN, and to 122 detect non-leaf networks (an upstream router uses this information 123 when pruning downstream interfaces). 125 On the other hand, PIM [PIM-DM] does not use any topology discovery 126 algorithm features when building delivery trees. However, this 127 independence is not without cost: PIM-DM accepts some duplicates on 128 multi-access LANs as a tradeoff for reduced protocol complexity. 130 7. Neighbor Model 132 The current inter-domain unicast routing model has some key 133 differences with proposed inter-domain multicast routing models with 134 respect to neighbor (peer) discovery. In particular, the current set 135 of multicast protocols depend heavily on dynamic neighbor discovery. 136 This is analogous to the situation with intra-domain unicast routing, 137 but is unlike current inter-domain unicast routing, where neighbors 138 are typically statically configured. 140 The static neighbor configuration model has several benefits for 141 inter-domain routing. First, neighbors are predefined, which is a 142 policy requirement in most cases. In addition, the set of peers in 143 the inter-domain unicast routing system defines the set of possible 144 inter-domain topologies (with the current active topology represented 145 by the collection of AS paths). 147 Another important difference relates to how inter-domain regions are 148 modeled. For purposes of this document, consider an inter-domain 149 region defined to be a part of an arbitrary topology in which a 150 higher level (inter-domain) routing protocol is used to calculate 151 paths between regions. In addition, each pair of adjacent regions is 152 connected by one or more multicast border routers. Current IDMR 153 proposals (e.g., [HDVMRP], [THALER96]) model an inter-domain region 154 as a routing domain. That is, border routers internetwork between one 155 or more intra-domain regions and an inter-domain region (again, 156 possibly more than one). In this model, inter-networking occurs 157 "inside" router. However, the inter-provider unicast routing model in 158 use today is quite different. In particular, the "peering" between 159 two providers occurs in neither of the provider's routing domains, 160 nor does it occur in some shared "inter-domain" routing domain. The 161 separation provides the administrative and policy control that is 162 required in today's Internet. 164 8. Unicast Topology Dependency 166 Ideally, unicast and multicast topologies are congruent in the 167 Internet. However, since it is frequently difficult to field new 168 facilities (such as IP multicast) in the "core" the Internet 169 infrastructure, there will continue to be many cases in which unicast 170 and multicast topologies are not congruent (either because a region 171 is not multicast capable at all, or because the region is not 172 natively forwarding multicast traffic). Thus, it is unlikely that the 173 entire IPv4 Internet will be able to carry native multicast traffic 174 in the foreseeable future. In addition, various policy requirements 175 will in certain cases cause to topologies to further diverge. The 176 implication is that a successful IDMR will need a topology discover 177 mechanism, or have other mechanisms for dealing with those cases in 178 which unicast and multicast topologies are not congruent. 180 9. Third-Party Resource Dependencies 182 Shared tree protocols require one or more globally shared Rendezvous 183 Points (RPs) [PIM-SM] or Cores [CBT]. The RP or Core effectively 184 serves as the root of a group specific shared tree. Data is sent to 185 the RP/Core for delivery on the shared tree. This means that some 186 groups may have an RP (or core) that is fielded by a third party. For 187 example, if providers A, B and C share a PIM-SM inter-domain region, 188 then there will exist an RP that is mapped to C's multicast border 189 router. In this case, C is hosting a kind of "transit RP" for A and B 190 (A and B register to C to communicate between themselves, even if C 191 has no receivers for the group(s) served by the RP. 193 10. Traffic Concentration Problem 195 Traffic can be "concentrated" on a shared tree. This can lead to 196 increased latency or packet loss. However, this is less of a problem 197 in the shared-media exchange point environment. 199 11. Distant RP/Core Problem 201 In the shared tree model, if the RP or Core is distant 202 (topologically), then joins will travel to the distant RP/Core, even 203 if the data is being delivered locally. Note that this problem is 204 exacerbated by the global nature of the RP/Core space; if a router is 205 registering to a RP/Core that is not in the local domain (say, 206 fielded by the site's direct provider), then the routing domain is 207 flat. 209 12. Multicast Internal Gateway Protocol (MIGP) Independence 211 A shared tree, explicit join protocol inter-domain routing protocol 212 may require modification to a leaf domain's internal multicast 213 routing mechanism. The problem arises when a domain is running a 214 "flood and prune" protocol such as DVMRP or PIM-DM internally while 215 participating in a shared tree inter-domain protocol. In this case, 216 those areas of the (internal) topology where there are no sources 217 will not receive inter-domain traffic. It has been suggested that 218 these protocols be modified to use Domain Wide Reports [HDVMRP] to 219 communication domain-wide group membership to a domain's border 220 routers. 222 13. Encapsulations 224 An IDMRP should minimize encapsulations where ever possible. PIM-SM 225 encapsulates packets sent to the shared tree in PIM Register messages 226 (data can be delivered natively if the last hop router or the RP 227 switches to the shortest path tree). HDVMRP requires every inter- 228 domain packet to be rewritten with an additional level of 229 encapsulation for inter-domain forwarding. Further, the number of 230 encapsulations/decapsulations for paths that traverse N 231 administrative domains is O(N); each border border router "registers" 232 to a group specific RP, which then decapsulates the packet for 233 distribution on the shared tree. 235 14. Policy Provisions 237 Current inter-domain unicast routing protocols have a rich and well 238 developed policy model. In contrast, multicast routing protocols 239 have little or no provision for implementing routing policy 240 (administrative scoping is one major exception). A concrete example 241 of this need is the various problems with inadvertent injection of 242 unicast routing tables into the MBONE, coupled with our inability to 243 propagate the resultant large DVMRP routing tables, point out the 244 need for such policy oriented controls. 246 A simple example illustrates why a successful inter-domain multicast 247 routing protocol will need to have a well developed policy model: 248 Consider three providers, A, B, and C, that have connections to a 249 shared-media exchange point. Assume that connectivity is non- 250 transitive due to some policy (the common case, since bi-lateral 251 agreements are a very common form of peering agreement). That is, A 252 and B are peers, B and C are peers, but A and C are not peers. Now, 253 consider a source prefix P, where P belongs to a customer of A (i.e., 254 P is advertised by A). Now, multicast packets forwarded by A's 255 border router will be correctly accepted by B, since B sees the RPF 256 interface for P to be the shared-media of the exchange. Likewise, 257 C's border router will reject the packets forwarded by A's border 258 router because, by definition, C does not have A's routes through its 259 interface on the exchange (so packets sourced "inside" A fail the RPF 260 check in C's border router). 262 In the example above, RPF is a powerful enough mechanism to inform C 263 that it should not accept packets sourced in P from A over the 264 exchange. However, consider the common case in which P is multi- 265 homed to both A and B. C now sees a route for P from B though its 266 interface on the exchange. Without some form of multi-provider 267 cooperation and/or packet filtering, C could accept multicast packets 268 from A across the exchange, even though A and C don't peer. Clearly, 269 this is an unintended consequence. In addition, note that RPF itself 270 is essentially a packet filtering technology, and as such has 271 qualitatively different resource requirements than the route filters 272 that are commonly deployed in border routers. 274 14.1. Today's MBONE 276 Another way to view the policy issues described above is to consider 277 the perspective of unicast reachability. Today's MBONE is comprised 278 of a single flat AS. Further, this AS running a simple distance 279 vector topology discovery protocol. This arrangement is unlikely to 280 scale gracefully or provide the same rich policy control that we find 281 in the unicast Internet. There are additional problems with a flat AS 282 model: the flat AS model fits neither the operational or 283 organizational models commonly found in Internet today. 285 15. Equal Cost Multipath 287 A common way to incrementally scale available bandwidth is to provide 288 parallel equal cost paths. It would be an advantage if a multicast 289 routing protocol could support this. However, this would seem 290 difficult to achieve when using Reverse Path Forwarding, so it is 291 unclear whether this goal is achievable. 293 16. Conclusion 295 Deployment of a general purpose IP multicast infrastructure for the 296 Internet has been slowed by various factors. One of the primary 297 reasons, however, is the lack of a true inter-domain Multicast 298 Routing Protocol. Several proposals have been advanced to solve this 299 problem, including PIM-SM [PIM-SM], DVMRP [PIMMBR], and Hierarchical 300 DVMRP [HDVMRP]. However, the concerns outlined above have prevented 301 any of these protocols from being adopted as the standard inter- 302 domain multicast routing protocol. Finally, it is worth noting that 303 DVMRP, since it is the common denominator among router vendor 304 offerings, is currently the de-facto inter-domain routing protocol. 306 17. Security Considerations 308 Security considerations are not discussed in this memo. 310 18. References 312 [CBT] A. Ballardie, et. al., "Core Based Trees (CBT) 313 Multicast -- Protocol Specification --", 314 draft-ietf-idmr-cbt-spec-06.txt, September, 1996. 316 [DVMRP] T. Pusateri, "Distance Vector Multicast Routing 317 Protocol", draft-ietf-idmr-dvmrp-v3-03, September, 318 1996. 320 [HDVMRP] Ajit S.. Thyagarajan and Steve Deering, " 321 Hierarchical Distance-Vector Multicast Routing for 322 the MBone", In Proceedings of the ACM SIGCOMM, pages 323 60-66, October, 1995. 325 [LABOV97] Labovitz, Craig, et. al., "Internet Routing 326 Instability", Submitted to SIGCOMM97. 328 [PIMARCH] Estrin, D, et. al., "Protocol Independent Multicast 329 Sparse Mode (PIM-SM): Motivation and Architecture", 330 draft-ietf-idmr-pim-arch-04.ps , October, 1996. 332 [PIM-DM] Estrin, D, et. al., "Protocol Independent Multicast 334 Dense Mode (PIM-DM): Protocol Specification", 335 draft-ietf-idmr-PIM-DM-spec-04.ps, September, 1996. 337 [PIMMBR] Estrin, D, et. al., "PIM Multicast Border Router 338 (PMBR) specification for connecting PIM-SM domains 339 to a DVMRP Backbone", draft-ietf-idmr-PIMBR-spec-01.ps, 340 September, 1996. 342 [PIM-SM] Estrin, D, et. al., "Protocol Independent Multicast 343 Sparse Mode (PIM-SM): Protocol Specification", 344 draft-ietf-idmr-PIM-SM-spec-09.ps, October, 1996. 346 [THALER96] D. Thaler, "Interoperability Rules for Multicast 347 Routing Protocols", draft-thaler-interop-00.ps, 348 November, 1996. 350 [VILLAM95] C Villamizar, Ravi Chandra, and Ramesh Govindan, 351 "Controlling BGP/IDRP Routing Overhead", 352 draft-ietf-idr-rout-dampen-00.ps, July, 1995. 354 19. Acknowledgments 356 Dino Farinacci and Dave Thaler provided several insightful comments 357 on earlier drafts of this document. 359 20. Author Information 361 David Meyer 362 University of Oregon 363 1225 Kincaid St. 364 Eugene, OR 97403 365 Phone: (541) 346-1747 366 e-mail: meyer@antc.uoregon.edu