Subject: RE: The Assert Mechanism

From: "Shekhar, Ravi" <[email-masked]>
Date: Thu, 21 Oct 1999 11:42:28 -0400

> This is done for the case when the DR is a downstream router. 
> In this case it
> creates a (*,G) state because of the IGMP report but it cannot add the
> interface to the olist as it is the (*,G) incoming interface. 
> However it still
> has to generate joins.

  But the real question is that is it required for DR to inform RPF 
  every 30 seconds "periodically"? Shouldnt there be a mechanism to do it 
  only once when membership comes up (perhaps by forcing a phony assert 
  on the LAN). And from then on, since assert-winner is running IGMP, it 
  will know when local group membership is withdrawn and accordingly prune 
  the oif.
     The only good explanation I could find for doing it periodically is
  that RPF nbr is _not_ running IGMP and hence doesnt know when to withdraw
  <*, G> join. Are there any other reasons?

  Anyways, I do not have a strong opinion about doing it either way and
  supporting both might be good. Mohit has already pointed out couple of
  advantages of doing it the way he suggested. I would like to add couple
  of observations about the other way (i.e. DR periodically sending join
  to the assert winner):

  Disadvantages:
   1) Extra J/P messages.

  Advantages:

   1) It requires running IGMP only on DR. This could become a useful 
      feature, especially now that we have DR priority option and DR can
      be more deterministically pointed out on the LAN. Also it might be 
      another point in favor of SM as opposed to dense-mode protocols that 
      typically require IGMP to run on all the routers on the LAN with
hosts.

   2) In the example which Mohit pointed out, consider these two sequence of

      events:
        a) if C was never forwarding data, B would have been responsible 
           for forwarding data for local members.
        b) - Next assume C was forwarding the data due to join from D.
           - Local member comes up and C wins the assert. B does not forward

             data for local memebers. C takes on the responsibility.
           - D withdraws its join but C still continues to forward data for
               local members.

      Now in both these cases, the end state of the network is same (local
group 
      member on the LAN and no other joins). But the end result is
different.
      In one case B is forwarding data, and in other case C is forwarding
data.
      This is not wrong, but it could add complexity while debugging the
network.
      Forwarder on the LAN depends on the history of the network state as 
      opposed to just current state. 
      
  Please feel free to add to/correct the list. Thanks.

  - Ravi Shekhar.

---

From: Dave Thaler <[email-masked]>
Date: Thu, 21 Oct 1999 13:05:14 -0700 (PDT)

>       typically require IGMP to run on all the routers on the LAN with hosts.

That sounds like a bad idea to me.  If all routers on the LAN aren't
running IGMP, and you're turning on/off IGMP whenever you become/stop
being a DR, that sounds like a convergence nightmare.  

You really want to run IGMP on all routers so that all routers have
a consistent view of which groups have directly-connected members.

-Dave