Subject: [pim] why PIM DR auto-switchover is more desired than VRRP master switchover in the case of uplink failure?

From: xuxiaohu 41208 <[email-masked]>
Date: Tue, 23 Mar 2010 23:37:57 -0700

Hi all,

After my presentation of draft-xu-pim-drpriority-auto-adjustment on the PIM session, somebody (sorry I forgot your name!)argued that PIM DR auto-switchover doesn't need to be specified in a WG informational doc since the similar approach of VRRP (i.e., the VRRP master auto-switchover) is not described in the VRRP specification. 

That seems reasonable. However, I realized later that PIM DR auto-switchover is more desired than VRRP master switchover in the event of uplink failure. The reason is: for VRRP, the VRRP master can still hold its master role even throught it loses the connectivity to the outside network. As such, upon receiving a packet from a given host on the LAN, the VRRP master could respond with an ICMP redirection message to the host due to a configur
ed floating route on it, the host in turn will change the nexthop for that destination address to the VRRP Backup router's real address. In other words, the upstream link tracking mechanism is not a much desired feature for VRRP. As for PIM, the PIM DR could also use that floating route for multicast tree rebuilding when its uplink becomes down. However, once the uplink of the PIM DR is recovered from down to up, the multicast forwarding wil
l be interrupted absolutely till the multicast tree rebuilding is completed sucessfully. In contrast, the multicast forwarding interruption due to the multicast tree rebuilding caused by the uplink recovery event will not happen in our first solution. IMO, non-interruption forwarding during the RPF route optimization from the second-best to the best (e.g., caused by the uplink recovery event) is a much desired feature for improving the users
' QoE of IPTV service.

Comments?

Best regards,

Xiaohu

---

From: ycai <[email-masked]>
Date: Thu, 25 Mar 2010 00:27:39 -0700

Xiaohu,

My main issue is that I don't see a strong reason why one would want to run
PIM on these "routers", namely R1 and R2, in the first place.  IGMP proxy as
documented in RFC4605 is a better alternative.  And I will be much more
supportive if the draft suggests similar enhancement for IGMP proxy.

On 3/23/10 11:37 PM, "xuxiaohu 41208" <[email-masked]> wrote:

> Hi all,
> 
> After my presentation of draft-xu-pim-drpriority-auto-adjustment on the PIM
> session, somebody (sorry I forgot your name!)argued that PIM DR
> auto-switchover doesn't need to be specified in a WG informational doc since
> the similar approach of VRRP (i.e., the VRRP master auto-switchover) is not
> described in the VRRP specification.
> 
> That seems reasonable. However, I realized later that PIM DR auto-switchover
> is more desired than VRRP master switchover in the event of uplink failure.
> The reason is: for VRRP, the VRRP master can still hold its master role even
> throught it loses the connectivity to the outside network. As such, upon
> receiving a packet from a given host on the LAN, the VRRP master could respond
> with an ICMP redirection message to the host due to a configur
> ed floating route on it, the host in turn will change the nexthop for that
> destination address to the VRRP Backup router's real address. In other words,
> the upstream link tracking mechanism is not a much desired feature for VRRP.
> As for PIM, the PIM DR could also use that floating route for multicast tree
> rebuilding when its uplink becomes down. However, once the uplink of the PIM
> DR is recovered from down to up, the multicast forwarding wil
> l be interrupted absolutely till the multicast tree rebuilding is completed
> sucessfully. In contrast, the multicast forwarding interruption due to the
> multicast tree rebuilding caused by the uplink recovery event will not happen
> in our first solution. IMO, non-interruption forwarding during the RPF route
> optimization from the second-best to the best (e.g., caused by the uplink
> recovery event) is a much desired feature for improving the users
> ' QoE of IPTV service.
> 
> Comments?
> 
> Best regards,
> 
> Xiaohu
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

-- 
Yiqun

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 29 Mar 2010 13:38:26 -0700

Xiaohu,

This draft seems like a clever and reasonable solution to the problem you 
are trying to solve.  However, my point was that I do not think it is 
necessary to specify this solution in this WG, as there is nothing in the 
protocol that prevents you from doing it today.  This solution is simply 
an implementation feature that uses the existing tools in the protocol.

As an example, interface tracking is a useful and desired feature 
available in many VRRP implementations, yet I could find no mention of 
interface tracking in any of the VRRP WG docs.  The VRRP protocol 
specifies the tools available, and implementations are free to add 
features like interface tracking that build on the tools in the spec.  I 
don't think "desirability" makes it any more or less necessary to document 
an implementation feature that uses existing tools in the protocol.

Thanks,
Lenny

On Tue, 23 Mar 2010, xuxiaohu 41208 wrote:

-) Hi all,
-) 
-) After my presentation of draft-xu-pim-drpriority-auto-adjustment on the 
-) PIM session, somebody (sorry I forgot your name!)argued that PIM DR 
-) auto-switchover doesn't need to be specified in a WG informational doc 
-) since the similar approach of VRRP (i.e., the VRRP master 
-) auto-switchover) is not described in the VRRP specification.
-) 
-) That seems reasonable. However, I realized later that PIM DR 
-) auto-switchover is more desired than VRRP master switchover in the 
-) event of uplink failure. The reason is: for VRRP, the VRRP master can 
-) still hold its master role even throught it loses the connectivity to 
-) the outside network. As such, upon receiving a packet from a given host 
-) on the LAN, the VRRP master could respond with an ICMP redirection 
-) message to the host due to a configur ed floating route on it, the host 
-) in turn will change the nexthop for that destination address to the 
-) VRRP Backup router's real address. In other words, the upstream link 
-) tracking mechanism is not a much desired feature for VRRP. As for PIM, 
-) the PIM DR could also use that floating route for multicast tree 
-) rebuilding when its uplink becomes down. However, once the uplink of 
-) the PIM DR is recovered from down to up, the multicast forwarding wil l 
-) be interrupted absolutely till the multicast tree rebuilding is 
-) completed sucessfully. In contrast, the multicast forwarding 
-) interruption due to the multicast tree rebuilding caused by the uplink 
-) recovery event will not happen in our first solution. IMO, 
-) non-interruption forwarding during the RPF route optimization from the 
-) second-best to the best (e.g., caused by the uplink recovery event) is 
-) a much desired feature for improving the users ' QoE of IPTV service.
-) 
-) Comments?
-) 
-) Best regards,
-) 
-) Xiaohu
-) _______________________________________________
-) pim mailing list
-) [email-masked]
-) https://www.ietf.org/mailman/listinfo/pim
-)