headers
Jacni Qin | 3 Mar 2011 09:59
Picon

Re: Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00

Hi Tina,

Thanks for writing the document, please see below my comments.

For the discussions about draft-qin-softwire-dslite-multicast in Section 3,
Acctually, both ASM and SSM are covered everytime when some points are discussed, for example, Address mapping, mB4, mAFTR.
Particularly, the authors spent a lot of efforts on the ASM deployment issues encounterd in Section 7.
So, please update the text related, also that in the Table 1, thanks.


Cheers,
Jacni


On Thu, Mar 3, 2011 at 5:32 AM, Tina Tsou <tena <at> huawei.com> wrote:
Hi Dan,
We have emailed all of the authors of the various drafts and ask them to
review draft-tsou-multicast-transition-taxonomy.


We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


-----Original Message-----
From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On Behalf Of
Dan Wing
Sent: Wednesday, March 02, 2011 12:20 PM
To: 'Stig Venaas'; 'Tom Taylor'
Cc: behave <at> ietf.org
Subject: Re: [BEHAVE] Fwd: New Version Notification for
draft-tsou-multicast-transition-taxonomy-00

> -----Original Message-----
> From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On
> Behalf Of Stig Venaas
> Sent: Wednesday, March 02, 2011 11:41 AM
> To: Tom Taylor
> Cc: behave <at> ietf.org
> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-
> multicast-transition-taxonomy-00
>
> On 3/1/2011 8:00 AM, Tom Taylor wrote:
> > We have prepared this document to help sort out the multicast
> > transition
> > work in the BEHAVE and SOFTWIRES WGs. Please have a look at and
> > comment
> > on the conclusions.
>
> A good well written document :)

Agreed.

> I would not use the term Multicast Topology for ASM vs SSM. Topology is
> more used for network topology... ASM and SSM are generally I think,
> referred to as different multicast service models. I would suggest
> using
> that term.
>
> That is the only change I would suggest in the draft.
>
> Some comments regarding ID.venaas-mcast46 though. It can be used
> together with ID.boucadair-64-multicast-address-format, and I plan
> to update it with a reference to that. This is maybe obvious though.

Tom, tt would be really valuable if you could email all of the
authors of the various drafts and ask them to review
draft-tsou-multicast-transition-taxonomy, to ensure their documents
are all accurately summarized.

-d

> It is correct that it is from 2008. Although not relevant, I feel like
> pointing out that the draft is very close to
> draft-venaas-mboned-v4v6mcastgw-00.txt from 2003.
>
> Stig
>
> _______________________________________________
> Behave mailing list
> Behave <at> ietf.org
> https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
Behave <at> ietf.org
https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
Behave <at> ietf.org
https://www.ietf.org/mailman/listinfo/behave

