Subject: The Assert Mechanism

From: "Mohit Talwar (Exchange)" <[email-masked]>
Date: Wed, 20 Oct 1999 16:14:04 -0700

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.

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.

thanx,
mohit.

---

From: Liming Wei <[email-masked]>
Date: Wed, 20 Oct 1999 19:04:39 -0700 (PDT)

> From: "Mohit Talwar (Exchange)" <[email-masked]>
> 
> hi all,   
>             

When C dies, D's unicast path will switch to point to B. D should
join B and forwarding should resume.

-Liming

---

From: Isidor Kouvelas <[email-masked]>
Date: Wed, 20 Oct 1999 20:16:41 -0700

>join B and forwarding should resume.

D has already left the group...

I

---

From: helmy <[email-masked]>
Date: Wed, 20 Oct 1999 23:46:49 -0700 (PDT)

> D has already left the group...
B will be re-elected DR and will get the joins from R1 and will send joins
to the RP.

---

From: Ardas Cilingiroglu <[email-masked]>
Date: Thu, 21 Oct 1999 10:53:56 -0400

Hi,

I can think of two solutions that will take care of 2 different problems:

Problem-1: C dies.

Solution-1: For a solution on this I agree with Mohit that, the assert-loser
oif (in case of a DR with local-receivers) can keep track of the neighbor
that he lost assert to, and in case that neighbor dies he can remove the assert

state.

Problem-2: R2 leaves membership and oif on C gets pruned.

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.

thanks,
Ardas

---

From: Ardas Cilingiroglu <[email-masked]>
Date: Thu, 21 Oct 1999 11:55:42 -0400

Hi,

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.
- By using assert-oif-timers, C should assume the role of DRship
for (S,G) and B should stop acting like DR for (S,G) for assert-period.