Subject: RE: PIM-SM: data loss after assert?

From: "Mohit Talwar (Exchange)" <[email-masked]>
Date: Wed, 25 Aug 1999 18:57:39 -0700

thread long dead, but still...

question follows at the end

> -----Original Message-----
> From: Ahmed A-G Helmy [mailto:[email-masked]]
> Sent: Friday, March 26, 1999 2:54 PM
> To: Ardas Cilingiroglu
> Cc: [email-masked]
> Subject: Re: PIM-SM: data loss after assert?
> 
> 
> > > >               (*,G)       (S,G)
> > > >                RT1         RT3
> > > >                 |           |
> > > >            -----+-----------+------
> > > >                 |           |
> > > >                RT2         RT4
> > > >               (*,G)       (S,G)
> > > > 
> > > > Consider the following scenario:
> > > > 
> > > >   - Assert happens between RT1 and RT3.
> > > >     This creates (S,G)RPT state at RT1.
> > > >     According to spec, this creates no change for RT2, 
> > > >     RT3 and RT4.
> > > > 
> > > >   - Immediately after this, oif of (S,G) at RT3 is removed
> > > >     (either pruned or timed out).
> > > 
> > > how is that oif removed... if pruned then RT2 should 
> > > override using a join... this has nothing to do with 
> > > asserts per se I think... u cannot 
> > > prune a LAN with receivers downstream..
> > 
> > You are right about the pruned case (I mistakenly thought that no
> > overrides will happen because (*,G) and (S,G) have different RPFs). 
> > How about oif at RT3 timing out, how will that case be handled?
> 
> ok... S,G timer is refreshed by data packets, ... if S,G 
> entry is idle (i.e. not forwarding packets), then the S,G cache 
> will not be active and S,G in this case should not participate 
> in the assert process (as per the spec).
>
> if you're talking about the oif timer per se, that gets refreshed 
> by the Joins that are sent to the assert winner (have to 
> check the latest spec for that).
> 
> > 
> > > all downstream routers should have the assert winner as 
> > > their RPF nbr for the S,G..
> > 
> > Are you saying that RT2 should create an (S,G) state with 
> > RPF pointing to RT3? In this case RT2 joins to the SPT tree 
> > (even when all receivers below RT4 are gone), 
> > and receivers below RT2 are in a sub-optimal path both to
> > RP and to S (which could be as bad as the sum of shortest 
> > paths to S and RP). 
>
> yes,.. if one downstream member joins to the spt, it may force other 
> members to get packets thru spt... however, after the assert 
> timer times out in RT3, it will go back to its original RPF which 
> is RT1 and back to shared tree... hope I didn't miss ur point,

ahmed, i don't think u mean 
"yes, RT2 should create an (S,G) state..."
but 
"yes, RT2 will get data thru SPT..."

am i right?
cause according to the spec,
downstream routers (such as RT2) will ignore the assert message
if it does not match the entry exactly. 

so the assert from RT3 will be ignored by RT2
since the assert will have the RPT bit set
and RT2 does not have an (S,G) entry.

while i am at it, there's another question i have

according to the spec...
3.5.1 Sending Asserts
	.
	.
	.
      1 Do unicast routing table lookup on source address from data
        packet, and send assert on interface "I" for source address in
        data packet; include metric preference of routing protocol and
        metric from routing table lookup.

why should the assert include the metric for the source
and not 
RP if the matching entry is (*,G) or (*,*,RP)
S  if the matching entry is (S,G)  

or is this what the spec intended?

thanx much,
mohit.