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

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