<div>Hi Tina,<br><br>Thanks for writing the document, please see below my comments.<br><br>For the discussions about draft-qin-softwire-dslite-multicast in Section 3,<br>Acctually, both ASM and SSM are covered everytime when some points are discussed, for example, Address mapping, mB4, mAFTR.<br>
Particularly, the authors spent a lot of efforts on the ASM deployment issues encounterd in Section 7.<br>So, please update the text related, also that in the Table 1, thanks.<br><br><br>Cheers,<br>Jacni<br><br><br><div class="gmail_quote">On Thu, Mar 3, 2011 at 5:32 AM, Tina Tsou <span dir="ltr">&lt;<a href="mailto:tena <at> huawei.com">tena <at> huawei.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
Hi Dan,<br>
We have emailed all of the authors of the various drafts and ask them to<br>
review draft-tsou-multicast-transition-taxonomy.<br><br><br>
We keep our promises with one another - no matter what!<br><br>
Best Regards,<br>Tina TSOU<br><a href="http://tinatsou.weebly.com/contact.html" target="_blank">http://tinatsou.weebly.com/contact.html</a><br><div class="im">
<br><br>
-----Original Message-----<br>
From: <a href="mailto:behave-bounces <at> ietf.org">behave-bounces <at> ietf.org</a> [mailto:<a href="mailto:behave-bounces <at> ietf.org">behave-bounces <at> ietf.org</a>] On Behalf Of<br>
</div>
<div>
<div></div>
<div class="h5">Dan Wing<br>
Sent: Wednesday, March 02, 2011 12:20 PM<br>
To: 'Stig Venaas'; 'Tom Taylor'<br>
Cc: <a href="mailto:behave <at> ietf.org">behave <at> ietf.org</a><br>
Subject: Re: [BEHAVE] Fwd: New Version Notification for<br>
draft-tsou-multicast-transition-taxonomy-00<br><br>
&gt; -----Original Message-----<br>
&gt; From: <a href="mailto:behave-bounces <at> ietf.org">behave-bounces <at> ietf.org</a> [mailto:<a href="mailto:behave-bounces <at> ietf.org">behave-bounces <at> ietf.org</a>] On<br>
&gt; Behalf Of Stig Venaas<br>
&gt; Sent: Wednesday, March 02, 2011 11:41 AM<br>
&gt; To: Tom Taylor<br>
&gt; Cc: <a href="mailto:behave <at> ietf.org">behave <at> ietf.org</a><br>
&gt; Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-≤br>
&gt; multicast-transition-taxonomy-00<br>
&gt;<br>
&gt; On 3/1/2011 8:00 AM, Tom Taylor wrote:<br>
&gt; &gt; We have prepared this document to help sort out the multicast<br>
&gt; &gt; transition<br>
&gt; &gt; work in the BEHAVE and SOFTWIRES WGs. Please have a look at and<br>
&gt; &gt; comment<br>
&gt; &gt; on the conclusions.<br>
&gt;<br>
&gt; A good well written document :)<br><br>
Agreed.<br><br>
&gt; I would not use the term Multicast Topology for ASM vs SSM. Topology is<br>
&gt; more used for network topology... ASM and SSM are generally I think,<br>
&gt; referred to as different multicast service models. I would suggest<br>
&gt; using<br>
&gt; that term.<br>
&gt;<br>
&gt; That is the only change I would suggest in the draft.<br>
&gt;<br>
&gt; Some comments regarding ID.venaas-mcast46 though. It can be used<br>
&gt; together with ID.boucadair-64-multicast-address-format, and I plan<br>
&gt; to update it with a reference to that. This is maybe obvious though.<br><br>
Tom, tt would be really valuable if you could email all of the<br>
authors of the various drafts and ask them to review<br>
draft-tsou-multicast-transition-taxonomy, to ensure their documents<br>
are all accurately summarized.<br><br>
-d<br><br>
&gt; It is correct that it is from 2008. Although not relevant, I feel like<br>
&gt; pointing out that the draft is very close to<br>
&gt; draft-venaas-mboned-v4v6mcastgw-00.txt from 2003.<br>
&gt;<br>
&gt; Stig<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Behave mailing list<br>
&gt; <a href="mailto:Behave <at> ietf.org">Behave <at> ietf.org</a><br>
&gt; <a href="https://www.ietf.org/mailman/listinfo/behave" target="_blank">https://www.ietf.org/mailman/listinfo/behave</a><br><br>
_______________________________________________<br>
Behave mailing list<br><a href="mailto:Behave <at> ietf.org">Behave <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/behave" target="_blank">https://www.ietf.org/mailman/listinfo/behave</a><br><br>
_______________________________________________<br>
Behave mailing list<br><a href="mailto:Behave <at> ietf.org">Behave <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/behave" target="_blank">https://www.ietf.org/mailman/listinfo/behave</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
Permalink | Reply |
headers
Tom Taylor | 4 Mar 2011 05:06

Re: Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00

This is a point to be discussed. Our criterion for whether ASM was 
addressed was whether sources were allowed in network A. You discussed 
ASM in network C, and the table records this fact, but your introduction 
has the following statement:

   "This document does not cover the case where an IPv4 host connected to
    a CPE served by a DS-Lite AFTR can be the source of multicast
    traffic."

Should we classify by a different criterion than the one we used?

