Re: [multrans] Draft agenda for multicast transition interim

"Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> Fri, 09 December 2011 19:17 UTC

Return-Path: <yiu_lee@cable.comcast.com>
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 7F2DE21F8A6F; Fri, 9 Dec 2011 11:17:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.735
X-Spam-Level:
X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 vK0U1ZiVbpTQ; Fri, 9 Dec 2011 11:17:49 -0800 (PST)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8561621F8880; Fri, 9 Dec 2011 11:17:49 -0800 (PST)
Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.63418493; Fri, 09 Dec 2011 12:18:18 -0700
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0339.001; Fri, 9 Dec 2011 14:17:29 -0500
From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
To: Ronald Bonica <rbonica@juniper.net>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "multrans@ietf.org" <multrans@ietf.org>, MBONED WG <mboned@ietf.org>
Thread-Topic: [multrans] Draft agenda for multicast transition interim
Thread-Index: AQHMs6Ffjh6RlJwL9UOCkcshob2Wj5XN/LJggAEdUwCAAQ+9cIADrvDwgAAC14CAAAploIAAASiA
Date: Fri, 09 Dec 2011 19:17:26 +0000
Message-ID: <CB07C8E1.192B8%yiu_lee@cable.comcast.com>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74E19E481@EMBX01-WF.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [69.241.25.0]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <8A7FC06B62BFF84A94840B2E549BB465@cable.comcast.com>
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: Fri, 09 Dec 2011 19:17:50 -0000

Thanks.

On 12/9/11 2:14 PM, "Ronald Bonica" <rbonica@juniper.net> wrote:

>This was proposed as part of the MULTRANS solution, so it is a candidate
>for adoption in MBONED.
>
>                                                            Ron
>
>
>> -----Original Message-----
>> From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com]
>> Sent: Friday, December 09, 2011 1:36 PM
>> To: Ronald Bonica; mohamed.boucadair@orange.com; multrans@ietf.org;
>> 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" <rbonica@juniper.net> 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: mohamed.boucadair@orange.com
>> >> [mailto:mohamed.boucadair@orange.com]
>> >> Sent: Wednesday, December 07, 2011 7:08 AM
>> >> To: Ronald Bonica; Tina TSOU; multrans@ietf.org; MBONED WG
>> >> Subject: RE: Draft agenda for multicast transition interim
>> >>
>> >> Dear Ron, all,
>> >>
>> >> Please see inline.
>> >>
>> >> Cheers,
>> >> Med
>> >>
>> >> > -----Message d'origine-----
>> >> > De : multrans-bounces@ietf.org
>> >> > [mailto:multrans-bounces@ietf.org] De la part de Ronald Bonica
>> >> > Envoyé : mardi 6 décembre 2011 19:44
>> >> > À : Tina TSOU; multrans@ietf.org; 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
>> >multrans@ietf.org
>> >https://www.ietf.org/mailman/listinfo/multrans
>