Subject: RE: The Assert Mechanism

From: "Shekhar, Ravi" <[email-masked]>
Date: Wed, 20 Oct 1999 20:00:06 -0400

> consider the following topology
> 
>                                                     
>                             +---+               
>                             | A |               
>                             +---+               
>                               .                  
>                               .                  
>                               .                  
>             +-+-+                           +-+-+
>             | B |                           | C |
>             +-+-+                           +-+-+            
>               |                               |              
> ----------+---------------------------------------+----------
>           |                                       | 
>           R1                                    +---+
>                                                 | D |
>                                                 +-+-+
>                                                   | 
>                                                   R2
> 
> A is the RP
> B is the DR on the LAN
> C is the RPF towards A for D
> 
> now consider the following sequence of events...
> R1 joins a group G
> B creates (*,G) state and forwards the join upstream towards A
> R2 joins the group G
> D creates (*,G) state and sends the join on the LAN with C as 
> the target
> C create (*,G) state and forwards the join upstream towards A
> ---
> a source starts sending data
> an assert elections takes place on the LAN
> C emerges the winner of the assert election!
> B deletes the oif and sends a prune upstream towards A
> ---
> R2 leaves the group G
> D sends a prune to C
> C keeps sending data on the LAN for R1
> ---
> C dies
> R1 stops receiving any data sent for the group G!!!
> 
> whew!
> 
> so my question is ...
> "how does the assert loser (B) know that it has to now start 
>  forwarding data on the LAN for local receivers?"
> i looked at the spec and don't think it covers this case.
> but i may be wrong.
> 
> i looked at rusty's notes on the web (thanx rusty :) and found 
> that he had noted the same problem but dunno if it was ever 
> discussed on the list.  this is what he has to say...
> 
> "If a router is the DR on an interface that belongs to a (*, G)'s
> 	downstream list and that interface has local recievers (igmp), 
> 	some implementation dependent method must be used to ensure
> 	the interface (and joins to the RP) are re-instantiated when
> 	the assert winner quits forwarding traffic, if a no facility
> 	is added to the protocol to over come this. 
> 
> 	One method could be maintaining a timer on the loosing oif of
> 	the DR with local recievers.  another method could be a hello
> 	option that the assert winner would add stating that it is
> 	actively forwarding (s,g) or (*,g) for a local reciever."
> 
> another good solution would be to require that when a router 
> loses a (*,G)
> or (S,G) assert election for an interface on which it is the 
> DR and for
> which there are local receivers, the router associate that 
> (*,G) or (S,G)
> entry with the assert winning neighbor.  this list is also 
> updated when
> IGMP declares that all local members for a group have left.
> 
> when a neighbor dies and the router is the DR on that 
> interface, the router 
> should go ahead and add the interface to all tree entries in 
> this list for
> that neighbor.

  Although this mechanism will work if C dies, but this still leaves 
  the hole as to what happens if C doesnt die AND D stops sending
  <*, G> joins to C. After 210 seconds, C will remove the 
  oif and not forward any data (unless the implementation at C makes
  LastHopRouter to take on the responsibility of local group membership
  even after it doesnt have any downstream routers sending joins to it.
  But all implementations may not do that).

  Hence it is better if B keeps joining every 210 seconds if it has 
  IGMP membership. This makes the situation look like as if B has 
  been receiving joins from some downstream router every 210 seconds.

  Regards.
  - Ravi Shekhar.

---

From: Mani M <[email-masked]>
Date: Thu, 21 Oct 1999 10:19:39 +0530

Hi Mohit / ALL

You have prescribed two solutions for the problem

(i) Maintaining a timer in the Assert looser's oif .
My question is how does this timer help in forwarding the packets to R1 and R2 . that is how does B know of C's death. how does the timer come into picture ?
if we maintain a arbitrary timer value and evry time it expires assert has to take place and it'll increase the network overhead. if we maintain a large timer value data loss between 
C's death and timer expiry may be large

(ii) In the second method of maintaing an option in the hello message ther is chance for data loss.

(iii) In the third method you've told "another good solution would be to require that when a router loses a (*,G)or (S,G) assert election for an interface on which it is the DR and for which there are local receivers, the router associate that (*,G) or (S,G)entry with the assert winning neighbor"
What is meant by the word associate ?

Thanks
Mani

---

From: "Mohit Talwar (Exchange)" <[email-masked]>
Date: Thu, 21 Oct 1999 10:30:48 -0700

hi ardas,

> Solution-2: For this we can have a timer, assert-oif-timer on
> both the winner and the loser guy. The winner guy assumes the
> DR role for the group G for the whole assert-period. It means
> even if C receives prune from D, C will not remove the oif
> because of the local member R1.
> Assert-oif-timer expires after the assert-period on both B and C,
> after which C will stop its DR role for G and therefore remove the
> oif, and B will resume its role and add the oif.

i don't see why u need the assert-oif-timer. the DR (B) doesn't 
HAVE TO take over responsibility for local receivers necesarily.
it should be happy as long as there is someone (C) doing it.  it
needs to take over only when that someone (C) stops doing it (dies).

> I just wanted to stress another version of the problem, where
>    - B is the DR and has the (*,G) entry, and
>    - C has an (S,G) entry (i.e. R2 takes a different 
>      path for joining to Shared-Tree)
> 
> In this case, after assert B will create (S,G)RPT entry with 
> oif removed. Note that the solutions can get modified to take 
> care of these problems as well, as follows:
> 
> - (S,G)RPT should keep track of the winner-neighbor on the lost-oif.
  
that is what i had in mind too when i said that the DR keeps track 
of (*,g) and ***(S,G)*** entries.  thanx for making this point.

i think i have exhausted my quota of mails on this issue.  
so i'll stop now :)
mohit.

---

From: "Shekhar, Ravi" <[email-masked]>
Date: Thu, 21 Oct 1999 14:48:26 -0400

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

  Certainly thats true. If a router can be a potential DR, its better to
  run IGMP on it.
  When I stated that, I was thinking of possiblity of having PIMSM routers 
  which are ineligible to be DR (like OSPF allows for routers with Router 
  Priority set to 0). Such routers need not run IGMP.

  - Ravi Shekhar.