Subject: [MBONED] Multicast transition work in MBONED

From: Leonard Giuliano <[email-masked]>
Date: Thu, 7 Jun 2012 13:34:50 -0700

The multicast transition work within MBONED was initially intended to 
consist of ~ 3 document with limited scope.  In a very short amount of 
time, we've seen 7 drafts (and counting) with scope widening.

In order to make sure we are focusing on work that is of actual value to 
the community and prevent a flood of high volume/low value drafts, we 
would like to revisit the basic questions of multicast transition within 
MBONED.  We would like to hear answers from the WG to the following 
questions before continuing any work on multicast transition in MBONED:

1) Which operators intend to source multicast traffic from one IP version 
and receive it over another IP version?

2) For those who answer 1), please identify the use-cases of interest in 
draft-ietf-mboned-v4v6-mcast-ps so we can limit discussion to solutions 
for those use cases.

MBONED Chairs

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 7 Jun 2012 16:46:43 -0500

Hi guys,

1. For our shipboard networks, which are dual-stack, we intend to allow for IPv4 multicast sources to feed IPv6 clients, and vice versa. The networks are dual stack throughout, but the end systems are not likely to be. My preference is to send both v4 and v6 multicasts through the network, doing the conversion (if necessary) at the edge router connecting to the source.

2. Use cases 3.4 and 3.5.

Thanks!

Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leonard Giuliano
Sent: Thursday, June 07, 2012 4:35 PM
To: MBONED WG
Cc: Ronald Bonica
Subject: [MBONED] Multicast transition work in MBONED

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

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Fri, 8 Jun 2012 07:46:57 +0000

Hi Bert,
For the first case, please refer to my draft:
http://tools.ietf.org/html/draft-zhou-mboned-multrans-path-optimization-01
Your comments are welcome.

Best Regards,
Cathy
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Manfredi, Albert E
发送时间: 2012年6月8日 5:47
收件人: Leonard Giuliano; MBONED WG
抄送: Ronald Bonica
主题: Re: [MBONED] Multicast transition work in MBONED

Hi guys,

Thanks!

Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leonard Giuliano
Sent: Thursday, June 07, 2012 4:35 PM
To: MBONED WG
Cc: Ronald Bonica
Subject: [MBONED] Multicast transition work in MBONED

MBONED Chairs

---

From: Simon Perreault <[email-masked]>
Date: Fri, 08 Jun 2012 08:39:19 -0400

On 2012-06-07 17:46, Manfredi, Albert E wrote:
> 1. For our shipboard networks, which are dual-stack, we intend to
> allow for IPv4 multicast sources to feed IPv6 clients, and vice
> versa. The networks are dual stack throughout, but the end systems
> are not likely to be. My preference is to send both v4 and v6
> multicasts through the network, doing the conversion (if necessary)
> at the edge router connecting to the source.

Will that double the amount of multicast traffic in your network? If so, 
is it a problem?

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 8 Jun 2012 10:59:29 -0500

If you have a dual stack network both in unicast and multicast, it is
probably not very efficient but also you have no problem as well in
serving the users in both unicast and multicast in IPv4 and IPv6.

What would be more interesting is to hear from the land operators of
fixed and mobile networks.

I would add a Question 0 to Lenny's questions:

0. Which of the v6 transition technologies (NAT64, 6rd, DS-Lite, 4rd)
have you deployed or plan on deploying? Your interest in providing
multicast to the users of these transition technologies?

Regards,

Behcet

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 8 Jun 2012 14:26:52 -0500

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> Sent: Friday, June 08, 2012 8:39 AM
> To: [email-masked]
> Subject: Re: [MBONED] Multicast transition work in MBONED
> 

Yes, it could be double the bandwidth, if MLD and IGMP both indicate membership. For us, that's not a problem. What it means is that the IPv6 and IPv4 versions will go through the network along multicast trees that are optimized for each respective IP version.

The alternative approach is to allow sources to transmit either v4 or v6 multicasts, and then to do the translation at the destination edge routers, based on whether these edge routers receive IGMP or MLD join reports. In principle, that works too. But it's far messier. There's nothing easier than messing with the source side of the multicast, the way IP multicast works. The source always has the easiest job of all.

Bert