On 03/03/2011 3:59 AM, Jacni Qin wrote:
> Hi Tina,
>
> Thanks for writing the document, please see below my comments.
>
> For the discussions about draft-qin-softwire-dslite-multicast in Section 3,
> Acctually, both ASM and SSM are covered everytime when some points are
> discussed, for example, Address mapping, mB4, mAFTR.
> Particularly, the authors spent a lot of efforts on the ASM deployment
> issues encounterd in Section 7.
> So, please update the text related, also that in the Table 1, thanks.
>
>
> Cheers,
> Jacni
>
>
> On Thu, Mar 3, 2011 at 5:32 AM, Tina Tsou<tena <at> huawei.com>  wrote:
>
>> Hi Dan,
>> We have emailed all of the authors of the various drafts and ask them to
>> review draft-tsou-multicast-transition-taxonomy.
>>
>>
>> We keep our promises with one another - no matter what!
>>
>> Best Regards,
>> Tina TSOU
>> http://tinatsou.weebly.com/contact.html
>>
>>
>> -----Original Message-----
>> From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On Behalf
>> Of
>> Dan Wing
>> Sent: Wednesday, March 02, 2011 12:20 PM
>> To: 'Stig Venaas'; 'Tom Taylor'
>> Cc: behave <at> ietf.org
>> Subject: Re: [BEHAVE] Fwd: New Version Notification for
>> draft-tsou-multicast-transition-taxonomy-00
>>
>>> -----Original Message-----
>>> From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On
>>> Behalf Of Stig Venaas
>>> Sent: Wednesday, March 02, 2011 11:41 AM
>>> To: Tom Taylor
>>> Cc: behave <at> ietf.org
>>> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-
>>> multicast-transition-taxonomy-00
>>>
>>> On 3/1/2011 8:00 AM, Tom Taylor wrote:
>>>> We have prepared this document to help sort out the multicast
>>>> transition
>>>> work in the BEHAVE and SOFTWIRES WGs. Please have a look at and
>>>> comment
>>>> on the conclusions.
>>>
>>> A good well written document :)
>>
>> Agreed.
>>
>>> I would not use the term Multicast Topology for ASM vs SSM. Topology is
>>> more used for network topology... ASM and SSM are generally I think,
>>> referred to as different multicast service models. I would suggest
>>> using
>>> that term.
>>>
>>> That is the only change I would suggest in the draft.
>>>
>>> Some comments regarding ID.venaas-mcast46 though. It can be used
>>> together with ID.boucadair-64-multicast-address-format, and I plan
>>> to update it with a reference to that. This is maybe obvious though.
>>
>> Tom, tt would be really valuable if you could email all of the
>> authors of the various drafts and ask them to review
>> draft-tsou-multicast-transition-taxonomy, to ensure their documents
>> are all accurately summarized.
>>
>> -d
>>
>>> It is correct that it is from 2008. Although not relevant, I feel like
>>> pointing out that the draft is very close to
>>> draft-venaas-mboned-v4v6mcastgw-00.txt from 2003.
>>>
>>> Stig
>>>
>>> _______________________________________________
>>> Behave mailing list
>>> Behave <at> ietf.org
>>> https://www.ietf.org/mailman/listinfo/behave
>>
>> _______________________________________________
>> Behave mailing list
>> Behave <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/behave
>>
>> _______________________________________________
>> Behave mailing list
>> Behave <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/behave
>>
>
Permalink | Reply |
headers
Jacni Qin | 7 Mar 2011 07:26
Picon

Re: Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00

Hi Tom,

Sorry, I don't follow you point.

For ASM, we mean "Any-Source Multicast". The statement below is just to clarify that for example, in practical deployment of the scheme, the broadband subscribers are not allowed to source the multicast traffic. Other things like, RP, Source Registration, of ASM are all taken into account.


Cheers,
Jacni

On Fri, Mar 4, 2011 at 12:06 PM, Tom Taylor <tom111.taylor <at> bell.net> wrote:
This is a point to be discussed. Our criterion for whether ASM was addressed was whether sources were allowed in network A. You discussed ASM in network C, and the table records this fact, but your introduction has the following statement:

 "This document does not cover the case where an IPv4 host connected to
  a CPE served by a DS-Lite AFTR can be the source of multicast
  traffic."

Should we classify by a different criterion than the one we used?



On 03/03/2011 3:59 AM, Jacni Qin wrote:
Hi Tina,

Thanks for writing the document, please see below my comments.

For the discussions about draft-qin-softwire-dslite-multicast in Section 3,
Acctually, both ASM and SSM are covered everytime when some points are
discussed, for example, Address mapping, mB4, mAFTR.
Particularly, the authors spent a lot of efforts on the ASM deployment
issues encounterd in Section 7.
So, please update the text related, also that in the Table 1, thanks.


Cheers,
Jacni


On Thu, Mar 3, 2011 at 5:32 AM, Tina Tsou<tena <at> huawei.com>  wrote:

Hi Dan,
We have emailed all of the authors of the various drafts and ask them to
review draft-tsou-multicast-transition-taxonomy.


We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


-----Original Message-----
From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On Behalf
Of
Dan Wing
Sent: Wednesday, March 02, 2011 12:20 PM
To: 'Stig Venaas'; 'Tom Taylor'
Cc: behave <at> ietf.org
Subject: Re: [BEHAVE] Fwd: New Version Notification for
draft-tsou-multicast-transition-taxonomy-00

-----Original Message-----
From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On
Behalf Of Stig Venaas
Sent: Wednesday, March 02, 2011 11:41 AM
To: Tom Taylor
Cc: behave <at> ietf.org
Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-
multicast-transition-taxonomy-00

On 3/1/2011 8:00 AM, Tom Taylor wrote:
We have prepared this document to help sort out the multicast
transition
work in the BEHAVE and SOFTWIRES WGs. Please have a look at and
comment
on the conclusions.

A good well written document :)

Agreed.

I would not use the term Multicast Topology for ASM vs SSM. Topology is
more used for network topology... ASM and SSM are generally I think,
referred to as different multicast service models. I would suggest
using
that term.

That is the only change I would suggest in the draft.

Some comments regarding ID.venaas-mcast46 though. It can be used
together with ID.boucadair-64-multicast-address-format, and I plan
to update it with a reference to that. This is maybe obvious though.

Tom, tt would be really valuable if you could email all of the
authors of the various drafts and ask them to review
draft-tsou-multicast-transition-taxonomy, to ensure their documents
are all accurately summarized.

-d

It is correct that it is from 2008. Although not relevant, I feel like
pointing out that the draft is very close to
draft-venaas-mboned-v4v6mcastgw-00.txt from 2003.

Stig

_______________________________________________
Behave mailing list
Behave <at> ietf.org
https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
Behave <at> ietf.org
https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
Behave <at> ietf.org
https://www.ietf.org/mailman/listinfo/behave



<div>Hi Tom,<br><br>Sorry, I don't follow you point.<br><br>For ASM, we mean "Any-Source Multicast". The statement below is just to clarify that for example, in practical deployment of the scheme, the broadband subscribers are not allowed to source the multicast traffic. Other things like, RP, Source Registration, of ASM are all taken into account.<br><br><br>Cheers,<br>Jacni<br><br><div class="gmail_quote">On Fri, Mar 4, 2011 at 12:06 PM, Tom Taylor <span dir="ltr">&lt;<a href="mailto:tom111.taylor <at> bell.net">tom111.taylor <at> bell.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
This is a point to be discussed. Our criterion for whether ASM was addressed was whether sources were allowed in network A. You discussed ASM in network C, and the table records this fact, but your introduction has the following statement:<br><br>
 &nbsp;"This document does not cover the case where an IPv4 host connected to<br>
 &nbsp; a CPE served by a DS-Lite AFTR can be the source of multicast<br>
 &nbsp; traffic."<br><br>
