Subject: [MBONED] draft-tsou-mboned-multrans-addr-acquisition-01

From: Tina TSOU <[email-masked]>
Date: Wed, 2 May 2012 18:57:34 +0000

Now that the multicast transition framework document is officially accepted, is the Working Group prepared also to take on the topic of address acquisition, which is one of the tasks it identifies?
If so, would draft-tsou-mboned-multrans-addr-acquisition-01 be acceptable as a starting point?

Tina

---

From: Tina TSOU <[email-masked]>
Date: Thu, 10 May 2012 17:49:19 +0000

Dear chairs,
Would you ask the WG for adoption of draft-tsou-mboned-multrans-addr-acquisition-01 as WG document?

Thank you and have a good day.

Tina and co-authors

From: Tina TSOU
Sent: Wednesday, May 02, 2012 11:58 AM
To: [email-masked]
Subject: draft-tsou-mboned-multrans-addr-acquisition-01

Tina

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 14 May 2012 13:24:23 -0700

We would like to poll the WG to decide if 
draft-tsou-mboned-multrans-addr-acquisition-01 should be adopted as an 
MBONED document.  Please respnd by May 29 if you thing this doc should or 
should not be adopted by MBONED.

-MBONED Chairs

On Thu, 10 May 2012, Tina TSOU wrote:

-) Dear chairs,
-) Would you ask the WG for adoption of draft-tsou-mboned-multrans-addr-acquisition-01 as WG document?
-) 
-) Thank you and have a good day.
-) 
-) Tina and co-authors
-) 
-) From: Tina TSOU
-) Sent: Wednesday, May 02, 2012 11:58 AM
-) To: [email-masked]
-) Subject: draft-tsou-mboned-multrans-addr-acquisition-01
-) 
-) 
-) Now that the multicast transition framework document is officially accepted, is the Working Group prepared also to take on the topic of address acquisition, which is one of the tasks it identifies?
-) If so, would draft-tsou-mboned-multrans-addr-acquisition-01 be acceptable as a starting point?
-) 
-) Tina
-) 
-)

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 14 May 2012 20:55:45 +0000

Quick question to the authors. Why not the network preconfigure the IPv6
address from the v4 address and  give both IPv4 and IPv6 addresses to the
receivers and let the endpoint choose?

From:  Tina TSOU <[email-masked]>
Date:  Thursday, May 10, 2012 1:49 PM
To:  Leonard Giuliano <[email-masked]>, Greg Shepherd <[email-masked]>
Cc:  "[email-masked]'" <[email-masked]>
Subject:  Re: [MBONED] draft-tsou-mboned-multrans-addr-acquisition-01

Dear chairs,
Would you ask the WG for adoption of
draft-tsou-mboned-multrans-addr-acquisition-01 as WG document?

Tina and co-authors

From: Tina TSOU 
 
Now that the multicast transition framework document is officially accepted,
is the Working Group prepared also to take on the topic of address
acquisition, which is one of the tasks it identifies?
If so, would draft-tsou-mboned-multrans-addr-acquisition-01 be acceptable as
a starting point?
 
Tina

---

From: Tom Taylor <[email-masked]>
Date: Mon, 14 May 2012 20:27:23 -0400

I believe that is the "administrative preparation" strategy described in 
the document.

Tom Taylor

> receivers and let the endpoint choose?
...

---

From: Jacni Qin <[email-masked]>
Date: Tue, 15 May 2012 09:46:58 +0800

Hi authors,

Some questions about the "possible solutions" proposed,

3.1, as stated by itself, probably not reasonable from implementation 
standpoint.

For 3.2 and the first approach in 3.3, I guess they're ALGs, and IMHO, 
the discussions in Section 4.1 of the 
http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00, are 
sufficient.

About the second approach in 3.3, not sure I fully understand it yet, 
but so far I see it also a kind of ALG.

Cheers,
Jacni