---

From: Antonio Querubin <[email-masked]>
Date: Sat, 9 Jun 2012 07:51:54 -1000 (HST)

> Yes, it could be double the bandwidth, if MLD and IGMP both indicate 
> membership. For us, that's not a problem. What it means is that the IPv6 
> and IPv4 versions will go through the network along multicast trees that 
> are optimized for each respective IP version.
>
> The alternative approach is to allow sources to transmit either v4 or v6 
> multicasts, and then to do the translation at the destination edge 
> routers, based on whether these edge routers receive IGMP or MLD join 
> reports. In principle, that works too. But it's far messier. There's 
> nothing easier than messing with the source side of the multicast, the 
> way IP multicast works. The source always has the easiest job of all.

I concur.  I had a similar problem a few years ago and went through the 
same analysis - and similar conclusion.  Either let the source stream in 
both IPv4 and IPv6 directly, or if the source isn't configurable that way, 
run a local translator directly on the source to do the translation.  Let 
the network decide which streams need replication - all the way to the 
source.

Antonio Querubin
e-mail:  [email-masked]
xmpp:  [email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Mon, 11 Jun 2012 09:30:54 -0400

On 2012-06-09 13:51, Antonio Querubin wrote:
>> membership. For us, that's not a problem. What it means is that the
>> IPv6 and IPv4 versions will go through the network along multicast
>> trees that are optimized for each respective IP version.
>>
>> The alternative approach is to allow sources to transmit either v4 or
>> v6 multicasts, and then to do the translation at the destination edge
> both IPv4 and IPv6 directly, or if the source isn't configurable that
> way, run a local translator directly on the source to do the
> translation. Let the network decide which streams need replication - all
> the way to the source.

Understood, thanks.

Let's call this the "dual-stack approach", whether or not a very simple 
stateless translator, presumably based on RFC 6145, is used at the 
source. You have a dual-stack multicast network, that's what matters.

For a number of operational reasons, several operators are unable to use 
the dual-stack approach. Either they are forced to migrate their 
IPv4-only network directly to IPv6-only, or they cannot afford to have 
multicast streams flowing over both IPv4 and IPv6 simultaneously.

In my understanding, the multicast translation work that is being 
proposed in MBONED is targeted at operators that are unable to use the 
dual-stack approach. I think it could be fine to say, as it has been 
said for unicast, that the dual-stack approach is to be preferred. If 
it's impossible to go dual-stack, then here is a more complex 
translation framework that we can propose.

Makes sense?

Simon

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 11 Jun 2012 12:44:03 -0500

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Monday, June 11, 2012 9:31 AM
> To: Antonio Querubin

> translation framework that we can propose.

Makes sense as one option. However even there, if I'm the operator of a dual stack terrestrial network, with multicasts arriving from single stack networks, no matter IPv4 or IPv6, I might opt to create the "other" multicast version at the ingress gateway regardless. Just for the sake of simplicity.

So it would be good to know how one creates the extra IPv6 bits when receiving IPv4 multicasts, assuming we need one standard way of doing this. Otherwise, if that IPv6 multicast traverses my network on its way to another IPv6 network, it might look different from the original. Whether this matters or not is probably case-specific.

Bert

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 11 Jun 2012 13:00:09 -0700

On Mon, 11 Jun 2012, Simon Perreault wrote:

SNIP
-) 
-) For a number of operational reasons, several operators are unable to use the
-) dual-stack approach. Either they are forced to migrate their IPv4-only
-) network directly to IPv6-only, or they cannot afford to have multicast
-) streams flowing over both IPv4 and IPv6 simultaneously.
-) 
-) In my understanding, the multicast translation work that is being proposed in
-) MBONED is targeted at operators that are unable to use the dual-stack
-) approach. I think it could be fine to say, as it has been said for unicast,
-) that the dual-stack approach is to be preferred. If it's impossible to go
-) dual-stack, then here is a more complex translation framework that we can
-) propose.
-) 

Well, that's the main reason for this poll.  We want to understand what 
operators really are doing so that we are focusing our work on what is 
truly needed and not answering questions that no one is asking.

---

From: Tom Taylor <[email-masked]>
Date: Mon, 11 Jun 2012 16:16:53 -0400

