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

From: Ronald Bonica <[email-masked]>
Date: Wed, 14 Mar 2012 11:28:08 -0400

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

---

From: "Cathy Zhou(Qian)" <[email-masked]>
Date: Mon, 19 Mar 2012 09:18:23 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Wednesday, March 14, 2012 11:28 PM
To: [email-masked]
Subject: [MBONED] draft-zhou-mboned-multrans-path-optimization

Folks,

--------------------
Ron Bonica

_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 19 Mar 2012 10:39:14 -0400

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

> From: Cathy Zhou(Qian) [mailto:[email-masked]]
> Sent: Monday, March 19, 2012 5:18 AM
> To: Ronald Bonica; [email-masked]
> Subject: RE: [MBONED] draft-zhou-mboned-multrans-path-optimization
> 
> 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.
> 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

---

From: "Cathy Zhou(Qian)" <[email-masked]>
Date: Tue, 20 Mar 2012 08:26:51 +0000

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.

Best Regards,
Cathy ZHOU

-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]] 
Sent: Monday, March 19, 2012 10:39 PM
To: Cathy Zhou(Qian); [email-masked]
Subject: RE: [MBONED] draft-zhou-mboned-multrans-path-optimization

Hi Cathy,

                                               Ron

---

From: Stig Venaas <[email-masked]>
Date: Tue, 20 Mar 2012 10:19:28 -0700

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

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.

Stig

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 20 Mar 2012 14:22:34 -0400

Cathy,

It seems wrong to use the words "transition" and "optimization" in the same sentence. By definition, any investment in a transition technology is a "throw away" investment. Once the transition is complete, the investment yields no return.

Do we really want to optimize a technology that:

- has not yet been fully specified
- has not yet seen any deployment
- should be decommissioned as soon as possible

                                           Ron

> Sent: Tuesday, March 20, 2012 4:27 AM
> 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.
> 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
>

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Wed, 21 Mar 2012 07:46:56 +0000

Hi Stig,
Please see inline.

Best Regards,
Cathy ZHOU

