Subject: RE: The Assert Mechanism

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

> -----Original Message-----
> From: helmy [mailto:[email-masked]]
> 
> On Wed, 20 Oct 1999, Isidor Kouvelas wrote:
> 
> > In message <[email-masked]>,
> > Liming Wei writes:
> > >> From: "Mohit Talwar (Exchange)" <[email-masked]>
> > >> 
> > >> hi all,   
> > >>             
> > >> 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.
> > >
> > >When C dies, D's unicast path will switch to point to B. D should
> > >join B and forwarding should resume.
> > 
> > D has already left the group...
> > 
> > I
> > 
> B will be re-elected DR and will get the joins from R1 and 
> will send joins to the RP.

but B was never voted out of office :)
or are u saying that everytime a neighbor dies, the DR 
should reevaluate all local group membersips.

but instead of reevaluating ALL local group memberships, the
DR can associate with each neighbor, a set of (*,G) and (S,G)
entries for which there are local group members and for which
it had lost the assert to that neighbor.  so when a neighbor
dies the DR need consider only these entries.  by keeping this
extra state u can reduce processing cost and avoid triggering
unnecessary asserts.

thanx,
mohit.

---

From: helmy <[email-masked]>
Date: Thu, 21 Oct 1999 00:37:16 -0700 (PDT)

> but B was never voted out of office :)

For *,G it has,... by the Assert, 
and my email was in that regard, that B should become the DR again for *,G
on that LAN. That's the natural thing to do in my opinion, which I thought
the spec already did using timers.