Re: [multrans] Draft agenda for multicast transition interim

["Lee, Yiu" <[e-mail]>]

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" <[e-mail]> 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?
>
>I will send my comments in a separate email.
>
>                                         Ron
>
>
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]]
>> Sent: Wednesday, December 07, 2011 7:08 AM
>> To: Ronald Bonica; Tina TSOU; [e-mail]; MBONED WG
>> Subject: RE: Draft agenda for multicast transition interim
>> 
>> Dear Ron, all,
>> 
>> Please see inline.
>> 
>> Cheers,
>> Med
>> 
>> > -----Message d'origine-----
>> > De : [e-mail]
>> > [mailto:[e-mail]] De la part de Ronald Bonica
>> > Envoyé : mardi 6 décembre 2011 19:44
>> > À : Tina TSOU; [e-mail]; 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
>_______________________________________________
>multrans mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/multrans