-----Original Message-----
From: Stig Venaas [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2012 1:19 AM
To: Cathy Zhou(Qian)
Cc: Ronald Bonica; [email-masked]
Subject: Re: [MBONED] draft-zhou-mboned-multrans-path-optimization

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

[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

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Wed, 21 Mar 2012 08:06:07 +0000

Hi Ron,
How about we changing the title to "Multicast path optimization in IPv4 and IPv6 networks"?
In fact, this problem not only exists in the translator case, but also in the pure IPv6 case. 
As I replied to Stig's comments, this idea comes from RFC4601, which talks about IPv4 case. 
We hope to solve similar problems in both translator and pure IPv6 cases.

Best Regards,
Cathy ZHOU

-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2012 2:23 AM
To: Cathy Zhou(Qian); [email-masked]
Subject: RE: [MBONED] draft-zhou-mboned-multrans-path-optimization

Cathy,

                                           Ron

---

From: Stig Venaas <[email-masked]>
Date: Wed, 21 Mar 2012 07:18:06 -0700

Please see inline.
> [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 exi…

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.

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.

Stig

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 21 Mar 2012 11:01:29 -0400

Cathy,

If you divorce the problem of path optimization from the problem of v6 transition, it might be worthwhile to ask the WG if there is interest.

                                             Ron

> From: Zhouqian (Cathy) [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2012 4:06 AM
> It seems wrong to use the words "transition" and "optimization" in the
> same sentence. By definition, any investment in a transition technology
> is a "throw away" investment. Once the transition is complete, the
> investment yields no return.
> 
> > > 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

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Thu, 22 Mar 2012 09:23:44 +0000

Hi Stig,
Please see inline.

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

Please see inline.

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

[Cathy]: Agree.

Stig

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 22 Mar 2012 23:09:11 +0000

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)" <[email-masked]> wrote:

>>interworking are mainly discussed. Routing issues are not considered yet.
>[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,
>[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
>>
>>
>>deploy and configure AFs in a manner that will prevent the problems that
>>you are attempting to solve?
>>
>>                                                 Ron
>>

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Fri, 23 Mar 2012 01:50:46 +0000

Hi Yiu,
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. 
The other case is v4 network connecting to both v4 and v6 sources via MTR, which is less common. In both cases, the MTR will not make translation/encapsulation when the source and network are in the same version, and if this is the best path after routing comparison. It may not be appropriate to call the router MTR. Do you have any suggestion for this, MR or ...?

Best Regards,
Cathy ZHOU

-----Original Message-----
From: Lee, Yiu [mailto:[email-masked]] 
Sent: Friday, March 23, 2012 7:09 AM
To: Zhouqian (Cathy); Stig Venaas
Cc: [email-masked]; Ronald Bonica
Subject: Re: [MBONED] draft-zhou-mboned-multrans-path-optimization

Hi Cathy,

Thanks,
Yiu

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 23 Mar 2012 02:07:24 +0000

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)" <[email-masked]> 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.

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Fri, 23 Mar 2012 02:31:25 +0000

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:[email-masked]] 
Sent: Friday, March 23, 2012 10:07 AM
To: Zhouqian (Cathy); Stig Venaas
Cc: [email-masked]; Ronald Bonica
Subject: Re: [MBONED] draft-zhou-mboned-multrans-path-optimization

Hi Cathy,

Thanks,
Yiu

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 23 Mar 2012 02:42:26 +0000

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)" <[email-masked]> wrote:

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

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Fri, 23 Mar 2012 03:16:18 +0000

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. 

Best Regards,
Cathy ZHOU

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 23 Mar 2012 03:32:17 +0000

The whole assumption is the v4 stream has been converted once in the upper
network. In other words, this optimization only helps in a back-to-back
MTR. This is really a rare scenario.

On 3/22/12 11:16 PM, "Zhouqian (Cathy)" <[email-masked]> wrote:

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

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Fri, 23 Mar 2012 04:09:23 +0000

Yes, the v4 stream will be converted to v6 stream. 
What do you mean "back-to-back"? Do you mean the two MTRs are back-to-back? The first MTR will convert the v4 stream to v6 stream and send the v6 stream to the second MTR, which will just copy it to the v6 network?
In addition, this document is not limited to this case, the multi-access scenario defined in RFC 4601 is also included.
Another advantage of this solution is that when IPv4 source transitions to IPv6 source, there will be no impact on the MTR. 

Best Regards,
Cathy ZHOU

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 23 Mar 2012 14:20:57 +0000

Hi Cathy,

Comment inlines:

On 3/23/12 12:09 AM, "Zhouqian (Cathy)" <[email-masked]> wrote:

>What do you mean "back-to-back"? Do you mean the two MTRs are
>back-to-back? The first MTR will convert the v4 stream to v6 stream and
>send the v6 stream to the second MTR, which will just copy it to the v6
>network?

[YL] Yes and I argue this is a rare scenario.

>In addition, this document is not limited to this case, the multi-access
>scenario defined in RFC 4601 is also included.
>Another advantage of this solution is that when IPv4 source transitions
>to IPv6 source, there will be no impact on the MTR.

[YL] I think it would be easier to understand the motivation if you can
include some high-level use cases in the drafts. Then we can compare them
in deployment and see how urgent we need to solve them.

B.R.,
Yiu

---

From: Stig Venaas <[email-masked]>
Date: Fri, 23 Mar 2012 09:54:31 -0700

One thing that perhaps worries me here, is that I think you
may end up translating multiple times between IPv4 and IPv6,
even if no translation is necessary.

I don't think you should simply compare metrics for IPv4 and IPv6 and
choose what is best. Or at least, there should be some additional cost
for the translation that is added to the metric. Doing translation adds
delay (and I would think jitter). Then there is also the issue of load
on the translator.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Fri, 23 Mar 2012 10:17:28 -0700

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

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

> On 3/22/12 10:31 PM, "Zhouqian (Cathy)"<[email-masked]>  wrote:
>
>> Hi Yiu,
>> On 3/22/12 9:50 PM, "Zhouqian (Cathy)"<[email-masked]>  wrote:
>>

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 23 Mar 2012 18:24:09 +0000

Hi Stig,

>the quality of the stream).

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

>(S6,G6) can actually help provide redundancy, as long as they can

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

---

From: Stig Venaas <[email-masked]>
Date: Fri, 23 Mar 2012 11:43:05 -0700

On 3/23/2012 11:24 AM, Lee, Yiu wrote:
> Hi Stig,
>
> On 3/23/12 1:17 PM, "Stig Venaas"<[email-masked]>  wrote:
>

I think mixed receivers in a dual-stack network will be common though.
We're talking about transition, and the reason we're doing translation
is that there are mixed receivers, right? And most IPv6 networks are
dual-stack.

We've been discussing simple scenarios where translators are placed
on borders between IPv4-only and IPv6-only networks, but I don't think
it is that simple. When parts of the network are dual-stack, you have
some choice where to deploy the translators.

I think the main question to ask is perhaps where translators would be
located. Some interesting things (as I tried to illustrate) might happen
with translators in multiple locations and trying to be clever...

> general, single translation is better than double.

Please don't get me wrong. I want to avoid translation as much as
possible. Hence I also want to avoid double translation, although it
might in some cases be better than tunneling.

Some general things to consider are IMO

1. Is it bad if multiple independent devices are performing the same
    translation of the same data?

    Translation at the source may guarantee it happens at most once.
    Translation further down the tree may result in multiple devices
    doing the same translation. Bandwidth is the main reason not to do
    it at the source in a dual-stack network.

2. With multiple translators, can we ensure that packets don't get
    double translated unnecessary?

    Basically if the network is dual-stack, can one make sure that
    there never will be more than one translator on the path between
    any source-receiver pair?

Stig

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 23 Mar 2012 22:14:51 +0000

Hi Stig,

>    any source-receiver pair?

These are interesting questions. IMHO, if we can deploy the translator
closer to the access network and connect the source directly to the
translator, this could be the most trivial setup. If the sources are
placed high-up in the network and multiple translators are involved, that
may require some intelligence in the translator. I agree what you said, we
may need more than simple matrix to design what situation the translate
should translate the stream. It is also not simple to decide a v6 stream
using native v6 address is equal to a v4 stream using v4-embedded v6
address in term on content. When we have a mixed environment, we need to
know what deployment problem we are trying to solve.

B.R.,
Yiu

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Mon, 26 Mar 2012 15:29:15 +0000

Hi Stig,
Please see inline.

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

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

Stig