[c-nsp] fast multicast convergence

[adam vitkovsky]

Thank you very much Oli

> it will send a join after a new RPF intf. has been identified for a given
source.
I see, so if I'll run IP FRR/LFA it will be almost immediately right please?

>IIRC, there is/was some interdependency with pim query-interval and link-up
I see, so I'll definitely need to make sure my IGP adjacency to come up
before the PIM neighborship is established on a given link
I don't really see any advantage in tuning the PIM query-interval(which
affects hellos) on the p2p links between routers because when the link goes
down the PIM neighbor is removed immediately
 
I guess the longest delay is introduced when the links at router connected
to source fails
-as the routing change needs to be propagated via IGP -than it all boils
down to how well is the IGP tuned for fast convergence


adam
-----Original Message-----
From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com] 
Sent: Monday, June 25, 2012 11:32 AM
To: adam vitkovsky; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] fast multicast convergence

 
> Consider this PIM-SM scenario
> 
> Designated Router has two paths towards the Source and RPF has chosen 
> one
> 
> The m-cast traffic will flow via the RPF interface down to the 
> interested receivers as long as the DR will be sending the periodic 
> Join messages up the Source-Tree
> 
> Now when the RPF interface goes down and after the IGP converges
> 
> -will the DR send triggered Join message via the new RPF interface 
> towards the Source immediately after it learns the alternate path 
> towards the Source please?
> 
> -or the DR will simply wait till the next scheduled Join period please?

it will send a join after a new RPF intf. has been identified for a given
source. In earlier IOS releases, there was a backoff after the first change
in the RIB, RPF process started 500 msec after first change in the RIB and
went through all S,G/*,G to update RPF intf. Now this is event-driven.
 
> I'm asking because the PIM-SM convergence is based on how fast can be 
> the Join message propagated from the DR to Source over the backup path 
> -creating the SPT state in all routers it passes through
> 
> In MoFRR this is preprogramed by DR sending Join also via the Backup 
> path (in XR it also enables triggered Joins)

true.
 
> I don't see any specific knob to control the pace at which the 
> periodic join msgs are sent

you can configure the RPF backoff mentioned earlier (ip multicast rpf
backoff).

> Or would also this be affected by the query-interval please?

IIRC, there is/was some interdependency with pim query-interval and link-up
to avoid a blackhole between IGP coming up and PIM establishing a
neighbourship.. possibly something to check in your specific environment..

	oli