Re: [MBONED] draft-zhou-mboned-multrans-path-optimization

Hi Cathy,

When I read Fig 1, I think the most important question is why MTR1 would
connect to IPv4 network? MTR should be deployed only when transitioning is
needed. If the source is v4, why need MTR to deliver v4 multicast to v4
network? I fail to see why.

Thanks,
Yiu

On 3/21/12 3:46 AM, "Zhouqian (Cathy)" <cathy.zhou@huawei.com> wrote:

>Hi Stig,
>Please see inline.
>
>Best Regards,
>Cathy ZHOU
>
>
>-----Original Message-----
>From: Stig Venaas [mailto:stig@venaas.com]
>Sent: Wednesday, March 21, 2012 1:19 AM
>To: Cathy Zhou(Qian)
>Cc: Ronald Bonica; mboned@ietf.org
>Subject: Re: [MBONED] draft-zhou-mboned-multrans-path-optimization
>
>On 3/20/2012 1:26 AM, Cathy Zhou(Qian) wrote:
>> Hi Ron,
>> It is possible to deploy and configure AFs to solve the problem. The
>>IPv6 router and IPv4 router mentioned in this document could be AFs.
>> But in the current AF document, the address translation and v4/v6
>>interworking are mainly discussed. Routing issues are not considered yet.
>> Our document proposed a possible way to solve such routing related
>>problems.
>
>It appears to me that it requires a translator to be more intelligent
>in making decisions on whether to translate or not, and does add some
>complexity. I'm also unsure how this would work if there are multiple
>translators making such decisions independently. Would this require
>IPv4 and IPv6 routing to use comparable metrics? This is not
>necessarily the case today.
>
>[Cathy]It does add some complexity, but not much. The only complexity is
>the metric value added in the router for translation or encapsulation.
>If there are multiple translators, the IPv4 and IPv6 routing metrics
>could be different for different translators. The decision of the router
>is based on the comparison result of metric value for each path.
>In addition, in our case, v4/v6 translation is not necessarily needed.
>When the source is IPv6, for example, the network is also IPv6, there may
>be two multicast flows. In this case,
>We can compare the two metrics and select an optimized path for the
>multicast flow.
>
>
>The few translator implementations I know don't do this. But it is
>worth considering how useful this is, and if it is, how it can be done.
>
>I feel it may be a bit early to discuss at this point. I see it mostly
>as an optimization than can be considered later. It is an interesting
>problem though.
>
>[Cathy]This idea basically comes from RFC4601, when duplicate IPv4
>multicast flows exist. In the transition stage when both IPv4 and IPv6
>flows exist, or in the future when duplicate IPv6 flows exist, we need to
>consider this problem.
>
>Stig
>
>>
>> Best Regards,
>> Cathy ZHOU
>>
>>
>> -----Original Message-----
>> From: Ronald Bonica [mailto:rbonica@juniper.net]
>> Sent: Monday, March 19, 2012 10:39 PM
>> To: Cathy Zhou(Qian); mboned@ietf.org
>> Subject: RE: [MBONED] draft-zhou-mboned-multrans-path-optimization
>>
>> Hi Cathy,
>>
>> At this point, can you tell me for certain that it is impossible to
>>deploy and configure AFs in a manner that will prevent the problems that
>>you are attempting to solve?
>>
>>                                                 Ron
>>
>>> -----Original Message-----
>>> From: Cathy Zhou(Qian) [mailto:cathy.zhou@huawei.com]
>>> Sent: Monday, March 19, 2012 5:18 AM
>>> To: Ronald Bonica; mboned@ietf.org
>>> Subject: RE: [MBONED] draft-zhou-mboned-multrans-path-optimization
>>>
>>> Which AF behavior will pre-empt the entire issue?
>>> AF function defines v4-v6 interworking, but this draft does not depend
>>> on how AF functions. It can be applied in all transition cases
>>> involving 4<->6 conversion.
>>> So I think it can be processed in parallel with AF function definition.
>>>
>>> Best Regards,
>>> Cathy ZHOU
>>>
>>>
>>> -----Original Message-----
>>> From: mboned-bounces@ietf.org [mailto:mboned-bounces@ietf.org] On
>>> Behalf Of Ronald Bonica
>>> Sent: Wednesday, March 14, 2012 11:28 PM
>>> To: mboned@ietf.org
>>> Subject: [MBONED] draft-zhou-mboned-multrans-path-optimization
>>>
>>> Folks,
>>>
>>> Is it appropriate to address the problems raised by draft-zhou-mboned-
>>> multrans-path-optimization before the AF function has been defined? I
>>> could imagine at least one AF behavior that would pre-empt the entire
>>> issue.
>>>
>>> --------------------
>>> Ron Bonica
>>> //speaking as individual contributor
>>> vcard:       www.bonica.org/ron/ronbonica.vcf
>>>
>>>
>>> _______________________________________________
>>> MBONED mailing list
>>> MBONED@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mboned
>> _______________________________________________
>> MBONED mailing list
>> MBONED@ietf.org
>> https://www.ietf.org/mailman/listinfo/mboned
>
>_______________________________________________
>MBONED mailing list
>MBONED@ietf.org
>https://www.ietf.org/mailman/listinfo/mboned

Re: [MBONED] draft-zhou-mboned-multrans-path-optimization

Attachment: smime.p7s