Re: Fw: New Version Notification for draft-dizhou-pim-umf-problem-statement-00
zhoudi <[email protected]> Fri, 27 Aug 2010 10:56:07 +0800
| Newsgroups | gmane.ietf.pim,gmane.ietf.magma |
|---|---|
| Message-ID | <[email protected]> |
--===============1880046911==
Content-type: multipart/alternative;
boundary="Boundary_(ID_CMpn1vfvpHEP4t+PavdreQ)"
--Boundary_(ID_CMpn1vfvpHEP4t+PavdreQ)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
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 ; [email protected] ; [email protected] ; [email protected] ; [email protected] ; Hui Deng ; [email protected] ; 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 <[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.
>
>
>
--Boundary_(ID_CMpn1vfvpHEP4t+PavdreQ)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6000.17063" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#cce8cf>
<DIV>Hi Indranil,</DIV>
<DIV> Thanks for your comment.</DIV>
<DIV> My reply is as follows:</DIV>
<DIV> </DIV>
<DIV> Thanks and Regards</DIV>
<DIV> ZhouDi</DIV>
<DIV><FONT face=宋体 size=2></FONT> </DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 9pt 宋体">----- Original Message ----- </DIV>
<DIV style="BACKGROUND: #e4e4e4; FONT: 9pt 宋体; font-color: black"><B>From:</B>
<A [email protected]
href="mailto:[email protected]">Indranil Bhattacharya</A> </DIV>
<DIV style="FONT: 9pt 宋体"><B>To:</B> <A [email protected]
href="mailto:[email protected]">zhoudi</A> </DIV>
<DIV style="FONT: 9pt 宋体"><B>Cc:</B> <A [email protected]
href="mailto:[email protected]">Greg Shepherd</A> ; <A [email protected]
href="mailto:[email protected]">[email protected]</A> ; <A [email protected]
href="mailto:[email protected]">[email protected]</A> ; <A [email protected]
href="mailto:[email protected]">[email protected]</A> ; <A
[email protected] href="mailto:[email protected]">[email protected]</A> ; <A
[email protected] href="mailto:[email protected]">Hui
Deng</A> ; <A [email protected]
href="mailto:[email protected]">[email protected]</A> ; <A
[email protected] href="mailto:[email protected]">Liu Hui</A>
</DIV>
<DIV style="FONT: 9pt 宋体"><B>Sent:</B> Thursday, August 26, 2010 10:30
PM</DIV>
<DIV style="FONT: 9pt 宋体"><B>Subject:</B> Re: Fw: New Version Notification for
draft-dizhou-pim-umf-problem-statement-00</DIV>
<DIV><BR></DIV>
<DIV>Hi ZhouDi,</DIV>
<DIV> </DIV>
<DIV> A
few comments.</DIV>
<DIV><FONT face=宋体 size=2></FONT> </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>
Without a refresh mechanism for the entry in the switch there is a problem.
After receiving the first data packet FHR send PIM</DIV>
<DIV> prune. 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> NULL OIF. </DIV>
<DIV><FONT color=#008000> 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.</FONT></DIV>
<DIV><FONT color=#008000> But the behaviour of periodically
forwarding and pruning can be optimized. </FONT></DIV>
<DIV><FONT color=#008000> Do you have any idea about it,especially
in PIM SM？Thanks.</FONT></DIV>
<DIV><FONT face=宋体 size=2></FONT> </DIV>
<DIV>2. This should not affect the FHR's capability of sending NULL
register. </DIV>
<DIV> <FONT color=#008000> Have you found some potential problems?
Thanks.</FONT></DIV>
<DIV><FONT face=宋体 size=2></FONT> </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> cpu of the switch. So better if switch's
hw-multicast-entries can be changed based on the pim snooping information.
</DIV>
<DIV> Absence of a snooping entry means forward the data to
all interfaces in the same vlan. Presence of a pruned interface in the</DIV>
<DIV> snooping entry means forward data to all interfaces in
that vlan excluding the pruned interface.</DIV>
<DIV> <FONT color=#008000> I will accept your suggestion.
Thanks.</FONT><BR></DIV>
<DIV>Please let me know your thoughts.</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>Indranil<BR></DIV>
<DIV class=gmail_quote>On Thu, Aug 19, 2010 at 12:22 PM, zhoudi <SPAN
dir=ltr><<A href="mailto:[email protected]">[email protected]</A>></SPAN>
wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi,<BR>
According to your advice, I newly submitted the problem-statement for
the problem of<BR>Unnecessary Multicast Flooding between sources and PIM
FHRs.<BR><A
href="http://datatracker.ietf.org/doc/draft-dizhou-pim-umf-problem-statement/"
target=_blank>http://datatracker.ietf.org/doc/draft-dizhou-pim-umf-problem-statement/</A><BR>
Welcome to comment on the problem and bring forward
solutions.<BR><BR> Thanks and Regards.<BR>
ZhouDi<BR><BR><BR>Subject: New Version Notification for
draft-dizhou-pim-umf-problem-statement-00<BR><BR><BR>><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
repository.<BR>><BR>> Filename:
draft-dizhou-pim-umf-problem-statement<BR>> Revision: 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 describes the unnecessary
multicast stream flooding<BR>> problem in the link layer switches between
multicast source and PIM<BR>> First Hop Router (FHR). The
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. This<BR>> often leads to waste of
switchs' cache and link bandwidth when the<BR>> multicast streams are not
actually required. This 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></BLOCKQUOTE></BODY></HTML>
--Boundary_(ID_CMpn1vfvpHEP4t+PavdreQ)--
--===============1880046911==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
pim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pim
--===============1880046911==--