[MBONED] 答复: draft-zhou-mboned-multrans-path-optimization

["Zhouqian (Cathy)" <[e-mail]>]

Hi Stig,
Please see inline.

________________________________________
发件人: Stig Venaas [[e-mail]]
发送时间: 2012年3月24日 1:17
到: Zhouqian (Cathy)
Cc: Lee, Yiu; [e-mail]; Ronald Bonica
主题: Re: [MBONED] draft-zhou-mboned-multrans-path-optimization

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).

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).

[Cathy] Agree that the router should join only one version (S,G) in order to avoid bandwidth waste. Based on the metrics, it can choose one best path. The metrics here not only consider the hops between devices, the bandwidth is also considered. If the hops are less, but the bandwidth is much larger, the router may choose the path with larger bandwidth capacity.
Also agree that the translation should be close to the receiver.

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.

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.