--- 1/draft-ietf-mboned-imrp-some-issues-01.txt	2006-02-05 00:19:50.000000000 +0100
+++ 2/draft-ietf-mboned-imrp-some-issues-02.txt	2006-02-05 00:19:50.000000000 +0100
@@ -1,19 +1,21 @@
+
 MBONE Deployment Working Group                               David Meyer
 Internet Draft                                      University of Oregon
-Expiration Date:                               September 1997 March 1997
+
+Expiration Date:                                 December 1997 June 1997
 
       Some Issues for an Inter-domain Multicast Routing Protocol
 
-               draft-ietf-mboned-imrp-some-issues-01.txt
+               draft-ietf-mboned-imrp-some-issues-02.txt
 
-1. Status Of This Memo
+1. Status of this Memo
 
    This document is an Internet-Draft.  Internet-Drafts are working
    documents of the Internet Engineering Task Force (IETF), its areas,
    and its working groups.  Note that other groups may also distribute
    working documents as Internet-Drafts.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as ``work in progress.''
@@ -60,22 +62,22 @@
 
 4. Forwarding State Distribution
 
    The objective of a multicast forwarding state distribution mechanism
    is to ensure that multicast traffic is efficiently distributed to
    those parts of the topology where there are receivers. Dense and
    sparse mode protocols will accept differing overheads based on design
    tradeoffs. In the dense mode case, the data-driven nature state
    distribution has disadvantage that data is periodically distributed
    to branches of the distribution tree which don't have receivers
-   ("Flood and Prune" behavior). It seems unlikely that this mechanism
-   will be scalable to Internet-wide case.
+   ("Broadcast and Prune" behavior). It seems unlikely that this
+   mechanism will be scalable to Internet-wide case.
 
    On the other hand, sparse mode protocols use receiver-initiated,
    explicit joins to establish a forwarding path along a shared
    distribution tree. While the on-demand nature of sparse mode
    protocols have favorable properties with respect to distribution of
    forwarding state, it also has the possible disadvantage of creating
    dependencies on shared resources (again, see the section on "Third-
    Party Resource Dependencies" below).
 
 5. Forwarding State Maintenance
@@ -94,21 +96,26 @@
    multicast to scale to Internet sizes. Thus it seems likely that
    Inter-domain multicast routing protocols will have to do less
    forwarding state maintenance, and hence be less aggressive in
    reshaping distribution trees. Note that this reshaping is related to
    what has been termed "routing flux" (again, see [LABOV97]), since the
    routing traffic does not directly affect path selection. Rather, the
    primary effect is to require significant processing resources in a
    border router. Finally, note that unlike the unicast case, we do not
    have good data characterizing this effect for multicast routers.
 
-5.1. Bursty Source Problem
+5.1. Data Driven Forwarding State Creation
+
+   Another issue with broadcast and prune protocols is that forwarding
+   state is created in a data-driven manner.
+
+5.2. Bursty Source Problem
 
    When a source's inter-burst period is longer than the router state
    timeout period, some or all of a source's packets can be lost. This
    effect has been termed the "Bursty Source Problem" [ESTRIN97]. The
    current set of multicast routing protocols attempt, where possible,
    to avoid this problem (i.e., maximize response to bursty sources).
 
 6. Mixed Control
 
    Mixing control of topology discovery and distribution tree
@@ -213,24 +220,24 @@
    be exacerbated if the RP/Core space is global; if a router is
    registering to a RP/Core that is not in the local domain (say,
    fielded by the site's direct provider), then the routing domain is
    flat.
 
 12. Multicast Internal Gateway Protocol (MIGP) Independence
 
    A shared tree, explicit join protocol inter-domain routing protocol
    may require modification to a leaf domain's internal multicast
    routing mechanism. The problem arises when a domain is running a
-   "flood and prune" protocol such as DVMRP or PIM-DM internally while
-   participating in a shared tree inter-domain protocol. In this case,
-   there can be areas of the (internal) topology that has receivers but
-   will not receive inter-domain traffic.
+   "broadcast and prune" protocol such as DVMRP or PIM-DM internally
+   while participating in a shared tree inter-domain protocol. In this
+   case, there can be areas of the (internal) topology that has
+   receivers but will not receive inter-domain traffic.
 
    [THALER96] describes interoperability rules to alleviate this
    problem. Consider the case where a border router has interfaces in an
    inter-domain shared tree region and a DVMRP region. The rules
    covering this case state that either the DVMRP region must implement
    Region Wide Reports [HDVMRP], or the DVMRP component of the border
    router must be a wildcard receiver for externally reached sources,
    while the shared tree component is a wildcard receiver for internally
    reached sources. Alternatively, many current implementations use a
    "receiver-is-sender" approach (which depends for the most part on