From gjshep@gmail.com Thu Sep 1 19:16:48 2011 Return-Path: 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 D4A9D21F913C for ; Thu, 1 Sep 2011 19:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.855 X-Spam-Level: X-Spam-Status: No, score=-103.855 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 rQO4Xk2dF+ZW for ; Thu, 1 Sep 2011 19:16:48 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E939121F916C for ; Thu, 1 Sep 2011 19:16:47 -0700 (PDT) Received: by bkar4 with SMTP id r4so2869130bka.31 for ; Thu, 01 Sep 2011 19:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=NpADkcmVHoGojFemx4NgafmcJ4YZq8nYBXMd4Fa5b6E=; b=cRX9cb7vId54zNUaYIT85CXi6+1Y8iXT/BS33qpNsoZBJVJee+QJC1ZKDCHIZDS+RJ uL6Gqp76at2YjnayttS/bQzmxiHtJAg3jRWY2Iv+8nkHuISWV0AtQlsn88bPJhxmaUpp OhSpX+0wAwgRRSjr5cMD7zYFp/rwez3tLB5Co= MIME-Version: 1.0 Received: by 10.204.135.23 with SMTP id l23mr240549bkt.273.1314929874877; Thu, 01 Sep 2011 19:17:54 -0700 (PDT) Received: by 10.204.36.11 with HTTP; Thu, 1 Sep 2011 19:17:54 -0700 (PDT) Date: Thu, 1 Sep 2011 19:17:54 -0700 Message-ID: From: Greg Shepherd To: multrans@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [multrans] Multrans Quebec Minutes X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 02:16:48 -0000 Here's the like to the jabber scribe/minutes. Please review and send any corrections or clarifications and I'll edit and post. http://www.ietf.org/jabber/logs/multrans@jabber.ietf.org/2011-07-25.html Thanks!, Greg From ycai@cisco.com Thu Sep 1 23:27:44 2011 Return-Path: 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 31CC521F8DE8 for ; Thu, 1 Sep 2011 23:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] 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 NI-elD5nieHU for ; Thu, 1 Sep 2011 23:27:43 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 921B121F8DE7 for ; Thu, 1 Sep 2011 23:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ycai@cisco.com; l=781; q=dns/txt; s=iport; t=1314944959; x=1316154559; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=DziMsQwpSSrVIc9zpNgiu1Eldz8AAvYcyUd8h6+2/jY=; b=jwvHHAcDT/eoF0P1MNSQ44Yyy7cMQq6WgkMBNJvb4wy+7IJw2lZ1BGes 0Ns3WXOLXF1GSRdS6T7+xT7kI5nMsVwPVNKleYvCIEy30khU9qydnBgCN 0j1OOSe9DVWojEmC+3vQg/F7y3k2JnNfbCpwmTH4MVRC7eG+Qo/cOPpQE I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOx2YE6rRDoI/2dsb2JhbABCqFh4gUYBAQEBAgEBAQEPAScCATEQDQEIZwYwAQEEARIJGYdQBJhwAZ8nhmUEh2mLQ4UXhGSHMQ X-IronPort-AV: E=Sophos;i="4.68,317,1312156800"; d="scan'208";a="18750653" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-6.cisco.com with ESMTP; 02 Sep 2011 06:29:18 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p826THXF029297; Fri, 2 Sep 2011 06:29:17 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Sep 2011 23:29:17 -0700 Received: from 10.21.115.59 ([10.21.115.59]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Sep 2011 06:29:17 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 01 Sep 2011 23:30:04 -0700 From: Yiqun Cai To: , Message-ID: Thread-Topic: [multrans] Multrans Quebec Minutes Thread-Index: AcxpOb/etVivdp/ZgUO3HI/Lw9Bl8w== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Sep 2011 06:29:17.0610 (UTC) FILETIME=[A43830A0:01CC6939] Subject: Re: [multrans] Multrans Quebec Minutes X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 06:27:44 -0000 It is good notes. Given the amount of discussion that took place, this is probably as good as it can get. Thanks. Now, a minor request I hope the chairs can accommodate. Please replace the "i chun/ichun/i ching/" with "yiqun". And "bill prestegn" with "bill ver steeg". Thanks. On 9/1/11 7:17 PM, "Greg Shepherd" wrote: > Here's the like to the jabber scribe/minutes. Please review and send > any corrections or clarifications and I'll edit and post. > > http://www.ietf.org/jabber/logs/multrans@jabber.ietf.org/2011-07-25.html > > Thanks!, > Greg > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans -- Yiqun From mohamed.boucadair@orange-ftgroup.com Sun Sep 4 22:39:04 2011 Return-Path: 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 F26AC21F8802 for ; Sun, 4 Sep 2011 22:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 EVEiRQ1zwlma for ; Sun, 4 Sep 2011 22:39:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3918B21F871E for ; Sun, 4 Sep 2011 22:39:04 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 606753B439E; Mon, 5 Sep 2011 07:40:46 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 49F01180054; Mon, 5 Sep 2011 07:40:46 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 5 Sep 2011 07:40:46 +0200 From: To: Tina TSOU , "multrans@ietf.org" Date: Mon, 5 Sep 2011 07:40:44 +0200 Thread-Topic: [multrans] Use Cases For Multicast Transition From IPv4 to IPv6 Thread-Index: Acxi1BaYo6QQdnVdRL2MD7isZroNsQIuTtqQ Message-ID: <94C682931C08B048B7A8645303FDC9F3516735EE77@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.9.5.42414 Subject: Re: [multrans] Use Cases For Multicast Transition From IPv4 to IPv6 X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 05:39:05 -0000 Hi Tina, I read this document and I must admit it overlaps with http://tools.ietf.or= g/html/draft-jaclee-behave-v4v6-mcast-ps-02#section-3.=20 We tried in the problem statement document to provide a prioritization of t= he use cases instead of just listing them. This prioritization work is impo= rtant IMHO in a first stage to keep work items very focused.=20 Cheers, Med =20 -----Message d'origine----- De : multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] De la par= t de Tina TSOU Envoy=E9 : jeudi 25 ao=FBt 2011 05:07 =C0 : multrans@ietf.org Objet : [multrans] Use Cases For Multicast Transition From IPv4 to IPv6: dr= aft-tsou-multrans-use-cases Hi all, Here is an I-D about Use Cases for Multicast Transition from IPv4 to IPv6. https://datatracker.ietf.org/doc/draft-tsou-multrans-use-cases/ We may use this version as a starting point for the WG to do use cases bash= ing. Abstract Like other internet activities, multicast is affected by the fact that the transition from IPv4 to IPv6 is occurring over a period of years, via multiple transition paths. As a result, mechanisms need to be added to the basic multicast architecture to assist in specific transition scenarios. This document describes detailed use cases so that the requirements for the multicast transition mechanisms can be better understood. The considered opinion in discussions to date on multicast transition requirements has been that the two most important transition scenarios in the near future will be the "4-6-4" and "6-4" network scenarios. These scenarios are described in detail below, in their several possible variants, showing the new issues that IPv6 transition raises for multicast operation. There is further general agreement that Any-Source Multicast (ASM) (the service, not necessarily the technology) is no longer an important use case. As a result, this document restricts itself to scenarios where the set of multicast sources is separate from the set of multicast receivers. As a final restriction, it assumes a single administrative provider domain. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html _______________________________________________ multrans mailing list multrans@ietf.org https://www.ietf.org/mailman/listinfo/multrans From Tina.Tsou.Zouting@huawei.com Fri Sep 9 23:58:10 2011 Return-Path: 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 9DD4321F85F1 for ; Fri, 9 Sep 2011 23:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.294 X-Spam-Level: X-Spam-Status: No, score=-6.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 uatMxk9Qr+8X for ; Fri, 9 Sep 2011 23:58:09 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 93CC821F85EF for ; Fri, 9 Sep 2011 23:58:09 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRA00EEUOS3R8@szxga03-in.huawei.com> for multrans@ietf.org; Sat, 10 Sep 2011 15:00:03 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRA00FEIOS344@szxga03-in.huawei.com> for multrans@ietf.org; Sat, 10 Sep 2011 15:00:03 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADX15370; Sat, 10 Sep 2011 15:00:03 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 10 Sep 2011 14:59:51 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.247]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Sat, 10 Sep 2011 14:59:58 +0800 Date: Sat, 10 Sep 2011 06:59:57 +0000 From: Tina TSOU In-reply-to: <94C682931C08B048B7A8645303FDC9F3516735EE77@PUEXCB1B.nanterre.francetelecom.fr> X-Originating-IP: [10.212.245.85] To: "mohamed.boucadair@orange-ftgroup.com" , "multrans@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [multrans] Use Cases For Multicast Transition From IPv4 to IPv6 Thread-index: Acxi1BaYo6QQdnVdRL2MD7isZroNsQIuTtqQAP4j6zA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <94C682931C08B048B7A8645303FDC9F3516735EE77@PUEXCB1B.nanterre.francetelecom.fr> Subject: Re: [multrans] Use Cases For Multicast Transition From IPv4 to IPv6 X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2011 06:58:10 -0000 Hi Med, See the meeting minutes from Quebec BoF. 4-6-4 has got one of the highest priorities as you wish.=20 And the BoF co-chair Greg explicitly asked a presentation and eventually an= I-D for the use cases. The two volunteers raised their hands in the Quebec= BoF meeting include Yiu and me, if I remember correctly. Hi Greg, Would you clarify a little bit more? Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: mohamed.boucadair@orange-ftgroup.com [mailto:mohamed.boucadair@orange= -ftgroup.com]=20 Sent: Sunday, September 04, 2011 10:41 PM To: Tina TSOU; multrans@ietf.org Subject: RE: [multrans] Use Cases For Multicast Transition From IPv4 to IPv= 6 Hi Tina, I read this document and I must admit it overlaps with http://tools.ietf.or= g/html/draft-jaclee-behave-v4v6-mcast-ps-02#section-3.=20 We tried in the problem statement document to provide a prioritization of t= he use cases instead of just listing them. This prioritization work is impo= rtant IMHO in a first stage to keep work items very focused.=20 Cheers, Med =20 -----Message d'origine----- De : multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] De la par= t de Tina TSOU Envoy=E9 : jeudi 25 ao=FBt 2011 05:07 =C0 : multrans@ietf.org Objet : [multrans] Use Cases For Multicast Transition From IPv4 to IPv6: dr= aft-tsou-multrans-use-cases Hi all, Here is an I-D about Use Cases for Multicast Transition from IPv4 to IPv6. https://datatracker.ietf.org/doc/draft-tsou-multrans-use-cases/ We may use this version as a starting point for the WG to do use cases bash= ing. Abstract Like other internet activities, multicast is affected by the fact that the transition from IPv4 to IPv6 is occurring over a period of years, via multiple transition paths. As a result, mechanisms need to be added to the basic multicast architecture to assist in specific transition scenarios. This document describes detailed use cases so that the requirements for the multicast transition mechanisms can be better understood. The considered opinion in discussions to date on multicast transition requirements has been that the two most important transition scenarios in the near future will be the "4-6-4" and "6-4" network scenarios. These scenarios are described in detail below, in their several possible variants, showing the new issues that IPv6 transition raises for multicast operation. There is further general agreement that Any-Source Multicast (ASM) (the service, not necessarily the technology) is no longer an important use case. As a result, this document restricts itself to scenarios where the set of multicast sources is separate from the set of multicast receivers. As a final restriction, it assumes a single administrative provider domain. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html _______________________________________________ multrans mailing list multrans@ietf.org https://www.ietf.org/mailman/listinfo/multrans From spencer@wonderhamster.org Wed Sep 14 08:10:57 2011 Return-Path: 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 7904821F8CB3 for ; Wed, 14 Sep 2011 08:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, STOX_REPLY_TYPE=0.001, 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 DyKf4ERFHNBR for ; Wed, 14 Sep 2011 08:10:44 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 209DE21F8B61 for ; Wed, 14 Sep 2011 08:10:44 -0700 (PDT) Received: from S73602b ([50.58.7.243]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MHGpv-1QrXKE35DH-00DkfK; Wed, 14 Sep 2011 11:12:51 -0400 Message-ID: <84062BDB236B4F2EB392E782A1AC4DD8@china.huawei.com> From: "Spencer Dawkins" To: "Tina TSOU" , References: Date: Wed, 14 Sep 2011 10:12:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Provags-ID: V02:K0:UAk1Xlk/nlIma6H7LMkMM1FzOKhQ1349iNtAdRXodXW t3s99hRsfi9otS/Zo405KSeVvdk3+XnKjae3wH/4NSP84oklAl llD36oLKNynki2p9YqGBiqpqBDiCAOu+gMqwmY1LsZGTrOc9Bv +vd9pVb1UqtaJ35NXM1nIUwIqnkho90VwKb0LVc2pAuWdz5RIZ KKabOIGSVB9yaxQW38wQrX3uYYWf0tl9wpQ7R2GYOwHlPJcx3V 0rJpy1PLl4dkMbWVtBj2ac6AkBDV9ISuikGsL5bXnxmZ5RTD2v EaMjAKmi6M44/pHT4loZbz1FLJRLeJ8AGj1Gy/wXjuzOZL9T4o H/1cclse0DydkS4FDd3ECc4wqGmsBPoTRk4PO08fp Subject: Re: [multrans] Draft Multrans 2nd BoF request X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 15:10:57 -0000 (Speaking as individual) Just as a schedule check, the cutoff date for IETF 82 BOF requests is 10/03 (according to http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF82). The only response I've seen to this proposal was from Dan Wing, asking that BEHAVE be added to the first-priority conflict list. Are there any other suggestions that people would like to make? If so, it might be great to say something before the BOF request goes in. Thanks, Spencer (as individual) > Hi all, > This is draft Multrans 2nd BoF request. Comments are welcome. > > --------------------------------------------------------- > Working Group Name: Multrans BOF > Area Name: Transport Area > Session Requester: Tina Tsou > > Number of Sessions: 1 > Length of Session(s): 2 hours > > > Number of Attendees: 100 > Conflicts to Avoid: > First Priority: PIM, MBONED, RMT, V6OPS, SOFTWIRE > Second Priority: tsvarea intarea > > Special Requests: > N/A > > In current deployments, the IP multicast forwarding scheme is used by many > providers to deliver some services, such as live TV broadcasting. > Transition to IPv6 raises issues and corresponding requirements. In > particular, IPv4 service continuity is an essential requirement from a > business perspective. > This specifically includes continued receiver access to IPv4-formatted > contents even when the assignment of a dedicated global IPv4 address to > the receiver is no longer possible and even after the receivers have > migrated to IPv6. > Likewise, the delivery of IPv6-formatted contents to IPv4 receivers must > also be possible. > Multicast transition scenarios include the ability to access > IPv4-formatted multicast contents from an IPv4 receiver over an IPv6-only > network and the ability to access IPv4-formatted multicast contents from > an IPv6-only receiver. > The aforementioned issues can be classified into: > . Multicast group and source discovery procedures > . Multicast group subscription procedures > . Multicast tree computation > . Required IPv4-IPv6 multicast inter-working functions > The proposed BoF session aims at discussing use cases and prioritizing > list of issues, forming a new WG. > The proposed agenda for the BoF session goes like this: > . Welcome introduction and agenda bashing (chairs, 10 min) > . Use cases (TBD, 30 min) > . Prioritizing list of issues (TBD, 30 min) > . Discussion (all, 30 min) > . Conclusion and next steps (chairs, ADs, 20 min) > Reading material: > http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02 > http://tools.ietf.org/html/draft-tsou-multrans-use-cases-00 > --------------------------------------------------------- > > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans From gjshep@gmail.com Wed Sep 14 08:26:01 2011 Return-Path: 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 00BBE21F8C57 for ; Wed, 14 Sep 2011 08:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.495 X-Spam-Level: X-Spam-Status: No, score=-103.495 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 d1kQpTOqwOCc for ; Wed, 14 Sep 2011 08:26:00 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CBC6F21F8B34 for ; Wed, 14 Sep 2011 08:25:59 -0700 (PDT) Received: by bkaq10 with SMTP id q10so1803658bka.31 for ; Wed, 14 Sep 2011 08:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=0XFo51ugcNQhxctUpX3f8f+WSdeyloL4ZS0+lSjvqTY=; b=FUTKOAH+lEZRo2i/y62HEwDVvhMPbLW2TuhtVwVBmPBdG/iEOm2ze9a35c+VH2lPYN 9oWN+9qH7OloZUEb2S9kFtrHfRr/IDdee3TL/l77u/dGVIXrgTa78mURVr+uyfU4pcHZ W19LcQmgE3LI5VoRPlQg+JLK17Npa+ueXKLAg= MIME-Version: 1.0 Received: by 10.204.132.82 with SMTP id a18mr223683bkt.356.1316014088306; Wed, 14 Sep 2011 08:28:08 -0700 (PDT) Received: by 10.204.51.132 with HTTP; Wed, 14 Sep 2011 08:28:08 -0700 (PDT) In-Reply-To: <84062BDB236B4F2EB392E782A1AC4DD8@china.huawei.com> References: <84062BDB236B4F2EB392E782A1AC4DD8@china.huawei.com> Date: Wed, 14 Sep 2011 08:28:08 -0700 Message-ID: From: Greg Shepherd To: Spencer Dawkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multrans@ietf.org Subject: Re: [multrans] Draft Multrans 2nd BoF request X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 15:26:01 -0000 First Priority please: PIM, MBONED, Softwire Thanks, Greg On Wed, Sep 14, 2011 at 8:12 AM, Spencer Dawkins wrote: > (Speaking as individual) > > Just as a schedule check, the cutoff date for IETF 82 BOF requests is 10/= 03 > (according to http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF82). > The only response I've seen to this proposal was from Dan Wing, asking th= at > BEHAVE be added to the first-priority conflict list. > > Are there any other suggestions that people would like to make? If so, it > might be great to say something before the BOF request goes in. > > Thanks, > > Spencer (as individual) > >> Hi all, >> This is draft Multrans 2nd BoF request. Comments are welcome. >> >> --------------------------------------------------------- >> Working Group Name: Multrans BOF >> Area Name: Transport Area >> Session Requester: Tina Tsou >> >> Number of Sessions: 1 >> Length of Session(s): =A02 hours >> >> >> Number of Attendees: 100 >> Conflicts to Avoid: >> =A0First Priority: PIM, MBONED, RMT, V6OPS, SOFTWIRE >> =A0Second Priority: tsvarea intarea >> >> Special Requests: >> =A0N/A >> >> In current deployments, the IP multicast forwarding scheme is used by ma= ny >> providers to deliver some services, such as live TV broadcasting. >> Transition to IPv6 raises issues and corresponding requirements. In >> particular, IPv4 service continuity is an essential requirement from a >> business perspective. >> This specifically includes continued receiver access to IPv4-formatted >> contents even when the assignment of a dedicated global IPv4 address to = the >> receiver is no longer possible and even after the receivers have migrate= d to >> IPv6. >> Likewise, the delivery of IPv6-formatted contents to IPv4 receivers must >> also be possible. >> Multicast transition scenarios include the ability to access >> IPv4-formatted multicast contents from an IPv4 receiver over an IPv6-onl= y >> network and the ability to access IPv4-formatted multicast contents from= an >> IPv6-only receiver. >> The aforementioned issues can be classified into: >> . Multicast group and source discovery procedures >> . Multicast group subscription procedures >> . Multicast tree computation >> . Required IPv4-IPv6 multicast inter-working functions >> The proposed BoF session aims at discussing use cases and prioritizing >> list of issues, forming a new WG. >> The proposed agenda for the BoF session goes like this: >> . Welcome introduction and agenda bashing (chairs, 10 min) >> . Use cases (TBD, 30 min) >> . Prioritizing list of issues (TBD, 30 min) >> . Discussion (all, 30 min) >> . Conclusion and next steps (chairs, ADs, 20 min) >> Reading material: >> http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02 >> http://tools.ietf.org/html/draft-tsou-multrans-use-cases-00 >> --------------------------------------------------------- >> >> >> >> Best Regards, >> Tina TSOU >> http://tinatsou.weebly.com/contact.html >> >> >> >> _______________________________________________ >> multrans mailing list >> multrans@ietf.org >> https://www.ietf.org/mailman/listinfo/multrans > > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans > From spencer@wonderhamster.org Wed Sep 14 11:09:44 2011 Return-Path: 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 7736321F8C42 for ; Wed, 14 Sep 2011 11:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 Umn--ruZl5+g for ; Wed, 14 Sep 2011 11:09:41 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 1495C21F8C3F for ; Wed, 14 Sep 2011 11:09:40 -0700 (PDT) Received: from S73602b ([50.58.7.243]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M09S8-1ROa5I19uW-00ucQI; Wed, 14 Sep 2011 14:11:49 -0400 Message-ID: From: "Spencer Dawkins" To: Date: Wed, 14 Sep 2011 13:11:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1589_01CC72DF.DB112870" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Provags-ID: V02:K0:1uXH/6TSVu6zFN8PwbaO0FR3i4yj1mMYzNlSSvtt60s mFrYg2+W69EDAFgoQNdj7w4Qck5eO0wyFJPgA/K+CyV33YMebz zQP4GBIQ2xXmQF+rMl67Hc6QMUqudY7uEIllwSyF5ty6BqgHmR MLgAmwIm+u9X4s6rqqkyh48vlbLjgAWsTwbbHKQItF2X1vzFmu VP79Y8aoWO3wH6wN5XpUV9ow4T/x0a9yZ6eTb3IPuqXrfSB5lJ f8zvL4yVwwSoclaQNAiD25Hv2zY0h8tD3uIThKED6rlhZ0sHEM efQe18JRJ7A625/zXEKCOs1xniyirTwljSxciwH0cb9KMRn5Ng mfL+pROZJ6iHl8QaMG/I0Yw9FY34wc52LooaE5WSI Subject: [multrans] Fw: Draft Multrans BoF request X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 18:09:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1589_01CC72DF.DB112870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Me again, speaking as an individual again ... The goal in the draft BOF request is to form a working group. The most = recent proposed charter I've seen on the mailing list is this one, from = before the (excellent) BOF at IETF 81 (if I'm reading Tina's note = correctly, this version was created before the informal meeting at IETF = 80). Is a more recent version available? Thanks, Spencer, speaking as an individual ----- Original Message -----=20 From: Tina Tsou=20 To: 'Jari Arkko'=20 Cc: multrans@ietf.org=20 Sent: Tuesday, June 14, 2011 2:03 AM Subject: Re: [multrans] Draft Multrans BoF request Jari, About the proposed charter, here is a copy from the presentation in = IPv4-IPv6 multicast meetings in Prague in March. =20 The task of this Working Group is to devise the means whereby existing multicast distribution mechanisms can work when signalling and content = have to traverse one or more boundaries where IP version changes. =20 The Working Group will consider three cases: -- provider distributed multicast (including IPTV); -- multicast networks connected directly to a multicast backbone = network; -- multicast networks separated from the backbone network by unicast . =20 The Working Group's first task is to create a Problem Statement. This documents will specify the requirements that must be satisfied by = multicast transition solutions for the three cases listed above. It will describe = the scenarios that need to be considered and the challenges posed by those scenarios in thos e three em Statement will specify the new functional capabilities required to enable the solution of the multicast transition problem in the different scenarios. =20 The Working Group will follow up with one or more framework documents analyzing the potential multicast transition solutions for specific scenarios or groups of scenarios. The circumstances under which the different solution approaches are applicable will be described, taking account of the unicast transition mechanisms that may be deployed in a given network . The fr lude a view of the evolution path for multicast transition over time, possibly though not necessarily = as a function of the associated unicast transition path. The final outcome = of framework drafts should be recommendations for preferred solution approaches. =20 Finally, the Working Group will produce a small set of solution drafts = for the cases considered to be of the highest priority before re-chartering = or disbandment. Specifically, the Working Group will provide one or two solutions for the provider distrib uted mul icast source and receiver are IPv4 and there is an intervening IPv6 network. = The solution(s) must be compatible with the unicast translation (NAT64) and tunneling (DS Lite, Gateway-Initiated DS lite) transition mechanisms. = The solution(s) must discuss the considerations specifically relevant to = these three unicast transition mechanisms to the extent this di scussion=20 covered by the framework document. The Working Group will also provide a solution for the case of multicast networks connected directly to a multicast backbone network. =20 Relations: Behave, Softwires, PIM, Mboned, V6ops =20 Deliverables: Problem Statement (Informational) Framework for the provider distributed = multicast case (Informational) Framework for the case of multicast networks connected directly to a multicast backbone network (Informational) Solutions (2-3) (Proposed Standard)=20 =20 We keep our promises with one another - no matter what! =20 Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html =20 From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Monday, June 13, 2011 11:09 AM To: Tina Tsou Cc: Lee, Yiu; 'Tom Taylor'; mohamed.boucadair@orange-ftgroup.com; = multrans@ietf.org Subject: Re: [multrans] Draft Multrans BoF request Tina, others, I'm trying to construct a wiki entry for this BOF so that the IESG and = IAB have all the information available to them to make decisions on what = BOFs to approve on Thursday. What other drafts than the ps I should = list? Is there a pointer to a mailing list post or some web site for the = proposed charter? Also, for my background: are there providers who are = asking for multicast transition solutions? I.e., not just deploying = multicast separately for the two IP versions? Here's what we have so far: MULTRANS - Multicast Transition=20 Description Jari -------------------------------------------------------------------------= ------- _______________________________________________ multrans mailing list multrans@ietf.org https://www.ietf.org/mailman/listinfo/multrans ------=_NextPart_000_1589_01CC72DF.DB112870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Me again, speaking as an individual again = ...
 
