Subject: PIM wg agenda items

From: Tom Pusateri <[email-masked]>
Date: Wed, 10 Mar 1999 15:09:00 -0800

I haven't received any agenda items for the PIM working group 
meeting next week. Hopefully, Liming has a list. But consider this
another request to send them to us if you haven't already sent
them to Liming.

For your amusement, the current agenda is:

http://www3.juniper.net/~pusateri/pim/minneapolis/index.html

Thanks,
Tom

---

From: Liming Wei <[email-masked]>
Date: Wed, 10 Mar 1999 15:18:28 -0800 (PST)

Tom, Sorry if I haven't posted the agenda items. I have the following
so far:

 1) Bi-directional tree PIM, Dino (30 minutes)
 2) State Refresh for PIM dense mode, Kurt (30-40 minutes)

I should give an overview of the updated spec, but that depends on
how much can be settled in the next few days.

-Liming
---------
> From: Tom Pusateri <[email-masked]>
>

---

From: Liming Wei <[email-masked]>
Date: Wed, 10 Mar 1999 15:49:05 -0800 (PST)

> We agreed up front that we would not let anyone talk without
> prior documentation. If a paper is not available (preferred),
> please have the slides available for everyone to review before
> the meeting.

I don't remember that we drew a line here that all requests
should be immediately rejected if no document is posted. We probably
strongly suggested that all presentation SHOULD have documentation
posted before the meeting.

I know that a draft exists, it is just because the people involved
were too busy, and the fact that I also forgot to request the doc at
the time of the request.

-Liming

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Wed, 10 Mar 1999 15:24:10 -0800

>  1) Bi-directional tree PIM, Dino (30 minutes)

Is there any document/draft/slides which we could use to get the
basic idea in advance, or it is suppose to be a surprise/motivation
to listen more carefully during the talk :)

Pavlin

---

From: Liming Wei <[email-masked]>
Date: Wed, 10 Mar 1999 15:39:13 -0800 (PST)

> There is supposed to be something in writing sent to the list
> before the speaker is allowed to present anything.

I'd say lets demand that for all presentation requests, but
only reject a presentation request if we run out of available time
and the item is irrevelant to the WG charter. None of that is true
this time.

For this particular item, I know a draft exists, but there might be
reasons that it wasn't posted (I even thought it was if not for
Pavlin's message).

-Liming

---

From: Liming Wei <[email-masked]>
Date: Wed, 10 Mar 1999 15:30:59 -0800 (PST)

> From: Pavlin Ivanov Radoslavov <[email-masked]>
> 

Since this is quite new, I wouldn't be surprised if there is not
sufficient time to post the document/slides. Lets remember to request
them in the WG meeting :-).

-Liming

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 10 Mar 1999 18:28:18 -0500

Thanks,
Tom

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 10 Mar 1999 18:37:18 -0500

Thanks,
Tom

---

From: Liming Wei <[email-masked]>
Date: Wed, 10 Mar 1999 18:31:36 -0800 (PST)

> please have the slides available for everyone to review before

[Obviously my previous attempt to respond did not go through...
 here is another try.]

I have sent a message to Dino requesting him to post document onto the
mailing list. This is more or less due to my oversight when I forgot
to make the request way earlier. My apologies to members of the list
and Dino.

Having said that, I'd like to say,

 1) We have plenty of "unused" presentation time available this time.
    It would be stupid to reject a presentation request on a very
    interesting subject, just because a vague verbal rule may exist;

 2) If we indeed had a agreement "up front" (sorry, for forgetting it)
    on that, I'd like to propose to amend it into,

-----

      Requests for presentation slot are strongly recommended to
      have documentation available to WG members before the meeting
      starts;

      Presentation requests without accompanying documentation
      will have lower precedence in terms of presentation time
      allocation;

-----

    In the last IETF, Bill Fenner gave an presentation on one of
    the issues on the fly, that was pretty good. If we had insisted
    on a written doc at that time, the resolution would have taken
    much longer. So nothing new this time.

-Liming

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 10 Mar 1999 22:46:57 -0800 (PST)

>> to make the request way earlier. My apologies to members of the list

    Spec enclosed. Can also be found at ftp://ftpeng.cisco.com/dino/
    draft-farinacci-bidir-pim-00.txt.

Dino

------------------------------------------------------------------------

