Re: Fw: New Version Notification for draft-dizhou-pim-umf-problem-statement-00
Indranil Bhattacharya <[email protected]> Thu, 26 Aug 2010 20:00:08 +0530
| Newsgroups | gmane.ietf.magma |
|---|---|
| Message-ID | <[email protected]> |
--===============0166545494==
Content-Type: multipart/alternative; boundary=0016364eef34cffdb3048ebad56a
--0016364eef34cffdb3048ebad56a
Content-Type: text/plain; charset=ISO-8859-1
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 <[email protected]> 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.
> >
> >
> >
>
--0016364eef34cffdb3048ebad56a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Hi ZhouDi,</div>
<div>=A0</div>
<div>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0A few=A0comments.</div>
<div>=A0</div>
<div>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.<br>=A0=A0=A0 Without a=
refresh mechanism for the entry in the switch there is a problem. After re=
ceiving the first data packet FHR send PIM</div>
<div>=A0=A0 =A0prune. Then the entry expires and switch forwards data again=
but FHR does not send PIM prune because it already has (S,G) with</div>
<div>=A0=A0 =A0NULL OIF. </div>
<div>=A0</div>
<div>=A0</div>
<div>2. This=A0 should not affect the FHR's capability of sending NULL =
register. </div>
<div>=A0</div>
<div>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 </div>
<div>=A0=A0=A0 cpu of the switch. So better if switch's hw-multicast-en=
tries can be changed based on the pim snooping information. </div>
<div>=A0=A0=A0 Absence of a snooping entry means forward the data to all in=
terfaces in the same vlan. Presence of a pruned interface in the</div>
<div>=A0=A0 =A0snooping entry means forward data to all interfaces in that =
vlan excluding the pruned interface.<br></div>
<div>Please let me know your thoughts.</div>
<div>=A0</div>
<div>Thanks,</div>
<div>Indranil<br></div>
<div class=3D"gmail_quote">On Thu, Aug 19, 2010 at 12:22 PM, zhoudi <span d=
ir=3D"ltr"><<a href=3D"mailto:[email protected]">[email protected]</a>></sp=
an> wrote:<br>
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3D"gmail_quote">Hi,<br>=A0 =A0 According to your=
advice, I newly submitted the problem-statement for the problem of<br>Unne=
cessary Multicast Flooding between sources and PIM FHRs.<br>
<a href=3D"http://datatracker.ietf.org/doc/draft-dizhou-pim-umf-problem-sta=
tement/" target=3D"_blank">http://datatracker.ietf.org/doc/draft-dizhou-pim=
-umf-problem-statement/</a><br>=A0 =A0 Welcome to =A0comment on the problem=
and =A0bring forward solutions.<br>
<br>=A0 =A0 Thanks and Regards.<br>=A0 =A0 ZhouDi<br><br><br>Subject: New V=
ersion Notification for draft-dizhou-pim-umf-problem-statement-00<br><br><b=
r>><br>> 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 r=
epository.<br>
><br>> Filename: draft-dizhou-pim-umf-problem-statement<br>> Revis=
ion: 00<br>> Title: Unnecessary Multicast Flooding Problem Statement<br>=
> Creation_date: 2010-08-17<br>> WG ID: Independent Submission<br>
> Number_of_pages: 15<br>><br>> Abstract:<br>> This document de=
scribes the unnecessary multicast stream flooding<br>> problem in the li=
nk layer switches between multicast source and PIM<br>> First Hop Router=
(FHR). =A0The IGMP-Snooping Switch will forward<br>
> multicast streams to router ports, and the PIM FHR must receive all<br=
>> multicast streams even if there is no request from receiver. =A0This<=
br>> often leads to waste of switchs' cache and link bandwidth when =
the<br>
> multicast streams are not actually required. =A0This document details<=
br>> the problem and defines design goals for a generic mechanism to<br>=
> restrain the unnecessary multicast stream flooding.<br>><br>><br=
>
><br>> The IETF Secretariat.<br>><br>><br>><br></blockquote>=
</div><br>
--0016364eef34cffdb3048ebad56a--
--===============0166545494==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
magma mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/magma
--===============0166545494==--