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

Hi Stig,
Please see inline.

-----Original Message-----
From: Stig Venaas [mailto:stig@venaas.com] 
Sent: Wednesday, March 21, 2012 10:18 PM
To: Zhouqian (Cathy)
Cc: Ronald Bonica; mboned@ietf.org
Subject: Re: [MBONED] draft-zhou-mboned-multrans-path-optimization

On 21.03.2012 00:46, Zhouqian (Cathy) wrote:
> Hi Stig,
> Please see inline.

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.

Right, so the idea is to have knowledge that the v4 and the v6 streams
are the same, and doing something like assert, right? I can see how this
could be done since the translator knows based on the v4 and v6 (S,G)s
that they are the same.

[Cathy]: Yes, we use PIM assert message.

But if you do something like assert, you need to make sure you have
comparable metrics for v4 and v6. Which certainly can be done, but I'm
pointing out that it is a requirement.

If you do something like assert though, you need to make sure that the
other PIM devices on the link also support this.

[Cathy]: Agree.

Stig

> 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