Subject: [multrans] Draft Multrans BoF request

From: Tina Tsou <[email-masked]>
Date: Mon, 06 Jun 2011 15:03:05 -0700

Hi all,
This is the draft Multrans BoF request, written by Christian and the authors
of problem statement I-D. Your comments are welcome. We plan to send the
final version to the AD Jari by this Friday.

In current deployments, the IP multicast forwarding scheme is used by many
providers to deliver some services, such as live TV broadcasting.
Transition to IPv6 raises issues and corresponding requirements. In
particular, IPv4 service continuity is an essential requirement from a
business perspective. 
This specifically includes continued receiver access to IPv4-formatted
contents even when the assignment of a dedicated global IPv4 address to the
receiver is no longer possible and even after the receivers have migrated to
IPv6. 
Likewise, the delivery of IPv6-formatted contents to IPv4 receivers must
also be possible.
Multicast transition scenarios include the ability to access IPv4-formatted
multicast contents from an IPv4 receiver over an IPv6-only network and the
ability to access IPv4-formatted multicast contents from an IPv6-only
receiver.
The aforementioned issues can be classified into:
.	Multicast group and source discovery procedures
.	Multicast group subscription procedures
.	Multicast tree computation
.	Required IPv4-IPv6 multicast inter-working functions
The proposed BoF session aims at discussing and hopefully validating the
need for the IETF to work on these issues.
The proposed agenda for the BoF session goes like this:
.	Welcome introduction and agenda bashing (chairs, 10 min)
.	Multicast transition scenarios (TBD, 20 min)
.	Requirements issues (TBD, 15 min)
.	Issues (TBD, 15 min)
.	Discussion (all, 20 min)
.	Conclusion and next steps (chairs, ADs, 10 min)
Reading material:
http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02"
 
BoF chairs should include one rep from the service provider's community.

We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

---

From: Tina Tsou <[email-masked]>
Date: Mon, 06 Jun 2011 15:06:09 -0700

Hi all,
A small nit, 
.	Requirements and issues (TBD, 15 min)
should be
.	Requirements (TBD, 15 min)

It is updated below.

.	Requirements (TBD, 15 min)

Best Regards,
Tina TSOU

---

From: <[email-masked]>
Date: Tue, 7 Jun 2011 08:17:03 +0200

Hmmm, I'm struggling a bit with the term "IPvX-formatted content". Since it is clear to me how I should interprte this term I'm not sure if it is really correct.
Perhaps "IPvX-transported content" could do a better job, but I'm unfortunately not a native speaker and may fail as well.

Olaf

> -----Ursprüngliche Nachricht-----
> Von: [email-masked]
> [mailto:[email-masked]] Im Auftrag von Tina Tsou
> Gesendet: Dienstag, 7. Juni 2011 00:03
> An: [email-masked]
> Cc: 'Jari Arkko'
> Betreff: [multrans] Draft Multrans BoF request
>
> Hi all,
> _______________________________________________
> multrans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multrans
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 7 Jun 2011 12:33:51 +0000

Hi Olaf,

I understand where the confusion comes from. Content supposes to be IP
version agnostic. I think IPvX-transported content may be a better word.

Yiu

On 6/7/11 2:17 AM, "[email-masked]" <[email-masked]>
wrote:

>Hmmm, I'm struggling a bit with the term "IPvX-formatted content". Since
>it is clear to me how I should interprte this term I'm not sure if it is
>really correct.
>Perhaps "IPvX-transported content" could do a better job, but I'm
>unfortunately not a native speaker and may fail as well.
>
>Olaf
>
>

---

From: Jacni Qin <[email-masked]>
Date: Wed, 8 Jun 2011 08:42:19 +0800

hi Olaf,

Or "IPvX-Framed" ? :-)

Cheers,
Jacni

---

From: <[email-masked]>
Date: Thu, 9 Jun 2011 14:34:50 +0800

Nice point! Non-native speaker too, but when consider transporting "IPv4-transported content" over IPv6-only network, is it also a little bit confusing? :-)  

Then, I guess "IPvX-Framed" sounds better.

Cheers,

Xiaohong

opensource A+P: http://opensourceaplusp.weebly.com/

