From roberta.maglione@telecomitalia.it Tue Nov 1 10: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 B80B711E8094 for ; Tue, 1 Nov 2011 10:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=0.256, 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 fy7hNIoDCtjo for ; Tue, 1 Nov 2011 10:26:01 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id E2FA321F8D8A for ; Tue, 1 Nov 2011 10:26:00 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 1 Nov 2011 18:24:02 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Tue, 1 Nov 2011 18:24:01 +0100 From: Maglione Roberta To: Tina TSOU , "multrans@ietf.org" Date: Tue, 1 Nov 2011 18:20:47 +0100 Thread-Topic: Update of Multrans Problem Statement and Use Case draft Thread-Index: AQHMmAUNjJb88rY39k25ujOJwT530ZWW2+xwgAFpOm8= Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C83@GRFMBX704BA020.griffon.local> References: In-Reply-To: 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 Subject: Re: [multrans] Update of Multrans Problem Statement and Use Case 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, 01 Nov 2011 17:26:01 -0000 Hello Tina, in this version of the document it seems to be missing the 6-4-6 Network= Scenario where both the receivers and the source are IPv6 capable, but the IPv6 connectivity among them is provided over an IPv4-Only Network running Multiprotocol Label Switching (MPLS). We discussed this scenario on list some weeks ago, I was wondering why you = did not include it in the document. Best Regards Roberta ________________________________________ From: multrans-bounces@ietf.org [multrans-bounces@ietf.org] On Behalf Of Ti= na TSOU [Tina.Tsou.Zouting@huawei.com] Sent: Monday, October 31, 2011 8:49 PM To: multrans@ietf.org Subject: [multrans] Update of Multrans Problem Statement and Use Case draft Dear all, Version -03 of the Multrans Problem Statement and Use Case draft has been submitted. By agreement amongst the authors, the diagrams and updated descriptions from draft-tsou-multrans-use-cases-00 have been absorbed into the problem statement and use case draft. https://datatracker.ietf.org/doc/draft-jaclee-behave-v4v6-mcast-ps/ now presents the following use cases, all within the agreed context of IPTV: 1. IPv4 Receiver and Source Connected to an IPv6-Only Network (4-6-4) 2. IPv6 Receiver Connected to an IPv4 Source Through an IPv4 Multicast-Incapable Access Network and an IPv6 Multicast-Capable Network (6-4-6-4) 3. IPv6 Receiver and Source Connected to an IPv4-Only Network (6-4-6) 4. IPv6 Receiver and IPv4 Source (6-4) 5. IPv4 Receiver and IPv6 Source (4-6) The diagrams and accompanying text show a potential solution to the problem of differing IP versions through the use of nodes embodying "adaptation functions". The Multrans BoF was negotiated on the basis of solutions where these adaptation functions consisted of application layer gateways (ALGs). Comments on this assumption and how it should work are invited. B. R. Tina +1-408-859-4996 _______________________________________________ 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 Nov 1 10:33: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 B9F3B21F99F4 for ; Tue, 1 Nov 2011 10:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynU7O18rgwjg for ; Tue, 1 Nov 2011 10:33:58 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1743321F99F1 for ; Tue, 1 Nov 2011 10:33:58 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.59634068; Tue, 01 Nov 2011 11:40:15 -0600 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.0339.001; Tue, 1 Nov 2011 13:32:20 -0400 From: "Lee, Yiu" To: Maglione Roberta , Tina TSOU , "multrans@ietf.org" Thread-Topic: [multrans] Update of Multrans Problem Statement and Use Case draft Thread-Index: AQHMmLw02tImPGYa6UaIoA84/LJC0g== Date: Tue, 1 Nov 2011 17:32:19 +0000 Message-ID: In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C83@GRFMBX704BA020.griffon.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [147.191.125.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <2022630DB41A67499A7FDA8320E2D66B@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multrans] Update of Multrans Problem Statement and Use Case 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, 01 Nov 2011 17:33:58 -0000 Hi Roberta, We describe 6-4-6 in Section 3.3. This is very generic scenario and does not mention MPLS in the IPv4 networks. IMHO, MPLS would create an abstraction which makes the underneath network irrelevant. Do you suggest we need to describe 6-MPLS-6? B.R., Yiu On 11/1/11 1:20 PM, "Maglione Roberta" wrote: >Hello Tina, > in this version of the document it seems to be missing the 6-4-6 >Network Scenario where both the receivers and > the source are IPv6 capable, but the IPv6 connectivity among them is > provided over an IPv4-Only Network running Multiprotocol Label > Switching (MPLS). >We discussed this scenario on list some weeks ago, I was wondering why >you did not include it in the document. > >Best Regards >Roberta >________________________________________ >From: multrans-bounces@ietf.org [multrans-bounces@ietf.org] On Behalf Of >Tina TSOU [Tina.Tsou.Zouting@huawei.com] >Sent: Monday, October 31, 2011 8:49 PM >To: multrans@ietf.org >Subject: [multrans] Update of Multrans Problem Statement and Use Case >draft > >Dear all, >Version -03 of the Multrans Problem Statement and Use Case draft has >been submitted. By agreement amongst the authors, the diagrams and >updated descriptions from draft-tsou-multrans-use-cases-00 have been >absorbed into the problem statement and use case draft. > >https://datatracker.ietf.org/doc/draft-jaclee-behave-v4v6-mcast-ps/ now >presents the following use cases, all within the agreed context of IPTV: > >1. IPv4 Receiver and Source Connected to an IPv6-Only Network (4-6-4) > >2. IPv6 Receiver Connected to an IPv4 Source Through an IPv4 >Multicast-Incapable Access Network and an IPv6 Multicast-Capable Network >(6-4-6-4) > >3. IPv6 Receiver and Source Connected to an IPv4-Only Network (6-4-6) > >4. IPv6 Receiver and IPv4 Source (6-4) > >5. IPv4 Receiver and IPv6 Source (4-6) > >The diagrams and accompanying text show a potential solution to the >problem of differing IP versions through the use of nodes embodying >"adaptation functions". The Multrans BoF was negotiated on the basis of >solutions where these adaptation functions consisted of application >layer gateways (ALGs). Comments on this assumption and how it should >work are invited. > > > >B. R. >Tina >+1-408-859-4996 >_______________________________________________ >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. > >_______________________________________________ >multrans mailing list >multrans@ietf.org >https://www.ietf.org/mailman/listinfo/multrans From roberta.maglione@telecomitalia.it Tue Nov 1 11:13:15 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 94B251F0CBA for ; Tue, 1 Nov 2011 11:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.481 X-Spam-Level: X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[AWL=0.238, 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 gvg5+302JIjo for ; Tue, 1 Nov 2011 11:13:15 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1E41F0CA1 for ; Tue, 1 Nov 2011 11:13:14 -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, 1 Nov 2011 18:50:03 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Tue, 1 Nov 2011 18:50:02 +0100 From: Maglione Roberta To: "'Lee, Yiu'" , Tina TSOU , "multrans@ietf.org" Date: Tue, 1 Nov 2011 18:50:02 +0100 Thread-Topic: [multrans] Update of Multrans Problem Statement and Use Case draft Thread-Index: AQHMmLw02tImPGYa6UaIoA84/LJC0pWYSjQw Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB758B7F9@GRFMBX704BA020.griffon.local> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C83@GRFMBX704BA020.griffon.local> In-Reply-To: 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 Subject: Re: [multrans] Update of Multrans Problem Statement and Use Case 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, 01 Nov 2011 18:13:15 -0000 Hi Yiu, I saw you mentioned 6-4-6 in Section 3.3 in a generic way, however the rea= son why I believe IPv4 network with IP/MPLS is a particular case is because= for unicast there is a specific solution (6PE) for the 6-4-6 with MPLS in = the IPv4 network. For multicast at the moment there is no equivalent for 6P= E. Please see the text below, I proposed some time ago on the list for this sc= enario: RFC 4798 tackles the unicast angle of the problem and it explains how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud by using Multiprotocol Border Gateway Protocol (MP-BGP) to exchange the IPv6 reachability information transparently. The devices implementing this mechanism are called IPv6 Provider Edge routers (6PE). The 6PE technique is currently deployed for unicast traffic in several Service Provider's networks. A similar approach would be useful for multicast services too, in order to allow the Service Providers to start offering IPv6 multicast contents (from its own multicast sources or provided by external Content Providers) to new IPv6 customers. This mechanism would allow the Service Providers to replicate for multicast contents, the same architectural model currently deployed for unicast traffic with 6PE method. In addition as this model does not require any translation or interworking function it is expected it would be able to preserve the service quality and the integrity of contents. Thanks Best regards, Roberta -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Sent: marted=EC 1 novembre 2011 18.32 To: Maglione Roberta; Tina TSOU; multrans@ietf.org Subject: Re: [multrans] Update of Multrans Problem Statement and Use Case d= raft Hi Roberta, We describe 6-4-6 in Section 3.3. This is very generic scenario and does not mention MPLS in the IPv4 networks. IMHO, MPLS would create an abstraction which makes the underneath network irrelevant. Do you suggest we need to describe 6-MPLS-6? B.R., Yiu On 11/1/11 1:20 PM, "Maglione Roberta" wrote: >Hello Tina, > in this version of the document it seems to be missing the 6-4-6 >Network Scenario where both the receivers and > the source are IPv6 capable, but the IPv6 connectivity among them is > provided over an IPv4-Only Network running Multiprotocol Label > Switching (MPLS). >We discussed this scenario on list some weeks ago, I was wondering why >you did not include it in the document. > >Best Regards >Roberta >________________________________________ >From: multrans-bounces@ietf.org [multrans-bounces@ietf.org] On Behalf Of >Tina TSOU [Tina.Tsou.Zouting@huawei.com] >Sent: Monday, October 31, 2011 8:49 PM >To: multrans@ietf.org >Subject: [multrans] Update of Multrans Problem Statement and Use Case >draft > >Dear all, >Version -03 of the Multrans Problem Statement and Use Case draft has >been submitted. By agreement amongst the authors, the diagrams and >updated descriptions from draft-tsou-multrans-use-cases-00 have been >absorbed into the problem statement and use case draft. > >https://datatracker.ietf.org/doc/draft-jaclee-behave-v4v6-mcast-ps/ now >presents the following use cases, all within the agreed context of IPTV: > >1. IPv4 Receiver and Source Connected to an IPv6-Only Network (4-6-4) > >2. IPv6 Receiver Connected to an IPv4 Source Through an IPv4 >Multicast-Incapable Access Network and an IPv6 Multicast-Capable Network >(6-4-6-4) > >3. IPv6 Receiver and Source Connected to an IPv4-Only Network (6-4-6) > >4. IPv6 Receiver and IPv4 Source (6-4) > >5. IPv4 Receiver and IPv6 Source (4-6) > >The diagrams and accompanying text show a potential solution to the >problem of differing IP versions through the use of nodes embodying >"adaptation functions". The Multrans BoF was negotiated on the basis of >solutions where these adaptation functions consisted of application >layer gateways (ALGs). Comments on this assumption and how it should >work are invited. > > > >B. R. >Tina >+1-408-859-4996 >_______________________________________________ >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. > >_______________________________________________ >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 Tina.Tsou.Zouting@huawei.com Tue Nov 1 14:01:41 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 3836311E81FF for ; Tue, 1 Nov 2011 14:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.959 X-Spam-Level: X-Spam-Status: No, score=-5.959 tagged_above=-999 required=5 tests=[AWL=0.640, 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 mirysYWywBJp for ; Tue, 1 Nov 2011 14:01:40 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1B58111E8105 for ; Tue, 1 Nov 2011 14:01:40 -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 <0LU000ATM1I9O1@szxga03-in.huawei.com> for multrans@ietf.org; Wed, 02 Nov 2011 04:42:09 +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 <0LU0008UP1I9WK@szxga03-in.huawei.com> for multrans@ietf.org; Wed, 02 Nov 2011 04:42:09 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEV57988; Wed, 02 Nov 2011 04:42:08 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 02 Nov 2011 04:42:05 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.58]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0270.001; Wed, 02 Nov 2011 04:42:00 +0800 Date: Tue, 01 Nov 2011 20:41:59 +0000 From: Tina TSOU In-reply-to: <282BBE8A501E1F4DA9C775F964BB21FE3EB758B7F9@GRFMBX704BA020.griffon.local> X-Originating-IP: [10.193.34.114] To: Maglione Roberta , "'Lee, Yiu'" , "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] Update of Multrans Problem Statement and Use Case draft Thread-index: AQHMmAUNjJb88rY39k25ujOJwT530ZWW2+xwgAFpOm///30cgIAABPMAgACnJlA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C83@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB758B7F9@GRFMBX704BA020.griffon.local> Subject: Re: [multrans] Update of Multrans Problem Statement and Use Case 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, 01 Nov 2011 21:01:41 -0000 Ciao Roberta, Sorry, it was oversight. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Sent: Tuesday, November 01, 2011 10:50 AM To: 'Lee, Yiu'; Tina TSOU; multrans@ietf.org Subject: RE: [multrans] Update of Multrans Problem Statement and Use Case d= raft Hi Yiu, I saw you mentioned 6-4-6 in Section 3.3 in a generic way, however the rea= son why I believe IPv4 network with IP/MPLS is a particular case is because= for unicast there is a specific solution (6PE) for the 6-4-6 with MPLS in = the IPv4 network. For multicast at the moment there is no equivalent for 6P= E. Please see the text below, I proposed some time ago on the list for this sc= enario: RFC 4798 tackles the unicast angle of the problem and it explains how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud by using Multiprotocol Border Gateway Protocol (MP-BGP) to exchange the IPv6 reachability information transparently. The devices implementing this mechanism are called IPv6 Provider Edge routers (6PE). The 6PE technique is currently deployed for unicast traffic in several Service Provider's networks. A similar approach would be useful for multicast services too, in order to allow the Service Providers to start offering IPv6 multicast contents (from its own multicast sources or provided by external Content Providers) to new IPv6 customers. This mechanism would allow the Service Providers to replicate for multicast contents, the same architectural model currently deployed for unicast traffic with 6PE method. In addition as this model does not require any translation or interworking function it is expected it would be able to preserve the service quality and the integrity of contents. Thanks Best regards, Roberta -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Sent: marted=EC 1 novembre 2011 18.32 To: Maglione Roberta; Tina TSOU; multrans@ietf.org Subject: Re: [multrans] Update of Multrans Problem Statement and Use Case d= raft Hi Roberta, We describe 6-4-6 in Section 3.3. This is very generic scenario and does not mention MPLS in the IPv4 networks. IMHO, MPLS would create an abstraction which makes the underneath network irrelevant. Do you suggest we need to describe 6-MPLS-6? B.R., Yiu On 11/1/11 1:20 PM, "Maglione Roberta" wrote: >Hello Tina, > in this version of the document it seems to be missing the 6-4-6 >Network Scenario where both the receivers and > the source are IPv6 capable, but the IPv6 connectivity among them is > provided over an IPv4-Only Network running Multiprotocol Label > Switching (MPLS). >We discussed this scenario on list some weeks ago, I was wondering why >you did not include it in the document. > >Best Regards >Roberta >________________________________________ >From: multrans-bounces@ietf.org [multrans-bounces@ietf.org] On Behalf Of >Tina TSOU [Tina.Tsou.Zouting@huawei.com] >Sent: Monday, October 31, 2011 8:49 PM >To: multrans@ietf.org >Subject: [multrans] Update of Multrans Problem Statement and Use Case >draft > >Dear all, >Version -03 of the Multrans Problem Statement and Use Case draft has >been submitted. By agreement amongst the authors, the diagrams and >updated descriptions from draft-tsou-multrans-use-cases-00 have been >absorbed into the problem statement and use case draft. > >https://datatracker.ietf.org/doc/draft-jaclee-behave-v4v6-mcast-ps/ now >presents the following use cases, all within the agreed context of IPTV: > >1. IPv4 Receiver and Source Connected to an IPv6-Only Network (4-6-4) > >2. IPv6 Receiver Connected to an IPv4 Source Through an IPv4 >Multicast-Incapable Access Network and an IPv6 Multicast-Capable Network >(6-4-6-4) > >3. IPv6 Receiver and Source Connected to an IPv4-Only Network (6-4-6) > >4. IPv6 Receiver and IPv4 Source (6-4) > >5. IPv4 Receiver and IPv6 Source (4-6) > >The diagrams and accompanying text show a potential solution to the >problem of differing IP versions through the use of nodes embodying >"adaptation functions". The Multrans BoF was negotiated on the basis of >solutions where these adaptation functions consisted of application >layer gateways (ALGs). Comments on this assumption and how it should >work are invited. > > > >B. R. >Tina >+1-408-859-4996 >_______________________________________________ >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. > >_______________________________________________ >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 Wed Nov 2 10:49: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 D58271F0C9A for ; Wed, 2 Nov 2011 10:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.982 X-Spam-Level: X-Spam-Status: No, score=-99.982 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_BASE64_TEXT=1.753, 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 asCSPPB+mnSR for ; Wed, 2 Nov 2011 10:49:21 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 03D5B1F0C4B for ; Wed, 2 Nov 2011 10:49:20 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.59816765; Wed, 02 Nov 2011 11:57:01 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0339.001; Wed, 2 Nov 2011 13:49:15 -0400 From: "Lee, Yiu" To: Maglione Roberta Thread-Topic: [multrans] Update of Multrans Problem Statement and Use Case draft Thread-Index: AQHMmLw02tImPGYa6UaIoA84/LJC0pWYSjQwgAHWOIA= Date: Wed, 2 Nov 2011 17:49:05 +0000 Message-ID: <80512B2B-CD01-49AC-AE66-E3CA6C81191E@Cable.Comcast.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C83@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB758B7F9@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB758B7F9@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: <145FB9CB2C64284398386D97FAB3E22B@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "multrans@ietf.org" Subject: Re: [multrans] Update of Multrans Problem Statement and Use Case 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: Wed, 02 Nov 2011 17:49:21 -0000 SGkgUm9iZXJ0YSwNCg0KSXMgaXQgdGhlIHNpbWlsYXIgcHJvYmxlbSB0aGUgbWVzaCBzb2Z0d2Fy ZSB0cnlpbmcgdG8gc29sdmUgKG11bHRpY2FzdCAgDQpvdmVyIHR1bm5lbCk/DQoNCllpdQ0KDQoN Cg0KT24gTm92IDEsIDIwMTEsIGF0IDE6NTAgUE0sICJNYWdsaW9uZSBSb2JlcnRhIiA8cm9iZXJ0 YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0IA0KID4gd3JvdGU6DQoNCj4gSGkgWWl1LA0KPiBJ IHNhdyB5b3UgbWVudGlvbmVkIDYtNC02IGluIFNlY3Rpb24gMy4zIGluIGEgZ2VuZXJpYyB3YXks IGhvd2V2ZXIgIA0KPiB0aGUgcmVhc29uIHdoeSBJIGJlbGlldmUgSVB2NCBuZXR3b3JrIHdpdGgg SVAvTVBMUyBpcyBhIHBhcnRpY3VsYXIgIA0KPiBjYXNlIGlzIGJlY2F1c2UgZm9yIHVuaWNhc3Qg dGhlcmUgaXMgYSBzcGVjaWZpYyBzb2x1dGlvbiAoNlBFKSBmb3IgIA0KPiB0aGUgNi00LTYgd2l0 aCBNUExTIGluIHRoZSBJUHY0IG5ldHdvcmsuIEZvciBtdWx0aWNhc3QgYXQgdGhlIG1vbWVudCAg DQo+IHRoZXJlIGlzIG5vIGVxdWl2YWxlbnQgZm9yIDZQRS4NCj4NCj4gUGxlYXNlIHNlZSB0aGUg dGV4dCBiZWxvdywgSSBwcm9wb3NlZCBzb21lIHRpbWUgYWdvIG9uIHRoZSBsaXN0IGZvciAgDQo+ IHRoaXMgc2NlbmFyaW86DQo+DQo+DQo+ICBSRkMgNDc5OCB0YWNrbGVzIHRoZSB1bmljYXN0IGFu Z2xlIG9mIHRoZSBwcm9ibGVtIGFuZCBpdCBleHBsYWlucyBob3cNCj4gICB0byBpbnRlcmNvbm5l Y3QgSVB2NiBpc2xhbmRzIG92ZXIgYSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZw0KPiAg IChNUExTKS1lbmFibGVkIElQdjQgY2xvdWQgYnkgdXNpbmcgTXVsdGlwcm90b2NvbCBCb3JkZXIg R2F0ZXdheQ0KPiAgIFByb3RvY29sIChNUC1CR1ApIHRvIGV4Y2hhbmdlIHRoZSBJUHY2IHJlYWNo YWJpbGl0eSBpbmZvcm1hdGlvbg0KPiAgIHRyYW5zcGFyZW50bHkuICBUaGUgZGV2aWNlcyBpbXBs ZW1lbnRpbmcgdGhpcyBtZWNoYW5pc20gYXJlIGNhbGxlZA0KPiAgIElQdjYgUHJvdmlkZXIgRWRn ZSByb3V0ZXJzICg2UEUpLiAgVGhlIDZQRSB0ZWNobmlxdWUgaXMgY3VycmVudGx5DQo+ICAgZGVw bG95ZWQgZm9yIHVuaWNhc3QgdHJhZmZpYyBpbiBzZXZlcmFsIFNlcnZpY2UgUHJvdmlkZXIncyBu ZXR3b3Jrcy4NCj4NCj4gICBBIHNpbWlsYXIgYXBwcm9hY2ggd291bGQgYmUgdXNlZnVsIGZvciBt dWx0aWNhc3Qgc2VydmljZXMgdG9vLCBpbg0KPiAgIG9yZGVyIHRvIGFsbG93IHRoZSBTZXJ2aWNl IFByb3ZpZGVycyB0byBzdGFydCBvZmZlcmluZyBJUHY2ICANCj4gbXVsdGljYXN0DQo+ICAgY29u dGVudHMgKGZyb20gaXRzIG93biBtdWx0aWNhc3Qgc291cmNlcyBvciBwcm92aWRlZCBieSBleHRl cm5hbA0KPiAgIENvbnRlbnQgUHJvdmlkZXJzKSB0byBuZXcgSVB2NiBjdXN0b21lcnMuICBUaGlz IG1lY2hhbmlzbSB3b3VsZCAgDQo+IGFsbG93DQo+ICAgdGhlIFNlcnZpY2UgUHJvdmlkZXJzIHRv IHJlcGxpY2F0ZSBmb3IgbXVsdGljYXN0IGNvbnRlbnRzLCB0aGUgc2FtZQ0KPiAgIGFyY2hpdGVj dHVyYWwgbW9kZWwgY3VycmVudGx5IGRlcGxveWVkIGZvciB1bmljYXN0IHRyYWZmaWMgd2l0aCA2 UEUNCj4gICBtZXRob2QuICBJbiBhZGRpdGlvbiBhcyB0aGlzIG1vZGVsIGRvZXMgbm90IHJlcXVp cmUgYW55IHRyYW5zbGF0aW9uDQo+ICAgb3IgaW50ZXJ3b3JraW5nIGZ1bmN0aW9uIGl0IGlzIGV4 cGVjdGVkIGl0IHdvdWxkIGJlIGFibGUgdG8gcHJlc2VydmUNCj4gICB0aGUgc2VydmljZSBxdWFs aXR5IGFuZCB0aGUgaW50ZWdyaXR5IG9mIGNvbnRlbnRzLg0KPg0KPg0KPiBUaGFua3MNCj4gQmVz dCByZWdhcmRzLA0KPiBSb2JlcnRhDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IExlZSwgWWl1IFttYWlsdG86WWl1X0xlZUBDYWJsZS5Db21jYXN0LmNvbV0NCj4gU2Vu dDogbWFydGVkqKwgMSBub3ZlbWJyZSAyMDExIDE4LjMyDQo+IFRvOiBNYWdsaW9uZSBSb2JlcnRh OyBUaW5hIFRTT1U7IG11bHRyYW5zQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbXVsdHJhbnNd IFVwZGF0ZSBvZiBNdWx0cmFucyBQcm9ibGVtIFN0YXRlbWVudCBhbmQgVXNlICANCj4gQ2FzZSBk cmFmdA0KPg0KPiBIaSBSb2JlcnRhLA0KPg0KPiBXZSBkZXNjcmliZSA2LTQtNiBpbiBTZWN0aW9u IDMuMy4gVGhpcyBpcyB2ZXJ5IGdlbmVyaWMgc2NlbmFyaW8gYW5kICANCj4gZG9lcw0KPiBub3Qg bWVudGlvbiBNUExTIGluIHRoZSBJUHY0IG5ldHdvcmtzLiBJTUhPLCBNUExTIHdvdWxkIGNyZWF0 ZSBhbg0KPiBhYnN0cmFjdGlvbiB3aGljaCBtYWtlcyB0aGUgdW5kZXJuZWF0aCBuZXR3b3JrIGly cmVsZXZhbnQuIERvIHlvdSAgDQo+IHN1Z2dlc3QNCj4gd2UgbmVlZCB0byBkZXNjcmliZSA2LU1Q TFMtNj8NCj4NCj4gQi5SLiwNCj4gWWl1DQo+DQo+DQo+IE9uIDExLzEvMTEgMToyMCBQTSwgIk1h Z2xpb25lIFJvYmVydGEiIDxyb2JlcnRhLm1hZ2xpb25lQHRlbGVjb21pdGFsaWEuaXQgDQo+ID4N Cj4gd3JvdGU6DQo+DQo+PiBIZWxsbyBUaW5hLA0KPj4gIGluIHRoaXMgdmVyc2lvbiBvZiB0aGUg ZG9jdW1lbnQgaXQgc2VlbXMgdG8gYmUgbWlzc2luZyB0aGUgNi00LTYNCj4+IE5ldHdvcmsgU2Nl bmFyaW8gd2hlcmUgYm90aCB0aGUgcmVjZWl2ZXJzIGFuZA0KPj4gIHRoZSBzb3VyY2UgYXJlIElQ djYgY2FwYWJsZSwgYnV0IHRoZSBJUHY2IGNvbm5lY3Rpdml0eSBhbW9uZyB0aGVtIGlzDQo+PiAg cHJvdmlkZWQgb3ZlciBhbiBJUHY0LU9ubHkgTmV0d29yayBydW5uaW5nIE11bHRpcHJvdG9jb2wg TGFiZWwNCj4+ICBTd2l0Y2hpbmcgKE1QTFMpLg0KPj4gV2UgZGlzY3Vzc2VkIHRoaXMgc2NlbmFy aW8gb24gbGlzdCBzb21lIHdlZWtzIGFnbywgSSB3YXMgd29uZGVyaW5nICANCj4+IHdoeQ0KPj4g eW91IGRpZCBub3QgaW5jbHVkZSBpdCBpbiB0aGUgZG9jdW1lbnQuDQo+Pg0KPj4gQmVzdCBSZWdh cmRzDQo+PiBSb2JlcnRhDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBGcm9tOiBtdWx0cmFucy1ib3VuY2VzQGlldGYub3JnIFttdWx0cmFucy1ib3VuY2Vz QGlldGYub3JnXSBPbiAgDQo+PiBCZWhhbGYgT2YNCj4+IFRpbmEgVFNPVSBbVGluYS5Uc291Llpv dXRpbmdAaHVhd2VpLmNvbV0NCj4+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAzMSwgMjAxMSA4OjQ5 IFBNDQo+PiBUbzogbXVsdHJhbnNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFttdWx0cmFuc10gVXBk YXRlIG9mIE11bHRyYW5zIFByb2JsZW0gU3RhdGVtZW50IGFuZCBVc2UgQ2FzZQ0KPj4gZHJhZnQN Cj4+DQo+PiBEZWFyIGFsbCwNCj4+IFZlcnNpb24gLTAzIG9mIHRoZSBNdWx0cmFucyBQcm9ibGVt IFN0YXRlbWVudCBhbmQgVXNlIENhc2UgZHJhZnQgaGFzDQo+PiBiZWVuIHN1Ym1pdHRlZC4gQnkg YWdyZWVtZW50IGFtb25nc3QgdGhlIGF1dGhvcnMsIHRoZSBkaWFncmFtcyBhbmQNCj4+IHVwZGF0 ZWQgZGVzY3JpcHRpb25zIGZyb20gZHJhZnQtdHNvdS1tdWx0cmFucy11c2UtY2FzZXMtMDAgaGF2 ZSBiZWVuDQo+PiBhYnNvcmJlZCBpbnRvIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgdXNlIGNh c2UgZHJhZnQuDQo+Pg0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt amFjbGVlLWJlaGF2ZS12NHY2LW1jYXN0LXBzLyAgDQo+PiBub3cNCj4+IHByZXNlbnRzIHRoZSBm b2xsb3dpbmcgdXNlIGNhc2VzLCBhbGwgd2l0aGluIHRoZSBhZ3JlZWQgY29udGV4dCBvZiAgDQo+ PiBJUFRWOg0KPj4NCj4+IDEuIElQdjQgUmVjZWl2ZXIgYW5kIFNvdXJjZSBDb25uZWN0ZWQgdG8g YW4gSVB2Ni1Pbmx5IE5ldHdvcmsgKDQtNi00KQ0KPj4NCj4+IDIuIElQdjYgUmVjZWl2ZXIgQ29u bmVjdGVkIHRvIGFuIElQdjQgU291cmNlIFRocm91Z2ggYW4gSVB2NA0KPj4gTXVsdGljYXN0LUlu Y2FwYWJsZSBBY2Nlc3MgTmV0d29yayBhbmQgYW4gSVB2NiBNdWx0aWNhc3QtQ2FwYWJsZSAgDQo+ PiBOZXR3b3JrDQo+PiAoNi00LTYtNCkNCj4+DQo+PiAzLiBJUHY2IFJlY2VpdmVyIGFuZCBTb3Vy Y2UgQ29ubmVjdGVkIHRvIGFuIElQdjQtT25seSBOZXR3b3JrICg2LTQtNikNCj4+DQo+PiA0LiBJ UHY2IFJlY2VpdmVyIGFuZCBJUHY0IFNvdXJjZSAoNi00KQ0KPj4NCj4+IDUuIElQdjQgUmVjZWl2 ZXIgYW5kIElQdjYgU291cmNlICg0LTYpDQo+Pg0KPj4gVGhlIGRpYWdyYW1zIGFuZCBhY2NvbXBh bnlpbmcgdGV4dCBzaG93IGEgcG90ZW50aWFsIHNvbHV0aW9uIHRvIHRoZQ0KPj4gcHJvYmxlbSBv ZiBkaWZmZXJpbmcgSVAgdmVyc2lvbnMgdGhyb3VnaCB0aGUgdXNlIG9mIG5vZGVzIGVtYm9keWlu Zw0KPj4gImFkYXB0YXRpb24gZnVuY3Rpb25zIi4gVGhlIE11bHRyYW5zIEJvRiB3YXMgbmVnb3Rp YXRlZCBvbiB0aGUgIA0KPj4gYmFzaXMgb2YNCj4+IHNvbHV0aW9ucyB3aGVyZSB0aGVzZSBhZGFw dGF0aW9uIGZ1bmN0aW9ucyBjb25zaXN0ZWQgb2YgYXBwbGljYXRpb24NCj4+IGxheWVyIGdhdGV3 YXlzIChBTEdzKS4gQ29tbWVudHMgb24gdGhpcyBhc3N1bXB0aW9uIGFuZCBob3cgaXQgc2hvdWxk DQo+PiB3b3JrIGFyZSBpbnZpdGVkLg0KPj4NCj4+DQo+Pg0KPj4gQi4gUi4NCj4+IFRpbmENCj4+ ICsxLTQwOC04NTktNDk5Ng0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IG11bHRyYW5zIG1haWxpbmcgbGlzdA0KPj4gbXVsdHJhbnNAaWV0Zi5v cmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXVsdHJhbnMNCj4+ DQo+PiBRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkg ZXNjbHVzaXZhbWVudGUgIA0KPj4gYWxsZQ0KPj4gcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVz aW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lICANCj4+IGRlcml2YW50ZQ0KPj4g ZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50 ZSB2aWV0YXRlLg0KPj4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8g cGVyIGVycm9yZSBzaWV0ZSAgDQo+PiBjb3J0ZXNlbWVudGUNCj4+IHByZWdhdGkgZGkgZGFybmUg aW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSAgDQo+PiBwcm92dmVkZXJl IGFsbGENCj4+IHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KPj4NCj4+IFRoaXMgZS1tYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbg0KPj4gcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiAg DQo+PiBEaXNzZW1pbmF0aW9uLA0KPj4gY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJv ZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSAgDQo+PiBhcmUgbm90DQo+PiB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55ICANCj4+ IGF0dGFjaG1lbnRzDQo+PiBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwg VGhhbmtzLg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiBtdWx0cmFucyBtYWlsaW5nIGxpc3QNCj4+IG11bHRyYW5zQGlldGYub3JnDQo+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211bHRyYW5zDQo+DQo+DQo+ IFF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2Ns dXNpdmFtZW50ZSAgDQo+IGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29w aWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lICANCj4gZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2Vu emEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgIA0KPiB2aWV0YXRl LiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNp ZXRlICANCj4gY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNh emlvbmUgYWwgbWl0dGVudGUgZSAgDQo+IGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlv bmUsIEdyYXppZS4NCj4NCj4gVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25m aWRlbnRpYWwgYW5kIG1heSBjb250YWluICANCj4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRl bmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiAgDQo+IERpc3NlbWluYXRpb24sIGNvcHlp bmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgIA0KPiB1bmF1dGhvcmlzZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgIA0K PiB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIg YnkgcmV0dXJuIGUtIA0KPiBtYWlsLCBUaGFua3MuDQo+DQo= From tom111.taylor@bell.net Thu Nov 10 16:05:11 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 468D71F0C5B for ; Thu, 10 Nov 2011 16:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.867 X-Spam-Level: X-Spam-Status: No, score=-100.867 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 KKFd-wx2Jv2n for ; Thu, 10 Nov 2011 16:05:10 -0800 (PST) Received: from blu0-omc4-s15.blu0.hotmail.com (blu0-omc4-s15.blu0.hotmail.com [65.55.111.154]) by ietfa.amsl.com (Postfix) with ESMTP id BDF111F0C5A for ; Thu, 10 Nov 2011 16:05:10 -0800 (PST) Received: from BLU0-SMTP67 ([65.55.111.135]) by blu0-omc4-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 16:05:06 -0800 X-Originating-IP: [76.70.77.190] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([76.70.77.190]) by BLU0-SMTP67.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 16:05:05 -0800 Date: Thu, 10 Nov 2011 19:05:06 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "multrans@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2011 00:05:06.0079 (UTC) FILETIME=[915A32F0:01CCA005] Subject: [multrans] Inconsistencies in draft-jaclee-behave-v4v6-mcast-ps-03.txt 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, 11 Nov 2011 00:05:11 -0000 draft-jaclee-behave-v4v6-mcast-ps-03.txt was updated to include new use case text, but outside of Section 3, it was not touched. It now contains a number of inconsistencies that will need clearing up. This is just a note of the the work that has to be done. I will propose text in other notes. Section 2.1: the 6-4-6-4 case (Section 3.2) is not consistent with the "Multicast-enabled networks only" restriction in scope. This obviously goes beyond the editorial to a group decision on what should be in scope. Section 4.2: text is needed to allow for the possibility that an ALG can initiate a subscription on behalf of a receiver. Section 4.4: the final paragraph is again inconsistent with the 6-4-6-4 case. Earlier in the paragraph, need text to indicate that if an ALG initiates a subscription on behalf of a receiver, interworking between various versions of IGMP and MLD may be avoided, and similarly one could avoid combinations of MLD and PIMv4 or IGMP and PIMv6. Given that the sub-sections of 4.4 continue to discuss interworking, perhaps an additional sub-section could be added to discuss the ALG approach. Yet another sub-section could deal with use of ALGs between PIMv4 and PIMv6 networks. Section 5: will naturally be updated to match the Multrans charter if one is agreed. Tom Taylor From Tina.Tsou.Zouting@huawei.com Fri Nov 11 11:24:54 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 3F21621F8564 for ; Fri, 11 Nov 2011 11:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.14 X-Spam-Level: X-Spam-Status: No, score=-6.14 tagged_above=-999 required=5 tests=[AWL=0.459, 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 lKrOolwYXjqP for ; Fri, 11 Nov 2011 11:24:53 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 578D621F8557 for ; Fri, 11 Nov 2011 11:24:53 -0800 (PST) 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 <0LUI00KAIGL9M7@szxga05-in.huawei.com> for multrans@ietf.org; Sat, 12 Nov 2011 03:24:45 +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 <0LUI00HISGKXL1@szxga05-in.huawei.com> for multrans@ietf.org; Sat, 12 Nov 2011 03:24:45 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEY27670; Sat, 12 Nov 2011 03:24:44 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 12 Nov 2011 03:24:37 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0270.001; Sat, 12 Nov 2011 03:24:36 +0800 Date: Fri, 11 Nov 2011 19:24:35 +0000 From: Tina TSOU X-Originating-IP: [10.193.34.134] 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: link to meeting slides for multrans BoF Thread-index: Acygp4tCJWaHMutOQq64J81cYj3+LA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [multrans] link to meeting slides for multrans BoF 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, 11 Nov 2011 19:24:54 -0000 Dear all, Here is the link to meeting slides for multrans BoF. http://www.ietf.org/proceedings/82/agenda/multrans.txt http://www.ietf.org/proceedings/82/slides/multrans-0.pdf http://www.ietf.org/proceedings/82/slides/multrans-1.ppt http://www.ietf.org/proceedings/82/slides/multrans-2.ppt http://www.ietf.org/proceedings/82/slides/multrans-3.ppt Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From tom111.taylor@bell.net Fri Nov 11 12:11: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 2A64721F8B4B for ; Fri, 11 Nov 2011 12:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.486 X-Spam-Level: X-Spam-Status: No, score=-101.486 tagged_above=-999 required=5 tests=[AWL=0.310, 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 S89ALH5+DP9F for ; Fri, 11 Nov 2011 12:10:54 -0800 (PST) Received: from blu0-omc4-s24.blu0.hotmail.com (blu0-omc4-s24.blu0.hotmail.com [65.55.111.163]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECA021F8B42 for ; Fri, 11 Nov 2011 12:10:54 -0800 (PST) Received: from BLU0-SMTP24 ([65.55.111.137]) by blu0-omc4-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 12:10:36 -0800 X-Originating-IP: [76.70.77.190] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([76.70.77.190]) by BLU0-SMTP24.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 12:10:36 -0800 Date: Fri, 11 Nov 2011 15:10:37 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "multrans@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2011 20:10:36.0622 (UTC) FILETIME=[F9B72EE0:01CCA0AD] Subject: Re: [multrans] link to meeting slides for multrans BoF 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, 11 Nov 2011 20:11:01 -0000 The current set of "Issues" charts is at multrans-2. Do people have comments? On 11/11/2011 2:24 PM, Tina TSOU wrote: > Dear all, > Here is the link to meeting slides for multrans BoF. > http://www.ietf.org/proceedings/82/agenda/multrans.txt > http://www.ietf.org/proceedings/82/slides/multrans-0.pdf > http://www.ietf.org/proceedings/82/slides/multrans-1.ppt > http://www.ietf.org/proceedings/82/slides/multrans-2.ppt > http://www.ietf.org/proceedings/82/slides/multrans-3.ppt > > > 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 Nov 11 14:22:38 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 ED26D21F8508 for ; Fri, 11 Nov 2011 14:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.154 X-Spam-Level: X-Spam-Status: No, score=-6.154 tagged_above=-999 required=5 tests=[AWL=0.445, 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 ds6yJFn842i6 for ; Fri, 11 Nov 2011 14:22:37 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5CB21F8507 for ; Fri, 11 Nov 2011 14:22:37 -0800 (PST) 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 <0LUI003BBOTHB4@szxga05-in.huawei.com> for multrans@ietf.org; Sat, 12 Nov 2011 06:22:29 +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 <0LUI0021HOTGXN@szxga05-in.huawei.com> for multrans@ietf.org; Sat, 12 Nov 2011 06:22:29 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEY29004; Sat, 12 Nov 2011 06:22:27 +0800 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; Sat, 12 Nov 2011 06:22:16 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0270.001; Sat, 12 Nov 2011 06:22:20 +0800 Date: Fri, 11 Nov 2011 22:22:19 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.193.34.134] To: Tom Taylor , "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] link to meeting slides for multrans BoF Thread-index: Acygp4tCJWaHMutOQq64J81cYj3+LP//hsGA//9VNyA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [multrans] link to meeting slides for multrans BoF 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, 11 Nov 2011 22:22:38 -0000 Tom, Per discussion with Stig yesterday, the framework draft considers a single translator, which he think is a useful scenario not in the current version of issues slides. 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 Tom Taylor Sent: Friday, November 11, 2011 12:11 PM To: multrans@ietf.org Subject: Re: [multrans] link to meeting slides for multrans BoF The current set of "Issues" charts is at multrans-2. Do people have comments? On 11/11/2011 2:24 PM, Tina TSOU wrote: > Dear all, > Here is the link to meeting slides for multrans BoF. > http://www.ietf.org/proceedings/82/agenda/multrans.txt > http://www.ietf.org/proceedings/82/slides/multrans-0.pdf > http://www.ietf.org/proceedings/82/slides/multrans-1.ppt > http://www.ietf.org/proceedings/82/slides/multrans-2.ppt > http://www.ietf.org/proceedings/82/slides/multrans-3.ppt > > > 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 tom111.taylor@bell.net Fri Nov 11 15:58: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 A8F9021F8485 for ; Fri, 11 Nov 2011 15:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.564 X-Spam-Level: X-Spam-Status: No, score=-101.564 tagged_above=-999 required=5 tests=[AWL=0.232, 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 zhkUdypvXxrn for ; Fri, 11 Nov 2011 15:58:05 -0800 (PST) Received: from blu0-omc4-s12.blu0.hotmail.com (blu0-omc4-s12.blu0.hotmail.com [65.55.111.151]) by ietfa.amsl.com (Postfix) with ESMTP id EAE2821F8486 for ; Fri, 11 Nov 2011 15:58:04 -0800 (PST) Received: from BLU0-SMTP6 ([65.55.111.135]) by blu0-omc4-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 15:58:04 -0800 X-Originating-IP: [76.70.77.190] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([76.70.77.190]) by BLU0-SMTP6.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 15:58:03 -0800 Date: Fri, 11 Nov 2011 18:58:05 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Tina TSOU References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2011 23:58:03.0787 (UTC) FILETIME=[C00F4DB0:01CCA0CD] Cc: "multrans@ietf.org" Subject: Re: [multrans] link to meeting slides for multrans BoF 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, 11 Nov 2011 23:58:05 -0000 I can add the slide, but Stig, what additional issues are currently missing? On 11/11/2011 5:22 PM, Tina TSOU wrote: > Tom, Per discussion with Stig yesterday, the framework draft > considers a single translator, which he think is a useful scenario > not in the current version of issues slides. > > > 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 Tom Taylor Sent: > Friday, November 11, 2011 12:11 PM To: multrans@ietf.org Subject: Re: > [multrans] link to meeting slides for multrans BoF > > The current set of "Issues" charts is at multrans-2. Do people have > comments? > > On 11/11/2011 2:24 PM, Tina TSOU wrote: >> Dear all, Here is the link to meeting slides for multrans BoF. >> http://www.ietf.org/proceedings/82/agenda/multrans.txt >> http://www.ietf.org/proceedings/82/slides/multrans-0.pdf >> http://www.ietf.org/proceedings/82/slides/multrans-1.ppt >> http://www.ietf.org/proceedings/82/slides/multrans-2.ppt >> http://www.ietf.org/proceedings/82/slides/multrans-3.ppt >> >> >> 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 dwing@cisco.com Fri Nov 11 16:20:47 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 67D4B1F0C3D for ; Fri, 11 Nov 2011 16:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.685 X-Spam-Level: X-Spam-Status: No, score=-105.685 tagged_above=-999 required=5 tests=[AWL=0.914, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooJ0TRkHJu8R for ; Fri, 11 Nov 2011 16:20:46 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id ADFA51F0C3B for ; Fri, 11 Nov 2011 16:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1673; q=dns/txt; s=iport; t=1321057246; x=1322266846; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=QPlUKz5embp/2RMVbOdzOzc8uJpk1e1F4Z6UFohgyak=; b=FPSBeFHlWY685xx+nNGIKiDnq8r1EzEVLlByWBE4tlO3iJbs95Ddq308 dOxiDoTnXltTh3rn3el9VFezmSqFV4cSxJ9Eciof4xiyxC8bHZ90DOya4 349DixQ/8y0LpkhNnFMY52g0JqOw7/YeJyw3sXh6tenhMxUx0Q9EJ6tDH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0AAMi7vU6rRDoH/2dsb2JhbABCmiiBa44bgQWBcgEBAQIBAQEBAQUKARUCEDQQBwEDAgkPAgQBAQEnBxkOFQoJCAEBBAESCQIXh2AImRYBnhGJfgSIDoRAJwGZPA X-IronPort-AV: E=Sophos;i="4.69,497,1315180800"; d="scan'208";a="13788192" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 12 Nov 2011 00:20:38 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAC0KbDg013915; Sat, 12 Nov 2011 00:20:37 GMT From: "Dan Wing" To: "'Tom Taylor'" , References: In-Reply-To: Date: Sat, 12 Nov 2011 08:20:37 +0800 Message-ID: <004d01cca0d0$e72adf10$b5809d30$@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: AcygrgoIuYPnRr0kQDKTeScyJC2sggAIhjFw Content-language: en-us Subject: Re: [multrans] link to meeting slides for multrans BoF 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, 12 Nov 2011 00:20:47 -0000 > -----Original Message----- > From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] On > Behalf Of Tom Taylor > Sent: Saturday, November 12, 2011 4:11 AM > To: multrans@ietf.org > Subject: Re: [multrans] link to meeting slides for multrans BoF > > The current set of "Issues" charts is at multrans-2. Do people have > comments? Slide 7 says "Assuming AF1 is an ALG". My comment: don't build a system requiring an ALG. Slide 8: yes, IPv6 and IPv4 on the access network is infeasible. I mean, isn't the access network where everybody has insufficient bandwidth for carrying the same traffic on both IPv6 and IPv4, isn't it? Slide 9, on Join Permanently. This appears to be an optimization purely for multicast, and appears to have nothing to do with the scope of the MultTrans BoF. -d > On 11/11/2011 2:24 PM, Tina TSOU wrote: > > Dear all, > > Here is the link to meeting slides for multrans BoF. > > http://www.ietf.org/proceedings/82/agenda/multrans.txt > > http://www.ietf.org/proceedings/82/slides/multrans-0.pdf > > http://www.ietf.org/proceedings/82/slides/multrans-1.ppt > > http://www.ietf.org/proceedings/82/slides/multrans-2.ppt > > http://www.ietf.org/proceedings/82/slides/multrans-3.ppt > > > > > > 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 simon.perreault@viagenie.ca Sat Nov 12 06:52:47 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 38F7221F8922 for ; Sat, 12 Nov 2011 06:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 95iYCD7HudtV for ; Sat, 12 Nov 2011 06:52:46 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 76F8021F8906 for ; Sat, 12 Nov 2011 06:52:46 -0800 (PST) Received: from banana.viagenie.ca (210.241-ppp.3menatwork.com [72.0.210.241]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9573420DC3 for ; Sat, 12 Nov 2011 09:52:15 -0500 (EST) Message-ID: <4EBE8820.605@viagenie.ca> Date: Sat, 12 Nov 2011 09:52:16 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: multrans@ietf.org References: <004d01cca0d0$e72adf10$b5809d30$@com> In-Reply-To: <004d01cca0d0$e72adf10$b5809d30$@com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [multrans] link to meeting slides for multrans BoF 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, 12 Nov 2011 14:52:47 -0000 Dan Wing wrote, on 11/11/2011 07:20 PM: > Slide 7 says "Assuming AF1 is an ALG". My comment: don't build a system > requiring an ALG. We need to be careful here. There are two types of ALGs: transparent and non-transparent (from RFC2101). Only the transparent ALG is "evil". A non-transparent ALG, one that operates within the boundaries of an application protocol (e.g. a SIP B2BUA, an HTTP proxy), can be a fine, recommendable transition mechanism. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From tom111.taylor@bell.net Sat Nov 12 16: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 9736111E8089 for ; Sat, 12 Nov 2011 16:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.61 X-Spam-Level: X-Spam-Status: No, score=-101.61 tagged_above=-999 required=5 tests=[AWL=0.186, 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 O+DE9YihfyQd for ; Sat, 12 Nov 2011 16:57:17 -0800 (PST) Received: from blu0-omc4-s23.blu0.hotmail.com (blu0-omc4-s23.blu0.hotmail.com [65.55.111.162]) by ietfa.amsl.com (Postfix) with ESMTP id 9B56911E8083 for ; Sat, 12 Nov 2011 16:57:17 -0800 (PST) Received: from BLU0-SMTP38 ([65.55.111.135]) by blu0-omc4-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 Nov 2011 16:57:16 -0800 X-Originating-IP: [76.70.77.190] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([76.70.77.190]) by BLU0-SMTP38.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 Nov 2011 16:57:16 -0800 Date: Sat, 12 Nov 2011 19:57:20 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Dan Wing References: <004d01cca0d0$e72adf10$b5809d30$@com> In-Reply-To: <004d01cca0d0$e72adf10$b5809d30$@com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2011 00:57:16.0666 (UTC) FILETIME=[30275DA0:01CCA19F] Cc: multrans@ietf.org Subject: Re: [multrans] link to meeting slides for multrans BoF 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: Sun, 13 Nov 2011 00:57:18 -0000 Below. On 11/11/2011 7:20 PM, Dan Wing wrote: >> -----Original Message----- >> From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] On >> Behalf Of Tom Taylor >> Sent: Saturday, November 12, 2011 4:11 AM ... > > Slide 8: yes, IPv6 and IPv4 on the access network is infeasible. I mean, > isn't the access network where everybody has insufficient bandwidth for > carrying the same traffic on both IPv6 and IPv4, isn't it? > [PTT] Sorry, I don't get the linkage between this and what the slide says. > > -d >... From jacni@jacni.com Sun Nov 13 17:04:31 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 CBC5F21F84F9 for ; Sun, 13 Nov 2011 17:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.225, 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 UknRP0EpzQ69 for ; Sun, 13 Nov 2011 17:04:31 -0800 (PST) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 46FD521F84FC for ; Sun, 13 Nov 2011 17:04:30 -0800 (PST) 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 469DF380078 for ; Sun, 13 Nov 2011 20:04:29 -0500 (EST) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id DBC5B3400A8 for ; Mon, 14 Nov 2011 09:04:25 +0800 (CST) Received: from [172.20.167.26] (unknown [221.11.61.6]) by app (Coremail) with SMTP id +AWowJCLUgULacBOqzgKAA--.15129S2; Mon, 14 Nov 2011 09:04:13 +0800 (CST) Message-ID: <4EC0698C.9090308@jacni.com> Date: Mon, 14 Nov 2011 09:06:20 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Tina TSOU References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030403050909030000040209" X-CM-TRANSID: +AWowJCLUgULacBOqzgKAA--.15129S2 X-Coremail-Antispam: 1UD129KBjvdXoWrKF1UJr1kCryxJr17Cr4DArb_yoW3AFg_CF 1xZ3y8Jw4UJrZrKan3X3y2yr1fZryYgw1fAa4DW3Zrur15Cr4vkrs3G3s8Kr1rGas3KF1U AF1fKr1UAFW3CjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUj4kYjxAI6xkYrwAYjxAI6xCIbckI1I0E57IF64kEYxAxM7k0a2IF 6F4UM7kC6x804xWl1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s1ln4vEF7Iv6F18KV Aqrcv_GVWUtr1rJF1ln4vE4IxY62xKV4CY8xCE548m6r4UJryUGwAawVCIc40E5I027xCE 548m6r1DJr4UtwAa7VCY0VAaVVAqrcv_Jw1UWr13McIj6xIIjxv20xvE14v26r106r15Mc Ij6I8E87Iv67AKxVWUJVW8JwACjcxG0xvEwIxGrwACjI8F5VAYr7xFoVCIc40_GwCjr7xv wVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFI7 vE0wC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0xZFpf9x 07jEc_fUUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQAMEko7lPRGLwABsm Cc: "multrans@ietf.org" Subject: Re: [multrans] link to meeting slides for multrans BoF 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, 14 Nov 2011 01:04:31 -0000 This is a multi-part message in MIME format. --------------030403050909030000040209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hi, In multran-1, about the "IPv4 Access Network (not mcast capable)", do you mean Layer2 or Layer3? Cheers, Jacni On 11/12/2011 3:24 AM, Tina TSOU wrote: > Dear all, > Here is the link to meeting slides for multrans BoF. > http://www.ietf.org/proceedings/82/agenda/multrans.txt > http://www.ietf.org/proceedings/82/slides/multrans-0.pdf > http://www.ietf.org/proceedings/82/slides/multrans-1.ppt > http://www.ietf.org/proceedings/82/slides/multrans-2.ppt > http://www.ietf.org/proceedings/82/slides/multrans-3.ppt > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans > --------------030403050909030000040209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hi,

