From gjshep@gmail.com Tue Aug 9 09:01:12 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 5867D21F8C1A for ; Tue, 9 Aug 2011 09:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 nr85hDhCbh4X for ; Tue, 9 Aug 2011 09:01:11 -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 A364721F8C41 for ; Tue, 9 Aug 2011 09:01:08 -0700 (PDT) Received: by fxe6 with SMTP id 6so193190fxe.31 for ; Tue, 09 Aug 2011 09:01:37 -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=d3HHGX/wZdtpspaHi3gFtUmM9Na0+dZHwXJf/49quzQ=; b=lvWdXBNTrXAweZ9I4SOr6EsTE4rosOc6vdULNmJeD+AQ1z3c1O64WT4q2LDP3RmrDg rhvAauYtW5+VrNU9wB75ixc3Lev6QUUUt+CqNvEu6egi2+y6Xlg66Er4syuv7WkdRVdm 5Z6P7rKWq3MR2hde/CEFt499U17Ui9l9Fuyfs= MIME-Version: 1.0 Received: by 10.204.20.203 with SMTP id g11mr744891bkb.233.1312905696997; Tue, 09 Aug 2011 09:01:36 -0700 (PDT) Received: by 10.204.119.137 with HTTP; Tue, 9 Aug 2011 09:01:36 -0700 (PDT) Date: Tue, 9 Aug 2011 09:01:36 -0700 Message-ID: From: Greg Shepherd To: multrans@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [multrans] BOF 1 down.. 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, 09 Aug 2011 16:01:12 -0000 Thanks everyone for attending/participating on the first Multrans BOF. I'll post the minutes on the list for approval before posting them at ietf.org so please look for them here later this week. I believe we did well in working toward focusing the issues brought do the group down to specific scenarios and prioritizing needs. But we'll need to solidify these two in advance of BOF II in Taipei. So first, we need to document use cases. I believe we had two "volunteers" at the BOF mention their willingness to document use cases. Please do so. This doesn't need to be a draft, but a detailed network diagram showing the relevant puzzle and missing piece(s). Once we've agreed upon use cases and have them well defined, we can document them in a consolidated use-case draft for general distribution. From this should come the prioritized list of issues. If we get this far before Taipei then I feel the next BOF could be even more productive as well can address the list and how it relates to other on-going IETF work to better identify what is missing from the current set of solutions. Thanks again everyone!, Greg From Tina.Tsou.Zouting@huawei.com Tue Aug 9 10:57:18 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 3EC4021F8A23 for ; Tue, 9 Aug 2011 10:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.622, 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 I4IAg86fUsbA for ; Tue, 9 Aug 2011 10:57:17 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7B16B21F8A1A for ; Tue, 9 Aug 2011 10:57:17 -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 <0LPO00LFR9W8HX@szxga03-in.huawei.com> for multrans@ietf.org; Wed, 10 Aug 2011 01:57:45 +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 <0LPO008C19W8J6@szxga03-in.huawei.com> for multrans@ietf.org; Wed, 10 Aug 2011 01:57:44 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADA90890; Wed, 10 Aug 2011 01:57:44 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 10 Aug 2011 01:57:41 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.99]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Wed, 10 Aug 2011 01:57:39 +0800 Date: Tue, 09 Aug 2011 17:57:40 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.193.34.126] To: "gjshep@gmail.com" , "multrans@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [multrans] BOF 1 down.. Thread-index: AQHMVq37Gkk568bySkqFo66eLgFMSZUUzg2w X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [multrans] BOF 1 down.. 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: Tue, 09 Aug 2011 17:57:18 -0000 Greg and Joel, Thank you for being the wonderful BoF chairs. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] On Behalf Of Greg Shepherd Sent: Tuesday, August 09, 2011 9:02 AM To: multrans@ietf.org Subject: [multrans] BOF 1 down.. Thanks everyone for attending/participating on the first Multrans BOF. I'll post the minutes on the list for approval before posting them at ietf.org so please look for them here later this week. I believe we did well in working toward focusing the issues brought do the group down to specific scenarios and prioritizing needs. But we'll need to solidify these two in advance of BOF II in Taipei. So first, we need to document use cases. I believe we had two "volunteers" at the BOF mention their willingness to document use cases. Please do so. This doesn't need to be a draft, but a detailed network diagram showing the relevant puzzle and missing piece(s). Once we've agreed upon use cases and have them well defined, we can document them in a consolidated use-case draft for general distribution. From this should come the prioritized list of issues. If we get this far before Taipei then I feel the next BOF could be even more productive as well can address the list and how it relates to other on-going IETF work to better identify what is missing from the current set of solutions. Thanks again everyone!, Greg _______________________________________________ multrans mailing list multrans@ietf.org https://www.ietf.org/mailman/listinfo/multrans From roberta.maglione@telecomitalia.it Tue Aug 23 00:47: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 4F82821F86DD for ; Tue, 23 Aug 2011 00:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.238 X-Spam-Level: * X-Spam-Status: No, score=1.238 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 QSfaubCwLG4U for ; Tue, 23 Aug 2011 00:47:47 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 86FE721F8620 for ; Tue, 23 Aug 2011 00:47:47 -0700 (PDT) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 23 Aug 2011 09:48:52 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Tue, 23 Aug 2011 09:48:52 +0200 From: Maglione Roberta To: "'multrans@ietf.org'" Date: Tue, 23 Aug 2011 09:48:52 +0200 Thread-Topic: Clarification question about Problem Statement and Use Cases draft Thread-Index: AcxhaRlrFggMTacCSO21470vfvxz1w== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D91@GRFMBX704BA020.griffon.local> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ullio Mario Subject: [multrans] Clarification question about Problem Statement and Use Cases draft 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: Tue, 23 Aug 2011 07:47:48 -0000 Hello, I have a question about the prioritization of the scenarios described in= draft draft-jaclee-behave-v4v6-mcast-ps: Section 3.2 "IPv6 Receiver and Source Connected to an IPv4-Only Network" sa= ys that 6-4-6 scenario according to the BEHAVE WG is of lower priority, I = would like to better understand why. In my opinion "IPv6 Receiver and Source Connected to an IPv4-Only Network" = use case could also cover the scenario where both receivers and source are = IPv6 and they get IPv6 unicast connectivity from an IPv4 network by using 6= PE solution (for unicast traffic). If I am not wrong this use case does not belong to behave discussion, but I= believe that having a multicast equivalent solution for 6PE may be useful = for a Service Provider that would like to start offering IPv6 multicast kee= ping his own backbone network in IPv4. I would appreciate your comments. Thanks, Best regards, Roberta Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From yiu_lee@cable.comcast.com Tue Aug 23 00:54:14 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 3CC7921F8B11 for ; Tue, 23 Aug 2011 00:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.537 X-Spam-Level: X-Spam-Status: No, score=-105.537 tagged_above=-999 required=5 tests=[AWL=1.437, BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, 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 w6Vm2aOMeHoU for ; Tue, 23 Aug 2011 00:54:13 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8716F21F8B0D for ; Tue, 23 Aug 2011 00:54:13 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.137935224; Tue, 23 Aug 2011 03:55:18 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Tue, 23 Aug 2011 03:55:18 -0400 From: "Lee, Yiu" To: Maglione Roberta Thread-Topic: [multrans] Clarification question about Problem Statement and Use Cases draft Thread-Index: AcxhaRlrFggMTacCSO21470vfvxz1wAIl/eA Date: Tue, 23 Aug 2011 07:55:17 +0000 Message-ID: <78E58E38-F5AC-4A1C-BD16-A11BF9633203@Cable.Comcast.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D91@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D91@GRFMBX704BA020.griffon.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <912DC98E79B38B40B49E2E83DC76E097@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multrans@ietf.org" , Ullio Mario Subject: Re: [multrans] Clarification question about Problem Statement and Use Cases draft 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: Tue, 23 Aug 2011 07:54:14 -0000 Hi Roberta, So you refer to S6-N4-R6 case? Regards, Yiu On Aug 23, 2011, at 3:48 AM, "Maglione Roberta" wrote: > In my opinion "IPv6 Receiver and Source Connected to an IPv4-Only =20 > Network" use case could also cover the scenario where both receivers =20 > and source are IPv6 and they get IPv6 unicast connectivity from an =20 > IPv4 network by using 6PE solution (for unicast traffic). > If I am not wrong this use case does not belong to behave =20 > discussion, but I believe that having a multicast equivalent =20 > solution for 6PE may be useful for a Service Provider that would =20 > like to start offering IPv6 multicast keeping his own backbone =20 > network in IPv4. > > I would appreciate your comments. > Thanks, > Best regards, > Roberta > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente =20 > alle persone indicate. La diffusione, copia o qualsiasi altra azione =20 > derivante dalla conoscenza di queste informazioni sono rigorosamente =20 > vietate. Qualora abbiate ricevuto questo documento per errore siete =20 > cortesemente pregati di darne immediata comunicazione al mittente e =20 > di provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain =20 > privileged information intended for the addressee(s) only. =20 > Dissemination, copying, printing or use by anybody else is =20 > unauthorised. If you are not the intended recipient, please delete =20 > this message and any attachments and advise the sender by return e-=20 > mail, Thanks. > > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans From roberta.maglione@telecomitalia.it Tue Aug 23 00:55:46 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 E6E1121F855D for ; Tue, 23 Aug 2011 00:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 zy7D8HKkeFow for ; Tue, 23 Aug 2011 00:55:46 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 28EC521F8548 for ; Tue, 23 Aug 2011 00:55:46 -0700 (PDT) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 23 Aug 2011 09:56:52 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Tue, 23 Aug 2011 09:56:52 +0200 From: Maglione Roberta To: "'Lee, Yiu'" Date: Tue, 23 Aug 2011 09:56:52 +0200 Thread-Topic: [multrans] Clarification question about Problem Statement and Use Cases draft Thread-Index: AcxhaRlrFggMTacCSO21470vfvxz1wAIl/eAAAhXTLA= Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D92@GRFMBX704BA020.griffon.local> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D91@GRFMBX704BA020.griffon.local> <78E58E38-F5AC-4A1C-BD16-A11BF9633203@Cable.Comcast.com> In-Reply-To: <78E58E38-F5AC-4A1C-BD16-A11BF9633203@Cable.Comcast.com> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multrans@ietf.org" , Ullio Mario Subject: Re: [multrans] Clarification question about Problem Statement and Use Cases draft 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: Tue, 23 Aug 2011 07:55:47 -0000 Hi Yiu, Yes, correct. Thanks Roberta -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Sent: marted=EC 23 agosto 2011 9.55 To: Maglione Roberta Cc: multrans@ietf.org; Ullio Mario Subject: Re: [multrans] Clarification question about Problem Statement and = Use Cases draft Hi Roberta, So you refer to S6-N4-R6 case? Regards, Yiu On Aug 23, 2011, at 3:48 AM, "Maglione Roberta" wrote: > In my opinion "IPv6 Receiver and Source Connected to an IPv4-Only > Network" use case could also cover the scenario where both receivers > and source are IPv6 and they get IPv6 unicast connectivity from an > IPv4 network by using 6PE solution (for unicast traffic). > If I am not wrong this use case does not belong to behave > discussion, but I believe that having a multicast equivalent > solution for 6PE may be useful for a Service Provider that would > like to start offering IPv6 multicast keeping his own backbone > network in IPv4. > > I would appreciate your comments. > Thanks, > Best regards, > Roberta > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e > di provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. > Dissemination, copying, printing or use by anybody else is > unauthorised. If you are not the intended recipient, please delete > this message and any attachments and advise the sender by return e- > mail, Thanks. > > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From yiu_lee@cable.comcast.com Tue Aug 23 00:59:55 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 F0DAF21F8B27 for ; Tue, 23 Aug 2011 00:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.525 X-Spam-Level: X-Spam-Status: No, score=-105.525 tagged_above=-999 required=5 tests=[AWL=1.185, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8, 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 ZNkimwN+dIt1 for ; Tue, 23 Aug 2011 00:59:54 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id B87F921F8B20 for ; Tue, 23 Aug 2011 00:59:53 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.137935330; Tue, 23 Aug 2011 04:00:58 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Tue, 23 Aug 2011 04:00:58 -0400 From: "Lee, Yiu" To: Maglione Roberta Thread-Topic: [multrans] Clarification question about Problem Statement and Use Cases draft Thread-Index: AcxhaRlrFggMTacCSO21470vfvxz1wAIl/eAAAhXTLD//77qAA== Date: Tue, 23 Aug 2011 08:00:56 +0000 Message-ID: <379B24BA-08AB-45A4-BD97-311A91225B04@Cable.Comcast.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D91@GRFMBX704BA020.griffon.local> <78E58E38-F5AC-4A1C-BD16-A11BF9633203@Cable.Comcast.com> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D92@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D92@GRFMBX704BA020.griffon.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" Content-ID: <7BE84CAB564E1C4FA728BAE3DA54A650@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "multrans@ietf.org" , Ullio Mario Subject: Re: [multrans] Clarification question about Problem Statement and Use Cases draft 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: Tue, 23 Aug 2011 07:59:55 -0000 SGkgUm9iZXJ0YSwNCg0KV2UgZGlkIHRoaW5rIGFib3V0IGl0LiBGb3IgdGhlIFBTIGFuZCB1c2Vj YXNlLCB3ZSBjYW4gaW5jbHVkZSB0aGlzLiBUbyAgDQpwcmlvcml0aXplIHRoZSB3b3JrLCBkbyB5 b3Ugc2VlIHRoaXMgaGlnaCBwcmlvcml0eSB0byBhZGRyZXNzPw0KDQpUaGFua3MsDQpZaXUNCg0K DQoNCk9uIEF1ZyAyMywgMjAxMSwgYXQgMzo1NyBBTSwgIk1hZ2xpb25lIFJvYmVydGEiIDxyb2Jl cnRhLm1hZ2xpb25lQHRlbGVjb21pdGFsaWEuaXQgDQogPiB3cm90ZToNCg0KPiBIaSBZaXUsDQo+ IFllcywgY29ycmVjdC4NCj4gVGhhbmtzDQo+IFJvYmVydGENCj4NCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogTGVlLCBZaXUgW21haWx0bzpZaXVfTGVlQENhYmxlLkNvbWNh c3QuY29tXQ0KPiBTZW50OiBtYXJ0ZWSorCAyMyBhZ29zdG8gMjAxMSA5LjU1DQo+IFRvOiBNYWds aW9uZSBSb2JlcnRhDQo+IENjOiBtdWx0cmFuc0BpZXRmLm9yZzsgVWxsaW8gTWFyaW8NCj4gU3Vi amVjdDogUmU6IFttdWx0cmFuc10gQ2xhcmlmaWNhdGlvbiBxdWVzdGlvbiBhYm91dCBQcm9ibGVt ICANCj4gU3RhdGVtZW50IGFuZCBVc2UgQ2FzZXMgZHJhZnQNCj4NCj4gSGkgUm9iZXJ0YSwNCj4N Cj4gU28geW91IHJlZmVyIHRvIFM2LU40LVI2IGNhc2U/DQo+DQo+IFJlZ2FyZHMsDQo+IFlpdQ0K Pg0KPg0KPg0KPiBPbiBBdWcgMjMsIDIwMTEsIGF0IDM6NDggQU0sICJNYWdsaW9uZSBSb2JlcnRh IiA8cm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0DQo+PiB3cm90ZToNCj4NCj4+IElu IG15IG9waW5pb24gIklQdjYgUmVjZWl2ZXIgYW5kIFNvdXJjZSBDb25uZWN0ZWQgdG8gYW4gSVB2 NC1Pbmx5DQo+PiBOZXR3b3JrIiB1c2UgY2FzZSBjb3VsZCBhbHNvIGNvdmVyIHRoZSBzY2VuYXJp byB3aGVyZSBib3RoIHJlY2VpdmVycw0KPj4gYW5kIHNvdXJjZSBhcmUgSVB2NiBhbmQgdGhleSBn ZXQgSVB2NiB1bmljYXN0IGNvbm5lY3Rpdml0eSBmcm9tIGFuDQo+PiBJUHY0IG5ldHdvcmsgYnkg dXNpbmcgNlBFIHNvbHV0aW9uIChmb3IgdW5pY2FzdCB0cmFmZmljKS4NCj4+IElmIEkgYW0gbm90 IHdyb25nIHRoaXMgdXNlIGNhc2UgZG9lcyBub3QgYmVsb25nIHRvIGJlaGF2ZQ0KPj4gZGlzY3Vz c2lvbiwgYnV0IEkgYmVsaWV2ZSB0aGF0IGhhdmluZyBhIG11bHRpY2FzdCBlcXVpdmFsZW50DQo+ PiBzb2x1dGlvbiBmb3IgNlBFIG1heSBiZSB1c2VmdWwgZm9yIGEgU2VydmljZSBQcm92aWRlciB0 aGF0IHdvdWxkDQo+PiBsaWtlIHRvIHN0YXJ0IG9mZmVyaW5nIElQdjYgbXVsdGljYXN0IGtlZXBp bmcgaGlzIG93biBiYWNrYm9uZQ0KPj4gbmV0d29yayBpbiBJUHY0Lg0KPj4NCj4+IEkgd291bGQg YXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRzLg0KPj4gVGhhbmtzLA0KPj4gQmVzdCByZWdhcmRzLA0K Pj4gUm9iZXJ0YQ0KPj4NCj4+DQo+PiBRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRp IHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUNCj4+IGFsbGUgcGVyc29uZSBpbmRpY2F0 ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lDQo+PiBkZXJp dmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jv c2FtZW50ZQ0KPj4gdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1 bWVudG8gcGVyIGVycm9yZSBzaWV0ZQ0KPj4gY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUg aW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZQ0KPj4gZGkgcHJvdnZlZGVyZSBh bGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KPj4NCj4+IFRoaXMgZS1tYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbg0KPj4gcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5Lg0KPj4gRGlz c2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcw0K Pj4gdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2UgZGVsZXRlDQo+PiB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2 aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtDQo+PiBtYWlsLCBUaGFua3MuDQo+Pg0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG11bHRyYW5z IG1haWxpbmcgbGlzdA0KPj4gbXVsdHJhbnNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXVsdHJhbnMNCj4NCj4gUXVlc3RvIG1lc3NhZ2dpbyBlIGkg c3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlICANCj4gYWxsZSBw ZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBh emlvbmUgIA0KPiBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXpp b25pIHNvbm8gcmlnb3Jvc2FtZW50ZSAgDQo+IHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNl dnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgIA0KPiBjb3J0ZXNlbWVudGUg cHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlICAN Cj4gZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KPg0KPiBUaGlz IGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRh aW4gIA0KPiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2Vl KHMpIG9ubHkuICANCj4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5 IGFueWJvZHkgZWxzZSBpcyAgDQo+IHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSAgDQo+IHRoaXMgbWVzc2FnZSBhbmQgYW55 IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS0gDQo+IG1haWws IFRoYW5rcy4NCj4NCg== From roberta.maglione@telecomitalia.it Tue Aug 23 01:54:17 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 D62C521F86DD for ; Tue, 23 Aug 2011 01:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.021 X-Spam-Level: X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 i1ue1ryJwz4m for ; Tue, 23 Aug 2011 01:54:17 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id CABE921F84F9 for ; Tue, 23 Aug 2011 01:54:16 -0700 (PDT) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 23 Aug 2011 10:55:22 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Tue, 23 Aug 2011 10:55:21 +0200 From: Maglione Roberta To: "'Lee, Yiu'" Date: Tue, 23 Aug 2011 10:55:21 +0200 Thread-Topic: [multrans] Clarification question about Problem Statement and Use Cases draft Thread-Index: AcxhaRlrFggMTacCSO21470vfvxz1wAIl/eAAAhXTLD//77qAIAANdVg Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D94@GRFMBX704BA020.griffon.local> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D91@GRFMBX704BA020.griffon.local> <78E58E38-F5AC-4A1C-BD16-A11BF9633203@Cable.Comcast.com> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D92@GRFMBX704BA020.griffon.local> <379B24BA-08AB-45A4-BD97-311A91225B04@Cable.Comcast.com> In-Reply-To: <379B24BA-08AB-45A4-BD97-311A91225B04@Cable.Comcast.com> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multrans@ietf.org" , Ullio Mario Subject: Re: [multrans] Clarification question about Problem Statement and Use Cases draft 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: Tue, 23 Aug 2011 08:54:17 -0000 Hi Yiu, Thanks for your reply. It would be good to include this use case in the draft. As far as priority, I'm not sure about how the group interprets the terms "= high" and "low", but in I would give to this scenario the same ranking you = put for 4-6-4 e.g. DSLite. Best regards, Roberta -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Sent: marted=EC 23 agosto 2011 10.01 To: Maglione Roberta Cc: multrans@ietf.org; Ullio Mario Subject: Re: [multrans] Clarification question about Problem Statement and = Use Cases draft Hi Roberta, We did think about it. For the PS and usecase, we can include this. To prioritize the work, do you see this high priority to address? Thanks, Yiu On Aug 23, 2011, at 3:57 AM, "Maglione Roberta" wrote: > Hi Yiu, > Yes, correct. > Thanks > Roberta > > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Sent: marted=EC 23 agosto 2011 9.55 > To: Maglione Roberta > Cc: multrans@ietf.org; Ullio Mario > Subject: Re: [multrans] Clarification question about Problem > Statement and Use Cases draft > > Hi Roberta, > > So you refer to S6-N4-R6 case? > > Regards, > Yiu > > > > On Aug 23, 2011, at 3:48 AM, "Maglione Roberta" > wrote: > >> In my opinion "IPv6 Receiver and Source Connected to an IPv4-Only >> Network" use case could also cover the scenario where both receivers >> and source are IPv6 and they get IPv6 unicast connectivity from an >> IPv4 network by using 6PE solution (for unicast traffic). >> If I am not wrong this use case does not belong to behave >> discussion, but I believe that having a multicast equivalent >> solution for 6PE may be useful for a Service Provider that would >> like to start offering IPv6 multicast keeping his own backbone >> network in IPv4. >> >> I would appreciate your comments. >> Thanks, >> Best regards, >> Roberta >> >> >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente >> alle persone indicate. La diffusione, copia o qualsiasi altra azione >> derivante dalla conoscenza di queste informazioni sono rigorosamente >> vietate. Qualora abbiate ricevuto questo documento per errore siete >> cortesemente pregati di darne immediata comunicazione al mittente e >> di provvedere alla sua distruzione, Grazie. >> >> This e-mail and any attachments is confidential and may contain >> privileged information intended for the addressee(s) only. >> Dissemination, copying, printing or use by anybody else is >> unauthorised. If you are not the intended recipient, please delete >> this message and any attachments and advise the sender by return e- >> mail, Thanks. >> >> _______________________________________________ >> multrans mailing list >> multrans@ietf.org >> https://www.ietf.org/mailman/listinfo/multrans > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e > di provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. > Dissemination, copying, printing or use by anybody else is > unauthorised. If you are not the intended recipient, please delete > this message and any attachments and advise the sender by return e- > mail, Thanks. > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From Tina.Tsou.Zouting@huawei.com Tue Aug 23 12:54:56 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 8B62A21F8CDE; Tue, 23 Aug 2011 12:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.822 X-Spam-Level: X-Spam-Status: No, score=-5.822 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=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 6HAhMeYKCzyi; Tue, 23 Aug 2011 12:54:55 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4756B21F8CE9; Tue, 23 Aug 2011 12:54:54 -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 <0LQE00AVVCPDRX@szxga05-in.huawei.com>; Wed, 24 Aug 2011 03:56:01 +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 <0LQE00LBGCPCOA@szxga05-in.huawei.com>; Wed, 24 Aug 2011 03:56:01 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADJ10197; Wed, 24 Aug 2011 03:56:00 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 24 Aug 2011 03:55:57 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Wed, 24 Aug 2011 03:55:57 +0800 Date: Tue, 23 Aug 2011 19:55:55 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.193.34.145] To: Jacni Qin Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_BgwBklIBz1/o3vJwpk98rA)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Thread-index: AQHMYTdUSUw9NjVHm0mqk4ZZAfKXSpUprIKggABN34CAAN1WYA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "softwires@ietf.org" , Multicast Transition Subject: Re: [multrans] [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 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: Tue, 23 Aug 2011 19:54:56 -0000 --Boundary_(ID_BgwBklIBz1/o3vJwpk98rA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Jacni, Thank you for your prompt reply, which shows you are a very good engineer and coauthor. You are too close to your text. You know what you want to say, but it doesn't necessarily say that to other people. A few of the observations below are of that nature. Detailed replies below, marked with [TT]. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: Jacni Qin [mailto:jacniq@gmail.com] Sent: Tuesday, August 23, 2011 7:32 AM To: Tina TSOU Cc: softwires@ietf.org Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Thanks for the comments, inline please. On Tue, Aug 23, 2011 at 9:58 AM, Tina TSOU > wrote: Hi all, In IETF-81, the chairs asked the authors of different drafts on multicast sit together to discuss and compromise. So we did. Here are some comments on draft-qin-softwire-dslite-multicast-04. Overall: if this is to be a Standards Track document, the whole document has to be reviewed, the normative parts identified, and requirements language substituted for the current descriptive language. Jacni>: I don't see it, while you can post comments. [TT] Where are the MUSTs, SHOULDs, and MAYs that have to be satisfied for interoperability? Everything is "will" or "should". Section 1: Editorial: at the end of the second paragraph, "vastly consumed" reads better in English as: "consumed in vast quantities". Jacni>: Sorry, EN is not my first language. Maybe we need the help from a native guy. [TT] I'll get one to confirm this. Substantive: add the following to the sentence making up the third paragraph: "..., which prevents these consequences by making use of the native multicast capabilities of the intervening IPv6 network." Jacni>: No objection to add a sentence, but modified as "which preserves the efficiency of using multicast for traffics forwarding." [TT] Why not the more specific statement? BTW, the word in English is "traffic". not "traffics". Section 2: Terminology: "Multicast AFTR" has connotations (IPv4 NAT) that simply aren't there. Suggestion: "Multicast Transitional Border Gateway (mTBG)". Jacni>: I think the AFTR is a general item, see the similar comments raised in another thread about 4rd. Substantive(?): In the description of the Multicast B4, it would make more sense to change "... which is able to enforce ..." to "... which implements ...". Section 3.2: Bullet 1: the second sentence jams two unrelated ideas together. It needs a little expansion to read properly. The next sentence doesn't make sense within the stated scope of the bullet and shouldn't be there. The suggested changed text is thus: Jacni>: Sorry, I don't agree. I think text in the paragraph following the bullet explains the scope clearly. [TT] The sentence that the text below omits reads as follows: "While since technically, there is no extra function required for the scenario of native access (i.e. to access dual-stack content natively from the IPv6 receiver), this portion is not taken into account." The title of the use case is: "An IPv4 receiver accessing IPv4 content (i.e., content formatted and reachable in IPv4)" So what does an IPv6 receiver have to do with this? And getting content from the receiver? The whole sentence just doesn't make sense. "A viable scenario for this use case in DS-Lite environment: customers with legacy receivers must continue to access the IPv4-enabled multicast services. This means the traffic should be accessed through IPv4 and additional functions are needed to traverse the operator's IPv6- enabled network. It is the purpose of this document to describe those functions. Refer to [I-D.jaclee-behave- v4v6-mcast-ps] for the deployment considerations." Final paragraph: don't you need a final sentence saying something like: "Depending on the specific details of the contract, this may mean that the specific framing of the content packets (as IPv4 packets) must be preserved along with the content within that framing." Jacni>:That's what the current text means. [TT] No, it just makes a case for it. We have to draw the conclusion, not leave it to the reader. Section 4: First paragraph: the following sentences need to be added after the first one to give a full picture of what is required for a solution: "For multicast, in contrast, separate mechanisms are required to process the outgoing multicast signalling packets and the incoming packets of content. The multicast signalling needs to be interworked to IPv6 and processed as IPv6 signalling. For incoming multicast content, this document defines ..." Jacni>: The signalling things will be detailed in the signalling section. This is just a general description here. [TT] The general description has to be general, not just focus on the handling of the multicast content. Middle paragraph: why doesn't it simply read: "See Section 4.3 for multicast distribution tree establishment and Section 4.4 for multicast traffic forwarding." Section 4.2 Third paragraph typo: mPrefixe64 -> mPrefix64 Jacni>: Oops, got it, thank you. Section 4.3 Bullets: it makes no sense to embed the mAFTR in the MLD Querier. That would cause the native IPv6 multicast infrastructure to be bypassed. It is also inconsistent with the architectural figure. Delete the first bullet and merge the second one with the next paragraph, like this: Jacni>: Actually, this is one of the typical cases. The mAFTR can be embedded in the MLD Querier, which will not bapass the IPv6 multicast infrastructure. [TT] The only way I can see that is if the MLD Querier happens to have a link directly to the target IPv4 network, so traversal of the IPv6 network is unnecessary. Are you saying that providers will tend to arrange things this way? "The mAFTR should process the received PIMv6 Join message for the IPv4-embedded IPv6 group and send the corresponding IPv4 PIM Join message. It creates an entry for the IPv6 multicast group address in its multicast Routing Information Base. This entry is used to forward ..." Section 4.5 It is not clear whether the final paragraph is talking about the mB4+B4 or the mAFTR+AFTR or both. In fact, it makes good sense to combine the mB4 and the B4, but combining the AFTR and mAFTR would be questionable for reasons of scalability. Jacni>: We don't see the problems so far. [TT] OK, taking out the opinion part, here is the comment: is that last paragraph talking about combining the mB4 and B4, the mAFTR and AFTR, or both possibilities? The text should make clear what we intend. There may be routing issues to sort out regarding reachability of the IPv4 prefix that is shared by the source -- the multicast routers should choose the path leading through the mAFTR rather than the one going through the AFTR. Jacni>: Sorry, I don't understand the ".. IPv4 prefix that is shared by the source.." For multicast routing, multicast routers including mAFTR will deal with that based on converged unicast routing. You can learn more about it in the following sections. [TT] Well, this was a side issue, but are extra administrative arrangements needed to ensure that multicast signalling knows to go through the mAFTR rather than AFTR to reach the source, if both routers advertise reachability to the same IPv4 prefix? No more comments up to section 7. Maybe more comments from section 7 onwards in a separate E-mail. Jacni>: Thank again for your comments. Cheers, Jacni Regards, Tina _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --Boundary_(ID_BgwBklIBz1/o3vJwpk98rA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Jacni,