The goal in the draft BOF request is to form a = working group.=20 The most recent proposed charter I've seen on the mailing list is this = one, from=20 before the (excellent) BOF at IETF 81 (if I'm reading Tina's note = correctly,=20 this version was created before the informal meeting at IETF = 80).
 
Is a more recent version available?
 
Thanks,
 
Spencer, speaking as an individual
 
----- Original Message -----=20
From: Tina Tsou =
Sent: Tuesday, June 14, 2011 2:03 AM
Subject: Re: [multrans] Draft Multrans BoF = request

Jari,

About=20 the proposed charter, here is a copy from the presentation in IPv4-IPv6=20 multicast meetings in Prague in March.

 

The=20 task of this Working Group is to devise the means whereby=20 existing

multicast=20 distribution mechanisms can work when signalling and=20 content have

to=20 traverse one or more boundaries where IP version = changes.

 

The Working Group will consider three=20 cases:

--=20 provider distributed multicast (including=20 IPTV);

--=20 multicast networks connected directly to a = multicast=20 backbone network;

--=20 multicast networks separated from the = backbone network=20 by unicast

.

 

The=20 Working Group's first task is to create a Problem Statement.=20 This

documents=20 will specify the requirements that must be satisfied by=20 multicast

transition=20 solutions for the three cases listed above. It will describe=20 the

scenarios=20 that need to be considered and the challenges posed by=20 those

scenarios=20 in thos e three em Statement will specify

the=20 new functional capabilities required to enable the solution of=20 the

multicast=20 transition problem in the different scenarios.

 

The Working Group will follow up with one or more framework=20 documents

analyzing=20 the potential multicast transition solutions for = specific

scenarios=20 or groups of scenarios. The circumstances under which = the

different=20 solution approaches are applicable will be described,=20 taking

account=20 of the unicast transition mechanisms that = may be=20 deployed in a

given=20 network . The fr lude a view of the evolution

path=20 for multicast transition over time, possibly though not necessarily=20 as

a=20 function of the associated unicast = transition path.=20 The final outcome of

framework=20 drafts should be recommendations for preferred = solution

approaches.

 

Finally,=20 the Working Group will produce a small set of solution drafts=20 for

the=20 cases considered to be of the highest priority before re-chartering=20 or

disbandment.=20 Specifically, the Working Group will provide one or = two

solutions=20 for the provider distrib uted mul icast

source=20 and receiver are IPv4 and there is an intervening IPv6 network.=20 The

solution(s)=20 must be compatible with the unicast = translation=20 (NAT64) and

