Re: draft-zhou-pim-fhr-source-network-prohibition-00 & draft-zhou-pim-source-network-pim-snooping-00
zhoudi <zhoudi <at> h3c.com>
2010-12-02 06:36:28 GMT
Hi Yiqun,
Thanks for your insightful comments.
I accept the first comment. It is a good idea. Thanks very much.
In fact, these two drafts shall work together.
So before FHR's (S,G) entry expires, FHR will receive the multicast stream
again because the lifetime of pruned port in switch is only 1/3 of FHR
(S,G) entry's. Then FHR could tell if the source is alive.
For the third comment, if the non-dr changes to be DR, it could
send out pim join to the souce. We would add it into the draft later. It is
really a good comment too. Thanks.
In ip-based video surveillance system, the switches' bandwidth and out-gress cache
would be wasted seriously, which is described in detail in the problem-statement draft.
So we hope there would be a solution to solve this problem.
Best Regards.
ZhouDi
----- Original Message -----
From: "Yiqun Cai" <ycai <at> cisco.com>
To: "zhoudi" <zhoudi <at> h3c.com>; <pim <at> ietf.org>
Sent: Wednesday, December 01, 2010 4:13 PM
Subject: Re: [pim] draft-zhou-pim-fhr-source-network-prohibition-00 & draft-zhou-pim-source-network-pim-snooping-00
> Greetings,
>
> I do have a few comments.
>
> 1. The FSNP draft states,
>
> Because DF of Bidir-PIM has to always forward multicast to RP link,
>
> And then concludes,
>
> so Bidir-PIM has no need to refuse multicast streams.
>
> This doesn't follow, because we can't assume there is only a single router,
> which is the DF for all RPs.
>
> 2. The FSNP solution as described wouldn't work for PIM-SM either. It is
> possible that the source sends the packets before the receivers join the
> group (keep in mind that the receivers may be in another domain served by a
> different RP with an MSDP peering to the RP in the same domain as the
> source). If the DR prunes the source upon getting a register stop, the DR
> will have no way of knowing whether the source continues to send and
> therefore will stop sending registers, effectively blockholing all new
> receivers.
>
> We can ask the DR/switch to do periodic flood-and-prune like in DM. But I
> am not sure the complexity really buys us anything.
>
> The solution described for PIM-DM also has flaws that might lead to
> unintended packet loss. But that is of less importance so I'm not going in
> there right now.
>
> 3. In practice, the switches must always forward the packets to DR (for an
> SM group) and DF (for a Bidir group). But it is not realistic to ask the
> switch to know the mode of the group (which is determined by the RP). So
> the switch must by default "flood", and wait for a "prune". Once it gets a
> prune, if there is a DR change or a group mode change, it will be difficult
> to make sure the states on the switches and routers are consistent using the
> current set of messages. And if we introduce more messages, we might as
> well make the switches have an IP address and run PIM.
>
> Again, I'm not sure if the complexity is worth it.
>
> Going through the minutes (sorry I wasn't at the meeting), I'm not sure if
> we concluded that we needed to address the problem for all PIM modes. It
> would be a more manageable solution if we focus on SSM only.
>
>
> On 11/30/10 6:23 PM, "zhoudi" <zhoudi <at> h3c.com> wrote:
>
>> Dear all,
>>
>> For the problem of unnecessary multicast flooding in the source network, which
>> is
>> described in the problem-statement draft and presented by DengHui at IETF79
>> meeting,
>> we have uploaded two solution drafts, one for the FHR(First hop router) and
>> the other
>> for the switches in the source netwrok.
>>
>> http://datatracker.ietf.org/doc/draft-dizhou-pim-umf-problem-statement/
>>
>> http://datatracker.ietf.org/doc/draft-zhou-pim-fhr-source-network-prohibition/
>>
>> http://datatracker.ietf.org/doc/draft-zhou-pim-source-network-pim-snooping/
>>
>>
>> Besides the problem, there is no protocol for switches in the source network
>> at present.
>> We hope there would be a protocol to prohibit multicast stream at the exact
>> switch.
>>
>> The solution above is suitable for PIM SSM/SM/DM.
>>
>> Besides the solution based on pim-snooping and pim, the solution based on igmp
>> extension
>> works too, which was described in the problem-statement draft.
>>
>> We welcome your comments and discussions on it,
>>
>> Thanks and Regards,
>>
>> ZhouDi
>>
>> _______________________________________________
>> pim mailing list
>> pim <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/pim
>
>
> --
> Yiqun
>
>
RSS Feed