Thank you for your prompt reply, which shows you ar= e a very good engineer and coauthor.

 

You are too close to your text. You know what you w= ant to say, but it doesn't necessarily say that to other people. A few of the observations below are of that nature.

 

Detailed replies below, marked with [TT].

 

 

Best Regards,

Tina TSOU

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

 

 

From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: Tuesday, August 23, 2011 7:32 AM
To: Tina TSOU
Cc: softwires@ietf.org
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multi= cast-04

 

Thanks for the comments, = inline please.

On Tue, Aug 23, 2011 at 9:58 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com= > wrote:

Hi all,
In IETF-81, the chairs asked the authors of different drafts on multicast s= it together to discuss and compromise. So we did.

Here are some comments on draft-qin-softwire-dslite-multicast-04.

Overall: if this is to be a Standards Track document, the whole document has to be reviewed, the normative parts identified, and requirements
language substituted for the current descriptive language.

Jacni>: I don't see it, while you can post comme= nts.

[TT] Where are the MUS= Ts, SHOULDs, and MAYs that have to be satisfied for interoperability? Every= thing is "will" or "should". 

 

 

Section 1:

Editorial: at the end of the second paragraph, "vastly consumed" = reads
better in English as: "consumed in vast quantities".

Jacni>: Sorry, EN is not my first language. = ;Maybe we need the help from a native guy.