tunneling (DS Lite, Gateway-Initiated DS = lite) transition mechanisms. = The

solution(s)=20 must discuss the considerations specifically relevant to=20 these

three=20 unicast transition mechanisms to the extent = this di=20 scussion

covered=20 by the framework document. The Working Group will also provide=20 a

solution=20 for the case of multicast networks connected directly to = a

multicast backbone=20 network.

 

Relations:=20 Behave, Softwires, PIM, Mboned,=20 V6ops

 

Deliverables:

Problem=20 Statement (Informational) Framework=20 for the provider distributed multicast case=20 (Informational)

Framework=20 for the case of multicast networks connected directly to = a

multicast=20 backbone network (Informational)

Solutions=20 (2-3) (Proposed Standard)

 

We=20 keep our promises with one another =96 no matter = what!

 

Best=20 Regards,

Tina=20 TSOU

http://tinatsou.weebly.com/contact= .html

 

From:=20 Jari Arkko [mailto:jari.arkko@piuha.net]
Sent: Monday, June = 13, 2011=20 11:09 AM
To: Tina Tsou
Cc: Lee, Yiu; 'Tom Taylor';=20 mohamed.boucadair@orange-ftgroup.com; = multrans@ietf.org
Subject: Re:=20 [multrans] Draft Multrans BoF request

Tina, = others,

I'm=20 trying to construct a wiki entry for this BOF so that the IESG and IAB = have all=20 the information available to them to make decisions on what BOFs to = approve on=20 Thursday. What other drafts than the ps I should list? Is there a = pointer to a=20 mailing list post or some web site for the proposed charter? Also, for = my=20 background: are there providers who are asking for multicast transition=20 solutions? I.e., not just deploying multicast separately for the two IP=20 versions?

Here's what we have so far:

MULTRANS - Multicast Transition

DescriptionLength of session: 120 minutes
Responsible AD: Jari Arkko, Ralph Droms, and = David Harrington
Mailing list: =A0https://www.ietf.org/mailman/listinfo/multrans=
Drafts: [= =A0jaclee-behave-v4v6-mcast-ps]
Agenda: [=A0agenda]
Charter: TBD
Status: Under consideration < /span>
Jari

_______________________________________________
multrans = mailing=20 list
multrans@ietf.org
https://www.ietf.org/mailman/listinfo/multra= ns
------=_NextPart_000_1589_01CC72DF.DB112870-- From Tina.Tsou.Zouting@huawei.com Wed Sep 14 12:59:40 2011 Return-Path: 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 621CD21F8BE5 for ; Wed, 14 Sep 2011 12:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.962 X-Spam-Level: X-Spam-Status: No, score=-5.962 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] 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 KLoWeTee30JV for ; Wed, 14 Sep 2011 12:59:39 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 55E3821F8BC4 for ; Wed, 14 Sep 2011 12:59:39 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ0025V3MZOR@szxga05-in.huawei.com> for multrans@ietf.org; Thu, 15 Sep 2011 04:01:47 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ000NA3MYW2@szxga05-in.huawei.com> for multrans@ietf.org; Thu, 15 Sep 2011 04:01:47 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADZ00731; Thu, 15 Sep 2011 04:01:44 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 15 Sep 2011 04:01:40 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.247]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Thu, 15 Sep 2011 04:01:41 +0800 Date: Wed, 14 Sep 2011 20:01:40 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.193.34.116] To: "gjshep@gmail.com" , Spencer Dawkins Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [multrans] Draft Multrans 2nd BoF request Thread-index: AQHMcvDKxsRgOL56m0O6YMBJRshTH5VMedEAgAC9wGA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <84062BDB236B4F2EB392E782A1AC4DD8@china.huawei.com> Cc: "multrans@ietf.org" Subject: Re: [multrans] Draft Multrans 2nd BoF request X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 19:59:40 -0000 Greg, See >> Conflicts to Avoid: >> First Priority: PIM, MBONED, RMT, V6OPS, SOFTWIRE, BEHAVE Do you mean delete RMT and V6OPS from the list? Or is it just fine as above= ? Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Greg Shepherd [mailto:gjshep@gmail.com]=20 Sent: Wednesday, September 14, 2011 8:28 AM To: Spencer Dawkins Cc: Tina TSOU; multrans@ietf.org Subject: Re: [multrans] Draft Multrans 2nd BoF request First Priority please: PIM, MBONED, Softwire Thanks, Greg On Wed, Sep 14, 2011 at 8:12 AM, Spencer Dawkins wrote: > (Speaking as individual) > > Just as a schedule check, the cutoff date for IETF 82 BOF requests is 10/= 03 > (according to http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF82). > The only response I've seen to this proposal was from Dan Wing, asking th= at > BEHAVE be added to the first-priority conflict list. > > Are there any other suggestions that people would like to make? If so, it > might be great to say something before the BOF request goes in. > > Thanks, > > Spencer (as individual) > >> Hi all, >> This is draft Multrans 2nd BoF request. Comments are welcome. >> >> --------------------------------------------------------- >> Working Group Name: Multrans BOF >> Area Name: Transport Area >> Session Requester: Tina Tsou >> >> Number of Sessions: 1 >> Length of Session(s): =A02 hours >> >> >> Number of Attendees: 100 >> Conflicts to Avoid: >> =A0First Priority: PIM, MBONED, RMT, V6OPS, SOFTWIRE >> =A0Second Priority: tsvarea intarea >> >> Special Requests: >> =A0N/A >> >> In current deployments, the IP multicast forwarding scheme is used by ma= ny >> providers to deliver some services, such as live TV broadcasting. >> Transition to IPv6 raises issues and corresponding requirements. In >> particular, IPv4 service continuity is an essential requirement from a >> business perspective. >> This specifically includes continued receiver access to IPv4-formatted >> contents even when the assignment of a dedicated global IPv4 address to = the >> receiver is no longer possible and even after the receivers have migrate= d to >> IPv6. >> Likewise, the delivery of IPv6-formatted contents to IPv4 receivers must >> also be possible. >> Multicast transition scenarios include the ability to access >> IPv4-formatted multicast contents from an IPv4 receiver over an IPv6-onl= y >> network and the ability to access IPv4-formatted multicast contents from= an >> IPv6-only receiver. >> The aforementioned issues can be classified into: >> . Multicast group and source discovery procedures >> . Multicast group subscription procedures >> . Multicast tree computation >> . Required IPv4-IPv6 multicast inter-working functions >> The proposed BoF session aims at discussing use cases and prioritizing >> list of issues, forming a new WG. >> The proposed agenda for the BoF session goes like this: >> . Welcome introduction and agenda bashing (chairs, 10 min) >> . Use cases (TBD, 30 min) >> . Prioritizing list of issues (TBD, 30 min) >> . Discussion (all, 30 min) >> . Conclusion and next steps (chairs, ADs, 20 min) >> Reading material: >> http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02 >> http://tools.ietf.org/html/draft-tsou-multrans-use-cases-00 >> --------------------------------------------------------- >> >> >> >> Best Regards, >> Tina TSOU >> http://tinatsou.weebly.com/contact.html >> >> >> >> _______________________________________________ >> multrans mailing list >> multrans@ietf.org >> https://www.ietf.org/mailman/listinfo/multrans > > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans > From gjshep@gmail.com Wed Sep 14 13:07:27 2011 Return-Path: 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 A21F221F8C60 for ; Wed, 14 Sep 2011 13:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 pybeG5qduAPv for ; Wed, 14 Sep 2011 13:07:26 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6334321F8C57 for ; Wed, 14 Sep 2011 13:07:26 -0700 (PDT) Received: by bkaq10 with SMTP id q10so2047149bka.31 for ; Wed, 14 Sep 2011 13:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=zzRdZL/2ZUrzzOtwSXxZDlfAogr3BC5tF17mJ8nsVk0=; b=jT8P3oeH1YMOdw4dL1zB2UMn+/ZXj6Fcgo04kiDKbiO4GRrEwy3d5KwLY2JoatLmwO xMzbu3tO3m2xlQWDDGVoD7J6bGmZRGwz1sMB3wOGGhdQEz6bSaPWU/Ih0HsSEgm253hU WLFTWhGRsbneis87a+cDAxZn492WYen1R4Rzw= MIME-Version: 1.0 Received: by 10.204.140.148 with SMTP id i20mr140757bku.96.1316030974320; Wed, 14 Sep 2011 13:09:34 -0700 (PDT) Received: by 10.204.51.132 with HTTP; Wed, 14 Sep 2011 13:09:34 -0700 (PDT) In-Reply-To: References: <84062BDB236B4F2EB392E782A1AC4DD8@china.huawei.com> Date: Wed, 14 Sep 2011 13:09:34 -0700 Message-ID: From: Greg Shepherd To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multrans@ietf.org" Subject: Re: [multrans] Draft Multrans 2nd BoF request X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 20:07:27 -0000 No, I just wanted to be sure my conflicts were on the list too. Thanks!, Greg On Wed, Sep 14, 2011 at 1:01 PM, Tina TSOU w= rote: > Greg, > See >>> Conflicts to Avoid: >>> =A0First Priority: PIM, MBONED, RMT, V6OPS, SOFTWIRE, BEHAVE > Do you mean delete RMT and V6OPS from the list? Or is it just fine as abo= ve? > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > -----Original Message----- > From: Greg Shepherd [mailto:gjshep@gmail.com] > Sent: Wednesday, September 14, 2011 8:28 AM > To: Spencer Dawkins > Cc: Tina TSOU; multrans@ietf.org > Subject: Re: [multrans] Draft Multrans 2nd BoF request > > First Priority please: PIM, MBONED, Softwire > > Thanks, > Greg > > On Wed, Sep 14, 2011 at 8:12 AM, Spencer Dawkins > wrote: >> (Speaking as individual) >> >> Just as a schedule check, the cutoff date for IETF 82 BOF requests is 10= /03 >> (according to http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF82)= . >> The only response I've seen to this proposal was from Dan Wing, asking t= hat >> BEHAVE be added to the first-priority conflict list. >> >> Are there any other suggestions that people would like to make? If so, i= t >> might be great to say something before the BOF request goes in. >> >> Thanks, >> >> Spencer (as individual) >> >>> Hi all, >>> This is draft Multrans 2nd BoF request. Comments are welcome. >>> >>> --------------------------------------------------------- >>> Working Group Name: Multrans BOF >>> Area Name: Transport Area >>> Session Requester: Tina Tsou >>> >>> Number of Sessions: 1 >>> Length of Session(s): =A02 hours >>> >>> >>> Number of Attendees: 100 >>> Conflicts to Avoid: >>> =A0First Priority: PIM, MBONED, RMT, V6OPS, SOFTWIRE >>> =A0Second Priority: tsvarea intarea >>> >>> Special Requests: >>> =A0N/A >>> >>> In current deployments, the IP multicast forwarding scheme is used by m= any >>> providers to deliver some services, such as live TV broadcasting. >>> Transition to IPv6 raises issues and corresponding requirements. In >>> particular, IPv4 service continuity is an essential requirement from a >>> business perspective. >>> This specifically includes continued receiver access to IPv4-formatted >>> contents even when the assignment of a dedicated global IPv4 address to= the >>> receiver is no longer possible and even after the receivers have migrat= ed to >>> IPv6. >>> Likewise, the delivery of IPv6-formatted contents to IPv4 receivers mus= t >>> also be possible. >>> Multicast transition scenarios include the ability to access >>> IPv4-formatted multicast contents from an IPv4 receiver over an IPv6-on= ly >>> network and the ability to access IPv4-formatted multicast contents fro= m an >>> IPv6-only receiver. >>> The aforementioned issues can be classified into: >>> . Multicast group and source discovery procedures >>> . Multicast group subscription procedures >>> . Multicast tree computation >>> . Required IPv4-IPv6 multicast inter-working functions >>> The proposed BoF session aims at discussing use cases and prioritizing >>> list of issues, forming a new WG. >>> The proposed agenda for the BoF session goes like this: >>> . Welcome introduction and agenda bashing (chairs, 10 min) >>> . Use cases (TBD, 30 min) >>> . Prioritizing list of issues (TBD, 30 min) >>> . Discussion (all, 30 min) >>> . Conclusion and next steps (chairs, ADs, 20 min) >>> Reading material: >>> http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02 >>> http://tools.ietf.org/html/draft-tsou-multrans-use-cases-00 >>> --------------------------------------------------------- >>> >>> >>> >>> Best Regards, >>> Tina TSOU >>> http://tinatsou.weebly.com/contact.html >>> >>> >>> >>> _______________________________________________ >>> multrans mailing list >>> multrans@ietf.org >>> https://www.ietf.org/mailman/listinfo/multrans >> >> _______________________________________________ >> multrans mailing list >> multrans@ietf.org >> https://www.ietf.org/mailman/listinfo/multrans >> > From Tina.Tsou.Zouting@huawei.com Thu Sep 15 00:27:05 2011 Return-Path: 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 80E8121F84DC for ; Thu, 15 Sep 2011 00:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.962 X-Spam-Level: X-Spam-Status: No, score=-5.962 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] 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 qKWEOQJwk9dJ for ; Thu, 15 Sep 2011 00:27:01 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 03AB021F84D2 for ; Thu, 15 Sep 2011 00:27:00 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ00ARVZGHSW@szxga05-in.huawei.com> for multrans@ietf.org; Thu, 15 Sep 2011 15:29:06 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ004PMZDUFG@szxga05-in.huawei.com> for multrans@ietf.org; Thu, 15 Sep 2011 15:29:05 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADZ33544; Thu, 15 Sep 2011 15:28:48 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 15 Sep 2011 15:27:16 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.247]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Thu, 15 Sep 2011 15:27:17 +0800 Date: Thu, 15 Sep 2011 07:27:16 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.212.245.15] To: Spencer Dawkins , "multrans@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_f1htAk4ibfQj3CFjKbWJPA)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [multrans] Fw: Draft Multrans BoF request Thread-index: AQHMcwoEa0HkRquzpEOclxyp6+BpUZVOAXAg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [multrans] Fw: Draft Multrans BoF request X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 07:27:05 -0000 --Boundary_(ID_f1htAk4ibfQj3CFjKbWJPA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Spencer et al, Thank you for your question. I'm taking the next step based on feedback received at the IETF 81 BoF. Here is the revised proposed charter. ---------------- The task of the MULTRANS Working Group is to devise the means whereby existing multicast mechanisms can operate successfully when signalling and content have to traverse one or more IPv4/IPv6 boundaries. Goals 1. The Working Group's first task is to develop a problem statement that identifies the scope of the problem of multicast operation during the transition from IPv4 to IPv6. The problem statement will identify: -- requirements that must be satisfied by the mechanisms for multicast transition; -- use cases that must be considered, ranked by priority; it targets IPTV ("the use case of greatest interest to the IETF 81 BoF participants"), with possible rechartering for other use cases later. -- design considerations that should be taken into account in subsequent work. 2. The Multrans Working Group will develop Standards Track documents specifying protocol interworking for the new combinations of protocols (for example, between PIM (IPv4) and PIM (IPv6)) required for multicast transition from IPv4 to IPv6. 3. The Multrans Working Group will specify the means whereby multicast addresses may be translated between IPv4 and IPv6, in both stateful and stateless fashion, in direct analogy to RFC 6052 for unicast addresses. 4. The Multrans Working Group will specify extensions to DHCPv4 and DHCPv6 required to configure hosts during the transitional period. 5. The Multrans Working Group will specify the operational and management capabilities required to support multicast transition. In particular, this work may involve the specification of MIBs. If the working group identifies any requirements for extensions to the multicast protocols themselves, the requirements would be sent to the working groups responsible for those protocols for consideration. Or have documents in multrans that extend multicast protocols, ask the corresponding working group for review. Milestones May 2012 WG adopts - problem statement draft - interworking drafts - DHCP new options drafts - MIB draft Sep 2012 Submit to IESG - problem statement draft - interworking drafts - DHCP new options drafts - MIB draft ------------------ Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Wednesday, September 14, 2011 11:12 AM To: multrans@ietf.org Subject: [multrans] Fw: Draft Multrans BoF request Me again, speaking as an individual again ... The goal in the draft BOF request is to form a working group. The most recent proposed charter I've seen on the mailing list is this one, from before the (excellent) BOF at IETF 81 (if I'm reading Tina's note correctly, this version was created before the informal meeting at IETF 80). Is a more recent version available? Thanks, Spencer, speaking as an individual ----- Original Message ----- From: Tina Tsou To: 'Jari Arkko' Cc: multrans@ietf.org Sent: Tuesday, June 14, 2011 2:03 AM Subject: Re: [multrans] Draft Multrans BoF request Jari, About the proposed charter, here is a copy from the presentation in IPv4-IPv6 multicast meetings in Prague in March. The task of this Working Group is to devise the means whereby existing multicast distribution mechanisms can work when signalling and content have to traverse one or more boundaries where IP version changes. The Working Group will consider three cases: -- provider distributed multicast (including IPTV); -- multicast networks connected directly to a multicast backbone network; -- multicast networks separated from the backbone network by unicast . The Working Group's first task is to create a Problem Statement. This documents will specify the requirements that must be satisfied by multicast transition solutions for the three cases listed above. It will describe the scenarios that need to be considered and the challenges posed by those scenarios in thos e three em Statement will specify the new functional capabilities required to enable the solution of the multicast transition problem in the different scenarios. The Working Group will follow up with one or more framework documents analyzing the potential multicast transition solutions for specific scenarios or groups of scenarios. The circumstances under which the different solution approaches are applicable will be described, taking account of the unicast transition mechanisms that may be deployed in a given network . The fr lude a view of the evolution path for multicast transition over time, possibly though not necessarily as a function of the associated unicast transition path. The final outcome of framework drafts should be recommendations for preferred solution approaches. Finally, the Working Group will produce a small set of solution drafts for the cases considered to be of the highest priority before re-chartering or disbandment. Specifically, the Working Group will provide one or two solutions for the provider distrib uted mul icast source and receiver are IPv4 and there is an intervening IPv6 network. The solution(s) must be compatible with the unicast translation (NAT64) and tunneling (DS Lite, Gateway-Initiated DS lite) transition mechanisms. The solution(s) must discuss the considerations specifically relevant to these three unicast transition mechanisms to the extent this di scussion covered by the framework document. The Working Group will also provide a solution for the case of multicast networks connected directly to a multicast backbone network. Relations: Behave, Softwires, PIM, Mboned, V6ops Deliverables: Problem Statement (Informational) Framework for the provider distributed multicast case (Informational) Framework for the case of multicast networks connected directly to a multicast backbone network (Informational) Solutions (2-3) (Proposed Standard) We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Monday, June 13, 2011 11:09 AM To: Tina Tsou Cc: Lee, Yiu; 'Tom Taylor'; mohamed.boucadair@orange-ftgroup.com; multrans@ietf.org Subject: Re: [multrans] Draft Multrans BoF request Tina, others, I'm trying to construct a wiki entry for this BOF so that the IESG and IAB have all the information available to them to make decisions on what BOFs to approve on Thursday. What other drafts than the ps I should list? Is there a pointer to a mailing list post or some web site for the proposed charter? Also, for my background: are there providers who are asking for multicast transition solutions? I.e., not just deploying multicast separately for the two IP versions? Here's what we have so far: MULTRANS - Multicast Transition Description Jari ________________________________ _______________________________________________ multrans mailing list multrans@ietf.org https://www.ietf.org/mailman/listinfo/multrans --Boundary_(ID_f1htAk4ibfQj3CFjKbWJPA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Spencer et al,

