IETF Logo Mail Archive

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

Indranil Bhattacharya <myselfindranil@gmail.com> Thu, 26 August 2010 14:29 UTC

Return-Path: <myselfindranil@gmail.com>
X-Original-To: magma@core3.amsl.com
Delivered-To: magma@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4ED3A69C2; Thu, 26 Aug 2010 07:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.442
X-Spam-Level:
X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTswgvSt+NCj; Thu, 26 Aug 2010 07:29:37 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 21A223A685B; Thu, 26 Aug 2010 07:29:36 -0700 (PDT)
Received: by qwc9 with SMTP id 9so1811237qwc.31 for <multiple recipients>; Thu, 26 Aug 2010 07:30:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=07hKbXUZeYNug5+dKvfDrElQxDuec0b00D5Wznv2nko=; b=wZUCenl7VDYiAFZhpJptGTH+0durkuEghejAONu6dZdZpWU7/4sl3Jc6W11gdwA42N ylt6Z1jtrhRNreYbpwQPpDckz42XO1Nd+qgEAZASbcZWvRRD976hXn26GUneplniiQ/K RdyGw24xO9Cj8aPNg36tZU5wVWML0qpfZzRqE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kZeg17/qCCA6UPjSJ2ZhLPPQiO1MPwII+VJYBKCqgdF2E1YXHDRKwiP4dVN1mGw9TY 4bKFpJbqs0ZIr5cYcZ1L8sw/OUturvFmaA/H6TKsdoxNW/An/5/XKIhaSr96Hsj4sgpE A4l0b5uOX7RGQgfx/1kBj1141J4e8tAqbKZsA=
MIME-Version: 1.0
Received: by 10.229.87.140 with SMTP id w12mr7196073qcl.125.1282833009081; Thu, 26 Aug 2010 07:30:09 -0700 (PDT)
Received: by 10.229.117.149 with HTTP; Thu, 26 Aug 2010 07:30:08 -0700 (PDT)
In-Reply-To: <009201cb3f6b$206dd2f0$240a0164@h3c.huawei3com.com>
References: <009201cb3f6b$206dd2f0$240a0164@h3c.huawei3com.com>
Date: Thu, 26 Aug 2010 20:00:08 +0530
Message-ID: <AANLkTikafuWZSwXezvi9rHutLMXfym98Ae=7K=mBpYiU@mail.gmail.com>
From: Indranil Bhattacharya <myselfindranil@gmail.com>
To: zhoudi <zhoudi@h3c.com>
Content-Type: multipart/alternative; boundary=0016364eef34cffdb3048ebad56a
Cc: Greg Shepherd <gjshep@gmail.com>, multimob@ietf.org, young@h3c.com, Hui Deng <denghui@chinamobile.com>, mboned@ietf.org, magma@ietf.org, pim@ietf.org
Subject: Re: [magma] Fw: New Version Notification for draft-dizhou-pim-umf-problem-statement-00
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/magma>
List-Post: <mailto:magma@ietf.org>
List-Help: <mailto:magma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Aug 2010 14:29:39 -0000

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.


2. This  should not affect the FHR's capability of sending NULL register.

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.
Please let me know your thoughts.

Thanks,
Indranil
On Thu, Aug 19, 2010 at 12:22 PM, zhoudi <zhoudi@h3c.com> 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.
> >
> >
> >
>

v2.8.7 | Report a Bug | By Email