Subject: Re: Assert RPF

From: [email-masked] (Billy Ng)
Date: Tue, 8 Sep 1998 15:50:48 -0400

Rusty,

> From [email-masked] Tue Sep  8 15:01:01 1998
> 
> Hi Billy,
> 
> > > Billy Ng states:
> > > > 
> 
> > > for example
> > > 
> > > 	s
> > > 	|    
> > > 	R4 /----RP
> > > 	| / 	|
> > > 	R1	R2
> > >         |	|
> > > 	+--+----+ (LAN)
> > > 	   |
> > > 	   R3 -- r
> > > 
> 
> > > now suppose:
> > > 
> > > 	R1 has (*,g) and (s,g)
> > > 	R2 has (*,g)
> > > 
> 
> > >  2. R1 forwards a dup onto the lan, R2 creates an assert with rpt=1.
> > > R1 finds it's (*,g) entry and:
> > > 
> 
> > >   b. the lan is in both the (s,g) and (*,g) entries of R1.  in this
> > > case R1 creates an assert with rpt=1 and the election process for
> > > (*,g) entries takes place amoung R1 and R2.  in which case either
> > > could be the winner.  if R1 is the winner everything is ok.  however, 
> > > if R2 wins the assert for (*,G), once it forwards a s,g dup onto the
> > > lan, R1 will send an assert with rpt=0 and will win the assert for
> > 
> > Right here.  Since R2 has just won the election, R1 will no longer has
> > this outgoing interface for this (*,G) entry and its (S,G) entry until
> > the assert times out from downstream.  In this case, the forwarder is
> > R2 which should have been less preferred.  Is this correct?
> > 
> 
> i don't think i understand the: 'and its (S,G)..' and part
> about the downstream assert timer.  it sounds like you are
> saying that R1's (s,g) will not have the lan on it's ds?
> 

The forwarding of (*,G) means for all sources that share this G
including S and therefore the outgoing for (S,G) would also be deleted 
as a result.

However, you are correct that since the downstream router does an
exact match for the entry, the affected (*,G) entry at the downstream
will send a new join toward the assert winner, but the unaffected (S,G) 
entry at the downsteam continues to send join toward the old RPF neighbor
which in effect grafts back the upstream outgoing interface for the (S,G)
entry at the upstream.  However, this can cause a delay of up to the
join interval of the downstream (S,G) join and data will be lost for
that amount of time.
 
> to follow through on this scenario: after R2 has won the (*,G)
> assert (rpt=1).  we will have the following state (L is the lan):
> 
> 	R1: (*,g)       ds= -L
> 	    (s,g).spt=1 ds= +L
> 
> 	R2: (*,g)       ds= +L
> 	    (s,g).rpt=1 ds= -L
> 
> 	R3: (*,g) up = R2
> 	    (s,g) up = R1
> 
> 
> as long as some downstream stream neighbor (or a local
> receiver where R1 has spt switched) on L continues to cause
> the (s,g) state, R1 will maintain L in the ds list. do
> you see a problem with the above state?  or were you making a
> different point?
> 

Again the outgoing interface of the (S,G) is gone until the next join
from downstream.

> > So my question is that if we do not ignore the (S,G) entry in the first
> > place, then the problem should be solved, unless there is another reason
> > for ignoring it.
> > 
> > --Billy
> > 
> 
> 
> again, i may very well have misunderstood, but it seems to me
> the spec as it is will result in the appropriate state above,
> so i still don't think anything is broken.  

So the key point is whether the outgoing interface be deleted for the
(S,G) entry.  If we can say only delete the outgoing interface for (*,G)
except for source S for the forwarding cache, then it will work as you 
describe.

> however, your
> suggestion may still be valid and save some dups on the lan.
> the question is whether this would break anything.
> 
> - rusty
> 
> 

Right, so far I don't see anything that would break.

Thanks,

--Billy

---

From: [email-masked]
Date: Wed, 9 Sep 1998 11:40:56 -0700 (PDT)

> including S and therefore the outgoing for (S,G) would also be deleted 

rfc2362 3.5.2) Recieving Asserts:

 Recieving Asserts on an entry's outgoing interface:

 2 ...
	When the deletion occurs
        for a (*,G) or (*,*,RP) entry , the interface is also deleted
        from any associated (S,G)RPT-bit or (*,G) entries, respectively.
        The Entry-timer for the affected entries is restarted.

since the (s, g) in R1 has the spt flag set, the lan is never removed
from the R1's (s,g) entry.  (note the state of R2 below)

> > assert (rpt=1).  we will have the following state (L is the lan):

i hope this clarifies things...

> except for source S for the forwarding cache, then it will work as you 

correct, and i think the spec provides for this with the distinction
of the rpt bit.

take care,

- rusty