Thank you for your question.

I’m taking the next step based on feedback received at the IETF 81 BoF. Here is the revised proposed charter.

----------------

The task of the MULTRANS Working Group is to devise the means whereby existing multicast

mechanisms can operate successfully when signalling and content have to traverse one or more IPv4/IPv6 boundaries.

 

Goals

 

1. The Working Group's first task is to develop a problem statement that identifies the scope of the problem of multicast operation during the transition from IPv4 to IPv6. The problem

statement will identify:

     -- requirements that must be satisfied by the mechanisms

        for multicast transition;

     -- use cases that must be considered, ranked by priority; it targets IPTV ("the use case of greatest interest to the IETF 81 BoF participants"), with possible rechartering for other use cases later.

     -- design considerations that should be taken into account in subsequent work.

 

2. The Multrans Working Group will develop Standards Track documents specifying protocol

interworking for the new combinations of protocols (for example, between PIM (IPv4) and PIM (IPv6)) required for multicast transition from IPv4 to IPv6.

 

3. The Multrans Working Group will specify the means whereby multicast addresses may be

translated between IPv4 and IPv6, in both stateful and stateless fashion, in direct analogy to

RFC 6052 for unicast addresses.

 

4. The Multrans Working Group will specify extensions to DHCPv4 and DHCPv6 required to configure hosts during the transitional period.

 

5. The Multrans Working Group will specify the operational and management capabilities required to support multicast transition. In particular, this work may involve the specification of MIBs.

 

If the working group identifies any requirements for extensions to the multicast protocols themselves, the requirements would be sent to the working groups responsible for those protocols for consideration. Or have documents in multrans that extend multicast protocols, ask the corresponding working group for review.

 

Milestones

 

May 2012  WG adopts

– problem statement draft

– interworking drafts

– DHCP new options drafts

– MIB draft

 

Sep 2012 Submit to IESG

– problem statement draft

– interworking drafts

– DHCP new options drafts

– MIB draft

------------------

 

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

 

 

From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] On Behalf Of Spencer Dawkins
Sent: Wednesday, September 14, 2011 11:12 AM
To: multrans@ietf.org
Subject: [multrans] Fw: Draft Multrans BoF request

 

Me again, speaking as an individual again ...

 

The goal in the draft BOF request is to form a working group. The most recent proposed charter I've seen on the mailing list is this one, from before the (excellent) BOF at IETF 81 (if I'm reading Tina's note correctly, this version was created before the informal meeting at IETF 80).

 

Is a more recent version available?

 

Thanks,

 

Spencer, speaking as an individual

 

----- Original Message -----

From: Tina Tsou

Sent: Tuesday, June 14, 2011 2:03 AM

Subject: Re: [multrans] Draft Multrans BoF request

 

Jari,

About the proposed charter, here is a copy from the presentation in IPv4-IPv6 multicast meetings in Prague in March.

 

The task of this Working Group is to devise the means whereby existing

multicast distribution mechanisms can work when signalling and content have

to traverse one or more boundaries where IP version changes.

 

The Working Group will consider three cases:

-- provider distributed multicast (including IPTV);

-- multicast networks connected directly to a multicast backbone network;

-- multicast networks separated from the backbone network by unicast

.

 

The Working Group's first task is to create a Problem Statement. This

documents will specify the requirements that must be satisfied by multicast

transition solutions for the three cases listed above. It will describe the

scenarios that need to be considered and the challenges posed by those

scenarios in thos e three em Statement will specify

the new functional capabilities required to enable the solution of the

multicast transition problem in the different scenarios.

 

The Working Group will follow up with one or more framework documents

analyzing the potential multicast transition solutions for specific

scenarios or groups of scenarios. The circumstances under which the

different solution approaches are applicable will be described, taking

account of the unicast transition mechanisms that may be deployed in a

given network . The fr lude a view of the evolution

path for multicast transition over time, possibly though not necessarily as

a function of the associated unicast transition path. The final outcome of

framework drafts should be recommendations for preferred solution

approaches.

 

Finally, the Working Group will produce a small set of solution drafts for

the cases considered to be of the highest priority before re-chartering or

disbandment. Specifically, the Working Group will provide one or two

solutions for the provider distrib uted mul icast

source and receiver are IPv4 and there is an intervening IPv6 network. The

solution(s) must be compatible with the unicast translation (NAT64) and

tunneling (DS Lite, Gateway-Initiated DS lite) transition mechanisms. The

solution(s) must discuss the considerations specifically relevant to these

three unicast transition mechanisms to the extent this di scussion

covered by the framework document. The Working Group will also provide a

solution for the case of multicast networks connected directly to a

multicast backbone network.

 

Relations: Behave, Softwires, PIM, Mboned, V6ops

 

Deliverables:

Problem Statement (Informational) Framework for the provider distributed multicast case (Informational)

Framework for the case of multicast networks connected directly to a

multicast backbone network (Informational)

Solutions (2-3) (Proposed Standard)

 

We keep our promises with one another – no matter what!

 

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

 

From: Jari Arkko [mailto:jari.arkko@piuha.net]
Sent: Monday, June 13, 2011 11:09 AM
To: Tina Tsou
Cc: Lee, Yiu; 'Tom Taylor'; mohamed.boucadair@orange-ftgroup.com; multrans@ietf.org
Subject: Re: [multrans] Draft Multrans BoF request

Tina, others,

I'm trying to construct a wiki entry for this BOF so that the IESG and IAB have all the information available to them to make decisions on what BOFs to approve on Thursday. What other drafts than the ps I should list? Is there a pointer to a mailing list post or some web site for the proposed charter? Also, for my background: are there providers who are asking for multicast transition solutions? I.e., not just deploying multicast separately for the two IP versions?

Here's what we have so far:


MULTRANS - Multicast Transition

Description
Jari

_______________________________________________
multrans mailing list
multrans@ietf.org
https://www.ietf.org/mailman/listinfo/multrans