[TT] I'll get one to confirm this.

 

Substantive: add the = following to the sentence making up the third
paragraph:

"..., which prevents these consequences by making use of the native multicast capabilities of the intervening IPv6 network."

Jacni>: No objection to add a sentence, but modified = as "which preserves the efficiency of using multicast for traffics for= warding."

[TT] Why not the more specific statement? BTW, the = word in English is "traffic". not "traffics".

 

Section 2:

Terminology: "Multicast AFTR" has connotations (IPv4 NAT) that si= mply
aren't there. Suggestion: "Multicast Transitional Border Gateway (mTBG= )".

Jacni>: I think the AFTR is a general item,= see the similar comments raised

in another thread about 4rd.

 

Substantive(?): In th= e description of the Multicast B4, it would make
more sense to change "... which is able to enforce ..." to "= ... which
implements ...".

Section 3.2:

Bullet 1: the second sentence jams two unrelated ideas together. It
needs a little expansion to read properly. The next sentence doesn't
make sense within the stated scope of the bullet and shouldn't be there. The suggested changed text is thus:

Jacni>: Sorry, I don't agree. I think = text in the paragraph following the bullet

explains the scope= clearly.

[TT] The sentence that the text below omits reads a= s follows:

 

"While since technically, there is no extra fu= nction

    required for the scenario of native acc= ess (i.e. to access dual-stack

    content natively from the IPv6 receiver= ), this portion is not taken

    into account."

 

