Re: [MBONED] Draft agenda for multicast transition interim

Tina,

Would it be possible to condense everything that needs to be discussed in the Overview into the draft that you are working on with Marshall and Stig?

                                      Ron

> -----Original Message-----
> From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]
> 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