Network Working Group                                     Deborah Estrin
Internet Draft                                                   USC/ISI
Expiration Date: August 1999                              Dino Farinacci
                                                           cisco Systems
                                                       February 11, 1999

                 Bi-Directional Shared Trees in PIM-SM
                   <draft-farinacci-bidir-pim-00.txt>

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."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   This proposal extends the PIM-SM [1] forwarding mechanism for
   multicast datagram forwarding. PIM-SM constructs and maintains uni-
   directional shared trees and uni-directional source trees. We show
   how we can extend the elements of operation of sparse-mode PIM to
   support bi-directional shared trees.

1. Introduction

   A uni-directional shared tree is a distribution mechanism for sources
   to send multicast datagrams to receivers joined to the shared tree
   using an arbitrary root node in the network. When using undirectional
   shared trees, all sources' traffic first go to the root of the tree
   so they can be delivered down the distribution tree. As a result,
   there can be unnecessarily long delivery paths to the receivers close
   to the source.

Estrin, Farinacci                                               [Page 1]

Internet Draft      PIM Bi-Directional Shared Trees        February 1999

   When using bi-directional shared trees, data can flow in either
   direction on a branch of the tree. This allows improved data delivery
   to receivers close to the source when the traffic traveling upstream
   to the root node can be "turned around" and forwarded on downstream
   branches [2].

2. Pros and Cons of Bi-Directional Shared Trees

   There are 3 basic advantages of bi-directional shared trees:

   o State is reduced compared to source trees. Each router in the multicast
     routing domain needs only to keep state for the group and not each source
     sending to each group. [2]
   o Short-cut branches can be used when data flows upstream as noted above.
     That is, packets from sources to topologically near-by receivers do not
     have to travel all the way to the root of the shared tree.
   o Bursty sources can send with no or little state in routers.

   There are 3 basic disadvantages of bi-directional shared trees:

   o Since all traffic goes to the root of the tree, there is a traffic
     concentration point at the root node and links leading to it.
   o Traffic always flows to the root node even when it doesn't have to. That
     is, if the root node has a single branch on the tree, it does not take
     part in forwarding traffic but it must receive the traffic because
     downstream nodes don't know the topology of the tree upstream.
   o The path taken between the source and receivers might not travel over
     the shortest path, although it is likely to be a shorter path than via a
     uni-directional shared tree.

3. Modifications to PIM

   A strong goal of this proposal is to make as few changes as possible
   to PIM and multicast forwarding. We also wish to make the changes
   compatible, so a phased (incrementally deployed) transition to bi-
   directional shared tree PIM can be accomplished. Therefore, we use
   (*,G) state to describe bi-directional shared tree (traditionally
   (*,G) has been used to describe uni-directional shared tree state).

   By definition a PIM bi-directional shared tree group may not have any
   (S,G) state stored for the group. There are exceptions when mixing
   non-bidir PIM routers with bidir PIM routers (see later in this
   specification).

   At the same time a router learns the RP for a group, it will know if
   the group is to operate in bi-directional shared tree mode or legacy

Estrin, Farinacci                                               [Page 2]

Internet Draft      PIM Bi-Directional Shared Trees        February 1999

   uni-directional shared tree mode.

4. Modifications to Multicast Forwarding

   There will be modifications to multicast forwarding since bi-
   directional shared tree delivery requires traffic to flow upstream
   (towards the root). This is contrary to RPF forwarding used on uni-
   directional shared trees (packets can only be forwarded away from the
   root node, downstream towards receivers).

5. No Modifications to Multicast Capable Hosts

   This proposal does not require modifications to multicast capable
   hosts. [3]

6. How do Receivers Join to the Bi-directional Shared Tree

   Receiving hosts use IGMP [3] (as they do today) to join multicast
   groups. The attached routers perform the same actions as are done to
   graft branches on the undirectional tree. That is, the designated
   router (DR), on the attached subnet with the receiver, will send a
   PIM Join/Prune message with (*,G) in the Join-List toward the RP for
   the group.

   Routers maintain (*,G) state as defined in the sparse-mode PIM
   specification. [1]

7. How do Sources send on the Bi-directional Shared Tree

   A source host will send a multicast packet by transmitting on it's
   attached interface (as it does today) [3]. The attached parent router
   will initiate the delivery of the multicast packet upstream towards
   the RP. See details later on which router on the attched interface
   becomes the parent router.

   When a packet flows upstream, a receiving router must know that it
   can bypass the RPF check on the (*,G) entry. To accomplish this, we
   introduce a new IP option called the Upstream Multicast Packet (UMP).
   The UMP IP header option is encoded as follows:

Estrin, Farinacci                                               [Page 3]

