>
> > 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
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