--Boundary_(ID_f1htAk4ibfQj3CFjKbWJPA)-- From Tina.Tsou.Zouting@huawei.com Thu Sep 15 00:34:27 2011 Return-Path: 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 1FB3B21F8508 for ; Thu, 15 Sep 2011 00:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.963 X-Spam-Level: X-Spam-Status: No, score=-5.963 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] 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 0MyGSfUwcio4 for ; Thu, 15 Sep 2011 00:34:26 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id CE39C21F84E1 for ; Thu, 15 Sep 2011 00:34:25 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ00I29ZR3AL@szxga05-in.huawei.com> for multrans@ietf.org; Thu, 15 Sep 2011 15:35:28 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ004IBZPLFG@szxga05-in.huawei.com> for multrans@ietf.org; Thu, 15 Sep 2011 15:35:27 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADZ34415; Thu, 15 Sep 2011 15:35:26 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 15 Sep 2011 15:35:16 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.247]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Thu, 15 Sep 2011 15:35:24 +0800 Date: Thu, 15 Sep 2011 07:35:23 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.212.245.15] To: "gjshep@gmail.com" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [multrans] Draft Multrans 2nd BoF request Thread-index: AQHMcvDKxsRgOL56m0O6YMBJRshTH5VMedEAgAC9wGD//5DiAIABQ4kQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <84062BDB236B4F2EB392E782A1AC4DD8@china.huawei.com> Cc: "multrans@ietf.org" Subject: Re: [multrans] Draft Multrans 2nd BoF request X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 07:34:27 -0000 Hi Greg, Spencer et al, This is the revised draft BoF request. I'm sending it to the TSV ADs becaus= e I believe the sense of the room at IETF 81 was that the use case of inter= est is IPTV, and my understanding is that the interworking specifications w= ould appropriately be done in TSV (same as BEHAVE in TSV for unicast). --- Working Group Name: Multrans BOF Area Name: Transport Area Session Requester: Tina Tsou Number of Sessions: 1 Length of Session(s): 2 hours Number of Attendees: 100 Conflicts to Avoid: First Priority: PIM, MBONED, RMT, V6OPS, SOFTWIRE, BEHAVE =20 Second Priority: tsvarea intarea Special Requests: N/A In current deployments, the IP multicast forwarding scheme is used by many = providers to deliver some services, such as live TV broadcasting. Transition to IPv6 raises issues and corresponding requirements. In particu= lar, IPv4 service continuity is an essential requirement from a business pe= rspective. This specifically includes continued receiver access to IPv4-formatted cont= ents even when the assignment of a dedicated global IPv4 address to the rec= eiver is no longer possible and even after the receivers have migrated to I= Pv6. Likewise, the delivery of IPv6-formatted contents to IPv4 receivers must al= so be possible. Multicast transition scenarios include the ability to access IPv4-formatted= multicast contents from an IPv4 receiver over an IPv6-only network and the= ability to access IPv4-formatted multicast contents from an IPv6-only rece= iver. The aforementioned issues can be classified into: . Multicast group and source discovery procedures=20 . Multicast group subscription procedures=20 . Multicast tree computation=20 . Required IPv4-IPv6 multicast inter-working functions=20 The proposed BoF session aims at discussing use cases and prioritizing list= of issues, forming a new WG. The proposed agenda for the BoF session goes like this: . Welcome introduction and agenda bashing (chairs, 10 min)=20 . Use cases (TBD, 30 min)=20 . Prioritizing list of issues (TBD, 30 min)=20 . Bashing the proposed charter (all, 30 min)=20 . Conclusion and next steps (chairs, ADs, 20 min)=20 Reading material: http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02 http://tools.ietf.org/html/draft-tsou-multrans-use-cases-00 --- Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Greg Shepherd [mailto:gjshep@gmail.com]=20 Sent: Wednesday, September 14, 2011 1:10 PM To: Tina TSOU Cc: Spencer Dawkins; multrans@ietf.org Subject: Re: [multrans] Draft Multrans 2nd BoF request No, I just wanted to be sure my conflicts were on the list too. Thanks!, Greg On Wed, Sep 14, 2011 at 1:01 PM, Tina TSOU w= rote: > Greg, > See >>> Conflicts to Avoid: >>> =A0First Priority: PIM, MBONED, RMT, V6OPS, SOFTWIRE, BEHAVE > Do you mean delete RMT and V6OPS from the list? Or is it just fine as abo= ve? > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > -----Original Message----- > From: Greg Shepherd [mailto:gjshep@gmail.com] > Sent: Wednesday, September 14, 2011 8:28 AM > To: Spencer Dawkins > Cc: Tina TSOU; multrans@ietf.org > Subject: Re: [multrans] Draft Multrans 2nd BoF request > > First Priority please: PIM, MBONED, Softwire > > Thanks, > Greg > > On Wed, Sep 14, 2011 at 8:12 AM, Spencer Dawkins > wrote: >> (Speaking as individual) >> >> Just as a schedule check, the cutoff date for IETF 82 BOF requests is 10= /03 >> (according to http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF82)= . >> The only response I've seen to this proposal was from Dan Wing, asking t= hat >> BEHAVE be added to the first-priority conflict list. >> >> Are there any other suggestions that people would like to make? If so, i= t >> might be great to say something before the BOF request goes in. >> >> Thanks, >> >> Spencer (as individual) >> >>> Hi all, >>> This is draft Multrans 2nd BoF request. Comments are welcome. >>> >>> --------------------------------------------------------- >>> Working Group Name: Multrans BOF >>> Area Name: Transport Area >>> Session Requester: Tina Tsou >>> >>> Number of Sessions: 1 >>> Length of Session(s): =A02 hours >>> >>> >>> Number of Attendees: 100 >>> Conflicts to Avoid: >>> =A0First Priority: PIM, MBONED, RMT, V6OPS, SOFTWIRE >>> =A0Second Priority: tsvarea intarea >>> >>> Special Requests: >>> =A0N/A >>> >>> In current deployments, the IP multicast forwarding scheme is used by m= any >>> providers to deliver some services, such as live TV broadcasting. >>> Transition to IPv6 raises issues and corresponding requirements. In >>> particular, IPv4 service continuity is an essential requirement from a >>> business perspective. >>> This specifically includes continued receiver access to IPv4-formatted >>> contents even when the assignment of a dedicated global IPv4 address to= the >>> receiver is no longer possible and even after the receivers have migrat= ed to >>> IPv6. >>> Likewise, the delivery of IPv6-formatted contents to IPv4 receivers mus= t >>> also be possible. >>> Multicast transition scenarios include the ability to access >>> IPv4-formatted multicast contents from an IPv4 receiver over an IPv6-on= ly >>> network and the ability to access IPv4-formatted multicast contents fro= m an >>> IPv6-only receiver. >>> The aforementioned issues can be classified into: >>> . Multicast group and source discovery procedures >>> . Multicast group subscription procedures >>> . Multicast tree computation >>> . Required IPv4-IPv6 multicast inter-working functions >>> The proposed BoF session aims at discussing use cases and prioritizing >>> list of issues, forming a new WG. >>> The proposed agenda for the BoF session goes like this: >>> . Welcome introduction and agenda bashing (chairs, 10 min) >>> . Use cases (TBD, 30 min) >>> . Prioritizing list of issues (TBD, 30 min) >>> . Discussion (all, 30 min) >>> . Conclusion and next steps (chairs, ADs, 20 min) >>> Reading material: >>> http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02 >>> http://tools.ietf.org/html/draft-tsou-multrans-use-cases-00 >>> --------------------------------------------------------- >>> >>> >>> >>> Best Regards, >>> Tina TSOU >>> http://tinatsou.weebly.com/contact.html >>> >>> >>> >>> _______________________________________________ >>> multrans mailing list >>> multrans@ietf.org >>> https://www.ietf.org/mailman/listinfo/multrans >> >> _______________________________________________ >> multrans mailing list >> multrans@ietf.org >> https://www.ietf.org/mailman/listinfo/multrans >> > From cancanhuang110@gmail.com Fri Sep 16 02:12:39 2011 Return-Path: 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 1E4ED21F8AFD for ; Fri, 16 Sep 2011 02:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 8uUMjKuunb4X for ; Fri, 16 Sep 2011 02:12:38 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C80F21F8A7B for ; Fri, 16 Sep 2011 02:12:37 -0700 (PDT) Received: by fxd18 with SMTP id 18so1613011fxd.31 for ; Fri, 16 Sep 2011 02:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=oztWJI/pQblej44cu042aUG8Ya/BK6lBsrgwjaTf5U0=; b=S0jCKSA+OQfcU63OCtaIcPXYbvGDPgFgj2ziuW0VMNArqtHGUCQbE6c24PWFsxAceo iTIr+okRFUYr5c2vB9tKpRoiGZH+VLYt7BE5drg2jeFz9gEw5AL8s7JJ5LqPDIe6eRvL qE5GZUqmLNuInvKJ2Jp8vL0HAk2BLiWjMYSXg= MIME-Version: 1.0 Received: by 10.223.46.89 with SMTP id i25mr2498569faf.34.1316164491292; Fri, 16 Sep 2011 02:14:51 -0700 (PDT) Received: by 10.223.86.202 with HTTP; Fri, 16 Sep 2011 02:14:51 -0700 (PDT) Date: Fri, 16 Sep 2011 17:14:51 +0800 Message-ID: From: huang cancan To: multrans@ietf.org Content-Type: multipart/alternative; boundary=00151747b722f82f3104ad0b6c99 Subject: [multrans] about the charter of Multrans X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 09:12:39 -0000 --00151747b722f82f3104ad0b6c99 Content-Type: text/plain; charset=ISO-8859-1 hi all: We are ready to include solutions work in the charter. cancanhuang China Telecom --00151747b722f82f3104ad0b6c99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi all:
=A0
We are ready to include solutions work in the charter.
=A0
cancanhuang
=A0
China Telecom
--00151747b722f82f3104ad0b6c99-- From Tina.Tsou.Zouting@huawei.com Wed Sep 21 16:11:58 2011 Return-Path: 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 55D9321F8BDE for ; Wed, 21 Sep 2011 16:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.344 X-Spam-Level: X-Spam-Status: No, score=-0.344 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 QaSFyIJ1ed28 for ; Wed, 21 Sep 2011 16:11:55 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEF521F8BDC for ; Wed, 21 Sep 2011 16:11:54 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRW00IXSB7YAJ@szxga03-in.huawei.com> for multrans@ietf.org; Thu, 22 Sep 2011 07:14:22 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRW00HNJB7YIC@szxga03-in.huawei.com> for multrans@ietf.org; Thu, 22 Sep 2011 07:14:22 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADU98507; Thu, 22 Sep 2011 07:14:22 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 22 Sep 2011 07:14:15 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.147]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 07:14:17 +0800 Date: Wed, 21 Sep 2011 23:14:16 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.212.244.33] To: huang cancan , "multrans@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_H+8swxk7P5eidvm8zWEUzg)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: about the charter of Multrans Thread-index: AQHMdFEddF8wA4uac0q/JDuLg2NoZZVYfQvQ X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [multrans] about the charter of Multrans X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 23:11:58 -0000 --Boundary_(ID_H+8swxk7P5eidvm8zWEUzg) Content-type: multipart/alternative; boundary="Boundary_(ID_vTaTJRGHUThyRCP8Kp5BNw)" --Boundary_(ID_vTaTJRGHUThyRCP8Kp5BNw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thank you, Cancan. Here is updated version, scoped down to a single use-case for which there is commercial interest (i.e., IPTV). Proposed MULTRANS Charter The task of the MULTRANS Working Group is to devise the means whereby existing multicast mechanisms can operate successfully when signalling and content have to traverse one or more IPv4/IPv6 boundaries. The scope of the Working Group is initially limited to the IPTV case, since the requirements for this application are better understood than those for other potential multicast applications. Goals 1. The Working Group's first task is to develop a problem statement that identifies the scope of the problem of multicast operation for the IPTV application during the transition from IPv4 to IPv6. The problem statement will identify: -- requirements that must be satisfied by the mechanisms for multicast transition; -- use cases that must be considered, ranked by priority; -- design considerations that should be taken into account in subsequent work. 2. The Multrans Working Group will develop Standards Track documents specifying protocol interworking for the new combinations of protocols (for example, between PIM (IPv4) and PIM (IPv6)) required for multicast transition from IPv4 to IPv6. 3. The Multrans Working Group will specify the means whereby multicast addresses may be translated between IPv4 and IPv6, in both stateful and stateless fashion, in direct analogy to RFC 6052 for unicast addresses. 4. The Multrans Working Group will specify extensions to DHCPv4, DHCPv6, and RADIUS attributes required to configure hosts during the transitional period. 5. The Multrans Working Group will specify the operational and management capabilities required to support multicast transition. In particular, this work may involve the specification of MIBs. Relationship to other working groups: - Work done in the Softwire working group on the use of encapsulation as a multicast transition mechanism will be coordinated with the more general work being done by the MULTRANS working group. - The specification for translation between IPv4 and IPv6 multicast addresses will be reviewed jointly with the MBONED working group, as will recommendations relating to operation and management of multicast transition. - DHCP options, RADIUS attributes, and MIB modules developed by MULTRANS will be jointly reviewed with the appropriate other parties (DHC and RADEXT working groups, MIB Doctors directorate). - The interworking recommendations for PIM, IGMP, and MLD developed in this group will be reviewed jointly with PIM, MBONED. Milestones May 2012 WG adopts - problem statement draft - interworking drafts - address translation draft - drafts related to operations and management of multicast transition Sep 2012 Submit to IESG - problem statement draft - interworking drafts - address translation draft - drafts related to operations and management of multicast transition Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: huang cancan [mailto:cancanhuang110@gmail.com] Sent: Friday, September 16, 2011 2:15 AM To: multrans@ietf.org Cc: Tina TSOU Subject: about the charter of Multrans hi all: We are ready to include solutions work in the charter. cancanhuang China Telecom --Boundary_(ID_vTaTJRGHUThyRCP8Kp5BNw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Thank you, Cancan.

Here is updated version, scoped down to a single us= e-case for which there is commercial interest (i.e., IPTV).

 

Proposed MULTRANS Charter

 

The task of the MULTRANS Working Group is to devise= the means whereby existing multicast mechanisms can operate successfully when signalling and content have to traverse= one or more IPv4/IPv6 boundaries. The scope of the Working Group is initia= lly limited to the IPTV case, since the requirements for this application a= re better understood than those for other potential multicast applications.

 

Goals

 

1. The Working Group's first task is to develop a p= roblem statement that identifies the scope of the problem of multicast operation for the IPTV application during the transition from IPv4 to IPv6= . The problem statement will identify:

   =    -- requirements that must be satisfied = by the mechanisms

   =       for multicast transition;

   =    -- use cases that must be considered, r= anked by priority;

   =    -- design considerations that should be taken = into account in subsequent work.

 

2. The Multrans Working Group will develop Standards= Track documents specifying protocol interworking for the new combinations = of protocols (for example, between PIM (IPv4) and PIM (IPv6)) required for = multicast transition from IPv4 to IPv6.

 

3. The Multrans Working Group will specify the means= whereby multicast addresses may be translated between IPv4 and IPv6, in bo= th stateful and stateless fashion, in direct ana= logy to RFC 6052 for unicast addresses.

 

4. The Multrans Working Group will specify extension= s to DHCPv4, DHCPv6, and RADIUS attributes required to configure hosts duri= ng the transitional period.

 

5. The Multrans Working Group will specify the opera= tional and management capabilities required to support multicast transition= . In particular, this work may involve the specification of MIBs.

 

Relationship to other working groups:

 

- Work done in the Softwire working group on the us= e of encapsulation as a multicast transition mechanism will be coordinated with the more general work being done by the MULTRANS working group.<= /o:p>

 

- The specification for translation between IPv4 an= d IPv6 multicast addresses will be reviewed jointly with the MBONED working group, as will recommendations relating to operation and managemen= t of multicast transition.

 

- DHCP options, RADIUS attributes, and MIB modules = developed by MULTRANS will be jointly reviewed with the appropriate other parties (DHC and RADEXT working groups, MIB Doctors directorate).

 

- The interworking recommendations for PIM, IGMP, a= nd MLD developed in this group will be reviewed jointly with PIM, MBONED.

 

 

Milestones

 

May 2012  WG= adopts

– problem statement draft

– interworking drafts

-  address translation draft

-  drafts<= /span> related to operations and management of multicast transition

 

Sep 2012 Submit to IESG

– problem statement draft

– interworking drafts

-  address translation draft

-  drafts<= /span> related to operations and management of multicast transition

 

 

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact= .html

 

From: huang cancan [mailto:cancanhuang110@gmail.com]
Sent: Friday, September 16, 2011 2:15 AM
To: multrans@ietf.org
Cc: Tina TSOU
Subject: about the charter of Multrans

 

hi all:

 

We are ready to include solutions work in the charte= r.

 

cancanhuang

 

China Telecom