> So it would be good to know how one creates the extra IPv6 bits when receiving IPv4 multicasts, assuming we need one standard way of doing this. Otherwise, if that IPv6 multicast traverses my netwo…
I think the gateway also requires translation within PIM in the 
signalling direction. To move my PIM transition thinking forward, I've 
been look at existing implementations (XORP in particular) to see what 
would have to change.

Tom Taylor

---

From: Simon Perreault <[email-masked]>
Date: Mon, 11 Jun 2012 16:22:38 -0400

> truly needed and not answering questions that no one is asking.

Are you looking for answers from operators other than the ones 
co-authoring the drafts?

I mean, just by looking at the two adopted drafts I'm counting 4 
operators among the authors lists. 3 more in the acknowledgements 
section. Many others have been involved in the mailing list discussions.

Why are we asking this question yet again?

Isn't the problem statement draft supposed to be the definitive answer 
to this question?

Simon

---

From: Qiong <[email-masked]>
Date: Tue, 12 Jun 2012 22:11:16 +0800

Dear all,

1. In our situation, the source may still remian in IPv4, while the
receiver will be IPv6-only since there is no more IPv4 address anymore.
However, the network might be IPv4-only, which can not support IPv6
multicast yet; or the network can support IPv6 multicast. This is the case
of 6-4.
Another situation is: the access network is still IPv4-only, and the core
netowrk (or application platform) is IPv6, then that is the case of 6-4-6-4.

2. Use case: 3.2, 3.4,

Best wishes
Qiong

On Fri, Jun 8, 2012 at 4:34 AM, Leonard Giuliano <[email-masked]> wrote:

> the community and prevent a flood of high volume/low value drafts, we would
> like to revisit the basic questions of multicast transition within MBONED.
>  We would like to hear answers from the WG to the following questions
> before continuing any work on multicast transition in MBONED:
>
> draft-ietf-mboned-v4v6-mcast-**ps so we can limit discussion to solutions
> for those use cases.
>
>
> MBONED Chairs
> ______________________________**_________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mboned<https://www.ietf.org/mailman/listinfo/mboned>
>

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 18 Jun 2012 11:07:30 -0400

Hi Qiong,

If you were to enable IPv6 multicast throughout your network before deploying IPv6 only receivers, would you not fall into use cases 3.4 and 3.5 (the dual stack scenarios). Since you are going to have to enable IPv6 multicast throughout your network anyway, wouldn’t it be a good idea to do so sooner than later?

                                                                      Ron

From: Qiong [mailto:[email-masked]]
Sent: Tuesday, June 12, 2012 10:11 AM
To: Lenny Giuliano
Cc: MBONED WG; Ronald Bonica
Subject: Re: [MBONED] Multicast transition work in MBONED

Dear all,

1. In our situation, the source may still remian in IPv4, while the receiver will be IPv6-only since there is no more IPv4 address anymore. However, the network might be IPv4-only, which can not support IPv6 multicast yet; or the network can support IPv6 multicast. This is the case of 6-4.
Another situation is: the access network is still IPv4-only, and the core netowrk (or application platform) is IPv6, then that is the case of 6-4-6-4.

2. Use case: 3.2, 3.4,

Best wishes
Qiong
On Fri, Jun 8, 2012 at 4:34 AM, Leonard Giuliano <[email-masked]<mailto:[email-masked]>> wrote:

The multicast transition work within MBONED was initially intended to consist of ~ 3 document with limited scope.  In a very short amount of time, we've seen 7 drafts (and counting) with scope widening.

In order to make sure we are focusing on work that is of actual value to the community and prevent a flood of high volume/low value drafts, we would like to revisit the basic questions of multicast transition within MBONED.  We would like to hear answers from the WG to the following questions before continuing any work on multicast transition in MBONED:

1) Which operators intend to source multicast traffic from one IP version and receive it over another IP version?

2) For those who answer 1), please identify the use-cases of interest in draft-ietf-mboned-v4v6-mcast-ps so we can limit discussion to solutions for those use cases.

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

---

From: Qiong <[email-masked]>
Date: Tue, 19 Jun 2012 10:02:39 +0800

Hi Ronald,