The title of the use case is: "An IPv4 receive= r accessing IPv4 content (i.e., content formatted and reachable in IPv4)&qu= ot;

 

So what does an IPv6 receiver have to do with this?= And getting content from the receiver? The whole sentence just doesn't make sense.

 

  "A viable= scenario for this use case in DS-Lite environment: customers
   with legacy receivers must continue to access the IPv4-enabled=
   multicast services.  This means the traffic should be acc= essed
   through IPv4 and additional functions are needed to traverse t= he
   operator's IPv6- enabled network. It is the purpose of this    document to describe those functions.  Refer to [I-D.jacl= ee-behave-
   v4v6-mcast-ps] for the deployment considerations."

Final paragraph: don't you need a final sentence saying something like:
"Depending on the specific details of the contract, this may mean that=
the specific framing of the content packets (as IPv4 packets) must be
preserved along with the content within that framing."

Jacni>:That's what the current text means.

[TT] No, it just makes= a case for it. We have to draw the conclusion, not leave it to the reader.=  

 

Section 4:

First paragraph: the following sentences need to be added after the
first one to give a full picture of what is required for a solution:

"For multicast, in contrast, separate mechanisms are required to proce= ss
the outgoing multicast signalling packets and the incoming packets of
content. The multicast signalling needs to be interworked to IPv6 and
processed as IPv6 signalling. For incoming multicast content, this
document defines ..."

 