--Boundary_(ID_vTaTJRGHUThyRCP8Kp5BNw)-- --Boundary_(ID_H+8swxk7P5eidvm8zWEUzg) Content-type: text/plain; name="Proposed Multrans Charter-110921-01.txt" Content-transfer-encoding: base64 Content-disposition: attachment; filename="Proposed Multrans Charter-110921-01.txt"; size=2893; creation-date="Wed, 21 Sep 2011 21:15:15 GMT"; modification-date="Wed, 21 Sep 2011 23:11:39 GMT" Content-description: Proposed Multrans Charter-110921-01.txt UHJvcG9zZWQgTVVMVFJBTlMgQ2hhcnRlcg0KDQpUaGUgdGFzayBvZiB0aGUgTVVMVFJBTlMgV29y a2luZyBHcm91cCBpcyB0byBkZXZpc2UgdGhlIG1lYW5zIHdoZXJlYnkgZXhpc3RpbmcgbXVsdGlj YXN0IG1lY2hhbmlzbXMgY2FuIG9wZXJhdGUgc3VjY2Vzc2Z1bGx5ICB3aGVuIHNpZ25hbGxpbmcg YW5kIGNvbnRlbnQgaGF2ZSB0byB0cmF2ZXJzZSBvbmUgb3IgbW9yZSBJUHY0L0lQdjYgYm91bmRh cmllcy4gVGhlIHNjb3BlIG9mIHRoZSBXb3JraW5nIEdyb3VwIGlzIGluaXRpYWxseSBsaW1pdGVk IHRvIHRoZSBJUFRWIGNhc2UsIHNpbmNlIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoaXMgYXBwbGlj YXRpb24gYXJlIGJldHRlciB1bmRlcnN0b29kIHRoYW4gdGhvc2UgZm9yIG90aGVyIHBvdGVudGlh bCBtdWx0aWNhc3QgYXBwbGljYXRpb25zLg0KDQpHb2Fscw0KDQoxLiBUaGUgV29ya2luZyBHcm91 cCdzIGZpcnN0IHRhc2sgaXMgdG8gZGV2ZWxvcCBhIHByb2JsZW0gc3RhdGVtZW50IHRoYXQgaWRl bnRpZmllcyB0aGUgc2NvcGUgb2YgdGhlIHByb2JsZW0gb2YgbXVsdGljYXN0IG9wZXJhdGlvbiBm b3IgdGhlIElQVFYgYXBwbGljYXRpb24gZHVyaW5nIHRoZSB0cmFuc2l0aW9uIGZyb20gSVB2NCB0 byBJUHY2LiBUaGUgcHJvYmxlbSBzdGF0ZW1lbnQgd2lsbCBpZGVudGlmeToNCiAgICAgIC0tIHJl cXVpcmVtZW50cyB0aGF0IG11c3QgYmUgc2F0aXNmaWVkIGJ5IHRoZSBtZWNoYW5pc21zDQogICAg ICAgICBmb3IgbXVsdGljYXN0IHRyYW5zaXRpb247DQogICAgICAtLSB1c2UgY2FzZXMgdGhhdCBt dXN0IGJlIGNvbnNpZGVyZWQsIHJhbmtlZCBieSBwcmlvcml0eTsNCiAgICAgIC0tIGRlc2lnbiBj b25zaWRlcmF0aW9ucyB0aGF0IHNob3VsZCBiZSB0YWtlbiBpbnRvIGFjY291bnQgaW4gc3Vic2Vx dWVudCB3b3JrLg0KDQoyLiBUaGUgTXVsdHJhbnMgV29ya2luZyBHcm91cCB3aWxsIGRldmVsb3Ag U3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50cyBzcGVjaWZ5aW5nIHByb3RvY29sIGludGVyd29ya2lu ZyBmb3IgdGhlIG5ldyBjb21iaW5hdGlvbnMgb2YgcHJvdG9jb2xzIChmb3IgZXhhbXBsZSwgYmV0 d2VlbiBQSU0gKElQdjQpIGFuZCBQSU0gKElQdjYpKSByZXF1aXJlZCBmb3IgbXVsdGljYXN0IHRy YW5zaXRpb24gZnJvbSBJUHY0IHRvIElQdjYuDQoNCjMuIFRoZSBNdWx0cmFucyBXb3JraW5nIEdy b3VwIHdpbGwgc3BlY2lmeSB0aGUgbWVhbnMgd2hlcmVieSBtdWx0aWNhc3QgYWRkcmVzc2VzIG1h eSBiZSB0cmFuc2xhdGVkIGJldHdlZW4gSVB2NCBhbmQgSVB2NiwgaW4gYm90aCBzdGF0ZWZ1bCBh bmQgc3RhdGVsZXNzIGZhc2hpb24sIGluIGRpcmVjdCBhbmFsb2d5IHRvIFJGQyA2MDUyIGZvciB1 bmljYXN0IGFkZHJlc3Nlcy4NCg0KNC4gVGhlIE11bHRyYW5zIFdvcmtpbmcgR3JvdXAgd2lsbCBz cGVjaWZ5IGV4dGVuc2lvbnMgdG8gREhDUHY0LCBESENQdjYsIGFuZCBSQURJVVMgYXR0cmlidXRl cyByZXF1aXJlZCB0byBjb25maWd1cmUgaG9zdHMgZHVyaW5nIHRoZSB0cmFuc2l0aW9uYWwgcGVy aW9kLg0KDQo1LiBUaGUgTXVsdHJhbnMgV29ya2luZyBHcm91cCB3aWxsIHNwZWNpZnkgdGhlIG9w ZXJhdGlvbmFsIGFuZCBtYW5hZ2VtZW50IGNhcGFiaWxpdGllcyByZXF1aXJlZCB0byBzdXBwb3J0 IG11bHRpY2FzdCB0cmFuc2l0aW9uLiBJbiBwYXJ0aWN1bGFyLCB0aGlzIHdvcmsgbWF5IGludm9s dmUgdGhlIHNwZWNpZmljYXRpb24gb2YgTUlCcy4NCg0KUmVsYXRpb25zaGlwIHRvIG90aGVyIHdv cmtpbmcgZ3JvdXBzOg0KDQotIFdvcmsgZG9uZSBpbiB0aGUgU29mdHdpcmUgd29ya2luZyBncm91 cCBvbiB0aGUgdXNlIG9mIGVuY2Fwc3VsYXRpb24gYXMgYSBtdWx0aWNhc3QgdHJhbnNpdGlvbiBt ZWNoYW5pc20gd2lsbCBiZSBjb29yZGluYXRlZCB3aXRoIHRoZSBtb3JlIGdlbmVyYWwgd29yayBi ZWluZyBkb25lIGJ5IHRoZSBNVUxUUkFOUyB3b3JraW5nIGdyb3VwLg0KDQotIFRoZSBzcGVjaWZp Y2F0aW9uIGZvciB0cmFuc2xhdGlvbiBiZXR3ZWVuIElQdjQgYW5kIElQdjYgbXVsdGljYXN0IGFk ZHJlc3NlcyB3aWxsIGJlIHJldmlld2VkIGpvaW50bHkgd2l0aCB0aGUgTUJPTkVEIHdvcmtpbmcg Z3JvdXAsIGFzIHdpbGwgcmVjb21tZW5kYXRpb25zIHJlbGF0aW5nIHRvIG9wZXJhdGlvbiBhbmQg bWFuYWdlbWVudCBvZiBtdWx0aWNhc3QgdHJhbnNpdGlvbi4NCg0KLSBESENQIG9wdGlvbnMsIFJB RElVUyBhdHRyaWJ1dGVzLCBhbmQgTUlCIG1vZHVsZXMgZGV2ZWxvcGVkIGJ5IE1VTFRSQU5TIHdp bGwgYmUgam9pbnRseSByZXZpZXdlZCB3aXRoIHRoZSBhcHByb3ByaWF0ZSBvdGhlciBwYXJ0aWVz IChESEMgYW5kIFJBREVYVCB3b3JraW5nIGdyb3VwcywgTUlCIERvY3RvcnMgZGlyZWN0b3JhdGUp Lg0KDQotIFRoZSBpbnRlcndvcmtpbmcgcmVjb21tZW5kYXRpb25zIGZvciBQSU0sIElHTVAsIGFu ZCBNTEQgZGV2ZWxvcGVkIGluIHRoaXMgZ3JvdXAgd2lsbCBiZSByZXZpZXdlZCBqb2ludGx5IHdp dGggUElNLCBNQk9ORUQuDQoNCg0KTWlsZXN0b25lcw0KDQpNYXkgMjAxMiAgV0cgYWRvcHRzDQqo QyBwcm9ibGVtIHN0YXRlbWVudCBkcmFmdA0KqEMgaW50ZXJ3b3JraW5nIGRyYWZ0cw0KLSBhZGRy ZXNzIHRyYW5zbGF0aW9uIGRyYWZ0DQotIGRyYWZ0cyByZWxhdGVkIHRvIG9wZXJhdGlvbnMgYW5k IG1hbmFnZW1lbnQgb2YgbXVsdGljYXN0IHRyYW5zaXRpb24NCg0KU2VwIDIwMTIgU3VibWl0IHRv IElFU0cNCqhDIHByb2JsZW0gc3RhdGVtZW50IGRyYWZ0DQqoQyBpbnRlcndvcmtpbmcgZHJhZnRz DQotIGFkZHJlc3MgdHJhbnNsYXRpb24gZHJhZnQNCi0gZHJhZnRzIHJlbGF0ZWQgdG8gb3BlcmF0 aW9ucyBhbmQgbWFuYWdlbWVudCBvZiBtdWx0aWNhc3QgdHJhbnNpdGlvbg== --Boundary_(ID_H+8swxk7P5eidvm8zWEUzg)-- From mohamed.boucadair@orange.com Wed Sep 21 22:56:19 2011 Return-Path: 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 7DD5021F8D27 for ; Wed, 21 Sep 2011 22:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] 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 QNT80qBIrEgN for ; Wed, 21 Sep 2011 22:56:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id A69E021F8D26 for ; Wed, 21 Sep 2011 22:56:16 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 44CF72AC7E7; Thu, 22 Sep 2011 07:58:46 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 1D41A158069; Thu, 22 Sep 2011 07:58:46 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 22 Sep 2011 07:58:46 +0200 From: To: Tina TSOU , huang cancan , "multrans@ietf.org" Date: Thu, 22 Sep 2011 07:58:44 +0200 Thread-Topic: about the charter of Multrans Thread-Index: AQHMdFEddF8wA4uac0q/JDuLg2NoZZVYfQvQgABy1VA= Message-ID: <94C682931C08B048B7A8645303FDC9F355A8E5A24B@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F355A8E5A24BPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.9.22.41514 Subject: Re: [multrans] about the charter of Multrans X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 05:56:19 -0000 --_000_94C682931C08B048B7A8645303FDC9F355A8E5A24BPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Tina, Is there any interest on the stateful approaches? I have included it for di= scussion in the bar bof we had in Prague but, If I remember well, there was= no interest. IMHO, the charter should focus on the stateless. Cheers, Med ________________________________ De : multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] De la par= t de Tina TSOU Envoy=E9 : jeudi 22 septembre 2011 01:14 =C0 : huang cancan; multrans@ietf.org Objet : Re: [multrans] about the charter of Multrans Thank you, Cancan. Here is updated version, scoped down to a single use-case for which there i= s commercial interest (i.e., IPTV). Proposed MULTRANS Charter The task of the MULTRANS Working Group is to devise the means whereby exist= ing multicast mechanisms can operate successfully when signalling and conte= nt have to traverse one or more IPv4/IPv6 boundaries. The scope of the Work= ing Group is initially limited to the IPTV case, since the requirements for= this application are better understood than those for other potential mult= icast applications. Goals 1. The Working Group's first task is to develop a problem statement that id= entifies the scope of the problem of multicast operation for the IPTV appli= cation during the transition from IPv4 to IPv6. The problem statement will = identify: -- requirements that must be satisfied by the mechanisms for multicast transition; -- use cases that must be considered, ranked by priority; -- design considerations that should be taken into account in subsequ= ent work. 2. The Multrans Working Group will develop Standards Track documents specif= ying protocol interworking for the new combinations of protocols (for examp= le, between PIM (IPv4) and PIM (IPv6)) required for multicast transition fr= om IPv4 to IPv6. 3. The Multrans Working Group will specify the means whereby multicast addr= esses may be translated between IPv4 and IPv6, in both stateful and statele= ss fashion, in direct analogy to RFC 6052 for unicast addresses. 4. The Multrans Working Group will specify extensions to DHCPv4, DHCPv6, an= d RADIUS attributes required to configure hosts during the transitional per= iod. 5. The Multrans Working Group will specify the operational and management c= apabilities required to support multicast transition. In particular, this w= ork may involve the specification of MIBs. Relationship to other working groups: - Work done in the Softwire working group on the use of encapsulation as a = multicast transition mechanism will be coordinated with the more general wo= rk being done by the MULTRANS working group. - The specification for translation between IPv4 and IPv6 multicast address= es will be reviewed jointly with the MBONED working group, as will recommen= dations relating to operation and management of multicast transition. - DHCP options, RADIUS attributes, and MIB modules developed by MULTRANS wi= ll be jointly reviewed with the appropriate other parties (DHC and RADEXT w= orking groups, MIB Doctors directorate). - The interworking recommendations for PIM, IGMP, and MLD developed in this= group will be reviewed jointly with PIM, MBONED. Milestones May 2012 WG adopts - problem statement draft - interworking drafts - address translation draft - drafts related to operations and management of multicast transition Sep 2012 Submit to IESG - problem statement draft - interworking drafts - address translation draft - drafts related to operations and management of multicast transition Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: huang cancan [mailto:cancanhuang110@gmail.com] Sent: Friday, September 16, 2011 2:15 AM To: multrans@ietf.org Cc: Tina TSOU Subject: about the charter of Multrans hi all: We are ready to include solutions work in the charter. cancanhuang China Telecom --_000_94C682931C08B048B7A8645303FDC9F355A8E5A24BPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Tina,
 
Is there any interest on the stateful approac= hes? I=20 have included it for discussion in the bar bof we had in Prague but, If I=20 remember well, there was no interest.
 