In multran-1, about the "IPv4 Access Network (not mcast capable)", do you mean Layer2 or Layer3?


Cheers,
Jacni

On 11/12/2011 3:24 AM, Tina TSOU wrote: 
Dear all,
Here is the link to meeting slides for multrans BoF.
http://www.ietf.org/proceedings/82/agenda/multrans.txt
http://www.ietf.org/proceedings/82/slides/multrans-0.pdf
http://www.ietf.org/proceedings/82/slides/multrans-1.ppt
http://www.ietf.org/proceedings/82/slides/multrans-2.ppt
http://www.ietf.org/proceedings/82/slides/multrans-3.ppt


Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html



_______________________________________________
multrans mailing list
multrans@ietf.org
https://www.ietf.org/mailman/listinfo/multrans
--------------030403050909030000040209-- From dwing@cisco.com Sun Nov 13 18:15:47 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 0812511E80B7 for ; Sun, 13 Nov 2011 18:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.7 X-Spam-Level: X-Spam-Status: No, score=-105.7 tagged_above=-999 required=5 tests=[AWL=0.899, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9B7pBfWb5DP for ; Sun, 13 Nov 2011 18:15:46 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9527F11E8087 for ; Sun, 13 Nov 2011 18:15:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1102; q=dns/txt; s=iport; t=1321236946; x=1322446546; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=X9bReXtnIXdJK9vL3aOgmVR0944+1wORWftEvOTPH+w=; b=JKZ0G3i2/rgvkb2KnerrTczKyg47fZyd9DOMvNc3aSMfJK7Kpfg+k5TY x3vVZzYizjbT8xvGkuyThYYiXf7FtLELt7HCm47iBIuZ0UqKXoVbR2qn8 08+tetOvlDqKv/gbgwo4Zcc8XrNl2/YPH31DCr7HnvkNnyHFLEIezUFJ1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgAALF4wE6rRDoJ/2dsb2JhbABCmXWBao4cgQWBcgEBAQQICgEXED8MAQMCCQ8CBAEBAScHGSMKCQgBAQQTCxehQAGdOYl/BIgOhGcBmT4 X-IronPort-AV: E=Sophos;i="4.69,504,1315180800"; d="scan'208";a="13975673" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 14 Nov 2011 02:15:46 +0000 Received: from dwingWS (sjc-vpn4-650.cisco.com [10.21.82.138]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAE2FiJw025509; Mon, 14 Nov 2011 02:15:44 GMT From: "Dan Wing" To: "'Tom Taylor'" References: <004d01cca0d0$e72adf10$b5809d30$@com> In-Reply-To: Date: Mon, 14 Nov 2011 10:15:43 +0800 Message-ID: <01c701cca273$510da810$f328f830$@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: AcyhnzDyDwelYqztRgqA2I/2qzL/FgA0/jmg Content-Language: en-us Cc: multrans@ietf.org Subject: Re: [multrans] link to meeting slides for multrans BoF 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, 14 Nov 2011 02:15:47 -0000 > -----Original Message----- > From: Tom Taylor [mailto:tom111.taylor@bell.net] > Sent: Sunday, November 13, 2011 8:57 AM > To: Dan Wing > Cc: multrans@ietf.org > Subject: Re: [multrans] link to meeting slides for multrans BoF > > Below. > > On 11/11/2011 7:20 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] > On > >> Behalf Of Tom Taylor > >> Sent: Saturday, November 12, 2011 4:11 AM > ... > > > > Slide 8: yes, IPv6 and IPv4 on the access network is infeasible. I > mean, > > isn't the access network where everybody has insufficient bandwidth > for > > carrying the same traffic on both IPv6 and IPv4, isn't it? > > > [PTT] Sorry, I don't get the linkage between this and what the slide > says. The slide said something like "is it infeasible to run both IPv6 and IPv4 on the access link" -- or, at least, that is what I interpreted the slide to mean. If my interpretation is not the intent of the slide, the slide should probably be made clearer. -d > > > > -d > >... From tom111.taylor@bell.net Sun Nov 13 18:58:36 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 652AB11E8194 for ; Sun, 13 Nov 2011 18:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.641 X-Spam-Level: X-Spam-Status: No, score=-101.641 tagged_above=-999 required=5 tests=[AWL=0.155, 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 LF5zBMbpwVjV for ; Sun, 13 Nov 2011 18:58:35 -0800 (PST) Received: from blu0-omc4-s17.blu0.hotmail.com (blu0-omc4-s17.blu0.hotmail.com [65.55.111.156]) by ietfa.amsl.com (Postfix) with ESMTP id 6296611E8160 for ; Sun, 13 Nov 2011 18:58:35 -0800 (PST) Received: from BLU0-SMTP18 ([65.55.111.135]) by blu0-omc4-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Nov 2011 18:58:34 -0800 X-Originating-IP: [76.70.77.190] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([76.70.77.190]) by BLU0-SMTP18.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Nov 2011 18:58:34 -0800 Date: Sun, 13 Nov 2011 21:58:33 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Dan Wing References: <004d01cca0d0$e72adf10$b5809d30$@com> <01c701cca273$510da810$f328f830$@com> In-Reply-To: <01c701cca273$510da810$f328f830$@com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2011 02:58:34.0451 (UTC) FILETIME=[4C76FA30:01CCA279] Cc: multrans@ietf.org Subject: Re: [multrans] link to meeting slides for multrans BoF 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, 14 Nov 2011 02:58:36 -0000 Oops, I'll think about how to fix that up. The intended question was: - is it infeasible to have AF1 at the provider edge? - is it infeasible to have AF1 at the customer edge? - does one have an advantage over the other? On 13/11/2011 9:15 PM, Dan Wing wrote: >> -----Original Message----- >> From: Tom Taylor [mailto:tom111.taylor@bell.net] >> Sent: Sunday, November 13, 2011 8:57 AM >> To: Dan Wing >> Cc: multrans@ietf.org >> Subject: Re: [multrans] link to meeting slides for multrans BoF >> >> Below. >> >> On 11/11/2011 7:20 PM, Dan Wing wrote: >>>> -----Original Message----- >>>> From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] >> On >>>> Behalf Of Tom Taylor >>>> Sent: Saturday, November 12, 2011 4:11 AM >> ... >>> >>> Slide 8: yes, IPv6 and IPv4 on the access network is infeasible. I >> mean, >>> isn't the access network where everybody has insufficient bandwidth >> for >>> carrying the same traffic on both IPv6 and IPv4, isn't it? >>> >> [PTT] Sorry, I don't get the linkage between this and what the slide >> says. > > The slide said something like "is it infeasible to run both IPv6 > and IPv4 on the access link" -- or, at least, that is what I > interpreted the slide to mean. > > If my interpretation is not the intent of the slide, the slide > should probably be made clearer. > > -d > > > > >>> >>> -d >>> ... > > > From tom111.taylor@bell.net Sun Nov 13 18:59: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 C06D311E8198 for ; Sun, 13 Nov 2011 18:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.663 X-Spam-Level: X-Spam-Status: No, score=-101.663 tagged_above=-999 required=5 tests=[AWL=0.133, 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 ddAyHfknvT1Q for ; Sun, 13 Nov 2011 18:59:27 -0800 (PST) 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 163ED11E8197 for ; Sun, 13 Nov 2011 18:59:27 -0800 (PST) Received: from BLU0-SMTP60 ([65.55.111.136]) by blu0-omc4-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Nov 2011 18:59:22 -0800 X-Originating-IP: [76.70.77.190] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([76.70.77.190]) by BLU0-SMTP60.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Nov 2011 18:59:21 -0800 Date: Sun, 13 Nov 2011 21:59:20 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Jacni Qin References: <4EC0698C.9090308@jacni.com> In-Reply-To: <4EC0698C.9090308@jacni.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2011 02:59:21.0714 (UTC) FILETIME=[68A2BD20:01CCA279] Cc: "multrans@ietf.org" Subject: Re: [multrans] link to meeting slides for multrans BoF 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, 14 Nov 2011 02:59:27 -0000 As I understand it: Layer 3. On 13/11/2011 8:06 PM, Jacni Qin wrote: > hi, > > In multran-1, about the "IPv4 Access Network (not mcast capable)", do > you mean Layer2 or Layer3? > > > Cheers, > Jacni > > On 11/12/2011 3:24 AM, Tina TSOU wrote: >> Dear all, >> Here is the link to meeting slides for multrans BoF. >> http://www.ietf.org/proceedings/82/agenda/multrans.txt >> http://www.ietf.org/proceedings/82/slides/multrans-0.pdf >> http://www.ietf.org/proceedings/82/slides/multrans-1.ppt >> http://www.ietf.org/proceedings/82/slides/multrans-2.ppt >> http://www.ietf.org/proceedings/82/slides/multrans-3.ppt >> >> >> 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 jacni@jacni.com Sun Nov 13 19:09: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 63FAB1F0CB8 for ; Sun, 13 Nov 2011 19:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=0.215, 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 BdIKTKzbF-le for ; Sun, 13 Nov 2011 19:09:00 -0800 (PST) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 603251F0C94 for ; Sun, 13 Nov 2011 19:08:57 -0800 (PST) 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 C51AF380090 for ; Sun, 13 Nov 2011 22:08:55 -0500 (EST) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 59B603400E9 for ; Mon, 14 Nov 2011 11:08:52 +0800 (CST) Received: from [172.20.167.26] (unknown [221.11.61.6]) by app (Coremail) with SMTP id +AWowJBLiQczhsBOBGQKAA--.15332S2; Mon, 14 Nov 2011 11:08:38 +0800 (CST) Message-ID: <4EC086B4.1060408@jacni.com> Date: Mon, 14 Nov 2011 11:10:44 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Tom Taylor References: <4EC0698C.9090308@jacni.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010603080807000209060601" X-CM-TRANSID: +AWowJBLiQczhsBOBGQKAA--.15332S2 X-Coremail-Antispam: 1UD129KBjvdXoWrZw48WF15uFW3trWkCF47CFg_yoWkurc_CF 4xZ3y8Jr1UJrW7Kan3JrZFyr13Zr1jgw18JryDW3Zrur15Crs5trs3G3s8Gr18Ga4xKr1U AF1fKr1UCF43KjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUj4kYjxAI6xkYrwAYjxAI6xCIbckI1I0E57IF64kEYxAxM7k0a2IF 6F4UM7kC6x804xWl1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s1ln4vEF7Iv6F18KV Aqrcv_GVWUtr1rJF1ln4vE4IxY62xKV4CY8xCE548m6r4UJryUGwAawVCIc40E5I027xCE 548m6r1DJr4UtwAa7VCY0VAaVVAqrcv_Jw1UWr13McIj6xIIjxv20xvE14v26r1j6r18Mc Ij6I8E87Iv67AKxVWUJVW8JwACjcxG0xvEwIxGrwACjI8F5VAYr7xFoVCIc40_GwCjr7xv wVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFI7 vE0wC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0xZFpf9x 07jRPfdUUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQAMEko7lPRGLwAPso Cc: "multrans@ietf.org" Subject: Re: [multrans] link to meeting slides for multrans BoF 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, 14 Nov 2011 03:09:01 -0000 This is a multi-part message in MIME format. --------------010603080807000209060601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Re-, Sorry, I don't understand that, even in the native context, will it be used to deliver multicast services? Cheers, Jacni On 11/14/2011 10:59 AM, Tom Taylor wrote: > As I understand it: Layer 3. > > On 13/11/2011 8:06 PM, Jacni Qin wrote: >> hi, >> >> In multran-1, about the "IPv4 Access Network (not mcast capable)", do >> you mean Layer2 or Layer3? >> >> >> Cheers, >> Jacni >> >> On 11/12/2011 3:24 AM, Tina TSOU wrote: >>> Dear all, >>> Here is the link to meeting slides for multrans BoF. >>> http://www.ietf.org/proceedings/82/agenda/multrans.txt >>> http://www.ietf.org/proceedings/82/slides/multrans-0.pdf >>> http://www.ietf.org/proceedings/82/slides/multrans-1.ppt >>> http://www.ietf.org/proceedings/82/slides/multrans-2.ppt >>> http://www.ietf.org/proceedings/82/slides/multrans-3.ppt >>> >>> >>> 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 > --------------010603080807000209060601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Re-,

