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

["Lee, Yiu" <[e-mail]>]

Hi Stig,

On 3/23/12 1:17 PM, "Stig Venaas" <[e-mail]> wrote:

>On 3/22/2012 8:16 PM, Zhouqian (Cathy) wrote:
>> Sorry, I mean the v4 and v6 interface, rather than the source in my
>>last email.
>> Yes, there will be two streams coming from the source. When the two
>>streams coming from v4 and v6 interface separately, MTR will determine
>>whether the two addresses (v4 and v6) have the address format based on
>>draft-ietf-mboned-64-multicast-address-format. If the v6 address is
>>v4-embedded v6 address according to the draft, it means the two streams
>>are the same. If it is not, the two steams are different.
>> Then the two streams will come to different receivers.
>
>The scenario I find the most interesting is a bit similar to what you
>describe I think.
>
>Imagine you have a router supporting IPv4 PIM and IPv6 PIM that is
>translation capable. Imagine that it receives IPv4 join (PIM or
>IGMP) on one interface, and an IPv6 join (PIM or MLD) on another
>interface. It could even be the same interface...
>
>Assume these joins are for (S4,G4) and (S6,G6), and that there
>are active sources for both, sending basically the same content.
>Either because there is a real source for both, or some upstream
>router is translating.
>
>The router could then simply send upstream joins for both of these,
>and forward the traffic as needed without translation.
>
>But if the router is aware that these two are really the same content,
>it could in theory join just one of the streams, and translate as
>needed for the one downstream that wants a different protocol. We
>basically will have a tradeoff between bandwidth on the upstream
>links, and the cost of translation (both on this device, and perhaps
>the quality of the stream).

[YL] Agree about the trade-off. In the Taipei demo, it seems the header
translation is relatively cheap.

>
>One concern I have though, is that if say the stream is originally
>(S4,G4) but this router decides to join only (S6,G6), then we may
>end up translating twice. If possible, the router should know how
>to choose the non-translated source.
>
>Also note that if this router chooses to join both (S4,G4) and (S6,G6),
>then somewhere upstream there may be translation from IPv4 to IPv6 to
>provide this content. And we're sort of wasting bandwidth by having two
>identical streams coming down to this router.
>
>If this router only joined (S4,G4), and did translation itself, then
>translation would still occur only in one place, and you would not
>waste bandwidth. Basically it is good to translate as close to the
>receiver as possible (I think).
>
>Note that when I say translation in one place, I mean only once on the
>path from the source to a particular receiver. There is also a
>trade-off with bandwidth and translation cost whether you do it close
>to the source so that perhaps only one device does the translation for
>all the content, or whether you do it close to the receivers so that
>there may be multiple devices, each on a different receiver branch,
>translating the same data.
>
>One final thought. Somehow having two identical streams (S4,G4) and
>(S6,G6) can actually help provide redundancy, as long as they can
>be translated as needed.


[YL] I try to understand the network topology. When we develop the problem
statement and framework, we focus on 4-6-4, 6-4 and 6-4-6-4. We didn't
discuss the deployment scenario where we have mixed receivers and mixed
sources in a dual-stack network. This is an interesting deployment
scenario but we will need to define a set of requirements and use cases
before tackling the solution. For example: you asked whether the router
should join (S4,G4) or join (S6,G6) and translate twice? I don't know. In
general, single translation is better than double.



>
>Stig
>
>> Best Regards,
>> Cathy ZHOU
>>
>>
>> -----Original Message-----
>> From: Lee, Yiu [mailto:[e-mail]]
>> Sent: Friday, March 23, 2012 10:42 AM
>> To: Zhouqian (Cathy); Stig Venaas
>> Cc: [e-mail]; Ronald Bonica
>> Subject: Re: [MBONED] draft-zhou-mboned-multrans-path-optimization
>>
>> You can't do that right? If I have a v4 receiver connected to the
>>v6-only
>> network, the v4 receiver has to receive stream from the S4 source. Or
>>you
>> suggest the access network will statefully convert the v6 group address
>>to
>> v4 group address?
>>
>>
>> On 3/22/12 10:31 PM, "Zhouqian (Cathy)"<[e-mail]>  wrote:
>>
>>> Hi Yiu,
>>> This solution is not only for transition, it also covers the pure v6
>>>case.
>>> About the content stream, there will be only one stream received by MTR
>>> because MTR makes comparison.
>>> If the path metric of v4 source>  path metric of v6 source, the MTR
>>>will
>>> choose the path of v6 source. Otherwise, it will choose v4 source.
>>> If the v4 metric=v6 metric, it will choose one of them.
>>>
>>> Best Regards,
>>> Cathy ZHOU
>>>
>>>
>>> -----Original Message-----
>>> From: Lee, Yiu [mailto:[e-mail]]
>>> Sent: Friday, March 23, 2012 10:07 AM
>>> To: Zhouqian (Cathy); Stig Venaas
>>> Cc: [e-mail]; Ronald Bonica
>>> Subject: Re: [MBONED] draft-zhou-mboned-multrans-path-optimization
>>>
>>> Hi Cathy,
>>>
>>> I am a little confused. Since MTR is for transitioning, why will it
>>> connect to the S6 in the first place? Besides, say you have two types
>>>of
>>> receivers (v4 and v6) connected to the v6-only network. At any given
>>>time,
>>> there are v4 and v6 receivers watching TV. In this setup, you will
>>>have to
>>> stream the content twice anyway because the group address will be
>>> different for native-v6 (v6 source) and v4-embedded v6 (v4 source).
>>>Did I
>>> get this wrong?
>>>
>>> Thanks,
>>> Yiu
>>>
>>>
>>> On 3/22/12 9:50 PM, "Zhouqian (Cathy)"<[e-mail]>  wrote:
>>>
>>>> There are two cases in Figure 1. One is v6 network connecting to both
>>>>v4
>>>> and v6 sources via MTR, which is in higher priority and is the main
>>>>case
>>>> of this document.
>