Re: [multrans] Draft agenda for multicast transition interim

Ronald Bonica <rbonica@juniper.net> Tue, 06 December 2011 18:51 UTC

Return-Path: <rbonica@juniper.net>
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 C32A721F8BBA; Tue, 6 Dec 2011 10:51:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.59
X-Spam-Level:
X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 8ZxDFoUWfVts; Tue, 6 Dec 2011 10:51:34 -0800 (PST)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id B937321F8BB9; Tue, 6 Dec 2011 10:51:32 -0800 (PST)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTt5kKH0jMNPyIdEMN2SDjgIdp8HhZkwf@postini.com; Tue, 06 Dec 2011 10:51:33 PST
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 6 Dec 2011 10:44:14 -0800
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 6 Dec 2011 13:44:12 -0500
From: Ronald Bonica <rbonica@juniper.net>
To: Tina TSOU <Tina.Tsou.Zouting@huawei.com>, "multrans@ietf.org" <multrans@ietf.org>, MBONED WG <mboned@ietf.org>
Date: Tue, 06 Dec 2011 13:44:12 -0500
Thread-Topic: Draft agenda for multicast transition interim
Thread-Index: AQHMs6Ffjh6RlJwL9UOCkcshob2Wj5XN/LJggAEdUwA=
Message-ID: <13205C286662DE4387D9AF3AC30EF456D74DE5BC2F@EMBX01-WF.jnpr.net>
References: <C0E0A32284495243BDE0AC8A066631A80C216ECF@szxeml526-mbx.china.huawei.com>
In-Reply-To: <C0E0A32284495243BDE0AC8A066631A80C216ECF@szxeml526-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 06 Dec 2011 18:51:34 -0000

Hi Tina,

Thanks for the proposed agenda. A few comments are inline.

                                   Ron

> -----Original Message-----
> From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] On
> Behalf Of Tina TSOU
> Sent: Monday, December 05, 2011 8:04 PM
> To: multrans@ietf.org; MBONED WG
> Subject: [multrans] Draft agenda for multicast transition interim
> 
> Dear all,
> It is proposed to hold the multicast transition interim meeting as a
> series of short meetings. Timing of individual meetings may be set to
> spread inconvenient hours around the globe. The objective of these
> meetings is to achieve technical progress in the indicated topics. Here
> is the proposed agenda:
> 
> 1. Use Cases (1 hour)
> 
> Ensure we are all clear on what use cases will be in scope.

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.

> 
> 
> 2. Multicast address discovery by the receiver (2 hours)
> 
> How does the receiver learn the multicast addresses corresponding to
> specific programs, in the IP version that the receiver understands?

We might want to call this Multicast Source Discovery. The following are a few interesting questions:

- How are multicast sources identified?
- How dynamic is the Source Discovery Mechanism? Does it simple discover and announce every multicast stream in the network or is registration required?
- How do we ensure that the scope of the Source discovery mechanism is the same as the scope of the multicast network?
- Can the Source Discovery mechanism be crafted from existing protocols?

Again, it would be great if we had a draft to work from.

> 
> 
> 3. Multicast address translation (2 hours)
> 
> Stateless translation between IPv4 and IPv6 addresses should get
> priority in this discussion, but we may go on to the broader topic if
> there appears to be a need.

What broader topic? Stateful translation? Why go there?

> 
> 
> 4. What and how an adaptation function between the receiver and the
> network works (2 hours)
> 
> In cases where the receiver and the multicast-enabled network to which
> it is attached support different IP versions, an adaptation function
> (AF) is required between them. What are the requirements on that AF for
> the handling of multicast signalling and the handling of multicast
> content?
> 
> 5. What and how an adaptation function between two networks works (2
> hours)
> 
> In cases where two adjacent multicast-enabled networks support
> different
> IP versions, another type of adaptation function is needed. What are
> the
> requirements on that AF for the handling of multicast signalling and
> the
> handling of multicast content?
> 
> Comments on this draft agenda are invited.
> 
> Tina
> _______________________________________________
> multrans mailing list
> multrans@ietf.org
> https://www.ietf.org/mailman/listinfo/multrans