Jacni>: The signalling things will be detailed in the= signalling section.

This is just a general description here.

[TT] The general descr= iption has to be general, not just focus on the handling of the multicast c= ontent. 


Middle paragraph: why doesn't it simply read:

"See Section 4.3 for multicast distribution tree establishment and
Section 4.4 for multicast traffic forwarding."

Section 4.2

Third paragraph typo: mPrefixe64 -> mPrefix64

Jacni>: Oops, got it, thank you.

 


Section 4.3

Bullets: it makes no sense to embed the mAFTR in the MLD Querier. That
would cause the native IPv6 multicast infrastructure to be bypassed. It
is also inconsistent with the architectural figure. Delete the first
bullet and merge the second one with the next paragraph, like this:

Jacni>: Actually, this is one of the typical cas= es.

The mAFTR can be embedded in the MLD Querier, which will=

not bapass the IPv6 multicast infrastructure.

[TT] The only way I ca= n see that is if the MLD Querier happens to have a link directly to th= e target IPv4 network, so traversal of the IPv6 network is unnecessary. Are= you saying that providers will tend to arrange things this way?&nbs= p;


"The mAFTR should process the received PIMv6 Join message for the
IPv4-embedded IPv6 group and send the corresponding IPv4 PIM Join
message. It creates an entry for the IPv6 multicast group address in its multicast Routing Information Base. This entry is used to forward ..."=

Section 4.5

It is not clear whether the final paragraph is talking about the mB4+B4=
or the mAFTR+AFTR or both. In fact, it makes good sense to combine the<= br> mB4 and the B4, but combining the AFTR and mAFTR would be questionable
for reasons of scalability.

 

Jacni>: We don't see the problems so far.=

[TT] OK, taking out th= e opinion part, here is the comment: is that last paragraph talking about c= ombining the mB4 and B4, the mAFTR and AFTR, or both possibilities? The te= xt should make clear what we intend.

 

There may be routing issues to sort out
regarding reachability of the IPv4 prefix that is shared by the source
-- the multicast routers should choose the path leading through the
mAFTR rather than the one going through the AFTR.

 

Jacni>: Sorry, I don't understand the ".. IPv4 p= refix that is shared by the source.."

For multicast routing, multicast routers including mAFTR= will deal with that based on

converged unicast routing.

You can learn more about it in the following sections.

[TT] Well, this was a side issue, but are extra administr= ative arrangements needed to ensure that multicast signalling knows to go through the mAFTR rather than AFTR to reach the source, if both routers advertis= e reachability to the same IPv4 prefix?

 


No more comments up to section 7. Maybe more comments from section 7
onwards in a separate E-mail.

Jacni>: Thank again for your comments.

 

 

Cheers,

Jacni

 


Regards,
Tina
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

 

