Re: [multrans] Draft Multrans BoF request

"Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> Mon, 13 June 2011 10:52 UTC

Return-Path: <yiu_lee@cable.comcast.com>
X-Original-To: multrans@ietfa.amsl.com
Delivered-To: multrans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E8511E80B2 for <multrans@ietfa.amsl.com>; Mon, 13 Jun 2011 03:52:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.735
X-Spam-Level:
X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pgz0r6ORm2y for <multrans@ietfa.amsl.com>; Mon, 13 Jun 2011 03:52:56 -0700 (PDT)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3B75D11E80B0 for <multrans@ietf.org>; Mon, 13 Jun 2011 03:52:56 -0700 (PDT)
Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.40300885; Mon, 13 Jun 2011 04:56:10 -0600
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Mon, 13 Jun 2011 06:52:47 -0400
From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
To: Tina Tsou <tena@huawei.com>, 'Tom Taylor' <tom111.taylor@bell.net>, "mohamed.boucadair@orange-ftgroup.com" <mohamed.boucadair@orange-ftgroup.com>
Thread-Topic: [multrans] Draft Multrans BoF request
Thread-Index: AQHMKVEQI0ttNqtGZ0a/FRHSSyGv7JS6ujvwgABjLwA=
Date: Mon, 13 Jun 2011 10:52:46 +0000
Message-ID: <CA1B6430.10305%yiu_lee@cable.comcast.com>
In-Reply-To: <008701cc2987$09cbd9a0$1d638ce0$@com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.0.101115
x-originating-ip: [147.191.125.12]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <88AF7A2F8339D24F90D06D11BD91B076@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 'Jari Arkko' <jari.arkko@piuha.net>, "multrans@ietf.org" <multrans@ietf.org>
Subject: Re: [multrans] Draft Multrans BoF request
X-BeenThere: multrans@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss the work of IPv4-IPv6 multicast." <multrans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multrans>, <mailto:multrans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multrans>
List-Post: <mailto:multrans@ietf.org>
List-Help: <mailto:multrans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multrans>, <mailto:multrans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jun 2011 10:52:57 -0000

Thanks Tina!


On 6/13/11 1:02 AM, "Tina Tsou" <tena@huawei.com> wrote:

>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: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] On
>Behalf
>Of Lee, Yiu
>Sent: Sunday, June 12, 2011 4:36 PM
>To: Tom Taylor; mohamed.boucadair@orange-ftgroup.com
>Cc: 'Jari Arkko'; multrans@ietf.org
>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" <tom111.taylor@bell.net> 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, mohamed.boucadair@orange-ftgroup.com 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#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 : multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] De la
>>>part de Tina Tsou
>>> Envoyé : mardi 7 juin 2011 00:06
>>> À : multrans@ietf.org
>>> 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
>>> multrans@ietf.org
>>> https://www.ietf.org/mailman/listinfo/multrans
>>> _______________________________________________
>>> multrans mailing list
>>> multrans@ietf.org
>>> https://www.ietf.org/mailman/listinfo/multrans
>>>
>>>
>>_______________________________________________
>>multrans mailing list
>>multrans@ietf.org
>>https://www.ietf.org/mailman/listinfo/multrans
>
>_______________________________________________
>multrans mailing list
>multrans@ietf.org
>https://www.ietf.org/mailman/listinfo/multrans
>