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

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: mboned-bounces@ietf.org [mailto:mboned-bounces@ietf.org] On Behalf Of Jacni Qin
Sent: Monday, May 14, 2012 9:47 PM
To: Tina TSOU
Cc: 'mboned@ietf.org'
Subject: Re: [MBONED] draft-tsou-mboned-multrans-addr-acquisition-01

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:
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: mboned@ietf.org<mailto:mboned@ietf.org>
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

_______________________________________________

MBONED mailing list

MBONED@ietf.org<mailto:MBONED@ietf.org>

https://www.ietf.org/mailman/listinfo/mboned