IMHO, the charter should focus on the=20 stateless.
 
Cheers,
Med 

De : multrans-bounces@ietf.org=20 [mailto:multrans-bounces@ietf.org] De la part de Tina=20 TSOU
Envoy=E9 : jeudi 22 septembre 2011 01:14
=C0 = ;:=20 huang cancan; multrans@ietf.org
Objet : Re: [multrans] about= the=20 charter of Multrans

Thank=20 you, Cancan.

Here=20 is updated version, scoped down to a single use-case for which there is=20 commercial interest (i.e., IPTV).

 

Proposed=20 MULTRANS Charter

 

The=20 task of the MULTRANS Working Group is to devise the means whereby existing= =20 multicast mechanisms can operate successfully when signalling and content have to traverse one or more=20 IPv4/IPv6 boundaries. The scope of the Working Group is initially limited t= o the=20 IPTV case, since the requirements for this application are better understoo= d=20 than those for other potential multicast applications.

 

Goals

 

1.=20 The Working Group's first task is to develop a problem statement that ident= ifies=20 the scope of the problem of multicast operation for the IPTV application du= ring=20 the transition from IPv4 to IPv6. The problem statement will=20 identify:

      -- requirements that must be satisfied by the=20 mechanisms

        = ;=20 for multicast transition;

      -- use cases that must be considered, ranked by=20 priority;

      -- design considerations that should be taken into account in= =20 subsequent work.

 

2.=20 The Multrans Working Group will develop Standar= ds=20 Track documents specifying protocol interworking for the new combinations o= f=20 protocols (for example, between PIM (IPv4) and PIM (IPv6)) required for=20 multicast transition from IPv4 to IPv6.

 

3.=20 The Multrans Working Group will specify the mea= ns=20 whereby multicast addresses may be translated between IPv4 and IPv6, in bot= h=20 stateful and stateless fashion, in direct analo= gy to=20 RFC 6052 for unicast addresses.

 

4.=20 The Multrans Working Group will specify extensi= ons to=20 DHCPv4, DHCPv6, and RADIUS attributes required to configure hosts during th= e=20 transitional period.

 

5.=20 The Multrans Working Group will specify the=20 operational and management capabilities required to support multicast=20 transition. In particular, this work may involve the specification of=20 MIBs.

 

Relationship=20 to other working groups:

 

-=20 Work done in the Softwire working group on the use of encapsulation as a=20 multicast transition mechanism will be coordinated with the more general wo= rk=20 being done by the MULTRANS working group.

 

-=20 The specification for translation between IPv4 and IPv6 multicast addresses= will=20 be reviewed jointly with the MBONED working group, as will recommendations= =20 relating to operation and management of multicast=20 transition.

 

-=20 DHCP options, RADIUS attributes, and MIB modules developed by MULTRANS will= be=20 jointly reviewed with the appropriate other parties (DHC and RADEXT working= =20 groups, MIB Doctors directorate).

 

-=20 The interworking recommendations for PIM, IGMP, and MLD developed in this g= roup=20 will be reviewed jointly with PIM, MBONED.

 

 

Milestones

 

May=20 2012  WG<= /SPAN>=20 adopts

=96=20 problem statement draft

=96=20 interworking drafts

-=20  address translation=20 draft

-=20  drafts=20 related to operations and management of multicast=20 transition

 

Sep=20 2012 Submit to IESG

=96=20 problem statement draft

=96=20 interworking drafts

-=20  address translation=20 draft

-=20  drafts=20 related to operations and management of multicast=20 transition

 

 =

Best=20 Regards,

Tina=20 TSOU

http://tina= tsou.weebly.com/contact.html

 

From:=20 huang cancan [mailto:cancanhuang110@gmail.com]=20
Sent: Friday, September 16, 2011 2:15 AM
To:= =20 multrans@ietf.org
Cc: Tina TSOU
Subject: about the char= ter=20 of Multrans

 

hi all:

 

We are ready to include solutions work in the=20 charter.

 

cancanhuang

 

China Telecom

--_000_94C682931C08B048B7A8645303FDC9F355A8E5A24BPUEXCB1Bnante_-- From jacni@jacni.com Wed Sep 21 23:23:28 2011 Return-Path: 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 809C821F8C26 for ; Wed, 21 Sep 2011 23:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] 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 FyM8I5Vwx7GE for ; Wed, 21 Sep 2011 23:23:25 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3D021F8C16 for ; Wed, 21 Sep 2011 23:23:25 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id BA0753800A7 for ; Thu, 22 Sep 2011 02:25:53 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with SMTP id 4A8CF3400E0 for ; Thu, 22 Sep 2011 14:25:52 +0800 (CST) Received: from [172.18.4.149] (unknown [114.142.151.53]) by app (Coremail) with SMTP id +AWowJDrtgLt1HpOStIIAA--.12651S2; Thu, 22 Sep 2011 14:25:50 +0800 (CST) Message-ID: <4E7AD548.4020705@jacni.com> Date: Thu, 22 Sep 2011 14:27:20 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <94C682931C08B048B7A8645303FDC9F355A8E5A24B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F355A8E5A24B@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: multipart/alternative; boundary="------------010301040802020409050400" X-CM-TRANSID: +AWowJDrtgLt1HpOStIIAA--.12651S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWrW8AF1rXF18Xw48CryxGrg_yoWrZw45pa 98GF4UKF4kJF18Cw1kA3yqv34xuFyvq3y7Kas8Kwn8A398G3W8tr15t3y3tFWDXrs5Xa4j vF4j9r1UXay5ZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU-ab7IF0VCFI7km07C26c804VAKzcIF0wAYjxAI6xCI4x8I1I0E 5I8CrVAYj202j2Wlb7Iv0xC_Cr1lb4IE77IF4wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rV WrJVCq3wAawVACjsI_Ar4v6c8GOVW06r1DJrWUAwAawVCFI7vE04vSzxk24VAqrcv_Gr1U Xr18M2kK6IIYrVAqxI0j4VAqrcv_Jw1UGr1DM2vj6xkI62vS6c8GOVWUtr1rJFyl5I8CrV AYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG04xIwI0_Jr0_Gr1l 5I8CrVCF0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r 4UM4x0Y48IcVAKI48JM4x0x7Aq67kGj7Al6IIYrVW8Mx8GjcxK6IxK0xIIj40E5I8CrwCY jI0SjxkI62AI1cAE67vIY487MxAIw28IcxkI7VAKI48JMxCIbVAxMI8E67AF67kF1VAFwI 0_JF0_Jw1lIxkGc2Ij64vIr4UvcSsGvfC2KfnxnUUI43ZEXa7IUn_cTPUUUUU== X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQETEko7lOJOrwAAsn Cc: huang cancan , "multrans@ietf.org" Subject: Re: [multrans] about the charter of Multrans X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 06:23:28 -0000 This is a multi-part message in MIME format. --------------010301040802020409050400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Re-, On 9/22/2011 1:58 PM, mohamed.boucadair@orange.com wrote: > Dear Tina, > Is there any interest on the stateful approaches? I have included it > for discussion in the bar bof we had in Prague but, If I remember > well, there was no interest. > IMHO, the charter should focus on the stateless. > +1. In addition, not sure whether the specifications of Interworking functions are necessary. Since fortunately the signalling protocols are sort of IP version independent, more important thing is the address mapping/conversion. And they are implementations to a great extent which should be handled by different transition approaches according to their target use cases/scenarios. Cheers, Jacni > Cheers, > Med > > ------------------------------------------------------------------------ > *De :* multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] > *De la part de* Tina TSOU > *Envoyé :* jeudi 22 septembre 2011 01:14 > *À :* huang cancan; multrans@ietf.org > *Objet :* Re: [multrans] about the charter of Multrans > > Thank you, Cancan. > > Here is updated version, scoped down to a single use-case for which > there is commercial interest (i.e., IPTV). > > Proposed MULTRANS Charter > > The task of the MULTRANS Working Group is to devise the means whereby > existing multicast mechanisms can operate successfully when signalling > and content have to traverse one or more IPv4/IPv6 boundaries. The > scope of the Working Group is initially limited to the IPTV case, > since the requirements for this application are better understood than > those for other potential multicast applications. > > Goals > > 1. The Working Group's first task is to develop a problem statement > that identifies the scope of the problem of multicast operation for > the IPTV application during the transition from IPv4 to IPv6. The > problem statement will identify: > > -- requirements that must be satisfied by the mechanisms > > for multicast transition; > > -- use cases that must be considered, ranked by priority; > > -- design considerations that should be taken into account in > subsequent work. > > 2. The Multrans Working Group will develop Standards Track documents > specifying protocol interworking for the new combinations of protocols > (for example, between PIM (IPv4) and PIM (IPv6)) required for > multicast transition from IPv4 to IPv6. > > 3. The Multrans Working Group will specify the means whereby multicast > addresses may be translated between IPv4 and IPv6, in both stateful > and stateless fashion, in direct analogy to RFC 6052 for unicast > addresses. > > 4. The Multrans Working Group will specify extensions to DHCPv4, > DHCPv6, and RADIUS attributes required to configure hosts during the > transitional period. > > 5. The Multrans Working Group will specify the operational and > management capabilities required to support multicast transition. In > particular, this work may involve the specification of MIBs. > > Relationship to other working groups: > > - Work done in the Softwire working group on the use of encapsulation > as a multicast transition mechanism will be coordinated with the more > general work being done by the MULTRANS working group. > > - The specification for translation between IPv4 and IPv6 multicast > addresses will be reviewed jointly with the MBONED working group, as > will recommendations relating to operation and management of multicast > transition. > > - DHCP options, RADIUS attributes, and MIB modules developed by > MULTRANS will be jointly reviewed with the appropriate other parties > (DHC and RADEXT working groups, MIB Doctors directorate). > > - The interworking recommendations for PIM, IGMP, and MLD developed in > this group will be reviewed jointly with PIM, MBONED. > > Milestones > > May 2012WG adopts > > --problem statement draft > > --interworking drafts > > - address translation draft > > - drafts related to operations and management of multicast transition > > Sep 2012 Submit to IESG > > --problem statement draft > > --interworking drafts > > - address translation draft > > - drafts related to operations and management of multicast transition > > Best Regards, > > Tina TSOU > > http://tinatsou.weebly.com/contact.html > > *From:*huang cancan [mailto:cancanhuang110@gmail.com] > *Sent**:* Friday, September 16, 2011 2:15 AM > *To:* multrans@ietf.org > *Cc:* Tina TSOU > *Subject:* about the charter of Multrans > > hi all: > > We are ready to include solutions work in the charter. > > cancanhuang > > China Telecom > > > > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans --------------010301040802020409050400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Re-,

On 9/22/2011 1:58 PM, mohamed.boucadair@orange.com wrote:
Dear Tina,
 
Is there any interest on the stateful approaches? I have included it for discussion in the bar bof we had in Prague but, If I remember well, there was no interest.
 
IMHO, the charter should focus on the stateless.

+1.

In addition, not sure whether the specifications of Interworking functions are necessary. Since fortunately the signalling protocols are sort of IP version independent, more important thing is the address mapping/conversion. And they are implementations to a great extent which should be handled by different transition approaches according to their target use cases/scenarios.


Cheers,
Jacni


Cheers,
Med 

De : multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] De la part de Tina TSOU
Envoyé : jeudi 22 septembre 2011 01:14
À : huang cancan; multrans@ietf.org
Objet : Re: [multrans] about the charter of Multrans

Thank you, Cancan.

Here is updated version, scoped down to a single use-case for which there is commercial interest (i.e., IPTV).

 

Proposed MULTRANS Charter

 

The task of the MULTRANS Working Group is to devise the means whereby existing multicast mechanisms can operate successfully when signalling and content have to traverse one or more IPv4/IPv6 boundaries. The scope of the Working Group is initially limited to the IPTV case, since the requirements for this application are better understood than those for other potential multicast applications.

 

Goals

 

1. The Working Group's first task is to develop a problem statement that identifies the scope of the problem of multicast operation for the IPTV application during the transition from IPv4 to IPv6. The problem statement will identify:

      -- requirements that must be satisfied by the mechanisms

         for multicast transition;

      -- use cases that must be considered, ranked by priority;

      -- design considerations that should be taken into account in subsequent work.

 

2. The Multrans Working Group will develop Standards Track documents specifying protocol interworking for the new combinations of protocols (for example, between PIM (IPv4) and PIM (IPv6)) required for multicast transition from IPv4 to IPv6.

 

3. The Multrans Working Group will specify the means whereby multicast addresses may be translated between IPv4 and IPv6, in both stateful and stateless fashion, in direct analogy to RFC 6052 for unicast addresses.

 

4. The Multrans Working Group will specify extensions to DHCPv4, DHCPv6, and RADIUS attributes required to configure hosts during the transitional period.

 

5. The Multrans Working Group will specify the operational and management capabilities required to support multicast transition. In particular, this work may involve the specification of MIBs.

 

Relationship to other working groups:

 

- Work done in the Softwire working group on the use of encapsulation as a multicast transition mechanism will be coordinated with the more general work being done by the MULTRANS working group.

 

- The specification for translation between IPv4 and IPv6 multicast addresses will be reviewed jointly with the MBONED working group, as will recommendations relating to operation and management of multicast transition.

 

- DHCP options, RADIUS attributes, and MIB modules developed by MULTRANS will be jointly reviewed with the appropriate other parties (DHC and RADEXT working groups, MIB Doctors directorate).

 

- The interworking recommendations for PIM, IGMP, and MLD developed in this group will be reviewed jointly with PIM, MBONED.

 

 

Milestones

 

May 2012  WG adopts

– problem statement draft

– interworking drafts

-  address translation draft

-  drafts related to operations and management of multicast transition

 

Sep 2012 Submit to IESG

– problem statement draft

– interworking drafts

-  address translation draft

-  drafts related to operations and management of multicast transition

 

 

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

 

From: huang cancan [mailto:cancanhuang110@gmail.com]
Sent: Friday, September 16, 2011 2:15 AM
To: multrans@ietf.org
Cc: Tina TSOU
Subject: about the charter of Multrans

 

hi all:

 

We are ready to include solutions work in the charter.

 

cancanhuang

 

China Telecom