On 5/11/2012 Friday 1:49 AM, Tina TSOU wrote:
> *From:*Tina TSOU
> *Sent:* Wednesday, May 02, 2012 11:58 AM
> *To:* [email-masked]
> *Subject:* draft-tsou-mboned-multrans-addr-acquisition-01
>
> Now that the multicast transition framework document is officially 
> accepted, is the Working Group prepared also to take on the topic of 
> address acquisition, which is one of the tasks it identifies?
>
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Tue, 15 May 2012 06:32:10 +0000

I support adopting this document as a WG document.

Best Regards,
Cathy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leonard Giuliano
Sent: Tuesday, May 15, 2012 4:24 AM
To: MBONED WG
Subject: Re: [MBONED] draft-tsou-mboned-multrans-addr-acquisition-01

-MBONED Chairs

-) Dear chairs,

---

From: <[email-masked]>
Date: Tue, 15 May 2012 13:30:27 +0200

Dear all,

I do personally see a value to publish this document as a WG it; mainly the discussion about potential extension to SDP to convey both IPv4 and IPv6 addresses.

I support the adoption of this document.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] 
>De la part de Leonard Giuliano
>Envoyé : lundi 14 mai 2012 22:24
>À : MBONED WG
>Objet : Re: [MBONED] draft-tsou-mboned-multrans-addr-acquisition-01
>
>
>-) Would you ask the WG for adoption of 
>-) Now that the multicast transition framework document is 
>officially accepted, is the Working Group prepared also to 
>take on the topic of address acquisition, which is one of the 
>tasks it identifies?

---

From: Tina TSOU <[email-masked]>
Date: Tue, 15 May 2012 20:24:36 +0000

Tina

From: Jacni Qin [mailto:[email-masked]]
Sent: Monday, May 14, 2012 6:47 PM
To: Tina TSOU
Cc: Leonard Giuliano; Greg Shepherd; [email-masked]'
Subject: Re: [MBONED] draft-tsou-mboned-multrans-addr-acquisition-01

Hi authors,

3.1, as stated by itself, probably not reasonable from implementation standpoint.

For 3.2 and the first approach in 3.3, I guess they're ALGs, and IMHO, the discussions in Section 4.1 of the http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00, are sufficient.

[Tina] R u suggesting that the Problem Statement is going too far into solution descriptions and should be cut back?

About the second approach in 3.3, not sure I fully understand it yet, but so far I see it also a kind of ALG.

Cheers,
Jacni

Tina and co-authors

From: Tina TSOU
Sent: Wednesday, May 02, 2012 11:58 AM
To: [email-masked]<mailto:[email-masked]>
Subject: draft-tsou-mboned-multrans-addr-acquisition-01

Tina

MBONED mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 15 May 2012 17:07:41 -0500

Tina et al,

I also support this effort. A couple of comments:

My reaction to the Reactive Strategy in 3.1 was that it's too hard. Instead of making the IPv4 receiver kludge up IPv6 addresses, presumably kludge up MLD(?), and then convert IPv6 multicasts, why not just install an IPv6 stack in that receiver? (And yet, the counter to this is that Microsoft Office 2003 is capable of ingesting Office 2007 files quite well, and maybe even Office 2010 files, and all done in the "receiver." Still, Office suites are expensive for users, whereas IP stacks are not.)

The Dynamic Modification in 3.2, by the network, seems to be a more realistic option.

The Administrative Preparation in 3.3 seems to be an elaboration of 3.2. It merely adds a description of mechanisms that may be used to obtain info on the receiver, where 3.2 only said:

   It requires that an element in that network must
   intercept program guide information destined to the receiver, locate
   the access information, and map IP addresses to an alternate version
   as necessary to suit the receiver.

Isn't 3.3 describing HOW the network knows to "suit the receiver"?