________________________________

	发件人: Jacni Qin [mailto:[email-masked]] 
	发送时间: 2011年6月8日 8:42
	收件人: Lee, Yiu
	抄送: [email-masked]; [email-masked]
	主题: Re: [multrans] Draft Multrans BoF request

	hi Olaf,
	
	Or "IPvX-Framed" ? :-)
	
	Cheers,
	Jacni

		Hi Olaf,

		Yiu

---

From: <[email-masked]>
Date: Fri, 10 Jun 2011 08:53:55 +0200

Hi Tina, all,

I would propose to keep one single slot to discuss the issues and requirements.

Furthermore, a slot to present the scope (http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02#section-2.1) and the list of work items should be added (see http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02#section-5)

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Tina Tsou
Envoyé : mardi 7 juin 2011 00:06
À : [email-masked]
Cc : 'Jari Arkko'
Objet : Re: [multrans] Draft Multrans BoF request

Hi all,
A small nit, 

It is updated below.

Best Regards,
Tina TSOU

---

From: Tom Taylor <[email-masked]>
Date: Fri, 10 Jun 2011 23:10:17 -0400

Please explain why you want to keep requirements and issues together. 
They are two separate topics. The requirements flow from the users' and 
service providers' needs. The issues flow from a technical analysis of 
the operation of the available protocols.

As to time allocation, I'd suggest that the scenarios should have 
somewhat less time, 15 minutes at most, unless we are going to present 
lower-priority scenarios at a detailed level. The extra time should be 
shifted to the discussion slot.

---

From: "Lee, Yiu" <[email-masked]>
Date: Sun, 12 Jun 2011 22:36:24 +0000

Hi Tom,

I guess we can remove "issues" from the topic just like what you
suggested. For the time allocated to scenarios, I think we will list all
but only focus on 4-6-4 and 6r-4s.

Regards,
Yiu

On 6/10/11 11:10 PM, "Tom Taylor" <[email-masked]> wrote:

>> Furthermore, a slot to present the scope
>>(http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02#section-
>>2.1) and the list of work items should be added (see
>>http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02#section-5
>>)
>>
>> Cheers,
>> Med
>>
>>

---

From: Tina Tsou <[email-masked]>
Date: Sun, 12 Jun 2011 23:02:03 -0600

Hi all,
Here is the update based on the multrans list discussion.

I volunteer to present the list of work items. I put some presenters' name
with question mark for the time being; need to be confirmed by that time.
----------------------
In current deployments, the IP multicast forwarding scheme is used by many
providers to deliver some services, such as live TV broadcasting.
Transition to IPv6 raises issues and corresponding requirements. In
particular, IPv4 service continuity is an essential requirement from a
business perspective.
This specifically includes continued receiver access to IPv4-framed contents
even when the assignment of a dedicated global IPv4 address to the receiver
is no longer possible and even after the receivers have migrated to IPv6.
Likewise, the delivery of IPv6-framed contents to IPv4 receivers must also
be possible.
Multicast transition scenarios include the ability to access IPv4-framed
multicast contents from an IPv4 receiver over an IPv6-only network and the
ability to access IPv4-framed multicast contents from an IPv6-only receiver.
The aforementioned issues can be classified into:
.    Multicast group and source discovery procedures
.    Multicast group subscription procedures
.    Multicast tree computation
.    Required IPv4-IPv6 multicast inter-working functions
The proposed BoF session aims at discussing and hopefully validating the
need for the IETF to work on these issues.
The proposed agenda for the BoF session goes like this:
.    Welcome introduction and agenda bashing (chairs, 10 min)
.    Multicast transition scenarios (XiaoHong?, 20 min)
.    Requirements (Yiu Lee?, 15 min)
.    Issues (Tom Taylor?, 15 min)
.    Scope (TBD, 15 min)
.    List of work items (Tina TSOU, 15 min)
.    Discussion (all, 20 min)
.    Conclusion and next steps (chairs, ADs, 10 min)
Reading material:
http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02"

----------------------

We keep our promises with one another – no matter what!

Best Regards,
Tina TSOU

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lee, Yiu
Sent: Sunday, June 12, 2011 4:36 PM
To: Tom Taylor; [email-masked]
Cc: 'Jari Arkko'; [email-masked]
Subject: Re: [multrans] Draft Multrans BoF request

Hi Tom,

Regards,
Yiu

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 13 Jun 2011 10:52:46 +0000

Thanks Tina!

---

From: Tina Tsou <[email-masked]>
Date: Mon, 13 Jun 2011 11:52:29 -0600

Best regards,
Tina TSOU
http://tinatsou.weebly.com/

Begin forwarded message:

> From: Jari Arkko <[email-masked]>
> Date: June 13, 2011 11:08:44 AM MDT
> To: Tina Tsou <[email-masked]>
> Cc: "Lee, Yiu" <[email-masked]>, 'Tom Taylor' <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

> Tina, others,
> 
> I'm trying to construct a wiki entry for this BOF so that the IESG and IAB have all the information available to them to make decisions on what BOFs to approve on Thursday. What other drafts than the ps I should list? Is there a pointer to a mailing list post or some web site for the proposed charter? Also, for my background: are there providers who are asking for multicast transition solutions? I.e., not just deploying multicast separately for the two IP versions?
> 
> Here's what we have so far:
> 
>> MULTRANS - Multicast Transition 
>> Description: Proposed BOF to gather efforts around enabling IPv4-IPv6 coexistence and transition with multicast traffic. This proposal has relationships to existing chartered work in SOFTWIRE and BEHAVE working groups.
>> Length of session: 120 minutes 
>> Responsible AD: Jari Arkko, Ralph Droms, and David Harrington 
>> Mailing list:  https://www.ietf.org/mailman/listinfo/multrans 
>> Drafts: [ jaclee-behave-v4v6-mcast-ps] 
>> Agenda: [ agenda] 
>> Charter: TBD 
>> Status: Under consideration
> 
> Jari
>

---

From: Tina Tsou <[email-masked]>
Date: Mon, 13 Jun 2011 12:02:18 -0600

Tom Taylor,
Would u send out the list of drafts, and the draft charter, which has been presented and discussed in IPv4-IPV6 multicast ad-hoc meetings in Prague in March.

My Splashtop application in iPAD doesn't work today to connect to my laptop, where I saved these files from Prague meeting. So I'm not able to send it until I go back to hotel room tonight.

I'm in NANOG 52 meeting.

Best regards,
Tina TSOU

---

From: Tina Tsou <[email-masked]>
Date: Mon, 13 Jun 2011 15:42:02 -0600

> Also, for my background: are there providers who are asking for multicast transition solutions? I.e., not just deploying multicast separately for the two IP versions?
Jari, 
There are people from FT and Comcast as the author of the problem statements, indicating they are asking not just deploying multicast separately for the two IP versions. It does not have to mean their deployments are exactly the same as the document.
In addition, in my mind, the deployment of SSM and ASM on the dual stack network is also part of multicast transition. Some operators are asking it. Though the priority could be discussed, the scope could be discussed.

Best regards,
Tina TSOU

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 13 Jun 2011 21:46:11 +0000

Jari mentioned that some Chinese operators have started investigating multicast for their IP-TV delivery. I think ZTC and Huawei may have more insights.

From: Tina Tsou <[email-masked]<mailto:[email-masked]>>
Date: Mon, 13 Jun 2011 15:42:02 -0600
To: Jari Arkko <[email-masked]<mailto:[email-masked]>>
Cc: "Yiu L. LEE" <[email-masked]<mailto:[email-masked]>>, Tom Taylor <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [multrans] Draft Multrans BoF request

Best regards,
Tina TSOU

On Jun 13, 2011, at 11:08 AM, Jari Arkko <[email-masked]<mailto:[email-masked]>> wrote:

Tina, others,

Description: Proposed BOF to gather efforts around enabling IPv4-IPv6 coexistence and transition with multicast traffic. This proposal has relationships to existing chartered work in SOFTWIRE and BEHAVE working groups.
Length of session: 120 minutes
Responsible AD: Jari Arkko, Ralph Droms, and David Harrington
Mailing list:  <https://www.ietf.org/mailman/listinfo/multrans> https://www.ietf.org/mailman/listinfo/multrans
Drafts: [ jaclee-behave-v4v6-mcast-ps<http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02>]
Agenda: [ agenda<http://www.arkko.com/ietf/ietf-81/multrans/agenda.txt>]
Charter: TBD
Status: Under consideration

Jari

---

From: Tina Tsou <[email-masked]>
Date: Mon, 13 Jun 2011 16:07:20 -0600

Jari,
I gave u a quick response thinking the discussion was Tuesday.
We will wait and see if they reply with more details.

Best regards,
Tina TSOU

---

From: Jari Arkko <[email-masked]>
Date: Mon, 13 Jun 2011 20:08:44 +0300

Tina, others,

I'm trying to construct a wiki entry for this BOF so that the IESG and
IAB have all the information available to them to make decisions on
what BOFs to approve on Thursday. What other drafts than the ps I
should list? Is there a pointer to a mailing list post or some web site
for the proposed charter? Also, for my background: are there providers
who are asking for multicast transition solutions? I.e., not just
deploying multicast separately for the two IP versions?

Description: Proposed BOF to gather
efforts around enabling IPv4-IPv6 coexistence and transition with
multicast traffic. This proposal has relationships to existing
chartered work in SOFTWIRE and BEHAVE working groups.

Responsible AD: Jari Arkko, Ralph
Droms, and David Harrington

Agenda: [ agenda]

Charter: TBD

Jari

---

From: Tina Tsou <[email-masked]>
Date: Tue, 14 Jun 2011 00:57:25 -0600

Jari,
About other drafts than the list, do you mean the 16 drafts we discussed in
Prague IPv4-IPv6 multicast meetings, or the new draft or updated draft
specifically for this BoF?

Best Regards,
Tina TSOU
 
From: Jari Arkko [mailto:[email-masked]] 
Sent: Monday, June 13, 2011 11:09 AM
To: Tina Tsou
Cc: Lee, Yiu; 'Tom Taylor'; [email-masked];
[email-masked]
Subject: Re: [multrans] Draft Multrans BoF request
 
Tina, others,

I'm trying to construct a wiki entry for this BOF so that the IESG and IAB
have all the information available to them to make decisions on what BOFs to
approve on Thursday. What other drafts than the ps I should list? Is there a
pointer to a mailing list post or some web site for the proposed charter?
Also, for my background: are there providers who are asking for multicast
transition solutions? I.e., not just deploying multicast separately for the
two IP versions?

MULTRANS - Multicast Transition 
Description: Proposed BOF to gather efforts around enabling IPv4-IPv6
coexistence and transition with multicast traffic. This proposal has
relationships to existing chartered work in SOFTWIRE and BEHAVE working
groups.
Length of session: 120 minutes 
Responsible AD: Jari Arkko, Ralph Droms, and David Harrington 
Mailing list:  <https://www.ietf.org/mailman/listinfo/multrans>
https://www.ietf.org/mailman/listinfo/multrans 
Drafts: [ <http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02>
jaclee-behave-v4v6-mcast-ps] 
Agenda: [ <http://www.arkko.com/ietf/ietf-81/multrans/agenda.txt>  agenda] 
Charter: TBD 
Status: Under consideration 

Jari

---

From: Tina Tsou <[email-masked]>
Date: Tue, 14 Jun 2011 01:03:41 -0600

Jari,
About the proposed charter, here is a copy from the presentation in
IPv4-IPv6 multicast meetings in Prague in March.
 
The task of this Working Group is to devise the means whereby existing
multicast distribution mechanisms can work when signalling and content have
to traverse one or more boundaries where IP version changes.
 
The Working Group will consider three cases:
-- provider distributed multicast (including IPTV);
-- multicast networks connected directly to a multicast backbone network;
-- multicast networks separated from the backbone network by unicast
networks.
 
The Working Group's first task is to create a Problem Statement. This
documents will specify the requirements that must be satisfied by multicast
transition solutions for the three cases listed above. It will describe the
scenarios that need to be considered and the challenges posed by those
scenarios in those three cases. Finally, the Problem Statement will specify
the new functional capabilities required to enable the solution of the
multicast transition problem in the different scenarios.
 
The Working Group will follow up with one or more framework documents
analyzing the potential multicast transition solutions for specific
scenarios or groups of scenarios. The circumstances under which the
different solution approaches are applicable will be described, taking
account of the unicast transition mechanisms that may be deployed in a
given network. The framework drafts should include a view of the evolution
path for multicast transition over time, possibly though not necessarily as
a function of the associated unicast transition path. The final outcome of
the framework drafts should be recommendations for preferred solution
approaches.
 
Finally, the Working Group will produce a small set of solution drafts for
the cases considered to be of the highest priority before re-chartering or
disbandment. Specifically, the Working Group will provide one or two
solutions for the provider distributed multicast case when the multicast
source and receiver are IPv4 and there is an intervening IPv6 network. The
solution(s) must be compatible with the unicast translation (NAT64) and
tunneling (DS Lite, Gateway-Initiated DS lite) transition mechanisms. The
solution(s) must discuss the considerations specifically relevant to these
three unicast transition mechanisms to the extent this discussion is not
covered by the framework document. The Working Group will also provide a
solution for the case of multicast networks connected directly to a
multicast backbone network.
 
Relations: Behave, Softwires, PIM, Mboned, V6ops
 
Deliverables:
Problem Statement (Informational)
Framework for the provider distributed multicast case (Informational)
Framework for the case of multicast networks connected directly to a
multicast backbone network (Informational)
Solutions (2-3) (Proposed Standard)

Best Regards,
Tina TSOU

Tina, others,

Jari

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 14 Jun 2011 21:29:30 +0000

Sorry, I meant Jacni from ZTC, not Jari ;-)

From: "Yiu L. LEE" <[email-masked]<mailto:[email-masked]>>
Date: Mon, 13 Jun 2011 21:46:11 +0000
To: Tina Tsou <[email-masked]<mailto:[email-masked]>>, Jari Arkko <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [multrans] Draft Multrans BoF request

Best regards,
Tina TSOU

Tina, others,

Jari

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

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 14 Jun 2011 21:41:37 +0000

Hi Jari,

Yes, dual-stack multicast seems natural and easy for transitioning. Since there is no IPv4 address depletion for IPv6 multicast addresses and most multicast deployments are private, why not multicast content in both IPv4 and IPv6? I see at least two drawbacks:

(1) Bandwidth utilization. Content is agnostic, it doesn't care it was delivered over IPv4 or IPv6. However, when we multicast content in both IP versions, it would double the multicast traffic for nothing. Consider more and more TV channels moving to HD, the bandwidth consumption could be substantial. This problem is particularly problematic when comes to the access network. Cable is a shared media, as long as one receiver subscribes a channel, the media would flow through in the access network.

(2) Managing both IPv4 and IPv6 multicast distribution trees would increase opex. This may not sound big but troubling multicast is cosidered harder than unicast, so this could be some saving.

B.R.,
Yiu

From: Jari Arkko <[email-masked]<mailto:[email-masked]>>
Date: Mon, 13 Jun 2011 20:08:44 +0300
To: Tina Tsou <[email-masked]<mailto:[email-masked]>>
Cc: "Yiu L. LEE" <[email-masked]<mailto:[email-masked]>>, 'Tom Taylor' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [multrans] Draft Multrans BoF request

---

From: <[email-masked]>
Date: Wed, 15 Jun 2011 08:16:33 +0200

Hi Jari, all,

We have the same analysis in our side.

Cheers,
Med

________________________________
De : Lee, Yiu [mailto:[email-masked]]
Envoyé : mardi 14 juin 2011 23:42
À : Jari Arkko; Tina Tsou
Cc : 'Tom Taylor'; BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Objet : Re: [multrans] Draft Multrans BoF request

Hi Jari,

B.R.,
Yiu

---

From: <[email-masked]>
Date: Wed, 15 Jun 2011 08:27:03 +0200

Hi Tom,

The rationale behind grouping the requirements and technical issues is to make it easy to understand why a given point is considered as an issue and also for the time distribution efficiency. 

In my mind the requirements would discuss what is documented in http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02#section-2.3 and technical issues point to http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02#section-4. 

Cheers,
Med

---

From: <[email-masked]>
Date: Wed, 15 Jun 2011 18:23:42 +0800

Thanks Tina!

Cheers,
Xiaohong

|-----邮件原件-----
|发件人: Tina Tsou [mailto:[email-masked]] 
|发送时间: 2011年6月13日 13:02
|收件人: 'Lee, Yiu'; 'Tom Taylor'; BOUCADAIR Mohamed OLNC-NAD-TIP
|抄送: 'Jari Arkko'; [email-masked]
|主题: Re: [multrans] Draft Multrans BoF request
|
|Hi all,
|Here is the update based on the multrans list discussion.
|
|I volunteer to present the list of work items. I put some 
|presenters' name with question mark for the time being; need 
|to be confirmed by that time.
|----------------------
|In current deployments, the IP multicast forwarding scheme is 
|used by many providers to deliver some services, such as live 
|TV broadcasting.
|Transition to IPv6 raises issues and corresponding 
|requirements. In particular, IPv4 service continuity is an 
|essential requirement from a business perspective.
|This specifically includes continued receiver access to 
|IPv4-framed contents even when the assignment of a dedicated 
|global IPv4 address to the receiver is no longer possible and 
|even after the receivers have migrated to IPv6.
|Likewise, the delivery of IPv6-framed contents to IPv4 
|receivers must also be possible.
|Multicast transition scenarios include the ability to access 
|IPv4-framed multicast contents from an IPv4 receiver over an 
|IPv6-only network and the ability to access IPv4-framed 
|multicast contents from an IPv6-only receiver.
|The aforementioned issues can be classified into:
|.    Multicast group and source discovery procedures
|.    Multicast group subscription procedures
|.    Multicast tree computation
|.    Required IPv4-IPv6 multicast inter-working functions
|The proposed BoF session aims at discussing and hopefully 
|validating the need for the IETF to work on these issues.
|The proposed agenda for the BoF session goes like this:
|.    Welcome introduction and agenda bashing (chairs, 10 min)
|.    Multicast transition scenarios (XiaoHong?, 20 min)
|.    Requirements (Yiu Lee?, 15 min)
|.    Issues (Tom Taylor?, 15 min)
|.    Scope (TBD, 15 min)
|.    List of work items (Tina TSOU, 15 min)
|.    Discussion (all, 20 min)
|.    Conclusion and next steps (chairs, ADs, 10 min)
|Reading material:
|http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02"
|
|BoF chairs should include one rep from the service provider's 
|community.
|----------------------
|
|
|We keep our promises with one another – no matter what!
|
|Best Regards,
|Tina TSOU
|http://tinatsou.weebly.com/contact.html
|
|
|-----Original Message-----
|From: [email-masked] 
|[mailto:[email-masked]] On Behalf Of Lee, Yiu
|Sent: Sunday, June 12, 2011 4:36 PM
|To: Tom Taylor; [email-masked]
|Cc: 'Jari Arkko'; [email-masked]
|Subject: Re: [multrans] Draft Multrans BoF request
|
|Hi Tom,
|
|I guess we can remove "issues" from the topic just like what 
|you suggested. For the time allocated to scenarios, I think we 
|will list all but only focus on 4-6-4 and 6r-4s.
|
|Regards,
|Yiu
|
|
|On 6/10/11 11:10 PM, "Tom Taylor" <[email-masked]> wrote:
|
|>Please explain why you want to keep requirements and issues together.
|>They are two separate topics. The requirements flow from the 
|users' and 
|>service providers' needs. The issues flow from a technical 
|analysis of 
|>the operation of the available protocols.
|>
|>As to time allocation, I'd suggest that the scenarios should have 
|>somewhat less time, 15 minutes at most, unless we are going 
|to present 
|>lower-priority scenarios at a detailed level. The extra time 
|should be 
|>shifted to the discussion slot.
|>
|>On 10/06/2011 2:53 AM, [email-masked] wrote:
|>> Hi Tina, all,
|>>
|>> I would propose to keep one single slot to discuss the issues and 
|>>requirements.
|>>
|>> Furthermore, a slot to present the scope
|>>(http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps
|-02#secti
|>>on-
|>>2.1) and the list of work items should be added (see
|>>http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-
|02#sectio
|>>n-5
|>>)
|>>
|>> Cheers,
|>> Med
|>>
|>>
|>> -----Message d'origine-----
|>> De : [email-masked] 
|[mailto:[email-masked]] De 
|>>la part de Tina Tsou  Envoyé : mardi 7 juin 2011 00:06  À : 
|>>[email-masked]  Cc : 'Jari Arkko'
|>> Objet : Re: [multrans] Draft Multrans BoF request
|>>
|>> Hi all,
|>> A small nit,
|>> .    Requirements and issues (TBD, 15 min)
|>> should be
|>> .    Requirements (TBD, 15 min)
|>>
|>> It is updated below.
|>>
|>> In current deployments, the IP multicast forwarding scheme 
|is used by 
|>>many  providers to deliver some services, such as live TV 
|>>broadcasting.
|>> Transition to IPv6 raises issues and corresponding 
|requirements. In  
|>>particular, IPv4 service continuity is an essential 
|requirement from a  
|>>business perspective.
|>> This specifically includes continued receiver access to 
|>>IPv4-formatted  contents even when the assignment of a dedicated 
|>>global IPv4 address to the  receiver is no longer possible and even 
|>>after the receivers have migrated to  IPv6.
|>> Likewise, the delivery of IPv6-formatted contents to IPv4 receivers 
|>>must  also be possible.
|>> Multicast transition scenarios include the ability to access 
|>>IPv4-formatted  multicast contents from an IPv4 receiver over an 
|>>IPv6-only network and the  ability to access IPv4-formatted 
|multicast 
|>>contents from an IPv6-only  receiver.
|>> The aforementioned issues can be classified into:
|>> .    Multicast group and source discovery procedures
|>> .    Multicast group subscription procedures
|>> .    Multicast tree computation
|>> .    Required IPv4-IPv6 multicast inter-working functions
|>> The proposed BoF session aims at discussing and hopefully 
|validating 
|>>the  need for the IETF to work on these issues.
|>> The proposed agenda for the BoF session goes like this:
|>> .    Welcome introduction and agenda bashing (chairs, 10 min)
|>> .    Multicast transition scenarios (TBD, 20 min)
|>> .    Requirements (TBD, 15 min)
|>> .    Issues (TBD, 15 min)
|>> .    Discussion (all, 20 min)
|>> .    Conclusion and next steps (chairs, ADs, 10 min)
|>> Reading material:
|>> http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02"
|>>
|>> BoF chairs should include one rep from the service 
|provider's community.
|>>
|>>
|>> We keep our promises with one another - no matter what!
|>>
|>> Best Regards,
|>> Tina TSOU
|>> http://tinatsou.weebly.com/contact.html
|>>
|>>
|>>
|>>
|>> _______________________________________________
|>> multrans mailing list
|>> [email-masked]
|>> https://www.ietf.org/mailman/listinfo/multrans
|>> _______________________________________________
|>> multrans mailing list
|>> [email-masked]
|>> https://www.ietf.org/mailman/listinfo/multrans
|>>
|>>
|>_______________________________________________
|>multrans mailing list
|>[email-masked]
|>https://www.ietf.org/mailman/listinfo/multrans
|
|_______________________________________________
|multrans mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/multrans
|
|
|

---

From: Jacni Qin <[email-masked]>
Date: Wed, 15 Jun 2011 23:24:41 +0800

Dear Jari, all,

Sorry for my late reply.

Yes, as Yiu said, we're working with operators on the transition of services
to IPv6, IPTV is an important one including mulicast based Broadcasting
delivery. while we found there are some problems different from those of the
unicast cases, which have been brought up in the Problem Statment document.
Thanks!

Cheers,
Jacni

On Wed, Jun 15, 2011 at 5:29 AM, Lee, Yiu <[email-masked]> wrote:

>   From: "Yiu L. LEE" <[email-masked]>
> To: Tina Tsou <[email-masked]>, Jari Arkko <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>
>   Jari mentioned that some Chinese operators have started investigating
> multicast for their IP-TV delivery. I think ZTC and Huawei may have more
> insights.
>
>
>   From: Tina Tsou <[email-masked]>
> To: Jari Arkko <[email-masked]>
> Cc: "Yiu L. LEE" <[email-masked]>, Tom Taylor <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
>    Also, for my background: are there providers who are asking for
> multicast transition solutions? I.e., not just deploying multicast
> separately for the two IP versions?
>
> Jari,
> There are people from FT and Comcast as the author of the problem
> statements, indicating they are asking not just deploying multicast
> separately for the two IP versions. It does not have to mean their
> deployments are exactly the same as the document.
> In addition, in my mind, the deployment of SSM and ASM on the dual stack
> network is also part of multicast transition. Some operators are asking it.
> Though the priority could be discussed, the scope could be discussed.
>
> Best regards,
> Tina TSOU
>  *MULTRANS* - Multicast Transition
> Agenda: [ agenda <http://www.arkko.com/ietf/ietf-81/multrans/agenda.txt>]
> Charter: TBD
>    _______________________________________________ multrans mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/multrans
>