Mailing List Archive: Cisco: NSP

fast multicast convergence

Index | Next | Previous | View Threaded

adam.vitkovsky at swan

Jun 25, 2012, 2:09 AM

Post #1 of 5 (433 views)
Permalink

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?

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)

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

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

Thank you

adam

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

oboehmer at cisco

Jun 25, 2012, 2:31 AM

Post #2 of 5 (417 views)
Permalink

Re: fast multicast convergence [In reply to]

> 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

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

adam.vitkovsky at swan

Jun 25, 2012, 4:11 AM

Post #3 of 5 (414 views)
Permalink

Re: fast multicast convergence [In reply to]

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]
Sent: Monday, June 25, 2012 11:32 AM
To: adam vitkovsky; cisco-nsp [at] puck
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

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

oboehmer at cisco

Jun 25, 2012, 5:32 AM

Post #4 of 5 (414 views)
Permalink

Re: fast multicast convergence [In reply to]

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

adam.vitkovsky at swan

Jun 25, 2012, 6:14 AM

Post #5 of 5 (411 views)
Permalink

Re: fast multicast convergence [In reply to]

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]
Sent: Monday, June 25, 2012 2:32 PM
To: adam vitkovsky; cisco-nsp [at] puck
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

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads