Subject: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00

From: Tom Taylor <[email-masked]>
Date: Tue, 1 Mar 2011 11:00:14 -0500

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 new version of I-D, draft-tsou-multicast-transition-taxonomy-00.txt 
has been successfully submitted by Tom Taylor and posted to the IETF 
repository.

Filename:	 draft-tsou-multicast-transition-taxonomy
Revision:	 00
Title:		 A Classification and Evaluation of Approaches to Transitional 
Multicast
Creation_date:	 2011-02-28
WG ID:		 Independent Submission
Number_of_pages: 12

Abstract:
A number of different contributions to the IETF make proposals in
support of multicast during the transition from IPv4 to IPv6.  This
document provides a taxonomic framework to make it easier to see how
the different proposals relate to each other.  It analyzes the
current work in progress in the light of this framework and draws a
number of conclusions regarding how this work should move forward in
the BEHAVE and SOFTWIRES Working Groups.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 02 Mar 2011 11:41:21 -0800

> work in the BEHAVE and SOFTWIRES WGs. Please have a look at and comment

A good well written document :)

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.

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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 2 Mar 2011 12:20:26 -0800

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

Agreed.

> 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

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Tina Tsou <[email-masked]>
Date: Wed, 02 Mar 2011 13:32:59 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Dan Wing
Sent: Wednesday, March 02, 2011 12:20 PM
To: 'Stig Venaas'; 'Tom Taylor'
Cc: [email-masked]
Subject: Re: [BEHAVE] Fwd: New Version Notification for
draft-tsou-multicast-transition-taxonomy-00

Agreed.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 2 Mar 2011 14:18:38 -0800

> From: Tina Tsou [mailto:[email-masked]]
> Sent: Wednesday, March 02, 2011 1:33 PM
> To: 'Dan Wing'; 'Stig Venaas'; 'Tom Taylor'
> Cc: [email-masked]
> Subject: RE: [BEHAVE] Fwd: New Version Notification for draft-tsou-
> We have emailed all of the authors of the various drafts and ask them
> to review draft-tsou-multicast-transition-taxonomy.

Great.  Thanks!
-d

> Behalf Of

---

From: Jacni Qin <[email-masked]>
Date: Thu, 3 Mar 2011 16:59:07 +0800

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 3 Mar 2011 12:53:44 -0800 (PST)

Hi Tom,
  Here are my comments.

First of all NAT64 multicast has been implemented in Teemu Kiviniemi's thesis, 
he announced it in Behave list more than once.

[ID.sarikaya-mcast4nat64] is based on this implementation. The thesis gives 
credit to [ID.venaas-mcast46] especially in address translation.

You mentioned that [ID.sarikaya-mcast4nat64]  has a number of useful details, 
these details are on protocol translation part. It is important to note that 
SIIT algorithm requires modifications for multicast protocol translation.

BTW, I have submitted a new version of this draft.

Regarding DS-Lite and 6rd, I think that totally different approaches are needed. 
I am going to submit a draft before the deadline expires.

Keep up the good work.

Regards,

Behcet

---

From: Tom Taylor <[email-masked]>
Date: Thu, 3 Mar 2011 23:06:59 -0500

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:
> On Thu, Mar 3, 2011 at 5:32 AM, Tina Tsou<[email-masked]>  wrote:
>
>> Hi Dan,

---

From: Stig Venaas <[email-masked]>
Date: Fri, 04 Mar 2011 11:31:04 -0800

> credit to [ID.venaas-mcast46] especially in address translation.

Yes, the implementation was based on [ID.venaas-mcast46]

Stig

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 4 Mar 2011 14:00:30 -0800 (PST)

> Yes, the  implementation was based on  [ID.venaas-mcast46]

It is a little overstatement, I think.

Yes, Stig has done pioneer work in this area, dating way back to 2003. Thanks 
Stig.

If you take away NAT46 part and add multicast data protocol translation you get 
something like [ID.sarikaya-mcast4nat64] which is based on Kiviniemi's thesis 
:-).

Regards,

Behcet

---

From: Stig Venaas <[email-masked]>
Date: Fri, 04 Mar 2011 14:33:20 -0800

> It is a little overstatement, I think.

All I know is what he told me. When he announced it on the behave wg
list last May he wrote:

The implementation follows the architectural ideas and address
translation presented in draft-venaas-behave-mcast46. IPv4 to IPv6
protocol translation is done using an adapted version of the SIIT
algorithm. IPv6 to IPv4 translation or unicast translation is not
supported.

So maybe it is just the ideas.

> something like [ID.sarikaya-mcast4nat64] which is based on Kiviniemi's thesis

There are not that many ways to do this. So there are going to be some
similarities either way. You can say that my draft is similar to NAT46
too I think...

Stig

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 4 Mar 2011 15:05:30 -0800 (PST)

> similarities either way. 

> You can say that my draft is similar to  NAT46
> too I think...

In "take away NAT46" above, NAT46 refers to what  [ID.venaas-mcast46] have in 
Sections 5.2 - 5.4 and 6.3 - 6.4.

i.e. IPv4 only host talking to IPv6 only servers.

Regards,

Behcet

---

From: Jacni Qin <[email-masked]>
Date: Mon, 7 Mar 2011 14:26:40 +0800

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 <[email-masked]> wrote:

> 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:
>

---

From: Tom Taylor <[email-masked]>
Date: Mon, 7 Mar 2011 08:13:24 -0500

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.