Re: [multrans] Draft agenda for multicast transition interim

Ronald Bonica <rbonica@juniper.net> Fri, 09 December 2011 19:15 UTC

Return-Path: <rbonica@juniper.net>
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 1C29421F86A5; Fri, 9 Dec 2011 11:15:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.592
X-Spam-Level:
X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 BitEC8dRV8me; Fri, 9 Dec 2011 11:15:45 -0800 (PST)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 705A421F8531; Fri, 9 Dec 2011 11:15:41 -0800 (PST)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTuJeUWejUikTjdCHLXbAnIQCaWGvMG8T@postini.com; Fri, 09 Dec 2011 11:15:45 PST
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 9 Dec 2011 11:14:03 -0800
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 9 Dec 2011 14:14:02 -0500
From: Ronald Bonica <rbonica@juniper.net>
To: "Lee, Yiu" <Yiu_Lee@cable.comcast.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "multrans@ietf.org" <multrans@ietf.org>, MBONED WG <mboned@ietf.org>
Date: Fri, 09 Dec 2011 14:14:00 -0500
Thread-Topic: [multrans] Draft agenda for multicast transition interim
Thread-Index: AQHMs6Ffjh6RlJwL9UOCkcshob2Wj5XN/LJggAEdUwCAAQ+9cIADrvDwgAAC14CAAAploA==
Message-ID: <13205C286662DE4387D9AF3AC30EF456D74E19E481@EMBX01-WF.jnpr.net>
References: <13205C286662DE4387D9AF3AC30EF456D74E0D8304@EMBX01-WF.jnpr.net> <CB07BED1.192AD%yiu_lee@cable.comcast.com>
In-Reply-To: <CB07BED1.192AD%yiu_lee@cable.comcast.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
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:15:46 -0000

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