Re: [multrans] Draft agenda for multicast transition interim

 Tina nd Ron:

Have we set the date for the interim?

Sue 

-----Original Message-----
From: Tina TSOU 
Sent: Saturday, December 10, 2011 4:13 PM
To: Ronald Bonica; multrans@ietf.org; MBONED WG
Subject: RE: Draft agenda for multicast transition interim

Hi Ron,
Input Drafts for the first agenda item "Overview" are below.
1.
http://datatracker.ietf.org/doc/draft-tsou-multicast-transition-taxonomy/
A Classification and Evaluation of Approaches to Transitional Multicast 2.
http://datatracker.ietf.org/doc/draft-tsou-behave-translated-multicast/
A Generic Approach to Multicast Translation In Support of IPv6 Transition

Tina

-----Original Message-----
From: Ronald Bonica [mailto:rbonica@juniper.net]
Sent: Tuesday, December 06, 2011 10:44 AM
To: Tina TSOU; multrans@ietf.org; MBONED WG
Subject: RE: Draft agenda for multicast transition interim

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