Re: [multrans] Draft agenda for multicast transition interim

<mohamed.boucadair@orange.com> Wed, 07 December 2011 12:07 UTC

Return-Path: <mohamed.boucadair@orange.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 A6DDE21F8B94; Wed, 7 Dec 2011 04:07:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.025
X-Spam-Level:
X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXR-giGC22oa; Wed, 7 Dec 2011 04:07:34 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E65A321F8B02; Wed, 7 Dec 2011 04:07:33 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 6D7573247EC; Wed, 7 Dec 2011 13:07:32 +0100 (CET)
Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 52EC135C055; Wed, 7 Dec 2011 13:07:32 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 7 Dec 2011 13:07:32 +0100
From: mohamed.boucadair@orange.com
To: Ronald Bonica <rbonica@juniper.net>, Tina TSOU <Tina.Tsou.Zouting@huawei.com>, "multrans@ietf.org" <multrans@ietf.org>, MBONED WG <mboned@ietf.org>
Date: Wed, 07 Dec 2011 13:07:30 +0100
Thread-Topic: Draft agenda for multicast transition interim
Thread-Index: AQHMs6Ffjh6RlJwL9UOCkcshob2Wj5XN/LJggAEdUwCAAQ+9cA==
Message-ID: <94C682931C08B048B7A8645303FDC9F35A8D144894@PUEXCB1B.nanterre.francetelecom.fr>
References: <C0E0A32284495243BDE0AC8A066631A80C216ECF@szxeml526-mbx.china.huawei.com> <13205C286662DE4387D9AF3AC30EF456D74DE5BC2F@EMBX01-WF.jnpr.net>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74DE5BC2F@EMBX01-WF.jnpr.net>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.7.101515
Subject: Re: [multrans] Draft agenda for multicast transition interim
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: Wed, 07 Dec 2011 12:07:34 -0000

Dear Ron, all,

Please see inline.

Cheers,
Med 

> -----Message d'origine-----
> De : multrans-bounces@ietf.org 
> [mailto:multrans-bounces@ietf.org] De la part de Ronald Bonica
> Envoyé : mardi 6 décembre 2011 19:44
> À : Tina TSOU; multrans@ietf.org; MBONED WG
> Objet : Re: [multrans] Draft agenda for multicast transition interim
> 
> Hi Tina,
> 
> Thanks for the proposed agenda. A few comments are inline.
 
> 
> We might want to call the first agenda item "Overview" 
> instead of "Use Cases". IMHO, the Overview contains the 
> following parts:
> 
> - an introduction to the problem space
> - an introduction to the solution space
> 
> The crux of the problem is that multicast connectivity is 
> required among the following host types:
> 
> - dual-stack
> - IPv4-only
> - IPv6-only
> 
> Therefore, multicast data and signaling will need to traverse 
> IPv4/IPv6 boundaries. The IPv4/IPv6 boundary may be adjacent 
> to the source, at any point between the source and 
> destination, or adjacent to the destination. For some network 
> topologies (e.g., IPv4 edge, IPv6 core), multiple IPv4/IPv6 
> boundary crossings may be required. For the purpose of this 
> exercise, all network segments are assumed to be multicast enabled.
> 
> (You can talk about use cases here, but you probably don't 
> want to enumerate every possible use-case. Talk about a use 
> case only if it introduces new requirements for the 
> adaptation function that will be deployed at the IPv4/IPv6 boundary).
> 
> The solution space contains:
> 
> - a source discovery solution
> - a multicast address mapping solution
> - an adaptation function solution
> 
> More on each of those, below.  It would be great if we had a 
> short  draft to review before the first Interim meeting.

Below some pointers which may be of interest:

* Address mapping: http://tools.ietf.org/html/draft-boucadair-behave-64-multicast-address-format-03
* Service discovery using SDP (Use Cases): http://tools.ietf.org/html/draft-boucadair-mmusic-ipv6-use-cases-00#section-3
* Candidate solution for address discovery (SDP ALTC): http://tools.ietf.org/html/draft-boucadair-mmusic-altc-04
* Adaptation functions overview: http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-03#section-4.4
* Unicast/Multicast PREFIX provisioning: http://tools.ietf.org/html/draft-qin-softwire-multicast-prefix-option-01


Cheers,
Med