I agree we do would like to enable IPv6 multicast in our network. However,
all these things can not be achieved within one night. We still have a lot
of old devices which can not support IPv6 multicast in our network, but we
are running out of IPv4 address right now. So we can not wait until the
whole network is ready for IPv6 multicast.

Hope it clarifies.

Best wishes
Qiong

On Mon, Jun 18, 2012 at 11:07 PM, Ronald Bonica <[email-masked]> wrote:

> Hi Qiong,****
>
> ** **
>
> If you were to enable IPv6 multicast throughout your network before
> deploying IPv6 only receivers, would you not fall into use cases 3.4 and
> 3.5 (the dual stack scenarios). Since you are going to have to enable IPv6
> multicast throughout your network anyway, wouldn’t it be a good idea to do
> so sooner than later? ****
>
> ** **
>
>                                                                       Ron*
> ***
>
> ** **
>
> *From:* Qiong [mailto:[email-masked]]
> *Sent:* Tuesday, June 12, 2012 10:11 AM
> *To:* Lenny Giuliano
> *Cc:* MBONED WG; Ronald Bonica
>
> *Subject:* Re: [MBONED] Multicast transition work in MBONED****
>
> ** **
>
> Dear all,
>
>
> Qiong****
> On Fri, Jun 8, 2012 at 4:34 AM, Leonard Giuliano <[email-masked]>
> wrote:****
>
>
> draft-ietf-mboned-v4v6-mcast-ps so we can limit discussion to solutions for
> those use cases.
>
>
> MBONED Chairs
> https://www.ietf.org/mailman/listinfo/mboned****
>
> ** **
>

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 20 Jun 2012 04:48:36 -0400

Qiong,

Which of the following do you think will require more money/effort:

-          To deploy IPv6 multicast throughout your network

-          To deploy the MLTRANS mechanisms that you will require to compensate for the lack the above mentioned capability

How much more money/effort? Why?

                                                 Ron

From: Qiong [mailto:[email-masked]]
Sent: Monday, June 18, 2012 10:03 PM
To: Ronald Bonica
Cc: Lenny Giuliano; MBONED WG
Subject: Re: [MBONED] Multicast transition work in MBONED

Hi Ronald,

I agree we do would like to enable IPv6 multicast in our network. However, all these things can not be achieved within one night. We still have a lot of old devices which can not support IPv6 multicast in our network, but we are running out of IPv4 address right now. So we can not wait until the whole network is ready for IPv6 multicast.

Hope it clarifies.

Best wishes
Qiong
On Mon, Jun 18, 2012 at 11:07 PM, Ronald Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qiong,

                                                                      Ron

