Subject: [pim] New Version Notification for draft-liu-pim-single-stream-multicast-frr-01

From: Liu Hui <[email-masked]>
Date: Thu, 21 Oct 2010 09:47:39 +0800

Hi WG,

We upload the multicast frr draft to version -01, with more detailed desciption for the single stream multicast frr (SMFRR) method. 

http://tools.ietf.org/id/draft-liu-pim-single-stream-multicast-frr-01.txt

SMFRR uses PIM dual join to setup primary and backup paths/trees.  Compared to the previous dual join FRR schemes, it does not forward multicast stream on backup path in normal conditions, which could be thought of as 1:1 protection for IP multicast stream.   

The major point lies in: Extension of PIM protocol is required  to identify backup join messages, and fault notification is required to open backup path multicast forwarding . 

We welcome your comments and discussions on it,

Thanks,
Liu Hui

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 22 Oct 2010 18:44:05 -0400

Hi Liu,

Current implementation of PIM dual join (MFRR) is based on following:

1. Sub 50ms convergence as multicast stream has been pre-delivered on the backup interface in advance and recovery time is de facto equal to failure detection time, triggered by either LOS, BFD, RIB notification (RPF interface change) or some local decision (no traffic from particular multicast stream is seen on a primary interface for a pre-defined amount of time)+ local switchover.

2. No changes to existing (very widely deployed) PIM implementation.

So far my conclusion:

Benefit of not sending traffic on backup path is very doubtful:
a. You'd still need to reserve networks resources in case primary breaks.
b. By not sending traffic down the secondary path you loose ability to  quickly recover (which is absolutely critical) as it is control plane based.

Regards,
Jeff  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Liu Hui
Sent: Wednesday, October 20, 2010 18:48
To: [email-masked]
Subject: [pim] New Version Notification for draft-liu-pim-single-stream-multicast-frr-01

Hi WG,

Thanks,
Liu Hui

_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: Liu Hui <[email-masked]>
Date: Mon, 25 Oct 2010 15:02:15 +0800

Hi Jeff,

Thanks for your insightful comments.

You are right that MFRR is fast by preinjecting backup stream. But it's
precious for complete copying of the service streams, which can not meet the
requirements of all application scenarios.  And this is why we manage to
introduce this SMFRR solution.

Single stream indeed needs resources to maintain backup path. But the
purpose of this consumption is to enable fast switching, and it's low
compared to the processing of duplicate multicast stream. 

Its switching speed could be further shortened by making fault notification
in data plane, and is expected to meet the practical requirement for
ordinary multicast topologies.

Thanks,
Liu Hui

> From: Jeff Tantsura [mailto:[email-masked]] 
> Sent: Saturday, October 23, 2010 6:44 AM
> To: Liu Hui; [email-masked]
> Subject: RE: [pim] New Version Notification for 
> draft-liu-pim-single-stream-multicast-frr-01
> 
> Hi Liu,
> 
> 1. Sub 50ms convergence as multicast stream has been 
> pre-delivered on the backup interface in advance and recovery 
> time is de facto equal to failure detection time, triggered 
> by either LOS, BFD, RIB notification (RPF interface change) 
> or some local decision (no traffic from particular multicast 
> stream is seen on a primary interface for a pre-defined 
> amount of time)+ local switchover.
> 
> b. By not sending traffic down the secondary path you loose 
> ability to  quickly recover (which is absolutely critical) as 
> it is control plane based.
> 
> 
> Regards,
> Jeff  
> 
> Subject: [pim] New Version Notification for 
> draft-liu-pim-single-stream-multicast-frr-01
> 
> Hi WG,
> 
> We upload the multicast frr draft to version -01, with more 
> detailed desciption for the single stream multicast frr 
> (SMFRR) method. 
> 
> SMFRR uses PIM dual join to setup primary and backup 
> paths/trees.  Compared to the previous dual join FRR schemes, 
> it does not forward multicast stream on backup path in normal 
> conditions, which could be thought of as 1:1 protection for 
> IP multicast stream.   
> 
> The major point lies in: Extension of PIM protocol is 
> required  to identify backup join messages, and fault 
> notification is required to open backup path multicast forwarding . 
>