Subject: Re: [MBONED] Draft agenda for multicast transition interim

From: Ronald Bonica <[email-masked]>
Date: Tue, 6 Dec 2011 13:44:12 -0500

Hi Tina,

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

                                   Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tina TSOU
> Sent: Monday, December 05, 2011 8:04 PM
> To: [email-masked]; 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multrans

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 9 Dec 2011 13:28:21 -0500

Med,

draft-boucadair-behave-64-multicast-address-format appears to be pretty well cooked. Maybe the MBONED chairs could ask for a few volunteer reviewers?

I will send my comments in a separate email.

                                         Ron

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, December 07, 2011 7:08 AM
> To: Ronald Bonica; Tina TSOU; [email-masked]; MBONED WG
> Subject: RE: Draft agenda for multicast transition interim
> 
> Dear Ron, all,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : [email-masked]
> > [mailto:[email-masked]] De la part de Ronald Bonica
> > Envoyé : mardi 6 décembre 2011 19:44
> > À : Tina TSOU; [email-masked]; MBONED WG
> > Objet : Re: [multrans] Draft agenda for multicast transition interim
> >
> > Hi Tina,
> >
> > We might want to call the first agenda item "Overview"
> > instead of "Use Cases". IMHO, the Overview contains the
> > following parts:
> >
> > 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).
> >
> > 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

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 9 Dec 2011 14:14:00 -0500

This was proposed as part of the MULTRANS solution, so it is a candidate for adoption in MBONED.

                                                            Ron

> From: Lee, Yiu [mailto:[email-masked]]
> Sent: Friday, December 09, 2011 1:36 PM
> To: Ronald Bonica; [email-masked]; [email-masked];
> MBONED WG
> Subject: Re: [multrans] Draft agenda for multicast transition interim
> 
> Hi Ron,
> 
> We also have a question which WG would like to be home for this draft.
> We
> have couple of WG drafts relying on this in Softwire. We presented it
> in
> BEHAVE w/o much response. We would like to hear from the IESG where
> this
> draft should belong.
> 
> Regards,
> Yiu
> 
> On 12/9/11 1:28 PM, "Ronald Bonica" <[email-masked]> wrote:
> 
> >Med,
> >
> >draft-boucadair-behave-64-multicast-address-format appears to be
> pretty
> >well cooked. Maybe the MBONED chairs could ask for a few volunteer
> >reviewers?
> >

---

From: Tina TSOU <[email-masked]>
Date: Sat, 10 Dec 2011 21:12:59 +0000

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:[email-masked]] 
Sent: Tuesday, December 06, 2011 10:44 AM
To: Tina TSOU; [email-masked]; MBONED WG
Subject: RE: Draft agenda for multicast transition interim

Hi Tina,

                                   Ron

- dual-stack
- IPv4-only
- IPv6-only

---

From: Tom Taylor <[email-masked]>
Date: Sun, 11 Dec 2011 19:12:38 -0500

I can see a brief historical mention for taxonomy in the overview, since 
it was one of the triggers for the Multrans discussions in Prague. 
However, translated-multicast describes a stateful approach to 
translation, and people rejected it at the time as unnecessary. I'd say 
that one should "go into our back pocket" as a potential resource, bu 
need not take up our time at the interim meeting.

> A Generic Approach to Multicast Translation In Support of IPv6 Transition
...

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 12 Dec 2011 11:35:36 -0500

Hi Sue,

Given that the purpose of that meeting is to review Marshall's overview document, we should schedule the meeting for sometime after the draft has been posted and everyone has had a chance to read it.

Marshall, can you provide an ETA?

                             Ron

> From: Susan Hares [mailto:[email-masked]]
> Sent: Monday, December 12, 2011 11:03 AM
> To: Tina TSOU; Ronald Bonica; [email-masked]; MBONED WG
>  Tina nd Ron:
> Have we set the date for the interim?
> 
> Sue
> 
> From: Tina TSOU
> Sent: Saturday, December 10, 2011 4:13 PM
> To: Ronald Bonica; [email-masked]; MBONED WG
> > meetings is to achieve technical progress in the indicated topics.
> > Here is the proposed agenda:
> >
> > 1. Use Cases (1 hour)
> >
> We might want to call the first agenda item "Overview" instead of "Use
> Cases". IMHO, the Overview contains the following parts:
> 
> 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).
> 
> More on each of those, below.  It would be great if we had a short
> draft to review before the first Interim meeting.
> >
> >
> - 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?
> > (AF) is required between them. What are the requirements on that AF
> > for the handling of multicast signalling and the handling of
> multicast
> > content?
> >
> > 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?
> >

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 26 Dec 2011 17:16:24 -0500

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

> From: Tina TSOU [mailto:[email-masked]]
> for

---

From: Tina TSOU <[email-masked]>
Date: Tue, 27 Dec 2011 03:38:32 +0000

Ron,
Yes.

Tina

-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]] 
Sent: Monday, December 26, 2011 2:16 PM
To: Tina TSOU; MBONED WG
Subject: RE: Draft agenda for multicast transition interim

Tina,

                                      Ron