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

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" <albert.e.manfredi@boeing.com<mailto:albert.e.manfredi@boeing.com>> wrote:

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:Tina.Tsou.Zouting@huawei.com]
Sent: Thursday, May 24, 2012 12:02 PM
To: Manfredi, Albert E
Cc: mboned@ietf.org<mailto:mboned@ietf.org>
Subject: Re: [MBONED] draft-tsou-mboned-multrans-addr-acquisition-01

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" <albert.e.manfredi@boeing.com<mailto:albert.e.manfredi@boeing.com>> wrote:
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> [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<mailto: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