--Boundary_(ID_BgwBklIBz1/o3vJwpk98rA)-- From Tina.Tsou.Zouting@huawei.com Tue Aug 23 15:45:17 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 5781121F8BBD for ; Tue, 23 Aug 2011 15:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[AWL=0.473, 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 w4FMWPIoIDBf for ; Tue, 23 Aug 2011 15:45:16 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4C33921F8BB3 for ; Tue, 23 Aug 2011 15:45:16 -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 <0LQE00GKDKLBKU@szxga05-in.huawei.com> for multrans@ietf.org; Wed, 24 Aug 2011 06:46:23 +0800 (CST) Received: from szxrg02-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 <0LQE00CA5KLAK3@szxga05-in.huawei.com> for multrans@ietf.org; Wed, 24 Aug 2011 06:46:23 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADJ63008; Wed, 24 Aug 2011 06:46:22 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 24 Aug 2011 06:46:17 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Wed, 24 Aug 2011 06:46:20 +0800 Date: Tue, 23 Aug 2011 22:46:20 +0000 From: Tina TSOU In-reply-to: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D94@GRFMBX704BA020.griffon.local> X-Originating-IP: [10.193.34.145] To: Maglione Roberta , "'Lee, Yiu'" 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] Clarification question about Problem Statement and Use Cases draft Thread-index: AcxhaRlrFggMTacCSO21470vfvxz1wAIl/eAAAhXTLD//77qAIAANdVg//+CoLA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D91@GRFMBX704BA020.griffon.local> <78E58E38-F5AC-4A1C-BD16-A11BF9633203@Cable.Comcast.com> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D92@GRFMBX704BA020.griffon.local> <379B24BA-08AB-45A4-BD97-311A91225B04@Cable.Comcast.com> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D94@GRFMBX704BA020.griffon.local> Cc: "multrans@ietf.org" , Ullio Mario Subject: Re: [multrans] Clarification question about Problem Statement and Use Cases draft 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: Tue, 23 Aug 2011 22:45:17 -0000 Roberta, I agreed with you. P.s. Hope colleagues in US East Coast are safe now. It is reported a 5.9 le= vel earthquake happened. Best Regards, Tina TSOU -----Original Message----- From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] On Behal= f Of Maglione Roberta Sent: Tuesday, August 23, 2011 1:55 AM To: 'Lee, Yiu' Cc: multrans@ietf.org; Ullio Mario Subject: Re: [multrans] Clarification question about Problem Statement and = Use Cases draft Hi Yiu, Thanks for your reply. It would be good to include this use case in the draft. As far as priority, I'm not sure about how the group interprets the terms "= high" and "low", but in I would give to this scenario the same ranking you = put for 4-6-4 e.g. DSLite. Best regards, Roberta -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Sent: marted=EC 23 agosto 2011 10.01 To: Maglione Roberta Cc: multrans@ietf.org; Ullio Mario Subject: Re: [multrans] Clarification question about Problem Statement and = Use Cases draft Hi Roberta, We did think about it. For the PS and usecase, we can include this. To prioritize the work, do you see this high priority to address? Thanks, Yiu On Aug 23, 2011, at 3:57 AM, "Maglione Roberta" wrote: > Hi Yiu, > Yes, correct. > Thanks > Roberta > > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Sent: marted=EC 23 agosto 2011 9.55 > To: Maglione Roberta > Cc: multrans@ietf.org; Ullio Mario > Subject: Re: [multrans] Clarification question about Problem > Statement and Use Cases draft > > Hi Roberta, > > So you refer to S6-N4-R6 case? > > Regards, > Yiu > > > > On Aug 23, 2011, at 3:48 AM, "Maglione Roberta" > wrote: > >> In my opinion "IPv6 Receiver and Source Connected to an IPv4-Only >> Network" use case could also cover the scenario where both receivers >> and source are IPv6 and they get IPv6 unicast connectivity from an >> IPv4 network by using 6PE solution (for unicast traffic). >> If I am not wrong this use case does not belong to behave >> discussion, but I believe that having a multicast equivalent >> solution for 6PE may be useful for a Service Provider that would >> like to start offering IPv6 multicast keeping his own backbone >> network in IPv4. >> >> I would appreciate your comments. >> Thanks, >> Best regards, >> Roberta >> >> >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente >> alle persone indicate. La diffusione, copia o qualsiasi altra azione >> derivante dalla conoscenza di queste informazioni sono rigorosamente >> vietate. Qualora abbiate ricevuto questo documento per errore siete >> cortesemente pregati di darne immediata comunicazione al mittente e >> di provvedere alla sua distruzione, Grazie. >> >> This e-mail and any attachments is confidential and may contain >> privileged information intended for the addressee(s) only. >> Dissemination, copying, printing or use by anybody else is >> unauthorised. If you are not the intended recipient, please delete >> this message and any attachments and advise the sender by return e- >> mail, Thanks. >> >> _______________________________________________ >> multrans mailing list >> multrans@ietf.org >> https://www.ietf.org/mailman/listinfo/multrans > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e > di provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. > Dissemination, copying, printing or use by anybody else is > unauthorised. If you are not the intended recipient, please delete > this message and any attachments and advise the sender by return e- > mail, Thanks. > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. _______________________________________________ multrans mailing list multrans@ietf.org https://www.ietf.org/mailman/listinfo/multrans From yiu_lee@cable.comcast.com Tue Aug 23 16:24:22 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 8545D21F8C75 for ; Tue, 23 Aug 2011 16:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=1.971, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, 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 1DSY6zcq8yiQ for ; Tue, 23 Aug 2011 16:24:21 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9DD21F8C66 for ; Tue, 23 Aug 2011 16:24:21 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.138037611; Tue, 23 Aug 2011 19:25:28 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Tue, 23 Aug 2011 19:25:28 -0400 From: "Lee, Yiu" To: "multrans@ietf.org" Thread-Topic: [multrans] Clarification question about Problem Statement and Use Cases draft Thread-Index: AQHMYevwDWlwaCF3oU6iPZKQo/kPww== Date: Tue, 23 Aug 2011 23:25:25 +0000 Message-ID: In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D94@GRFMBX704BA020.griffon.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <59D17FD9DF1AED4D9CA78B5DED727951@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multrans] Clarification question about Problem Statement and Use Cases draft 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: Tue, 23 Aug 2011 23:24:22 -0000 Sure. We can include the use case in next revision. On 8/23/11 4:55 AM, "Maglione Roberta" wrote: >Hi Yiu, > Thanks for your reply. >It would be good to include this use case in the draft. >As far as priority, I'm not sure about how the group interprets the terms >"high" and "low", but in I would give to this scenario the same ranking >you put for 4-6-4 e.g. DSLite. > >Best regards, >Roberta > > >-----Original Message----- >From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] >Sent: marted=EC 23 agosto 2011 10.01 >To: Maglione Roberta >Cc: multrans@ietf.org; Ullio Mario >Subject: Re: [multrans] Clarification question about Problem Statement >and Use Cases draft > >Hi Roberta, > >We did think about it. For the PS and usecase, we can include this. To >prioritize the work, do you see this high priority to address? > >Thanks, >Yiu > > > >On Aug 23, 2011, at 3:57 AM, "Maglione Roberta" > > wrote: > >> Hi Yiu, >> Yes, correct. >> Thanks >> Roberta >> >> -----Original Message----- >> From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] >> Sent: marted=EC 23 agosto 2011 9.55 >> To: Maglione Roberta >> Cc: multrans@ietf.org; Ullio Mario >> Subject: Re: [multrans] Clarification question about Problem >> Statement and Use Cases draft >> >> Hi Roberta, >> >> So you refer to S6-N4-R6 case? >> >> Regards, >> Yiu >> >> >> >> On Aug 23, 2011, at 3:48 AM, "Maglione Roberta" >>>> wrote: >> >>> In my opinion "IPv6 Receiver and Source Connected to an IPv4-Only >>> Network" use case could also cover the scenario where both receivers >>> and source are IPv6 and they get IPv6 unicast connectivity from an >>> IPv4 network by using 6PE solution (for unicast traffic). >>> If I am not wrong this use case does not belong to behave >>> discussion, but I believe that having a multicast equivalent >>> solution for 6PE may be useful for a Service Provider that would >>> like to start offering IPv6 multicast keeping his own backbone >>> network in IPv4. >>> >>> I would appreciate your comments. >>> Thanks, >>> Best regards, >>> Roberta >>> >>> >>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente >>> alle persone indicate. La diffusione, copia o qualsiasi altra azione >>> derivante dalla conoscenza di queste informazioni sono rigorosamente >>> vietate. Qualora abbiate ricevuto questo documento per errore siete >>> cortesemente pregati di darne immediata comunicazione al mittente e >>> di provvedere alla sua distruzione, Grazie. >>> >>> This e-mail and any attachments is confidential and may contain >>> privileged information intended for the addressee(s) only. >>> Dissemination, copying, printing or use by anybody else is >>> unauthorised. If you are not the intended recipient, please delete >>> this message and any attachments and advise the sender by return e- >>> mail, Thanks. >>> >>> _______________________________________________ >>> multrans mailing list >>> multrans@ietf.org >>> https://www.ietf.org/mailman/listinfo/multrans >> >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente >> alle persone indicate. La diffusione, copia o qualsiasi altra azione >> derivante dalla conoscenza di queste informazioni sono rigorosamente >> vietate. Qualora abbiate ricevuto questo documento per errore siete >> cortesemente pregati di darne immediata comunicazione al mittente e >> di provvedere alla sua distruzione, Grazie. >> >> This e-mail and any attachments is confidential and may contain >> privileged information intended for the addressee(s) only. >> Dissemination, copying, printing or use by anybody else is >> unauthorised. If you are not the intended recipient, please delete >> this message and any attachments and advise the sender by return e- >> mail, Thanks. >> > >Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >persone indicate. La diffusione, copia o qualsiasi altra azione derivante >dalla conoscenza di queste informazioni sono rigorosamente vietate. >Qualora abbiate ricevuto questo documento per errore siete cortesemente >pregati di darne immediata comunicazione al mittente e di provvedere alla >sua distruzione, Grazie. > >This e-mail and any attachments is confidential and may contain >privileged information intended for the addressee(s) only. Dissemination, >copying, printing or use by anybody else is unauthorised. If you are not >the intended recipient, please delete this message and any attachments >and advise the sender by return e-mail, Thanks. > From gjshep@gmail.com Wed Aug 24 08:05: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 01A1F21F8BE8 for ; Wed, 24 Aug 2011 08:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.901 X-Spam-Level: X-Spam-Status: No, score=-103.901 tagged_above=-999 required=5 tests=[AWL=-0.302, 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 dg33fYbS2mrt for ; Wed, 24 Aug 2011 08:05:34 -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 D3AF721F8BE5 for ; Wed, 24 Aug 2011 08:05:33 -0700 (PDT) Received: by bkar4 with SMTP id r4so1152451bka.31 for ; Wed, 24 Aug 2011 08:06:41 -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=t2O/eMLvnD02ZhUkcweFxhXC50x3ZBk6KNw2Au2h81w=; b=RRwv8NXxhS9Oll0sbEgk4kMTdg7+COHjZPd//bvcKg5FktoZ/55ofozxmp6/H8nkbq NGzcuT5z+TV8RD24o9mfwfSIVYyWPKgjVBuh1iGZ9z07OdfX8bCyhgfzTfRcapZdtBc0 HFivr9h2ouJ2WCCdR1uc/lHvmkoY0EjCFYt6o= MIME-Version: 1.0 Received: by 10.204.156.82 with SMTP id v18mr2277525bkw.362.1314198401560; Wed, 24 Aug 2011 08:06:41 -0700 (PDT) Received: by 10.204.135.142 with HTTP; Wed, 24 Aug 2011 08:06:41 -0700 (PDT) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D94@GRFMBX704BA020.griffon.local> Date: Wed, 24 Aug 2011 08:06:41 -0700 Message-ID: From: Greg Shepherd To: "Lee, Yiu" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multrans@ietf.org" Subject: Re: [multrans] Clarification question about Problem Statement and Use Cases draft 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, 24 Aug 2011 15:05:35 -0000 It's best if we can clearly define use cases on the list before any revisio= ns. Thanks Greg On Tue, Aug 23, 2011 at 4:25 PM, Lee, Yiu wrote= : > Sure. We can include the use case in next revision. > > On 8/23/11 4:55 AM, "Maglione Roberta" > wrote: > >>Hi Yiu, >> =A0 Thanks for your reply. >>It would be good to include this use case in the draft. >>As far as priority, I'm not sure about how the group interprets the terms >>"high" and "low", but in I would give to this scenario the same ranking >>you put for 4-6-4 e.g. DSLite. >> >>Best regards, >>Roberta >> >> >>-----Original Message----- >>From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] >>Sent: marted=EC 23 agosto 2011 10.01 >>To: Maglione Roberta >>Cc: multrans@ietf.org; Ullio Mario >>Subject: Re: [multrans] Clarification question about Problem Statement >>and Use Cases draft >> >>Hi Roberta, >> >>We did think about it. For the PS and usecase, we can include this. To >>prioritize the work, do you see this high priority to address? >> >>Thanks, >>Yiu >> >> >> >>On Aug 23, 2011, at 3:57 AM, "Maglione Roberta" >>> > wrote: >> >>> Hi Yiu, >>> Yes, correct. >>> Thanks >>> Roberta >>> >>> -----Original Message----- >>> From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] >>> Sent: marted=EC 23 agosto 2011 9.55 >>> To: Maglione Roberta >>> Cc: multrans@ietf.org; Ullio Mario >>> Subject: Re: [multrans] Clarification question about Problem >>> Statement and Use Cases draft >>> >>> Hi Roberta, >>> >>> So you refer to S6-N4-R6 case? >>> >>> Regards, >>> Yiu >>> >>> >>> >>> On Aug 23, 2011, at 3:48 AM, "Maglione Roberta" >>>>>> wrote: >>> >>>> In my opinion "IPv6 Receiver and Source Connected to an IPv4-Only >>>> Network" use case could also cover the scenario where both receivers >>>> and source are IPv6 and they get IPv6 unicast connectivity from an >>>> IPv4 network by using 6PE solution (for unicast traffic). >>>> If I am not wrong this use case does not belong to behave >>>> discussion, but I believe that having a multicast equivalent >>>> solution for 6PE may be useful for a Service Provider that would >>>> like to start offering IPv6 multicast keeping his own backbone >>>> network in IPv4. >>>> >>>> I would appreciate your comments. >>>> Thanks, >>>> Best regards, >>>> Roberta >>>> >>>> >>>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente >>>> alle persone indicate. La diffusione, copia o qualsiasi altra azione >>>> derivante dalla conoscenza di queste informazioni sono rigorosamente >>>> vietate. Qualora abbiate ricevuto questo documento per errore siete >>>> cortesemente pregati di darne immediata comunicazione al mittente e >>>> di provvedere alla sua distruzione, Grazie. >>>> >>>> This e-mail and any attachments is confidential and may contain >>>> privileged information intended for the addressee(s) only. >>>> Dissemination, copying, printing or use by anybody else is >>>> unauthorised. If you are not the intended recipient, please delete >>>> this message and any attachments and advise the sender by return e- >>>> mail, Thanks. >>>> >>>> _______________________________________________ >>>> multrans mailing list >>>> multrans@ietf.org >>>> https://www.ietf.org/mailman/listinfo/multrans >>> >>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente >>> alle persone indicate. La diffusione, copia o qualsiasi altra azione >>> derivante dalla conoscenza di queste informazioni sono rigorosamente >>> vietate. Qualora abbiate ricevuto questo documento per errore siete >>> cortesemente pregati di darne immediata comunicazione al mittente e >>> di provvedere alla sua distruzione, Grazie. >>> >>> This e-mail and any attachments is confidential and may contain >>> privileged information intended for the addressee(s) only. >>> Dissemination, copying, printing or use by anybody else is >>> unauthorised. If you are not the intended recipient, please delete >>> this message and any attachments and advise the sender by return e- >>> mail, Thanks. >>> >> >>Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >>persone indicate. La diffusione, copia o qualsiasi altra azione derivante >>dalla conoscenza di queste informazioni sono rigorosamente vietate. >>Qualora abbiate ricevuto questo documento per errore siete cortesemente >>pregati di darne immediata comunicazione al mittente e di provvedere alla >>sua distruzione, Grazie. >> >>This e-mail and any attachments is confidential and may contain >>privileged information intended for the addressee(s) only. Dissemination, >>copying, printing or use by anybody else is unauthorised. If you are not >>the intended recipient, please delete this message and any attachments >>and advise the sender by return e-mail, Thanks. >> > > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans > From Tina.Tsou.Zouting@huawei.com Wed Aug 24 20:06:06 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 9BCDE21F88A0 for ; Wed, 24 Aug 2011 20:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 7jwfBbqlISxo for ; Wed, 24 Aug 2011 20:06:06 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id D3B9F21F886D for ; Wed, 24 Aug 2011 20:06:05 -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 <0LQG0012YRC3O4@szxga03-in.huawei.com> for multrans@ietf.org; Thu, 25 Aug 2011 11:07:15 +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 <0LQG00AENRC3R6@szxga03-in.huawei.com> for multrans@ietf.org; Thu, 25 Aug 2011 11:07:15 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADK33779; Thu, 25 Aug 2011 11:07:15 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 25 Aug 2011 11:07:11 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Thu, 25 Aug 2011 11:07:13 +0800 Date: Thu, 25 Aug 2011 03:07:12 +0000 From: Tina TSOU X-Originating-IP: [10.193.34.145] To: "multrans@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Use Cases For Multicast Transition From IPv4 to IPv6: draft-tsou-multrans-use-cases Thread-index: Acxi1BaYo6QQdnVdRL2MD7isZroNsQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [multrans] Use Cases For Multicast Transition From IPv4 to IPv6: draft-tsou-multrans-use-cases 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, 25 Aug 2011 03:06:06 -0000 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 bashing. 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 From Tina.Tsou.Zouting@huawei.com Wed Aug 24 20:10:22 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 99A0E21F8C04 for ; Wed, 24 Aug 2011 20:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.916 X-Spam-Level: X-Spam-Status: No, score=-5.916 tagged_above=-999 required=5 tests=[AWL=0.083, 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 Dfem13INKghi for ; Wed, 24 Aug 2011 20:10:22 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id C96DC21F8BBF for ; Wed, 24 Aug 2011 20:10:21 -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 <0LQG00MR9RIQBV@szxga03-in.huawei.com> for multrans@ietf.org; Thu, 25 Aug 2011 11:11:14 +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 <0LQG001WLRIQ9P@szxga03-in.huawei.com> for multrans@ietf.org; Thu, 25 Aug 2011 11:11:14 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADK34223; Thu, 25 Aug 2011 11:11:13 +0800 (CST) Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 25 Aug 2011 11:11:08 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.177]) by szxeml409-hub.china.huawei.com ([169.254.89.141]) with mapi id 14.01.0270.001; Thu, 25 Aug 2011 11:11:13 +0800 Date: Thu, 25 Aug 2011 03:11:11 +0000 From: Tina TSOU X-Originating-IP: [10.193.34.145] To: "multrans@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Draft Multrans 2nd BoF request Thread-index: Acxi1KTRF0FMQ8rrQGS+7rlSCBaqgA== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: 3Ls= ADLY ALBz AmMJ BSdY EBdu EcEt FrNm GIC3 GnCy G19L H9S2 IKS5 Iou0 I8J0 JHKC; 1; bQB1AGwAdAByAGEAbgBzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {D7F401B8-829D-42A5-9AD7-AE026CAE0CEF}; dABpAG4AYQAuAHQAcwBvAHUALgB6AG8AdQB0AGkAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 25 Aug 2011 03:11:12 GMT; RAByAGEAZgB0ACAATQB1AGwAdAByAGEAbgBzACAAMgBuAGQAIABCAG8ARgAgAHIAZQBxAHUAZQBzAHQA x-cr-puzzleid: {D7F401B8-829D-42A5-9AD7-AE026CAE0CEF} X-CFilter-Loop: Reflected Subject: [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, 25 Aug 2011 03:10:22 -0000 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 From dwing@cisco.com Thu Aug 25 09:11:53 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 C9D7921F855F for ; Thu, 25 Aug 2011 09:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.098 X-Spam-Level: X-Spam-Status: No, score=-103.098 tagged_above=-999 required=5 tests=[AWL=-1.099, BAYES_00=-2.599, 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 ZpeH3X9V-3Qw for ; Thu, 25 Aug 2011 09:11:53 -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 1F3D421F84E4 for ; Thu, 25 Aug 2011 09:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2787; q=dns/txt; s=iport; t=1314288787; x=1315498387; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=McIpP9AWfFx7RLR6ooA9aqVIHlCUUjy9vt+9ouXuvUs=; b=j0KVTLBaaFt+pYWBiX7iVye3RPznjEmfP50oDSOVY0m3k8gtlWrarRdi ln3blCd1qE1Mbr6/nn3iJzfZgbjixbhLiYkpgflexM6Bp+WAoUJotHJtm qxk6pC3oV7JqGy8n5afYUZ2ACdbte8JBT1jIjSpcMYwX3GlQopcIRe9YV c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8AALVzVk6rRDoI/2dsb2JhbABCmCqBbI1sd4FAAQEBAQIBAQEBBQoBFxA0EAcBAwIJDwIEAQEOGgcZDhUKCQgBAQQBEgsXh1AEnAABnw+GTASHYZxT X-IronPort-AV: E=Sophos;i="4.68,281,1312156800"; d="scan'208";a="16473652" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-6.cisco.com with ESMTP; 25 Aug 2011 16:13:06 +0000 Received: from dwingWS (sjc-vpn6-1523.cisco.com [10.21.125.243]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7PGD5ow031574; Thu, 25 Aug 2011 16:13:06 GMT From: "Dan Wing" To: "'Tina TSOU'" , References: In-Reply-To: Date: Thu, 25 Aug 2011 09:13:05 -0700 Message-ID: <016401cc6341$df854920$9e8fdb60$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acxi1KTRF0FMQ8rrQGS+7rlSCBaqgAAbRTAQ Content-Language: en-us 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, 25 Aug 2011 16:11:53 -0000 > -----Original Message----- > From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] On > Behalf Of Tina TSOU > Sent: Wednesday, August 24, 2011 8:11 PM > To: multrans@ietf.org > Subject: [multrans] Draft Multrans 2nd BoF request > > 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 Please include BEHAVE in the conflict list. -d > 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