_______________________________________________
multrans mailing list
multrans@ietf.org
https://www.ietf.org/mailman/listinfo/multrans
--------------010301040802020409050400-- From tom111.taylor@bell.net Thu Sep 22 12:29:35 2011 Return-Path: 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 794011F0C53 for ; Thu, 22 Sep 2011 12:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.429 X-Spam-Level: X-Spam-Status: No, score=-101.429 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 dAuOmIsIDCzc for ; Thu, 22 Sep 2011 12:29:34 -0700 (PDT) Received: from blu0-omc4-s34.blu0.hotmail.com (blu0-omc4-s34.blu0.hotmail.com [65.55.111.173]) by ietfa.amsl.com (Postfix) with ESMTP id CA2DD1F0C3C for ; Thu, 22 Sep 2011 12:29:33 -0700 (PDT) Received: from BLU0-SMTP49 ([65.55.111.136]) by blu0-omc4-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Sep 2011 12:32:05 -0700 X-Originating-IP: [65.94.104.44] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([65.94.104.44]) by BLU0-SMTP49.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Sep 2011 12:32:04 -0700 Date: Thu, 22 Sep 2011 15:32:04 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <94C682931C08B048B7A8645303FDC9F355A8E5A24B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F355A8E5A24B@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 22 Sep 2011 19:32:05.0234 (UTC) FILETIME=[4F5DDD20:01CC795E] Cc: "multrans@ietf.org" Subject: Re: [multrans] about the charter of Multrans X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 19:29:35 -0000 As co-author of RFC 6052, perhaps you can explain why that document dealt with stateful translation. On 22/09/2011 1:58 AM, mohamed.boucadair@orange.com wrote: > Dear Tina, > > Is there any interest on the stateful approaches? I have included it for discussion in the bar bof we had in Prague but, If I remember well, there was no interest. > > IMHO, the charter should focus on the stateless. > > Cheers, > Med > > ________________________________ > De : multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] De la part de Tina TSOU > Envoyé : jeudi 22 septembre 2011 01:14 > À : huang cancan; multrans@ietf.org > Objet : Re: [multrans] about the charter of Multrans > > Thank you, Cancan. > Here is updated version, scoped down to a single use-case for which there is commercial interest (i.e., IPTV). > > Proposed MULTRANS Charter > > The task of the MULTRANS Working Group is to devise the means whereby existing multicast mechanisms can operate successfully when signalling and content have to traverse one or more IPv4/IPv6 boundaries. The scope of the Working Group is initially limited to the IPTV case, since the requirements for this application are better understood than those for other potential multicast applications. > > Goals > > 1. The Working Group's first task is to develop a problem statement that identifies the scope of the problem of multicast operation for the IPTV application during the transition from IPv4 to IPv6. The problem statement will identify: > -- requirements that must be satisfied by the mechanisms > for multicast transition; > -- use cases that must be considered, ranked by priority; > -- design considerations that should be taken into account in subsequent work. > > 2. The Multrans Working Group will develop Standards Track documents specifying protocol interworking for the new combinations of protocols (for example, between PIM (IPv4) and PIM (IPv6)) required for multicast transition from IPv4 to IPv6. > > 3. The Multrans Working Group will specify the means whereby multicast addresses may be translated between IPv4 and IPv6, in both stateful and stateless fashion, in direct analogy to RFC 6052 for unicast addresses. > > 4. The Multrans Working Group will specify extensions to DHCPv4, DHCPv6, and RADIUS attributes required to configure hosts during the transitional period. > > 5. The Multrans Working Group will specify the operational and management capabilities required to support multicast transition. In particular, this work may involve the specification of MIBs. > > Relationship to other working groups: > > - Work done in the Softwire working group on the use of encapsulation as a multicast transition mechanism will be coordinated with the more general work being done by the MULTRANS working group. > > - The specification for translation between IPv4 and IPv6 multicast addresses will be reviewed jointly with the MBONED working group, as will recommendations relating to operation and management of multicast transition. > > - DHCP options, RADIUS attributes, and MIB modules developed by MULTRANS will be jointly reviewed with the appropriate other parties (DHC and RADEXT working groups, MIB Doctors directorate). > > - The interworking recommendations for PIM, IGMP, and MLD developed in this group will be reviewed jointly with PIM, MBONED. > > > Milestones > > May 2012 WG adopts > - problem statement draft > - interworking drafts > - address translation draft > - drafts related to operations and management of multicast transition > > Sep 2012 Submit to IESG > - problem statement draft > - interworking drafts > - address translation draft > - drafts related to operations and management of multicast transition > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > From: huang cancan [mailto:cancanhuang110@gmail.com] > Sent: Friday, September 16, 2011 2:15 AM > To: multrans@ietf.org > Cc: Tina TSOU > Subject: about the charter of Multrans > > hi all: > > We are ready to include solutions work in the charter. > > cancanhuang > > China Telecom > > > > > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans From mohamed.boucadair@orange.com Thu Sep 22 23:24:10 2011 Return-Path: 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 E6B3021F8B77 for ; Thu, 22 Sep 2011 23:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] 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 ixEgg9vMf4ls for ; Thu, 22 Sep 2011 23:24:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9229321F8B5E for ; Thu, 22 Sep 2011 23:24:09 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id D89A32DC38D; Fri, 23 Sep 2011 08:26:39 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C0F5227C06F; Fri, 23 Sep 2011 08:26:39 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 23 Sep 2011 08:26:39 +0200 From: To: Tom Taylor Date: Fri, 23 Sep 2011 08:26:38 +0200 Thread-Topic: [multrans] about the charter of Multrans Thread-Index: Acx5XlHobmUXl1T3Syu+i/GweO6/jgAWeQ/A Message-ID: <94C682931C08B048B7A8645303FDC9F355A8E5A60D@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F355A8E5A24B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.9.23.22414 Cc: "multrans@ietf.org" Subject: Re: [multrans] about the charter of Multrans X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 06:24:11 -0000 Hi Tom, Please refer to http://tools.ietf.org/html/rfc6144 for the discussion state= less vs. stateful for the unicast service. In particular, RFC6144 states: Stateless translation can be used for Scenarios 1, 2, 5, and 6, i.e., it supports "an IPv6 network to the IPv4 Internet", "the IPv4 Internet to an IPv6 network", "an IPv6 network to an IPv4 network", and "an IPv4 network to an IPv6 network". And=20 Stateful translation can be used for Scenarios 1, 3, and 5, i.e., it supports "an IPv6 network to the IPv4 Internet", "the IPv6 Internet to an IPv4 network", and "an IPv6 network to an IPv4 network". For the multicast and taking into account the use case prioritization: (*) we need a representation IPv6 address of an IPv4 source in an IPv6 doma= in: this can be done in a stateless manner using IPv4-converted IPv6 addres= ses (*) we need a representation IPv4 address of the multicast group IPv4 addre= ss in an IPv6 domain: this can be done in a stateless manner using the addr= ess format defined in draft-boucadair-*. Using these address schemes we obtain: o Stateless IPv4-IPv6 header translation of multicast flows o Stateless IPv4-IPv6 PIM adaptation function o Stateless IGMP-MLD interworking function (e.g., required for an IPv4 receiver to access to IPv4 multicast content via an IPv6 network) o Stateless (local) synthesis of IPv6 address when IPv4 multicast address are embedded in application payload (e.g., SDP [RFC4566]) o Except the provisioning of the same MPREFIX64, no coordination is required between IPv4-IPv6 PIM interworking function, IGMP-MLD interworking function, IPv4-IPv6 Interconnection Function and any ALG (Application Level Gateway) in the path o Minimal operational constraints on the multicast address management: IPv6 multicast addresses can be constructed using what has been deployed for IPv4 delivery mode. Cheers, Med =20 -----Message d'origine----- De : Tom Taylor [mailto:tom111.taylor@bell.net]=20 Envoy=E9 : jeudi 22 septembre 2011 21:32 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : multrans@ietf.org Objet : Re: [multrans] about the charter of Multrans As co-author of RFC 6052, perhaps you can explain why that document=20 dealt with stateful translation. On 22/09/2011 1:58 AM, mohamed.boucadair@orange.com wrote: > Dear Tina, > > Is there any interest on the stateful approaches? I have included it for = discussion in the bar bof we had in Prague but, If I remember well, there w= as no interest. > > IMHO, the charter should focus on the stateless. > > Cheers, > Med > > ________________________________ > De : multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] De la p= art de Tina TSOU > Envoy=E9 : jeudi 22 septembre 2011 01:14 > =C0 : huang cancan; multrans@ietf.org > Objet : Re: [multrans] about the charter of Multrans > > Thank you, Cancan. > Here is updated version, scoped down to a single use-case for which there= is commercial interest (i.e., IPTV). > > Proposed MULTRANS Charter > > The task of the MULTRANS Working Group is to devise the means whereby exi= sting multicast mechanisms can operate successfully when signalling and con= tent have to traverse one or more IPv4/IPv6 boundaries. The scope of the Wo= rking Group is initially limited to the IPTV case, since the requirements f= or this application are better understood than those for other potential mu= lticast applications. > > Goals > > 1. The Working Group's first task is to develop a problem statement that = identifies the scope of the problem of multicast operation for the IPTV app= lication during the transition from IPv4 to IPv6. The problem statement wil= l identify: > -- requirements that must be satisfied by the mechanisms > for multicast transition; > -- use cases that must be considered, ranked by priority; > -- design considerations that should be taken into account in subs= equent work. > > 2. The Multrans Working Group will develop Standards Track documents spec= ifying protocol interworking for the new combinations of protocols (for exa= mple, between PIM (IPv4) and PIM (IPv6)) required for multicast transition = from IPv4 to IPv6. > > 3. The Multrans Working Group will specify the means whereby multicast ad= dresses may be translated between IPv4 and IPv6, in both stateful and state= less fashion, in direct analogy to RFC 6052 for unicast addresses. > > 4. The Multrans Working Group will specify extensions to DHCPv4, DHCPv6, = and RADIUS attributes required to configure hosts during the transitional p= eriod. > > 5. The Multrans Working Group will specify the operational and management= capabilities required to support multicast transition. In particular, this= work may involve the specification of MIBs. > > Relationship to other working groups: > > - Work done in the Softwire working group on the use of encapsulation as = a multicast transition mechanism will be coordinated with the more general = work being done by the MULTRANS working group. > > - The specification for translation between IPv4 and IPv6 multicast addre= sses will be reviewed jointly with the MBONED working group, as will recomm= endations relating to operation and management of multicast transition. > > - DHCP options, RADIUS attributes, and MIB modules developed by MULTRANS = will be jointly reviewed with the appropriate other parties (DHC and RADEXT= working groups, MIB Doctors directorate). > > - The interworking recommendations for PIM, IGMP, and MLD developed in th= is group will be reviewed jointly with PIM, MBONED. > > > Milestones > > May 2012 WG adopts > - problem statement draft > - interworking drafts > - address translation draft > - drafts related to operations and management of multicast transition > > Sep 2012 Submit to IESG > - problem statement draft > - interworking drafts > - address translation draft > - drafts related to operations and management of multicast transition > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > From: huang cancan [mailto:cancanhuang110@gmail.com] > Sent: Friday, September 16, 2011 2:15 AM > To: multrans@ietf.org > Cc: Tina TSOU > Subject: about the charter of Multrans > > hi all: > > We are ready to include solutions work in the charter. > > cancanhuang > > China Telecom > > > > > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans From gjshep@gmail.com Tue Sep 27 09:00:21 2011 Return-Path: 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 466EB21F8BCD for ; Tue, 27 Sep 2011 09:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.442 X-Spam-Level: X-Spam-Status: No, score=-103.442 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 cgiYUy-kCifx for ; Tue, 27 Sep 2011 09:00:20 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD7A121F8C74 for ; Tue, 27 Sep 2011 09:00:18 -0700 (PDT) Received: by bkaq10 with SMTP id q10so7915583bka.31 for ; Tue, 27 Sep 2011 09:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=MY3zcU5ji6IJDH3PET3SSX2tctvExlAdJwxKlMFPOUM=; b=vIKQaGoNEhAcf0lbXqYHGk0HjZmfZw+hINcOBQ5GSq5n7R8nxRPn7uQT6dQBI90JkF zU7O/08ZNkvME5oXl9E5gIbUS7lox7rFuZnwvnHTZr7WOATWJCnn0gRZ3cfSLQ0fsceP 3NBZ8ZMByBq6I6MD2bc4yqyup1DovtfpVusYU= MIME-Version: 1.0 Received: by 10.204.140.148 with SMTP id i20mr4912476bku.96.1317139383553; Tue, 27 Sep 2011 09:03:03 -0700 (PDT) Received: by 10.204.51.132 with HTTP; Tue, 27 Sep 2011 09:03:03 -0700 (PDT) In-Reply-To: <20110927131722.1CA0021F8CC1@ietfa.amsl.com> References: <20110927131722.1CA0021F8CC1@ietfa.amsl.com> Date: Tue, 27 Sep 2011 09:03:03 -0700 Message-ID: From: Greg Shepherd To: multrans@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multrans] Fwd: multrans - New Meeting Session Request for IETF 82 X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 16:00:21 -0000 BOF II requested for Taipei. ---------- Forwarded message ---------- From: IETF Meeting Session Request Tool Date: Tue, Sep 27, 2011 at 6:17 AM Subject: multrans - New Meeting Session Request for IETF 82 To: session-request@ietf.org Cc: dromasca@avaya.com, rbonica@juniper.net, gjshep@gmail.com, joelja@bogus= .com A new meeting session request has just been submitted by Greg Shepherd, a working group chair of multrans. --------------------------------------------------------- Working Group Name: multrans Area Name: Operations and Management Area Session Requester: Greg Shepherd Number of Sessions: 1 Length of Session(s): =A02 hours Number of Attendees: 100 Conflicts to Avoid: =A0First Priority: =A0mboned pim softwire rmt v6ops =A0Second Priority: =A0tsvarea intarea =A0BOF or IRTF Session: This will be the second formal BOF to discuss Multicast Transition requirements leading to a decision as to whether this work requires a dedicated WG. Special Requests: ---------------------------------------------------------