zhoudi | 1 Dec 03:23 2010

draft-zhou-pim-fhr-source-network-prohibition-00 & draft-zhou-pim-source-network-pim-snooping-00

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.
 
 


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
Vero Zheng | 1 Dec 04:48 2010

Re: draft-ietf-pim-registry-01 wglc

Yes/Support

BR,
Vero

--------------------------------------------------
From: "Mike McBride (mmcbride)" <mmcbride <at> cisco.com>
Sent: Tuesday, November 30, 2010 6:07 AM
To: <pim <at> ietf.org>
Subject: [pim] draft-ietf-pim-registry-01 wglc

> Today begins a two week wglc for draft-ietf-pim-registry-01. A type for
> experimental use was not reserved in this draft. Please speak up to
> support or not support.
> 
> http://www.ietf.org/id/draft-ietf-pim-registry-01.txt
> 
> thanks,
> mike
> _______________________________________________
> pim mailing list
> pim <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pim 
Yiqun Cai | 1 Dec 09:13 2010
Picon

Re: 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
zhoudi | 2 Dec 07:36 2010

Re: draft-zhou-pim-fhr-source-network-prohibition-00 & draft-zhou-pim-source-network-pim-snooping-00

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
> 
>
Mike McBride (mmcbride | 2 Dec 21:27 2010
Picon

draft-ietf-pim-port-04 wglc

Today begins another wglc for the pim-port draft. It will be two weeks.
The draft has been updated with comments from previous wglc. Please
review the draft and respond with support or not.

http://www.ietf.org/id/draft-ietf-pim-port-04.txt

Thanks,
mike

> -----Original Message-----
> From: pim-bounces <at> ietf.org [mailto:pim-bounces <at> ietf.org] On Behalf Of
> Stig Venaas
> Sent: Monday, October 25, 2010 2:58 PM
> To: pim <at> ietf.org
> Subject: Re: [pim] I-D Action:draft-ietf-pim-port-04.txt
> 
> I believe this version includes all the changes requested by Thomas
and
> Yakov, as well as most of the changes requested by Dimitri as part of
> the wglc and the following discussion.
> 
> Comments welcome,
> 
> Stig
> _______________________________________________
> pim mailing list
> pim <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pim
Jeff Tantsura | 2 Dec 22:11 2010
Picon

Re: draft-ietf-pim-port-04 wglc

Yes/support (it's about time:))

Regards,
Jeff  
-----Original Message-----
From: pim-bounces <at> ietf.org [mailto:pim-bounces <at> ietf.org] On Behalf Of Mike McBride (mmcbride)
Sent: Thursday, December 02, 2010 12:28
To: pim <at> ietf.org
Subject: [pim] draft-ietf-pim-port-04 wglc

Today begins another wglc for the pim-port draft. It will be two weeks.
The draft has been updated with comments from previous wglc. Please
review the draft and respond with support or not.

http://www.ietf.org/id/draft-ietf-pim-port-04.txt

Thanks,
mike

> -----Original Message-----
> From: pim-bounces <at> ietf.org [mailto:pim-bounces <at> ietf.org] On Behalf Of
> Stig Venaas
> Sent: Monday, October 25, 2010 2:58 PM
> To: pim <at> ietf.org
> Subject: Re: [pim] I-D Action:draft-ietf-pim-port-04.txt
> 
> I believe this version includes all the changes requested by Thomas
and
> Yakov, as well as most of the changes requested by Dimitri as part of
> the wglc and the following discussion.
> 
> Comments welcome,
> 
> Stig
> _______________________________________________
> pim mailing list
> pim <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pim
_______________________________________________
pim mailing list
pim <at> ietf.org
https://www.ietf.org/mailman/listinfo/pim
zhoudi | 3 Dec 01:51 2010

Re: draft-ietf-pim-port-04 wglc

Yes/support

----- Original Message ----- 
From: "Mike McBride (mmcbride)" <mmcbride <at> cisco.com>
To: <pim <at> ietf.org>
Sent: Friday, December 03, 2010 4:27 AM
Subject: [pim] draft-ietf-pim-port-04 wglc

> Today begins another wglc for the pim-port draft. It will be two weeks.
> The draft has been updated with comments from previous wglc. Please
> review the draft and respond with support or not.
> 
> http://www.ietf.org/id/draft-ietf-pim-port-04.txt
> 
> Thanks,
> mike
> 
>> -----Original Message-----
>> From: pim-bounces <at> ietf.org [mailto:pim-bounces <at> ietf.org] On Behalf Of
>> Stig Venaas
>> Sent: Monday, October 25, 2010 2:58 PM
>> To: pim <at> ietf.org
>> Subject: Re: [pim] I-D Action:draft-ietf-pim-port-04.txt
>> 
>> I believe this version includes all the changes requested by Thomas
> and
>> Yakov, as well as most of the changes requested by Dimitri as part of
>> the wglc and the following discussion.
>> 
>> Comments welcome,
>> 
>> Stig
>> _______________________________________________
>> pim mailing list
>> pim <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/pim
> _______________________________________________
> pim mailing list
> pim <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pim
>
Internet-Drafts | 6 Dec 04:30 2010
Picon

I-D Action:draft-ietf-pim-group-rp-mapping-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Protocol Independent Multicast Working Group of the IETF.

	Title           : PIM Group-to-RP Mapping
	Author(s)       : B. Joshi, et al.
	Filename        : draft-ietf-pim-group-rp-mapping-06.txt
	Pages           : 19
	Date            : 2010-12-05

Each PIM-SM router in a Protocol Independent Multicast (PIM) Domain
which supports Any Source Multicast (ASM) maintains Group-to-RP
mappings which are used to identify a Rendezvous Point(RP) for a
specific multicast group.  PIM-SM has defined an algorithm to choose
a RP from the Group-to-RP mappings learned using various mechanisms.
This algorithm does not consider the PIM mode and the mechanism
through which a Group-to-RP mapping was learned.

This document defines a standard algorithm to deterministically
choose between several group-to-rp mappings for a specific group.
This document first explains the requirements to extend the
Group-to-RP mapping algorithm and then proposes the new algorithm.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pim-group-rp-mapping-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
pim mailing list
pim <at> ietf.org
https://www.ietf.org/mailman/listinfo/pim
Mike McBride (mmcbride | 7 Dec 01:23 2010
Picon

draft-ietf-pim-mtid-05 wglc

> Mike and Stig,  will we need another last call?

Yes, sorry for the delay. Today begins another 2 week wglc for
http://www.ietf.org/id/draft-ietf-pim-mtid-05.txt

Please review the draft and let us know if you support sending it to the
iesg.

thanks,
mike

> -----Original Message-----
> From: pim-bounces <at> ietf.org [mailto:pim-bounces <at> ietf.org] On Behalf Of
> Yiqun Cai (ycai)
> Sent: Wednesday, September 22, 2010 3:27 PM
> To: pim <at> ietf.org
> Subject: Re: [pim] I-D Action:draft-ietf-pim-mtid-05.txt
> 
> 
> Chairs, Dimitri,  and WG,
> 
> The latest update incorporates the comment received from the
discussion
> during the Last Call.
> 
> Please review and comment.
> 
> Mike and Stig,  will we need another last call?
> 
> Thanks.
> 
> 
> On 9/22/10 3:00 PM, "Internet-Drafts <at> ietf.org" <Internet-
> Drafts <at> ietf.org>
> wrote:
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Protocol Independent Multicast
> Working Group
> > of the IETF.
> >
> >
> > Title           : PIM Multi-Topology ID (MT-ID) Join-Attribute
> > Author(s)       : Y. Cai, H. Ou
> > Filename        : draft-ietf-pim-mtid-05.txt
> > Pages           : 11
> > Date            : 2010-09-22
> >
> > This document introduces a new type of PIM Join Attribute that
> > extends PIM signaling to identify a topology that should be used
when
> > constructing a particular multicast distribution tree.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-pim-mtid-05.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> > _______________________________________________
> > pim mailing list
> > pim <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/pim
> 
> 
> --
> Yiqun
> 
> _______________________________________________
> pim mailing list
> pim <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pim
Internet-Drafts | 9 Dec 08:45 2010
Picon

I-D Action:draft-ietf-pim-group-rp-mapping-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Protocol Independent Multicast Working Group of the IETF.

	Title           : PIM Group-to-RP Mapping
	Author(s)       : B. Joshi, et al.
	Filename        : draft-ietf-pim-group-rp-mapping-07.txt
	Pages           : 19
	Date            : 2010-12-08

Each PIM-SM router in a Protocol Independent Multicast (PIM) Domain
which supports Any Source Multicast (ASM) maintains Group-to-RP
mappings which are used to identify a Rendezvous Point(RP) for a
specific multicast group.  PIM-SM has defined an algorithm to choose
a RP from the Group-to-RP mappings learned using various mechanisms.
This algorithm does not consider the PIM mode and the mechanism
through which a Group-to-RP mapping was learned.

This document defines a standard algorithm to deterministically
choose between several group-to-rp mappings for a specific group.
This document first explains the requirements to extend the
Group-to-RP mapping algorithm and then proposes the new algorithm.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pim-group-rp-mapping-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
pim mailing list
pim <at> ietf.org
https://www.ietf.org/mailman/listinfo/pim

Gmane