Sorry, I don't understand that, even in the native context, will it be used to deliver multicast services?


Cheers,
Jacni


On 11/14/2011 10:59 AM, Tom Taylor wrote:
As I understand it: Layer 3.

On 13/11/2011 8:06 PM, Jacni Qin wrote:
hi,

In multran-1, about the "IPv4 Access Network (not mcast capable)", do
you mean Layer2 or Layer3?


Cheers,
Jacni

On 11/12/2011 3:24 AM, Tina TSOU wrote:
Dear all,
Here is the link to meeting slides for multrans BoF.
http://www.ietf.org/proceedings/82/agenda/multrans.txt
http://www.ietf.org/proceedings/82/slides/multrans-0.pdf
http://www.ietf.org/proceedings/82/slides/multrans-1.ppt
http://www.ietf.org/proceedings/82/slides/multrans-2.ppt
http://www.ietf.org/proceedings/82/slides/multrans-3.ppt


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

--------------010603080807000209060601-- From dwing@cisco.com Sun Nov 13 19:14: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 CC9A21F0CB8 for ; Sun, 13 Nov 2011 19:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.714 X-Spam-Level: X-Spam-Status: No, score=-105.714 tagged_above=-999 required=5 tests=[AWL=0.885, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mF2EEm3v4QHQ for ; Sun, 13 Nov 2011 19:14:58 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4395A1F0CAD for ; Sun, 13 Nov 2011 19:14:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1988; q=dns/txt; s=iport; t=1321240498; x=1322450098; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=aclvkIpttFLEcqqjy5VgvZk5NvMnbvr0+rLNCRgxGyo=; b=gGSYy2TngwkmFkA6cLF5K60KTTZ6ulYr8N51aeRvXUYspomj1722u5V6 Jsf5Z17tP8OaxTGTVWW1kEMmrN66elc+a4Yh1SHQuOSu4GSB109x9SFzH eZJYHVav0ekK8Qeq+yaNfxJkxMkCjb8RAj3D6+jrHbF3SqZTAkgNLxvhS I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgAAGaGwE6rRDoH/2dsb2JhbABCmXeBao4cgQWBcgEBAQMBCAoBFxA/BQcBAwIJDwIEAQEBJwcZIwoJCAEBBBMLF4dgmWcBnT2JfwSIDoRnAZk+ X-IronPort-AV: E=Sophos;i="4.69,505,1315180800"; d="scan'208";a="13977228" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 14 Nov 2011 03:14:58 +0000 Received: from dwingWS (sjc-vpn4-650.cisco.com [10.21.82.138]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAE3EuNY010647; Mon, 14 Nov 2011 03:14:57 GMT From: "Dan Wing" To: "'Tom Taylor'" References: <004d01cca0d0$e72adf10$b5809d30$@com> <01c701cca273$510da810$f328f830$@com> In-Reply-To: Date: Mon, 14 Nov 2011 11:14:56 +0800 Message-ID: <021a01cca27b$969731f0$c3c595d0$@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: AcyieU370yh+FB+1SPawkxB7vU4nogAAhRPA Content-Language: en-us Cc: multrans@ietf.org Subject: Re: [multrans] link to meeting slides for multrans BoF 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, 14 Nov 2011 03:14:58 -0000 > -----Original Message----- > From: Tom Taylor [mailto:tom111.taylor@bell.net] > Sent: Monday, November 14, 2011 10:59 AM > To: Dan Wing > Cc: multrans@ietf.org > Subject: Re: [multrans] link to meeting slides for multrans BoF > > Oops, I'll think about how to fix that up. The intended question was: > - is it infeasible to have AF1 at the provider edge? > - is it infeasible to have AF1 at the customer edge? > - does one have an advantage over the other? Will there be a mix of customers with, and without, AF1? E.g., "legacy" customers who have not purchased or have not installed AF1? The answer to that question influences the answer to your question significantly. -d > On 13/11/2011 9:15 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: Tom Taylor [mailto:tom111.taylor@bell.net] > >> Sent: Sunday, November 13, 2011 8:57 AM > >> To: Dan Wing > >> Cc: multrans@ietf.org > >> Subject: Re: [multrans] link to meeting slides for multrans BoF > >> > >> Below. > >> > >> On 11/11/2011 7:20 PM, Dan Wing wrote: > >>>> -----Original Message----- > >>>> From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] > >> On > >>>> Behalf Of Tom Taylor > >>>> Sent: Saturday, November 12, 2011 4:11 AM > >> ... > >>> > >>> Slide 8: yes, IPv6 and IPv4 on the access network is infeasible. > I > >> mean, > >>> isn't the access network where everybody has insufficient bandwidth > >> for > >>> carrying the same traffic on both IPv6 and IPv4, isn't it? > >>> > >> [PTT] Sorry, I don't get the linkage between this and what the slide > >> says. > > > > The slide said something like "is it infeasible to run both IPv6 > > and IPv4 on the access link" -- or, at least, that is what I > > interpreted the slide to mean. > > > > If my interpretation is not the intent of the slide, the slide > > should probably be made clearer. > > > > -d > > > > > > > > > >>> > >>> -d > >>> ... > > > > > > From tom111.taylor@bell.net Sun Nov 13 19:17:41 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 759451F0C5F for ; Sun, 13 Nov 2011 19:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.68 X-Spam-Level: X-Spam-Status: No, score=-101.68 tagged_above=-999 required=5 tests=[AWL=0.116, 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 UzIaUzrUy+lR for ; Sun, 13 Nov 2011 19:17:40 -0800 (PST) Received: from blu0-omc4-s10.blu0.hotmail.com (blu0-omc4-s10.blu0.hotmail.com [65.55.111.149]) by ietfa.amsl.com (Postfix) with ESMTP id EF59F1F0C47 for ; Sun, 13 Nov 2011 19:17:39 -0800 (PST) Received: from BLU0-SMTP54 ([65.55.111.136]) by blu0-omc4-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Nov 2011 19:17:39 -0800 X-Originating-IP: [76.70.77.190] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([76.70.77.190]) by BLU0-SMTP54.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Nov 2011 19:17:38 -0800 Date: Sun, 13 Nov 2011 22:17:37 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Jacni Qin References: <4EC0698C.9090308@jacni.com> <4EC086B4.1060408@jacni.com> In-Reply-To: <4EC086B4.1060408@jacni.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2011 03:17:38.0582 (UTC) FILETIME=[F66B8360:01CCA27B] Cc: "multrans@ietf.org" Subject: Re: [multrans] link to meeting slides for multrans BoF 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, 14 Nov 2011 03:17:41 -0000 They'll be delivered over the access network in unicast form. On 13/11/2011 10:10 PM, Jacni Qin wrote: > Re-, > > Sorry, I don't understand that, even in the native context, will it be > used to deliver multicast services? > > > Cheers, > Jacni > > > On 11/14/2011 10:59 AM, Tom Taylor wrote: >> As I understand it: Layer 3. >> >> On 13/11/2011 8:06 PM, Jacni Qin wrote: >>> hi, >>> >>> In multran-1, about the "IPv4 Access Network (not mcast capable)", do >>> you mean Layer2 or Layer3? >>> >>> >>> Cheers, >>> Jacni >>> >>> On 11/12/2011 3:24 AM, Tina TSOU wrote: >>>> Dear all, >>>> Here is the link to meeting slides for multrans BoF. >>>> http://www.ietf.org/proceedings/82/agenda/multrans.txt >>>> http://www.ietf.org/proceedings/82/slides/multrans-0.pdf >>>> http://www.ietf.org/proceedings/82/slides/multrans-1.ppt >>>> http://www.ietf.org/proceedings/82/slides/multrans-2.ppt >>>> http://www.ietf.org/proceedings/82/slides/multrans-3.ppt >>>> >>>> >>>> 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 bingxuere@gmail.com Mon Nov 14 06:38:32 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 236DA11E810A for ; Mon, 14 Nov 2011 06:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.349, 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 vlBvxW0wGorb for ; Mon, 14 Nov 2011 06:38:29 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC2EC11E8090 for ; Mon, 14 Nov 2011 06:38:26 -0800 (PST) Received: by iaeo4 with SMTP id o4so9425250iae.31 for ; Mon, 14 Nov 2011 06:38:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=VIsiUTNl2TSgYRGuYvwqc2qGQZ/7Z6OUVh2IGlH6+8Y=; b=H6dtcWhmMmnR8zxzQUTkrbeHgrGTg3i7pzAQY/MJEgwDvXMFS1oG0RlVWy3EgQPUBR KKSJXbmMLTk7cwZSsqzNF23mk63QNYcZkzzhONL+ntBna39rnFYDajZ9oh+8Aq8g1+zE +LzQoF5e1YhkB0Yun80bi3yzodiUpFJ3ypIFA= Received: by 10.42.161.132 with SMTP id t4mr22693607icx.16.1321281506241; Mon, 14 Nov 2011 06:38:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.223.197 with HTTP; Mon, 14 Nov 2011 06:37:45 -0800 (PST) From: Qiong Date: Mon, 14 Nov 2011 22:37:45 +0800 Message-ID: To: multrans@ietf.org Content-Type: multipart/alternative; boundary=90e6ba6e8356d3ec6904b1b2d227 Subject: Re: [multrans] link to meeting slides for multrans BoF 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, 14 Nov 2011 14:38:32 -0000 --90e6ba6e8356d3ec6904b1b2d227 Content-Type: text/plain; charset=UTF-8 Hi Jacni, In our use case, the IPv4 access network means layer2 network, which possibly do not support MLD snooping. Best regards Qiong **** *From:* Jacni Qin [mailto:jacni@jacni.com] *Sent:* Monday, November 14, 2011 9:06 AM *To:* Tina TSOU *Cc:* multrans@ietf.org *Subject:* Re: [multrans] link to meeting slides for multrans BoF**** **** hi, In multran-1, about the "IPv4 Access Network (not mcast capable)", do you mean Layer2 or Layer3? Cheers, Jacni --90e6ba6e8356d3ec6904b1b2d227 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

In our use case, the IPv4 access network means layer2 network, wh= ich possibly do not support MLD snooping.

Best regards

Qiong= <= p style=3D"color: rgb(80, 0, 80); ">

=C2=A0

From:=C2=A0Jacni Qin [mailto:ja= cni@jacni.com]=C2=A0
Sent:=C2=A0Monday, November 14, 2011 9:06 AM
To:=C2=A0Tina= TSOU
Cc:=C2=A0multrans@ietf.org
Subjec= t:=C2=A0Re: [multrans] link to meeting slides for multrans BoF

=C2=A0=

hi,

In multran-1, about the "IPv4 Access Network (not mcast ca= pable)", do you mean Layer2 or Layer3?


Cheers,
Jacni

 --90e6ba6e8356d3ec6904b1b2d227-- From jacni@jacni.com Mon Nov 14 17:19: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 4A5331F0CCA for ; Mon, 14 Nov 2011 17:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] 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 UakNEZL8svgt for ; Mon, 14 Nov 2011 17:19:03 -0800 (PST) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id CB67E1F0C7D for ; Mon, 14 Nov 2011 17:19:03 -0800 (PST) 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 B3E6E3800D4 for ; Mon, 14 Nov 2011 20:19:02 -0500 (EST) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 71D4B340099 for ; Tue, 15 Nov 2011 09:18:59 +0800 (CST) Received: from [172.18.171.158] (unknown [221.11.61.15]) by app (Coremail) with SMTP id +AWowJB7BQr3vcFOcXILAA--.11400S2; Tue, 15 Nov 2011 09:18:56 +0800 (CST) Message-ID: <4EC1BE75.6050003@jacni.com> Date: Tue, 15 Nov 2011 09:20:53 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Qiong References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020803060200030407000405" X-CM-TRANSID: +AWowJB7BQr3vcFOcXILAA--.11400S2 X-Coremail-Antispam: 1UD129KBjvdXoW7Xw1DJF4kWF45CFWfCryxuFg_yoWfJrb_Gr 4kZry8Gw18AayxKrsrtrZ0yr1fZw1jgw1xAa4DC3yxur1Skr1ftrn5Kr90q34fKFWUtr9r Xr1fKryUCF4a9jkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUjz8YjxAI6xkYrwAYjxAI6xCIbckI1I0E57IF64kEYxAxM7k0a2IF 6F1UM7kC6x804xWl1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s1ln4vEF7Iv6F18KV Aqrcv_GVWUtr1rJF1ln4vE4IxY62xKV4CY8xCE548m6r4UJryUGwAawVCIc40E5I027xCE 548m6r1DJr4UtwAa7VCY0VAaVVAqrcv_Jw1UWr13McIj6xIIjxv20xvE14v26r1j6r18Mc Ij6I8E87Iv67AKxVWUJVW8JwACjcxG0xvEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2 V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFI7vE0wC2zVAF1VAY17CE14v26r 1Y6r17MIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0xZFpf9x07jgcTQUUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQAMEko7lPRGLwAhsG Cc: multrans@ietf.org Subject: Re: [multrans] link to meeting slides for multrans BoF 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, 15 Nov 2011 01:19:04 -0000 This is a multi-part message in MIME format. --------------020803060200030407000405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Re-, Sorry, I'm confused. Anyway, IMHO the transition use case won't be that complex, like "... -6-4-6-4-6-4-X-X- ..." The "X-Y" and "X-Y-X" are more than sufficient for the current discussion. Cheers, Jacni On 11/14/2011 10:37 PM, Qiong wrote: > > Hi Jacni, > > In our use case, the IPv4 access network means layer2 network, which > possibly do not support MLD snooping. > > Best regards > > Qiong > > > *From:* Jacni Qin [mailto:jacni@jacni.com ] > *Sent:* Monday, November 14, 2011 9:06 AM > *To:* Tina TSOU > *Cc:* multrans@ietf.org > *Subject:* Re: [multrans] link to meeting slides for multrans BoF > > hi, > > In multran-1, about the "IPv4 Access Network (not mcast capable)", do > you mean Layer2 or Layer3? > > > Cheers, > Jacni > > > > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans --------------020803060200030407000405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Re-,

Sorry, I'm confused.
Anyway, IMHO the transition use case won't be that complex, like "... -6-4-6-4-6-4-X-X- ..."
The "X-Y" and "X-Y-X" are more than sufficient for the current discussion.


Cheers,
Jacni


On 11/14/2011 10:37 PM, Qiong wrote:

Hi Jacni,

In our use case, the IPv4 access network means layer2 network, which possibly do not support MLD snooping.

Best regards

Qiong


 

From: Jacni Qin [mailto:jacni@jacni.com] 
Sent: Monday, November 14, 2011 9:06 AM
To: Tina TSOU
Cc: multrans@ietf.org
Subject: Re: [multrans] link to meeting slides for multrans BoF

 

hi,

In multran-1, about the "IPv4 Access Network (not mcast capable)", do you mean Layer2 or Layer3?


Cheers,
Jacni

 

_______________________________________________
multrans mailing list
multrans@ietf.org
https://www.ietf.org/mailman/listinfo/multrans
--------------020803060200030407000405-- From stig@venaas.com Tue Nov 15 00:33:38 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 6B51921F8DCC for ; Tue, 15 Nov 2011 00:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, 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 ckaKa8x97QMi for ; Tue, 15 Nov 2011 00:33:37 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id A2B3921F8DC8 for ; Tue, 15 Nov 2011 00:33:37 -0800 (PST) Received: from [10.21.76.249] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 6490F7FF0; Tue, 15 Nov 2011 09:33:33 +0100 (CET) Message-ID: <4EC223D3.8010308@venaas.com> Date: Tue, 15 Nov 2011 00:33:23 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Tom Taylor References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "multrans@ietf.org" Subject: Re: [multrans] link to meeting slides for multrans BoF 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, 15 Nov 2011 08:33:38 -0000 On 11/11/2011 3:58 PM, Tom Taylor wrote: > I can add the slide, but Stig, what additional issues are currently > missing? I'm sorry for not having had time to check the list and follow up on this. I'm not sure if I see any issues missing, it's more that all the scenarios appear to have at least 2 AFs, although I believe the most needed scenario is just a single AF where the source is of one address family, and the receivers can be a mix. Something like this: IPv4 Receiver ----- \ ...... IPv4 source / IPv6 Receiver - - AF When presenting this, I think it might be good to explain this most simple scenario before the more complex ones. Stig > > On 11/11/2011 5:22 PM, Tina TSOU wrote: >> Tom, Per discussion with Stig yesterday, the framework draft >> considers a single translator, which he think is a useful scenario >> not in the current version of issues slides. >> >> >> 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 Tom Taylor Sent: >> Friday, November 11, 2011 12:11 PM To: multrans@ietf.org Subject: Re: >> [multrans] link to meeting slides for multrans BoF >> >> The current set of "Issues" charts is at multrans-2. Do people have >> comments? >> >> On 11/11/2011 2:24 PM, Tina TSOU wrote: >>> Dear all, Here is the link to meeting slides for multrans BoF. >>> http://www.ietf.org/proceedings/82/agenda/multrans.txt >>> http://www.ietf.org/proceedings/82/slides/multrans-0.pdf >>> http://www.ietf.org/proceedings/82/slides/multrans-1.ppt >>> http://www.ietf.org/proceedings/82/slides/multrans-2.ppt >>> http://www.ietf.org/proceedings/82/slides/multrans-3.ppt >>> >>> >>> 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 Sat Nov 19 15:29:02 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 CB4F521F858C for ; Sat, 19 Nov 2011 15:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.43 X-Spam-Level: * X-Spam-Status: No, score=1.43 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 NjhZ1qaFk-Ma for ; Sat, 19 Nov 2011 15:29:02 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id F2E1B21F8586 for ; Sat, 19 Nov 2011 15:29:01 -0800 (PST) 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 <0LUX00K1HL8763@szxga03-in.huawei.com> for multrans@ietf.org; Sun, 20 Nov 2011 07:28:55 +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 <0LUX009K4L87MH@szxga03-in.huawei.com> for multrans@ietf.org; Sun, 20 Nov 2011 07:28:55 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFF06792; Sun, 20 Nov 2011 07:28:32 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 20 Nov 2011 07:28:21 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Sun, 20 Nov 2011 07:28:24 +0800 Date: Sat, 19 Nov 2011 23:28:23 +0000 From: Tina TSOU X-Originating-IP: [10.212.244.23] 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: Something I forgot to speak to the mic Thread-index: AcynEuqgyvtLJqTaTy2EwshREX/98Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AG2t APD8 BEm4 CJex DJNy Dl4Q EVhE E19G FywN GFts GYN/ Gvun HONu IOP7 Iyzj I+vd; 1; bQB1AGwAdAByAGEAbgBzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {952DFC45-0511-4C55-B979-F9A7F5DFA007}; dABpAG4AYQAuAHQAcwBvAHUALgB6AG8AdQB0AGkAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Sat, 19 Nov 2011 23:28:18 GMT; UwBvAG0AZQB0AGgAaQBuAGcAIABJACAAZgBvAHIAZwBvAHQAIAB0AG8AIABzAHAAZQBhAGsAIAB0AG8AIAB0AGgAZQAgAG0AaQBjAA== x-cr-puzzleid: {952DFC45-0511-4C55-B979-F9A7F5DFA007} X-CFilter-Loop: Reflected Subject: [multrans] Something I forgot to speak to the mic 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, 19 Nov 2011 23:29:02 -0000 Hi all, There is something I forgot to speak to the mic. Through the discussion in the BoF, it is clear that it is more or less translation + ops. Why should it be done in SOFTWIRE which is encapsulation? Multrans doesn't step onto softwire's toes. It also doesn't step onto MBONED's toes as well. One set of technology can do its own ops, not have to send it to separate ops WG. For example, in this meeting, IETF decides CGN MIB is done in WG behave, not WG Opsawg. Anyway, I'm ready to contribute to futhur technical drafts. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From gjshep@gmail.com Tue Nov 22 16:42:00 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 7DD8811E8098 for ; Tue, 22 Nov 2011 16:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, 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 r7LXrNUVEdUT for ; Tue, 22 Nov 2011 16:41:59 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 87B1111E8089 for ; Tue, 22 Nov 2011 16:41:58 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so545666bkb.31 for ; Tue, 22 Nov 2011 16:41:56 -0800 (PST) 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=WFxrxI3RnUWi1eBsehmHEpOsAKdzPbAXklkK75vOpIY=; b=xP3smKk5CtvsBUS3XvgaiG5EAv0pDVHdP0RaCK2VdDTvSv7U7ggokX3uGhqYTNF/pJ NLQyQaq/soIh1cx0PdcNg1fVTCsk66E7c1taGzM0gD1/6zcf070+Ix3FZHvK1KcWA5+t Hj3ju3jbMk4J5zNjbE7ooO/CbN95pvU9LTBtA= MIME-Version: 1.0 Received: by 10.204.132.78 with SMTP id a14mr18371003bkt.15.1322008916349; Tue, 22 Nov 2011 16:41:56 -0800 (PST) Received: by 10.204.79.5 with HTTP; Tue, 22 Nov 2011 16:41:56 -0800 (PST) In-Reply-To: References: <20111121200358.GP19998@cisco.com> Date: Tue, 22 Nov 2011 16:41:56 -0800 Message-ID: From: Greg Shepherd To: Tina TSOU , multrans@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "eckert@cisco.com" , Susan Hares Subject: Re: [multrans] Multrans Miniutes 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, 23 Nov 2011 00:42:00 -0000 Please keep the multrans mail list on the distribution of all things related to multrans. Thanks, Greg On Tue, Nov 22, 2011 at 4:29 PM, Tina TSOU w= rote: > Toerless, Marshall, > Some supplements from my memory and Tom's audio record: > 1. The part of "Spencer Dawkin: ..." is something like this if I remember= corectly: > "Twenty people want to do SOMETHING, and maybe three people don't think w= e should, so we should do SOMETHING". > > 2. Dave Thaler said > "how multicast addresses are discovered on each side of the address famil= y boundary." > > 3. There are 10 in the room + 1 in the jabber said "working group, then i= nterim meeting", not 9+1. > When Greg counted 10 in the room, then I said from the my seat "Tom said = 'I will break the tie' in the jabber", Greg said "I don't understand what u= said", sorry about my Chinese accent. > > Tina > > > -----Original Message----- > From: Tina TSOU > Sent: Monday, November 21, 2011 4:55 PM > To: 'eckert@cisco.com' > Cc: Marshall Eubanks; Greg Shepherd; Ron Bonica; Susan Hares > Subject: RE: Multrans Miniutes > > Thank you, Toerless. > > " Tina: work coming from group of people taking multicast work identified > =A0out of behave, then derived the use cases etc. and figured that it > =A0touches multiple areas and that's why they feel this justifies a WG." > > Can you rephrase what I said in the meeting as following which I remember= ed, > " Tina: work coming from group of people taking multicast work identified > =A0out of behave, then derived the problem and use cases, priority of iss= ues etc. > =A0it was everything in Prague, then strip encapsulation in Quebec, and n= ow its translation + ops, > =A0figured that it touches BEHAVE, MBONED, V6OPS and PIM and that's why t= hey feel this justifies a WG." > > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > -----Original Message----- > From: eckert@cisco.com [mailto:eckert@cisco.com] > Sent: Monday, November 21, 2011 12:04 PM > To: Tina TSOU > Cc: Marshall Eubanks; Greg Shepherd; Ron Bonica; Susan Hares > Subject: Re: Multrans Miniutes > > I had sent my minutes after the meeting directly to greg. Sorry, > couldn't remember marshalls mail. > > Appended. > > Cheers > =A0 =A0Toerless > > > Agenda: > > Drafts: > > Problem statement draft > > Framework for IPv4/IPv6 Multicast Translation > > Multicast Proxy in IPv4/IPv6 Transition > > Agenda > > Welcome/Agenda bash/Minutes > > Stig: =A0Item missing. > > Marshall: This is multicast IPv4 to IPv4 transition BOF, NOT TRANSLATION. > > Greg: less people here in BOF than last time. > > Alain Durand: lot of this work has been done in Softwire > Greg: but this is transition, not translation. > > Framework for IPv4/IPv6 Multicast Translation : Stig Venaas > =A0draft-venaas-behave-v4v6mc-framework-03.txt > > =A0Slide 2: Overview: > =A0- behave did a unicast translation framework, RFC6144 > =A0- this draft started as a multicast version of that > =A0- ... > > =A0Slide 3: Scenarios > =A0- IPv4/IPv6 network/sender/receiver <-> > > =A0Slide 4: Multicast and translation > > =A0Slide 5: IPv6 nework receiving multicast from IPv4 Internet > > =A0Slide 6: IPv6 network receiving multicast from IPv4 Internet > > =A0Slide 7: Well-known multicsat prefix(es)? > > =A0Slide 8: IPv4 network receiving multicast from IPv6 Internet > > =A0Slide 9: New signaling mechanisms > > =A0Greg: TOS translation ? > =A0Stig: Should probably match the unicast translation itis using. > > =A0DaveT(haler): Want mapping to be the same as unicast mapping if > =A0unicast packets are sent to the source. Problem is slightly harder > =A0than the simplre unicast case. Unicast: How do you get the =A0address. > =A0Unicast addresses can be learned via DNS. In multicast you are usually > =A0joined with literal addresses. > > =A0Greg: This is an SSM question. > =A0Greg: It is less a translation than a location. > =A0Dave: Right, eg: follow the default-route. > > =A0Stig: Document has case where unicast translation is different from > =A0multicast translation for example when paths are different. > =A0Dave: Have an idea here, but depends on what is needed by use cases. > > =A0Ron Bonica: You said stateful is almost impossible. This needs some > =A0qualification. Eg: limiting the groupa address =A0space makes this > =A0fairly simple. Even the IPv4 address space is much larger than what's > =A0needed, so only a small address range may need to be mapped. > > =A0Stig: Agreed if you can limit yourself to known prefixes. For example > =A0as a content provider. > > =A0Ron: Given how new IPv6 multicast is, we should hopefully be able to e= nforce > =A0this addressing limitation. > > =A0Sue Hares: Did i understand correctly that only small set of addresses > =A0are mapped ? This is the address translation function only ? > > =A0Dave: Summary unicast of BEHAVE: Statefull and stateless. A small > =A0range of v6 can be mapped to v4 stateless, otherwise statefull is need= ed. > > =A0Ron: Translator can work in two ways: Statically join to everything > =A0or only join dynamically. > > =A0Stig: For dynamic mode you first need the joins to reach you, so you m= ay > =A0need to be an RP if ASM is used. > > =A0Ron: DM do not need to talk about, but SM is interesting. > > =A0Chairs: Primary use case is SSM. > > =A0Unintelligble discussion about how sources vs. groups are discovered > =A0(both in SDP). > > =A0Hitoshi: Question: SDP related. Thinks it is not really a good idea > =A0to change SDP. Should not change data in it. > > =A0Second question: is there for translation =A0negotiation ? > =A0Stig: difficult. > > =A0Toerless: SDP is translated also in unicast solutions. > > Use Cases : China Telecom : Oian Wang : 15 minutes > > =A0Slide 1: 6-6-4 Case > =A0Slide 2: 6-4-6-4 Case > > =A0 =A0Marc Blanchet: for 6-4-6-4 was there an IPv4 network that was repl= aced by an > =A0 =A0 =A0 =A0 IPv6 network. > =A0 =A0Presenter: Actually dual-core network. > =A0 =A0Marc Blanchet: Why then use IPv6 transport instead of native IPv4 > =A0 =A0Presenter: ... > > =A0 =A0Tina: This is the IPTV network, IPv6 only. > > =A0 =A0Dave: blue on the let and right connected by non IPv4 mcast should > =A0 =A0mean 6 over 4 across the non mcast capable ipv4 network. > > =A0 =A0Ron: Special case of first case. > > =A0 =A0Tina: explains old equipment causing secon > > =A0 =A0Toerless: On first slide, what additional signaling/data goes betw= een > =A0 =A0v4 source and v6 network ? RTCP, SDP, RTSP, EPG, anything else. > > =A0 =A0Presenter: Need to get back to you. > > =A0 =A0Dave: was this all the use cases ? > > =A0 =A0Tina: Just the use-cases from china telecom. SOmewhat more general= ized > =A0 =A0from actual customer case. > > Use Cases : France Telecom : Christian Jacquenet > > =A0Slide 1: Context > =A0 =A0- Choose to deploy DSliste for new STB that can't get a unique IPv= 4 > =A0 =A0 =A0address anymore. > =A0Slide 2: 4-6-4 > > =A0 =A0Toerless: SSM ? - Yes > > =A0 =A0Stig: WIll there also be IPv6 receivers ? - Yes > =A0 =A0 Stig: So tunneling is not a good option. > > =A0 =A0Ron: DSlite means tunneling through the v6 network ??? - No! > =A0 =A0 =A0Christian: No tunneling anywhere > > =A0 =A0 =A0specific use case detail: DSlite required. > =A0 =A0 =A0otherwise same use case as china telekom ? > > =A0 =A0Toerless: USe case definition should more explicitly include > =A0 =A0 descriptoin also of native receivers to make sure it is taken int= o > =A0 =A0 account (not only the receivers requring translation/transition). > > =A0 =A0Marshall: Asking whether static translation is done. > =A0 =A0Christian: This is just use case, not solution, but that exactly > =A0 =A0is discussed as addition for multicast to DSlite. > > =A0 =A0Marshall: How about additional IPv6 sources intot he IPv6 cloud, > =A0 =A0this would complicate the problem. > > =A0 =A0Christian: Yes, when there are IPv6 sources, there should not be a= ny > =A0 =A0more DSlite then anymore, but only native IPv6 service. > =A0 =A0Only want to address very short term constraints. Just because of > =A0 =A0insufficicent short term roadmaps of STB vendors. > > =A0 =A0Marshall: I can also see solutions if there are IPv6 sources in th= e > =A0 =A0network. > > =A0 =A0Christian: But we want to avoid that context. > > =A0 =A0Marc: Very similar to cases in before. > > =A0 =A0Stig: possible solution: Lets make all IPv6 sources send to well > =A0 =A0defined IPv4 prefixes that map to IPv4. > > =A0 =A0Christian: There is a demo of this in the terminal room. > > =A0 =A0Dave Thaler: Is there a requirement that the addressing after two > =A0 =A0times translation is again the same as the original ? > > =A0 =A0Marshall: there is a difference between requirement and having thi= s > =A0 =A0be done as an option. > > =A0 =A0Dave: Has to do a lot with how the receiver learns about the sourc= e/group. > =A0 =A0Would constrain set of options if it was a requirement for address= es to > =A0 =A0be the same. > > =A0 =A0Spencer Dawkin: ... > > Multrans Issues : Eubanks : 20 minutes > > =A0Network example 1: IPvX-IPvY-IPvY > > =A0 =A0Toerless: do we really need this, this is transition, so the > =A0 =A0evolution of the network is v4 to v6. > > =A0 =A0Marshall: There can be a lot of combination of v4 to v6 or vice ve= rsa > =A0 =A0along the path. > > =A0 =A0Ron: Find it easy to believe to add v6 receivers. Find it easy to > =A0 =A0believe v6 network to v4 receivers. =A0Have hard time to consider = adding > =A0 =A0v4 receivers to v6 sources/v6 network. > > =A0 =A0Marshall: Want to flesh this out. Have representation of two opera= tors. > =A0 =A0Christian: agree with ROns comments. Can constrain the set of opti= ons. > > =A0 =A0Stig: Y=3D4 is most useful for now. Also important to have support= for > =A0 =A0mix of receivers. > > =A0 =A0Alain Durand: Reality is that there is a very popular vendor of > =A0 =A0sources with no plan to go to IPv6. Receiver today are now IPv4. > =A0 =A0There may be v6 receivers in the future > > =A0 =A0Marc: Have taled about this for days and days and days. I am a fir= m > =A0 =A0believe that we continue to talk about this. Need much more time > =A0 =A0to agree on scenario. Just consider it may take a long time. > > =A0 =A0Dan Wing: It took BEHAVE 5 hours to just conclude on the set of > =A0 =A0cases and then prioritize. > > =A0Content walk thhrough > > =A0 =A0DaveT: Setp 0 is missing. How do you figure out the channel that > =A0 =A0had to be put into step 1. > > =A0Content Distribution walk thhrough > > =A0Slide 6: Issues (1) > > =A0 =A0Stig: Key thing is that it should be a standard mapping. > > =A0 =A0Ron: Given how all sources start as v4, we should use stateless mo= del. > > =A0Slide 7: Issues (2) > > =A0 =A0Stig: Should not assume the translation is an ALG. > > =A0 =A0Discussion about AF and ALG terminology. > > =A0 =A0Dave: AF and ALG boxes may not need to be the same box. Is that wh= at > =A0 =A0was meant by Stig in before ? > > =A0 =A0Dan Wing: ALG - Application Layer Gateway: Examining and Modifying > =A0 =A0application layer payload in signaling. The more complex it is the > =A0 =A0harder the ALG job becomes. > > =A0 =A0Marshal: Is multicast immune to this problem ? Classical signaling= ? > > =A0 =A0Dan: How classical do we become here ? SAP ? HTTP, HTTPs ? > > =A0 =A0Ron: We probably don't tal about an ALG here. Just relays data-pla= ne > =A0 =A0between v4/v6. > > =A0 =A0Stig: DOn't want to argue too much but keep it open what the AF > =A0 =A0function is doing. > > =A0 =A0Spencer: ... ? > > =A0 =A0Hitoshi: ... > > =A0 =A0Toerless: Difficult part is when addresses in EPG need to be chang= ed > =A0 =A0or otherwise application backends need to be aware of mapping of > =A0 =A0v4/v6 addresses. > > =A0 =A0Dave: The primary issue you haven't gotten to is how to learn > =A0 =A0T(S) and T(G). Possible answers: a) proprietary -> non IETF. > =A0 =A0b) assume signle discovery protocol, eg: DNS in Unicast. And then > =A0 =A0do ALG for that protocol. c) most likely: STB also have no plans > =A0 =A0to move to IPv6. Information receiver gets is exactly what the sou= rce > =A0 =A0thinks. Even if it is in a different address family than the sourc= e, > =A0 =A0and make that work. > > =A0 =A0Marshal: back up. v4 source, v6 receiver. Application gets v4 addr= ess > =A0 =A0information. Receiver then needs to apply magic. > > =A0 =A0Dave: In category 3 either the application needs to do this magic > =A0 =A0or the OS/stack. > > =A0 =A0Marshal: yes. > > =A0 =A0Dave: > > =A0 =A0Toerless: category 4 ? Eg: can't change the app on the client, can= 't > =A0 =A0change the stack, so mayube instead of then actually having an > =A0 =A0IPv6 only receiver, we make it a dual stack client behind eg: DSli= te, > =A0 =A0and IPv4 is only used to receive multicast. > > =A0 =A0Discussion Marshal/Dave. Not clear what is fully in scope. > =A0 =A0Marshall: DOn't want to discuss web design. > =A0 =A0Dave: This excludes case a) > > =A0 =A0Marshal: What makes it proprietaary to use a web-page ? > =A0 =A0Dave: Because of the required ALG. > > =A0 =A0Marc: May actually want to device SDP ALG. > > =A0 =A0Dave: SDP my itself is not a protocol, it's just a data-model that > =A0 =A0needs to be carried in a transport. And then yes, this could be > =A0 =A0category a) or b). > > =A0 =A0Marshal: not supposed to solve this. > > =A0Network Example 2: IPvX-IPvY-IPvX > > =A0 =A0Marshal: Should this not done via a mechanism like softwires ? > > =A0 =A0Toerless/Dave: Discuss unicast only use case of china telecom, > =A0 =A0agree AMT would be appropriate, but this may not even need to > =A0 =A0be in scope for this BOF/WG ? > > =A0 =A0Marc: Are we ever getting to discuss whether to make a owrking gro= up ? > > Room discussion : Proposed Multrans Charter and nex steps : Remaining tim= e > > =A0Marshal: There seems to be energy to work on this. Raise hand if > =A0 you are willing to work on this. > =A018 in room +1 on jabber raise hand. > > =A0Alain: There is already work chartered in another working group > =A0softwires. > > =A0Dave: This BOF is a spinoff of the BEHAVE working group. Needs NAT > =A0and multicast experts together. This work would not overlap with BEHAV= E. > > =A0Alain is chair of softwires. > > =A0Marshal: Is this overlapping with softwires. > > =A0Alain: Very large overlap. > > =A0Stig: Softwires is limited to only encapsulation. > > =A0Greg: There is also the mesh draft which is not encapsulation. > > =A0Greg: We need to collect what's missing from the work of other WGs. > > =A0Marshal: Do we feel there is sufficient difference between softwires > =A0and what could be worked on in a to be formed WG ? > > =A0Dave: Suggest different question: Do people have enough information > =A0if this a tractable problem. Primarily discovery is the biggest proble= m. > =A0Fairly good confidence that data translation solution can be worked ou= t. > > =A0Greg: DSlite, softwires, right. Data is not the issue. > > =A0Marc: Focussing on which use case to work on requires dedicated time. > =A0after that is done, we will have a good idea whether we need a WG. > > =A0Stig: This work could be first done in MBONED WG. > > =A0Alain: One bit in softwires that is not fully fleshed is the translati= on > =A0piece. What was not discussed/figured out is discovery. > > =A0Toerless: Start discussing use-cases in mboned, review, recommend > =A0solution elements for them. Take existing work in other WGs into accou= nt > =A0(softwires). Figure out missing pieces. SImple pieces like translation > =A0could even be done in MBONED. > > =A0Greg: Alain suggesting interim meeting of dedicated group of people > =A0doen by chair of group hosting work (eg: Alain -> softwires). > =A0Identify piece missing, then forward those to MBONED. > > =A0Greg: Interim meeting did not do multicast work. Suggest to do a > =A0multicast-only interim softwires WG. > > =A0Alain: Yes. > > =A0Ron: Suggests joint interim softwires/mboned meting, parse out which > =A0parts are to be resolved where. > > =A0Tina: Work here is related to many WGs.a Better to have a single dedic= ated > =A0working group. > > =A0Stig: Work wostly limited to mboned. > > =A0Ron: WOuld likely need STB people involved. > > =A0Greg: Will not have all technical people if it's only done in mboned. > > =A0Stig: Issue is how to get right people together. Need people who are > =A0not in mboned involved. Need to get enough time for this, can't not be > =A0pushed off. > > =A0Greg: Interim meeting to come up with conclusion. > > =A0Tina: can we go through four slides of proposed charter. > =A0 - walking through four proposed goals > =A0 =A0 - requirements > =A0 =A0 - alg > =A0 =A0 - translation > =A0 =A0 - configuration and management > > =A0Alain: To early because we are not forming a WG. > > =A0Dave: vote for webex, primarily mboned, also behave, see little > =A0overlap with softwires. encap is softwires expertise. > > =A0Alain: Expertise of softwires is use cases described by Christian. > > =A0Dave: would like to see at least to se one internet draft on how > =A0the discovery is done before forming a working group. Even if it's > =A0not the best idea, but proof of exstance of a possible solution to the > =A0discovery would be needed first. > > =A0Tina: work coming from group of people taking multicast work identifie= d > =A0out of behave, then derived the use cases etc. and figured that it > =A0touches multiple areas and that's why they feel this justifies a WG. > > =A0Marc: proposes the interim. ALso a believer that after the focus > =A0session not everything will be done. Also fear that it will spread > =A0all over the place. A dedicated working group could help to keep > =A0the architecture in one place. Otherwise we will get a puzzle solution= . > > =A0Christian: Second comment. interim with softwires. mboned and softwire= s > =A0are natural placeholders and need to be involved in interim. > > > =A0Ron: One draft about address mapping could be taken through AD sponsor= . > > =A0Ron: There is no requirement that there is a BOF before a WG. There > =A0is the requirement it is a tractable problem and that there is > =A0energy and maybe some commercial demand and that it fits in the area. > =A0If we had an interim meeting hosted by other WGs and we find it is > =A0a tractable problem, and we feel we do not have a good enough umbrella > =A0in other WGs then we can spin off a WG. > > =A0Tina: If we think about interrim before Paris - little time > =A0Dave: Webex. > > =A0Alain: Not interrested in repeat of this BOF. Instead figure out the > =A0gaps, what's missing. Having a discussing at end of interim about > =A0charter would be recipe for desaster. > > =A0Opinion poll: > =A0 =A0a) Form a working group according to proposed charter > =A0 =A0 =A0 9 (room) + 1 jabber. > =A0 =A0b) interim webex, mboned + softwires (+ behave) > =A0 =A0 =A0 maybe february time frame. > =A0 =A0 =A0 10 > =A0 =A0c) go home, do nothing > =A0 =A0 =A0 0 > > =A0 Who is opposed to interrim: 0 > =A0 Who would participate in interrim: 15 > =A0 Opposed to WG now: 10 > > =A0 Ron: IETF is consenus based organization. Consensus in the room is fi= ne, > =A0 With the current status in the room where 50% think we need an > =A0 interrim to see whether the work is tractable would be counted as > =A0 non sufficient consensus. > > =A0 Greg: Let's have the interrim. > > > From Tina.Tsou.Zouting@huawei.com Tue Nov 22 16:45: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 D202211E80BA for ; Tue, 22 Nov 2011 16:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.165 X-Spam-Level: X-Spam-Status: No, score=-5.165 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 HHi2JhR8eGsQ for ; Tue, 22 Nov 2011 16:45:03 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B94B011E8098 for ; Tue, 22 Nov 2011 16:45:02 -0800 (PST) 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 <0LV3009I18QV6U@szxga03-in.huawei.com> for multrans@ietf.org; Wed, 23 Nov 2011 08:44:55 +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 <0LV300G2J8QVZP@szxga03-in.huawei.com> for multrans@ietf.org; Wed, 23 Nov 2011 08:44:55 +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 AFE37151; Wed, 23 Nov 2011 08:44:55 +0800 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 Nov 2011 08:44:51 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Wed, 23 Nov 2011 08:44:43 +0800 Date: Wed, 23 Nov 2011 00:44:43 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.193.34.142] To: "gjshep@gmail.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] Multrans Miniutes Thread-index: AQHMqHMLcWsy8dyCjk+tcWAgn8vOj5W3lUoA//+lHACAANWjAIABij8A//+AHACAAIZnQA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20111121200358.GP19998@cisco.com> Cc: "eckert@cisco.com" , Susan Hares Subject: Re: [multrans] Multrans Miniutes 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, 23 Nov 2011 00:45:04 -0000 Sure, thank you for cc the list. I appreciate it. Happy Thanksgiving! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] On Behal= f Of Greg Shepherd Sent: Tuesday, November 22, 2011 4:42 PM To: Tina TSOU; multrans@ietf.org Cc: eckert@cisco.com; Susan Hares Subject: Re: [multrans] Multrans Miniutes Please keep the multrans mail list on the distribution of all things related to multrans. Thanks, Greg On Tue, Nov 22, 2011 at 4:29 PM, Tina TSOU w= rote: > Toerless, Marshall, > Some supplements from my memory and Tom's audio record: > 1. The part of "Spencer Dawkin: ..." is something like this if I remember= corectly: > "Twenty people want to do SOMETHING, and maybe three people don't think w= e should, so we should do SOMETHING". > > 2. Dave Thaler said > "how multicast addresses are discovered on each side of the address famil= y boundary." > > 3. There are 10 in the room + 1 in the jabber said "working group, then i= nterim meeting", not 9+1. > When Greg counted 10 in the room, then I said from the my seat "Tom said = 'I will break the tie' in the jabber", Greg said "I don't understand what u= said", sorry about my Chinese accent. > > Tina > > > -----Original Message----- > From: Tina TSOU > Sent: Monday, November 21, 2011 4:55 PM > To: 'eckert@cisco.com' > Cc: Marshall Eubanks; Greg Shepherd; Ron Bonica; Susan Hares > Subject: RE: Multrans Miniutes > > Thank you, Toerless. > > " Tina: work coming from group of people taking multicast work identified > =A0out of behave, then derived the use cases etc. and figured that it > =A0touches multiple areas and that's why they feel this justifies a WG." > > Can you rephrase what I said in the meeting as following which I remember= ed, > " Tina: work coming from group of people taking multicast work identified > =A0out of behave, then derived the problem and use cases, priority of iss= ues etc. > =A0it was everything in Prague, then strip encapsulation in Quebec, and n= ow its translation + ops, > =A0figured that it touches BEHAVE, MBONED, V6OPS and PIM and that's why t= hey feel this justifies a WG." > > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > -----Original Message----- > From: eckert@cisco.com [mailto:eckert@cisco.com] > Sent: Monday, November 21, 2011 12:04 PM > To: Tina TSOU > Cc: Marshall Eubanks; Greg Shepherd; Ron Bonica; Susan Hares > Subject: Re: Multrans Miniutes > > I had sent my minutes after the meeting directly to greg. Sorry, > couldn't remember marshalls mail. > > Appended. > > Cheers > =A0 =A0Toerless > > > Agenda: > > Drafts: > > Problem statement draft > > Framework for IPv4/IPv6 Multicast Translation > > Multicast Proxy in IPv4/IPv6 Transition > > Agenda > > Welcome/Agenda bash/Minutes > > Stig: =A0Item missing. > > Marshall: This is multicast IPv4 to IPv4 transition BOF, NOT TRANSLATION. > > Greg: less people here in BOF than last time. > > Alain Durand: lot of this work has been done in Softwire > Greg: but this is transition, not translation. > > Framework for IPv4/IPv6 Multicast Translation : Stig Venaas > =A0draft-venaas-behave-v4v6mc-framework-03.txt > > =A0Slide 2: Overview: > =A0- behave did a unicast translation framework, RFC6144 > =A0- this draft started as a multicast version of that > =A0- ... > > =A0Slide 3: Scenarios > =A0- IPv4/IPv6 network/sender/receiver <-> > > =A0Slide 4: Multicast and translation > > =A0Slide 5: IPv6 nework receiving multicast from IPv4 Internet > > =A0Slide 6: IPv6 network receiving multicast from IPv4 Internet > > =A0Slide 7: Well-known multicsat prefix(es)? > > =A0Slide 8: IPv4 network receiving multicast from IPv6 Internet > > =A0Slide 9: New signaling mechanisms > > =A0Greg: TOS translation ? > =A0Stig: Should probably match the unicast translation itis using. > > =A0DaveT(haler): Want mapping to be the same as unicast mapping if > =A0unicast packets are sent to the source. Problem is slightly harder > =A0than the simplre unicast case. Unicast: How do you get the =A0address. > =A0Unicast addresses can be learned via DNS. In multicast you are usually > =A0joined with literal addresses. > > =A0Greg: This is an SSM question. > =A0Greg: It is less a translation than a location. > =A0Dave: Right, eg: follow the default-route. > > =A0Stig: Document has case where unicast translation is different from > =A0multicast translation for example when paths are different. > =A0Dave: Have an idea here, but depends on what is needed by use cases. > > =A0Ron Bonica: You said stateful is almost impossible. This needs some > =A0qualification. Eg: limiting the groupa address =A0space makes this > =A0fairly simple. Even the IPv4 address space is much larger than what's > =A0needed, so only a small address range may need to be mapped. > > =A0Stig: Agreed if you can limit yourself to known prefixes. For example > =A0as a content provider. > > =A0Ron: Given how new IPv6 multicast is, we should hopefully be able to e= nforce > =A0this addressing limitation. > > =A0Sue Hares: Did i understand correctly that only small set of addresses > =A0are mapped ? This is the address translation function only ? > > =A0Dave: Summary unicast of BEHAVE: Statefull and stateless. A small > =A0range of v6 can be mapped to v4 stateless, otherwise statefull is need= ed. > > =A0Ron: Translator can work in two ways: Statically join to everything > =A0or only join dynamically. > > =A0Stig: For dynamic mode you first need the joins to reach you, so you m= ay > =A0need to be an RP if ASM is used. > > =A0Ron: DM do not need to talk about, but SM is interesting. > > =A0Chairs: Primary use case is SSM. > > =A0Unintelligble discussion about how sources vs. groups are discovered > =A0(both in SDP). > > =A0Hitoshi: Question: SDP related. Thinks it is not really a good idea > =A0to change SDP. Should not change data in it. > > =A0Second question: is there for translation =A0negotiation ? > =A0Stig: difficult. > > =A0Toerless: SDP is translated also in unicast solutions. > > Use Cases : China Telecom : Oian Wang : 15 minutes > > =A0Slide 1: 6-6-4 Case > =A0Slide 2: 6-4-6-4 Case > > =A0 =A0Marc Blanchet: for 6-4-6-4 was there an IPv4 network that was repl= aced by an > =A0 =A0 =A0 =A0 IPv6 network. > =A0 =A0Presenter: Actually dual-core network. > =A0 =A0Marc Blanchet: Why then use IPv6 transport instead of native IPv4 > =A0 =A0Presenter: ... > > =A0 =A0Tina: This is the IPTV network, IPv6 only. > > =A0 =A0Dave: blue on the let and right connected by non IPv4 mcast should > =A0 =A0mean 6 over 4 across the non mcast capable ipv4 network. > > =A0 =A0Ron: Special case of first case. > > =A0 =A0Tina: explains old equipment causing secon > > =A0 =A0Toerless: On first slide, what additional signaling/data goes betw= een > =A0 =A0v4 source and v6 network ? RTCP, SDP, RTSP, EPG, anything else. > > =A0 =A0Presenter: Need to get back to you. > > =A0 =A0Dave: was this all the use cases ? > > =A0 =A0Tina: Just the use-cases from china telecom. SOmewhat more general= ized > =A0 =A0from actual customer case. > > Use Cases : France Telecom : Christian Jacquenet > > =A0Slide 1: Context > =A0 =A0- Choose to deploy DSliste for new STB that can't get a unique IPv= 4 > =A0 =A0 =A0address anymore. > =A0Slide 2: 4-6-4 > > =A0 =A0Toerless: SSM ? - Yes > > =A0 =A0Stig: WIll there also be IPv6 receivers ? - Yes > =A0 =A0 Stig: So tunneling is not a good option. > > =A0 =A0Ron: DSlite means tunneling through the v6 network ??? - No! > =A0 =A0 =A0Christian: No tunneling anywhere > > =A0 =A0 =A0specific use case detail: DSlite required. > =A0 =A0 =A0otherwise same use case as china telekom ? > > =A0 =A0Toerless: USe case definition should more explicitly include > =A0 =A0 descriptoin also of native receivers to make sure it is taken int= o > =A0 =A0 account (not only the receivers requring translation/transition). > > =A0 =A0Marshall: Asking whether static translation is done. > =A0 =A0Christian: This is just use case, not solution, but that exactly > =A0 =A0is discussed as addition for multicast to DSlite. > > =A0 =A0Marshall: How about additional IPv6 sources intot he IPv6 cloud, > =A0 =A0this would complicate the problem. > > =A0 =A0Christian: Yes, when there are IPv6 sources, there should not be a= ny > =A0 =A0more DSlite then anymore, but only native IPv6 service. > =A0 =A0Only want to address very short term constraints. Just because of > =A0 =A0insufficicent short term roadmaps of STB vendors. > > =A0 =A0Marshall: I can also see solutions if there are IPv6 sources in th= e > =A0 =A0network. > > =A0 =A0Christian: But we want to avoid that context. > > =A0 =A0Marc: Very similar to cases in before. > > =A0 =A0Stig: possible solution: Lets make all IPv6 sources send to well > =A0 =A0defined IPv4 prefixes that map to IPv4. > > =A0 =A0Christian: There is a demo of this in the terminal room. > > =A0 =A0Dave Thaler: Is there a requirement that the addressing after two > =A0 =A0times translation is again the same as the original ? > > =A0 =A0Marshall: there is a difference between requirement and having thi= s > =A0 =A0be done as an option. > > =A0 =A0Dave: Has to do a lot with how the receiver learns about the sourc= e/group. > =A0 =A0Would constrain set of options if it was a requirement for address= es to > =A0 =A0be the same. > > =A0 =A0Spencer Dawkin: ... > > Multrans Issues : Eubanks : 20 minutes > > =A0Network example 1: IPvX-IPvY-IPvY > > =A0 =A0Toerless: do we really need this, this is transition, so the > =A0 =A0evolution of the network is v4 to v6. > > =A0 =A0Marshall: There can be a lot of combination of v4 to v6 or vice ve= rsa > =A0 =A0along the path. > > =A0 =A0Ron: Find it easy to believe to add v6 receivers. Find it easy to > =A0 =A0believe v6 network to v4 receivers. =A0Have hard time to consider = adding > =A0 =A0v4 receivers to v6 sources/v6 network. > > =A0 =A0Marshall: Want to flesh this out. Have representation of two opera= tors. > =A0 =A0Christian: agree with ROns comments. Can constrain the set of opti= ons. > > =A0 =A0Stig: Y=3D4 is most useful for now. Also important to have support= for > =A0 =A0mix of receivers. > > =A0 =A0Alain Durand: Reality is that there is a very popular vendor of > =A0 =A0sources with no plan to go to IPv6. Receiver today are now IPv4. > =A0 =A0There may be v6 receivers in the future > > =A0 =A0Marc: Have taled about this for days and days and days. I am a fir= m > =A0 =A0believe that we continue to talk about this. Need much more time > =A0 =A0to agree on scenario. Just consider it may take a long time. > > =A0 =A0Dan Wing: It took BEHAVE 5 hours to just conclude on the set of > =A0 =A0cases and then prioritize. > > =A0Content walk thhrough > > =A0 =A0DaveT: Setp 0 is missing. How do you figure out the channel that > =A0 =A0had to be put into step 1. > > =A0Content Distribution walk thhrough > > =A0Slide 6: Issues (1) > > =A0 =A0Stig: Key thing is that it should be a standard mapping. > > =A0 =A0Ron: Given how all sources start as v4, we should use stateless mo= del. > > =A0Slide 7: Issues (2) > > =A0 =A0Stig: Should not assume the translation is an ALG. > > =A0 =A0Discussion about AF and ALG terminology. > > =A0 =A0Dave: AF and ALG boxes may not need to be the same box. Is that wh= at > =A0 =A0was meant by Stig in before ? > > =A0 =A0Dan Wing: ALG - Application Layer Gateway: Examining and Modifying > =A0 =A0application layer payload in signaling. The more complex it is the > =A0 =A0harder the ALG job becomes. > > =A0 =A0Marshal: Is multicast immune to this problem ? Classical signaling= ? > > =A0 =A0Dan: How classical do we become here ? SAP ? HTTP, HTTPs ? > > =A0 =A0Ron: We probably don't tal about an ALG here. Just relays data-pla= ne > =A0 =A0between v4/v6. > > =A0 =A0Stig: DOn't want to argue too much but keep it open what the AF > =A0 =A0function is doing. > > =A0 =A0Spencer: ... ? > > =A0 =A0Hitoshi: ... > > =A0 =A0Toerless: Difficult part is when addresses in EPG need to be chang= ed > =A0 =A0or otherwise application backends need to be aware of mapping of > =A0 =A0v4/v6 addresses. > > =A0 =A0Dave: The primary issue you haven't gotten to is how to learn > =A0 =A0T(S) and T(G). Possible answers: a) proprietary -> non IETF. > =A0 =A0b) assume signle discovery protocol, eg: DNS in Unicast. And then > =A0 =A0do ALG for that protocol. c) most likely: STB also have no plans > =A0 =A0to move to IPv6. Information receiver gets is exactly what the sou= rce > =A0 =A0thinks. Even if it is in a different address family than the sourc= e, > =A0 =A0and make that work. > > =A0 =A0Marshal: back up. v4 source, v6 receiver. Application gets v4 addr= ess > =A0 =A0information. Receiver then needs to apply magic. > > =A0 =A0Dave: In category 3 either the application needs to do this magic > =A0 =A0or the OS/stack. > > =A0 =A0Marshal: yes. > > =A0 =A0Dave: > > =A0 =A0Toerless: category 4 ? Eg: can't change the app on the client, can= 't > =A0 =A0change the stack, so mayube instead of then actually having an > =A0 =A0IPv6 only receiver, we make it a dual stack client behind eg: DSli= te, > =A0 =A0and IPv4 is only used to receive multicast. > > =A0 =A0Discussion Marshal/Dave. Not clear what is fully in scope. > =A0 =A0Marshall: DOn't want to discuss web design. > =A0 =A0Dave: This excludes case a) > > =A0 =A0Marshal: What makes it proprietaary to use a web-page ? > =A0 =A0Dave: Because of the required ALG. > > =A0 =A0Marc: May actually want to device SDP ALG. > > =A0 =A0Dave: SDP my itself is not a protocol, it's just a data-model that > =A0 =A0needs to be carried in a transport. And then yes, this could be > =A0 =A0category a) or b). > > =A0 =A0Marshal: not supposed to solve this. > > =A0Network Example 2: IPvX-IPvY-IPvX > > =A0 =A0Marshal: Should this not done via a mechanism like softwires ? > > =A0 =A0Toerless/Dave: Discuss unicast only use case of china telecom, > =A0 =A0agree AMT would be appropriate, but this may not even need to > =A0 =A0be in scope for this BOF/WG ? > > =A0 =A0Marc: Are we ever getting to discuss whether to make a owrking gro= up ? > > Room discussion : Proposed Multrans Charter and nex steps : Remaining tim= e > > =A0Marshal: There seems to be energy to work on this. Raise hand if > =A0 you are willing to work on this. > =A018 in room +1 on jabber raise hand. > > =A0Alain: There is already work chartered in another working group > =A0softwires. > > =A0Dave: This BOF is a spinoff of the BEHAVE working group. Needs NAT > =A0and multicast experts together. This work would not overlap with BEHAV= E. > > =A0Alain is chair of softwires. > > =A0Marshal: Is this overlapping with softwires. > > =A0Alain: Very large overlap. > > =A0Stig: Softwires is limited to only encapsulation. > > =A0Greg: There is also the mesh draft which is not encapsulation. > > =A0Greg: We need to collect what's missing from the work of other WGs. > > =A0Marshal: Do we feel there is sufficient difference between softwires > =A0and what could be worked on in a to be formed WG ? > > =A0Dave: Suggest different question: Do people have enough information > =A0if this a tractable problem. Primarily discovery is the biggest proble= m. > =A0Fairly good confidence that data translation solution can be worked ou= t. > > =A0Greg: DSlite, softwires, right. Data is not the issue. > > =A0Marc: Focussing on which use case to work on requires dedicated time. > =A0after that is done, we will have a good idea whether we need a WG. > > =A0Stig: This work could be first done in MBONED WG. > > =A0Alain: One bit in softwires that is not fully fleshed is the translati= on > =A0piece. What was not discussed/figured out is discovery. > > =A0Toerless: Start discussing use-cases in mboned, review, recommend > =A0solution elements for them. Take existing work in other WGs into accou= nt > =A0(softwires). Figure out missing pieces. SImple pieces like translation > =A0could even be done in MBONED. > > =A0Greg: Alain suggesting interim meeting of dedicated group of people > =A0doen by chair of group hosting work (eg: Alain -> softwires). > =A0Identify piece missing, then forward those to MBONED. > > =A0Greg: Interim meeting did not do multicast work. Suggest to do a > =A0multicast-only interim softwires WG. > > =A0Alain: Yes. > > =A0Ron: Suggests joint interim softwires/mboned meting, parse out which > =A0parts are to be resolved where. > > =A0Tina: Work here is related to many WGs.a Better to have a single dedic= ated > =A0working group. > > =A0Stig: Work wostly limited to mboned. > > =A0Ron: WOuld likely need STB people involved. > > =A0Greg: Will not have all technical people if it's only done in mboned. > > =A0Stig: Issue is how to get right people together. Need people who are > =A0not in mboned involved. Need to get enough time for this, can't not be > =A0pushed off. > > =A0Greg: Interim meeting to come up with conclusion. > > =A0Tina: can we go through four slides of proposed charter. > =A0 - walking through four proposed goals > =A0 =A0 - requirements > =A0 =A0 - alg > =A0 =A0 - translation > =A0 =A0 - configuration and management > > =A0Alain: To early because we are not forming a WG. > > =A0Dave: vote for webex, primarily mboned, also behave, see little > =A0overlap with softwires. encap is softwires expertise. > > =A0Alain: Expertise of softwires is use cases described by Christian. > > =A0Dave: would like to see at least to se one internet draft on how > =A0the discovery is done before forming a working group. Even if it's > =A0not the best idea, but proof of exstance of a possible solution to the > =A0discovery would be needed first. > > =A0Tina: work coming from group of people taking multicast work identifie= d > =A0out of behave, then derived the use cases etc. and figured that it > =A0touches multiple areas and that's why they feel this justifies a WG. > > =A0Marc: proposes the interim. ALso a believer that after the focus > =A0session not everything will be done. Also fear that it will spread > =A0all over the place. A dedicated working group could help to keep > =A0the architecture in one place. Otherwise we will get a puzzle solution= . > > =A0Christian: Second comment. interim with softwires. mboned and softwire= s > =A0are natural placeholders and need to be involved in interim. > > > =A0Ron: One draft about address mapping could be taken through AD sponsor= . > > =A0Ron: There is no requirement that there is a BOF before a WG. There > =A0is the requirement it is a tractable problem and that there is > =A0energy and maybe some commercial demand and that it fits in the area. > =A0If we had an interim meeting hosted by other WGs and we find it is > =A0a tractable problem, and we feel we do not have a good enough umbrella > =A0in other WGs then we can spin off a WG. > > =A0Tina: If we think about interrim before Paris - little time > =A0Dave: Webex. > > =A0Alain: Not interrested in repeat of this BOF. Instead figure out the > =A0gaps, what's missing. Having a discussing at end of interim about > =A0charter would be recipe for desaster. > > =A0Opinion poll: > =A0 =A0a) Form a working group according to proposed charter > =A0 =A0 =A0 9 (room) + 1 jabber. > =A0 =A0b) interim webex, mboned + softwires (+ behave) > =A0 =A0 =A0 maybe february time frame. > =A0 =A0 =A0 10 > =A0 =A0c) go home, do nothing > =A0 =A0 =A0 0 > > =A0 Who is opposed to interrim: 0 > =A0 Who would participate in interrim: 15 > =A0 Opposed to WG now: 10 > > =A0 Ron: IETF is consenus based organization. Consensus in the room is fi= ne, > =A0 With the current status in the room where 50% think we need an > =A0 interrim to see whether the work is tractable would be counted as > =A0 non sufficient consensus. > > =A0 Greg: Let's have the interrim. > > > _______________________________________________ multrans mailing list multrans@ietf.org https://www.ietf.org/mailman/listinfo/multrans From Tina.Tsou.Zouting@huawei.com Tue Nov 22 16:52: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 8E13E1F0C4B for ; Tue, 22 Nov 2011 16:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.156 X-Spam-Level: X-Spam-Status: No, score=-5.156 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 gKwKgjNND9SD for ; Tue, 22 Nov 2011 16:52:04 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5111F0C4C for ; Tue, 22 Nov 2011 16:52:04 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LV300E9Q92PFF@szxga04-in.huawei.com> for multrans@ietf.org; Wed, 23 Nov 2011 08:52:01 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LV30009192PA1@szxga04-in.huawei.com> for multrans@ietf.org; Wed, 23 Nov 2011 08:52:01 +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 AFG34013; Wed, 23 Nov 2011 08:52:00 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 Nov 2011 08:51:57 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Wed, 23 Nov 2011 08:51:53 +0800 Date: Wed, 23 Nov 2011 00:51:53 +0000 From: Tina TSOU X-Originating-IP: [10.193.34.142] To: "gjshep@gmail.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] Multrans Miniutes Thread-index: AQHMqHMLcWsy8dyCjk+tcWAgn8vOj5W3lUoA//+lHACAANWjAIABij8A//+AHACAAIZnQIAAAXLg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20111121200358.GP19998@cisco.com> Cc: "eckert@cisco.com" , Susan Hares Subject: Re: [multrans] Multrans Miniutes 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, 23 Nov 2011 00:52:06 -0000 "> Dave: was this all the use cases ? > > Tina: Just the use-cases from china telecom. SOmewhat more generalized > from actual customer case." What I said exactly is "> Tina: The slides here are the use-cases from China Telecom and France= Telecom. SOmewhat more generalized > from actual customer case. The complete and having commercial demand g= eneralized use cases are in the problem statement and use case draft and th= e issues slides." Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Tina TSOU=20 Sent: Tuesday, November 22, 2011 4:45 PM To: 'gjshep@gmail.com'; multrans@ietf.org Cc: eckert@cisco.com; Susan Hares Subject: RE: [multrans] Multrans Miniutes Sure, thank you for cc the list. I appreciate it. Happy Thanksgiving! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] On Behal= f Of Greg Shepherd Sent: Tuesday, November 22, 2011 4:42 PM To: Tina TSOU; multrans@ietf.org Cc: eckert@cisco.com; Susan Hares Subject: Re: [multrans] Multrans Miniutes Please keep the multrans mail list on the distribution of all things related to multrans. Thanks, Greg On Tue, Nov 22, 2011 at 4:29 PM, Tina TSOU w= rote: > Toerless, Marshall, > Some supplements from my memory and Tom's audio record: > 1. The part of "Spencer Dawkin: ..." is something like this if I remember= corectly: > "Twenty people want to do SOMETHING, and maybe three people don't think w= e should, so we should do SOMETHING". > > 2. Dave Thaler said > "how multicast addresses are discovered on each side of the address famil= y boundary." > > 3. There are 10 in the room + 1 in the jabber said "working group, then i= nterim meeting", not 9+1. > When Greg counted 10 in the room, then I said from the my seat "Tom said = 'I will break the tie' in the jabber", Greg said "I don't understand what u= said", sorry about my Chinese accent. > > Tina > > > -----Original Message----- > From: Tina TSOU > Sent: Monday, November 21, 2011 4:55 PM > To: 'eckert@cisco.com' > Cc: Marshall Eubanks; Greg Shepherd; Ron Bonica; Susan Hares > Subject: RE: Multrans Miniutes > > Thank you, Toerless. > > " Tina: work coming from group of people taking multicast work identified > =A0out of behave, then derived the use cases etc. and figured that it > =A0touches multiple areas and that's why they feel this justifies a WG." > > Can you rephrase what I said in the meeting as following which I remember= ed, > " Tina: work coming from group of people taking multicast work identified > =A0out of behave, then derived the problem and use cases, priority of iss= ues etc. > =A0it was everything in Prague, then strip encapsulation in Quebec, and n= ow its translation + ops, > =A0figured that it touches BEHAVE, MBONED, V6OPS and PIM and that's why t= hey feel this justifies a WG." > > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > -----Original Message----- > From: eckert@cisco.com [mailto:eckert@cisco.com] > Sent: Monday, November 21, 2011 12:04 PM > To: Tina TSOU > Cc: Marshall Eubanks; Greg Shepherd; Ron Bonica; Susan Hares > Subject: Re: Multrans Miniutes > > I had sent my minutes after the meeting directly to greg. Sorry, > couldn't remember marshalls mail. > > Appended. > > Cheers > =A0 =A0Toerless > > > Agenda: > > Drafts: > > Problem statement draft > > Framework for IPv4/IPv6 Multicast Translation > > Multicast Proxy in IPv4/IPv6 Transition > > Agenda > > Welcome/Agenda bash/Minutes > > Stig: =A0Item missing. > > Marshall: This is multicast IPv4 to IPv4 transition BOF, NOT TRANSLATION. > > Greg: less people here in BOF than last time. > > Alain Durand: lot of this work has been done in Softwire > Greg: but this is transition, not translation. > > Framework for IPv4/IPv6 Multicast Translation : Stig Venaas > =A0draft-venaas-behave-v4v6mc-framework-03.txt > > =A0Slide 2: Overview: > =A0- behave did a unicast translation framework, RFC6144 > =A0- this draft started as a multicast version of that > =A0- ... > > =A0Slide 3: Scenarios > =A0- IPv4/IPv6 network/sender/receiver <-> > > =A0Slide 4: Multicast and translation > > =A0Slide 5: IPv6 nework receiving multicast from IPv4 Internet > > =A0Slide 6: IPv6 network receiving multicast from IPv4 Internet > > =A0Slide 7: Well-known multicsat prefix(es)? > > =A0Slide 8: IPv4 network receiving multicast from IPv6 Internet > > =A0Slide 9: New signaling mechanisms > > =A0Greg: TOS translation ? > =A0Stig: Should probably match the unicast translation itis using. > > =A0DaveT(haler): Want mapping to be the same as unicast mapping if > =A0unicast packets are sent to the source. Problem is slightly harder > =A0than the simplre unicast case. Unicast: How do you get the =A0address. > =A0Unicast addresses can be learned via DNS. In multicast you are usually > =A0joined with literal addresses. > > =A0Greg: This is an SSM question. > =A0Greg: It is less a translation than a location. > =A0Dave: Right, eg: follow the default-route. > > =A0Stig: Document has case where unicast translation is different from > =A0multicast translation for example when paths are different. > =A0Dave: Have an idea here, but depends on what is needed by use cases. > > =A0Ron Bonica: You said stateful is almost impossible. This needs some > =A0qualification. Eg: limiting the groupa address =A0space makes this > =A0fairly simple. Even the IPv4 address space is much larger than what's > =A0needed, so only a small address range may need to be mapped. > > =A0Stig: Agreed if you can limit yourself to known prefixes. For example > =A0as a content provider. > > =A0Ron: Given how new IPv6 multicast is, we should hopefully be able to e= nforce > =A0this addressing limitation. > > =A0Sue Hares: Did i understand correctly that only small set of addresses > =A0are mapped ? This is the address translation function only ? > > =A0Dave: Summary unicast of BEHAVE: Statefull and stateless. A small > =A0range of v6 can be mapped to v4 stateless, otherwise statefull is need= ed. > > =A0Ron: Translator can work in two ways: Statically join to everything > =A0or only join dynamically. > > =A0Stig: For dynamic mode you first need the joins to reach you, so you m= ay > =A0need to be an RP if ASM is used. > > =A0Ron: DM do not need to talk about, but SM is interesting. > > =A0Chairs: Primary use case is SSM. > > =A0Unintelligble discussion about how sources vs. groups are discovered > =A0(both in SDP). > > =A0Hitoshi: Question: SDP related. Thinks it is not really a good idea > =A0to change SDP. Should not change data in it. > > =A0Second question: is there for translation =A0negotiation ? > =A0Stig: difficult. > > =A0Toerless: SDP is translated also in unicast solutions. > > Use Cases : China Telecom : Oian Wang : 15 minutes > > =A0Slide 1: 6-6-4 Case > =A0Slide 2: 6-4-6-4 Case > > =A0 =A0Marc Blanchet: for 6-4-6-4 was there an IPv4 network that was repl= aced by an > =A0 =A0 =A0 =A0 IPv6 network. > =A0 =A0Presenter: Actually dual-core network. > =A0 =A0Marc Blanchet: Why then use IPv6 transport instead of native IPv4 > =A0 =A0Presenter: ... > > =A0 =A0Tina: This is the IPTV network, IPv6 only. > > =A0 =A0Dave: blue on the let and right connected by non IPv4 mcast should > =A0 =A0mean 6 over 4 across the non mcast capable ipv4 network. > > =A0 =A0Ron: Special case of first case. > > =A0 =A0Tina: explains old equipment causing secon > > =A0 =A0Toerless: On first slide, what additional signaling/data goes betw= een > =A0 =A0v4 source and v6 network ? RTCP, SDP, RTSP, EPG, anything else. > > =A0 =A0Presenter: Need to get back to you. > > =A0 =A0Dave: was this all the use cases ? > > =A0 =A0Tina: Just the use-cases from china telecom. SOmewhat more general= ized > =A0 =A0from actual customer case. > > Use Cases : France Telecom : Christian Jacquenet > > =A0Slide 1: Context > =A0 =A0- Choose to deploy DSliste for new STB that can't get a unique IPv= 4 > =A0 =A0 =A0address anymore. > =A0Slide 2: 4-6-4 > > =A0 =A0Toerless: SSM ? - Yes > > =A0 =A0Stig: WIll there also be IPv6 receivers ? - Yes > =A0 =A0 Stig: So tunneling is not a good option. > > =A0 =A0Ron: DSlite means tunneling through the v6 network ??? - No! > =A0 =A0 =A0Christian: No tunneling anywhere > > =A0 =A0 =A0specific use case detail: DSlite required. > =A0 =A0 =A0otherwise same use case as china telekom ? > > =A0 =A0Toerless: USe case definition should more explicitly include > =A0 =A0 descriptoin also of native receivers to make sure it is taken int= o > =A0 =A0 account (not only the receivers requring translation/transition). > > =A0 =A0Marshall: Asking whether static translation is done. > =A0 =A0Christian: This is just use case, not solution, but that exactly > =A0 =A0is discussed as addition for multicast to DSlite. > > =A0 =A0Marshall: How about additional IPv6 sources intot he IPv6 cloud, > =A0 =A0this would complicate the problem. > > =A0 =A0Christian: Yes, when there are IPv6 sources, there should not be a= ny > =A0 =A0more DSlite then anymore, but only native IPv6 service. > =A0 =A0Only want to address very short term constraints. Just because of > =A0 =A0insufficicent short term roadmaps of STB vendors. > > =A0 =A0Marshall: I can also see solutions if there are IPv6 sources in th= e > =A0 =A0network. > > =A0 =A0Christian: But we want to avoid that context. > > =A0 =A0Marc: Very similar to cases in before. > > =A0 =A0Stig: possible solution: Lets make all IPv6 sources send to well > =A0 =A0defined IPv4 prefixes that map to IPv4. > > =A0 =A0Christian: There is a demo of this in the terminal room. > > =A0 =A0Dave Thaler: Is there a requirement that the addressing after two > =A0 =A0times translation is again the same as the original ? > > =A0 =A0Marshall: there is a difference between requirement and having thi= s > =A0 =A0be done as an option. > > =A0 =A0Dave: Has to do a lot with how the receiver learns about the sourc= e/group. > =A0 =A0Would constrain set of options if it was a requirement for address= es to > =A0 =A0be the same. > > =A0 =A0Spencer Dawkin: ... > > Multrans Issues : Eubanks : 20 minutes > > =A0Network example 1: IPvX-IPvY-IPvY > > =A0 =A0Toerless: do we really need this, this is transition, so the > =A0 =A0evolution of the network is v4 to v6. > > =A0 =A0Marshall: There can be a lot of combination of v4 to v6 or vice ve= rsa > =A0 =A0along the path. > > =A0 =A0Ron: Find it easy to believe to add v6 receivers. Find it easy to > =A0 =A0believe v6 network to v4 receivers. =A0Have hard time to consider = adding > =A0 =A0v4 receivers to v6 sources/v6 network. > > =A0 =A0Marshall: Want to flesh this out. Have representation of two opera= tors. > =A0 =A0Christian: agree with ROns comments. Can constrain the set of opti= ons. > > =A0 =A0Stig: Y=3D4 is most useful for now. Also important to have support= for > =A0 =A0mix of receivers. > > =A0 =A0Alain Durand: Reality is that there is a very popular vendor of > =A0 =A0sources with no plan to go to IPv6. Receiver today are now IPv4. > =A0 =A0There may be v6 receivers in the future > > =A0 =A0Marc: Have taled about this for days and days and days. I am a fir= m > =A0 =A0believe that we continue to talk about this. Need much more time > =A0 =A0to agree on scenario. Just consider it may take a long time. > > =A0 =A0Dan Wing: It took BEHAVE 5 hours to just conclude on the set of > =A0 =A0cases and then prioritize. > > =A0Content walk thhrough > > =A0 =A0DaveT: Setp 0 is missing. How do you figure out the channel that > =A0 =A0had to be put into step 1. > > =A0Content Distribution walk thhrough > > =A0Slide 6: Issues (1) > > =A0 =A0Stig: Key thing is that it should be a standard mapping. > > =A0 =A0Ron: Given how all sources start as v4, we should use stateless mo= del. > > =A0Slide 7: Issues (2) > > =A0 =A0Stig: Should not assume the translation is an ALG. > > =A0 =A0Discussion about AF and ALG terminology. > > =A0 =A0Dave: AF and ALG boxes may not need to be the same box. Is that wh= at > =A0 =A0was meant by Stig in before ? > > =A0 =A0Dan Wing: ALG - Application Layer Gateway: Examining and Modifying > =A0 =A0application layer payload in signaling. The more complex it is the > =A0 =A0harder the ALG job becomes. > > =A0 =A0Marshal: Is multicast immune to this problem ? Classical signaling= ? > > =A0 =A0Dan: How classical do we become here ? SAP ? HTTP, HTTPs ? > > =A0 =A0Ron: We probably don't tal about an ALG here. Just relays data-pla= ne > =A0 =A0between v4/v6. > > =A0 =A0Stig: DOn't want to argue too much but keep it open what the AF > =A0 =A0function is doing. > > =A0 =A0Spencer: ... ? > > =A0 =A0Hitoshi: ... > > =A0 =A0Toerless: Difficult part is when addresses in EPG need to be chang= ed > =A0 =A0or otherwise application backends need to be aware of mapping of > =A0 =A0v4/v6 addresses. > > =A0 =A0Dave: The primary issue you haven't gotten to is how to learn > =A0 =A0T(S) and T(G). Possible answers: a) proprietary -> non IETF. > =A0 =A0b) assume signle discovery protocol, eg: DNS in Unicast. And then > =A0 =A0do ALG for that protocol. c) most likely: STB also have no plans > =A0 =A0to move to IPv6. Information receiver gets is exactly what the sou= rce > =A0 =A0thinks. Even if it is in a different address family than the sourc= e, > =A0 =A0and make that work. > > =A0 =A0Marshal: back up. v4 source, v6 receiver. Application gets v4 addr= ess > =A0 =A0information. Receiver then needs to apply magic. > > =A0 =A0Dave: In category 3 either the application needs to do this magic > =A0 =A0or the OS/stack. > > =A0 =A0Marshal: yes. > > =A0 =A0Dave: > > =A0 =A0Toerless: category 4 ? Eg: can't change the app on the client, can= 't > =A0 =A0change the stack, so mayube instead of then actually having an > =A0 =A0IPv6 only receiver, we make it a dual stack client behind eg: DSli= te, > =A0 =A0and IPv4 is only used to receive multicast. > > =A0 =A0Discussion Marshal/Dave. Not clear what is fully in scope. > =A0 =A0Marshall: DOn't want to discuss web design. > =A0 =A0Dave: This excludes case a) > > =A0 =A0Marshal: What makes it proprietaary to use a web-page ? > =A0 =A0Dave: Because of the required ALG. > > =A0 =A0Marc: May actually want to device SDP ALG. > > =A0 =A0Dave: SDP my itself is not a protocol, it's just a data-model that > =A0 =A0needs to be carried in a transport. And then yes, this could be > =A0 =A0category a) or b). > > =A0 =A0Marshal: not supposed to solve this. > > =A0Network Example 2: IPvX-IPvY-IPvX > > =A0 =A0Marshal: Should this not done via a mechanism like softwires ? > > =A0 =A0Toerless/Dave: Discuss unicast only use case of china telecom, > =A0 =A0agree AMT would be appropriate, but this may not even need to > =A0 =A0be in scope for this BOF/WG ? > > =A0 =A0Marc: Are we ever getting to discuss whether to make a owrking gro= up ? > > Room discussion : Proposed Multrans Charter and nex steps : Remaining tim= e > > =A0Marshal: There seems to be energy to work on this. Raise hand if > =A0 you are willing to work on this. > =A018 in room +1 on jabber raise hand. > > =A0Alain: There is already work chartered in another working group > =A0softwires. > > =A0Dave: This BOF is a spinoff of the BEHAVE working group. Needs NAT > =A0and multicast experts together. This work would not overlap with BEHAV= E. > > =A0Alain is chair of softwires. > > =A0Marshal: Is this overlapping with softwires. > > =A0Alain: Very large overlap. > > =A0Stig: Softwires is limited to only encapsulation. > > =A0Greg: There is also the mesh draft which is not encapsulation. > > =A0Greg: We need to collect what's missing from the work of other WGs. > > =A0Marshal: Do we feel there is sufficient difference between softwires > =A0and what could be worked on in a to be formed WG ? > > =A0Dave: Suggest different question: Do people have enough information > =A0if this a tractable problem. Primarily discovery is the biggest proble= m. > =A0Fairly good confidence that data translation solution can be worked ou= t. > > =A0Greg: DSlite, softwires, right. Data is not the issue. > > =A0Marc: Focussing on which use case to work on requires dedicated time. > =A0after that is done, we will have a good idea whether we need a WG. > > =A0Stig: This work could be first done in MBONED WG. > > =A0Alain: One bit in softwires that is not fully fleshed is the translati= on > =A0piece. What was not discussed/figured out is discovery. > > =A0Toerless: Start discussing use-cases in mboned, review, recommend > =A0solution elements for them. Take existing work in other WGs into accou= nt > =A0(softwires). Figure out missing pieces. SImple pieces like translation > =A0could even be done in MBONED. > > =A0Greg: Alain suggesting interim meeting of dedicated group of people > =A0doen by chair of group hosting work (eg: Alain -> softwires). > =A0Identify piece missing, then forward those to MBONED. > > =A0Greg: Interim meeting did not do multicast work. Suggest to do a > =A0multicast-only interim softwires WG. > > =A0Alain: Yes. > > =A0Ron: Suggests joint interim softwires/mboned meting, parse out which > =A0parts are to be resolved where. > > =A0Tina: Work here is related to many WGs.a Better to have a single dedic= ated > =A0working group. > > =A0Stig: Work wostly limited to mboned. > > =A0Ron: WOuld likely need STB people involved. > > =A0Greg: Will not have all technical people if it's only done in mboned. > > =A0Stig: Issue is how to get right people together. Need people who are > =A0not in mboned involved. Need to get enough time for this, can't not be > =A0pushed off. > > =A0Greg: Interim meeting to come up with conclusion. > > =A0Tina: can we go through four slides of proposed charter. > =A0 - walking through four proposed goals > =A0 =A0 - requirements > =A0 =A0 - alg > =A0 =A0 - translation > =A0 =A0 - configuration and management > > =A0Alain: To early because we are not forming a WG. > > =A0Dave: vote for webex, primarily mboned, also behave, see little > =A0overlap with softwires. encap is softwires expertise. > > =A0Alain: Expertise of softwires is use cases described by Christian. > > =A0Dave: would like to see at least to se one internet draft on how > =A0the discovery is done before forming a working group. Even if it's > =A0not the best idea, but proof of exstance of a possible solution to the > =A0discovery would be needed first. > > =A0Tina: work coming from group of people taking multicast work identifie= d > =A0out of behave, then derived the use cases etc. and figured that it > =A0touches multiple areas and that's why they feel this justifies a WG. > > =A0Marc: proposes the interim. ALso a believer that after the focus > =A0session not everything will be done. Also fear that it will spread > =A0all over the place. A dedicated working group could help to keep > =A0the architecture in one place. Otherwise we will get a puzzle solution= . > > =A0Christian: Second comment. interim with softwires. mboned and softwire= s > =A0are natural placeholders and need to be involved in interim. > > > =A0Ron: One draft about address mapping could be taken through AD sponsor= . > > =A0Ron: There is no requirement that there is a BOF before a WG. There > =A0is the requirement it is a tractable problem and that there is > =A0energy and maybe some commercial demand and that it fits in the area. > =A0If we had an interim meeting hosted by other WGs and we find it is > =A0a tractable problem, and we feel we do not have a good enough umbrella > =A0in other WGs then we can spin off a WG. > > =A0Tina: If we think about interrim before Paris - little time > =A0Dave: Webex. > > =A0Alain: Not interrested in repeat of this BOF. Instead figure out the > =A0gaps, what's missing. Having a discussing at end of interim about > =A0charter would be recipe for desaster. > > =A0Opinion poll: > =A0 =A0a) Form a working group according to proposed charter > =A0 =A0 =A0 9 (room) + 1 jabber. > =A0 =A0b) interim webex, mboned + softwires (+ behave) > =A0 =A0 =A0 maybe february time frame. > =A0 =A0 =A0 10 > =A0 =A0c) go home, do nothing > =A0 =A0 =A0 0 > > =A0 Who is opposed to interrim: 0 > =A0 Who would participate in interrim: 15 > =A0 Opposed to WG now: 10 > > =A0 Ron: IETF is consenus based organization. Consensus in the room is fi= ne, > =A0 With the current status in the room where 50% think we need an > =A0 interrim to see whether the work is tractable would be counted as > =A0 non sufficient consensus. > > =A0 Greg: Let's have the interrim. > > > _______________________________________________ multrans mailing list multrans@ietf.org https://www.ietf.org/mailman/listinfo/multrans From spencer@wonderhamster.org Wed Nov 23 10:07: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 B780E11E80B9 for ; Wed, 23 Nov 2011 10:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 AAQEM5k5cmil for ; Wed, 23 Nov 2011 10:07:12 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD2B11E80A3 for ; Wed, 23 Nov 2011 10:07:12 -0800 (PST) Received: from [192.168.1.105] (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LbMVm-1R1L4P3d4k-00lGYZ; Wed, 23 Nov 2011 13:07:10 -0500 Message-ID: <4ECD3646.7050103@wonderhamster.org> Date: Wed, 23 Nov 2011 12:07:02 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: gjshep@gmail.com References: <20111121200358.GP19998@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:KK/PXWM3EdxdNBTQRcyUud1lDLOfjeJ3UlkEr63viKy Vj2gwqnUOtOh1pZdU2/aQ7enKUDTaOsUwhS+1uBj28kcHjzmn6 dGo/+kAMRz+Dq5M8bDv0BRAeue+Ptc9YiQIffG2JOcwbsSR4Dv Ue+yZG9W1jCDJw0cpPMwAlJss0LfC3kBu89Ea2F2oBUVaDpk37 EXTfxeCkdxSlkdFbkdxIgpI71QPbVmWCUTV9Idz8DgL9C8Y+xM DicgCRca/z1GS7I0srqisPpK9ZqlwfrPrylaG8EQtPnyS5qzVO 1TPv+uduRzisls0FOm9rCHjJ3O2yYVmZLnH97iviXjUqESrBwv DtRzJwAz8WYcCAFmCY1quIFE/2+MYaDG5vTYxfRdW Cc: Susan Hares , multrans@ietf.org Subject: Re: [multrans] Multrans Miniutes 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, 23 Nov 2011 18:07:12 -0000 Just confirming - that's what Spencer said ... Thanks! Spencer > On Tue, Nov 22, 2011 at 4:29 PM, Tina TSOU wrote: >> Toerless, Marshall, >> Some supplements from my memory and Tom's audio record: >> 1. The part of "Spencer Dawkin: ..." is something like this if I remember corectly: >> "Twenty people want to do SOMETHING, and maybe three people don't think we should, so we should do SOMETHING".