Subject: Re: PIM-SMv2 functional clarification - join latency

From: Manolo Sola <[email-masked]>
Date: Mon, 13 Sep 1999 23:05:08 +0900

Narayanan Vidya-CVN065 wrote:
> 
> > Here is what they said in English:
> >
> >  1) If the RP has lost (S,G) state (due to any number of
> > reasons including
> >     operator clearing state), the RP has to wait until the next
> >     (null) register to set up (S,G) state, and join again; (Dave)
> >
> 
> Yes, I agree with this in the event of no (S,G) state in the RP.
> 
> >  2) If the RP has not yet lost the (S,G) state, it should
> > trigger a join
> >     to the source when the first member shows up. (Ravi)
> >
> 
> Here is where I am having a problem relating this to the RFC. The RFC only
> seems to talk about (*,G) joins. Isn't it an (S,G) join that needs to go
> from the RP to the source?

With respect to the method explained in Ravi's email, I think that it
only can be applied to intermediate routers in the RP shared tree. As
(*,G) Join/Prune messages are addressed to an RP, when they arrive to
the RP they are not forwarded anymore.

What I guess it may happen according to the spec is the following: if
there is (S,G)SPT-bit state with a null list of oif at the RP, and an
(S,G) [addressed to the RP or S] or (*,G) [addressed to the RP] Join
arrives to the RP, a new interface will also be added to the so far null
list of (S,G)SPT-bit oif, and this will trigger the source specific join
process.

> thanks,
> Vidya

-- 
							Manolo Sola
							[email-masked]