Internet Draft      PIM Bi-Directional Shared Trees        February 1999

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Option Type  | Option Length |         Reserved              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Upstream Router's IP address                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type value is TBD.

   When a router forwards a multicast packet upstream, it identifies the
   upstream router in the option. Only the indicated upstream router is
   responsible to continue the forwarding of the packet upstream. When a
   router forwards a multicast packet with the UMP option, it will
   multicast the packet on the attached upstream subnet so other routers
   can forward packets down the shared tree if they have (*,G) state, or
   if there are directly attached members, they can receive the packet.

   In all cases, only a single copy of the packet is sent upstream,
   taking advantage of multi-access/multicast capable media where ever
   possible.

8. First-hop LAN

   On the first-hop LAN where the source resides, a special parent
   router election is performed so only one router forwards the packet
   upstream when inserting the UMP option. This is necessary because the
   source host doesn't send multicast packets with the UMP option.

   Each upstream router on a LAN must know if there are other upstream
   routers on the same LAN as the source host so it can determine if it
   should forward the upstream multicast packet or another upstream
   router should.

   So we introduce a Bidir-Capable PIM Hello Option. Only routers that
   support bi-directional shared tree forwarding insert the option on
   each interface PIM is enabled on.

   Each router will advertise it's metric it uses to reach the RP that
   is known for each group range. A router advertises this information
   on every interface except the RPF interface to the respective RP. By
   advertising the RP and metric information tells other routers, that
   the advertiser is a parent router for the source host LAN for the
   respective RP.

   The router with the smallest metric to the RP will be the upstream
   forwarder for the source and will insert the UMP option in the data

Estrin, Farinacci                                               [Page 4]

Internet Draft      PIM Bi-Directional Shared Trees        February 1999

   packet. When metrics are the same, the highest IP addressed router on
   the source's subnet is elected the parent rouer.

   The following Bidir-Capable PIM Hello Option format will be used:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |PIM Ver| Type  | Reserved      |           Checksum            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       OptionType              |         OptionLength          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          RP Address 1                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Metric Preference                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Metric                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               .                               |
       |                               .                               |
       |                               .                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           RP Address N                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Metric Preference                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Metric                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       OptionType = TBD

       OptionLength
           The length of the option payload in bytes. If there are no RP
           addresses advertised, the OptionLength field must be set to 0.

       RP Address
           The IP address of the RP learned via Bootstrap messages.

       Metric Preference
           The metric preference used relative to the metric value. This allows
           more than one unicast routing protocol to be used. The metric
           preference allows you to adminstratively select one protocol versus
           another since the routing protocol metrics may not be comparable.

       Metric
           The metric value learned via the routing protocol for the route the
           RP address matches for.

Estrin, Farinacci                                               [Page 5]

Internet Draft      PIM Bi-Directional Shared Trees        February 1999

9. Multicast Forwarding Rules

   The following steps describe the rules for bi-directional shared tree
   forwarding  in  PIM.  When a router receives a multicast datagram, it
   may arrive on the RPF interface for a (*,G)  entry  or  another  (the
   non-RPF) interface.

   A. When a multicast datagram arrives on the RPF interface:

   A1. A multicast routing table lookup is performed. Only a (*,G) entry can be
       returned (based on our definition that PIM bi-directional shared trees
       groups will not have (S,G) route entries).

       If the entry is not found, the datagram is silently discarded.

   A2. If the entry is found, the datagram is sent out each outgoing
       interface that resides in the outgoing interface list for the (*,G)
       entry. In this situation, the router doesn't care if the (*,G) tree
       state is bi-directional or uni-directional.

   A3. Before replicating the datagram on each outgoing interface, a router
       checks to see if the UMP option is present. If so, it can either remove
       the option or replace the existing address with 0.0.0.0 in the Upstream
       Router IP Address field. This is to indicate to downstream routers the
       packet is not traveling upstream.

   B. When multicast datagram arrives on a non-RPF interface:

   B1. A multicast routing table lookup is performed. Only a (*,G) entry can be
       returned (based on our definition of PIM bi-directional shared trees).

   B2. The router looks at the UMP option. If the option is not present or the
       Upstream Router IP Address is not it's own IP address on the received
       interface, the datagram is silently discarded.

   B3. If the UMP option is not present and the router is directly connected to
       the source of the multicast datagram and is the parent router on the
       interface for the respective RP for the group the source is sending to,
       the parent router inserts the UMP option and follows the steps B4.1
       and B4.2.

   B4. If the UMP option is present and the Upstream Router IP Address field is
       it's own IP address on the received interface, it will forward the
       datagram as follows:

       B4.1 The datagram is sent out each outgoing interface which resides
            in the outgoing interface list for the (*,G) entry except for the
            interface the packet was received on. Before sending out each

