[c-nsp] fast multicast convergence

adam vitkovsky adam.vitkovsky at swan.sk
Mon Jun 25 09:14:11 EDT 2012


Yes please what I meant was router wouldn't need to wait for IGP to compute
the RPF interface -as that would already be in place as LFA -so the router
can send Join out that interface immediately

Since you mentioned it already -are there any plans for sort of IP FRR for
m-cast please?
-where each node would pre-compute a backup Incoming Interface for every
primary IIF and backup OIL on each m-cast state
-but this would require link-state protocol in place of PIM

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


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



More information about the cisco-nsp mailing list