From: Qiong [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, June 12, 2012 10:11 AM
To: Lenny Giuliano
Cc: MBONED WG; Ronald Bonica

Dear all,

2. Use case: 3.2, 3.4,

Best wishes
Qiong

MBONED Chairs

---

From: Qiong <[email-masked]>
Date: Wed, 20 Jun 2012 18:22:41 +0800

Hi Ronald,

For your question, it would be too difficult to give you an acurate number
of money/effort, but I can tell you our situation of network upgradation.

In the transition period, it would be impossible to replace all the legacy
IPv4-only devices, especially a great many access network devices. So
actually, the process would be taken firstly towards our customers and new
region. For example, a new customer might get a new  STB with IPv6
functionality. However, this new customer might access some region only
with old devices, then at that time, it will be of great help to implement
some MLTRANS solutions in the new STB or deploy limited devices in the
network. I believe this will cost less than upgrading the whole network in
the first place.

For old customers, they will still use IPv4 as they already got address,
unless we upgrade their STB to support IPv6 remotely. But it is not the
first priority point.

Best wishes
Qiong

On Wed, Jun 20, 2012 at 4:48 PM, Ronald Bonica <[email-masked]> wrote:

> Qiong,****
>
> ** **
>
> Which of the following do you think will require more money/effort:****
>
> ** **
>
> **-          **To deploy IPv6 multicast throughout your network****
>
> **-          **To deploy the MLTRANS mechanisms that you will require to
> compensate for the lack the above mentioned capability****
>
> ** **
>
> How much more money/effort? Why?****
>
> ** **
>
>                                                  Ron****
>
> ** **
>
> ** **
>
> *Sent:* Monday, June 18, 2012 10:03 PM
> *To:* Ronald Bonica
> *Cc:* Lenny Giuliano; MBONED WG
>
> On Mon, Jun 18, 2012 at 11:07 PM, Ronald Bonica <[email-masked]>
> wrote:****
>
> Hi Qiong,****
>
>  ****
>
>  ****
>  ****
> *Cc:* MBONED WG; Ronald Bonica****
>
>
>  ****
> Dear all,****
>  ****

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 21 Jun 2012 12:14:50 -0400

Folks,

So it looks like use-cases 3.2, 3.4 and 3.5 may see deployment. There were no takers for use-cases 3.1 and 3.3.

In http://www.ietf.org/mail-archive/web/mboned/current/msg01607.html, Simon Perrault suggests two solutions for 3.4 and 3.5. Does the WG agree that those are the solutions that we should run with?

Simon’s solutions can also be applied to use-case 3.2 if we tunnel over non-multicast enabled IPv4 segment. Does everyone agree that that is a good idea?

                                                    Ron

From: Qiong [mailto:[email-masked]]
Sent: Wednesday, June 20, 2012 6:23 AM
To: Ronald Bonica
Cc: Lenny Giuliano; MBONED WG
Subject: Re: [MBONED] Multicast transition work in MBONED

Hi Ronald,

For your question, it would be too difficult to give you an acurate number of money/effort, but I can tell you our situation of network upgradation.

In the transition period, it would be impossible to replace all the legacy IPv4-only devices, especially a great many access network devices. So actually, the process would be taken firstly towards our customers and new region. For example, a new customer might get a new  STB with IPv6 functionality. However, this new customer might access some region only with old devices, then at that time, it will be of great help to implement some MLTRANS solutions in the new STB or deploy limited devices in the network. I believe this will cost less than upgrading the whole network in the first place.

For old customers, they will still use IPv4 as they already got address, unless we upgrade their STB to support IPv6 remotely. But it is not the first priority point.

Best wishes
Qiong
On Wed, Jun 20, 2012 at 4:48 PM, Ronald Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Qiong,

                                                 Ron

Hi Ronald,

Hope it clarifies.

Best wishes
Qiong

                                                                      Ron

Dear all,

2. Use case: 3.2, 3.4,

Best wishes
Qiong

MBONED Chairs

---

From: Tina TSOU <[email-masked]>
Date: Thu, 21 Jun 2012 16:26:06 +0000

The original question Lenny asked did not including 3.1 and 3.3.
Lenny asked
"1) Which operators intend to source multicast traffic from one IP version and receive it over another IP version?"
3.1 is 4-6-4
3.2 is 6-4-6.
So they r not In the scope of Lenny's question.

Tina

On Jun 21, 2012, at 9:16 AM, "Ronald Bonica" <[email-masked]<mailto:[email-masked]>> wrote:

Folks,

                                                    Ron

Hi Ronald,

Best wishes
Qiong

                                                 Ron

Hi Ronald,

Hope it clarifies.

Best wishes
Qiong

                                                                      Ron

Dear all,

2. Use case: 3.2, 3.4,

Best wishes
Qiong

MBONED Chairs

---

From: Simon Perreault <[email-masked]>
Date: Thu, 21 Jun 2012 12:28:02 -0400

On 2012-06-21 12:14, Ronald Bonica wrote:
> In http://www.ietf.org/mail-archive/web/mboned/current/msg01607.html,
> Simon Perrault suggests two solutions for 3.4 and 3.5. Does the WG agree
> that those are the solutions that we should run with?
>
> Simon’s solutions can also be applied to use-case 3.2 if we tunnel over
> non-multicast enabled IPv4 segment. Does everyone agree that that is a
> good idea?

Maybe it is the wrong URL or the wrong person, but I don't know what 
solutions you're talking about, sorry. Could you please summarize them?

Thanks,
Simon

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 21 Jun 2012 12:38:37 -0400

Do we have anybody who is going to deploy 3.1 or 3.3?

                                     Ron

From: Tina TSOU [mailto:[email-masked]]
Sent: Thursday, June 21, 2012 12:26 PM
To: Ronald Bonica
Cc: Qiong; MBONED WG
Subject: Re: [MBONED] Multicast transition work in MBONED

Tina

Simon's solutions can also be applied to use-case 3.2 if we tunnel over non-multicast enabled IPv4 segment. Does everyone agree that that is a good idea?

                                                    Ron

Hi Ronald,

Best wishes
Qiong

                                                 Ron

Hi Ronald,

Hope it clarifies.

Best wishes
Qiong

If you were to enable IPv6 multicast throughout your network before deploying IPv6 only receivers, would you not fall into use cases 3.4 and 3.5 (the dual stack scenarios). Since you are going to have to enable IPv6 multicast throughout your network anyway, wouldn't it be a good idea to do so sooner than later?

                                                                      Ron

Dear all,

2. Use case: 3.2, 3.4,

Best wishes
Qiong

MBONED Chairs

---

From: Tina TSOU <[email-masked]>
Date: Thu, 21 Jun 2012 16:45:44 +0000

I remember Christian, Med and Nic are going to deployed 3.1. Roberta asked about 3.3.
Med is out of office these days. Hope the whole Europe is not all in vacation.

Tina

On Jun 21, 2012, at 9:40 AM, "Ronald Bonica" <[email-masked]<mailto:[email-masked]>> wrote:

                                     Ron

Tina

                                                    Ron

Hi Ronald,

Best wishes
Qiong

                                                 Ron

Hi Ronald,

Hope it clarifies.

Best wishes
Qiong

                                                                      Ron

Dear all,

2. Use case: 3.2, 3.4,

Best wishes
Qiong

MBONED Chairs

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 21 Jun 2012 13:12:20 -0400

Tina,

It seems that the simplest solution in uses case 3.1  would be to deploy dual-stack in the network. Maybe Chris and Med, Nic  could explain why this is not the case?

                                                     Ron

From: Tina TSOU [mailto:[email-masked]]
Sent: Thursday, June 21, 2012 12:46 PM
To: Ronald Bonica
Cc: Qiong; MBONED WG
Subject: Re: [MBONED] Multicast transition work in MBONED

Tina

                                     Ron

Tina

                                                    Ron

Hi Ronald,

Best wishes
Qiong

                                                 Ron

Hi Ronald,

Hope it clarifies.

Best wishes
Qiong

                                                                      Ron

Dear all,

2. Use case: 3.2, 3.4,

Best wishes
Qiong

MBONED Chairs

---

From: <[email-masked]>
Date: Fri, 22 Jun 2012 10:34:15 +0200

Ron, all,

I have to admit I don't understand why this question about use cases is raised again and again, to second one of the comments that were made by Simon some time ago.

This effort initially started with the softwire http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/ draft, according to the section 3 of the softwire WG charter (http://datatracker.ietf.org/wg/softwire/charter/).

As per an initial request from the softwire WG chairs, several operators got together to document the accompanying problem statement draft that has been further elaborated with the integration of use cases in addition to the 4-6-4 use case, and which has now become a mboned WG document, as per the poll results that were confirmed some time ago.

I'm still wondering why the 4-6-4 use case should be ruled out, as it can be seen as a consequence of the enforcement of a global IPv6 strategy that includes (but is not limited to) the deployment of IPv6 multicast-enabled infrastructures combined with the introduction of techniques that are meant to address the need to access IPv4 contents during the transition period where end customers will not be assigned a global IPv4 address anymore.

Such techniques include DS-Lite.

I'm not convinced that deploying DS multicast architectures would be simpler, but I'm sure such design will certainly not optimize bandwidth usage in (at least) the access infrastructures.

As for the use of an IPv6-only, multicast-enabled, access infrastructure, this is something that has been slightly elaborated in the first bullet paragraph of section 1 of http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#page-6, whereas some operators are currently moving from a service-specific, multi-PVC design scheme towards a service-agnostic, single PVC design scheme.

A service-agnostic, single PVC design scheme has the inevitable effect of importing global IPv4 address depletion issues into service environments which used to rely upon a walled garden, RFC1918-based, design.

Combined with the introduction of DS-Lite, this leads to the 4-6-4 use case.

Note that the technical feasibility of what is documented in http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/ has already been demonstrated, thanks to a collaboration with a couple of vendors.

Is this 4-6-4 use case more complicated than a DS multicast design? Yes.

Is this messier? I don't think so, as it primarily depends on service provider-specific operational procedures.

Besides, I'm not convinced that there is room for such hasty qualitative appreciation at this stage of the effort.

I hope this will help closing the debate on the multicast transition use cases and that we will all move on. Finally.

Cheers,

Christian.

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Ronald Bonica
Envoyé : jeudi 21 juin 2012 19:12
À : Tina TSOU
Cc : MBONED WG
Objet : Re: [MBONED] Multicast transition work in MBONED

Tina,

                                                     Ron

Tina

                                     Ron

Tina

                                                    Ron

Hi Ronald,

Best wishes
Qiong

                                                 Ron

Hi Ronald,

Hope it clarifies.

Best wishes
Qiong

                                                                      Ron

Dear all,

2. Use case: 3.2, 3.4,

Best wishes
Qiong

MBONED Chairs

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 22 Jun 2012 21:30:01 -0400

Christian,

In both the 6-4-6 and 4-6-4 cases, it is architecturally cleaner to deploy dual stack in the core than it is to deploy the required adaptation functions. If a few operators step forward to say that they are deploying in the above mentioned scenarios, it might make sense to develop the required adaptation functions. However, lacking those operator statements, it makes little sense for the IETF to specify what may never be deployed.

I am particularly interested in understanding why an operator would chose adaptation over native dual stack. It seems that operational cost and complexity associate with adaptation will be greater than that associated with running dual stack.

                                                                   Ron

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 22, 2012 4:34 AM
To: Ronald Bonica; Tina TSOU
Cc: MBONED WG
Subject: RE: [MBONED] Multicast transition work in MBONED

Ron, all,

Cheers,

Christian.

________________________________
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Ronald Bonica
Envoyé : jeudi 21 juin 2012 19:12
À : Tina TSOU
Cc : MBONED WG
Objet : Re: [MBONED] Multicast transition work in MBONED
Tina,

                                                     Ron

Tina

                                     Ron

Tina

                                                    Ron

Hi Ronald,

Best wishes
Qiong

                                                 Ron

Hi Ronald,

Hope it clarifies.

Best wishes
Qiong

                                                                      Ron

Dear all,

2. Use case: 3.2, 3.4,

Best wishes
Qiong

MBONED Chairs

Thank you.

---

From: Mike McBride <[email-masked]>
Date: Tue, 26 Jun 2012 17:34:35 -0700

Ron,

I'd suggest having your "architecturally cleaner" comment added to the
framework draft. And perhaps state that it is the recommendation of
mboned to deploy dual stack in the core whenever possible.

And then further explain the need, of some like Christian, to provide
the adaptation functions. The adaptation work can then proceed even if
its not the mboned preference. The good position we are in is that
there are people/drafts and a wg queued up and ready to go. Its not
like there is no interest in working on the adaptation solutions.

mike

On Fri, Jun 22, 2012 at 6:30 PM, Ronald Bonica <[email-masked]> wrote:
> Christian,
>
>
>
> In both the 6-4-6 and 4-6-4 cases, it is architecturally cleaner to deploy
> dual stack in the core than it is to deploy the required adaptation
> functions. If a few operators step forward to say that they are deploying in
> the above mentioned scenarios, it might make sense to develop the required
> adaptation functions. However, lacking those operator statements, it makes
> little sense for the IETF to specify what may never be deployed.
>
>
>
> I am particularly interested in understanding why an operator would chose
> adaptation over native dual stack. It seems that operational cost and
> complexity associate with adaptation will be greater than that associated
> with running dual stack.
>
>
>
>                                                                    Ron
>
>
>
>
>
> I have to admit I don't understand why this question about use cases is
> raised again and again, to second one of the comments that were made by
> Simon some time ago.
>
>
>
> This effort initially started with the softwire
> http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/ draft,
> according to the section 3 of the softwire WG charter
> (http://datatracker.ietf.org/wg/softwire/charter/).
>
>
>
> As per an initial request from the softwire WG chairs, several operators got
> together to document the accompanying problem statement draft that has been
> further elaborated with the integration of use cases in addition to the
> 4-6-4 use case, and which has now become a mboned WG document, as per the
> poll results that were confirmed some time ago.
>
>
>
> I'm still wondering why the 4-6-4 use case should be ruled out, as it can be
> seen as a consequence of the enforcement of a global IPv6 strategy that
> includes (but is not limited to) the deployment of IPv6 multicast-enabled
> infrastructures combined with the introduction of techniques that are meant
> to address the need to access IPv4 contents during the transition period
> where end customers will not be assigned a global IPv4 address anymore.
>
>
>
> I'm not convinced that deploying DS multicast architectures would be
> simpler, but I'm sure such design will certainly not optimize bandwidth
> usage in (at least) the access infrastructures.
>
>
>
> As for the use of an IPv6-only, multicast-enabled, access infrastructure,
> this is something that has been slightly elaborated in the first bullet
> paragraph of section 1 of
> http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#page-6,
> whereas some operators are currently moving from a service-specific,
> multi-PVC design scheme towards a service-agnostic, single PVC design
> scheme.
>
>
>
> A service-agnostic, single PVC design scheme has the inevitable effect of
> importing global IPv4 address depletion issues into service environments
> which used to rely upon a walled garden, RFC1918-based, design.
>
>
>
> Note that the technical feasibility of what is documented in
> http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/ has
> already been demonstrated, thanks to a collaboration with a couple of
> vendors.
>
>
>
> Is this messier? I don't think so, as it primarily depends on service
> provider-specific operational procedures.
>
>
>
> Besides, I'm not convinced that there is room for such hasty qualitative
> appreciation at this stage of the effort.
>
>
>
> I hope this will help closing the debate on the multicast transition use
> cases and that we will all move on. Finally.
>
>
>
> Cheers,
>
>
>
> Christian.
>
>
>
>
>
>
>
>
>
> It seems that the simplest solution in uses case 3.1  would be to deploy
> dual-stack in the network. Maybe Chris and Med, Nic  could explain why this
> is not the case?
>
>
>
>                                                      Ron
>
>
>
> On Jun 21, 2012, at 9:40 AM, "Ronald Bonica" <[email-masked]> wrote:
>
> "1) Which operators intend to source multicast traffic from one IP
> version and receive it over another IP version?"
>
> 3.1 is 4-6-4
>
> 3.2 is 6-4-6.
>
> On Jun 21, 2012, at 9:16 AM, "Ronald Bonica" <[email-masked]> wrote:
>
> Folks,
>
>
>
> In http://www.ietf.org/mail-archive/web/mboned/current/msg01607.html, Simon
> Perrault suggests two solutions for 3.4 and 3.5. Does the WG agree that
> those are the solutions that we should run with?
>
>
>
> non-multicast enabled IPv4 segment. Does everyone agree that that is a good
> idea?
>
>
>
>                                                     Ron
>
>
>
> functionality. However, this new customer might access some region only with
> old devices, then at that time, it will be of great help to implement some
> MLTRANS solutions in the new STB or deploy limited devices in the network. I
> believe this will cost less than upgrading the whole network in the first
> place.
>
> -          To deploy the MLTRANS mechanisms that you will require to
> compensate for the lack the above mentioned capability
>
>
>
> deploying IPv6 only receivers, would you not fall into use cases 3.4 and 3.5
> (the dual stack scenarios). Since you are going to have to enable IPv6
> so sooner than later?
> 1. In our situation, the source may still remian in IPv4, while the receiver
> will be IPv6-only since there is no more IPv4 address anymore. However, the
> network might be IPv4-only, which can not support IPv6 multicast yet; or the
> network can support IPv6 multicast. This is the case of 6-4.
> consist of ~ 3 document with limited scope.  In a very short amount of time,
> we've seen 7 drafts (and counting) with scope widening.
>
> In order to make sure we are focusing on work that is of actual value to the
> community and prevent a flood of high volume/low value drafts, we would like
> to revisit the basic questions of multicast transition within MBONED.  We
> would like to hear answers from the WG to the following questions before
> continuing any work on multicast transition in MBONED:
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
>
> As emails may be altered, France Telecom - Orange is not liable for messages
> that have been modified, changed or falsified.
>
> Thank you.
>
>