[c-nsp] fast multicast convergence

[Oliver Boehmer (oboehmer)]

> 
> > 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?

well, no, IP-FRR/LFA will not protect multicast traffic (at least not yet), RPF interface update needs to follow "regular" IGP convergence, so in sub-second (rather than 50 msec or so).  If you need FRR-type of convergence for Mcast, you need MoFRR or p2mp-RSVP-TE with TR-FRR.


> >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

actually not:  The problem is (or better was, I think we fixed it) that the first PIM hello could get dropped following a link-up as the neighbour might not have been ready. Then we needed to wait for the query-interval to pass to send the next hello. But by then IGP was alrady up and has converged, so the RPF interface was changed, but we couldn't send a PIM-Join over the new interface as PIM hasn't come up yet. That was the issue, if I got that right..

> 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

ack, the problem above is only for the up event. Down-event is handled by the interface (or by IGP), but IOS-XR also enables BFD for PIM. 

> 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

well, I guess this is true for all link failures in between source and dest, or why do you point to the first-hop router?

	oli