Re: [multrans] Draft Multrans BoF request

<Olaf.Bonness@telekom.de> Tue, 07 June 2011 06:20 UTC

Return-Path: <Olaf.Bonness@telekom.de>
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 8708A11E8097 for <multrans@ietfa.amsl.com>; Mon, 6 Jun 2011 23:20:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 rC3e3ZZqJ1vg for <multrans@ietfa.amsl.com>; Mon, 6 Jun 2011 23:20:18 -0700 (PDT)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1D29011E8081 for <multrans@ietf.org>; Mon, 6 Jun 2011 23:20:17 -0700 (PDT)
Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 07 Jun 2011 08:17:05 +0200
Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.195]) by HE101251.emea1.cds.t-internal.com ([fe80::e428:2144:dcc5:bcce%15]) with mapi; Tue, 7 Jun 2011 08:17:05 +0200
From: <Olaf.Bonness@telekom.de>
To: <tena@huawei.com>, <multrans@ietf.org>
Date: Tue, 7 Jun 2011 08:17:03 +0200
Thread-Topic: [multrans] Draft Multrans BoF request
Thread-Index: AcwklYM01/VtPbTlQqqyEc7aBoR9LAARIg+Q
Message-ID: <CE8995AB5D178F44A2154F5C9A97CAF4024D34E79B90@HE111541.emea1.cds.t-internal.com>
References: <027f01cc2495$8596a070$90c3e150$@com>
In-Reply-To: <027f01cc2495$8596a070$90c3e150$@com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: jari.arkko@piuha.net
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: Tue, 07 Jun 2011 06:20:19 -0000

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: multrans-bounces@ietf.org
> [mailto:multrans-bounces@ietf.org] Im Auftrag von Tina Tsou
> Gesendet: Dienstag, 7. Juni 2011 00:03
> An: multrans@ietf.org
> Cc: 'Jari Arkko'
> Betreff: [multrans] Draft Multrans BoF request
>
> 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
>
>
>
> _______________________________________________
> multrans mailing list
> multrans@ietf.org
> https://www.ietf.org/mailman/listinfo/multrans
>