Re: [magma] Fw: New Version Notification for draft-dizhou-pim-umf-problem-statement-00

[zhoudi <[e-mail]>]

Hi Indranil,
     Thanks for your comment.
     My reply is as follows:
     
     Thanks and Regards
     ZhouDi

  ----- Original Message ----- 
  From: Indranil Bhattacharya 
  To: zhoudi 
  Cc: Greg Shepherd ; [e-mail] ; [e-mail] ; [e-mail] ; [e-mail] ; Hui Deng ; [e-mail] ; Liu Hui 
  Sent: Thursday, August 26, 2010 10:30 PM
  Subject: Re: Fw: New Version Notification for draft-dizhou-pim-umf-problem-statement-00


  Hi ZhouDi,

                A few comments.

  1. There must be a way to refresh the pim snooping entry in the switch. This needs to be done by pim j/p message from FHR.
      Without a refresh mechanism for the entry in the switch there is a problem. After receiving the first data packet FHR send PIM
      prune. Then the entry expires and switch forwards data again but FHR does not send PIM prune because it already has (S,G) with
      NULL OIF. 
     Yeah, you are right. That is why the lifetime of  pruned ports is 1/3 of the lifetime of PIM FHR's (S,G) entry.
     But the behaviour of periodically forwarding and pruning can be optimized. 
     Do you have any idea about it,especially in PIM SM?Thanks.

  2. This  should not affect the FHR's capability of sending NULL register. 
     Have you found some potential problems? Thanks.

  3. This special pim snoop entry needs to be installed in the hash/tcam region of the switch. Otherwise all data will have to hit the 
      cpu of the switch. So better if switch's hw-multicast-entries can be changed based on the pim snooping information. 
      Absence of a snooping entry means forward the data to all interfaces in the same vlan. Presence of a pruned interface in the
      snooping entry means forward data to all interfaces in that vlan excluding the pruned interface.
      I will accept your suggestion. Thanks.

  Please let me know your thoughts.

  Thanks,
  Indranil

  On Thu, Aug 19, 2010 at 12:22 PM, zhoudi <[e-mail]> wrote:

    Hi,
        According to your advice, I newly submitted the problem-statement for the problem of
    Unnecessary Multicast Flooding between sources and PIM FHRs.
    http://datatracker.ietf.org/doc/draft-dizhou-pim-umf-problem-statement/
        Welcome to  comment on the problem and  bring forward solutions.

        Thanks and Regards.
        ZhouDi


    Subject: New Version Notification for draft-dizhou-pim-umf-problem-statement-00


    >
    > A new version of I-D, draft-dizhou-pim-umf-problem-statement-00.txt has been successfully submitted by Di Zhou and posted to the IETF repository.
    >
    > Filename: draft-dizhou-pim-umf-problem-statement
    > Revision: 00
    > Title: Unnecessary Multicast Flooding Problem Statement
    > Creation_date: 2010-08-17
    > WG ID: Independent Submission
    > Number_of_pages: 15
    >
    > Abstract:
    > This document describes the unnecessary multicast stream flooding
    > problem in the link layer switches between multicast source and PIM
    > First Hop Router (FHR).  The IGMP-Snooping Switch will forward
    > multicast streams to router ports, and the PIM FHR must receive all
    > multicast streams even if there is no request from receiver.  This
    > often leads to waste of switchs' cache and link bandwidth when the
    > multicast streams are not actually required.  This document details
    > the problem and defines design goals for a generic mechanism to
    > restrain the unnecessary multicast stream flooding.
    >
    >
    >
    > The IETF Secretariat.
    >
    >
    >