Estrin, Farinacci                                               [Page 6]

Internet Draft      PIM Bi-Directional Shared Trees        February 1999

            interface, the router may remove the UMP option from the datagram
            or replace the existing address with 0.0.0.0 in the Upstream Router
            IP Address field.

       B4.2 The datagram is forwarded on the RPF interface for (*,G) by
            replacing the Upstream Router IP Address field in the UMP option
            with the next-hop address of the router that is used to reach
            the RP.

10. Distinguishing Bi-Directional Shared Tree Groups from other Groups

   When routers discover the identity of the RP for a multicast group it
   can determine if the group will operate in bi-directional shared tree
   mode or legacy mode. We modify the Encoded-Group Address fields in
   PIM Bootstrap and Candidate-RP Advertisement messages to include the
   Bidir-bit (see bit B below):

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Addr Family   | Encoding Type |B|   Reserved  |  Mask Len     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Group Multicast Address                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   When the Bidir-bit is set, all PIM routers will follow the forwarding
   rules described in the last section of this specification.

11. Mixing Bi-Directional Capable Routers with Legacy PIM Routers

   It will take time to upgrade all PIM routers in a domain to be bi-
   directional shared tree capable. However, enabling bi-directional
   shared tree routers in an existing network can be easy and simple.
   First, no special attention at the protocol level need to be taken if
   the network is engineered where you can place bidir PIM routers
   strategically near sources. That is, if sources are located on
   sender-only branches (no Joins have traveled up that branch) of the
   bi-directional shared tree, only that branch needs to be upgraded
   with bi-directional shared tree capable routers. All other routers on
   receiver branches forward based on legacy (*,G) uni-directional
   shared tree forwarding rules.

   When the network cannot be engineered to locate bi-directional shared
   tree capable routers on sender-only branches, the following
   transition support can be implemented:

Estrin, Farinacci                                               [Page 7]

Internet Draft      PIM Bi-Directional Shared Trees        February 1999

   o A router will detect if it's upstream neighboring router toward the RP is
     bi-directional shared tree capable or not. We will use the Bidir-Capable
     PIM Hello Option to convey this information.
   o A router that is one-hop downstream (of the RP) from a non-bidir capable
     router will maintain (S,G) state and will be responsible for forwarding
     multicast traffic to the RP by Registering to the RP as follows. The
     router (one-hop downstream from a non-bidir capable router) forwards
     multicast traffic to the RP by Registering to the RP as it would if it
     was a DR (or MBR) in legacy mode. When the data arrives at the RP, it
     can be delivered on the uni-directional shared tree (or any source trees
     that overlap with the shared tree).

   By definition, a bidir capable PIM router will not create (S,G) state
   when it either 1) receives a data packet or 2) receives any PIM
   control packet. However, there is one exception. When a router
   receives a data packet that is to travel upstream (the UMP option is
   present or the router is a parent router directly attached to the
   source) and the upstream neighbor toward the RP is not bidir capable,
   it will create (S,G) state and set the necessary flags indicating
   packets that match the route entry will be Register encapsulated to
   the RP. In this case, the router still doesn't accept join messages
   (and therefore not populate the (S,G) olist) if there are routers
   upstream that are sending (S,G) Joins or Prunes. A router that does
   this transition logic is called a bidir border router.

   If a bidir router creates (S,G) state for a bi-directional group, it
   will not send Join/Prune messages for the entry. If a bidir router
   changes it's RPF neighbor to the RP and the RPF neighbor is bidir
   capable, it will delete it's (S,G) entries.

   A bidir router must do longest match lookups for a group that is in
   bi-directional tree mode.  This handles the case where the RP
   forwards packets down a branch which has a sender and a member on it.
   In this case, a bidir border router should RPF fail for such packets
   since it will use the (S,G) entry rather than the (*,G) entry for the
   forwarding decision.

   If the RP is a bidir capable router and it receives a Register
   message, it will not create (S,G) state. It will forward the data
   encapsulated in the Register message down the shared tree. The RP
   will only send a Register-Stop if there are no members for the group
   (the (*,G) outgoing interface list is empty). An RP will receive a
   Register message in two cases, 1) the DR is a non-bidir capable
   router, or 2) it was sent by a bidir border router.

   If the RP is not bidir capable and it receives a Register from either
   a non-bidir capable DR or a bidir border router, it may trigger a
   Join toward the source. If there are any bidir capable routers on the

Estrin, Farinacci                                               [Page 8]