Another option would be for the network to transfer both multicasts, and simply respond according to whether the receiver used IGMP or MLD to join the multicast. And the receiver would know the appropriate IPv4 or IPv6 multicast group (and potentially source IP) using OOB means, like the EPG itself, or the EPG plus an associated SIP session, or EPG plus SDP. (Wasn't there a discussion some time ago about "why use SDP anymore?") Assuming bandwidth isn't in very short supply, my own approach would be either to get both versions from the source, or to create the other version at the initial ingress point to my network.

Bert

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jacni Qin
Sent: Monday, May 14, 2012 9:47 PM
To: Tina TSOU
Cc: [email-masked]'
Subject: Re: [MBONED] draft-tsou-mboned-multrans-addr-acquisition-01

Hi authors,

Cheers,
Jacni

Tina and co-authors

From: Tina TSOU

Tina

MBONED mailing list

---

From: Jacni Qin <[email-masked]>
Date: Wed, 16 May 2012 08:44:15 +0800

Re-,

On 5/16/2012 Wednesday 4:24 AM, Tina TSOU wrote:
>
> Tina
>
> *From:*Jacni Qin [mailto:[email-masked]]
> *Sent:* Monday, May 14, 2012 6:47 PM
> *To:* Tina TSOU
> *Cc:* Leonard Giuliano; Greg Shepherd; [email-masked]'
> *Subject:* Re: [MBONED] draft-tsou-mboned-multrans-addr-acquisition-01
>
> Hi authors,
>
> For 3.2 and the first approach in 3.3, I guess they're ALGs,
>
Sorry, some words missed, "... they're ALGs and manual configuration, ..."

> and IMHO, the discussions in Section 4.1 of the 
> [Tina] R u suggesting that the Problem Statement is going too far into 
> solution descriptions and should be cut back?
>
No, I don't think most of these are solutions, but just sort of analysis 
of deployment, to describe issues/problems maybe encountered, which have 
been discussed sufficiently in the Problem Statement.

Cheers,
Jacni
> *To:* [email-masked] <mailto:[email-masked]>
> [email-masked]  <mailto:[email-masked]>

---

From: Tom Taylor <[email-masked]>
Date: Wed, 16 May 2012 21:07:50 -0400

I believe the subject draft should be adopted as a work item. In 
response to Jacni Qin, I note that the absence of such a document led to 
extensive discussion of the topic in the interim meeting, despite its 
treatment in the problem statement draft. This, I think, is a clear 
indication that something more had to be said.

The question of whether receiver modification is in scope has come up in 
prior discussion. I think there should be a clear statement of the 
following in the introduction to the draft:

(1) The most straightforward solution to the acquisition problem is to 
make receivers dual-stack. That is, the receiver can extract IP 
addresses from the EPG regardless of their version and join and leave 
streams using either IGMP/IPv4 or MLD/IPv6 depending on the supplied 
addresses.

(2) Any solution that involves more costly changes to the receiver than 
making it dual-stack as just defined is therefore probably uneconomic.

This is why the degree of receiver modification required is a 
consideration for the different solution approaches.

One final remark: the current version of the draft doesn't necessarily 
cover all the possibilities, and one would hope the WG might add input 
to make it more inclusive. But it is probably a good start.

Tom Taylor

---

From: Jacni Qin <[email-masked]>
Date: Thu, 17 May 2012 11:15:36 +0800

hi,

On 5/17/2012 Thursday 9:07 AM, Tom Taylor wrote:
> response to Jacni Qin, I note that the absence of such a document led
> to extensive discussion of the topic in the interim meeting, despite
> its treatment in the problem statement draft. This, I think, is a
> clear indication that something more had to be said.
>
Except for the extension mentioned in the second approach of 3.3, I
still can't see anything new than what have been discussed in the
Section 4 of Problem Statement,
http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#page-18

>
> The question of whether receiver modification is in scope has come up
> in prior discussion. 
Thanks for the information.

Cheers,
Jacni

> I think there should be a clear statement of the following in the
> introduction to the draft:
>
> (2) Any solution that involves more costly changes to the receiver
> than making it dual-stack as just defined is therefore probably
> uneconomic.
>

---

From: Tina TSOU <[email-masked]>
Date: Thu, 24 May 2012 16:01:48 +0000

Bert,
Thank you for your support.

What you are saying suggests that it is only the third part of the existing document that makes real sense to an operator considering the problem of address acquisition. Maybe the document has to be organized differently. Instead of looking at theoretical approaches to the problem, maybe it should look at what might work for specific operator scenarios. We could think about what are the relevant variables to describe these scenarios. Whether the source and receiver support the same IP version is obviously one aspect, and whether the source is under the control of the provider (so that the provider can control address mapping.) Then there are the variations in architecture for creation and provision of the EPG.

Does this seem to be on the right track?

Tina

On May 15, 2012, at 3:07 PM, "Manfredi, Albert E" <[email-masked]<mailto:[email-masked]>> wrote:

Tina et al,

My reaction to the Reactive Strategy in 3.1 was that it’s too hard. Instead of making the IPv4 receiver kludge up IPv6 addresses, presumably kludge up MLD(?), and then convert IPv6 multicasts, why not just install an IPv6 stack in that receiver? (And yet, the counter to this is that Microsoft Office 2003 is capable of ingesting Office 2007 files quite well, and maybe even Office 2010 files, and all done in the “receiver.” Still, Office suites are expensive for users, whereas IP stacks are not.)

Isn’t 3.3 describing HOW the network knows to “suit the receiver”?

Another option would be for the network to transfer both multicasts, and simply respond according to whether the receiver used IGMP or MLD to join the multicast. And the receiver would know the appropriate IPv4 or IPv6 multicast group (and potentially source IP) using OOB means, like the EPG itself, or the EPG plus an associated SIP session, or EPG plus SDP. (Wasn’t there a discussion some time ago about “why use SDP anymore?”) Assuming bandwidth isn’t in very short supply, my own approach would be either to get both versions from the source, or to create the other version at the initial ingress point to my network.

Bert

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jacni Qin
Sent: Monday, May 14, 2012 9:47 PM
To: Tina TSOU
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [MBONED] draft-tsou-mboned-multrans-addr-acquisition-01

Hi authors,

Cheers,
Jacni

Tina and co-authors

From: Tina TSOU

Tina

MBONED mailing list

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 24 May 2012 15:02:00 -0500

Tina, yes, that sounds good to me. I think theoretical approaches that have little practical value, like trying to backfit an IPv4 device to do IPv6 MLD and then IPv6 to IPv4 packet translation, end up creating more confusion than explaining anything, IMO.

Also, for multicast, I would think that the provider can control address mapping regardless of whether the source is under his control or not? In some cases, the provider may not need to, especially with IPv6 to IPv6 multicasts, but that aside, the ISP should always be able to map IP multicast groups from a source to some other multicast address, no?

Bert

From: Tina TSOU [mailto:[email-masked]]
Sent: Thursday, May 24, 2012 12:02 PM
To: Manfredi, Albert E
Cc: [email-masked]
Subject: Re: [MBONED] draft-tsou-mboned-multrans-addr-acquisition-01

Bert,

Tina

Bert

Hi authors,

Cheers,
Jacni

Tina and co-authors

From: Tina TSOU

Tina

MBONED mailing list

---

From: Tina TSOU <[email-masked]>
Date: Fri, 25 May 2012 03:11:48 +0000

I had in mind some interaction between the translations used in the signalling and data planes and the translation used in the EPG, but as you say, the operator can always re-translate if necessary.

Tina

On May 24, 2012, at 1:02 PM, "Manfredi, Albert E" <[email-masked]<mailto:[email-masked]>> wrote:

Bert

From: Tina TSOU [mailto:[email-masked]]
Sent: Thursday, May 24, 2012 12:02 PM
To: Manfredi, Albert E
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MBONED] draft-tsou-mboned-multrans-addr-acquisition-01

Bert,

Tina

Bert

Hi authors,

Cheers,
Jacni

Tina and co-authors

From: Tina TSOU

Tina

MBONED mailing list

---

From: Qiong <[email-masked]>
Date: Mon, 28 May 2012 17:26:21 +0800

Dear all,

I support the adoption for this document. I do think it would be a usable
extension to SDP.

Best wishes
Qiong

On Tue, May 15, 2012 at 7:30 PM, <[email-masked]> wrote:

> Dear all,
>
> I do personally see a value to publish this document as a WG it; mainly
> the discussion about potential extension to SDP to convey both IPv4 and
> IPv6 addresses.
>

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 29 May 2012 03:59:16 +0000

+1, support the WG adoption.

Sheng

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Tuesday, May 15, 2012 7:30 PM
> To: Leonard Giuliano; MBONED WG