Should we classify by a different criterion than the one we used?<div>
<div></div>
<div class="h5">
<br><br><br>
On 03/03/2011 3:59 AM, Jacni Qin wrote:<br><blockquote class="gmail_quote">
Hi Tina,<br><br>
Thanks for writing the document, please see below my comments.<br><br>
For the discussions about draft-qin-softwire-dslite-multicast in Section 3,<br>
Acctually, both ASM and SSM are covered everytime when some points are<br>
discussed, for example, Address mapping, mB4, mAFTR.<br>
Particularly, the authors spent a lot of efforts on the ASM deployment<br>
issues encounterd in Section 7.<br>
So, please update the text related, also that in the Table 1, thanks.<br><br><br>
Cheers,<br>
Jacni<br><br><br>
On Thu, Mar 3, 2011 at 5:32 AM, Tina Tsou&lt;<a href="mailto:tena <at> huawei.com" target="_blank">tena <at> huawei.com</a>&gt; &nbsp;wrote:<br><br><blockquote class="gmail_quote">
Hi Dan,<br>
We have emailed all of the authors of the various drafts and ask them to<br>
review draft-tsou-multicast-transition-taxonomy.<br><br><br>
We keep our promises with one another - no matter what!<br><br>
Best Regards,<br>
Tina TSOU<br><a href="http://tinatsou.weebly.com/contact.html" target="_blank">http://tinatsou.weebly.com/contact.html</a><br><br><br>
-----Original Message-----<br>
From: <a href="mailto:behave-bounces <at> ietf.org" target="_blank">behave-bounces <at> ietf.org</a> [mailto:<a href="mailto:behave-bounces <at> ietf.org" target="_blank">behave-bounces <at> ietf.org</a>] On Behalf<br>
Of<br>
Dan Wing<br>
Sent: Wednesday, March 02, 2011 12:20 PM<br>
To: 'Stig Venaas'; 'Tom Taylor'<br>
Cc: <a href="mailto:behave <at> ietf.org" target="_blank">behave <at> ietf.org</a><br>
Subject: Re: [BEHAVE] Fwd: New Version Notification for<br>
draft-tsou-multicast-transition-taxonomy-00<br><br><blockquote class="gmail_quote">
-----Original Message-----<br>
From: <a href="mailto:behave-bounces <at> ietf.org" target="_blank">behave-bounces <at> ietf.org</a> [mailto:<a href="mailto:behave-bounces <at> ietf.org" target="_blank">behave-bounces <at> ietf.org</a>] On<br>
Behalf Of Stig Venaas<br>
Sent: Wednesday, March 02, 2011 11:41 AM<br>
To: Tom Taylor<br>
Cc: <a href="mailto:behave <at> ietf.org" target="_blank">behave <at> ietf.org</a><br>
Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-≤br>
multicast-transition-taxonomy-00<br><br>
On 3/1/2011 8:00 AM, Tom Taylor wrote:<br><blockquote class="gmail_quote">
We have prepared this document to help sort out the multicast<br>
transition<br>
work in the BEHAVE and SOFTWIRES WGs. Please have a look at and<br>
comment<br>
on the conclusions.<br>
</blockquote>
<br>
A good well written document :)<br>
</blockquote>
<br>
Agreed.<br><br><blockquote class="gmail_quote">
I would not use the term Multicast Topology for ASM vs SSM. Topology is<br>
more used for network topology... ASM and SSM are generally I think,<br>
referred to as different multicast service models. I would suggest<br>
using<br>
that term.<br><br>
That is the only change I would suggest in the draft.<br><br>
Some comments regarding ID.venaas-mcast46 though. It can be used<br>
together with ID.boucadair-64-multicast-address-format, and I plan<br>
to update it with a reference to that. This is maybe obvious though.<br>
</blockquote>
<br>
Tom, tt would be really valuable if you could email all of the<br>
authors of the various drafts and ask them to review<br>
draft-tsou-multicast-transition-taxonomy, to ensure their documents<br>
are all accurately summarized.<br><br>
-d<br><br><blockquote class="gmail_quote">
It is correct that it is from 2008. Although not relevant, I feel like<br>
pointing out that the draft is very close to<br>
draft-venaas-mboned-v4v6mcastgw-00.txt from 2003.<br><br>
Stig<br><br>
_______________________________________________<br>
Behave mailing list<br><a href="mailto:Behave <at> ietf.org" target="_blank">Behave <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/behave" target="_blank">https://www.ietf.org/mailman/listinfo/behave</a><br>
</blockquote>
<br>
_______________________________________________<br>
Behave mailing list<br><a href="mailto:Behave <at> ietf.org" target="_blank">Behave <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/behave" target="_blank">https://www.ietf.org/mailman/listinfo/behave</a><br><br>
_______________________________________________<br>
Behave mailing list<br><a href="mailto:Behave <at> ietf.org" target="_blank">Behave <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/behave" target="_blank">https://www.ietf.org/mailman/listinfo/behave</a><br><br>
</blockquote>
<br>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
Permalink | Reply |
headers
Tom Taylor | 7 Mar 2011 14:13

Re: Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00

Noting a restriction on practical deployment is fine, but it is a limit 
on the applicability of your document. I'm sure there are potential 
scenarios (e.g., campus environment) where ASM is a practical necessity.

On 07/03/2011 1:26 AM, Jacni Qin wrote:
> Hi Tom,
>
> Sorry, I don't follow you point.
>
> For ASM, we mean "Any-Source Multicast". The statement below is just to
> clarify that for example, in practical deployment of the scheme, the broadband
> subscribers are not allowed to source the multicast traffic. Other things
> like, RP, Source Registration, of ASM are all taken into account.
>
>
> Cheers,
> Jacni
>
Permalink | Reply |

Gmane