Internet Draft      PIM Bi-Directional Shared Trees        February 1999

   path, they will not create (S,G) state. In this case, the RP will
   never get data natively and therefore never send Register-Stop
   messages. The data will continue to be delivered via Register
   encapsulation.

   If the DR is not bidir capable and there is a parent router (which is
   bidir capable) colocated on a subnet, the parent router will not
   forward a directly connected source's packet upstream because the DR
   will Register encapsulate the packet. If the DR is bidir capable and
   is not the parent router, it will allow the parent router to forward
   the directly connected source's packet upstream and not Register
   encapsulate the data. If the DR is bidir capable and is the parent
   router, it will follow procedure B3.

   The following shows all possible cases mixing non-bidir (old) and
   bidir capable (new) routers. The notation for "new-dr" means the
   router is bidir capable, is the DR for the source's LAN and is the
   parent router. The notation for "old-dr" means the DR is a non-bidir
   capable router and there may or may not be bidir capable routers on
   the source's LAN.

    (1)      (2)      (3)      (4)      (5)      (6)      (7)      (8)
   old-rp   old-rp   old-rp   old-rp   new-rp   new-rp   new-rp   new-rp
   old      old      new      new      new      new      old      old
   old-dr   new-dr   old-dr   new-dr   new-dr   old-dr   new-dr   old-dr

   (1) This case is legacy mode.
   (2) The bidir DR sends Registers and does not forward packets with the UMP
       option.
   (3) The non-bidir DR sends Registers, the non-bidir RP may send joins but
       the bidir transit router will ignore them. This case, Register
       encapsulation gets data to the RP.
   (4) The bidir DR forwards multicast packet with UMP option upstream. The
       bidir transmit router sends Register to non-bidir RP.
   (5) This case is bi-directional shared tree mode.
   (6) The non-bidir DR will Register to the bidir RP. The bidir RP will not
       send Joins back to the source. It only Register-Stops if there are no
       members. The bidir transit router is not involved in forwarding
       multicast packets.
   (7) The bidir DR will Register to the bibir RP. The bidir RP will not send
       Joins back to the source. It only Register-Stops if there are no
       members. The non-bidir transit router is not involved in forwarding
       multicast packets.
   (8) The non-bidir DR will Register to the bidir RP. The bidir RP will not
       send Joins back to the source. It only Register-Stops if there are no
       members. The non-bidir transit router is not involved in forwarding
       multicast packets.

Estrin, Farinacci                                               [Page 9]

Internet Draft      PIM Bi-Directional Shared Trees        February 1999

12. Security Considerations

   When IPsec [4] is used on a multicast datagram, the UMP IP option
   will not be part of the encrypted payload. This is justified by
   allowing routers to be performant when forwarding packets upstream.

Estrin, Farinacci                                              [Page 10]

Internet Draft      PIM Bi-Directional Shared Trees        February 1999

13. Acknowledgments

   The authors would like to acknowledge Rusty Eddy (USC), Liming Wei
   (cisco), and Tony Speakman (cisco) for their comments and
   contributions to this specification.

14. Author Information

   Deborah Estrin
   ISI/USC
   [email-masked]

   Dino Farinacci
   cisco Systems, Inc.
   [email-masked]

15. References

   [1] Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM-
       SM): Protocol Specification", RFC 2362, June 1998.
   [2] A.J. Ballardie, P.F. Francis, and J.Crowcroft. Core based trees.
       In Proceedings of the ACM SIGCOMM, San Francisco, 1993.
   [3] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
       1112, August 1989.
   [4] Atkinson, R., "Security Architecture for the Internet Protocol",
       RFC 1825, August 1995.

Estrin, Farinacci                                              [Page 11]

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Thu, 11 Mar 1999 19:12:33 -0500

Dino Farinacci wrote:

>      concentration point at the root node
>

If the root is a member of the group, then traffic should flow towards it, just
like to any other member (ie it should not be considered traffic concentration at
the root node then),  agree?

thanks,
cyl

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 11 Mar 1999 16:22:49 -0800 (PST)

>> the root node then),  agree?

    Yes, but when it's not traffic still goes there. 

Dino

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Fri, 12 Mar 1999 11:12:08 -0500

>     Yes, but when it's not traffic still goes there.

If  you look at the traffic flow in the  bi-directional tree itself,  the same amount
of traffic is flowing towards the root as towards members. If a root can't cope,
members will have problems too.

So it's not accurate to say that there is a traffic concentration point at the root
node (the first bullet below).
The second bullet is only an issue if the root node is  not a member, and it makes
sense for a member to be the root.
i agree with the 3rd bullet.

thanks,
cyl