From jari.arkko@piuha.net Mon Jun 1 09:42:01 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED0D3A70A9 for ; Mon, 1 Jun 2009 09:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVbWrEwUCtuG for ; Mon, 1 Jun 2009 09:42:00 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 9F3463A6F2B for ; Mon, 1 Jun 2009 09:42:00 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 53F53198787 for ; Mon, 1 Jun 2009 19:42:00 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 11368198699 for ; Mon, 1 Jun 2009 19:42:00 +0300 (EEST) Message-ID: <4A23F820.7050101@piuha.net> Date: Mon, 01 Jun 2009 18:47:44 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: multimob@ietf.org References: <4A1BC82D.6080607@piuha.net> In-Reply-To: <4A1BC82D.6080607@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [multimob] Another question X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 16:42:01 -0000 Was there any response to this? Jari Arkko wrote: > Also, I have another question of my own. This does not have anything > to do with the technical parts, but more about groups of people who > are interested in this. Are the people interested in multimob and > proxy mip disjoint groups? > > For instance, are there people who are interested in Multimob going > forward AND who are, e.g., proxy MIP implementors? > > Jari > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > From behcetsarikaya@yahoo.com Mon Jun 1 10:09:32 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDFDC28B797 for ; Mon, 1 Jun 2009 10:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35rvAKXtpRt7 for ; Mon, 1 Jun 2009 10:09:32 -0700 (PDT) Received: from n7.bullet.re3.yahoo.com (n7.bullet.re3.yahoo.com [68.142.237.92]) by core3.amsl.com (Postfix) with SMTP id E3AEA3A681D for ; Mon, 1 Jun 2009 10:09:31 -0700 (PDT) Received: from [68.142.237.89] by n7.bullet.re3.yahoo.com with NNFMP; 01 Jun 2009 17:09:29 -0000 Received: from [67.195.9.82] by t5.bullet.re3.yahoo.com with NNFMP; 01 Jun 2009 17:09:29 -0000 Received: from [67.195.9.99] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 01 Jun 2009 17:09:29 -0000 Received: from [127.0.0.1] by omp103.mail.gq1.yahoo.com with NNFMP; 01 Jun 2009 17:06:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 656365.81394.bm@omp103.mail.gq1.yahoo.com Received: (qmail 84116 invoked by uid 60001); 1 Jun 2009 17:09:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243876169; bh=7+azFnpVlSiCmXmCd/czS0bg5FAOIPIMQt/EEhIgK20=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hiXAQVXEo11c5wQ1m3sFHh0+zROUJuRBt+wDQ4t/YqxEa/Gg63NZijvjLOOpdxf/BbAYFdhd6s5wpicIjDSpGi37LVrsWGuPRj0XhmyfJaYft+3VZif1opiVRFnDT8D18RbYwMBmuvVphx3U6LzQj2dYOcFz7vmtRVqKxBRzH6A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UlgcpMaUC+tRSx7c8Uk++Zwv1++omxHNs3DUuHELZy3e+TkFUDxYhpYLlO1J8yyuQw+tBMz1p4mf52YuBH2zAVTm1k5TnXt3PiFx89vPXnQiuYRVmfn1ado2p+NsTzfA4U7v4Quw4BGMm2xvDDUlxgSL/p6FKg/YfRc2P4gt6fc=; Message-ID: <419618.82400.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: o0UDM9wVM1nteNL25RAhDrPZWMMVsiGJ78pAmUjFaHdQM9MHi_FePxGf9xjA8UVlOxJb40nnUH66s3bmXJO1iuJRsSHVQpbrQnwju3K7RVaCeco.lDX6ni7EzX5VAqzBPU.zuL6bpLvXORI2_qmGJ9FuCB.ArBTxSFgV.Y1LsGJoP16.qujZq4rJtBrPnXZF2dYp4BpvoPetHCpMtxh_U.vnkulTeB6lYuXAKRcFTaLhNau63AW6OyuREj6kFRKrLSOwhFwRYC_VfvjvMRREX8u2Pmlmmc62G40Zt23XLygekR3qBlqL6xwGUtXVddQPlA.ciZXfmYL68GmNRFs8HolAiTM- Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Mon, 01 Jun 2009 10:09:29 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <4A1BC82D.6080607@piuha.net> <4A23F820.7050101@piuha.net> Date: Mon, 1 Jun 2009 10:09:29 -0700 (PDT) From: Behcet Sarikaya To: Jari Arkko , multimob@ietf.org In-Reply-To: <4A23F820.7050101@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] Another question X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 17:09:32 -0000 Hi Jari,=0A=A0 My responses are given below.=0A=0ARegards,=0A=0ABehcet=0A= =0A=0A=0A----- Original Message ----=0AFrom: Jari Arkko =0ATo: multimob@ietf.org=0ASent: Monday, June 1, 2009 10:47:44 AM=0ASubj= ect: Re: [multimob] Another question=0A=0AWas there any response to this?= =0A=0AJari Arkko wrote:=0A> Also, I have another question of my own. This d= oes not have anything to do with the technical parts, but more about groups= of people who are interested in this. Are the people interested in multimo= b and proxy mip disjoint groups?=0A> =0A[behcet] I don't think so. So of us= like Suresh and others are active in both groups.=0A=0A> For instance, are= there people who are interested in Multimob going forward AND who are, e.g= .., proxy MIP implementors?=0A=0A[behcet] We welcome PMIP implementors to Mu= ltimob.=0AI am not sure if they are in Multimob but I believe they will be.= =0A=0A> =0A> Jari=0A> =0A> _______________________________________________= =0A> multimob mailing list=0A> multimob@ietf.org=0A> https://www.ietf.org/m= ailman/listinfo/multimob=0A> =0A> =0A=0A=0A________________________________= _______________=0Amultimob mailing list=0Amultimob@ietf.org=0Ahttps://www.i= etf.org/mailman/listinfo/multimob=0A=0A=0A=0A From xiayangsong@huawei.com Mon Jun 1 10:10:54 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559AA28C218 for ; Mon, 1 Jun 2009 10:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iujp68bZWDIU for ; Mon, 1 Jun 2009 10:10:53 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 8ABF83A6B44 for ; Mon, 1 Jun 2009 10:10:53 -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 <0KKK00KNTL1VAE@szxga03-in.huawei.com> for multimob@ietf.org; Tue, 02 Jun 2009 01:10:43 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKK002RQL1VX8@szxga03-in.huawei.com> for multimob@ietf.org; Tue, 02 Jun 2009 01:10:43 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKK00DRPL1KUY@szxml04-in.huawei.com> for multimob@ietf.org; Tue, 02 Jun 2009 01:10:43 +0800 (CST) Date: Mon, 01 Jun 2009 12:10:32 -0500 From: Frank Xia To: Jari Arkko , multimob@ietf.org Message-id: <010701c9e2db$e553a830$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A1BC82D.6080607@piuha.net> <4A23F820.7050101@piuha.net> Subject: Re: [multimob] Another question X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 17:10:54 -0000 Hi Jari I am interested in multimob, and also have interaction with PMIP implementation team of our company. But, I am not an implementor. BR Frank ----- Original Message ----- From: "Jari Arkko" To: Sent: Monday, June 01, 2009 10:47 AM Subject: Re: [multimob] Another question > Was there any response to this? > > Jari Arkko wrote: >> Also, I have another question of my own. This does not have anything >> to do with the technical parts, but more about groups of people who >> are interested in this. Are the people interested in multimob and >> proxy mip disjoint groups? >> >> For instance, are there people who are interested in Multimob going >> forward AND who are, e.g., proxy MIP implementors? >> >> Jari >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> >> > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Mon Jun 1 20:10:23 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A7EB3A6E55 for ; Mon, 1 Jun 2009 20:10:23 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMD7q3HvUirX for ; Mon, 1 Jun 2009 20:10:22 -0700 (PDT) Received: from n61.bullet.mail.sp1.yahoo.com (n61.bullet.mail.sp1.yahoo.com [98.136.44.37]) by core3.amsl.com (Postfix) with SMTP id DB9E83A6C04 for ; Mon, 1 Jun 2009 20:10:16 -0700 (PDT) Received: from [216.252.122.217] by n61.bullet.mail.sp1.yahoo.com with NNFMP; 02 Jun 2009 03:10:16 -0000 Received: from [67.195.9.81] by t2.bullet.sp1.yahoo.com with NNFMP; 02 Jun 2009 03:10:16 -0000 Received: from [67.195.9.110] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 02 Jun 2009 03:10:15 -0000 Received: from [127.0.0.1] by omp114.mail.gq1.yahoo.com with NNFMP; 02 Jun 2009 03:08:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 68702.20357.bm@omp114.mail.gq1.yahoo.com Received: (qmail 59285 invoked by uid 60001); 2 Jun 2009 03:10:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243912215; bh=fNgFW+1kqWoKcK3Jer8n8/psg4LiDaNZlwv81rfTaJs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=0VWEARrA5h2aQjWUgFiFSphiBK6KlSE7ycke4yvL1YdUiLNUJme6pC1w2+PS/FTAci9rl8v3j7gQ5QtQLwdGfG4g+P6TsZjCmvOYS/xmPYK7G0IdhfJDNzRe8fiLSRlGwPeWu2IXPXcm6S/Orlt9lg0LZh46bi+nf/DpGrOiXx0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=6F8BU1On705S05PVLqvqVu288AsvmC5Hey/uTJdQJZbnrqi3R2j12t5OwYdFjE7qy67WxJBeP9ZBdl7JU9yvoA2eE2LD59k6/YaYfi/ee2C3GDdzZN4mpzbrLeJjtpd3STHJp9Nz/nOum5INYDDYDlBpGCl2q+F78l7KpjInwpE=; Message-ID: <703348.57660.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: b2RpWHMVM1lsbdIBk9b3mIJdBZIkFh3h8o3k6IT0o7JVmrI8ot88bSsjzGBTJrk6EzC8Pb68yJfwkLdTEMVG4.4GZPQJAvp72QAmv.Ww3bPOUX1MkxcznNaaucjK_mJ5E.Axl36o3g8KgB.QWJb0mM2yNPLHrWzz2gpsjaNviMraiqBiz8GgTDY4RBQNHxhkC3fLHcz22n8Btr9oZNJ3H.UmqQEO_.narZ66w3LxIqHfnvg5gP0ARTu9z.d7OO4gwuia0EvmOBqnY2Mcw.PIgzIMyl5.akNifmPCVSZpj.Z9sm.AZAM79aZR1lyZgqLEzO5w9.KxZA54YSJHTTHdCbWhCm0- Received: from [71.164.178.22] by web111404.mail.gq1.yahoo.com via HTTP; Mon, 01 Jun 2009 20:10:15 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 Date: Mon, 1 Jun 2009 20:10:15 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Juan Carlos Zuniga Subject: [multimob] multimob post from juancarlos X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 03:10:23 -0000 Jari, I'm interested in multicast mobility, especially from the Mobile TV point of view. PMIP is one of the possible scenarios, but I hope that the multimob group will consider MIP and other mobility scenarios as well. Regards, Juan Carlos -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Frank Xia Sent: Monday, June 01, 2009 1:11 PM To: Jari Arkko; multimob@ietf.org Subject: Re: [multimob] Another question Hi Jari I am interested in multimob, and also have interaction with PMIP implementation team of our company. But, I am not an implementor. BR Frank ----- Original Message ----- From: "Jari Arkko" To: Sent: Monday, June 01, 2009 10:47 AM Subject: Re: [multimob] Another question > Was there any response to this? > > Jari Arkko wrote: >> Also, I have another question of my own. This does not have anything >> to do with the technical parts, but more about groups of people who >> are interested in this. Are the people interested in multimob and >> proxy mip disjoint groups? >> >> For instance, are there people who are interested in Multimob going >> forward AND who are, e.g., proxy MIP implementors? >> >> Jari >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> >> > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob -----Inline Message Follows----- If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. From behcetsarikaya@yahoo.com Tue Jun 2 07:24:35 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2F23A6B1B for ; Tue, 2 Jun 2009 07:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amaDkVu7IimL for ; Tue, 2 Jun 2009 07:24:33 -0700 (PDT) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id B02BC3A6EF5 for ; Tue, 2 Jun 2009 07:24:30 -0700 (PDT) Received: (qmail 37871 invoked by uid 60001); 2 Jun 2009 14:24:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243952668; bh=yjjj7xmJbl0X25LW8HC24B9xL2rbROiexiSqltcj7JE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=xKYkfVBi4EaGhrZ0WzK0V88oUtk8UOKLSk0pwCrit6qA1a04BSROSndX5yAxzn39MNWkuSX1LgXBQ7Awt7/BrRP9tvw/katvO+Dz4LoNWPU17lHXkVWlvFosGbI4OixL4+JbwhGWbLszeFOqD1jgzWK5cP5NuSGMxQCqT6XWx1U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=S4GGmUUpfl7pQsnVuXotazr6eIHE/aZOzrezAdXYMkPg5jAQ3n4DvNWrX7jMiwjf0puC6LdxbDITn1vkk8jisFdlkQ5bhAusqvZIuxESsFYjHpKOgHnVjchozkTlv1JVFSwkAGVzsJwxeMwa5XDI9OheImA4E1EADPtHpJ1scvw=; Message-ID: <512157.36027.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: YhSR.24VM1l5YFf3DX1cC.HhX4p.a_P_GF9rGTixJT3a8DUQcxshnRheAI4WlPC5hsv3BblkAxvEHtpvxbPuwlRos_1L2q.MM5hozgs6tZh_49zBjWRIrzIkON8a7rqSPR5enYhM7yFrDg86wBnp5yX87yVI.yqdrEaJmSeBcQqOkNdzFCzaMjsRJnQIw9K5dzZd5IRco9dSZWgSbwUP7SPhx8xNQ2JhnVjSJnKfrNhT6.y3JgHAJE0lorrX1Lcx7UVLbjngqbW7SsvPVdWHqorCwypMUBKf13wd9lxoYb_Bq_4TP3azelRLtO2NRCt5A9NUQqlOg9eMaK6_Ia4WurnekIkI8CrN99E- Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Tue, 02 Jun 2009 07:24:28 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: Date: Tue, 2 Jun 2009 07:24:28 -0700 (PDT) From: Behcet Sarikaya To: YAO Chunyan , multimob@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1286187245-1243952668=:36027" Subject: Re: [multimob] multimob post from juancarlos X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 14:24:35 -0000 --0-1286187245-1243952668=:36027 Content-Type: multipart/alternative; boundary="0-2095524538-1243952668=:36027" --0-2095524538-1243952668=:36027 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Chunyan,=0A=C2=A0 This is the latest charter text incorporating Pierrick= 's comments.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A=0A______________________= __________=0AFrom: YAO Chunyan =0ATo: Beh= cet Sarikaya ; multimob@ietf.org=0ACc: Juan Carlos Zunig= a =0ASent: Tuesday, June 2, 2009 1:28:3= 8 AM=0ASubject: RE: [multimob] multimob post from juancarlos=0A=0A=0A=0AHi,= all, I am interested in multicast mobility also. =0AI am not sure how the = charter is going? There is no further mail since May 19. =0ARegards, =0AChu= nyan Yao =0A-----Original Message----- =0AFrom: multimob-bounces@ietf.org [= mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya =0ASent: 200= 9=E5=B9=B46=E6=9C=882=E6=97=A5 11:10 =0ATo: multimob@ietf.org =0ACc: Juan C= arlos Zuniga =0ASubject: [multimob] multimob post from juancarlos =0A=0A=0A= =0A=0A=0AJari, =0AI'm interested in multicast mobility, especially fm the M= obile TV point of view. =0APMIP is one of the possible scenarios, but I hop= e that the multimob group will consider MIP and other mobility scenarios as= well.=0ARegards, =0AJuan Carlos =0A-----Original Message----- =0AFrom: mul= timob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Fran= k Xia =0ASent: Monday, June 01, 2009 1:11 PM =0ATo: Jari Arkko; multimob@ie= tf.org =0ASubject: Re: [multimob] Another question =0AHi Jari =0AI am inter= ested in multimob, and also =0Ahave interaction with PMIP implementation te= am of our company.=C2=A0 But, I am not an implementor. =0ABR =0AFrank =0A--= --- Original Message ----- =0AFrom: "Jari Arkko" =0A= To: =0ASent: Monday, June 01, 2009 10:47 AM =0ASubject:= Re: [multimob] Another question =0A=0A> Was there any response to this? = =0A> =0A> Jari Arkko wrote: =0A>> Also, I have another question of my own. = This does not have anything =0A>> to do with the technical parts, but more = about groups of people who =0A>> are interested in this. Are the people int= erested in multimob and =0A>> proxy mip disjoint groups? =0A>> =0A>> For in= stance, are there people who are interested in Multimob going =0A>> forward= AND who are, e.g., proxy MIP implementors? =0A>> =0A>> Jari =0A>> =0A>> __= _____________________________________________ =0A>> multimob mailing list = =0A>> multimob@ietf.org =0A>> https://www.ietf.org/mailman/listinfo/multimo= b =0A>> =0A>> =0A> =0A> =0A> ______________________________________________= _ =0A> multimob mailing list =0A> multimob@ietf.org =0A> https://www.ietf.o= rg/mailman/listinfo/multimob =0A___________________________________________= ____ =0Amultimob mailing list =0Amultimob@ietf.org =0Ahttps://www.ietf.org/= mailman/listinfo/multimob =0A=0A-----Inline Message Follows----- =0AIf you = reply to this message, keeping the Subject: header intact, =0AMailman will = discard the held message.=C2=A0 Do this if the message is =0Aspam.=C2=A0 If= you reply to this message and include an Approved: header =0Awith the list= password in it, the message will be approved for posting =0Ato the list.= =C2=A0 The Approved: header can also appear in the first line =0Aof the bod= y of the reply. =0A=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =0A___________________= ____________________________ =0Amultimob mailing list =0Amultimob@ietf.org = =0Ahttps://www.ietf.org/mailman/listinfo/multimob =0A=0A=0A --0-2095524538-1243952668=:36027 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Chunyan,
=0A
  This is the latest cha= rter text incorporating Pierrick's comments.
=0A
 
=0ARegards,
=0A
 
=0A
Behcet
=0A
=
=0A
=0A
=0AFrom: YAO Chunyan <Chunyan.Yao@alc= atel-sbell.com.cn>
To: Behcet Sarikaya <sarikaya@ieee.org>; multimob@ietf.org
Cc: Juan Carlos Zuniga <JuanCarlo= s.Zuniga@INTERDIGITAL.COM>
Sent:= Tuesday, June 2, 2009 1:28:38 AM
Subject: RE: [multimob] multimob post from juancarlos<= BR>

=0A

Hi,= all, I am interested in multicast mobility also.

=0A

<= SPAN lang=3Dzh-cn>I am not sure how the charte= r is going? There is no further mail since May 19.

=0A

= Regards,

= =0A

Chunyan Yao

=0A

-----Origina= l Message-----
From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: 2009= =E5=B9=B46=E6=9C=882=E6=97=A5 11:10
To: multimob@ietf.org
Cc: Juan Carlos Zuniga
Subject: [multimob] m= ultimob post from juancarlos






=0A

Jari,

=0AI'm interested in multicas= t mobility, especially fm the Mobile TV point of view.

= =0A

PMIP is one of the po= ssible scenarios, but I hope that the multimob group will consider MIP and = other mobility scenarios as well.

=0A

Regards,

=0A

Juan Carlos

=0A

<= SPAN lang=3Dzh-cn>-----Original Message-----
From: mult= imob-bounces@ietf.org [= mailto:multimob-bounces@ietf.org] On Behalf Of Frank Xia
Sent: Monday, June 01, 2009 1:11= PM
To: J= ari Arkko; multimob@ietf.org
Subject: Re: [multimob] Another question =

=0A

Hi Jari

=0A

I am interes= ted in multimob, and also
have interaction with PMIP implementation team of our co= mpany.  But, I am not an implementor.

=0A

BR
Frank

=0A

----- Original Message -----
From: "Jari Arkko= " <jari.arkko@piuha.net>
To: <multimob@ietf.org>
Sent: Monday, June 01, 2009 10:4= 7 AM
Subj= ect: Re: [multimob] Another question


=0A

> Was there any response to this?<= /FONT>
>
> Jari Ark= ko wrote:
>> Also, I have another question of my own. This does not have anyth= ing
>&= gt; to do with the technical parts, but more about groups of people who
>> are= interested in this. Are the people interested in multimob and
>> proxy mip di= sjoint groups?
>>
>> For instance, are there people who are interested in Multimo= b going
>> forward AND who are, e.= g., proxy MIP implementors?
>>
>> Jari
>>
>> __________________________________________= _____
>= ;> multimob mailing list
>> multimob@ietf.org
>> https:/= /www.ietf.org/mailman/listinfo/multimob
>>
>>
>
>
> _______________________________________________ <= BR>> multimob mailing li= st
> m= ultimob@ietf.org
> https://www.ietf.org/mailman/listinfo/m= ultimob
__________________________________________= _____
multimob mailing list
<= FONT size=3D2 face=3DSimsun>multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob


=0A

-----Inline Message Follows-----

=0A

If you reply to= this message, keeping the Subject: header intact,
Mailman will discard the held mes= sage.  Do this if the message is
= spam.  If you reply to this message and i= nclude an Approved: header
with the list password in it, the message will be approv= ed for posting
to the list.  The Approved: header can also appear in the first = line
of t= he body of the reply.


=0A

     

=0A=

________________________= _______________________
multimob mailing list
<= FONT size=3D2 face=3DSimsun>multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob


=0A=0A= =0A=0A --0-2095524538-1243952668=:36027-- --0-1286187245-1243952668=:36027 Content-Type: text/plain; name="multimobcharter04.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="multimobcharter04.txt" Ck11bHRpY2FzdCBNb2JpbGl0eSAobXVsdGltb2IpDQoNCkNoYWlyczoNClRC RA0KDQpJbnRlcm5ldCBBcmVhIChpbnQpIERpcmVjdG9yczoNCkphcmkgQXJr a28gPGphcmkuYXJra29AcGl1aGEubmV0Pg0KTWFyayBUb3duc2xleSA8dG93 bnNsZXlAY2lzY28uY29tPiANCg0KSW50ZXJuZXQgQXJlYSBBZHZpc29yOg0K SmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+DQoNClNlY3VyaXR5 IEFyZWEgQWR2aXNvcjoNCk1hcnNoYWxsIEV1YmFua3MgPHRtZUBhbWVyaWNh ZnJlZS50dj4uDQoNCk1haWxpbmcgTGlzdHM6DQpHZW5lcmFsIERpc2N1c3Np b246IG11bHRpbW9iQGlldGYub3JnDQpTdWJzY3JpYmUgb25saW5lIGF0OiBo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aW1v Yg0KDQpEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwDQoNClRoZSBNdWx0 aWNhc3QgbW9iaWxpdHkgKG11bHRpbW9iKSB3aWxsIGRldmVsb3AgYSBzZXQg b2YgcHJvdG9jb2wgZXh0ZW5zaW9ucyBhbmQgcHJvdmlkZSBndWlkYW5jZSBh cHByb3ByaWF0ZSBmb3IgSVB2NCBhbmQgSVB2NiBtdWx0aWNhc3QgaW4gYSBt b2JpbGUgZW52aXJvbm1lbnQuIEl0IHdpbGwgY29uc2lkZXIgYm90aCBzb3Vy Y2Ugc3BlY2lmaWMgbXVsdGljYXN0IChTU00pICBhbmQgYW55IHNvdXJjZSBt dWx0aWNhc3QgKEFTTSkgbXVsdGljYXN0IG1vZGVscy4KClRoZSBzY29wZSBv ZiB3b3JrIHdpbGwgYmUgbGltaXRlZCB0byBncm91cCBtYW5hZ2VtZW50IGFu ZCBtb2JpbGUgSVAgcHJvdG9jb2xzIC0gcHJveGllZCBvciBjbGllbnQtYmFz ZWQuIFdvcmsgcmVxdWlyaW5nIG1vZGlmaWNhdGlvbnMgb2YgbXVsdGljYXN0 IHJvdXRpbmcgcHJvdG9jb2xzIChQSU0tU00sIFBJTS1ETSwgZXRjLikgaXMg b3V0IG9mIHNjb3BlLiBTcGVjaWZpYyBnb2FscyBhcmU6CiAgCi0gU3BlY2lm eSBJR01QL01MRCBleHRlbnNpb25zIG1ldGhvZHMgZm9yIHJlZHVjaW5nIGpv aW4vbGVhdmUgbGF0ZW5jeS4KLSBTcGVjaWZ5IGEgZG9ybWFudCBtb2RlIG9w ZXJhdGlvbiBmb3IgSUdNUHYzL01MRHYyLgotIFNwZWNpZnkgUE1JUHY2IGV4 dGVuc2lvbnMgdG8gc3VwcG9ydCBJUHY2IG11bHRpY2FzdCBpbmNsdWRpbmcg cmVtb3RlIHN1YnNjcmlwdGlvbiBhbmQgZmFzdCBoYW5kb3Zlci4gDQotIFBy b3ZpZGUgZ3VpZGFuY2UgYW5kIHNwZWNpZnkgbWV0aG9kcyBmb3IgbXVsdGkt aG9taW5nIHN1cHBvcnQgZm9yIG11bHRpY2FzdC4NCg0KTXVsdGltb2Igd2ls bCBzcGVjaWZ5IGEgc2V0IG9mIGV4dGVuc2lvbnMgdG8gSUdNUHYzL01MRHYy IGZvciBtb2JpbGUgZW52aXJvbm1lbnRzLiBJR01QdjMvTUxEdjIgaGFzIGJl ZW4gc3BlY2lmaWVkIGZvciB3aXJlZCBuZXR3b3JrcyB3aXRoIHNoYXJlZCBs aW5rcy4gTW9iaWxlIG5vZGVzIGFsc28gaGF2ZSBvdGhlciBuZWVkcyAoZS5n LiAgZW50ZXJpbmcgYSBkb3JtYW50IG1vZGUgdG8gY29uc2VydmUgYmF0dGVy eSBwb3dlciwgbWluaW1pc2luZyB0aGUgbGF0ZW5jeSBmb3Igam9pbmluZyBh bmQgbGVhdmluZyBhIGdyb3VwIGluIHN1cHBvcnQgb2YgbW92ZW1lbnQpLiAg VGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhc3Nlc3MgZXhpc3Rpbmcgc29sdXRp b25zIGZvciBncm91cCBtYW5hZ2VtZW50LCBhbmQgZGV0ZXJtaW5lIGlmIHRo ZXNlIG1ldGhvZHMgYXJlIHN1ZmZpY2llbnQuIFRoaXMgd2lsbCBpbmNsdWRl IGRlZmluaW5nIGJlc3QgY3VycmVudCBwcmFjdGljZSBmb3Igc2VsZWN0aW9u IG9mIHRpbWVyIHZhbHVlcyBhbmQgcHJvdG9jb2wgcGFyYW1ldGVycy4gSWYg dGhlc2UgbWV0aG9kcyBhcmUgbm90IHN1ZmZpY2llbnQsIHRoZSB3b3JraW5n IGdyb3VwIHNoYWxsIHByb3Bvc2UgbmV3IHNvbHV0aW9ucyBhcyB1cGRhdGVz IHRvIGV4aXN0aW5nIHByb3RvY29scyAoaW5jbHVkaW5nIHBvc3NpYmxlIGlu dHJvZHVjdGlvbiBvZiBhZGRpdGlvbmFsIG1lc3NhZ2UgdHlwZXMpLiBJdCBp cyBhIGdvYWwgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvIGVuc3VyZSBiYWNr d2FyZCBjb21wYXRpYmlsaXR5IHdpdGggdGhlIGN1cnJlbnQgaW1wbGVtZW50 YXRpb25zIG9mIGdyb3VwIG1hbmFnZW1lbnQgcHJvdG9jb2xzLiBNZXNzYWdl IHN0cnVjdHVyZXMgc3VwcG9ydGVkIGluIGN1cnJlbnQgZGVwbG95ZWQgbmV0 d29ya3Mgd2lsbCBub3QgYmUgbW9kaWZpZWQuDQoKVW5pY2FzdCBtb2JpbGl0 eSBwcm90b2NvbHMgKE1vYmlsZSBJUHY2LCBEdWFsLVN0YWNrIE1vYmlsZSBJ UHY2IGFuZCBhbHNvIE1vYmlsZSBJUHY0KSBwcm92aWRlIGJhc2ljIG11bHRp Y2FzdCBzdXBwb3J0IGFuZCBlbmFibGUgbW9iaWxlIG5vZGVzIHRvIHBlcmZv cm0gYmktZGlyZWN0aW9uYWwgdHVubmVsaW5nIGFuZCByZWNlaXZlIG11bHRp Y2FzdCB0cmFmZmljIGFuY2hvcmVkIGF0IHRoZSBob21lIGFnZW50LiBIb3dl dmVyLCBzdWNoIGJhc2ljIHN1cHBvcnQgc3VmZmVycyBmcm9tIHRoZSAnYXZh bGFuY2hlJyBwcm9ibGVtIGFzIHRoZSBob21lIGFnZW50cyByZXBsaWNhdGUg dGhlIHBhY2tldHMgYW5kIHVuaWNhc3QgdGhlbSB0byB0aGUgbW9iaWxlIG5v ZGVzIGFzIHdlbGwgYXMgZnJvbSBub24tb3B0aW1hbCwgdHJpYW5ndWxhciBy b3V0aW5nLCAncmVtb3RlIHN1YnNjcmlwdGlvbicgc3VmZmVycyBmcm9tIHBv c3NpYmxlIGxvc3Mgb2YgZGF0YSBkdXJpbmcgaGFuZG92ZXJzLiBUaGUgV0cg d2lsbCBhZGRyZXNzIHRoZXNlIGlzc3VlcyB3aXRoaW4gdGhlIGNvbnRleHQg b2YgUHJveHkgTW9iaWxlIElQdjYgKFBNSVB2NikuCgpDdXJyZW50bHkgUE1J UHY2IChhbmQgbW9iaWxpdHkgZXh0ZW5zaW9uIHByb3RvY29scyBsaWtlICBG TUlQdjYgYW5kIEhNSVB2NikgZG9lcyBub3QgIHN1cHBvcnQgbXVsdGljYXN0 aW5nIGV4cGxpY2l0bHkuIEJhc2ljIHN1cHBvcnQgZm9yIG11bHRpY2FzdCB3 aXRoIGJpLWRpcmVjdGlvbmFsIHR1bm5lbGluZyB3aWxsIGJlIGRvY3VtZW50 ZWQgZm9yIFBNSVB2NiAod2l0aCBubyBuZXcgbWVzc2FnZSB0eXBlcyBvciAg Y2hhbmdlcyB0byB0aGUgbWVzc2FnZSBwYXJhbWV0ZXJzKS4gUE1JUHY2IHRo YXQgaGFuZGxlcyBJUHY0IGFuZCBJUHY2IHdpbGwgYmUgZXh0ZW5kZWQgdG8g YWxzbyBzdXBwb3J0IG11bHRpY2FzdGluZyB3aXRoIElQdjQuIEZpbmFsbHks IFBNSVB2NiBiYXNpYyBtdWx0aWNhc3Qgc3VwcG9ydCB3aWxsIGJlIGV4dGVu ZGVkIHRvIHN1cHBvcnQgcmVtb3RlIHN1YnNjcmlwdGlvbiBhbmQgZmFzdCBo YW5kb3Zlci4KCkEgbXVsdGktaG9tZWQgbW9iaWxlIG5vZGUgbWF5IHdpc2gg dG8gam9pbiBtdWx0aWNhc3QgZ3JvdXBzIGFuZCB0byBkaXJlY3QgZGlmZmVy ZW50IG11bHRpY2FzdCBmbG93cyB0byBpdHMgaW50ZXJmYWNlcy4gVGhlIHdv cmtpbmcgZ3JvdXAgd2lsbCBkZWZpbmUgbXVsdGktaG9taW5nIHN1cHBvcnQg Zm9yIG11bHRpY2FzdCwgaW5jbHVkaW5nIGFuIGVmZmljaWVudCBwZXItaW50 ZXJmYWNlIHN1YnNjcmlwdGlvbiBtYW5hZ2VtZW50IGluIHRoZSBjYXNlIG9m IG11bHRpLWhvbWVkIG1vYmlsaXR5IGFuZCBtdWx0aWNhc3QgZmxvdyBiaW5k aW5nLiAKDQpJbiBwZXJmb3JtaW5nIHRoaXMgd29yaywgdGhlIE11bHRpbW9i IHdvcmtpbmcgZ3JvdXAgd2lsbCB3b3JrIGNsb3NlbHkgd2l0aCBORVRMTU0N CndvcmtpbmcgZ3JvdXAgYW5kIHdpbGwgY29vcmRpbmF0ZSB3b3JrIG9uIElH TVAvTUxEIGV4dGVuc2lvbnMgd2l0aCB0aGUgTUJPTkVEIHdvcmtpbmcgZ3Jv dXAuDQoNCkdPQUxTIGFuZCBNSUxFU1RPTkVTOg0KDQpzaXggbW9udGhzOiAN Ci0gU3VibWl0IGEgZG9jdW1lbnQgb24gbXVsdGlob21pbmcgc3VwcG9ydCBm b3IgbXVsdGljYXN0IGFzIGEgQkNQIFJGQy4KLSBTdWJtaXQgYSBkb2N1bWVu dCBvbiBtaW5pbWFsIGRlcGxveW1lbnQgZm9yIFBNSVB2NiByZW1vdGUgc3Vi c2NyaXB0aW9uIGZvciBtdWx0aWNhc3QgYXMgYSBCQ1AgUkZDDQoNCk9uZSB5 ZWFyOiAKLSBTdWJtaXQgYSBkb2N1bWVudCBvbiBJR01QL01MRCBleHRlbnNp b25zIGZvciBtdWx0aWNhc3QgbW9iaWxpdHkgYXMgYW4gRVhQL1BTIFJGQy4N Ci0gU3VibWl0IGEgZG9jdW1lbnQgb24gZXh0ZW5zaW9ucyBmb3IgbXVsdGlj YXN0IG1vYmlsaXR5IGluIFBNSVB2NiBhcyBhbiBFWFAvUFMgUkZDLg0KDQpS ZWNoYXJ0ZXIgb3IgY2xvc2Ugd29ya2luZyBncm91cC4K --0-1286187245-1243952668=:36027-- From JuanCarlos.Zuniga@InterDigital.com Mon Jun 1 10:32:24 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11FE53A6B4E for ; Mon, 1 Jun 2009 10:32:24 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3bDZD6A42Sx for ; Mon, 1 Jun 2009 10:32:23 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 381683A6872 for ; Mon, 1 Jun 2009 10:32:23 -0700 (PDT) Received: from interdigital.com ([10.0.128.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Jun 2009 13:32:22 -0400 Received: from SAM.InterDigital.com ([10.30.2.12]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Jun 2009 13:32:22 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 1 Jun 2009 13:32:21 -0400 Message-ID: In-Reply-To: <010701c9e2db$e553a830$3e0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Another question Thread-Index: Acni2/dppw8mgWhjTDmF1Gs5OzXb/QAAnLkg From: "Zuniga, Juan Carlos" To: "Frank Xia" , "Jari Arkko" , X-OriginalArrivalTime: 01 Jun 2009 17:32:22.0599 (UTC) FILETIME=[EBF37D70:01C9E2DE] X-Mailman-Approved-At: Tue, 02 Jun 2009 09:35:17 -0700 Subject: Re: [multimob] Another question X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 17:32:24 -0000 Jari, I'm interested in multicast mobility, especially from the Mobile TV point of view.=20 PMIP is one of the possible scenarios, but I hope that the multimob group will consider MIP and other mobility scenarios as well. Regards, Juan Carlos=20 -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Frank Xia Sent: Monday, June 01, 2009 1:11 PM To: Jari Arkko; multimob@ietf.org Subject: Re: [multimob] Another question Hi Jari I am interested in multimob, and also have interaction with PMIP implementation team of our company. But, I am not an implementor. BR Frank ----- Original Message -----=20 From: "Jari Arkko" To: Sent: Monday, June 01, 2009 10:47 AM Subject: Re: [multimob] Another question > Was there any response to this? >=20 > Jari Arkko wrote: >> Also, I have another question of my own. This does not have anything=20 >> to do with the technical parts, but more about groups of people who=20 >> are interested in this. Are the people interested in multimob and=20 >> proxy mip disjoint groups? >> >> For instance, are there people who are interested in Multimob going=20 >> forward AND who are, e.g., proxy MIP implementors? >> >> Jari >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> >> >=20 >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Wed Jun 3 11:42:26 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A69328C198 for ; Wed, 3 Jun 2009 11:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PDvOUYdiKnR for ; Wed, 3 Jun 2009 11:42:25 -0700 (PDT) Received: from n60.bullet.mail.sp1.yahoo.com (n60.bullet.mail.sp1.yahoo.com [98.136.44.40]) by core3.amsl.com (Postfix) with SMTP id 9BE7D3A6EA3 for ; Wed, 3 Jun 2009 11:42:25 -0700 (PDT) Received: from [216.252.122.216] by n60.bullet.mail.sp1.yahoo.com with NNFMP; 03 Jun 2009 18:42:25 -0000 Received: from [67.195.9.81] by t1.bullet.sp1.yahoo.com with NNFMP; 03 Jun 2009 18:42:25 -0000 Received: from [67.195.9.110] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 03 Jun 2009 18:42:25 -0000 Received: from [127.0.0.1] by omp114.mail.gq1.yahoo.com with NNFMP; 03 Jun 2009 18:40:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 799409.25518.bm@omp114.mail.gq1.yahoo.com Received: (qmail 89090 invoked by uid 60001); 3 Jun 2009 18:42:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1244054545; bh=ur/H8QUYVvCaWuK+/ZNvDoLOTlQQYRk3XFWpOPQej7Y=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bOjdoVXDyy9hBMqoYUfKlk8RSRaYxPsq8lWa48sR8jFidNDrZg5sbmKEb+nJsznr9oS/kIGturlBqocArkjZKprZrBRQELw75KMKF97Tlxv5RA4MpLqHzZ3IzLG1V5SD+DBRmyvXHBQYr6OAku19Xq5XjHaX63N7lSRQE0JEIFk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZypAUqoLKF3skDm8D/2gXWsaH8RFr16f5qSgYWzqW9mP8TWthq3UkH2qXSLl+XJsuBe9zK1ENo2yov6rjA32+Njmg3ZSlee8cDtLmf7PVKKFCCOcVsOlXnrh/L4/QtgB8pXjG3upQJ8OAQZIB9WVIzVggXtDZrsVdt/knFXDtQg=; Message-ID: <395304.88665.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: BDCqAYQVM1k4pGfD5pfTcYOIyy.1ht7OcOq45NZzaVQu5jZkwRAfo8NHyWfCfkfZOBoSB0tsaJBwzJA.tk3XZuled2xDIaxq8nEDQFJMN_II_lbwkQc0e05ZNxGIxeqfG7koJd30SPPBpu7IVbHv7YGNRxEhOX.kI6P8vcZ770gplgFQHWRh8Aqhn4W3MEaiQElkKZFpTXefAlLwCS9xUyjAdPp8D5gFmcF0af7T6Tu8vfCZ_noSz588CS1wKxVy_78kjsauVOUnzEbl5RaAcRl5zM6XsKdChuduwOIE_5493LHS_nUoH.F0yisbbTJwH1OY0Su0SNFjGLQGxU61_0Iy27evgAtPrg-- Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Wed, 03 Jun 2009 11:42:25 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: Date: Wed, 3 Jun 2009 11:42:25 -0700 (PDT) From: Behcet Sarikaya To: "Zuniga, Juan Carlos" , multimob@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] Another question X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 18:42:26 -0000 Hi JC,=0A=A0 If you have any suggestions to modify the charter according to= your suggested direction, please go through the charter and post it on the= list.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Original Message ----=0AF= rom: "Zuniga, Juan Carlos" =0ATo: Frank= Xia ; Jari Arkko ; multimob@= ietf.org=0ASent: Monday, June 1, 2009 12:32:21 PM=0ASubject: Re: [multimob]= Another question=0A=0AJari,=0A=0AI'm interested in multicast mobility, esp= ecially from the Mobile TV=0Apoint of view. =0A=0APMIP is one of the possib= le scenarios, but I hope that the multimob=0Agroup will consider MIP and ot= her mobility scenarios as well.=0A=0ARegards,=0A=0AJuan Carlos =0A=0A-----O= riginal Message-----=0AFrom: multimob-bounces@ietf.org [mailto:multimob-bou= nces@ietf.org] On=0ABehalf Of Frank Xia=0ASent: Monday, June 01, 2009 1:11 = PM=0ATo: Jari Arkko; multimob@ietf.org=0ASubject: Re: [multimob] Another qu= estion=0A=0AHi Jari=0A=0AI am interested in multimob, and also=0Ahave inter= action with PMIP implementation=0Ateam of our company.=A0 But, I am not=0Aa= n implementor.=0A=0ABR=0AFrank=0A=0A----- Original Message ----- =0AFrom: "= Jari Arkko" =0ATo: =0ASent: Monday= , June 01, 2009 10:47 AM=0ASubject: Re: [multimob] Another question=0A=0A= =0A> Was there any response to this?=0A> =0A> Jari Arkko wrote:=0A>> Also, = I have another question of my own. This does not have anything =0A>> to do = with the technical parts, but more about groups of people who =0A>> are int= erested in this. Are the people interested in multimob and =0A>> proxy mip = disjoint groups?=0A>>=0A>> For instance, are there people who are intereste= d in Multimob going =0A>> forward AND who are, e.g., proxy MIP implementors= ?=0A>>=0A>> Jari=0A>>=0A>> _______________________________________________= =0A>> multimob mailing list=0A>> multimob@ietf.org=0A>> https://www.ietf.or= g/mailman/listinfo/multimob=0A>>=0A>>=0A> =0A> =0A> _______________________= ________________________=0A> multimob mailing list=0A> multimob@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/multimob=0A________________________= _______________________=0Amultimob mailing list=0Amultimob@ietf.org=0Ahttps= ://www.ietf.org/mailman/listinfo/multimob=0A_______________________________= ________________=0Amultimob mailing list=0Amultimob@ietf.org=0Ahttps://www.= ietf.org/mailman/listinfo/multimob=0A=0A=0A=0A From behcetsarikaya@yahoo.com Fri Jun 5 08:54:56 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35C03A6D1C for ; Fri, 5 Jun 2009 08:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=-1.160, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDwYl02trv+d for ; Fri, 5 Jun 2009 08:54:55 -0700 (PDT) Received: from n8.bullet.re3.yahoo.com (n8.bullet.re3.yahoo.com [68.142.237.93]) by core3.amsl.com (Postfix) with SMTP id 756923A6D2B for ; Fri, 5 Jun 2009 08:54:55 -0700 (PDT) Received: from [68.142.237.90] by n8.bullet.re3.yahoo.com with NNFMP; 05 Jun 2009 15:54:56 -0000 Received: from [67.195.9.83] by t6.bullet.re3.yahoo.com with NNFMP; 05 Jun 2009 15:54:56 -0000 Received: from [67.195.9.106] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 05 Jun 2009 15:54:56 -0000 Received: from [127.0.0.1] by omp110.mail.gq1.yahoo.com with NNFMP; 05 Jun 2009 15:53:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 294163.64349.bm@omp110.mail.gq1.yahoo.com Received: (qmail 9853 invoked by uid 60001); 5 Jun 2009 15:54:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1244217295; bh=iCFFHggni3J6PCuMFaxq2V+yH4CUjN0xiIogp5bul4A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=K6ThJY8oF0ULhr+OblIr24necQy6kVI62LhG7Pu6AEF0Z9o+OQnIpxUoFPCY9vcQ0ofIpKTTNOKlZ10s1QKpNJSNFEKuYmZ0z1jJ8ecEZSLBdxftovKSjZM5z3ck5nzhWGKR/jOxWl+JDp/75x5BSdZpj1XpqVFheBJlHkIAwuE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=BFf8s/i/b7w+/lQvqWREMixWv1bJmpetiXrbhZ68O1t72GIIPXFbR9zwvb1bA9p6qCClSAeNqybzBXW7GdErOmTWD2BiI+mhpTo17MCUJxNF6nRQTn48v7SkahXlg/KC5ySPjdIUmRtuh4nd4V4qszCdEazw2DMgmhRoPOTM3iw=; Message-ID: <859159.9674.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: hFv32ukVM1kYYjTa6XEkkUPJjHmkCE7bOvy9hFNrl2Up1turbFjedhc2_dKKI879q3O_vZg0dynlbTfjiAiAMJcgHih9kMCD191pK6RcyZjvrf7Jt2B54JIKIzenoih.DbLaPLS_hwkvwBQzQFmX34W8Fnk3v3bh0Mb4oK9__SRv1P7OsgMtx92IhtgDxEBJFnRJ.GXWGNajcHL1EvhNy_PYzFXQMbSgo7OwMyCrV21ZVnhBirLIHMRqsLqQeKSkrq3d.eB9Ueobc1DVp4JK_H4Txdb8SEUDMYYVAfIpKr418KtFR5_TeYTFJ6wJLwTJYr0SDdr2Ld_rx65wRqwoimkPkiDVq365.64- Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Fri, 05 Jun 2009 08:54:55 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 References: Date: Fri, 5 Jun 2009 08:54:55 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-590744888-1244217295=:9674" Subject: [multimob] multimob post from Chunyan X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 15:54:56 -0000 --0-590744888-1244217295=:9674 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Chunyan, I suggest that you write a draft and/or tell us how the charter sh= ould be modified.=0A=0A--behcet=0A=0A=0A=0A=0A_____________________________= ___=0AFrom: YAO Chunyan =0ASent: 2009=E5=B9=B46=E6=9C=884=E6=97=A5 13:46=0A= To: 'Behcet Sarikaya '; 'multimob@ietf.org'=0ASubject: FW: [multimob] multi= mob post from juancarlos=0A=0A=0ADear=C2=A0Behcet, Thank you very much for = sending me the draft charter!=0A=C2=A0=0AHi,=C2=A0All, It seems that there = is no consideration on multicast source mobility and service procedures in = multimob, right? Could anyone kindly tell me why no consideration on those = issues?=0A=C2=A0=0ARegards,=0AChunyan=0A=0A=0A_____________________________= ___=0AFrom: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] =0ASent: 2009= =E5=B9=B46=E6=9C=882=E6=97=A5 22:24=0ATo: YAO Chunyan; multimob@ietf.org=0A= Subject: Re: [multimob] multimob post from juancarlos=0A=0A=0AHi Chunyan,= =0A=C2=A0 This is the latest charter text incorporating Pierrick's comments= ..=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A=0A________________________________= =0AFrom: YAO Chunyan =0ATo: Behcet Sarika= ya ; multimob@ietf.org=0ACc: Juan Carlos Zuniga =0ASent: Tuesday, June 2, 2009 1:28:38 AM=0ASub= ject: RE: [multimob] multimob post from juancarlos=0A=0A=0A=0AHi, all, I am= interested in multicast mobility also. =0AI am not sure how the charter is= going? There is no further mail since May 19. =0ARegards, =0AChunyan Yao = =0A-----Original Message----- =0AFrom: multimob-bounces@ietf.org [mailto:mu= ltimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya =0ASent: 2009=E5=B9= =B46=E6=9C=882=E6=97=A5 11:10 =0ATo: multimob@ietf.org =0ACc: Juan Carlos Z= uniga =0ASubject: [multimob] multimob post from juancarlos =0A=0A=0A=0A=0A= =0AJari, =0AI'm interested in multicast mobility, especially fm the Mobile = TV point of view. =0APMIP is one of the possible scenarios, but I hope that= the multimob group will consider MIP and other mobility scenarios as well.= =0ARegards, =0AJuan Carlos =0A-----Original Message----- =0AFrom: multimob-= bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Frank Xia = =0ASent: Monday, June 01, 2009 1:11 PM =0ATo: Jari Arkko; multimob@ietf.org= =0ASubject: Re: [multimob] Another question =0AHi Jari =0AI am interested = in multimob, and also =0Ahave interaction with PMIP implementation team of = our company.=C2=A0 But, I am not an implementor. =0ABR =0AFrank =0A----- Or= iginal Message ----- =0AFrom: "Jari Arkko" =0ATo: =0ASent: Monday, June 01, 2009 10:47 AM =0ASubject: Re: [= multimob] Another question =0A=0A> Was there any response to this? =0A> =0A= > Jari Arkko wrote: =0A>> Also, I have another question of my own. This doe= s not have anything =0A>> to do with the technical parts, but more about gr= oups of people who =0A>> are interested in this. Are the people interested = in multimob and =0A>> proxy mip disjoint groups? =0A>> =0A>> For instance, = are there people who are interested in Multimob going =0A>> forward AND who= are, e.g., proxy MIP implementors? =0A>> =0A>> Jari =0Asnipped the rest.= =0A=0A=0A --0-590744888-1244217295=:9674 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Chunyan, I suggest that you write a draft and/or tell = us how the charter should be modified.
=0A
 
=0A--behcet
=0A
<= BR>=0A
=0A
=0AFrom: YAO Chun= yan
Sent: 2009=E5=B9=B46=E6=9C=884=E6=97=A5 13:46
To: = 'Behcet Sarikaya '; 'multimob@ietf.org'
Subject: FW: [multimob] m= ultimob post from juancarlos

=0A
=0A
=0A
Dear Behcet, Thank you very much for sending m= e the draft charter!
=0A
<= /SPAN> 
=0A
Hi, All, It seems that th= ere is no consideration on multicast source mobility and service procedures= in multimob, right? Could anyone kindly tell me why no consideration on th= ose issues?
=0A
 =0A
Regards,
=0A
Chu= nyan

=0A
=0A
=0AFrom: Behcet Sarikaya [mailto:behcetsarikaya@yaho= o.com]
Sent: 2009=E5=B9=B46=E6=9C=882=E6=97=A5 22:24
To: YAO Chunyan; multimob@ietf.org
Subject: Re: [multimob] multimo= b post from juancarlos

=0A
=0A
=0AHi Chunyan,
=0A
  This is the latest charter text incorpor= ating Pierrick's comments.
=0A
 
=0A
Regards,
= =0A
 
=0A
Behcet
=0A

=0A
= =0A
=0AFrom: YAO Chunyan <Chunyan.Yao@alcatel-sbell.com.cn= >
To: Behcet Sarikaya= <sarikaya@ieee.org>; multimob@ietf.org
Cc: Juan Carlos Zuniga <JuanCarlos.Zuniga@INTERDIG= ITAL.COM>
Sent: Tuesd= ay, June 2, 2009 1:28:38 AM
Subject= : RE: [multimob] multimob post from juancarlos

=0A

Hi, all, I am intere= sted in multicast mobility also.

=0A

I am not sure how the charter is going? There= is no further mail since May 19.

=0A

Regards,

=0A

Chunyan Yao

=0A

<= SPAN lang=3Dzh-cn>-----Original Message-----
From: mult= imob-bounces@ietf.org [= mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: 2009=E5=B9=B46=E6=9C= =882=E6=97=A5 11:10
To: multimob@ietf.org
Cc: Juan Carlos Zuniga
Subject: [multimob] multimob post fro= m juancarlos






=0A

Jari,

=0A

I'm interested in multicast mobility, espe= cially fm the Mobile TV point of view.

=0A

PMIP is one of the possible scenarios= , but I hope that the multimob group will consider MIP and other mobility s= cenarios as well.

=0A

Regards,

=0A

Juan Carlos

=0A

= -----Original Message-----
<= SPAN lang=3Dzh-cn>From: multimob-bounces@ietf.= org [mailto:multimob-bo= unces@ietf.org] On Behalf Of Frank Xia
Sent: Monday, June 01, 2009 1:11 PM=
To: Jari Arkko; multim= ob@ietf.org
Subject: Re: [multimob] Another question

=0A

Hi Jari

=0A

I am interested in multimob, = and also
= have interaction with PMIP implementation team of our company.  But, I= am not an implementor.

=0A

BR
Frank

=0A

----- Original Message -----
From: "Jari Arkko" <jari.arkko@pi= uha.net>
To: <multimob@ietf.org>
Sent: Monday, June 01, 2009 10:47 AM =
Subject: Re: [multimob]= Another question


=0A

> Was there any response to this?
<= SPAN lang=3Dzh-cn>>
> Jari Arkko wrote:
>> Also, I h= ave another question of my own. This does not have anything <= BR>>> to do with the = technical parts, but more about groups of people who
>> are interested in this= .. Are the people interested in multimob and
>> proxy mip disjoint groups?
>>
>> For = instance, are there people who are interested in Multimob going
>> forward AND who are, e.= g., proxy MIP implementors?
>>
>> Jari
snipped the rest.


=0A=0A = --0-590744888-1244217295=:9674-- From schmidt@informatik.haw-hamburg.de Fri Jun 5 09:29:12 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078193A6E26 for ; Fri, 5 Jun 2009 09:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oNqeKH2aVHb for ; Fri, 5 Jun 2009 09:29:10 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 9C5E53A6E12 for ; Fri, 5 Jun 2009 09:29:09 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178163223.adsl.alicedsl.de ([85.178.163.223] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MCcI3-0007QZ-Db; Fri, 05 Jun 2009 18:29:11 +0200 Message-ID: <4A2947D3.8030905@informatik.haw-hamburg.de> Date: Fri, 05 Jun 2009 18:29:07 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Behcet Sarikaya References: <859159.9674.qm@web111403.mail.gq1.yahoo.com> In-Reply-To: <859159.9674.qm@web111403.mail.gq1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] multimob post from Chunyan X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 16:29:12 -0000 Hi Chunyan, source mobility is a little more complex and probably not the issue to start with. However, at least in the initial topic list, I suggested to include the issue of basic address transparency for sources. Regarding the general aspects of source mobility, the problem space and solutions published so far, I would like to hint on our problem statement: http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps . This dedicates a larger portion to the the topic. Best regards, Thomas > ------------------------------------------------------------------------ > *From:* YAO Chunyan > *Sent:* 2009å¹´6月4æ—¥ 13:46 > *To:* 'Behcet Sarikaya '; 'multimob@ietf.org' > *Subject:* FW: [multimob] multimob post from juancarlos > > *Dear *Behcet, Thank you very much for sending me the draft charter! > > Hi, All, It seems that there is no consideration on multicast source > mobility and service procedures in multimob, right? Could anyone kindly > tell me why no consideration on those issues? > > Regards, > Chunyan > > ------------------------------------------------------------------------ > *From:* Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > *Sent:* 2009å¹´6月2æ—¥ 22:24 > *To:* YAO Chunyan; multimob@ietf.org > *Subject:* Re: [multimob] multimob post from juancarlos > > Hi Chunyan, > This is the latest charter text incorporating Pierrick's comments. > > Regards, > > Behcet > > ------------------------------------------------------------------------ > *From:* YAO Chunyan > *To:* Behcet Sarikaya ; multimob@ietf.org > *Cc:* Juan Carlos Zuniga > *Sent:* Tuesday, June 2, 2009 1:28:38 AM > *Subject:* RE: [multimob] multimob post from juancarlos > > > Hi, all, I am interested in multicast mobility also. > > I am not sure how the charter is going? There is no further mail since > May 19. > > Regards, > > Chunyan Yao > > -----Original Message----- > From: multimob-bounces@ietf.org [_mailto:multimob-bounces@ietf.org_] On > Behalf Of Behcet Sarikaya > Sent: 2009å¹´6月2æ—¥ 11:10 > To: multimob@ietf.org > Cc: Juan Carlos Zuniga > Subject: [multimob] multimob post from juancarlos > > > > > > > Jari, > > I'm interested in multicast mobility, especially fm the Mobile TV point > of view. > > PMIP is one of the possible scenarios, but I hope that the multimob > group will consider MIP and other mobility scenarios as well. > > Regards, > > Juan Carlos > > -----Original Message----- > From: multimob-bounces@ietf.org [_mailto:multimob-bounces@ietf.org_] On > Behalf Of Frank Xia > Sent: Monday, June 01, 2009 1:11 PM > To: Jari Arkko; multimob@ietf.org > Subject: Re: [multimob] Another question > > Hi Jari > > I am interested in multimob, and also > have interaction with PMIP implementation team of our company. But, I > am not an implementor. > > BR > Frank > > ----- Original Message ----- > From: "Jari Arkko" > To: > Sent: Monday, June 01, 2009 10:47 AM > Subject: Re: [multimob] Another question > > >> Was there any response to this? >> >> Jari Arkko wrote: >> > Also, I have another question of my own. This does not have anything >> > to do with the technical parts, but more about groups of people who >> > are interested in this.. Are the people interested in multimob and >> > proxy mip disjoint groups? >> > >> > For instance, are there people who are interested in Multimob going >> > forward AND who are, e.g., proxy MIP implementors? >> > >> > Jari > snipped the rest. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From gorry@erg.abdn.ac.uk Sat Jun 6 03:34:02 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C0073A6845 for ; Sat, 6 Jun 2009 03:34:02 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XS3NQNQYqijW for ; Sat, 6 Jun 2009 03:34:01 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id D70B43A685A for ; Sat, 6 Jun 2009 03:34:00 -0700 (PDT) Received: from Gorry-Fairhursts-Laptop-6.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n56AXi5R006200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 6 Jun 2009 11:33:44 +0100 (BST) Message-ID: <4A2A4608.2070204@erg.abdn.ac.uk> Date: Sat, 06 Jun 2009 11:33:44 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Subject: [multimob] Comments on: draft-asaeda-multimob-igmp-mld-mobility-extensions-02 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 10:34:02 -0000 https://datatracker.ietf.org/drafts/draft-asaeda-multimob-igmp-mld-mobility-extensions/ I have a few comments (not particularly as a BoF chair) on the above draft. Best wishes, Gorry --- Comments/Questions: * I could not clearly identify the normative changes to be applied in the update - please could you use RFC 2119 language to help clarify the intended changes? * Intro Para 7, /Futhermore,.../ - I am not sure what this sentence is saying about use in SSM? * Section 2.3 - I think we SHOULD consider a case for multiple Queriers. In say, WiFi, this could be a useful scenario, and it would not be good to disregard this case. Do others agree? * The document speaks of a new Hold type being introduced. As I understand, it is assumed that a Join negates a previous Hold? In that case, have the authors considered how re-ordering of packets is addressed, and that the intended final state would be arrived at over paths with (mild) reordering? * I am curious about the treatment of the Hold and Join when a IGMP/MLD Proxy device is inserted between Querier and receiver, and whether there are cases where the semantics of a Join message may be misinterpreted? * Do you expect a Proxy at the IGMP/MLD level to generate Hold messages? * Has the possibility of an additional specific message type to release a hold been considered? - This would allow the join semantics to remain unchanged, there may be other pros/cons? * I'd love to see some bullets (or text) on the Security Considerations to help understand how large a change we may be considering. NiTs * It is allowed to place the copyright notice at the end of a draft - this is slightly easier to read, since the abstract makes the first page. * The current abstract does not clearly call-out what documents would be updated if this were to be published as a PS. * Abstract Sentence 2, English should be improved /to request join or leave multicast sessions/ - It could be even better to avoid the notion of join and leave, and say to inform the Querier of the set of groups that downstream receivers wish to receive? * Intro Para 2, /To create feasible condition/ - not sure the current method is infeasible, but could be suboptimal /traces all downstream/ - English should be improved /and proceed/ - English should be improved * Intro Para 3, - Is this para required, it seems to be generic? * The current document is not clear on calling-out the changes as BCP recommendations (sections 2 and 5?) or standards-track updates (section 3?). Using RFC2119 language would help here. From behcetsarikaya@yahoo.com Thu Jun 11 08:41:12 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30AEF3A6CAD for ; Thu, 11 Jun 2009 08:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUM7-3gOR+FD for ; Thu, 11 Jun 2009 08:41:11 -0700 (PDT) Received: from n8.bullet.re3.yahoo.com (n8.bullet.re3.yahoo.com [68.142.237.93]) by core3.amsl.com (Postfix) with SMTP id 5C11B3A6857 for ; Thu, 11 Jun 2009 08:41:11 -0700 (PDT) Received: from [68.142.237.90] by n8.bullet.re3.yahoo.com with NNFMP; 11 Jun 2009 15:41:16 -0000 Received: from [67.195.9.81] by t6.bullet.re3.yahoo.com with NNFMP; 11 Jun 2009 15:41:16 -0000 Received: from [67.195.9.100] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 11 Jun 2009 15:41:16 -0000 Received: from [127.0.0.1] by omp104.mail.gq1.yahoo.com with NNFMP; 11 Jun 2009 15:41:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 480269.96421.bm@omp104.mail.gq1.yahoo.com Received: (qmail 19838 invoked by uid 60001); 11 Jun 2009 15:41:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1244734876; bh=/5Ues3IJZEtmCz5mNOhytGnO8l4FkW3jg0aFWeD17Xc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=C7QmliBEtiFYI7MA3rZNHWFa1PonKoKvNdY7SYkTLLVmWfBUOdddotPQCYMysGzGPWFzF3NgyVh9UDzXudIAdFKmx+lr78KNkSTzsh8MLIbp3Sqb7S+KQwZeIDT65lwkg3qzlDan5vgJpp4L2fUexW6UT4k9dbz7G25VLuzoFrE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=oEEuwHe6Rj9h0uwHtmE9Fr1mZ4CCWMmp6pOSWLCwZKJ53uluQEFp0bcih6ohl/hebZlyUq2dGDLkmqpCLXkFAc+Qd/nv4TjhZJg4MH7TsHE8RkfhRv8068qi1rTVMMYwc/ahTodwdg6zUqsJzubT+s8WLJLM/QLLo/lfuc09p7w=; Message-ID: <388606.19779.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: NdShCKIVM1lHIgPTuNNtI6.bDTHAwHjbOPB6UORO6EpJr19qL.nDV3tfSn3hYt53Uk1VR0y1EU4QWGnLZ3CLbZJgukTwdn672kN2WWxCtWfjPVugEuwznrHUz3Eqq10j2Q2ZgtaUhloPhQcMsZG.0gWNW.rCu4E8o6qXWNurcE8Lmoye_u.bheAz1sJA1XMOHP64pRFUooGtDSySG.1HvIA73spNWWbmqa9G5YS1psxiSvf6uj_DmLVR8O_3UDlN_8muSW46fQPzyMjEsD_YAMdOuia4agtuX95MHKLoh2NZDtHv82I- Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Thu, 11 Jun 2009 08:41:16 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 Date: Thu, 11 Jun 2009 08:41:16 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multimob] Multimob Architecture X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 15:41:12 -0000 Hello all,=0A=A0 I was wondering if we need to add an architecture document= to the charter. =0AMaybe it will be nice to have a document that brings to= gether the two components of Multimob: group management and mobility protoc= ols.=0A=A0 Regards,=0A=0ABehcet=0A=0A=0A From gorry@erg.abdn.ac.uk Thu Jun 11 11:02:56 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C424B3A6954 for ; Thu, 11 Jun 2009 11:02:56 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEI1umMSssaF for ; Thu, 11 Jun 2009 11:02:56 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id B76113A687F for ; Thu, 11 Jun 2009 11:02:54 -0700 (PDT) Received: from 129-238-wf.tnc2009.rediris.es (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n5BI2pTW018089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 11 Jun 2009 19:02:51 +0100 (BST) Message-ID: <4A3146CB.6020602@erg.abdn.ac.uk> Date: Thu, 11 Jun 2009 20:02:51 +0200 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Behcet Sarikaya References: <388606.19779.qm@web111412.mail.gq1.yahoo.com> In-Reply-To: <388606.19779.qm@web111412.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org Subject: Re: [multimob] Multimob Architecture X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 18:02:56 -0000 Behcet Sarikaya wrote: > Hello all, > I was wondering if we need to add an architecture document to the charter. > Maybe it will be nice to have a document that brings together the two components of Multimob: group management and mobility protocols. > Regards, > > Behcet > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > If there are important architectural issues, we could. I'm not sure I see architectural issues, maybe others do? One other thought: I worry a little that multihoming work has a milestone of 6 months, and while I see this as important, I do not see a draft yet on this topic, so maybe the initial milestone is now too soon. Gorry From schmidt@informatik.haw-hamburg.de Thu Jun 11 11:20:54 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2F83A687F for ; Thu, 11 Jun 2009 11:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbcsMwpN+O8V for ; Thu, 11 Jun 2009 11:20:53 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 101193A6873 for ; Thu, 11 Jun 2009 11:20:52 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from 50-237-wf.tnc2009.rediris.es ([130.206.237.50]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MEotV-000BdA-V3; Thu, 11 Jun 2009 20:20:58 +0200 Message-ID: <4A314B06.6080206@informatik.haw-hamburg.de> Date: Thu, 11 Jun 2009 20:20:54 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <388606.19779.qm@web111412.mail.gq1.yahoo.com> <4A3146CB.6020602@erg.abdn.ac.uk> In-Reply-To: <4A3146CB.6020602@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] Multimob Architecture X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 18:20:54 -0000 Hi Gorry, et al., Gorry Fairhurst wrote: > Behcet Sarikaya wrote: >> Hello all, >> I was wondering if we need to add an architecture document to the >> charter. Maybe it will be nice to have a document that brings together >> the two components of Multimob: group management and mobility protocols. >> Regards, >> >> Behcet >> >> > If there are important architectural issues, we could. I'm not sure I > see architectural issues, maybe others do? > I'm not really convinced that there is any universal architecture: Rather I see quite different settings as defined by the mobility protocols in place. > One other thought: I worry a little that multihoming work has a > milestone of 6 months, and while I see this as important, I do not see a > draft yet on this topic, so maybe the initial milestone is now too soon. > Agree: supposedly, multihoming support is one of the more complex issues. Personally, I don't have a clear picture on how to best deal with it. So 6 month might be really too ambitious. Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From schmidt@informatik.haw-hamburg.de Fri Jun 12 11:55:44 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6BF43A69D0 for ; Fri, 12 Jun 2009 11:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfLm9mg1hTF6 for ; Fri, 12 Jun 2009 11:55:43 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 732DF3A677C for ; Fri, 12 Jun 2009 11:55:41 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from 124.red-80-36-164.staticip.rima-tde.net ([80.36.164.124] helo=[10.59.1.67]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MFBul-000NIa-Uw; Fri, 12 Jun 2009 20:55:48 +0200 Message-ID: <4A32A4AD.1000800@informatik.haw-hamburg.de> Date: Fri, 12 Jun 2009 20:55:41 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <4A2A4608.2070204@erg.abdn.ac.uk> In-Reply-To: <4A2A4608.2070204@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] Comments on: draft-asaeda-multimob-igmp-mld-mobility-extensions-02 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 18:55:44 -0000 Hi Gorry, many thanks for reading the draft and your detailed comments. In total I agree that this is a very premature document and requires thorough rewriting. In particular, I'd like to suggest a splitting of the document into two: * one BCP document on how to tune MLD best in wireless domains and mobile regimes. * another standard track document on protocol extensions like the listener hold option. Both parts of the current document are quite sketchy and unfinished. So we will happily take your comments and suggestions as input for working out the key elements and re-writing the drafts. Presently, I don't see much value in discussing further at this state of progress ;) Thanks, Thomas Gorry Fairhurst wrote: > https://datatracker.ietf.org/drafts/draft-asaeda-multimob-igmp-mld-mobility-extensions/ > > > I have a few comments (not particularly as a BoF chair) on the above draft. > > Best wishes, > > Gorry > > --- > > Comments/Questions: > > * I could not clearly identify the normative changes to be applied in > the update - please could you use RFC 2119 language to help clarify the > intended changes? > > * Intro Para 7, > /Futhermore,.../ > - I am not sure what this sentence is saying about use in SSM? > > * Section 2.3 > - I think we SHOULD consider a case for multiple Queriers. In say, WiFi, > this could be a useful scenario, and it would not be good to disregard > this case. Do others agree? > > * The document speaks of a new Hold type being introduced. As I > understand, it is assumed that a Join negates a previous Hold? In that > case, have the authors considered how re-ordering of packets is > addressed, and that the intended final state would be arrived at over > paths with (mild) reordering? > > * I am curious about the treatment of the Hold and Join when a IGMP/MLD > Proxy device is inserted between Querier and receiver, and whether there > are cases where the semantics of a Join message may be misinterpreted? > > * Do you expect a Proxy at the IGMP/MLD level to generate Hold messages? > > * Has the possibility of an additional specific message type to release > a hold been considered? - This would allow the join semantics to remain > unchanged, there may be other pros/cons? > > * I'd love to see some bullets (or text) on the Security Considerations > to help understand how large a change we may be considering. > > NiTs > > * It is allowed to place the copyright notice at the end of a draft - > this is slightly easier to read, since the abstract makes the first page. > > * The current abstract does not clearly call-out what documents would be > updated if this were to be published as a PS. > > * Abstract Sentence 2, English should be improved > /to request join or leave multicast sessions/ > - It could be even better to avoid the notion of join and leave, and say > to inform the Querier of the set of groups that downstream receivers > wish to receive? > > * Intro Para 2, > /To create feasible condition/ > - not sure the current method is infeasible, but could be suboptimal > /traces all downstream/ > - English should be improved > /and proceed/ > - English should be improved > > * Intro Para 3, > - Is this para required, it seems to be generic? > > * The current document is not clear on calling-out the changes as BCP > recommendations (sections 2 and 5?) or standards-track updates (section > 3?). Using RFC2119 language would help here. > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From asaeda@sfc.wide.ad.jp Fri Jun 12 20:38:54 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41CAF3A68D5 for ; Fri, 12 Jun 2009 20:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B04s5Z6MiLZ7 for ; Fri, 12 Jun 2009 20:38:53 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 323BE3A685D for ; Fri, 12 Jun 2009 20:38:52 -0700 (PDT) Received: from localhost (dhcp-246-6.mag.keio.ac.jp [133.27.246.6]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 6A4CE13D06C4 for ; Sat, 13 Jun 2009 12:38:59 +0900 (JST) Date: Sat, 13 Jun 2009 12:38:59 +0900 (JST) Message-Id: <20090613.123859.146111367.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <4A2A4608.2070204@erg.abdn.ac.uk> References: <4A2A4608.2070204@erg.abdn.ac.uk> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Comments on: draft-asaeda-multimob-igmp-mld-mobility-extensions-02 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 03:38:54 -0000 Gorry, Thanks for comments. > * The current document is not clear on calling-out the changes as > BCP recommendations (sections 2 and 5?) or standards-track updates > (section 3?). Using RFC2119 language would help here. Neither PS nor BCP is mentioned as the intention of this draft. We may divide into two drafts, one for PS and the other for BCP (timer tuning and optimization being useful as the operational guideline), if consensus. Some of your comments will be then fulfilled in these drafts. Thomas, > drafts. Presently, I don't see much value in discussing further at > this state of progress ;) It's not my thought. It's good to hear comments in any stage or any time. While my response may be delayed sometimes, I'll take into account given comments or reply my opinions later. I'd appreciate any comment. Furthermore just saying "premature" does not improve anything.. > --- > > Comments/Questions: > > * I could not clearly identify the normative changes to be applied > in the update - please could you use RFC 2119 language to help > clarify the intended changes? I'll fix it in the separate drafts. > * Intro Para 7, > /Futhermore,.../ > - I am not sure what this sentence is saying about use in SSM? It is not about SSM itself. It explains that coexisting exclude mode operations in multicast communication will reduce SSM advantage, because an exclude mode operation will re-organize multicast routing tree with RPT. I'd like to clarify the issue here. Note that many sentenses in the intro paragraph including this sentence are for an operational guideline (which will be a BCP draft), not PS draft maybe. > * Section 2.3 > - I think we SHOULD consider a case for multiple Queriers. In say, > WiFi, this could be a useful scenario, and it would not be good to > disregard this case. Do others agree? Maybe yes. Sect.2.3 does not deny the case, but wants to clarify the issue. This discussion will be in BCP draft. > * The document speaks of a new Hold type being introduced. As I > understand, it is assumed that a Join negates a previous Hold? In Yes. > that case, have the authors considered how re-ordering of packets is > addressed, and that the intended final state would be arrived at > over paths with (mild) reordering? Good catch. In the next revision, I'd say; "... The router then sends the corresponding Group-Specific or Group-and-Source Specific Query upon reception of an IGMP/MLD Hold message. If the router receives the IGMP/MLD report, it ignores the IGMP/MLD Hold message and keeps forwarding the data." Make sense? > * I am curious about the treatment of the Hold and Join when a > IGMP/MLD Proxy device is inserted between Querier and receiver, and > whether there are cases where the semantics of a Join message may be > misinterpreted? In that case IGMP/MLD Proxy device is the querier for its downstream nodes and *it* deals with the Hold message. Currently IGMP/MLD Proxy does not forward Hold messages to its upstream routers. So the data still comes to that proxy even if it receives Hold from its downstream. I prefer this simple scenario. > * Do you expect a Proxy at the IGMP/MLD level to generate Hold messages? ditto. > * Has the possibility of an additional specific message type to > release a hold been considered? - This would allow the join > semantics to remain unchanged, there may be other pros/cons? So the answer is same as of above "re-ordering" issue. > * I'd love to see some bullets (or text) on the Security > Considerations to help understand how large a change we may be > considering. I got it. I'll improve the whole text as well. Thanks, -- Hitoshi Asaeda From schmidt@informatik.haw-hamburg.de Sat Jun 13 14:26:43 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CF613A6C26 for ; Sat, 13 Jun 2009 14:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEN-kBGRcCEh for ; Sat, 13 Jun 2009 14:26:42 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id D29E03A6A32 for ; Sat, 13 Jun 2009 14:26:41 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178155159.adsl.alicedsl.de ([85.178.155.159] helo=[192.168.178.23]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MFakT-000Hay-9O for multimob@ietf.org; Sat, 13 Jun 2009 23:26:49 +0200 Message-ID: <4A341991.205@informatik.haw-hamburg.de> Date: Sat, 13 Jun 2009 23:26:41 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 21:26:43 -0000 Dear all, multicast support for PMIPv6 domains has been one of the most debated issues for Multimob, and at the same time some divergent understanding of the topic arose. As promised earlier, we have now prepared a document defining multicast listener support in PMIPv6 domains solely on the basis of standardized IETF protocols (see below): http://www.ietf.org/internet-drafts/draft-schmidt-multimob-pmipv6-mcast-deployment-00.txt It assigns the role of MLD proxies to MAGs and standard MLD queriers to LMAs, and we believe this is the minimal solution solely based on standard protocol behavior. At the price of "full multicast" functions at MAG and LMA, this approach provides some (but not all possible) traffic aggregations. In parallel, I should point on an alternative approach published earlier: http://tools.ietf.org/html/draft-gundavelli-multimob-pmip6basicmcast-solution This approach uses minimal, but non-standard MLD forwarding at the MAG and individual, unidirectional data tunneling from LMA to MN. MLD support at the MAG is thus more lightweight on the price of a complete loss of traffic aggregation. Both drafts should serve as a good starting point for defining a "minimal multicast standard" in PMIPv6 - and for discussions prior to the BoF in Stockholm. Looking forward to your comments! Thomas ---------------------------- snip ---------------------------------- A new version of I-D, draft-schmidt-multimob-pmipv6-mcast-deployment-00.txt has been successfuly submitted by Thomas Schmidt and posted to the IETF repository. Filename: draft-schmidt-multimob-pmipv6-mcast-deployment Revision: 00 Title: A Minimal Deployment Option for Multicast Listeners in PMIPv6 Domains Creation_date: 2009-06-13 WG ID: Independent Submission Number_of_pages: 10 Abstract: This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, Mobile Nodes remain agnostic of multicast mobility operations. -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From asaeda@sfc.wide.ad.jp Sat Jun 13 19:30:57 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29E543A695B for ; Sat, 13 Jun 2009 19:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.495 X-Spam-Level: *** X-Spam-Status: No, score=3.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l38jHSDwb83Z for ; Sat, 13 Jun 2009 19:30:56 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 3F26B3A68AF for ; Sat, 13 Jun 2009 19:30:55 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id EE7F013D06C4 for ; Sun, 14 Jun 2009 11:31:02 +0900 (JST) Date: Sun, 14 Jun 2009 11:31:04 +0900 (JST) Message-Id: <20090614.113104.91330668.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <20090613.123859.146111367.asaeda@sfc.wide.ad.jp> References: <4A2A4608.2070204@erg.abdn.ac.uk> <20090613.123859.146111367.asaeda@sfc.wide.ad.jp> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Comments on: draft-asaeda-multimob-igmp-mld-mobility-extensions-02 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 02:30:57 -0000 I'm sorry, I found a bug in my previous mail. So I'd correct my reply. > > * I am curious about the treatment of the Hold and Join when a > > IGMP/MLD Proxy device is inserted between Querier and receiver, and > > whether there are cases where the semantics of a Join message may be > > misinterpreted? > > In that case IGMP/MLD Proxy device is the querier for its downstream > nodes and *it* deals with the Hold message. > > Currently IGMP/MLD Proxy does not forward Hold messages to its > upstream routers. So the data still comes to that proxy even if it > receives Hold from its downstream. > I prefer this simple scenario. This my answer is not correct. For instance, PMIPv6 multicast explained in the following draft; http://tools.ietf.org/html/draft-asaeda-multimob-pmip6-extension-01 MAG can behave as an MLD proxy. In that case, MAG MUST forward MLD hold messages given from its MNs to the LMA, and LMA deals with the messages and decides if it keeps join state or not. Therefore, yes, IGMP/MLD proxy must forward hold messages to its upstream routers. This is the required extension for the use of hold/release extension. Thanks for reminding me. Regards, -- Hitoshi Asaeda From gorry@erg.abdn.ac.uk Sun Jun 14 00:39:09 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD083A6811 for ; Sun, 14 Jun 2009 00:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NK7Qp23h5Ge0 for ; Sun, 14 Jun 2009 00:39:08 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 84BAA3A65A6 for ; Sun, 14 Jun 2009 00:39:07 -0700 (PDT) Received: from Gorry-Fairhursts-Laptop-6.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n5E7clX1002870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 14 Jun 2009 08:38:48 +0100 (BST) Message-ID: <4A34A907.5070801@erg.abdn.ac.uk> Date: Sun, 14 Jun 2009 08:38:47 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hitoshi Asaeda References: <4A2A4608.2070204@erg.abdn.ac.uk> <20090613.123859.146111367.asaeda@sfc.wide.ad.jp> <20090614.113104.91330668.asaeda@sfc.wide.ad.jp> In-Reply-To: <20090614.113104.91330668.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org Subject: Re: [multimob] Comments on: draft-asaeda-multimob-igmp-mld-mobility-extensions-02 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 07:39:09 -0000 Yes, that seems appropriate to me, thanks for the clarification. Best wishes, Gorry Hitoshi Asaeda wrote: > I'm sorry, I found a bug in my previous mail. So I'd correct my reply. > >>> * I am curious about the treatment of the Hold and Join when a >>> IGMP/MLD Proxy device is inserted between Querier and receiver, and >>> whether there are cases where the semantics of a Join message may be >>> misinterpreted? >> In that case IGMP/MLD Proxy device is the querier for its downstream >> nodes and *it* deals with the Hold message. >> >> Currently IGMP/MLD Proxy does not forward Hold messages to its >> upstream routers. So the data still comes to that proxy even if it >> receives Hold from its downstream. >> I prefer this simple scenario. > > This my answer is not correct. > > For instance, PMIPv6 multicast explained in the following draft; > http://tools.ietf.org/html/draft-asaeda-multimob-pmip6-extension-01 > MAG can behave as an MLD proxy. > In that case, MAG MUST forward MLD hold messages given from its MNs to > the LMA, and LMA deals with the messages and decides if it keeps join > state or not. > > Therefore, yes, IGMP/MLD proxy must forward hold messages to its > upstream routers. > This is the required extension for the use of hold/release extension. > > Thanks for reminding me. > Regards, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > From gorry@erg.abdn.ac.uk Sun Jun 14 00:40:06 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6005E3A6805 for ; Sun, 14 Jun 2009 00:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUd-bFy84SRe for ; Sun, 14 Jun 2009 00:40:05 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 310723A65A6 for ; Sun, 14 Jun 2009 00:40:05 -0700 (PDT) Received: from Gorry-Fairhursts-Laptop-6.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n5E7ciRh002868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 14 Jun 2009 08:38:46 +0100 (BST) Message-ID: <4A34A904.6010907@erg.abdn.ac.uk> Date: Sun, 14 Jun 2009 08:38:44 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hitoshi Asaeda References: <4A2A4608.2070204@erg.abdn.ac.uk> <20090613.123859.146111367.asaeda@sfc.wide.ad.jp> In-Reply-To: <20090613.123859.146111367.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org Subject: Re: [multimob] Comments on: draft-asaeda-multimob-igmp-mld-mobility-extensions-02 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 07:40:06 -0000 See comments in-line, and look forward to an updated contribution. Do you plan to split the draft into two parts or two I-Ds next revision? Gorry Hitoshi Asaeda wrote: > Gorry, > > Thanks for comments. > >> * The current document is not clear on calling-out the changes as >> BCP recommendations (sections 2 and 5?) or standards-track updates >> (section 3?). Using RFC2119 language would help here. > > Neither PS nor BCP is mentioned as the intention of this draft. > We may divide into two drafts, one for PS and the other for BCP > (timer tuning and optimization being useful as the operational > guideline), if consensus. Some of your comments will be then fulfilled > in these drafts. > I think we agree. > > Thomas, > >> drafts. Presently, I don't see much value in discussing further at >> this state of progress ;) > > It's not my thought. > It's good to hear comments in any stage or any time. > While my response may be delayed sometimes, I'll take into account > given comments or reply my opinions later. I'd appreciate any > comment. > > Furthermore just saying "premature" does not improve anything.. > >> --- >> >> Comments/Questions: >> >> * I could not clearly identify the normative changes to be applied >> in the update - please could you use RFC 2119 language to help >> clarify the intended changes? > > I'll fix it in the separate drafts. > >> * Intro Para 7, >> /Futhermore,.../ >> - I am not sure what this sentence is saying about use in SSM? > > It is not about SSM itself. It explains that coexisting exclude mode > operations in multicast communication will reduce SSM advantage, > because an exclude mode operation will re-organize multicast routing > tree with RPT. I'd like to clarify the issue here. > OK - some clarification would be good next revision. > Note that many sentences in the intro paragraph including this > sentence are for an operational guideline (which will be a BCP draft), > not PS draft maybe. > >> * Section 2.3 >> - I think we SHOULD consider a case for multiple Queriers. In say, >> WiFi, this could be a useful scenario, and it would not be good to >> disregard this case. Do others agree? > > Maybe yes. > Sect.2.3 does not deny the case, but wants to clarify the issue. This > discussion will be in BCP draft. > >> * The document speaks of a new Hold type being introduced. As I >> understand, it is assumed that a Join negates a previous Hold? In > > Yes. > >> that case, have the authors considered how re-ordering of packets is >> addressed, and that the intended final state would be arrived at >> over paths with (mild) reordering? > > Good catch. > In the next revision, I'd say; > "... The router then sends the corresponding Group-Specific or > Group-and-Source Specific Query upon reception of an IGMP/MLD Hold > message. If the router receives the IGMP/MLD report, it ignores the > IGMP/MLD Hold message and keeps forwarding the data." > > Make sense? > Maybe. I'd like to see how the specification develops and then look again whether this has been addressed. > >> * I am curious about the treatment of the Hold and Join when a >> IGMP/MLD Proxy device is inserted between Querier and receiver, and >> whether there are cases where the semantics of a Join message may be >> misinterpreted? > > In that case IGMP/MLD Proxy device is the querier for its downstream > nodes and *it* deals with the Hold message. > > Currently IGMP/MLD Proxy does not forward Hold messages to its > upstream routers. So the data still comes to that proxy even if it > receives Hold from its downstream. > I prefer this simple scenario. > Updated in later email. >> * Do you expect a Proxy at the IGMP/MLD level to generate Hold messages? > > ditto. > >> * Has the possibility of an additional specific message type to >> release a hold been considered? - This would allow the join >> semantics to remain unchanged, there may be other pros/cons? > > So the answer is same as of above "re-ordering" issue. > >> * I'd love to see some bullets (or text) on the Security >> Considerations to help understand how large a change we may be >> considering. > > I got it. > > I'll improve the whole text as well. > > Thanks, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > From asaeda@sfc.wide.ad.jp Sun Jun 14 03:25:13 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38023A67B0 for ; Sun, 14 Jun 2009 03:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.883 X-Spam-Level: *** X-Spam-Status: No, score=3.883 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUr6SFnDk7vb for ; Sun, 14 Jun 2009 03:25:13 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id E53A63A67A1 for ; Sun, 14 Jun 2009 03:25:12 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 4889813D06C4 for ; Sun, 14 Jun 2009 19:25:20 +0900 (JST) Date: Sun, 14 Jun 2009 19:25:19 +0900 (JST) Message-Id: <20090614.192519.45824159.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <4A34A904.6010907@erg.abdn.ac.uk> References: <4A2A4608.2070204@erg.abdn.ac.uk> <20090613.123859.146111367.asaeda@sfc.wide.ad.jp> <4A34A904.6010907@erg.abdn.ac.uk> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Comments on: draft-asaeda-multimob-igmp-mld-mobility-extensions-02 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 10:25:13 -0000 > Do you plan to split the draft into two parts or two I-Ds next revision? Split into two I-Ds. One for PS draft (protocol extensions including hold/release messages and operations) and the other for BCP draft (timer tuning and protocol optimization without message format change). Regards, -- Hitoshi Asaeda From liuhui47967@huawei.com Sun Jun 14 06:21:36 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 512D33A6821 for ; Sun, 14 Jun 2009 06:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.515 X-Spam-Level: X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPItPthbunHK for ; Sun, 14 Jun 2009 06:21:35 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 736CA3A6C84 for ; Sun, 14 Jun 2009 06:21:35 -0700 (PDT) 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 <0KL800BNPD43DZ@szxga04-in.huawei.com> for multimob@ietf.org; Sun, 14 Jun 2009 21:21:39 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL800EG5D43G5@szxga04-in.huawei.com> for multimob@ietf.org; Sun, 14 Jun 2009 21:21:39 +0800 (CST) Received: from l47967b ([10.111.12.139]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL800ELID436C@szxml04-in.huawei.com> for multimob@ietf.org; Sun, 14 Jun 2009 21:21:39 +0800 (CST) Date: Sun, 14 Jun 2009 21:21:38 +0800 From: Liu Hui To: multimob@ietf.org Message-id: <00a801c9ecf3$0cceb050$8b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_MJ/lCkJLXbFKFTNpJsYQUw)" Thread-index: Acns8wyAJLiXJlLZRaqjRuPjZ91PvA== Subject: [multimob] An architecture draft for multicast receiver mobility X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 13:21:36 -0000 This is a multi-part message in MIME format. --Boundary_(ID_MJ/lCkJLXbFKFTNpJsYQUw) Content-type: text/plain; charset=windows-1250 Content-transfer-encoding: 7BIT Hi all, I prepare an architecture draft for Multicast Receiver Mobility. It describes the various aspects to be considered such as MIP signalling, group management, multicast routing, handover optimization and etc. in receiver mobility senario. These issues are analyzed and possible solution are suggested in the draft. Some of them are based on the contributions of the list. Currently it does not yet cover all MIP protocols, and all the issues and solutions. Other issues could be included later if necessary. You are welcome to provide comments or inputs to it. The draft could be found at: http://www.ietf.org/internet-drafts/draft-liu-multimob-multicast-receiver-mo bility-00.txt Best Regards, Liu Hui --Boundary_(ID_MJ/lCkJLXbFKFTNpJsYQUw) Content-type: text/html; charset=windows-1250 Content-transfer-encoding: 7BIT
Hi all,
 
I prepare an architecture draft for Multicast Receiver Mobility.  It describes the various aspects to be considered such as MIP signalling, group management, multicast routing, handover optimization and etc. in receiver mobility senario.  These issues are analyzed and possible solution are suggested in the draft. Some of them are based on the contributions of the list.
 
Currently it does not yet cover all MIP protocols, and all the issues and solutions.  Other issues could be included later if necessary.  You are welcome to provide comments or inputs to it.  The draft could be found at:
 
http://www.ietf.org/internet-drafts/draft-liu-multimob-multicast-receiver-mobility-00.txt
 
 
Best Regards,
Liu Hui
--Boundary_(ID_MJ/lCkJLXbFKFTNpJsYQUw)-- From liuhui47967@huawei.com Sun Jun 14 19:47:03 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19C128C0CF for ; Sun, 14 Jun 2009 19:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkH+ckW6AYE3 for ; Sun, 14 Jun 2009 19:47:02 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4CE403A6C7D for ; Sun, 14 Jun 2009 19:47:02 -0700 (PDT) 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 <0KL9006F4EBQCS@szxga04-in.huawei.com> for multimob@ietf.org; Mon, 15 Jun 2009 10:45:26 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL900L4EEBQAM@szxga04-in.huawei.com> for multimob@ietf.org; Mon, 15 Jun 2009 10:45:26 +0800 (CST) Received: from l47967b ([10.111.12.139]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL900MUQEBPXJ@szxml06-in.huawei.com> for multimob@ietf.org; Mon, 15 Jun 2009 10:45:26 +0800 (CST) Date: Mon, 15 Jun 2009 10:45:25 +0800 From: Liu Hui In-reply-to: <4A341991.205@informatik.haw-hamburg.de> To: "'Thomas C. Schmidt'" , multimob@ietf.org Message-id: <002d01c9ed63$562b6700$8b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Thread-index: AcnsbbUOOVdknk9YTgy9L3vp9nPgqQA82L3w Subject: Re: [multimob] New Version Notification fordraft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 02:47:03 -0000 Hi Thomas, I have a question and a comment.=20 AFAIK, the standard IGMP/MLD proxy (MAG in the draft) usually sends = summary report to its upstream equipment. Thus the source address of = the report should be set to the address of MAG but not the address of = MN. If this is the case, how LMA tell which MN triggers the report ? Is = it possible to realize explicit tracking on LMA for each MN in this = solution? In section 3, multicast data will "flow from the LMA to the MN on an = LMA-specific shared tree." It seems not very clear what this shared = tree is. Is it the tunnel from LMA to MAG? Because multicast routing = protocol are not involved here, it it better not to use shared tree = here. Best Regards, Liu Hui > -----Original Message----- > From: multimob-bounces@ietf.org=20 > [mailto:multimob-bounces@ietf.org] On Behalf Of Thomas C. Schmidt > Sent: Sunday, June 14, 2009 5:27 AM > To: multimob@ietf.org > Subject: [multimob] New Version Notification=20 > fordraft-schmidt-multimob-pmipv6-mcast-deployment-00 >=20 > Dear all, >=20 > multicast support for PMIPv6 domains has been one of the=20 > most debated > issues for Multimob, and at the same time some divergent=20 > understanding > of the topic arose. >=20 > As promised earlier, we have now prepared a document defining > multicast listener support in PMIPv6 domains solely on the basis of > standardized IETF protocols (see below):=20 > http://www.ietf.org/internet-drafts/draft-schmidt-multimob-pmi > pv6-mcast-deployment-00.txt=20 >=20 >=20 > It assigns the role of MLD proxies to MAGs and standard MLD queriers > to LMAs, and we believe this is the minimal solution solely based on > standard protocol behavior. >=20 > At the price of "full multicast" functions at MAG and LMA, this > approach provides some (but not all possible) traffic aggregations. >=20 > In parallel, I should point on an alternative approach=20 > published earlier: > http://tools.ietf.org/html/draft-gundavelli-multimob-pmip6basi > cmcast-solution >=20 > This approach uses minimal, but non-standard MLD forwarding=20 > at the MAG and > individual, unidirectional data tunneling from LMA to MN.=20 > MLD support at the > MAG is thus more lightweight on the price of a complete=20 > loss of traffic > aggregation. >=20 > Both drafts should serve as a good starting point for=20 > defining a "minimal > multicast standard" in PMIPv6 - and for discussions prior=20 > to the BoF in Stockholm. >=20 > Looking forward to your comments! >=20 > Thomas >=20 > ---------------------------- snip ---------------------------------- >=20 > A new version of I-D, > draft-schmidt-multimob-pmipv6-mcast-deployment-00.txt has=20 > been successfuly submitted by Thomas Schmidt and posted to=20 > the IETF repository. >=20 > Filename: draft-schmidt-multimob-pmipv6-mcast-deployment > Revision: 00 > Title: A Minimal Deployment Option for=20 > Multicast Listeners in PMIPv6=20 > Domains > Creation_date: 2009-06-13 > WG ID: Independent Submission > Number_of_pages: 10 >=20 > Abstract: > This document describes deployment options for activating=20 > multicast listener functions in Proxy Mobile IPv6 domains=20 > without modifying mobility and multicast protocol standards. =20 > Similar to Home Agents in Mobile IPv6, PMIPv6 Local Mobility=20 > Anchors serve as multicast subscription anchor points, while=20 > Mobile Access Gateways provide MLD proxy functions. In this=20 > scenario, Mobile Nodes remain agnostic of multicast mobility=20 > operations. > =20 >=20 >=20 >=20 > --=20 >=20 > Prof. Dr. Thomas C. Schmidt > =C2=B0 Hamburg University of Applied Sciences =20 > Berliner Tor 7 =C2=B0 > =C2=B0 Dept. Informatik, Internet Technologies Group 20099=20 > Hamburg, Germany =C2=B0 > =C2=B0 http://www.haw-hamburg.de/inet Fon:=20 > +49-40-42875-8452 =C2=B0 > =C2=B0 http://www.informatik.haw-hamburg.de/~schmidt Fax:=20 > +49-40-42875-8409 =C2=B0 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob >=20 From waehlisch@ieee.org Mon Jun 15 04:49:58 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F382728C127 for ; Mon, 15 Jun 2009 04:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wkf4tkDrQeAK for ; Mon, 15 Jun 2009 04:49:57 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id CF1E73A6C0A for ; Mon, 15 Jun 2009 04:49:56 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from imp051023.vpn.mi.fu-berlin.de ([130.133.51.23] helo=mw-thinkpad) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MGAh2-0002i1-BH; Mon, 15 Jun 2009 13:49:40 +0200 Date: Mon, 15 Jun 2009 13:49:42 +0200 From: Matthias Waehlisch To: Liu Hui In-Reply-To: <002d01c9ed63$562b6700$8b0c6f0a@china.huawei.com> Message-ID: References: <002d01c9ed63$562b6700$8b0c6f0a@china.huawei.com> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: multimob@ietf.org, "'Thomas C. Schmidt'" Subject: Re: [multimob] New Version Notification fordraft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 11:49:58 -0000 Hi Liu, On Mon, 15 Jun 2009, Liu Hui wrote: > AFAIK, the standard IGMP/MLD proxy (MAG in the draft) usually sends > summary report to its upstream equipment. > yes, MLD reports based on the RFC4605-membership database. > Thus the source address of the report should be set to the address of > MAG but not the address of MN. If this is the case, how LMA tell which > MN triggers the report ? Is it possible to realize explicit tracking on > LMA for each MN in this solution? > Hm, maybe you are right: the explicit tracking is bound to the proxy, i.e., MAG due aggregation based on RFC4605. We will rethink it. However, the explicit tracking is a minor optimization. The general operation is not affected by this. > In section 3, multicast data will "flow from the LMA to the MN on an > LMA-specific shared tree." It seems not very clear what this shared > tree is. Is it the tunnel from LMA to MAG? Because multicast routing > protocol are not involved here, it it better not to use shared tree > here. > The intention was to highlight that multicast data cannot flow following a source specific path between multicast sender and MN but via the LMA. Thanks for your comments matthias -- Matthias Waehlisch . FU Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From schmidt@informatik.haw-hamburg.de Mon Jun 15 14:37:57 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05D843A6C68 for ; Mon, 15 Jun 2009 14:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ct+1fdLJKQ3 for ; Mon, 15 Jun 2009 14:37:55 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 770FE3A69C5 for ; Mon, 15 Jun 2009 14:37:53 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from p54a7187a.dip0.t-ipconnect.de ([84.167.24.122] helo=[172.30.3.102]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MGJsG-0006xk-WE; Mon, 15 Jun 2009 23:37:53 +0200 Message-ID: <4A36BF2A.8000307@informatik.haw-hamburg.de> Date: Mon, 15 Jun 2009 23:37:46 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Liu Hui References: <002d01c9ed63$562b6700$8b0c6f0a@china.huawei.com> In-Reply-To: <002d01c9ed63$562b6700$8b0c6f0a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] New Version Notification fordraft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 21:37:57 -0000 Hi Liu, Liu Hui wrote: > AFAIK, the standard IGMP/MLD proxy (MAG in the draft) usually sends summary report to its upstream equipment. Thus the source address of the report should be set to the address of MAG but not the address of MN. If this is the case, how LMA tell which MN triggers the report ? Is it possible to realize explicit tracking on LMA for each MN in this solution? As Matthias already wrote: you're right, we have been too quick and assuming knowledge of the MN at the LMA is a lapse. Thanks for the hint. So, explicit tracking is actually not an option - we will remove this. However, the base scheme is unaffected, as reports and querying work. > In section 3, multicast data will "flow from the LMA to the MN on an LMA-specific shared tree." It seems not very clear what this shared tree is. Is it the tunnel from LMA to MAG? Because multicast routing protocol are not involved here, it it better not to use shared tree here. Well, that's a matter of taste - we can remove shared tree, if you think. There is tree built from the LMA to (one or several) MAGs and further to (one or several) MNs, which is shared among sources. So it actually is a shared tree, but not erected by PIM-SM, that's right. We should probably state this more explicit. Thanks for your valuable comments! Thomas > > > >> -----Original Message----- >> From: multimob-bounces@ietf.org >> [mailto:multimob-bounces@ietf.org] On Behalf Of Thomas C. Schmidt >> Sent: Sunday, June 14, 2009 5:27 AM >> To: multimob@ietf.org >> Subject: [multimob] New Version Notification >> fordraft-schmidt-multimob-pmipv6-mcast-deployment-00 >> >> Dear all, >> >> multicast support for PMIPv6 domains has been one of the >> most debated >> issues for Multimob, and at the same time some divergent >> understanding >> of the topic arose. >> >> As promised earlier, we have now prepared a document defining >> multicast listener support in PMIPv6 domains solely on the basis of >> standardized IETF protocols (see below): >> http://www.ietf.org/internet-drafts/draft-schmidt-multimob-pmi >> pv6-mcast-deployment-00.txt >> >> >> It assigns the role of MLD proxies to MAGs and standard MLD queriers >> to LMAs, and we believe this is the minimal solution solely based on >> standard protocol behavior. >> >> At the price of "full multicast" functions at MAG and LMA, this >> approach provides some (but not all possible) traffic aggregations. >> >> In parallel, I should point on an alternative approach >> published earlier: >> http://tools.ietf.org/html/draft-gundavelli-multimob-pmip6basi >> cmcast-solution >> >> This approach uses minimal, but non-standard MLD forwarding >> at the MAG and >> individual, unidirectional data tunneling from LMA to MN. >> MLD support at the >> MAG is thus more lightweight on the price of a complete >> loss of traffic >> aggregation. >> >> Both drafts should serve as a good starting point for >> defining a "minimal >> multicast standard" in PMIPv6 - and for discussions prior >> to the BoF in Stockholm. >> >> Looking forward to your comments! >> >> Thomas >> >> ---------------------------- snip ---------------------------------- >> >> A new version of I-D, >> draft-schmidt-multimob-pmipv6-mcast-deployment-00.txt has >> been successfuly submitted by Thomas Schmidt and posted to >> the IETF repository. >> >> Filename: draft-schmidt-multimob-pmipv6-mcast-deployment >> Revision: 00 >> Title: A Minimal Deployment Option for >> Multicast Listeners in PMIPv6 >> Domains >> Creation_date: 2009-06-13 >> WG ID: Independent Submission >> Number_of_pages: 10 >> >> Abstract: >> This document describes deployment options for activating >> multicast listener functions in Proxy Mobile IPv6 domains >> without modifying mobility and multicast protocol standards. >> Similar to Home Agents in Mobile IPv6, PMIPv6 Local Mobility >> Anchors serve as multicast subscription anchor points, while >> Mobile Access Gateways provide MLD proxy functions. In this >> scenario, Mobile Nodes remain agnostic of multicast mobility >> operations. >> >> >> >> >> -- >> >> Prof. Dr. Thomas C. Schmidt >> ° Hamburg University of Applied Sciences >> Berliner Tor 7 ° >> ° Dept. Informatik, Internet Technologies Group 20099 >> Hamburg, Germany ° >> ° http://www.haw-hamburg.de/inet Fon: >> +49-40-42875-8452 ° >> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: >> +49-40-42875-8409 ° >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From liuhui47967@huawei.com Tue Jun 16 00:58:58 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C883A6890 for ; Tue, 16 Jun 2009 00:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NA8Z0OCJljNa for ; Tue, 16 Jun 2009 00:58:57 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9A5F03A68EB for ; Tue, 16 Jun 2009 00:58:57 -0700 (PDT) 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 <0KLB00AK4MRKZ0@szxga04-in.huawei.com> for multimob@ietf.org; Tue, 16 Jun 2009 15:42:56 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLB00B0SMRKXM@szxga04-in.huawei.com> for multimob@ietf.org; Tue, 16 Jun 2009 15:42:56 +0800 (CST) Received: from l47967b ([10.111.12.139]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLB0040XMRK8B@szxml06-in.huawei.com> for multimob@ietf.org; Tue, 16 Jun 2009 15:42:56 +0800 (CST) Date: Tue, 16 Jun 2009 15:42:55 +0800 From: Liu Hui In-reply-to: <4A36BF2A.8000307@informatik.haw-hamburg.de> To: "'Thomas C. Schmidt'" Message-id: <004101c9ee56$104ba1c0$8b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: AcnuAYuG7fDGhsMTRnqeTBZYzQu2KAAUIFQQ Cc: multimob@ietf.org Subject: Re: [multimob] New Version Notification fordraft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 07:58:58 -0000 Hi Thomas and Matthias, If explicit tracking for each MN is not required, the solution should have no problem. This MAG proxy method has the advantage that least reports could be sent from MAG to LMA. Personally I think it is still possible for LMA to explicitly tracking each MAG, which may still be useful in practical application. Thus I suggest explicit tracking feature could be preserved between MAG and LMA, with original illustration revised. Best Regards, Liu Hui > > > AFAIK, the standard IGMP/MLD proxy (MAG in the draft) > usually sends summary report to its upstream equipment. Thus > the source address of the report should be set to the address > of MAG but not the address of MN. If this is the case, how > LMA tell which MN triggers the report ? Is it possible to > realize explicit tracking on LMA for each MN in this solution? > > As Matthias already wrote: you're right, we have been too > quick and assuming knowledge of the MN at the LMA is a lapse. > Thanks for the hint. > > So, explicit tracking is actually not an option - we will > remove this. > However, the base scheme is unaffected, as reports and querying work. From jari.arkko@piuha.net Tue Jun 16 04:57:32 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93833A6A55 for ; Tue, 16 Jun 2009 04:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XgaFaYWakxr for ; Tue, 16 Jun 2009 04:57:32 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 0FBE83A6A17 for ; Tue, 16 Jun 2009 04:57:32 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 185DE198714 for ; Tue, 16 Jun 2009 14:57:42 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 93A3A198660 for ; Tue, 16 Jun 2009 14:57:41 +0300 (EEST) Message-ID: <4A3788B4.6050803@piuha.net> Date: Tue, 16 Jun 2009 07:57:40 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [multimob] Multimob BOF X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 11:57:33 -0000 I have had trouble deciding what to do with this BOF request. There's clearly energy and people behind this. However, it has been unclear to me how how well the ideas match what real-life mobile networks and implementors need. In particular, when talking to Proxy MIP developers, there's a feeling that a document describing the use of multicast in PMIP would be useful. But at the same time they are very much against complex optimization proposals. There's also a question of whether the specifications, if any, should be developed in a free-standing WG or if they should simply be a part of the existing WGs such as NETLMM or NETEXT. In other words, there's a significant disagreement about the ambition level. In any case, I have decided to grant a BOF because I don't want to prevent the discussion from happening. I would like to request that the BOF be devoted to the high level questions, e.g., should we do nothing, develop an informational document explaining the use of multicast in PMIP, or develop an advanced optimization framework and significant protocol extensions. I think it can be taken as a starting point that we do not have enough documentation about the use of multicast with PMIP -- just grep for "multicast" in RFC 5213 :-) Jari From behcetsarikaya@yahoo.com Tue Jun 16 07:07:21 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7033A6BAA for ; Tue, 16 Jun 2009 07:07:21 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvjD2XsTWycw for ; Tue, 16 Jun 2009 07:07:20 -0700 (PDT) Received: from n10.bullet.re3.yahoo.com (n10.bullet.re3.yahoo.com [68.142.237.123]) by core3.amsl.com (Postfix) with SMTP id C146A3A6922 for ; Tue, 16 Jun 2009 07:07:19 -0700 (PDT) Received: from [68.142.237.90] by n10.bullet.re3.yahoo.com with NNFMP; 16 Jun 2009 14:02:27 -0000 Received: from [67.195.9.81] by t6.bullet.re3.yahoo.com with NNFMP; 16 Jun 2009 14:02:27 -0000 Received: from [67.195.9.99] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 16 Jun 2009 14:02:27 -0000 Received: from [127.0.0.1] by omp103.mail.gq1.yahoo.com with NNFMP; 16 Jun 2009 13:59:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 354812.72472.bm@omp103.mail.gq1.yahoo.com Received: (qmail 40476 invoked by uid 60001); 16 Jun 2009 14:02:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245160947; bh=83pcAfc91mgASMzofTqDcl4epVx6QdZvYN7PsH2kwfc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ublY50Pk+SqdekomFuokSsUKvc9KFHXq7bPAcSb2d8uQYbVHEVK27oEJBKolT7J5p/D0c/IyqFmy+iMzJlVWi1Oms0ff1jiLhFldAikvA+tpYuCjDcYpbnSPqIEX5f5QFyCFGwkUg5TihUMA+VdyCTk3sH38YAfyfQNpwpJ1arY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YH8nO1fdYRtkqPQtTL4ywh5gGWi3vDiNbDhUIP+5yYe1UL2puYW9ro6OC0wTKjI8apeclPyUTKPHu6tvZVU+ay58XAlymhvMVXXsoyLD1QQm0palabTBuzl68XIz+qqVlhg82nEV8Pnqv0D8cKxyCWbtVRFLBIuC9coHQcYE7D0=; Message-ID: <60889.38740.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: e8rqTO4VM1lDGdZTAjM5vKxKg7m_zgIaZBPfqcOOK650IOkDJC3W2H5RB_qOoylMgL_iZqBs8flfDYlsyyoutBetcSyMnp_Om_6jQ53HD_k3eAw1rzAvc9ZRDQRVrceY6g.zezD_ge7NxzwV.ycJHkt1ahi4yY0f3cQkE5f8tk0IyopehF9n.JfnxCsXzVY_y7TpuJM6bGsqa7kL1Kj8DC3J89vBt7aXrr8Jp1D8ofd0VfWunMQZfVyOzNjdGhdkMwRxoTD0wOGZOGo38ClL6C4SduTqLdY93IlWzJ9SgB_nLx0AE3F.sOrfJRx3lCaatnN17GgQGjngudtCcKUGkpo- Received: from [71.164.128.97] by web111416.mail.gq1.yahoo.com via HTTP; Tue, 16 Jun 2009 07:02:26 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 References: <4A3788B4.6050803@piuha.net> Date: Tue, 16 Jun 2009 07:02:26 -0700 (PDT) From: Behcet Sarikaya To: Jari Arkko , multimob@ietf.org In-Reply-To: <4A3788B4.6050803@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] Multimob BOF X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 14:07:21 -0000 Hi Jari,=0A=A0 Thanks for approving the BoF.=0AAs you know Multimob has two= sets of protocols to work on: Mobility protocols (currently PMIP) and grou= p management protocols.=0AI think that all the evaluation so far has been o= n PMIP side. =0AWe have many people in Multimob who are coming from the gro= up management protocol side and they believe some work in indeed needed.=0A= =0AIs your recommendation to not to concentrate on the group management asp= ect at the BoF?=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Original Message= ----=0AFrom: Jari Arkko =0ATo: multimob@ietf.org=0AS= ent: Tuesday, June 16, 2009 6:57:40 AM=0ASubject: [multimob] Multimob BOF= =0A=0AI have had trouble deciding what to do with this BOF request.=0A=0ATh= ere's clearly energy and people behind this. However, it has been unclear t= o me how how well the ideas match what real-life mobile networks and implem= entors need. In particular, when talking to Proxy MIP developers, there's a= feeling that a document describing the use of multicast in PMIP would be u= seful. But at the same time they are very much against complex optimization= proposals. There's also a question of whether the specifications, if any, = should be developed in a free-standing WG or if they should simply be a par= t of the existing WGs such as NETLMM or NETEXT. In other words, there's a s= ignificant disagreement about the ambition level.=0A=0AIn any case, I have = decided to grant a BOF because I don't want to prevent the discussion from = happening. I would like to request that the BOF be devoted to the high leve= l questions, e.g., should we do nothing, develop an informational document = explaining the use of multicast in PMIP, or develop an advanced optimizatio= n framework and significant protocol extensions. I think it can be taken as= a starting point that we do not have enough documentation about the use of= multicast with PMIP -- just grep for "multicast" in RFC 5213 :-)=0A=0AJari= =0A=0A_______________________________________________=0Amultimob mailing li= st=0Amultimob@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/multimob=0A= =0A=0A=0A From jari.arkko@piuha.net Tue Jun 16 07:07:28 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825383A6B5D for ; Tue, 16 Jun 2009 07:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGBEx4HuyJNb for ; Tue, 16 Jun 2009 07:07:27 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 39F7C3A68A0 for ; Tue, 16 Jun 2009 07:07:27 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 9D7161986EE; Tue, 16 Jun 2009 17:07:36 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 0AECC198665; Tue, 16 Jun 2009 17:07:35 +0300 (EEST) Message-ID: <4A37A727.6060304@piuha.net> Date: Tue, 16 Jun 2009 10:07:35 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Behcet Sarikaya References: <4A3788B4.6050803@piuha.net> <60889.38740.qm@web111416.mail.gq1.yahoo.com> In-Reply-To: <60889.38740.qm@web111416.mail.gq1.yahoo.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: multimob@ietf.org Subject: Re: [multimob] Multimob BOF X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 14:07:28 -0000 Behcet Sarikaya wrote: > Hi Jari, > Thanks for approving the BoF. > As you know Multimob has two sets of protocols to work on: Mobility protocols (currently PMIP) and group management protocols. > I think that all the evaluation so far has been on PMIP side. > We have many people in Multimob who are coming from the group management protocol side and they believe some work in indeed needed. > > Is your recommendation to not to concentrate on the group management aspect at the BoF? > No -- I only had time to dig into the PMIP side of the proposal. I do not have a specific recommendation on the group management side. Jari From gorry@erg.abdn.ac.uk Tue Jun 16 09:01:09 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F2BC3A6C07 for ; Tue, 16 Jun 2009 09:01:09 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtpHNxqezvBp for ; Tue, 16 Jun 2009 09:01:08 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 04AF93A6BC3 for ; Tue, 16 Jun 2009 09:01:06 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n5GG0i6b017129; Tue, 16 Jun 2009 17:00:45 +0100 (BST) Received: from 131.176.173.94 (SquirrelMail authenticated user gorry); by www.erg.abdn.ac.uk with HTTP; Tue, 16 Jun 2009 17:00:45 +0100 (BST) Message-ID: <49616.131.176.173.94.1245168045.squirrel@131.176.173.94> In-Reply-To: <4A36BF2A.8000307@informatik.haw-hamburg.de> References: <002d01c9ed63$562b6700$8b0c6f0a@china.huawei.com> <4A36BF2A.8000307@informatik.haw-hamburg.de> Date: Tue, 16 Jun 2009 17:00:45 +0100 (BST) From: gorry@erg.abdn.ac.uk To: "Thomas C. Schmidt" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org Subject: Re: [multimob] New Version Notification fordraft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 16:01:09 -0000 I'm trying to understand the thread: - A device can snoop or proxy the membership control traffic. The proxy function generates queries from within the device. - A proxy can proxy the reporting, which means the proxy sends a summary report upstream on behalf of all active downstream receivers when it is queried, and hence uses one of its own interface addresses as a source. - To me explicit tracking is a different issue - that is when the proxy monitors responses from each receiver (it may also send membership queries to receivers). The aim is to know which receivers (interfaces) need to receive each group. This a mode that is possible in IGMPv3 and MLDv2 to speed-up the leave process. Are we talking about the same thing here? Gorry > Hi Liu, > > Liu Hui wrote: > >> AFAIK, the standard IGMP/MLD proxy (MAG in the draft) usually sends >> summary report to its upstream equipment. Thus the source address of >> the report should be set to the address of MAG but not the address of >> MN. If this is the case, how LMA tell which MN triggers the report ? Is >> it possible to realize explicit tracking on LMA for each MN in this >> solution? > > As Matthias already wrote: you're right, we have been too quick and > assuming knowledge of the MN at the LMA is a lapse. Thanks for the hint. > > So, explicit tracking is actually not an option - we will remove this. > However, the base scheme is unaffected, as reports and querying work. > >> In section 3, multicast data will "flow from the LMA to the MN on an >> LMA-specific shared tree." It seems not very clear what this shared >> tree is. Is it the tunnel from LMA to MAG? Because multicast routing >> protocol are not involved here, it it better not to use shared tree >> here. > > Well, that's a matter of taste - we can remove shared tree, if you > think. There is tree built from the LMA to (one or several) MAGs and > further to (one or several) MNs, which is shared among sources. So it > actually is a shared tree, but not erected by PIM-SM, that's right. We > should probably state this more explicit. > > Thanks for your valuable comments! > > Thomas > >> >> >> >>> -----Original Message----- >>> From: multimob-bounces@ietf.org >>> [mailto:multimob-bounces@ietf.org] On Behalf Of Thomas C. Schmidt >>> Sent: Sunday, June 14, 2009 5:27 AM >>> To: multimob@ietf.org >>> Subject: [multimob] New Version Notification >>> fordraft-schmidt-multimob-pmipv6-mcast-deployment-00 >>> >>> Dear all, >>> >>> multicast support for PMIPv6 domains has been one of the >>> most debated >>> issues for Multimob, and at the same time some divergent >>> understanding >>> of the topic arose. >>> >>> As promised earlier, we have now prepared a document defining >>> multicast listener support in PMIPv6 domains solely on the basis of >>> standardized IETF protocols (see below): >>> http://www.ietf.org/internet-drafts/draft-schmidt-multimob-pmi >>> pv6-mcast-deployment-00.txt >>> >>> >>> It assigns the role of MLD proxies to MAGs and standard MLD queriers >>> to LMAs, and we believe this is the minimal solution solely based on >>> standard protocol behavior. >>> >>> At the price of "full multicast" functions at MAG and LMA, this >>> approach provides some (but not all possible) traffic aggregations. >>> >>> In parallel, I should point on an alternative approach >>> published earlier: >>> http://tools.ietf.org/html/draft-gundavelli-multimob-pmip6basi >>> cmcast-solution >>> >>> This approach uses minimal, but non-standard MLD forwarding >>> at the MAG and >>> individual, unidirectional data tunneling from LMA to MN. >>> MLD support at the >>> MAG is thus more lightweight on the price of a complete >>> loss of traffic >>> aggregation. >>> >>> Both drafts should serve as a good starting point for >>> defining a "minimal >>> multicast standard" in PMIPv6 - and for discussions prior >>> to the BoF in Stockholm. >>> >>> Looking forward to your comments! >>> >>> Thomas >>> >>> ---------------------------- snip ---------------------------------- >>> >>> A new version of I-D, >>> draft-schmidt-multimob-pmipv6-mcast-deployment-00.txt has >>> been successfuly submitted by Thomas Schmidt and posted to >>> the IETF repository. >>> >>> Filename: draft-schmidt-multimob-pmipv6-mcast-deployment >>> Revision: 00 >>> Title: A Minimal Deployment Option for >>> Multicast Listeners in PMIPv6 >>> Domains >>> Creation_date: 2009-06-13 >>> WG ID: Independent Submission >>> Number_of_pages: 10 >>> >>> Abstract: >>> This document describes deployment options for activating >>> multicast listener functions in Proxy Mobile IPv6 domains >>> without modifying mobility and multicast protocol standards. >>> Similar to Home Agents in Mobile IPv6, PMIPv6 Local Mobility >>> Anchors serve as multicast subscription anchor points, while >>> Mobile Access Gateways provide MLD proxy functions. In this >>> scenario, Mobile Nodes remain agnostic of multicast mobility >>> operations. >>> >>> >>> >>> >>> -- >>> >>> Prof. Dr. Thomas C. Schmidt >>> ° Hamburg University of Applied Sciences >>> Berliner Tor 7 ° >>> ° Dept. Informatik, Internet Technologies Group 20099 >>> Hamburg, Germany ° >>> ° http://www.haw-hamburg.de/inet Fon: >>> +49-40-42875-8452 ° >>> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: >>> +49-40-42875-8409 ° >>> _______________________________________________ >>> multimob mailing list >>> multimob@ietf.org >>> https://www.ietf.org/mailman/listinfo/multimob >>> >> > > -- > > Prof. Dr. Thomas C. Schmidt > ° Hamburg University of Applied Sciences Berliner Tor 7 > ° > ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany > ° > ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 > ° > ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 > ° > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From waehlisch@ieee.org Tue Jun 16 14:59:45 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B7C028C123 for ; Tue, 16 Jun 2009 14:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+uWMHJK4v+0 for ; Tue, 16 Jun 2009 14:59:43 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 70A393A6A6F for ; Tue, 16 Jun 2009 14:59:43 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.22.27.137] (helo=mw-thinkpad) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MGgh7-0007zp-IU; Tue, 16 Jun 2009 23:59:53 +0200 Date: Tue, 16 Jun 2009 23:59:53 +0200 From: Matthias Waehlisch To: gorry@erg.abdn.ac.uk In-Reply-To: <49616.131.176.173.94.1245168045.squirrel@131.176.173.94> Message-ID: References: <002d01c9ed63$562b6700$8b0c6f0a@china.huawei.com> <4A36BF2A.8000307@informatik.haw-hamburg.de> <49616.131.176.173.94.1245168045.squirrel@131.176.173.94> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="209690734-19384-1245189303=:3152" Content-ID: Cc: multimob@ietf.org, "Thomas C. Schmidt" Subject: Re: [multimob] New Version Notification fordraft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 21:59:45 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --209690734-19384-1245189303=:3152 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hi Gorry, On Tue, 16 Jun 2009, gorry@erg.abdn.ac.uk wrote: > I'm trying to understand the thread: >=20 > - A device can snoop or proxy the membership control traffic. The proxy= =20 > function generates queries from within the device. >=20 agree. > - A proxy can proxy the reporting, which means the proxy sends a=20 > summary report upstream on behalf of all active downstream receivers=20 > when it is queried, and hence uses one of its own interface addresses as= =20 > a source. >=20 Agree, as well. > - To me explicit tracking is a different issue - that is when the proxy= =20 > monitors responses from each receiver (it may also send membership=20 > queries to receivers). The aim is to know which receivers (interfaces)=20 > need to receive each group. This a mode that is possible in IGMPv3 and= =20 > MLDv2 to speed-up the leave process. >=20 > Are we talking about the same thing here? >=20 Yes. The confusion arose as we originally thought that LMA receives=20 MN-specific membership states ... Anyhow, the explicit tracking is not=20 specifically helpful to PMIP-multicast case. Sorry for the confusion. Cheers matthias=20 --=20 Matthias Waehlisch =2E FU Berlin, Inst. fuer Informatik, AG CST =2E Takustr. 9, D-14195 Berlin, Germany =2E. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net > > Hi Liu, > > > > Liu Hui wrote: > > > >> AFAIK, the standard IGMP/MLD proxy (MAG in the draft) usually sends > >> summary report to its upstream equipment. Thus the source address of > >> the report should be set to the address of MAG but not the address of > >> MN. If this is the case, how LMA tell which MN triggers the report ? = Is > >> it possible to realize explicit tracking on LMA for each MN in this > >> solution? > > > > As Matthias already wrote: you're right, we have been too quick and > > assuming knowledge of the MN at the LMA is a lapse. Thanks for the hint= =2E > > > > So, explicit tracking is actually not an option - we will remove this. > > However, the base scheme is unaffected, as reports and querying work. > > > >> In section 3, multicast data will "flow from the LMA to the MN on an > >> LMA-specific shared tree." It seems not very clear what this shared > >> tree is. Is it the tunnel from LMA to MAG? Because multicast routing > >> protocol are not involved here, it it better not to use shared tree > >> here. > > > > Well, that's a matter of taste - we can remove shared tree, if you > > think. There is tree built from the LMA to (one or several) MAGs and > > further to (one or several) MNs, which is shared among sources. So it > > actually is a shared tree, but not erected by PIM-SM, that's right. We > > should probably state this more explicit. > > > > Thanks for your valuable comments! > > > > Thomas > > > >> > >> > >> > >>> -----Original Message----- > >>> From: multimob-bounces@ietf.org > >>> [mailto:multimob-bounces@ietf.org] On Behalf Of Thomas C. Schmidt > >>> Sent: Sunday, June 14, 2009 5:27 AM > >>> To: multimob@ietf.org > >>> Subject: [multimob] New Version Notification > >>> fordraft-schmidt-multimob-pmipv6-mcast-deployment-00 > >>> > >>> Dear all, > >>> > >>> multicast support for PMIPv6 domains has been one of the > >>> most debated > >>> issues for Multimob, and at the same time some divergent > >>> understanding > >>> of the topic arose. > >>> > >>> As promised earlier, we have now prepared a document defining > >>> multicast listener support in PMIPv6 domains solely on the basis of > >>> standardized IETF protocols (see below): > >>> http://www.ietf.org/internet-drafts/draft-schmidt-multimob-pmi > >>> pv6-mcast-deployment-00.txt > >>> > >>> > >>> It assigns the role of MLD proxies to MAGs and standard MLD querier= s > >>> to LMAs, and we believe this is the minimal solution solely based o= n > >>> standard protocol behavior. > >>> > >>> At the price of "full multicast" functions at MAG and LMA, this > >>> approach provides some (but not all possible) traffic aggregations. > >>> > >>> In parallel, I should point on an alternative approach > >>> published earlier: > >>> http://tools.ietf.org/html/draft-gundavelli-multimob-pmip6basi > >>> cmcast-solution > >>> > >>> This approach uses minimal, but non-standard MLD forwarding > >>> at the MAG and > >>> individual, unidirectional data tunneling from LMA to MN. > >>> MLD support at the > >>> MAG is thus more lightweight on the price of a complete > >>> loss of traffic > >>> aggregation. > >>> > >>> Both drafts should serve as a good starting point for > >>> defining a "minimal > >>> multicast standard" in PMIPv6 - and for discussions prior > >>> to the BoF in Stockholm. > >>> > >>> Looking forward to your comments! > >>> > >>> Thomas > >>> > >>> ---------------------------- snip ---------------------------------- > >>> > >>> A new version of I-D, > >>> draft-schmidt-multimob-pmipv6-mcast-deployment-00.txt has > >>> been successfuly submitted by Thomas Schmidt and posted to > >>> the IETF repository. > >>> > >>> Filename:=09 draft-schmidt-multimob-pmipv6-mcast-deployment > >>> Revision:=09 00 > >>> Title:=09=09 A Minimal Deployment Option for > >>> Multicast Listeners in PMIPv6 > >>> Domains > >>> Creation_date:=09 2009-06-13 > >>> WG ID:=09=09 Independent Submission > >>> Number_of_pages: 10 > >>> > >>> Abstract: > >>> This document describes deployment options for activating > >>> multicast listener functions in Proxy Mobile IPv6 domains > >>> without modifying mobility and multicast protocol standards. > >>> Similar to Home Agents in Mobile IPv6, PMIPv6 Local Mobility > >>> Anchors serve as multicast subscription anchor points, while > >>> Mobile Access Gateways provide MLD proxy functions. In this > >>> scenario, Mobile Nodes remain agnostic of multicast mobility > >>> operations. > >>> > >>> > >>> > >>> > >>> -- > >>> > >>> Prof. Dr. Thomas C. Schmidt > >>> =C2=B0 Hamburg University of Applied Sciences > >>> Berliner Tor 7 =C2=B0 > >>> =C2=B0 Dept. Informatik, Internet Technologies Group 20099 > >>> Hamburg, Germany =C2=B0 > >>> =C2=B0 http://www.haw-hamburg.de/inet Fon: > >>> +49-40-42875-8452 =C2=B0 > >>> =C2=B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: > >>> +49-40-42875-8409 =C2=B0 > >>> _______________________________________________ > >>> multimob mailing list > >>> multimob@ietf.org > >>> https://www.ietf.org/mailman/listinfo/multimob > >>> > >> > > > > -- > > > > Prof. Dr. Thomas C. Schmidt > > =C2=B0 Hamburg University of Applied Sciences Berline= r Tor 7 > > =C2=B0 > > =C2=B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany > > =C2=B0 > > =C2=B0 http://www.haw-hamburg.de/inet Fon: +49-40-428= 75-8452 > > =C2=B0 > > =C2=B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-428= 75-8409 > > =C2=B0 > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > > >=20 >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob >=20 --209690734-19384-1245189303=:3152-- From liuhui47967@huawei.com Tue Jun 16 20:06:23 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427F33A6D6C for ; Tue, 16 Jun 2009 20:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqRRLM1NWEyk for ; Tue, 16 Jun 2009 20:06:22 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6506D3A6778 for ; Tue, 16 Jun 2009 20:06:22 -0700 (PDT) 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 <0KLD00I2Y4MNRA@szxga04-in.huawei.com> for multimob@ietf.org; Wed, 17 Jun 2009 11:06:23 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLD00BXT4MN3D@szxga04-in.huawei.com> for multimob@ietf.org; Wed, 17 Jun 2009 11:06:23 +0800 (CST) Received: from l47967b ([10.111.12.139]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLD003GD4MM49@szxml04-in.huawei.com> for multimob@ietf.org; Wed, 17 Jun 2009 11:06:23 +0800 (CST) Date: Wed, 17 Jun 2009 11:06:22 +0800 From: Liu Hui In-reply-to: <4A37A727.6060304@piuha.net> To: 'Jari Arkko' , 'Behcet Sarikaya' Message-id: <001301c9eef8$98343c30$8b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-index: Acnui9SDgAvDO4VWQEK2Z9ZbuF7LWAAbJBiA Cc: multimob@ietf.org Subject: Re: [multimob] Multimob BOF X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 03:06:23 -0000 Hi Jari, I understand your concern about practicability of the output of multimob. This is also the concern of mine and also many other people who are interested in this work. The group may absorb vendors and operators for they usually have practical eyes. Fortunately, we have some of them already involved and interested in the work. Personally I think the aim of the group should not be merely the extension of the PMIP (or other MIP) protocol to support multicast, but should be extending the multicast enabled network to support mobile users. For the former we only enhance one or two protocols, while for the latter we enhance the capabilty of the network and versatile the service delivery. Even though the two protocol suites, multicast and mobile IP, still do not see their success, the intergration of them may generate more than we can expect. I agree with you that intitial informational architecture or other related document should be prepared. But I disgree with you that they should be limited to PMIP. Even though it turns out that one MIP protocol eventually wipe out all other ones, this MIP protocol should be only one part of mobile multicast architecture. The above is my personal thinking and suggestions. Please give a consideration on it. Best Regards, Liu Hui > -----Original Message----- > From: multimob-bounces@ietf.org > [mailto:multimob-bounces@ietf.org] On Behalf Of Jari Arkko > Sent: Tuesday, June 16, 2009 10:08 PM > To: Behcet Sarikaya > Cc: multimob@ietf.org > Subject: Re: [multimob] Multimob BOF > > Behcet Sarikaya wrote: > > Hi Jari, > > Thanks for approving the BoF. > > As you know Multimob has two sets of protocols to work on: > Mobility protocols (currently PMIP) and group management protocols. > > I think that all the evaluation so far has been on PMIP side. > > We have many people in Multimob who are coming from the > group management protocol side and they believe some work in > indeed needed. > > > > Is your recommendation to not to concentrate on the group > management aspect at the BoF? > > > > No -- I only had time to dig into the PMIP side of the > proposal. I do not have a specific recommendation on the > group management side. > > Jari > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From jouni.nospam@gmail.com Thu Jun 18 09:15:44 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011F028C325 for ; Thu, 18 Jun 2009 09:15:44 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZNQwIWJF0Q5 for ; Thu, 18 Jun 2009 09:15:42 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 4118628C354 for ; Thu, 18 Jun 2009 09:15:42 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so1043685fga.18 for ; Thu, 18 Jun 2009 09:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=NmAkndtM8eywbAMiqLRobaGVzSYjuCnGa0rsVdPn9dM=; b=mHQN9jUcEYmGORi8cxDZD1JDI5cQ0kOsYprnVIqHVf31q51Upi3CS6EUrv8p+rzo5z h5fpSuHHu7NPBtMggdTjjIX2Hh94PhxnXRAZKSXWt7rLZA8Bmi/KiLpJchEhecXGEn/O +rb+y9hXLhWkS6kHp160HL1nbgHpdsBvsUJUI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=lErYDI2ltSLzG9rdzogHefjjbYiekPp0mhD0FNWkCmQClLotIPKtu3EZz4RzDD+igH AbQycs0vw0KOsJ97NmSafQ9WyxatbSh2HLs7J7LPsG35XSfpCdvL4HNcIgzjMqRbFDDZ 1IvgqH2uR3Gnpd9/drieY1p9Vc4Dj+Z3AoWRI= Received: by 10.86.65.9 with SMTP id n9mr2162045fga.43.1245341751910; Thu, 18 Jun 2009 09:15:51 -0700 (PDT) Received: from a83-245-212-65.elisa-laajakaista.fi (a83-245-212-65.elisa-laajakaista.fi [83.245.212.65]) by mx.google.com with ESMTPS id d6sm7200015fga.17.2009.06.18.09.15.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Jun 2009 09:15:51 -0700 (PDT) Message-Id: <8917F82B-F8AF-4A05-99C1-C0641519FBDE@gmail.com> From: jouni korhonen To: Thomas C. Schmidt In-Reply-To: <4A341991.205@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 18 Jun 2009 19:15:49 +0300 References: <4A341991.205@informatik.haw-hamburg.de> X-Mailer: Apple Mail (2.935.3) Cc: multimob@ietf.org Subject: Re: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 16:15:44 -0000 Hi Thomas, One comment regarding the *-mcast-deployment-00 I-D. It would benefit =20= greatly readability of this I-D and help to understand the exact MLD =20 proxy behavior if MLD report/query/etc messages' source and =20 destination addresses were listed in each case and both sides of the =20 MAG. Something like what RFC2710 did. Regarding the *-pmip6basicmcast-solution-01 I-D, I find it a bit odd =20 that it has new requirements to MNs apart from supporting certain MLD =20= version. Also I do not understand what the first sentence in Section =20 5. is about. Where is that requirement said? Finally, what is the point of describing two different MLD handling =20 behaviors for a MAG in these two I-Ds, when both obviously require =20 changes to the MAG. Or did I miss something? ;) Cheers, Jouni On Jun 14, 2009, at 12:26 AM, Thomas C. Schmidt wrote: > Dear all, > > multicast support for PMIPv6 domains has been one of the most debated > issues for Multimob, and at the same time some divergent understanding > of the topic arose. > > As promised earlier, we have now prepared a document defining > multicast listener support in PMIPv6 domains solely on the basis of > standardized IETF protocols (see below): = http://www.ietf.org/internet-drafts/draft-schmidt-multimob-pmipv6-mcast-de= ployment-00.txt > > It assigns the role of MLD proxies to MAGs and standard MLD queriers > to LMAs, and we believe this is the minimal solution solely based on > standard protocol behavior. > > At the price of "full multicast" functions at MAG and LMA, this > approach provides some (but not all possible) traffic aggregations. > > In parallel, I should point on an alternative approach published =20 > earlier: > = http://tools.ietf.org/html/draft-gundavelli-multimob-pmip6basicmcast-solut= ion > > This approach uses minimal, but non-standard MLD forwarding at the =20 > MAG and > individual, unidirectional data tunneling from LMA to MN. MLD =20 > support at the > MAG is thus more lightweight on the price of a complete loss of =20 > traffic > aggregation. > > Both drafts should serve as a good starting point for defining a =20 > "minimal > multicast standard" in PMIPv6 - and for discussions prior to the BoF =20= > in Stockholm. > > Looking forward to your comments! > > Thomas > > ---------------------------- snip ---------------------------------- > > A new version of I-D, draft-schmidt-multimob-pmipv6-mcast-=20 > deployment-00.txt has been successfuly submitted by Thomas Schmidt =20 > and posted to the IETF repository. > > Filename: draft-schmidt-multimob-pmipv6-mcast-deployment > Revision: 00 > Title: A Minimal Deployment Option for Multicast = Listeners in =20 > PMIPv6 Domains > Creation_date: 2009-06-13 > WG ID: Independent Submission > Number_of_pages: 10 > > Abstract: > This document describes deployment options for activating multicast > listener functions in Proxy Mobile IPv6 domains without modifying > mobility and multicast protocol standards. Similar to Home Agents in > Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast > subscription anchor points, while Mobile Access Gateways provide MLD > proxy functions. In this scenario, Mobile Nodes remain agnostic of > multicast mobility operations. > > > > --=20 > > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner =20= > Tor 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, =20= > Germany =B0 > =B0 http://www.haw-hamburg.de/inet Fon: =20 > +49-40-42875-8452 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: =20 > +49-40-42875-8409 =B0 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Thu Jun 18 09:34:29 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF943A685E for ; Thu, 18 Jun 2009 09:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoxzCC2eea7u for ; Thu, 18 Jun 2009 09:34:28 -0700 (PDT) Received: from n7.bullet.re3.yahoo.com (n7.bullet.re3.yahoo.com [68.142.237.92]) by core3.amsl.com (Postfix) with SMTP id 2508C3A6BE3 for ; Thu, 18 Jun 2009 09:33:48 -0700 (PDT) Received: from [68.142.237.90] by n7.bullet.re3.yahoo.com with NNFMP; 18 Jun 2009 16:33:56 -0000 Received: from [67.195.9.82] by t6.bullet.re3.yahoo.com with NNFMP; 18 Jun 2009 16:33:56 -0000 Received: from [67.195.9.109] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 18 Jun 2009 16:33:56 -0000 Received: from [127.0.0.1] by omp113.mail.gq1.yahoo.com with NNFMP; 18 Jun 2009 16:33:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 874276.39533.bm@omp113.mail.gq1.yahoo.com Received: (qmail 91700 invoked by uid 60001); 18 Jun 2009 16:33:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245342835; bh=ZTefvzl4jUqTGoyGbX2/7zHr6z/SnltrnqtUrfg75fs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ipk/1FwyJl+e1T5g1G8v2nUhdsocDONKxlKZVP88dsWjbC4vt3/mg273PWf4zrgJ9A7Dta7Hp8exIOCyCd9CNkf5f99tYu5MIHpDVwmX/mzU+1dMkg/ts2nmOrniefclA+tQopfjkZwsfYOob0CNHMa/SvQ13Jes7iF4jVSVteE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rSEGXrC2P0enXmczG0Mp6rvfNrPMaj1lSIxxtDTxP+UDE0XMM7Ls23O1k8rvRpFE46wOzPzbz2ldt2q/3kKyShjemQ0PTIg6kCMI9uxAR7PB9lUvvbTRiVudMk0BHp/iou6XZ93iCTEI9Q74Eav01KBZAww3AyyHFew19/aOPVE=; Message-ID: <925189.90854.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: TaW9FZQVM1mQ9BzZ_H3Mf6lEyGZyhEjQEPVoH5aLto.AJDCoIiD82vJFIBc.TaywBSCtCHC6BihTme.bong.1M4nlV5iqlDkqxh2pcbKQne428HdnipkeuNxGD1ONMcbFiL3_PfZtMPDBfXtMz1e4kWsh4p_g.yZUSY5Ir90SVRySlS9Mor_jJ5GXggjvuQj9OsVLUkHQny0iMtsObHPp1dnUFL5nBQS12J4Yx8wDo4kWg4hHg65huEQbf3IzQwfz5MTwIjt9Cy37xDEqzJwQ2WFI7K2B3ZWCNdfxk6actWlb7ASgQg8Ier5oLkHydNlbp5UdU2rAlMtWos7ziIAKBc- Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Thu, 18 Jun 2009 09:33:55 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 References: <4A341991.205@informatik.haw-hamburg.de> <8917F82B-F8AF-4A05-99C1-C0641519FBDE@gmail.com> Date: Thu, 18 Jun 2009 09:33:55 -0700 (PDT) From: Behcet Sarikaya To: jouni korhonen , "Thomas C. Schmidt" In-Reply-To: <8917F82B-F8AF-4A05-99C1-C0641519FBDE@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 16:34:29 -0000 Hi Jouni,=0A=A0 Thanks for your comments.=0ALet me answer the part on *-pmi= p6basicmcast-solution below.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Ori= ginal Message ----=0AFrom: jouni korhonen =0ATo: Th= omas C. Schmidt =0ACc: multimob@ietf.org= =0ASent: Thursday, June 18, 2009 11:15:49 AM=0ASubject: Re: [multimob] New = Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00= =0A=0AHi Thomas,=0A=0AOne comment regarding the *-mcast-deployment-00 I-D. = It would benefit greatly readability of this I-D and help to understand the= exact MLD proxy behavior if MLD report/query/etc messages' source and dest= ination addresses were listed in each case and both sides of the MAG. Somet= hing like what RFC2710 did.=0A=0ARegarding the *-pmip6basicmcast-solution-0= 1 I-D, I find it a bit odd that it has new requirements to MNs apart from s= upporting certain MLD version. Also I do not understand what the first sent= ence in Section 5. is about. Where is that requirement said?=0A=0A[behcet] = If you look at Section 6.10.5.=A0 Forwarding Rules in RFC 5213,=0Ait says: = =0A=0AHowever, the packets that are sent=0A=A0=A0=A0=A0=A0 with the link-lo= cal source address MUST NOT be forwarded.=0A=0AAs it is stated in *-pmip6ba= sicmcast-solution-01 I-D this was probably to support ND.=0A=0A=0A=0AFinall= y, what is the point of describing two different MLD handling behaviors for= a MAG in these two I-Ds, when both obviously require changes to the MAG. O= r did I miss something? ;)=0A=0A=0A[behcet] This is a deeper question.=0ATh= e reason for *-pmip6basicmcast-solution-01 I-D is to come up with a solutio= n which is LMA-based and which is inline with MIPv6/MIPv4 base spec multica= st support. We did not assume any multicast proxy support at the MAG. Very = minimal forwarding requirement on the MAG=0ASo basically the idea was not t= o get into any optimization ideas.=0A=0AI think that *-mcast-deployment-00= =A0 did not have the same requirements.=0A=0A=0ACheers,=0A=A0=A0=A0 Jouni= =0A=0Asnipped the rest=0A=0A=0A From schmidt@informatik.haw-hamburg.de Thu Jun 18 09:37:54 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF25F28C164 for ; Thu, 18 Jun 2009 09:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2cM3MVlHiq0 for ; Thu, 18 Jun 2009 09:37:53 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 9001B3A68D3 for ; Thu, 18 Jun 2009 09:37:52 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.22.26.203] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MHKcl-000Mel-FP; Thu, 18 Jun 2009 18:38:03 +0200 Message-ID: <4A3A6D6B.9060205@informatik.haw-hamburg.de> Date: Thu, 18 Jun 2009 18:38:03 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: jouni korhonen References: <4A341991.205@informatik.haw-hamburg.de> <8917F82B-F8AF-4A05-99C1-C0641519FBDE@gmail.com> In-Reply-To: <8917F82B-F8AF-4A05-99C1-C0641519FBDE@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 16:37:54 -0000 Hi Jouni, thanks for your comments! jouni korhonen wrote: > One comment regarding the *-mcast-deployment-00 I-D. It would benefit > greatly readability of this I-D and help to understand the exact MLD > proxy behavior if MLD report/query/etc messages' source and destination > addresses were listed in each case and both sides of the MAG. Something > like what RFC2710 did. > O.k., good suggestion: we will add this in the next revision which is about to come soon. > Regarding the *-pmip6basicmcast-solution-01 I-D, I find it a bit odd > that it has new requirements to MNs apart from supporting certain MLD > version. Also I do not understand what the first sentence in Section 5. > is about. Where is that requirement said? > What requirements do you refer to - apart from MLDv2? Actually, there should not be any. Regarding MLDv2: there is no general consensus on putting this as a requirement ... I don't believe there is an issue in using MLDv1 here, as well. About Sect 5, first sentence: I guess, this is just "catch up" on PMIPv6, recalling the context. I suppose it is not meant as adding a requirement ... > Finally, what is the point of describing two different MLD handling > behaviors for a MAG in these two I-Ds, when both obviously require > changes to the MAG. Or did I miss something? ;) > Two different approaches to the problem have been around - in preparing two documents we hope to support the discussion on the right way to go. However, the *-mcast-deployment-00 I-D should not require changes to the MAG apart from activating another protocol standard (MLD Proxy). That's at least the objective of it. Regards, Thomas > On Jun 14, 2009, at 12:26 AM, Thomas C. Schmidt wrote: > >> Dear all, >> >> multicast support for PMIPv6 domains has been one of the most debated >> issues for Multimob, and at the same time some divergent understanding >> of the topic arose. >> >> As promised earlier, we have now prepared a document defining >> multicast listener support in PMIPv6 domains solely on the basis of >> standardized IETF protocols (see below): >> http://www.ietf.org/internet-drafts/draft-schmidt-multimob-pmipv6-mcast-deployment-00.txt >> >> >> It assigns the role of MLD proxies to MAGs and standard MLD queriers >> to LMAs, and we believe this is the minimal solution solely based on >> standard protocol behavior. >> >> At the price of "full multicast" functions at MAG and LMA, this >> approach provides some (but not all possible) traffic aggregations. >> >> In parallel, I should point on an alternative approach published earlier: >> http://tools.ietf.org/html/draft-gundavelli-multimob-pmip6basicmcast-solution >> >> >> This approach uses minimal, but non-standard MLD forwarding at the MAG >> and >> individual, unidirectional data tunneling from LMA to MN. MLD support >> at the >> MAG is thus more lightweight on the price of a complete loss of traffic >> aggregation. >> >> Both drafts should serve as a good starting point for defining a "minimal >> multicast standard" in PMIPv6 - and for discussions prior to the BoF >> in Stockholm. >> >> Looking forward to your comments! >> >> Thomas >> >> ---------------------------- snip ---------------------------------- >> >> A new version of I-D, >> draft-schmidt-multimob-pmipv6-mcast-deployment-00.txt has been >> successfuly submitted by Thomas Schmidt and posted to the IETF >> repository. >> >> Filename: draft-schmidt-multimob-pmipv6-mcast-deployment >> Revision: 00 >> Title: A Minimal Deployment Option for Multicast Listeners in >> PMIPv6 Domains >> Creation_date: 2009-06-13 >> WG ID: Independent Submission >> Number_of_pages: 10 >> >> Abstract: >> This document describes deployment options for activating multicast >> listener functions in Proxy Mobile IPv6 domains without modifying >> mobility and multicast protocol standards. Similar to Home Agents in >> Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast >> subscription anchor points, while Mobile Access Gateways provide MLD >> proxy functions. In this scenario, Mobile Nodes remain agnostic of >> multicast mobility operations. >> >> >> >> -- >> >> Prof. Dr. Thomas C. Schmidt >> ° Hamburg University of Applied Sciences Berliner >> Tor 7 ° >> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, >> Germany ° >> ° http://www.haw-hamburg.de/inet Fon: >> +49-40-42875-8452 ° >> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: >> +49-40-42875-8409 ° >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From jouni.nospam@gmail.com Thu Jun 18 13:33:16 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5D723A6A50 for ; Thu, 18 Jun 2009 13:33:16 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lB4YLoZGKmS3 for ; Thu, 18 Jun 2009 13:33:16 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 9A7683A6923 for ; Thu, 18 Jun 2009 13:33:15 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so1093035fga.18 for ; Thu, 18 Jun 2009 13:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=79WPo+rhtj4QLHDUc/MInMxtOhrTwBByn7kVjW2tQKQ=; b=GCGm18DkFvpEOHarZvXIfzV9YX+4Q2SRWxticCuklqxMC3P6cAfwB2p8jVR1FjE2OJ DCtqPcDYUQQMx03ZLKK7oluz5FmZqBaNnxFeDIcNXDtiSpsgCtF3tgCFjYgAVmgbde3b /gHJFufeak4GJCgTvCFNvbJdcvtxNU1P+MknE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=CAmF1eZluAmZReAc1jA4tb5rYLLXW9glSXfqh7ALzLcxPMgziV/lqsxAs4aqmzjrue EsNHZlASgrbDcZqR4b8zlBkpQkIGuwUYTv9ZEX9t38a7MkIAs/tTtwAqSd+HCC0C4uKN nUiHDr5xNF+F99WN1G9HvJw8wCO1YWQmRuPh8= Received: by 10.86.59.2 with SMTP id h2mr2442347fga.30.1245357194899; Thu, 18 Jun 2009 13:33:14 -0700 (PDT) Received: from a83-245-212-65.elisa-laajakaista.fi (a83-245-212-65.elisa-laajakaista.fi [83.245.212.65]) by mx.google.com with ESMTPS id 12sm8138465fgg.10.2009.06.18.13.33.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Jun 2009 13:33:14 -0700 (PDT) Message-Id: <0D5E6D39-AF10-483E-8F81-285D7CC968A6@gmail.com> From: jouni korhonen To: Behcet Sarikaya In-Reply-To: <925189.90854.qm@web111409.mail.gq1.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 18 Jun 2009 23:33:13 +0300 References: <4A341991.205@informatik.haw-hamburg.de> <8917F82B-F8AF-4A05-99C1-C0641519FBDE@gmail.com> <925189.90854.qm@web111409.mail.gq1.yahoo.com> X-Mailer: Apple Mail (2.935.3) Cc: multimob@ietf.org, "Thomas C. Schmidt" Subject: Re: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 20:33:17 -0000 Hi Bechet, On Jun 18, 2009, at 7:33 PM, Behcet Sarikaya wrote: > > Hi Jouni, > Thanks for your comments. > Let me answer the part on *-pmip6basicmcast-solution below. > > Regards, > > Behcet > > > > ----- Original Message ---- > From: jouni korhonen > To: Thomas C. Schmidt > Cc: multimob@ietf.org > Sent: Thursday, June 18, 2009 11:15:49 AM > Subject: Re: [multimob] New Version Notification for draft-schmidt- > multimob-pmipv6-mcast-deployment-00 > > Hi Thomas, > > One comment regarding the *-mcast-deployment-00 I-D. It would > benefit greatly readability of this I-D and help to understand the > exact MLD proxy behavior if MLD report/query/etc messages' source > and destination addresses were listed in each case and both sides of > the MAG. Something like what RFC2710 did. > > Regarding the *-pmip6basicmcast-solution-01 I-D, I find it a bit odd > that it has new requirements to MNs apart from supporting certain > MLD version. Also I do not understand what the first sentence in > Section 5. is about. Where is that requirement said? > > [behcet] If you look at Section 6.10.5. Forwarding Rules in RFC 5213, > it says: > > However, the packets that are sent > with the link-local source address MUST NOT be forwarded. Right. Anyway, MLD hop limit is 1. It would not be forwarded beyond MAG anyway. What about the new requirement on MNs? > > As it is stated in *-pmip6basicmcast-solution-01 I-D this was > probably to support ND. > > > > Finally, what is the point of describing two different MLD handling > behaviors for a MAG in these two I-Ds, when both obviously require > changes to the MAG. Or did I miss something? ;) > > > [behcet] This is a deeper question. > The reason for *-pmip6basicmcast-solution-01 I-D is to come up with > a solution which is LMA-based and which is inline with MIPv6/MIPv4 > base spec multicast support. We did not assume any multicast proxy > support at the MAG. Very minimal forwarding requirement on the MAG > So basically the idea was not to get into any optimization ideas. > > I think that *-mcast-deployment-00 did not have the same > requirements. It is ok to have multiple solution proposals. The thing I am puzzled here is that *-pmip6basicmcast-solution-01 seems to require code changes in a MAG, then why not making it properly multicast aware? Cheers, Jouni From behcetsarikaya@yahoo.com Thu Jun 18 14:19:19 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94EC13A69AE for ; Thu, 18 Jun 2009 14:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZvGwNRzgeh4 for ; Thu, 18 Jun 2009 14:19:18 -0700 (PDT) Received: from n6.bullet.re3.yahoo.com (n6.bullet.re3.yahoo.com [68.142.237.91]) by core3.amsl.com (Postfix) with SMTP id 7117D3A67E2 for ; Thu, 18 Jun 2009 14:19:18 -0700 (PDT) Received: from [68.142.230.28] by n6.bullet.re3.yahoo.com with NNFMP; 18 Jun 2009 21:19:28 -0000 Received: from [67.195.9.82] by t1.bullet.re2.yahoo.com with NNFMP; 18 Jun 2009 21:19:28 -0000 Received: from [67.195.9.99] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 18 Jun 2009 21:19:28 -0000 Received: from [127.0.0.1] by omp103.mail.gq1.yahoo.com with NNFMP; 18 Jun 2009 21:16:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 662251.76325.bm@omp103.mail.gq1.yahoo.com Received: (qmail 80437 invoked by uid 60001); 18 Jun 2009 21:19:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245359968; bh=5/6HBCt4DZoH3UIxSCVoAYtJVEtmA0K20WFRg23eT0Q=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RfqVvRLYQGm7KNk96mz7E8mskBrPpMHjZgPKWAOaJL02xtgX+Ennjdi0dv65wu5CvYSKQlpR4Qq5bOV/92dCjIH2owWyzccWo9uwFMb4zLHwqyP74ayKbHsILJ7nGjsUbEZlnT0St39CXrkWpHE7jORh+dr+zaQZEd6qiCvpquI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ouCwX3O5QrKnul4/UsNCsxIOeDbZ0IDYngwEbh7NQNRyNfgtySGelyZioSE3Ca84IV0V9T5gTIcPD4lhSBwZSw2sgQC56/0h7uk/hvvaa8qjvJ/cg4go2wq42jTKsznjMFK6eAb1+fZVcRgUoAZ1Vl8Agfw4TjuLUsbspmhG3co=; Message-ID: <179153.80407.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: G6fxx2IVM1k.7QoNA80AZKE4UpCQoThy7rbOehcD9ZCLOIJvZe8HQ5fp_rjq.jhXbHhH051lgN09a_B4VMPyEmDtfhi6dBZCQSGr2JaIlaRX.G6bfgKPUP1cymVt3JAg_fzUha5vaoskAI9vYnEwEYS.JKpOp.D2OwZHTGXzBR83zOYKblfRxCPxfRcqKTrc.caYH6bC.ejHBT0I15S6FS34A4ciQyPFjKbECPIDgG_scQCIvrszb6DO6ZYPdLLPOZqWp_FtJgeHNR7UNQAgvhQMNOaDPKzfwiO1.8SxlIUB5XRMzAbMxszcwYCRXe7K1jkVOLs9vcgiGpihWTF2rCE- Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Thu, 18 Jun 2009 14:19:27 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 References: <4A341991.205@informatik.haw-hamburg.de> <8917F82B-F8AF-4A05-99C1-C0641519FBDE@gmail.com> <925189.90854.qm@web111409.mail.gq1.yahoo.com> <0D5E6D39-AF10-483E-8F81-285D7CC968A6@gmail.com> Date: Thu, 18 Jun 2009 14:19:27 -0700 (PDT) From: Behcet Sarikaya To: jouni korhonen In-Reply-To: <0D5E6D39-AF10-483E-8F81-285D7CC968A6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org, "Thomas C. Schmidt" Subject: Re: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 21:19:19 -0000 Hi Jouni,=0A=0A----- Original Message ----=0A> From: jouni korhonen =0A> To: Behcet Sarikaya =0A> Cc: Thoma= s C. Schmidt ; multimob@ietf.org=0A> Sen= t: Thursday, June 18, 2009 3:33:13 PM=0A> Subject: Re: [multimob] New Versi= on Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00=0A> = =0A> Hi Bechet,=0A> =0A> On Jun 18, 2009, at 7:33 PM, Behcet Sarikaya wrote= :=0A> =0A> > =0A> > Hi Jouni,=0A> >=A0 Thanks for your comments.=0A> > Let = me answer the part on *-pmip6basicmcast-solution below.=0A> > =0A> > Regard= s,=0A> > =0A> > Behcet=0A> > =0A> > =0A> > =0A> > ----- Original Message --= --=0A> > From: jouni korhonen =0A> > To: Thomas C. Schmidt =0A> > Cc: multi= mob@ietf.org=0A> > Sent: Thursday, June 18, 2009 11:15:49 AM=0A> > Subject:= Re: [multimob] New Version Notification for =0A> draft-schmidt-multimob-pm= ipv6-mcast-deployment-00=0A> > =0A> > Hi Thomas,=0A> > =0A> > One comment r= egarding the *-mcast-deployment-00 I-D. It would benefit greatly =0A> reada= bility of this I-D and help to understand the exact MLD proxy behavior if = =0A> MLD report/query/etc messages' source and destination addresses were l= isted in =0A> each case and both sides of the MAG. Something like what RFC2= 710 did.=0A> > =0A> > Regarding the *-pmip6basicmcast-solution-01 I-D, I fi= nd it a bit odd that it =0A> has new requirements to MNs apart from support= ing certain MLD version. Also I do =0A> not understand what the first sente= nce in Section 5. is about. Where is that =0A> requirement said?=0A> > =0A>= > [behcet] If you look at Section 6.10.5.=A0 Forwarding Rules in RFC 5213,= =0A> > it says:=0A> > =0A> > However, the packets that are sent=0A> >=A0 = =A0 =A0 with the link-local source address MUST NOT be forwarded.=0A> =0A> = Right. Anyway, MLD hop limit is 1. It would not be forwarded beyond MAG any= way.=0A> =0A> What about the new requirement on MNs?=0A> =0A=0ABecause no m= ulticast interface is assumed on the MAG, MN receives the multicast data en= capsulated in a unicast packet, it should decapsulate and give it its multi= cast interface. =0AThis requirement is the same as in MIPv6 RFC 3775. =0A> = =0A> > =0A> > As it is stated in *-pmip6basicmcast-solution-01 I-D this was= probably to =0A> support ND.=0A> > =0A> > =0A> > =0A> > Finally, what is t= he point of describing two different MLD handling behaviors =0A> for a MAG = in these two I-Ds, when both obviously require changes to the MAG. Or =0A> = did I miss something? ;)=0A> > =0A> > =0A> > [behcet] This is a deeper ques= tion.=0A> > The reason for *-pmip6basicmcast-solution-01 I-D is to come up = with a solution =0A> which is LMA-based and which is inline with MIPv6/MIPv= 4 base spec multicast =0A> support. We did not assume any multicast proxy s= upport at the MAG. Very minimal =0A> forwarding requirement on the MAG=0A> = > So basically the idea was not to get into any optimization ideas.=0A> > = =0A> > I think that *-mcast-deployment-00=A0 did not have the same requirem= ents.=0A> =0A> It is ok to have multiple solution proposals. The thing I am= puzzled here is =0A> that *-pmip6basicmcast-solution-01 seems to require c= ode changes in a MAG, then =0A> why not making it properly multicast aware?= =0A> =0A=0AI understand but making MAG multicast aware comes with a lot ass= umptions and also complications at the LMA. It has been left out of scope w= ith *-pmip6basicmcast-solution-01 I-D. These are optimizations that avoid= =A0things like avalanche problem. It is left for other drafts to deal with.= =0A*-pmip6basicmcast-solution-01 I-D is simple and enables maximum code sha= re with the legacy HA.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A From jouni.nospam@gmail.com Thu Jun 18 14:29:07 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53F6A3A67E1 for ; Thu, 18 Jun 2009 14:29:07 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMltVEYLS+yw for ; Thu, 18 Jun 2009 14:29:06 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 947EC3A6C9B for ; Thu, 18 Jun 2009 14:28:58 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so417207fge.18 for ; Thu, 18 Jun 2009 14:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=qv5VY/hIr+0crlGx9ctIoUHopE+6gNnG1SDPjYEJwSw=; b=gk+sqJ05LAUBM+Kl9kQ6Sb7fpOW8rPCfO5aMgSgWgFSO1FvzJY1/bvORIrs4mMW7nk bqpZpFhiBigJ3mTvLkMPNvNDA1WJFlJSTTS6CqkU/cifbqsak5AAOB8wVsgp6YRYzwg3 MNYANYrwj/jqgklGOPPgobSH837asmXwFRcfQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=RqmC9gafh8tatgnqghvUAEPKWmh6VH0+rorj1aFis0ayfecXkJjFbV6vel5lKnn5RB 60z19XscBq6MD94QLD8zBXR1pIHr/BqCiFBiCJ5uqogt4qFMFfsLZYJwyt1b2QagaaPm wL+2TSIqF4o1zcjuUXPItjA/acq9baNI6z5p8= Received: by 10.86.1.1 with SMTP id 1mr2523354fga.0.1245360548101; Thu, 18 Jun 2009 14:29:08 -0700 (PDT) Received: from a83-245-212-65.elisa-laajakaista.fi (a83-245-212-65.elisa-laajakaista.fi [83.245.212.65]) by mx.google.com with ESMTPS id d6sm480957fga.27.2009.06.18.14.29.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Jun 2009 14:29:07 -0700 (PDT) Message-Id: From: jouni korhonen To: Thomas C. Schmidt In-Reply-To: <4A3A6D6B.9060205@informatik.haw-hamburg.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 19 Jun 2009 00:29:06 +0300 References: <4A341991.205@informatik.haw-hamburg.de> <8917F82B-F8AF-4A05-99C1-C0641519FBDE@gmail.com> <4A3A6D6B.9060205@informatik.haw-hamburg.de> X-Mailer: Apple Mail (2.935.3) Cc: multimob@ietf.org Subject: Re: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 21:29:07 -0000 Hi Thomas, On Jun 18, 2009, at 7:38 PM, Thomas C. Schmidt wrote: > Hi Jouni, > > thanks for your comments! > > jouni korhonen wrote: > >> One comment regarding the *-mcast-deployment-00 I-D. It would >> benefit greatly readability of this I-D and help to understand the >> exact MLD proxy behavior if MLD report/query/etc messages' source >> and destination addresses were listed in each case and both sides >> of the MAG. Something like what RFC2710 did. > > O.k., good suggestion: we will add this in the next revision which > is about to come soon. Great. > > >> Regarding the *-pmip6basicmcast-solution-01 I-D, I find it a bit >> odd that it has new requirements to MNs apart from supporting >> certain MLD version. Also I do not understand what the first >> sentence in Section 5. is about. Where is that requirement said? > What requirements do you refer to - apart from MLDv2? > Actually, there should not be any. The last sentence in Section 6. states: "..unicast packets with the multicast datagram encapsulated. The mobile node MUST be capable of decapsulating packets sent to its home address in order to receive multicast datagrams." I see a MUST there. I am no means multicast savvy but it seems that the functionality above requires a bit more than just multicast reception capabilities from the MN... or? The LMA encapsulates a multicast packet inside another IP header before tunneling it to the MAG and eventually the MN is supposed to decapsulate the additional header before realizing that the packet is about multicast traffic. Section 3. references to RFC3344 (MIPv4..?) when it discusses this case. How the MN would know when it needs to decapsulate some packet and when not? Based on the source address? Maybe I have missed some RFC where this is already defined? > > > Regarding MLDv2: there is no general consensus on putting this as a > requirement ... I don't believe there is an issue in using MLDv1 > here, as well. Ok. That's fine. The I-D just says in Section 6. that the MN must be MLDv2 capable. > > > About Sect 5, first sentence: > I guess, this is just "catch up" on PMIPv6, recalling the context. I > suppose it is not meant as adding a requirement ... > >> Finally, what is the point of describing two different MLD handling >> behaviors for a MAG in these two I-Ds, when both obviously require >> changes to the MAG. Or did I miss something? ;) > > Two different approaches to the problem have been around - in > preparing two documents we hope to support the discussion on the > right way to go. > > However, the *-mcast-deployment-00 I-D should not require changes to > the MAG apart from activating another protocol standard (MLD Proxy). > That's at least the objective of it. The MLD proxy approach looked fine to me. Cheers, Jouni From schmidt@informatik.haw-hamburg.de Thu Jun 18 15:32:22 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4023A67ED for ; Thu, 18 Jun 2009 15:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzHakWp9RfrD for ; Thu, 18 Jun 2009 15:32:21 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 7E0CB3A65A6 for ; Thu, 18 Jun 2009 15:32:19 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178150002.adsl.alicedsl.de ([85.178.150.2] helo=[192.168.178.23]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MHQ9n-000Aao-CT; Fri, 19 Jun 2009 00:32:31 +0200 Message-ID: <4A3AC076.7070207@informatik.haw-hamburg.de> Date: Fri, 19 Jun 2009 00:32:22 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: jouni korhonen References: <4A341991.205@informatik.haw-hamburg.de> <8917F82B-F8AF-4A05-99C1-C0641519FBDE@gmail.com> <4A3A6D6B.9060205@informatik.haw-hamburg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 22:32:22 -0000 Hi Jouni, jouni korhonen wrote: >> >>> Regarding the *-pmip6basicmcast-solution-01 I-D, I find it a bit odd >>> that it has new requirements to MNs apart from supporting certain MLD >>> version. Also I do not understand what the first sentence in Section >>> 5. is about. Where is that requirement said? >> What requirements do you refer to - apart from MLDv2? >> Actually, there should not be any. > > The last sentence in Section 6. states: > > "..unicast packets with the multicast datagram encapsulated. The mobile > node MUST be capable of decapsulating packets sent to its home address > in order to receive multicast datagrams." > I see a MUST there. I am no means multicast savvy but it seems that the > functionality above requires a bit more than just multicast reception > capabilities from the MN... or? The LMA encapsulates a multicast packet > inside another IP header before tunneling it to the MAG and eventually > the MN is supposed to decapsulate the additional header before realizing > that the packet is about multicast traffic. Section 3. references to > RFC3344 (MIPv4..?) when it discusses this case. > How the MN would know when it needs to decapsulate some packet and when > not? Based on the source address? Maybe I have missed some RFC where > this is already defined? > Actually, I'm a bit uneasy with this tunneling, as well. If a MN receives encapsulated packets from a uni-directional GRE-tunnel, I guess it should just decapsulate them. However, the problem seems to be with the "interfaces": Unlike in RFC3775, the MN does not have a (bi-directional) tunnel interface to which it issues the MLD reports. Instead, it uses its regular (wireless) interface that in response receives unicast-encapsulated packets. I'm not exactly sure whether this really does work transparently, but it certainly gets more confusing with queries arriving from the LMA also in the tunnel. So this approach certainly needs more analysis and discussions. Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From behcetsarikaya@yahoo.com Thu Jun 18 16:28:31 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EBCE3A6911 for ; Thu, 18 Jun 2009 16:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2vPGpdmmwuo for ; Thu, 18 Jun 2009 16:28:30 -0700 (PDT) Received: from n2.bullet.mail.re3.yahoo.com (n2.bullet.mail.re3.yahoo.com [68.142.237.109]) by core3.amsl.com (Postfix) with SMTP id 785313A68E7 for ; Thu, 18 Jun 2009 16:28:30 -0700 (PDT) Received: from [68.142.237.88] by n2.bullet.mail.re3.yahoo.com with NNFMP; 18 Jun 2009 23:28:41 -0000 Received: from [67.195.9.83] by t4.bullet.re3.yahoo.com with NNFMP; 18 Jun 2009 23:28:41 -0000 Received: from [67.195.9.100] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 18 Jun 2009 23:28:41 -0000 Received: from [127.0.0.1] by omp104.mail.gq1.yahoo.com with NNFMP; 18 Jun 2009 23:28:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 47616.20966.bm@omp104.mail.gq1.yahoo.com Received: (qmail 88943 invoked by uid 60001); 18 Jun 2009 23:28:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245367720; bh=vL7I2CUyXtS2/mZWghpXFhU4zT/3Tzw4/vhcsxTywlY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Bi3Mxq3OMps3LNW63TXE8IxB0E2MFFJJvhLo4ZGyUYndSTUJXUCtEIIw5w4C1/2vGnU32OdYogN9sgJwSRlyynw2d8XuUas+T9sYdHD15FOsTAOxrNvELYZ/Q04qvP5xv3RlQY4kGpnDLE8EyFHpxK3GIh6cUQg2UtjdG7qK+IA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=z5HsUk/HTGI4ERISoZoiyb6umU/GePHCmFDY4922qpDWUflbgejt/iOK6+6DvEiojBjbwHkO52pyRnni2VjvAKuN1SoCJWQ2SlTmNptYF/q5O+i5Kshb5EJdgRFRIfNQuVk7jOEOvbYN0dXwm3+ACGFCVjozqc2x6qP+IhrqyoI=; Message-ID: <945398.87169.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: hBLi2ZsVM1l4m8m.UgG9puPCMom6Hihhsg1.K.ROtULfCmzIWOGUpj.BWYblOXLiOBqByJBAoRpCsIbQM8d1GDoUgrCeHz9p1IZQCmjO8VZIrpCJp3WGgBFDYWLKUs7sjPHqX50APVqJsaMcsMdAiH2dpEFzGQ9aWmgiZEBPG6BXoZVCNAsuzR8nnFyGBed3Ydu5eApEiCntddVvupUYOIT_CgQ5ew7wh0nMqJkNrt.hSafUVojvhJyEAaIeNgEj6dmuQ8A0_SGag86EqWM_Xs1SI.TJoh3l83.gbvIEqfCZ6kw0Xf5MAbtr7b.DYEA2LeMhZTz31JAQnTH1eQoBBIs- Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Thu, 18 Jun 2009 16:28:40 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 References: <4A341991.205@informatik.haw-hamburg.de> <8917F82B-F8AF-4A05-99C1-C0641519FBDE@gmail.com> <4A3A6D6B.9060205@informatik.haw-hamburg.de> <4A3AC076.7070207@informatik.haw-hamburg.de> Date: Thu, 18 Jun 2009 16:28:40 -0700 (PDT) From: Behcet Sarikaya To: "Thomas C. Schmidt" , jouni korhonen In-Reply-To: <4A3AC076.7070207@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 23:28:31 -0000 ----- Original Message ---- > From: Thomas C. Schmidt > To: jouni korhonen > Cc: multimob@ietf.org > Sent: Thursday, June 18, 2009 5:32:22 PM > Subject: Re: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00 > > Hi Jouni, > > jouni korhonen wrote: > > >> > >>> Regarding the *-pmip6basicmcast-solution-01 I-D, I find it a bit odd that it > has new requirements to MNs apart from supporting certain MLD version. Also I do > not understand what the first sentence in Section 5. is about. Where is that > requirement said? > >> What requirements do you refer to - apart from MLDv2? > >> Actually, there should not be any. > > > > The last sentence in Section 6. states: > > > > "..unicast packets with the multicast datagram encapsulated. The mobile node > MUST be capable of decapsulating packets sent to its home address in order to > receive multicast datagrams." > > I see a MUST there. I am no means multicast savvy but it seems that the > functionality above requires a bit more than just multicast reception > capabilities from the MN... or? The LMA encapsulates a multicast packet inside > another IP header before tunneling it to the MAG and eventually the MN is > supposed to decapsulate the additional header before realizing that the packet > is about multicast traffic. Section 3. references to RFC3344 (MIPv4..?) when it > discusses this case. Please see Sec. 4.4 in RFC 3344 on page 67. MIPv4 HA uses nested tunneling to send multicast data to MN. > > How the MN would know when it needs to decapsulate some packet and when not? > Based on the source address? Maybe I have missed some RFC where this is already > defined? > > > > Actually, I'm a bit uneasy with this tunneling, as well. If a MN receives > encapsulated packets from a uni-directional GRE-tunnel, I guess it should just > decapsulate them. However, the problem seems to be with the "interfaces": Unlike > in RFC3775, the MN does not have a (bi-directional) tunnel interface to which it > issues the MLD reports. Instead, it uses its regular (wireless) interface that > in response receives unicast-encapsulated packets. I'm not exactly sure whether > this really does work transparently, but it certainly gets more confusing with > queries arriving from the LMA also in the tunnel. > > So this approach certainly needs more analysis and discussions. > Maybe so. In this case MN sends and receives from the MAG regularly and the tunneled incoming packets are indicated properly so MN should be able to decapsulate them. I am not sure if this means MN is taking part in mobility signaling which is not allowed in PMIPv6. More comments will be welcome. Regards, Behcet From jouni.nospam@gmail.com Thu Jun 18 23:27:16 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62CBF3A6A81 for ; Thu, 18 Jun 2009 23:27:16 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEjV9BBZx9RI for ; Thu, 18 Jun 2009 23:27:15 -0700 (PDT) Received: from mail-fx0-f206.google.com (mail-fx0-f206.google.com [209.85.220.206]) by core3.amsl.com (Postfix) with ESMTP id AD3843A6A72 for ; Thu, 18 Jun 2009 23:27:14 -0700 (PDT) Received: by fxm2 with SMTP id 2so65125fxm.37 for ; Thu, 18 Jun 2009 23:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=DUYxKaxnFiXzPIGrJeEWcFsc/vYhRbclbYqmVzj9LxY=; b=YmQTZj3Q1KA3Zl/eh0w8fqUqrA/4DK0VN26Adknlj/RfSksZe6KT+LzR3L345bOPAn yiOlGL/L+UY67/XVgtb88nD08Xb1RkgLxjDnBJJG5zCrLkF3kjQrL/oN0v2pewk08jk5 fzFiA49k6EjxArYWtCtcFrpbgPXSJCNI0HQhc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=Vc4JwSeVD4dLyfrcexNGl/95yU95oTLHELaUd5RZtw5XUB6YeyuHCCXkztZAjEO/4e XARwwI9u6GZDw2KvuYssCd0qJ+whuJdg9DyuaXbZciBFD4AIeQAiXbTxn4F2DV4XaHDg nZXKJR43iOml/v/ENmHBEqtsNQacUZMl80l2E= Received: by 10.86.70.20 with SMTP id s20mr2822809fga.1.1245392845051; Thu, 18 Jun 2009 23:27:25 -0700 (PDT) Received: from a83-245-212-65.elisa-laajakaista.fi (a83-245-212-65.elisa-laajakaista.fi [83.245.212.65]) by mx.google.com with ESMTPS id e20sm7433337fga.25.2009.06.18.23.27.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Jun 2009 23:27:24 -0700 (PDT) Message-Id: <0360C43D-8821-4CA3-B2DE-BACDE1E6F379@gmail.com> From: jouni korhonen To: Behcet Sarikaya In-Reply-To: <945398.87169.qm@web111411.mail.gq1.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 19 Jun 2009 09:27:22 +0300 References: <4A341991.205@informatik.haw-hamburg.de> <8917F82B-F8AF-4A05-99C1-C0641519FBDE@gmail.com> <4A3A6D6B.9060205@informatik.haw-hamburg.de> <4A3AC076.7070207@informatik.haw-hamburg.de> <945398.87169.qm@web111411.mail.gq1.yahoo.com> X-Mailer: Apple Mail (2.935.3) Cc: multimob@ietf.org, "Thomas C. Schmidt" Subject: Re: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 06:27:16 -0000 Hi Behcet, On Jun 19, 2009, at 2:28 AM, Behcet Sarikaya wrote: >> jouni korhonen wrote: >> >>>> >>>>> Regarding the *-pmip6basicmcast-solution-01 I-D, I find it a bit >>>>> odd that it >> has new requirements to MNs apart from supporting certain MLD >> version. Also I do >> not understand what the first sentence in Section 5. is about. >> Where is that >> requirement said? >>>> What requirements do you refer to - apart from MLDv2? >>>> Actually, there should not be any. >>> >>> The last sentence in Section 6. states: >>> >>> "..unicast packets with the multicast datagram encapsulated. The >>> mobile node >> MUST be capable of decapsulating packets sent to its home address >> in order to >> receive multicast datagrams." >>> I see a MUST there. I am no means multicast savvy but it seems >>> that the >> functionality above requires a bit more than just multicast reception >> capabilities from the MN... or? The LMA encapsulates a multicast >> packet inside >> another IP header before tunneling it to the MAG and eventually the >> MN is >> supposed to decapsulate the additional header before realizing that >> the packet >> is about multicast traffic. Section 3. references to RFC3344 >> (MIPv4..?) when it >> discusses this case. > > Please see Sec. 4.4 in RFC 3344 on page 67. MIPv4 HA uses nested > tunneling to send multicast data to MN. The text is for a MIPv4 capable MN.. here in PMIP6 context we are talking about unmodified MN and cannot assume it has some functionality inherited just like that from MIPv4 specs. > > >>> How the MN would know when it needs to decapsulate some packet and >>> when not? >> Based on the source address? Maybe I have missed some RFC where >> this is already >> defined? >>> >> >> Actually, I'm a bit uneasy with this tunneling, as well. If a MN >> receives >> encapsulated packets from a uni-directional GRE-tunnel, I guess it >> should just >> decapsulate them. However, the problem seems to be with the >> "interfaces": Unlike >> in RFC3775, the MN does not have a (bi-directional) tunnel >> interface to which it >> issues the MLD reports. Instead, it uses its regular (wireless) >> interface that >> in response receives unicast-encapsulated packets. I'm not exactly >> sure whether >> this really does work transparently, but it certainly gets more >> confusing with >> queries arriving from the LMA also in the tunnel. >> >> So this approach certainly needs more analysis and discussions. >> > Maybe so. In this case MN sends and receives from the MAG regularly > and the tunneled incoming packets are indicated properly so MN > should be able to decapsulate them. Indicated properly how? Cheers, Jouni > > > I am not sure if this means MN is taking part in mobility signaling > which is not allowed in PMIPv6. > > More comments will be welcome. > > Regards, > > Behcet > > > > > From behcetsarikaya@yahoo.com Fri Jun 19 07:46:47 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026473A6922 for ; Fri, 19 Jun 2009 07:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm0qo4jIS4HN for ; Fri, 19 Jun 2009 07:46:46 -0700 (PDT) Received: from n70.bullet.mail.sp1.yahoo.com (n70.bullet.mail.sp1.yahoo.com [98.136.44.38]) by core3.amsl.com (Postfix) with SMTP id 197CB3A6884 for ; Fri, 19 Jun 2009 07:46:45 -0700 (PDT) Received: from [69.147.84.144] by n70.bullet.mail.sp1.yahoo.com with NNFMP; 19 Jun 2009 14:46:57 -0000 Received: from [67.195.9.81] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 19 Jun 2009 14:46:57 -0000 Received: from [67.195.9.99] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 19 Jun 2009 14:46:57 -0000 Received: from [127.0.0.1] by omp103.mail.gq1.yahoo.com with NNFMP; 19 Jun 2009 14:46:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 219433.39312.bm@omp103.mail.gq1.yahoo.com Received: (qmail 61292 invoked by uid 60001); 19 Jun 2009 14:46:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245422817; bh=WaKqUDo3AqYrbceMkhmMf08jJM0t2C/faPn+C2bBGHg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CIKZE8dY7x/Qp/f3iHX1Si2YlCnlmPNlN+PSIpWa+bYP6DWNqZPOxsisPxpPj4yw1RM5m1RvrBS1qaYlCq45I/vxOQ9WMniPcMTeoWf1EYqRv2HCaDutIk8X60mW1TV6zD5/an/caIjNaQcyuzF/jiTU3/ges8+RSFWiynXsdDI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QKHiNcCZIvkYROE388oAqmui0xYyftdFLHKzkanvveVc/Ouuef6gWQl0c1zUYJK5Ydu37DuiXic8c0/y1hfGmoWxjP4SOEVjSzFbJxp8R3gS1bghdjZqN1PuoTm92of0h/NPAG5/CXZtm5DmgJMRkY5ulnUAOmsRj3yjixR62rk=; Message-ID: <91483.60941.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: lrQtTKIVM1m68S4JwflC_lJLsPo0jQAqH7GJB5Y5jYVZj_wPnZDE_Bgl Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Fri, 19 Jun 2009 07:46:56 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 References: <4A341991.205@informatik.haw-hamburg.de> <8917F82B-F8AF-4A05-99C1-C0641519FBDE@gmail.com> <4A3A6D6B.9060205@informatik.haw-hamburg.de> <4A3AC076.7070207@informatik.haw-hamburg.de> <945398.87169.qm@web111411.mail.gq1.yahoo.com> <0360C43D-8821-4CA3-B2DE-BACDE1E6F379@gmail.com> Date: Fri, 19 Jun 2009 07:46:56 -0700 (PDT) From: Behcet Sarikaya To: jouni korhonen In-Reply-To: <0360C43D-8821-4CA3-B2DE-BACDE1E6F379@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org, "Thomas C. Schmidt" Subject: Re: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 14:46:47 -0000 Hi Jouni, ----- Original Message ---- > From: jouni korhonen > To: Behcet Sarikaya > Cc: multimob@ietf.org; Thomas C. Schmidt > Sent: Friday, June 19, 2009 1:27:22 AM > Subject: Re: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00 > > Hi Behcet, > > On Jun 19, 2009, at 2:28 AM, Behcet Sarikaya wrote: > > >> jouni korhonen wrote: > >> > >>>> > >>>>> Regarding the *-pmip6basicmcast-solution-01 I-D, I find it a bit odd that > it > >> has new requirements to MNs apart from supporting certain MLD version. Also I > do > >> not understand what the first sentence in Section 5. is about. Where is that > >> requirement said? > >>>> What requirements do you refer to - apart from MLDv2? > >>>> Actually, there should not be any. > >>> > >>> The last sentence in Section 6. states: > >>> > >>> "..unicast packets with the multicast datagram encapsulated. The mobile node > >> MUST be capable of decapsulating packets sent to its home address in order to > >> receive multicast datagrams." > >>> I see a MUST there. I am no means multicast savvy but it seems that the > >> functionality above requires a bit more than just multicast reception > >> capabilities from the MN... or? The LMA encapsulates a multicast packet > inside > >> another IP header before tunneling it to the MAG and eventually the MN is > >> supposed to decapsulate the additional header before realizing that the > packet > >> is about multicast traffic. Section 3. references to RFC3344 (MIPv4..?) when > it > >> discusses this case. > > > > Please see Sec. 4.4 in RFC 3344 on page 67. MIPv4 HA uses nested tunneling to > send multicast data to MN. > > The text is for a MIPv4 capable MN.. here in PMIP6 context we are talking about > unmodified MN and cannot assume it has some functionality inherited just like > that from MIPv4 specs. > > > > > > > >>> How the MN would know when it needs to decapsulate some packet and when not? > >> Based on the source address? Maybe I have missed some RFC where this is > already > >> defined? > >>> > >> > >> Actually, I'm a bit uneasy with this tunneling, as well. If a MN receives > >> encapsulated packets from a uni-directional GRE-tunnel, I guess it should > just > >> decapsulate them. However, the problem seems to be with the "interfaces": > Unlike > >> in RFC3775, the MN does not have a (bi-directional) tunnel interface to which > it > >> issues the MLD reports. Instead, it uses its regular (wireless) interface > that > >> in response receives unicast-encapsulated packets. I'm not exactly sure > whether > >> this really does work transparently, but it certainly gets more confusing > with > >> queries arriving from the LMA also in the tunnel. > >> > >> So this approach certainly needs more analysis and discussions. > >> > > Maybe so. In this case MN sends and receives from the MAG regularly and the > tunneled incoming packets are indicated properly so MN should be able to > decapsulate them. > > Indicated properly how? IP Header Protocol field. There is a value reserved for IP-in-IP encapsulation. You can check this at: http://www.iana.org/assignments/protocol-numbers/ So MN knows that it received an encapsulated packet. Whether an unmodified MN can decapsulate such packets and look at the new header and process them as multicast data, I guess yes, but I am not sure. Regards, Behcet From behcetsarikaya@yahoo.com Sat Jun 20 12:54:29 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A09373A6B80 for ; Sat, 20 Jun 2009 12:54:29 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzLA4doxzk8a for ; Sat, 20 Jun 2009 12:54:28 -0700 (PDT) Received: from n61.bullet.mail.sp1.yahoo.com (n61.bullet.mail.sp1.yahoo.com [98.136.44.37]) by core3.amsl.com (Postfix) with SMTP id CACD93A6B60 for ; Sat, 20 Jun 2009 12:54:28 -0700 (PDT) Received: from [216.252.122.217] by n61.bullet.mail.sp1.yahoo.com with NNFMP; 20 Jun 2009 19:54:41 -0000 Received: from [67.195.9.83] by t2.bullet.sp1.yahoo.com with NNFMP; 20 Jun 2009 19:54:41 -0000 Received: from [67.195.9.103] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 20 Jun 2009 19:54:41 -0000 Received: from [127.0.0.1] by omp107.mail.gq1.yahoo.com with NNFMP; 20 Jun 2009 19:54:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 231447.21500.bm@omp107.mail.gq1.yahoo.com Received: (qmail 22862 invoked by uid 60001); 20 Jun 2009 19:54:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245527681; bh=RWJlq3DNzypLQF9Yep4Obw5RvG6usRW8cKbXF3hayU0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=sdt7p21iOe9G9Bsl1C+ZfMaXkHOu3rGQJyCj9a3OfOeCo3w8V49XgSjxR4qlcvBua1/SG32IPCqwJwln06MvDn66zgbrcAPtRQcQbfgmxhTNnQ5QjMMTESPCc+Zk5qMYQP16NYypEqJ4pfZrcE4G4xldBTvxoUwC3UTC2EZV0I4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=xxgPv9fbSLiteI7iYqlz/FHLtG4wr8r5oZdvhojBm5nGjI8CxfbfIBUFkJaEbsaBsiAkLKz6PgtuIST4IrS2Nohy2skUT0z5MfiEqiRFFaTqv3AmyRhvdAmV/1fjFMEbVGN3yAI6g6VgM7PucdhINFCPglP/R9CY3XVMTevlqCo=; Message-ID: <997581.22706.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: Z55A9F4VM1nomwVZn8qk46kRcWj.Xvun8Spn5X5CBXFV48PrB5WVsCx7h2uTt9lvDc4wZbMkAmdY2a3OQVSOJB61zKODU0DGx2KDnVkOkYIs9MOaNyRzGqSe4zFJqSib8UiwZZG_WRsRaQ5MidGxY_27k1krUWajgcKv1Scsl1gNQZp9lh7kUyu1G1hft7dVO0NlV9Mj3HKq.auuWwzNCQHPN7XYUTM0cAgVOq0vyxYIWzBFW8ZTFkl6IpX3MwVGTxt_7HP8NR7k2bbHmjRhg2Wz_YXIKYqu5EkN2wzE7D0CWtGrFAURVDjVka6_INrRKP.HNUOiD_Kjq0PTyEOFbRTDDUDzOIV7FXxa Received: from [71.170.139.250] by web111409.mail.gq1.yahoo.com via HTTP; Sat, 20 Jun 2009 12:54:40 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 Date: Sat, 20 Jun 2009 12:54:40 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] BOF Date and Time X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2009 19:54:29 -0000 Folks, Multimob BoF will take place on Friday July 31 at 13:00 for one hour. More details are at: http://www.ietf.org/meetings/75/75-Draft-Agenda.pdf No room assigned yet. Please make sure to extend your stay in Stockholm to Friday afternoon. Regards, Behcet & Gorry From jouni.nospam@gmail.com Mon Jun 22 04:31:10 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA2B3A6B03 for ; Mon, 22 Jun 2009 04:31:10 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SdqEXimISm9 for ; Mon, 22 Jun 2009 04:31:10 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id AA6A33A6B3E for ; Mon, 22 Jun 2009 04:31:09 -0700 (PDT) Received: by ewy6 with SMTP id 6so4607774ewy.37 for ; Mon, 22 Jun 2009 04:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=r3OaZD/l9avjvqvA1z1ervTkJrIqCoDZnjrxOpah6qg=; b=FsObNYACzw9kWTu0Z2dgh7yybYE3s7vJMiT+1SoLdFTZguP5r2CMIGEGUIZlfJhlgP EeTlX0nopXL4UyQ4FAnHEWdnLajFno8Jz2iBhXbqbZXKrcEIwbEtvQmU2M0zc9wCHHgI lRgsHBOtLC2whJ2aT8DSdQNVA/dV7DdzaL3f0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=D8kAuD1HNzGz3H7HbVQkl88nFMSghj++ObBNnUcHHBw8MbUwCT+sUju4WNEoyf4nrm U7/4gPnbWWZQrL5sYj0/oZ9laqDedVY8fgwrSXNGr3pP6fQd43RGht3qZklBXznNge+j uM/xARwn+TYDULtVHuYQAD07LhMHSLgUHDXk8= Received: by 10.216.11.137 with SMTP id 9mr2120910wex.180.1245670281475; Mon, 22 Jun 2009 04:31:21 -0700 (PDT) Received: from ?10.254.0.126? ([192.100.123.77]) by mx.google.com with ESMTPS id 28sm201143eye.26.2009.06.22.04.31.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Jun 2009 04:31:21 -0700 (PDT) Message-Id: From: jouni korhonen To: Behcet Sarikaya In-Reply-To: <91483.60941.qm@web111413.mail.gq1.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 14:31:17 +0300 References: <4A341991.205@informatik.haw-hamburg.de> <8917F82B-F8AF-4A05-99C1-C0641519FBDE@gmail.com> <4A3A6D6B.9060205@informatik.haw-hamburg.de> <4A3AC076.7070207@informatik.haw-hamburg.de> <945398.87169.qm@web111411.mail.gq1.yahoo.com> <0360C43D-8821-4CA3-B2DE-BACDE1E6F379@gmail.com> <91483.60941.qm@web111413.mail.gq1.yahoo.com> X-Mailer: Apple Mail (2.935.3) Cc: multimob@ietf.org, "Thomas C. Schmidt" Subject: Re: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 11:31:11 -0000 Hi Behcet, On Jun 19, 2009, at 5:46 PM, Behcet Sarikaya wrote: > > Hi Jouni, [snip] >> tunneled incoming packets are indicated properly so MN should be >> able to >> decapsulate them. >> >> Indicated properly how? > > IP Header Protocol field. There is a value reserved for IP-in-IP > encapsulation. You can check this at: > http://www.iana.org/assignments/protocol-numbers/ > > So MN knows that it received an encapsulated packet. Whether an > unmodified MN can decapsulate such packets and look at the new > header and process them as multicast data, I guess yes, but I am not > sure. Righty. The "IPIP decapsulation" i.e. the tunnel interface should be clever enough to figure out this is about multicast traffic and pass the packet to the proper multicast receiver part in the stack. That is a broad assumption. Here, GRE could work better than IPIP. There is also another problem. You cannot assume that the MN has any possibility to find out the LMA Address. For example, in some architectures that has been purposely prohibited. And how an unmodified host could tell a difference between LMA Address and any other address? Regarding the I-D, it has to be more specific what is actually required from a MN to receive encapsulated multicast traffic. So far it looks to me that none of the proposed (encapsulation) methods work out of box in a multicast enabled host, even if we were not considering configuring (widely deployed) tunnels and such as a host change. If host changes are in scope, then chances are better but the I-D must be explicit about that decision then. The amount of additional text would not be that big imho. Cheers, Jouni > > > Regards, > > Behcet > > > > From behcetsarikaya@yahoo.com Mon Jun 22 08:06:00 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC7B3A6B6E for ; Mon, 22 Jun 2009 08:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv+2F57MFrdk for ; Mon, 22 Jun 2009 08:05:59 -0700 (PDT) Received: from n66.bullet.mail.sp1.yahoo.com (n66.bullet.mail.sp1.yahoo.com [98.136.44.50]) by core3.amsl.com (Postfix) with SMTP id B14DA3A6906 for ; Mon, 22 Jun 2009 08:05:59 -0700 (PDT) Received: from [69.147.84.144] by n66.bullet.mail.sp1.yahoo.com with NNFMP; 22 Jun 2009 15:06:12 -0000 Received: from [67.195.9.83] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 22 Jun 2009 15:06:12 -0000 Received: from [67.195.9.100] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 22 Jun 2009 15:06:11 -0000 Received: from [127.0.0.1] by omp104.mail.gq1.yahoo.com with NNFMP; 22 Jun 2009 15:06:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 881584.92145.bm@omp104.mail.gq1.yahoo.com Received: (qmail 96897 invoked by uid 60001); 22 Jun 2009 15:06:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245683171; bh=oBCTG55c7V9clWNElfPOUO4MpXw6kre358MDoi8GMaQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=TW/B4YtCkeWC9A0ldakloP1WIQlJ/pVIDEXAcrHelS0igK5hAyMySNHjWRa+gc2ljx98SIS8IOzNXxjEtkJJwKU328RAzHxKjkS/I5fEs7uziPMmSAzEzTn/QoEGBgVamY+ur5KNGUoIaJtML5gEvz+x+2lCmfy6N/qNBE4HzKU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=qc2VKrW0I2lpbCuIzdJvx7Na/5JivyK/6oaOI/WvKv7liM/FaVGUd1oJsHz7Th+qbdiu6G603AM9gLVnl3TVSuTxrQCrdE0erLo1rOz2BXbcp7dERrDFn2pzYi2DMwTi5D2iTEzS5taMDwDUFL2ctDZF62gr+FC7U6MLND2yhOI=; Message-ID: <692113.93816.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: M5Cn3MwVM1kGiMeV_Np.flHC7IxJXXT6SXnw_82Nh4s_FE8BuMEwoWAswvo4FX685IFqFEg6bWVR7KJnuzTDHkZW41XAD9ySUMZWRJHzFQL199rES7Wjb7lMw26rpWALclfN8EPzDY9YFSuyH0TVtEvZ9pHeETLAvSYX0uk4ZNSaNd02cuCcjHZ_juFHATYCorjyWa8kQS4X8_1COTRrdiOL6GDDTvAmKfCrsPjpibUdVfoXCe1fQJI5BaRDmzuCzLmSfZYlUXy8K30A8S8b6ZQWwxHJZQadg0lwUfjStOg2kTcBiXXVPCCyxk79vyeVOtLI_mE484O8.msZaaJkTrK1WWm_c1YE2WFkeDSIGzhS Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Mon, 22 Jun 2009 08:06:11 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 Date: Mon, 22 Jun 2009 08:06:11 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-929907059-1245683171=:93816" Subject: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 15:06:00 -0000 --0-929907059-1245683171=:93816 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello Folks,=0A=A0 This is the latest charter I have. Please comment. =0A= =0ARegards,=0A=0ABehcet=0A=0A=0A --0-929907059-1245683171=:93816 Content-Type: text/plain; name="multimobcharter06.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="multimobcharter06.txt" Ck11bHRpY2FzdCBNb2JpbGl0eSAobXVsdGltb2IpDQoNCkNoYWlyczoNClRC RA0KDQpJbnRlcm5ldCBBcmVhIChpbnQpIERpcmVjdG9yczoNCkphcmkgQXJr a28gPGphcmkuYXJra29AcGl1aGEubmV0Pg0KTWFyayBUb3duc2xleSA8dG93 bnNsZXlAY2lzY28uY29tPiANCg0KSW50ZXJuZXQgQXJlYSBBZHZpc29yOg0K SmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+DQoNClNlY3VyaXR5 IEFyZWEgQWR2aXNvcjoNCk1hcnNoYWxsIEV1YmFua3MgPHRtZUBhbWVyaWNh ZnJlZS50dj4uDQoNCk1haWxpbmcgTGlzdHM6DQpHZW5lcmFsIERpc2N1c3Np b246IG11bHRpbW9iQGlldGYub3JnDQpTdWJzY3JpYmUgb25saW5lIGF0OiBo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aW1v Yg0KDQpEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwDQoNClRoZSBNdWx0 aWNhc3QgbW9iaWxpdHkgKG11bHRpbW9iKSB3aWxsIGRldmVsb3AgYSBzZXQg b2YgcHJvdG9jb2wgZXh0ZW5zaW9ucyBhbmQgcHJvdmlkZSBndWlkYW5jZSBh cHByb3ByaWF0ZSBmb3IgSVB2NCBhbmQgSVB2NiBtdWx0aWNhc3QgaW4gYSBt b2JpbGUgZW52aXJvbm1lbnQuIEl0IHdpbGwgY29uc2lkZXIgYm90aCBzb3Vy Y2Ugc3BlY2lmaWMgbXVsdGljYXN0IChTU00pICBhbmQgYW55IHNvdXJjZSBt dWx0aWNhc3QgKEFTTSkgbXVsdGljYXN0IG1vZGVscy4KClRoZSBzY29wZSBv ZiB3b3JrIHdpbGwgYmUgbGltaXRlZCB0byBncm91cCBtYW5hZ2VtZW50IGFu ZCBtb2JpbGUgSVAgcHJvdG9jb2xzIC0gcHJveGllZCBvciBjbGllbnQtYmFz ZWQuIFdvcmsgcmVxdWlyaW5nIG1vZGlmaWNhdGlvbnMgb2YgbXVsdGljYXN0 IHJvdXRpbmcgcHJvdG9jb2xzIChQSU0tU00sIFBJTS1ETSwgZXRjLikgaXMg b3V0IG9mIHNjb3BlLiBTcGVjaWZpYyBnb2FscyBhcmU6CiAgCi0gU3BlY2lm eSBQTUlQdjYgZXh0ZW5zaW9ucyB0byBzdXBwb3J0IElQdjYgbXVsdGljYXN0 IGluY2x1ZGluZyByZW1vdGUgc3Vic2NyaXB0aW9uIGFuZCBmYXN0IGhhbmRv dmVyLiANCi0gU3BlY2lmeSBJR01QL01MRCBleHRlbnNpb25zIG1ldGhvZHMg Zm9yIHJlZHVjaW5nIGpvaW4vbGVhdmUgbGF0ZW5jeS4KLSBTcGVjaWZ5IGEg ZG9ybWFudCBtb2RlIG9wZXJhdGlvbiBmb3IgSUdNUHYzL01MRHYyLg0KLSBQ cm92aWRlIGd1aWRhbmNlIGFuZCBzcGVjaWZ5IG1ldGhvZHMgZm9yIG11bHRp LWhvbWluZyBzdXBwb3J0IGZvciBtdWx0aWNhc3QuDQoKVW5pY2FzdCBtb2Jp bGl0eSBwcm90b2NvbHMgKE1vYmlsZSBJUHY2LCBEdWFsLVN0YWNrIE1vYmls ZSBJUHY2IGFuZCBhbHNvIE1vYmlsZSBJUHY0KSBwcm92aWRlIGJhc2ljIG11 bHRpY2FzdCBzdXBwb3J0IGFuZCBlbmFibGUgbW9iaWxlIG5vZGVzIHRvIHBl cmZvcm0gYmktZGlyZWN0aW9uYWwgdHVubmVsaW5nIGFuZCByZWNlaXZlIG11 bHRpY2FzdCB0cmFmZmljIGFuY2hvcmVkIGF0IHRoZSBob21lIGFnZW50LiBI b3dldmVyLCBzdWNoIGJhc2ljIHN1cHBvcnQgc3VmZmVycyBmcm9tIHRoZSAn YXZhbGFuY2hlJyBwcm9ibGVtIGFzIHRoZSBob21lIGFnZW50cyByZXBsaWNh dGUgdGhlIHBhY2tldHMgYW5kIHVuaWNhc3QgdGhlbSB0byB0aGUgbW9iaWxl IG5vZGVzIGFzIHdlbGwgYXMgZnJvbSBub24tb3B0aW1hbCwgdHJpYW5ndWxh ciByb3V0aW5nLCAncmVtb3RlIHN1YnNjcmlwdGlvbicgc3VmZmVycyBmcm9t IHBvc3NpYmxlIGxvc3Mgb2YgZGF0YSBkdXJpbmcgaGFuZG92ZXJzLiBUaGUg V0cgd2lsbCBhZGRyZXNzIHRoZXNlIGlzc3VlcyB3aXRoaW4gdGhlIGNvbnRl eHQgb2YgUHJveHkgTW9iaWxlIElQdjYgKFBNSVB2NikuCgpDdXJyZW50bHkg UE1JUHY2IChhbmQgbW9iaWxpdHkgZXh0ZW5zaW9uIHByb3RvY29scyBsaWtl ICBGTUlQdjYgYW5kIEhNSVB2NikgZG9lcyBub3QgIHN1cHBvcnQgbXVsdGlj YXN0aW5nIGV4cGxpY2l0bHkuIEJhc2ljIHN1cHBvcnQgZm9yIG11bHRpY2Fz dCB3aXRoIGJpLWRpcmVjdGlvbmFsIHR1bm5lbGluZyB3aWxsIGJlIGRvY3Vt ZW50ZWQgZm9yIFBNSVB2NiAod2l0aCBubyBuZXcgbWVzc2FnZSB0eXBlcyBv ciAgY2hhbmdlcyB0byB0aGUgbWVzc2FnZSBwYXJhbWV0ZXJzKS4gUE1JUHY2 IHRoYXQgaGFuZGxlcyBJUHY0IGFuZCBJUHY2IHdpbGwgYmUgZXh0ZW5kZWQg dG8gYWxzbyBzdXBwb3J0IG11bHRpY2FzdGluZyB3aXRoIElQdjQuIEZpbmFs bHksIFBNSVB2NiBiYXNpYyBtdWx0aWNhc3Qgc3VwcG9ydCB3aWxsIGJlIGV4 dGVuZGVkIHRvIHN1cHBvcnQgcmVtb3RlIHN1YnNjcmlwdGlvbiBhbmQgZmFz dCBoYW5kb3Zlci4KCk11bHRpbW9iIHdpbGwgc3BlY2lmeSBhIHNldCBvZiBl eHRlbnNpb25zIHRvIElHTVB2My9NTER2MiBmb3IgbW9iaWxlIGVudmlyb25t ZW50cy4gSUdNUHYzL01MRHYyIGhhcyBiZWVuIHNwZWNpZmllZCBmb3Igd2ly ZWQgbmV0d29ya3Mgd2l0aCBzaGFyZWQgbGlua3MuIE1vYmlsZSBub2RlcyBh bHNvIGhhdmUgb3RoZXIgbmVlZHMgKGUuZy4gIGVudGVyaW5nIGEgZG9ybWFu dCBtb2RlIHRvIGNvbnNlcnZlIGJhdHRlcnkgcG93ZXIsIG1pbmltaXNpbmcg dGhlIGxhdGVuY3kgZm9yIGpvaW5pbmcgYW5kIGxlYXZpbmcgYSBncm91cCBp biBzdXBwb3J0IG9mIG1vdmVtZW50KS4gIFRoZSB3b3JraW5nIGdyb3VwIHdp bGwgYXNzZXNzIGV4aXN0aW5nIHNvbHV0aW9ucyBmb3IgZ3JvdXAgbWFuYWdl bWVudCwgYW5kIGRldGVybWluZSBpZiB0aGVzZSBtZXRob2RzIGFyZSBzdWZm aWNpZW50LiBUaGlzIHdpbGwgaW5jbHVkZSBkZWZpbmluZyBiZXN0IGN1cnJl bnQgcHJhY3RpY2UgZm9yIHNlbGVjdGlvbiBvZiB0aW1lciB2YWx1ZXMgYW5k IHByb3RvY29sIHBhcmFtZXRlcnMuIElmIHRoZXNlIG1ldGhvZHMgYXJlIG5v dCBzdWZmaWNpZW50LCB0aGUgd29ya2luZyBncm91cCBzaGFsbCBwcm9wb3Nl IG5ldyBzb2x1dGlvbnMgYXMgdXBkYXRlcyB0byBleGlzdGluZyBwcm90b2Nv bHMgKGluY2x1ZGluZyBwb3NzaWJsZSBpbnRyb2R1Y3Rpb24gb2YgYWRkaXRp b25hbCBtZXNzYWdlIHR5cGVzKS4gSXQgaXMgYSBnb2FsIGZvciB0aGUgd29y a2luZyBncm91cCB0byBlbnN1cmUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3 aXRoIHRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9ucyBvZiBncm91cCBtYW5h Z2VtZW50IHByb3RvY29scy4gTWVzc2FnZSBzdHJ1Y3R1cmVzIHN1cHBvcnRl ZCBpbiBjdXJyZW50IGRlcGxveWVkIG5ldHdvcmtzIHdpbGwgbm90IGJlIG1v ZGlmaWVkLg0KDQpBIG11bHRpLWhvbWVkIG1vYmlsZSBub2RlIG1heSB3aXNo IHRvIGpvaW4gbXVsdGljYXN0IGdyb3VwcyBhbmQgdG8gZGlyZWN0IGRpZmZl cmVudCBtdWx0aWNhc3QgZmxvd3MgdG8gaXRzIGludGVyZmFjZXMuIFRoZSB3 b3JraW5nIGdyb3VwIHdpbGwgZGVmaW5lIG11bHRpLWhvbWluZyBzdXBwb3J0 IGZvciBtdWx0aWNhc3QsIGluY2x1ZGluZyBhbiBlZmZpY2llbnQgcGVyLWlu dGVyZmFjZSBzdWJzY3JpcHRpb24gbWFuYWdlbWVudCBpbiB0aGUgY2FzZSBv ZiBtdWx0aS1ob21lZCBtb2JpbGl0eSBhbmQgbXVsdGljYXN0IGZsb3cgYmlu ZGluZy4gCg0KSW4gcGVyZm9ybWluZyB0aGlzIHdvcmssIHRoZSBNdWx0aW1v YiB3b3JraW5nIGdyb3VwIHdpbGwgd29yayBjbG9zZWx5IHdpdGggTkVUTE1N DQp3b3JraW5nIGdyb3VwIGFuZCB3aWxsIGNvb3JkaW5hdGUgd29yayBvbiBJ R01QL01MRCBleHRlbnNpb25zIHdpdGggdGhlIE1CT05FRCB3b3JraW5nIGdy b3VwLg0KDQpHT0FMUyBhbmQgTUlMRVNUT05FUzoNCg0Kc2l4IG1vbnRoczog DQoKLSBTdWJtaXQgYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudCBleHBsYWlu aW5nIHRoZSB1c2Ugb2YgbXVsdGljYXN0IGluIFBNSVB2Ni4NCg0KT25lIHll YXI6IA0KLSBTdWJtaXQgYSBkb2N1bWVudCBvbiBleHRlbnNpb25zIGZvciBt dWx0aWNhc3QgbW9iaWxpdHkgaW4gUE1JUHY2IGFzIGFuIEVYUC9QUyBSRkMu DQotIFN1Ym1pdCBhIEJDUCBkb2N1bWVudCBvbiBob3cgdG8gdHVuZSBNTEQg YmVzdCBpbiB3aXJlbGVzcyBkb21haW5zIGFuZCBtb2JpbGUgcmVnaW1lcy4N Cg0KUmVjaGFydGVyIG9yIGNsb3NlIHdvcmtpbmcgZ3JvdXAuCg== --0-929907059-1245683171=:93816-- From gorry@erg.abdn.ac.uk Mon Jun 22 08:42:53 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99C3628C17C for ; Mon, 22 Jun 2009 08:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 425ut5YX8oly for ; Mon, 22 Jun 2009 08:42:52 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id BE75C3A68FA for ; Mon, 22 Jun 2009 08:42:51 -0700 (PDT) Received: from dhcp-207-151.erg.abdn.ac.uk (dhcp-207-151.erg.abdn.ac.uk [139.133.207.151]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n5MFgwIG021502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 22 Jun 2009 16:42:59 +0100 (BST) Message-ID: <4A3FA683.3010908@erg.abdn.ac.uk> Date: Mon, 22 Jun 2009 16:42:59 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: multimob@ietf.org References: <692113.93816.qm@web111405.mail.gq1.yahoo.com> In-Reply-To: <692113.93816.qm@web111405.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 15:42:53 -0000 Hi Bechet, Just to be clear, this is NOT YET the charter of the group. The draft you posted was for comment by people with some ideas to improve the charter. I'd also welcome thoughts on whether we have the current charter and milestones correct. The current approved charter for the BoF is at: http://www.arkko.com/ietf/ietf-75/multimob/charter.txt My own take would be that the Charter text was OK. However, I would like to see the milestones updated. Here are my suggestions: Six months: - Submit a document on minimal deployment for PMIPv6 remote subscription for multicast as a BCP RFC One year: - Submit a document on tuning of IGMP/MLD in mobile multicast mobility as a BCP RFC. - Submit a document on IGMP/MLD extensions for multicast mobility as an EXP/PS RFC. - Submit a document on extensions for multicast mobility in PMIPv6 as an EXP/PS RFC. - Submit a document on multihoming requirements for multicast as a INFO RFC. As a co-Chair, I would be *REALLY* interested on views on the last item above, to understand whether people there is a need for this document and whether it is realistic to see this work completed by a WGLC one year after this work is started. Thoughts welcome, either sent to the chairs (cc us both) or via the list. Gorry Fairhurst (as Co-Chair) Behcet Sarikaya wrote: > Hello Folks, > This is the latest charter I have. Please comment. > > Regards, > > Behcet > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Mon Jun 22 09:01:49 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EAD23A6DF8 for ; Mon, 22 Jun 2009 09:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PElCEIBZIPG9 for ; Mon, 22 Jun 2009 09:01:48 -0700 (PDT) Received: from n77.bullet.mail.sp1.yahoo.com (n77.bullet.mail.sp1.yahoo.com [98.136.44.45]) by core3.amsl.com (Postfix) with SMTP id 4BBDC3A6943 for ; Mon, 22 Jun 2009 09:01:48 -0700 (PDT) Received: from [216.252.122.219] by n77.bullet.mail.sp1.yahoo.com with NNFMP; 22 Jun 2009 16:02:02 -0000 Received: from [67.195.9.81] by t4.bullet.sp1.yahoo.com with NNFMP; 22 Jun 2009 16:02:02 -0000 Received: from [67.195.9.104] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 22 Jun 2009 16:02:02 -0000 Received: from [127.0.0.1] by omp108.mail.gq1.yahoo.com with NNFMP; 22 Jun 2009 16:02:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 28884.50915.bm@omp108.mail.gq1.yahoo.com Received: (qmail 64660 invoked by uid 60001); 22 Jun 2009 16:02:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245686521; bh=zANwXsBNx9hrsmS3LH7S3blK1JtDssOCtSY0KOExAUE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CFqJOHyYO3EvV//IrU+TzouBBcGqjkbytF8v6q4YxEjda4CZRzMzrLYqFl8zhW/1B+kcBfmzSEkM6bGl5H8/OphpHjkVVT1EpLZfUVijnmsDpijQhKqxNThpp38/Ni3+Zvq4zEZM3L20lzHTA6rx2Ihv1bteF41RT3NmvtOtg+8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Bn/eK5DRvCKWQsQspdaPMhSsAz+959KSDNfCv+VDNpk8ePmkH5ANCRQ+l3Let2fVXDhVjmn6A0NgUS+MlJB9xsi78d587tVMC0GDfHepOYEPFjsYeA7S0UDBE9c6bzGtMVxcSHLPIl6Utj3+jttXeuLbPm6HT1Bfa08NuvDap4I=; Message-ID: <856610.64478.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: WR7hUCwVM1mju.903e_QVLg6MMzAXZ8E1GumXUSfl1F5hUJIzz8.ITwk01YwbgUzk43ignyHqLmoLCHuPib8oNCnIzatNIC2aR5rHBoofsWWGinSFs1jQkf8E2ohvka1Y9iyuBfq9gAIjT.LRK_6xerXVCAzxXrdVY.cZh59P3OletqzaTCNBqdUPBhyig3ZJyT7uIfoqh4FvzMvMmKLbEMTRF0mDyMYsNv7jUG6OMofjgrOKyJEM3pIrCMpvS07q8Ox_r_KBnzHAi_24PD75F4lesPE4_HEUBHLhNrE2pZwKtEJreIZ6La9E5cpf5U37heY_U9gCFHFcHG0odmxAeGsPQ-- Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Mon, 22 Jun 2009 09:02:01 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 References: <692113.93816.qm@web111405.mail.gq1.yahoo.com> <4A3FA683.3010908@erg.abdn.ac.uk> Date: Mon, 22 Jun 2009 09:02:01 -0700 (PDT) From: Behcet Sarikaya To: gorry@erg.abdn.ac.uk, multimob@ietf.org In-Reply-To: <4A3FA683.3010908@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 16:01:49 -0000 Hi Gorry,=0A=A0 Yes, this is a draft and the idea is to keep discussing it = on the list. We will post the latest one when IETF BoF page is on.=0A=0AYes= , I agree that we should concentrate on the milestones, so please use the l= ist below rather than repeat the whole charter text.=0A=0ARegards,=0A=0ABeh= cet=0A=0A----- Original Message ----=0A> From: Gorry Fairhurst =0A> To: multimob@ietf.org=0A> Cc: Behcet Sarikaya =0A> Sent: Monday, June 22, 2009 10:42:59 AM=0A> Subject: Re: [multimo= b] Charter discussion=0A> =0A> =0A> Hi Bechet,=0A> =0A> Just to be clear, t= his is NOT YET the charter of the group. The draft you posted =0A> was for = comment by people with some ideas to improve the charter. I'd also =0A> wel= come thoughts on whether we have the current charter and milestones correct= ..=0A> =0A> The current approved charter for the BoF is at:=0A> http://www.a= rkko.com/ietf/ietf-75/multimob/charter.txt=0A> =0A> =0A> My own take would = be that the Charter text was OK. However, I would like to see =0A> the mile= stones updated. Here are my suggestions:=0A> =0A> Six months:=0A> - Submit = a document on minimal deployment for PMIPv6 remote subscription for =0A> mu= lticast as a BCP RFC=0A> =0A> One year:=0A> - Submit a document on tuning o= f IGMP/MLD in mobile multicast mobility as a BCP =0A> RFC.=0A> - Submit a d= ocument on IGMP/MLD extensions for multicast mobility as an EXP/PS =0A> RFC= ..=0A> - Submit a document on extensions for multicast mobility in PMIPv6 as= an EXP/PS =0A> RFC.=0A> - Submit a document on multihoming requirements fo= r multicast as a INFO RFC.=0A> =0A> As a co-Chair, I would be *REALLY* inte= rested on views on the last item above, =0A> to understand whether people t= here is a need for this document and whether it is =0A> realistic to see th= is work completed by a WGLC one year after this work is =0A> started.=0A> = =0A> Thoughts welcome, either sent to the chairs (cc us both) or via the li= st.=0A> =0A> Gorry Fairhurst=0A> (as Co-Chair)=0A> =0A> Behcet Sarikaya wro= te:=0A> > Hello Folks,=0A> >=A0 This is the latest charter I have. Please c= omment. =0A> > Regards,=0A> > =0A> > Behcet=0A> > =0A> > =0A> >=A0 =A0 =A0 = =0A> > =0A> > -------------------------------------------------------------= -----------=0A> > =0A> > _______________________________________________=0A= > > multimob mailing list=0A> > multimob@ietf.org=0A> > https://www.ietf.or= g/mailman/listinfo/multimob=0A=0A=0A=0A From asaeda@sfc.wide.ad.jp Mon Jun 22 09:18:22 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED043A6DD4 for ; Mon, 22 Jun 2009 09:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.147 X-Spam-Level: *** X-Spam-Status: No, score=3.147 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DJE5RnR76NC for ; Mon, 22 Jun 2009 09:18:22 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 0855B28C1E9 for ; Mon, 22 Jun 2009 09:18:21 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 6BBDE13D06C8 for ; Tue, 23 Jun 2009 01:18:35 +0900 (JST) Date: Tue, 23 Jun 2009 01:18:41 +0900 (JST) Message-Id: <20090623.011841.91342214.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <4A3FA683.3010908@erg.abdn.ac.uk> References: <692113.93816.qm@web111405.mail.gq1.yahoo.com> <4A3FA683.3010908@erg.abdn.ac.uk> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 16:18:22 -0000 Hi, > Six months: > - Submit a document on minimal deployment for PMIPv6 remote > subscription for multicast as a BCP RFC I may just drop some discussion in this ML, but what does the "minimal" deployment for "remote" subscription mean? I remember there was some discussion about home subscription (or bi-directional tunneling method) for forwarding multicast data without any protocol modification. Doesn't this statement mean it? > - Submit a document on multihoming requirements for multicast as a INFO RFC. > > As a co-Chair, I would be *REALLY* interested on views on the last > item above, to understand whether people there is a need for this > document and whether it is realistic to see this work completed by a > WGLC one year after this work is started. It is not only for mobility, too. I think describing multihoming support should not be included in the initial charter for this group. Clarifying multihoming "requirement" may not be a bad idea, but, well, in any case multihoming related stuff is not the primary work of this group, I guess. One question. Previously we agreed to describe "problem statement" drafts and "requirement" drafts for both IGMP/MLD and PMIPv6 stuff. They are not needed any more? If yes, why? I think clarifying problem statement is at least necessary. Regards, -- Hitoshi Asaeda From schmidt@fhtw-berlin.de Mon Jun 22 11:10:12 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0280628C24A for ; Mon, 22 Jun 2009 11:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJhemLKWoo89 for ; Mon, 22 Jun 2009 11:10:09 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 4F9EC28C278 for ; Mon, 22 Jun 2009 11:09:07 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [213.63.26.26] (helo=[192.168.48.203]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MInxJ-0008lT-9c; Mon, 22 Jun 2009 20:09:21 +0200 Message-ID: <4A3FC8CB.8070405@fhtw-berlin.de> Date: Mon, 22 Jun 2009 20:09:15 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <692113.93816.qm@web111405.mail.gq1.yahoo.com> <4A3FA683.3010908@erg.abdn.ac.uk> In-Reply-To: <4A3FA683.3010908@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 18:10:12 -0000 Hi Gorry, I pretty much agree with the charter and modified list of milestones below. In particular, it sounds reasonable to move multihoming out of the first 6 month. There might be also interest to treat mobility protocols other than PMIP. Regarding problem-statements/ requirement drafts: I suppose, a general problem statement is not needed (but there). Specific requirements drafts have been around (and should be improved), but will not be needed for the initial BCP-type of activities: requirements here are obvious as given from the related specs in mcast and mobility. Best regards, Thomas Gorry Fairhurst wrote: > > Hi Bechet, > > Just to be clear, this is NOT YET the charter of the group. The draft > you posted was for comment by people with some ideas to improve the > charter. I'd also welcome thoughts on whether we have the current > charter and milestones correct. > > The current approved charter for the BoF is at: > http://www.arkko.com/ietf/ietf-75/multimob/charter.txt > > > My own take would be that the Charter text was OK. However, I would like > to see the milestones updated. Here are my suggestions: > > Six months: > - Submit a document on minimal deployment for PMIPv6 remote subscription > for multicast as a BCP RFC > > One year: > - Submit a document on tuning of IGMP/MLD in mobile multicast mobility > as a BCP RFC. > - Submit a document on IGMP/MLD extensions for multicast mobility as an > EXP/PS RFC. > - Submit a document on extensions for multicast mobility in PMIPv6 as an > EXP/PS RFC. > - Submit a document on multihoming requirements for multicast as a INFO > RFC. > > As a co-Chair, I would be *REALLY* interested on views on the last item > above, to understand whether people there is a need for this document > and whether it is realistic to see this work completed by a WGLC one > year after this work is started. > > Thoughts welcome, either sent to the chairs (cc us both) or via the list. > > Gorry Fairhurst > (as Co-Chair) > > Behcet Sarikaya wrote: >> Hello Folks, >> This is the latest charter I have. Please comment. >> Regards, >> >> Behcet >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From xiayangsong@huawei.com Mon Jun 22 12:24:20 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51E183A6981 for ; Mon, 22 Jun 2009 12:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlT612XcsvG4 for ; Mon, 22 Jun 2009 12:24:19 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E3DC73A684A for ; Mon, 22 Jun 2009 12:24:18 -0700 (PDT) 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 <0KLN00EEWN8OIZ@szxga04-in.huawei.com> for multimob@ietf.org; Tue, 23 Jun 2009 03:24:24 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLN0093TN8OGL@szxga04-in.huawei.com> for multimob@ietf.org; Tue, 23 Jun 2009 03:24:24 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLN00281N8H0C@szxml04-in.huawei.com> for multimob@ietf.org; Tue, 23 Jun 2009 03:24:23 +0800 (CST) Date: Mon, 22 Jun 2009 14:24:16 -0500 From: Frank Xia To: "Thomas C. Schmidt" , gorry@erg.abdn.ac.uk Message-id: <004a01c9f36f$0ca18080$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <692113.93816.qm@web111405.mail.gq1.yahoo.com> <4A3FA683.3010908@erg.abdn.ac.uk> <4A3FC8CB.8070405@fhtw-berlin.de> Cc: multimob@ietf.org Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 19:24:20 -0000 Hi Guys Mostly I am fine with the charter. However, it would be better to remove multihoming work from first 6 month work. IMO, getting multimob approved is our common goal, and starting small is probably a good strategy. BR Frank ----- Original Message ----- From: "Thomas C. Schmidt" To: Cc: Sent: Monday, June 22, 2009 1:09 PM Subject: Re: [multimob] Charter discussion > Hi Gorry, > > I pretty much agree with the charter and modified list of milestones > below. In particular, it sounds reasonable to move multihoming out of the > first 6 month. There might be also interest to treat mobility protocols > other than PMIP. > > Regarding problem-statements/ requirement drafts: I suppose, a general > problem statement is not needed (but there). Specific requirements drafts > have been around (and should be improved), but will not be needed for the > initial BCP-type of activities: requirements here are obvious as given > from the related specs in mcast and mobility. > > Best regards, > > Thomas > > Gorry Fairhurst wrote: >> >> Hi Bechet, >> >> Just to be clear, this is NOT YET the charter of the group. The draft you >> posted was for comment by people with some ideas to improve the charter. >> I'd also welcome thoughts on whether we have the current charter and >> milestones correct. >> >> The current approved charter for the BoF is at: >> http://www.arkko.com/ietf/ietf-75/multimob/charter.txt >> >> >> My own take would be that the Charter text was OK. However, I would like >> to see the milestones updated. Here are my suggestions: >> >> Six months: >> - Submit a document on minimal deployment for PMIPv6 remote subscription >> for multicast as a BCP RFC >> >> One year: >> - Submit a document on tuning of IGMP/MLD in mobile multicast mobility as >> a BCP RFC. >> - Submit a document on IGMP/MLD extensions for multicast mobility as an >> EXP/PS RFC. >> - Submit a document on extensions for multicast mobility in PMIPv6 as an >> EXP/PS RFC. >> - Submit a document on multihoming requirements for multicast as a INFO >> RFC. >> >> As a co-Chair, I would be *REALLY* interested on views on the last item >> above, to understand whether people there is a need for this document and >> whether it is realistic to see this work completed by a WGLC one year >> after this work is started. >> >> Thoughts welcome, either sent to the chairs (cc us both) or via the list. >> >> Gorry Fairhurst >> (as Co-Chair) >> >> Behcet Sarikaya wrote: >>> Hello Folks, >>> This is the latest charter I have. Please comment. >>> Regards, >>> >>> Behcet >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> multimob mailing list >>> multimob@ietf.org >>> https://www.ietf.org/mailman/listinfo/multimob >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Mon Jun 22 14:23:52 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48333A6898 for ; Mon, 22 Jun 2009 14:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0GXguTxDcSL for ; Mon, 22 Jun 2009 14:23:52 -0700 (PDT) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id E76C93A672F for ; Mon, 22 Jun 2009 14:23:51 -0700 (PDT) Received: (qmail 98307 invoked by uid 60001); 22 Jun 2009 21:24:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245705840; bh=IrDUE86IoHfyz4PCMH27iicWne7O33/uH5fRAH7b9xk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=srMgJKifgjUnNzVU1ZNESYUOJ6H7vw4hJADdjOyF8qnpcXshUnk6ISmpWxNe3PBB8Ky3vZab/YLChcf2ulbERDX1pYx1orhsOinJm4WQSNkjZ7LfeX4fKpu5rGVAdva4Kc4RmM5v3ndltQbsejyW4PG7oCGqPLAUc50t6qBXGDE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=5kLp8LV4iqPrVk/lAcsQz9/VqVjM6LdRFPr6px/pRvf/AsTsO1acbD9/BmOS7Ikj+7OnJAPHkD/hcBO/3AldKcuGgBpYdp64OzMoSPrbWC/QvgNdi2LqKNYUOVtZU8+XK65/Aqgpt6VX/7/92DOZrWsYFjzm+rQkPpQHMd4amrE=; Message-ID: <513081.97456.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: 9cn.ymoVM1nhcF0OKwT4fVkNUUImPHTkNgy3GCuxt35dp48cR2bBpEBZXenyRdTrCK.S1IYau.Vq_WmhW8VpicxpgGgBbpdDc2g_cy6f15kL.kzSr34pvPI3TyI2dRlaa4o1SeePEGxdRHKwlqNZUvayrre451BVjmJI0ysmBiO7t5yu..xcZppGhhIp7XgtaN4b8PI6fla_ffOLxao71IFL1CwS1cpuAn_6ozgOwt3w3ZLIDYdTVoSwhiXMLP_3aQoSV3KPr2wmB9EH2Q8HfjhsNJTD7QOYR8nWHFtdzm9YioW0vAE6Ogb3qCPTobxmmLPn4zRGqU6kpchz3Lo8gs09FQ-- Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Mon, 22 Jun 2009 14:24:00 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 References: <692113.93816.qm@web111405.mail.gq1.yahoo.com> <4A3FA683.3010908@erg.abdn.ac.uk> <4A3FC8CB.8070405@fhtw-berlin.de> Date: Mon, 22 Jun 2009 14:24:00 -0700 (PDT) From: Behcet Sarikaya To: "Thomas C. Schmidt" , gorry@erg.abdn.ac.uk In-Reply-To: <4A3FC8CB.8070405@fhtw-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 21:23:53 -0000 ----- Original Message ---- > From: Thomas C. Schmidt > To: gorry@erg.abdn.ac.uk > Cc: multimob@ietf.org > Sent: Monday, June 22, 2009 1:09:15 PM > Subject: Re: [multimob] Charter discussion > > Hi Gorry, > > I pretty much agree with the charter and modified list of milestones below. In > particular, it sounds reasonable to move multihoming out of the first 6 month. > There might be also interest to treat mobility protocols other than PMIP. > > Regarding problem-statements/ requirement drafts: I suppose, a general problem > statement is not needed (but there). Specific requirements drafts have been > around (and should be improved), but will not be needed for the initial BCP-type > of activities: requirements here are obvious as given from the related specs in > mcast and mobility. Yes, specific requirements draft like: http://ietfreport.isoc.org/all-ids/draft-deng-multimob-pmip6-requirement-01.txt http://ietfreport.isoc.org/all-ids/draft-liu-multimob-igmp-mld-mobility-req-01.txt need to be improved, the authors, please post a revised version and let us know. Regards, Behcet From asaeda@sfc.wide.ad.jp Mon Jun 22 20:10:35 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1B5F3A680F for ; Mon, 22 Jun 2009 20:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAUsBD4RLKWQ for ; Mon, 22 Jun 2009 20:10:35 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id EDA123A67F8 for ; Mon, 22 Jun 2009 20:10:34 -0700 (PDT) Received: from localhost (dhcp-143-182.sfc.wide.ad.jp [203.178.143.182]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 9045113D06C8 for ; Tue, 23 Jun 2009 12:10:49 +0900 (JST) Date: Tue, 23 Jun 2009 12:10:49 +0900 (JST) Message-Id: <20090623.121049.129769176.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <4A3FC8CB.8070405@fhtw-berlin.de> References: <692113.93816.qm@web111405.mail.gq1.yahoo.com> <4A3FA683.3010908@erg.abdn.ac.uk> <4A3FC8CB.8070405@fhtw-berlin.de> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 03:10:35 -0000 > Regarding problem-statements/ requirement drafts: I suppose, a general > problem statement is not needed (but there). What is "general" problem? And why do you think problem statement is not needed? I wonder the same discussion will come up again and again, "why multicast support for mobility should be discussed and why multicast does not properly work with mobility protocol, say PMIPv6?". If people already shared the problems and have the concensus of multimob work, then the problem statement draft wouldn't be necessary. I've thought the reason why many people always doubt multimob work is that there is no good problem statement draft to answer the question. > Specific requirements > drafts have been around (and should be improved), but will not be > needed for the initial BCP-type of activities: Why you assume "BCP" here? > requirements here are > obvious as given from the related specs in mcast and mobility. If requirements were obvious, the requirements draft wouldn't be needed. I've just suspected it. Regards, -- Hitoshi Asaeda From liuhui47967@huawei.com Mon Jun 22 23:22:43 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E4128C27A for ; Mon, 22 Jun 2009 23:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epK6LVNs309i for ; Mon, 22 Jun 2009 23:22:42 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 8850F3A68A5 for ; Mon, 22 Jun 2009 23:22:42 -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 <0KLO00BJ2HQ8E4@szxga03-in.huawei.com> for multimob@ietf.org; Tue, 23 Jun 2009 14:22:56 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLO000FEHQ77C@szxga03-in.huawei.com> for multimob@ietf.org; Tue, 23 Jun 2009 14:22:55 +0800 (CST) Received: from l47967b ([10.111.12.139]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLO0086OHQ73R@szxml06-in.huawei.com> for multimob@ietf.org; Tue, 23 Jun 2009 14:22:55 +0800 (CST) Date: Tue, 23 Jun 2009 14:22:55 +0800 From: Liu Hui In-reply-to: <513081.97456.qm@web111407.mail.gq1.yahoo.com> To: 'Behcet Sarikaya' , "'Thomas C. Schmidt'" , gorry@erg.abdn.ac.uk Message-id: <000101c9f3cb$0bd949b0$8b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-index: Acnzf9BtemTmFBGoSVWf7q7WEAUPTgASdP8g Cc: multimob@ietf.org Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 06:22:43 -0000 Hi all, We authors will try to improve the "igmp requirement draft" below before this meeting. For the discussed charter, 'start small' is a good policy that we should follow, but before we decide what proper specific things to start from, some general analysis may also be needed. For without the comprehensive view, how can we tell the value of each specific solution? For most drafts contributed to multimob, they must have their standpoints and their wits. But, do they solve a real problem? Can they be merged into the multicast mobility architecture? Are they a good solution to solve the problem? And finally, do they deserve being published as an RFC? Before answering these questions, at least a general picture should be depicted in our mind and be agreed beforehand. I have no negative viewpoint against the charter. I suggest before we decide a final version, some general discussions on the list may be helpful both for clarification and for quality improvement. Best Regards, Liu Hui > -----Original Message----- > From: multimob-bounces@ietf.org > [mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya > Sent: Tuesday, June 23, 2009 5:24 AM > To: Thomas C. Schmidt; gorry@erg.abdn.ac.uk > Cc: multimob@ietf.org > Subject: Re: [multimob] Charter discussion > > > ----- Original Message ---- > > From: Thomas C. Schmidt > > To: gorry@erg.abdn.ac.uk > > Cc: multimob@ietf.org > > Sent: Monday, June 22, 2009 1:09:15 PM > > Subject: Re: [multimob] Charter discussion > > > > Hi Gorry, > > > > I pretty much agree with the charter and modified list of > milestones > > below. In particular, it sounds reasonable to move > multihoming out of the first 6 month. > > There might be also interest to treat mobility protocols > other than PMIP. > > > > Regarding problem-statements/ requirement drafts: I > suppose, a general > > problem statement is not needed (but there). Specific requirements > > drafts have been around (and should be improved), but will not be > > needed for the initial BCP-type of activities: requirements > here are > > obvious as given from the related specs in mcast and mobility. > > Yes, specific requirements draft like: > http://ietfreport.isoc.org/all-ids/draft-deng-multimob-pmip6-r > equirement-01.txt > http://ietfreport.isoc.org/all-ids/draft-liu-multimob-igmp-mld > -mobility-req-01.txt > > need to be improved, the authors, please post a revised > version and let us know. > > Regards, > > Behcet > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From schmidt@informatik.haw-hamburg.de Tue Jun 23 03:28:25 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF393A6E8C for ; Tue, 23 Jun 2009 03:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZCT0Vjg6FVn for ; Tue, 23 Jun 2009 03:28:24 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 36EE93A6E64 for ; Tue, 23 Jun 2009 03:28:23 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [193.136.207.214] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MJ3Ex-000GD8-4E; Tue, 23 Jun 2009 12:28:37 +0200 Message-ID: <4A40AE45.3050905@informatik.haw-hamburg.de> Date: Tue, 23 Jun 2009 12:28:21 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hitoshi Asaeda References: <692113.93816.qm@web111405.mail.gq1.yahoo.com> <4A3FA683.3010908@erg.abdn.ac.uk> <4A3FC8CB.8070405@fhtw-berlin.de> <20090623.121049.129769176.asaeda@sfc.wide.ad.jp> In-Reply-To: <20090623.121049.129769176.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 10:28:26 -0000 Hi Hitoshi, Hitoshi Asaeda wrote: >> Regarding problem-statements/ requirement drafts: I suppose, a general >> problem statement is not needed (but there). > > What is "general" problem? I don't know: I spoke about a "general problem statement" regarding multicast mobility. > And why do you think problem statement is not needed? Because it's there: http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps > > I wonder the same discussion will come up again and again, "why > multicast support for mobility should be discussed and why multicast > does not properly work with mobility protocol, say PMIPv6?". > If people already shared the problems and have the concensus of > multimob work, then the problem statement draft wouldn't be necessary. > I've thought the reason why many people always doubt multimob work is > that there is no good problem statement draft to answer the question. > >> Specific requirements >> drafts have been around (and should be improved), but will not be >> needed for the initial BCP-type of activities: > > Why you assume "BCP" here? Because it is written in the charter / in the list Gorry sent. > >> requirements here are >> obvious as given from the related specs in mcast and mobility. > > If requirements were obvious, the requirements draft wouldn't be > needed. I've just suspected it. > ??? Unclear what you mean. What I intended to say - and what work I wanted to stimulate: Those items of the charter that are BCP-type of documents do not change specs. In complying to the existing specs, the requirements for this type of work are pretty clearly available. That's why work can easily progress right now. The picture may change once we look at modifying protocols for optimization. Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From asaeda@sfc.wide.ad.jp Tue Jun 23 04:18:03 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0482F28C2BF for ; Tue, 23 Jun 2009 04:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TgNl0CTxopy for ; Tue, 23 Jun 2009 04:18:01 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id B32E728C2AD for ; Tue, 23 Jun 2009 04:18:01 -0700 (PDT) Received: from localhost (dhcp-143-182.sfc.wide.ad.jp [203.178.143.182]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 91DEE13D06C8 for ; Tue, 23 Jun 2009 20:18:16 +0900 (JST) Date: Tue, 23 Jun 2009 20:18:15 +0900 (JST) Message-Id: <20090623.201815.154466603.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <4A40AE45.3050905@informatik.haw-hamburg.de> References: <4A3FC8CB.8070405@fhtw-berlin.de> <20090623.121049.129769176.asaeda@sfc.wide.ad.jp> <4A40AE45.3050905@informatik.haw-hamburg.de> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 11:18:03 -0000 Thomas, >> And why do you think problem statement is not needed? > > Because it's there: > http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps Maybe it does not help making people recognize the problems this multimob group wants to address. It just says many things. It is difficult to understand "what is the real problem?". Ok, then how about improving the following two requirement drafts Behcet said today: > Yes, specific requirements draft like: > http://ietfreport.isoc.org/all-ids/draft-deng-multimob-pmip6-requirement-01.txt > http://ietfreport.isoc.org/all-ids/draft-liu-multimob-igmp-mld-mobility-req-01.txt > > need to be improved, the authors, please post a revised version and > let us know. It is good to clarify also the problems for supporting multicast with PMIPv6 and IGMP/MLD protocols in these drafts, isn't it? >> I wonder the same discussion will come up again and again, "why >> multicast support for mobility should be discussed and why multicast >> does not properly work with mobility protocol, say PMIPv6?". >> If people already shared the problems and have the concensus of >> multimob work, then the problem statement draft wouldn't be necessary. >> I've thought the reason why many people always doubt multimob work is >> that there is no good problem statement draft to answer the question. >> >>> Specific requirements >>> drafts have been around (and should be improved), but will not be >>> needed for the initial BCP-type of activities: >> Why you assume "BCP" here? > > Because it is written in the charter / in the list Gorry sent. Maybe a category of problem statement and requirement draft would be Informational? >>> requirements here are >>> obvious as given from the related specs in mcast and mobility. >> If requirements were obvious, the requirements draft wouldn't be >> needed. I've just suspected it. > > ??? Unclear what you mean. I mean both problem statement and requirement should be clarified in either one or separate drafts (for each target protocol). Regards, -- Hitoshi Asaeda From schmidt@informatik.haw-hamburg.de Tue Jun 23 04:32:31 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B866D28C161 for ; Tue, 23 Jun 2009 04:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUiYRRKM-NtD for ; Tue, 23 Jun 2009 04:32:30 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 9D0A53A691F for ; Tue, 23 Jun 2009 04:32:30 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [193.136.207.214] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MJ4F2-0006mf-Rk; Tue, 23 Jun 2009 13:32:45 +0200 Message-ID: <4A40BD54.5060002@informatik.haw-hamburg.de> Date: Tue, 23 Jun 2009 13:32:36 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hitoshi Asaeda References: <4A3FC8CB.8070405@fhtw-berlin.de> <20090623.121049.129769176.asaeda@sfc.wide.ad.jp> <4A40AE45.3050905@informatik.haw-hamburg.de> <20090623.201815.154466603.asaeda@sfc.wide.ad.jp> In-Reply-To: <20090623.201815.154466603.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 11:32:31 -0000 Hi Hitoshi, Hitoshi Asaeda wrote: >>> And why do you think problem statement is not needed? >> Because it's there: >> http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps > > Maybe it does not help making people recognize the problems this > multimob group wants to address. It just says many things. It is > difficult to understand "what is the real problem?". > I guess you expect me to disagree :-): We consider the major contribution of the PS to bring densely together all the different key aspects of the problem space. This is indeed not a trivial collection and cannot be "easy reading". The problem we had with all the other drafts was a very partial focus that missed major parts of the problems - leading to confusion and also to the diverse positions arising at the previous BoF (remember the wise words of Rajeev). So our argument would be: if you carefully read the PS, the "real" problems of multicast + mobility will be very clear. Details on specific tasks can then be easily derived by just doing transfers. > Ok, then how about improving the following two requirement drafts > Behcet said today: > >> Yes, specific requirements draft like: >> http://ietfreport.isoc.org/all-ids/draft-deng-multimob-pmip6-requirement-01.txt I promised to work on this - however, I would put higher priority on the BCP-type solution for PMIPv6, so I beg some patience. >> http://ietfreport.isoc.org/all-ids/draft-liu-multimob-igmp-mld-mobility-req-01.txt >> We had a volunteer just two mails ago. [...] >>>> Specific requirements >>>> drafts have been around (and should be improved), but will not be >>>> needed for the initial BCP-type of activities: >>> Why you assume "BCP" here? >> Because it is written in the charter / in the list Gorry sent. > > Maybe a category of problem statement and requirement draft would be > Informational? > Yes, I guess so. Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From asaeda@sfc.wide.ad.jp Tue Jun 23 04:49:49 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03B1628C0EB for ; Tue, 23 Jun 2009 04:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1scPZBOjgCj for ; Tue, 23 Jun 2009 04:49:48 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 5CE453A6E67 for ; Tue, 23 Jun 2009 04:49:48 -0700 (PDT) Received: from localhost (dhcp-143-182.sfc.wide.ad.jp [203.178.143.182]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 815F313D06C8 for ; Tue, 23 Jun 2009 20:50:02 +0900 (JST) Date: Tue, 23 Jun 2009 20:50:02 +0900 (JST) Message-Id: <20090623.205002.128870716.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <4A40BD54.5060002@informatik.haw-hamburg.de> References: <4A40AE45.3050905@informatik.haw-hamburg.de> <20090623.201815.154466603.asaeda@sfc.wide.ad.jp> <4A40BD54.5060002@informatik.haw-hamburg.de> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 11:49:49 -0000 > So our argument would be: if you carefully read the PS, the "real" > problems of multicast + mobility will be very clear. Details on > specific tasks can then be easily derived by just doing transfers. I tend to disagree. I cannot imagine one can recognize the real problem after he/she reads the irtf-mobopts-mmcastv6-ps draft. My opinion is that it is good to improve two requirement drafts with clear problem statement. Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Tue Jun 23 13:49:45 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B833A6EEC for ; Tue, 23 Jun 2009 13:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucA3gM1PMej1 for ; Tue, 23 Jun 2009 13:49:44 -0700 (PDT) Received: from n62.bullet.mail.sp1.yahoo.com (n62.bullet.mail.sp1.yahoo.com [98.136.44.35]) by core3.amsl.com (Postfix) with SMTP id 790B23A6C67 for ; Tue, 23 Jun 2009 13:49:44 -0700 (PDT) Received: from [216.252.122.216] by n62.bullet.mail.sp1.yahoo.com with NNFMP; 23 Jun 2009 20:49:59 -0000 Received: from [67.195.9.82] by t1.bullet.sp1.yahoo.com with NNFMP; 23 Jun 2009 20:49:59 -0000 Received: from [67.195.9.103] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 23 Jun 2009 20:49:59 -0000 Received: from [127.0.0.1] by omp107.mail.gq1.yahoo.com with NNFMP; 23 Jun 2009 20:49:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 223528.74422.bm@omp107.mail.gq1.yahoo.com Received: (qmail 25463 invoked by uid 60001); 23 Jun 2009 20:49:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245790196; bh=2cabc11ViKuiJKauqgAcpSvhO8Wpzv/XNKMIwNAYN0s=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ltKqIPrHKvJpyTKLM9ZiW2TKDLPDJc6nmUPTbGszjXwrSpAskbvRJQICqDM3fJ+YZkPZcWxl+xRFyMnS82q6LbtJDUkYxxiI8OYGE9RXhBEwIz9kFpER6vuOZQ7dkXJj9+fEWBM9ERSOW6OWmd4JJwinx38nJPZnoejzpuNRl5c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=yO3pwL1nugEcYYLBfmNkqTvsd4zIc/2V1yIeDC7lBGbIKLbKFcM46BSoFPcvC2yJf40qEj6fqVPJP/XLHaUhlsAFAVdM+SeipiV4x6b9GoMgSEvSifCTLHRk9iUeV5aluuiaUVckBwx1JXlhN1iUTtEPNQihNSnTN4DOQ+VW1sc=; Message-ID: <671114.21633.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: EyfkmhMVM1lPa4jKdlURzNL0tzKpcCiMsMktTOL_SRxqnZYCegnXBGEoeFmYgciUxFCndNenkUL55qK4Pmua1TXGWK.EEBU4BFdlpqzADOeHagYgfAsTUrAfsu2hV4rX7KOimrrLDCj2QhqvJvF9inu_0VxJbBWasJtjDPrf8lJbbNkyBeCLZMBx2KDOOKPVm7UciLo7RPypgHlqpxn7W9g_6rCte8LUWDouFNCLqrByKHZtquWOwR2hQIWO4DD4CUqVbb23JNh4ig8QggJIZvcaOdPF3ZUiroeYc9.eLhEBcOQx3DOJt1P_04m0ldJZwN5YCPxHdaGKh5gFRHnOwYU- Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Tue, 23 Jun 2009 13:49:56 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 References: <4A341991.205@informatik.haw-hamburg.de> <8917F82B-F8AF-4A05-99C1-C0641519FBDE@gmail.com> <4A3A6D6B.9060205@informatik.haw-hamburg.de> <4A3AC076.7070207@informatik.haw-hamburg.de> <945398.87169.qm@web111411.mail.gq1.yahoo.com> <0360C43D-8821-4CA3-B2DE-BACDE1E6F379@gmail.com> <91483.60941.qm@web111413.mail.gq1.yahoo.com> Date: Tue, 23 Jun 2009 13:49:56 -0700 (PDT) From: Behcet Sarikaya To: jouni korhonen In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 20:49:45 -0000 Hi Jouni, ----- Original Message ---- > From: jouni korhonen > To: Behcet Sarikaya > Cc: multimob@ietf.org; Thomas C. Schmidt > Sent: Monday, June 22, 2009 6:31:17 AM > Subject: Re: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00 > > Hi Behcet, > > On Jun 19, 2009, at 5:46 PM, Behcet Sarikaya wrote: > > > > > Hi Jouni, > > > [snip] > > >> tunneled incoming packets are indicated properly so MN should be able to > >> decapsulate them. > >> > >> Indicated properly how? > > > > IP Header Protocol field. There is a value reserved for IP-in-IP > encapsulation. You can check this at: > > http://www.iana.org/assignments/protocol-numbers/ > > > > So MN knows that it received an encapsulated packet. Whether an unmodified MN > can decapsulate such packets and look at the new header and process them as > multicast data, I guess yes, but I am not sure. > > Righty. The "IPIP decapsulation" i.e. the tunnel interface should be clever > enough to figure out this is about multicast traffic and pass the packet to the > proper multicast receiver part in the stack. That is a broad assumption. Here, > GRE could work better than IPIP. There is also another problem. You cannot > assume that the MN has any possibility to find out the LMA Address. For example, > in some architectures that has been purposely prohibited. And how an unmodified > host could tell a difference between LMA Address and any other address? Yes, this is good point. > > Regarding the I-D, it has to be more specific what is actually required from a > MN to receive encapsulated multicast traffic. So far it looks to me that none of > the proposed (encapsulation) methods work out of box in a multicast enabled > host, even if we were not considering configuring (widely deployed) tunnels and > such as a host change. If host changes are in scope, then chances are better but > the I-D must be explicit about that decision then. The amount of additional text > would not be that big imho. What we came up with is to get the decapsulation done at the MAG so that MAG gets MN address and forwards the multicast packet to MN on MAG-MN link. What do you think about it? Regards, Behcet From liuhui47967@huawei.com Tue Jun 23 22:03:40 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57FCD28C41C for ; Tue, 23 Jun 2009 22:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5vsbsyPXKvT for ; Tue, 23 Jun 2009 22:03:35 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C885528C3A3 for ; Tue, 23 Jun 2009 22:03:33 -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 <0KLQ00AOQ8QC96@szxga03-in.huawei.com> for multimob@ietf.org; Wed, 24 Jun 2009 13:03:48 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLQ00DUP8QCQA@szxga03-in.huawei.com> for multimob@ietf.org; Wed, 24 Jun 2009 13:03:48 +0800 (CST) Received: from l47967b ([10.111.12.139]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLQ00MR58QCSP@szxml06-in.huawei.com> for multimob@ietf.org; Wed, 24 Jun 2009 13:03:48 +0800 (CST) Date: Wed, 24 Jun 2009 13:03:47 +0800 From: Liu Hui In-reply-to: <4A3FA683.3010908@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk, multimob@ietf.org Message-id: <000901c9f489$288f59f0$8b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-index: AcnzUCm9n3IF+cWUT9OMnzEJKQiT1QBJJxRg Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 05:03:40 -0000 Hi Gorry, I think the milestones listed below should be improved by introducing some works describing general issues, for they are the foundations for the group. Please indicate if you have different viewpoints then we can take a discussion. First, there are two requirement drafts which was submitted to this group in the early stage and have had positive influences on the later work submitted. They are respectively "PMIP requirements" and "Group management requirements" drafts, as Behcet listed in a previous mail. They should be improved and included in the milestones. Secondly, an architecture draft is needed in the milestone because it helps to make a framework and should support all the work in the group, and helps to prevent uselessness and aimlessness of the our work. This is also the initiative for me to prepare the architecture draft for "Multicast Mechanism for Receiver Mobility". It is just a startpoint and needs the coorporation of the participants to make a good construction based on it. A milestone for architecture draft should be added. Thirdly, if PMIP is considered first, may the work for PMIP handover optimization be added to the milestones? Such as: - Submit an intial document on PMIP handover optimization. Some drafts already includes this aspect and they will definitely been discussed in the future. Best Regards, Liu Hui > -----Original Message----- > From: multimob-bounces@ietf.org > [mailto:multimob-bounces@ietf.org] On Behalf Of Gorry Fairhurst > Sent: Monday, June 22, 2009 11:43 PM > To: multimob@ietf.org > Subject: Re: [multimob] Charter discussion > > > Hi Bechet, > > Just to be clear, this is NOT YET the charter of the group. > The draft you posted was for comment by people with some > ideas to improve the charter. I'd also welcome thoughts on > whether we have the current charter and milestones correct. > > The current approved charter for the BoF is at: > http://www.arkko.com/ietf/ietf-75/multimob/charter.txt > > > My own take would be that the Charter text was OK. However, I > would like to see the milestones updated. Here are my suggestions: > > Six months: > - Submit a document on minimal deployment for PMIPv6 remote > subscription for multicast as a BCP RFC > > One year: > - Submit a document on tuning of IGMP/MLD in mobile multicast > mobility as a BCP RFC. > - Submit a document on IGMP/MLD extensions for multicast > mobility as an EXP/PS RFC. > - Submit a document on extensions for multicast mobility in > PMIPv6 as an EXP/PS RFC. > - Submit a document on multihoming requirements for multicast > as a INFO RFC. > > As a co-Chair, I would be *REALLY* interested on views on the > last item above, to understand whether people there is a need > for this document and whether it is realistic to see this > work completed by a WGLC one year after this work is started. > > Thoughts welcome, either sent to the chairs (cc us both) or > via the list. > > Gorry Fairhurst > (as Co-Chair) > > Behcet Sarikaya wrote: > > Hello Folks, > > This is the latest charter I have. Please comment. > > > > Regards, > > > > Behcet > > From gorry@erg.abdn.ac.uk Wed Jun 24 02:09:52 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2D23A6AA7 for ; Wed, 24 Jun 2009 02:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muidEy+H-H5v for ; Wed, 24 Jun 2009 02:09:50 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 6B9E63A6A35 for ; Wed, 24 Jun 2009 02:09:49 -0700 (PDT) Received: from Gorry-Fairhursts-Laptop-6.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n5O99Xc3020565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Jun 2009 10:09:34 +0100 (BST) Message-ID: <4A41ED4D.6040603@erg.abdn.ac.uk> Date: Wed, 24 Jun 2009 10:09:33 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Liu Hui References: <000901c9f489$288f59f0$8b0c6f0a@china.huawei.com> In-Reply-To: <000901c9f489$288f59f0$8b0c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 09:09:52 -0000 I need to re-assess what needs to be done. I would welcome comments on the list before the end of Thursday 25th - to allow the chairs to discuss what needs to be done. I would like to see a final charter adopted early next week. Others please feel free to also express your thoughts. See specific comments, in-line. Best wishes, Gorry Liu Hui wrote: > Hi Gorry, > > > I think the milestones listed below should be improved by introducing some > works describing general issues, for they are the foundations for the group. > Please indicate if you have different viewpoints then we can take a > discussion. > I may have different viewpoints, but I am keen to find how others perceive the intended work to be undertaken. It is important we scope the work correctly. I thought (was I right?) that the group understood both the intended areas of work and had now draft documents (i.e. drafts that could become BCPs or PS Updates). As I see it, the currently proposed charted milestones consist of small, but important, updates to existing specifications, achievable in 6-12 months. If the problem space is larger, this group would need a set of problem-statements and requirements (for each work item?). If so, I'd be keen to check that these specific documents have been widely accepted by other related IETF groups prior to any BoF. > First, there are two requirement drafts which was submitted to this group > in the early stage and have had positive influences on the later work > submitted. They are respectively "PMIP requirements" and "Group management > requirements" drafts, as Behcet listed in a previous mail. They should be > improved and included in the milestones. > Yes, I was aware of these, but was not aware that the group intended these for publication - key parts of problem-statements often mutate into parts of other documents. > Secondly, an architecture draft is needed in the milestone because it helps > to make a framework and should support all the work in the group, and helps > to prevent uselessness and aimlessness of the our work. This is also the > initiative for me to prepare the architecture draft for "Multicast Mechanism > for Receiver Mobility". It is just a startpoint and needs the coorporation > of the participants to make a good construction based on it. A milestone for > architecture draft should be added. > Yes, I saw your contribution, thanks. On this I need to understand more clearly why we also need a wider-scope Info architecture document on IPv4, FMIP, etc. Could we take these wider-items as a part of a future set of milestones, and initially focus on PMIP and MLD? > Thirdly, if PMIP is considered first, may the work for PMIP handover > optimization be added to the milestones? Such as: > > - Submit an initial document on PMIP handover optimization. > So, you see this as an additional charter item? I'd hoped it could be reflected as a part of the current milestone: - Submit a document on minimal deployment for PMIPv6 remote subscription for multicast as a BCP RFC. Do you think this is possible? > Some drafts already includes this aspect and they will definitely been > discussed in the future. > I was hoping we would have one document that sets out the architecture and how to do a minimal deployment, and one that updates PMIP on how to do optimised deployment. > Best Regards, > Liu Hui > > > >> -----Original Message----- >> From: multimob-bounces@ietf.org >> [mailto:multimob-bounces@ietf.org] On Behalf Of Gorry Fairhurst >> Sent: Monday, June 22, 2009 11:43 PM >> To: multimob@ietf.org >> Subject: Re: [multimob] Charter discussion >> >> >> Hi Bechet, >> >> Just to be clear, this is NOT YET the charter of the group. >> The draft you posted was for comment by people with some >> ideas to improve the charter. I'd also welcome thoughts on >> whether we have the current charter and milestones correct. >> >> The current approved charter for the BoF is at: >> http://www.arkko.com/ietf/ietf-75/multimob/charter.txt >> >> >> My own take would be that the Charter text was OK. However, I >> would like to see the milestones updated. Here are my suggestions: >> >> Six months: >> - Submit a document on minimal deployment for PMIPv6 remote >> subscription for multicast as a BCP RFC > >> One year: >> - Submit a document on tuning of IGMP/MLD in mobile multicast >> mobility as a BCP RFC. > > >> - Submit a document on IGMP/MLD extensions for multicast >> mobility as an EXP/PS RFC. > >> - Submit a document on extensions for multicast mobility in >> PMIPv6 as an EXP/PS RFC. > >> - Submit a document on multihoming requirements for multicast >> as a INFO RFC. > >> As a co-Chair, I would be *REALLY* interested on views on the >> last item above, to understand whether people there is a need >> for this document and whether it is realistic to see this >> work completed by a WGLC one year after this work is started. >> >> Thoughts welcome, either sent to the chairs (cc us both) or >> via the list. >> >> Gorry Fairhurst >> (as Co-Chair) >> >> Behcet Sarikaya wrote: >>> Hello Folks, >>> This is the latest charter I have. Please comment. >>> >>> Regards, >>> >>> Behcet >>> > > From asaeda@sfc.wide.ad.jp Wed Jun 24 02:42:05 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 836FA28C492 for ; Wed, 24 Jun 2009 02:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.902 X-Spam-Level: ** X-Spam-Status: No, score=2.902 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNygn522e3hA for ; Wed, 24 Jun 2009 02:42:04 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 0AA5928C339 for ; Wed, 24 Jun 2009 02:42:03 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 1294C13D06C8 for ; Wed, 24 Jun 2009 18:42:18 +0900 (JST) Date: Wed, 24 Jun 2009 18:42:17 +0900 (JST) Message-Id: <20090624.184217.52537419.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <4A41ED4D.6040603@erg.abdn.ac.uk> References: <000901c9f489$288f59f0$8b0c6f0a@china.huawei.com> <4A41ED4D.6040603@erg.abdn.ac.uk> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 09:42:05 -0000 Hi, > Yes, I saw your contribution, thanks. On this I need to understand > more clearly why we also need a wider-scope Info architecture > document on IPv4, FMIP, etc. Could we take these wider-items as a > part of a future set of milestones, and initially focus on PMIP and > MLD? I agree. Smaller charter is a good start. > > Thirdly, if PMIP is considered first, may the work for PMIP handover > > optimization be added to the milestones? Such as: > > - Submit an initial document on PMIP handover optimization. It will be (actually, it "is") included in one PMIP extension draft. I don't think any benefit to split the handover scenario from the extension draft at this phase. > So, you see this as an additional charter item? I'd hoped it could > be reflected as a part of the current milestone: > - Submit a document on minimal deployment for PMIPv6 remote > subscription for multicast as a BCP RFC. I'm sorry, but I still cannot imagine this. Well, whether I imagine this or not, is this really needed for the initial charter? Smaller charter is good for booting. Regards, -- Hitoshi Asaeda From liuhui47967@huawei.com Wed Jun 24 04:29:11 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AAAA3A69E5 for ; Wed, 24 Jun 2009 04:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrUp2QG4-138 for ; Wed, 24 Jun 2009 04:29:10 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 836A728C414 for ; Wed, 24 Jun 2009 04:29:08 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLQ008KCQKPP9@szxga01-in.huawei.com> for multimob@ietf.org; Wed, 24 Jun 2009 19:29:13 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLQ0067ZQKPUS@szxga01-in.huawei.com> for multimob@ietf.org; Wed, 24 Jun 2009 19:29:13 +0800 (CST) Received: from l47967b ([10.111.12.139]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLQ00DK7QKNK6@szxml04-in.huawei.com> for multimob@ietf.org; Wed, 24 Jun 2009 19:29:13 +0800 (CST) Date: Wed, 24 Jun 2009 19:29:11 +0800 From: Liu Hui In-reply-to: <4A41ED4D.6040603@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk Message-id: <000b01c9f4be$ff593610$8b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-index: Acn0q9LM3hh3d3grR42MXcz2PpiX0AAEBj7Q Cc: multimob@ietf.org Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 11:29:11 -0000 Hi Gorry, Thanks for your comments. please see mine inline and forgive me if I'm too straight. > > > > I think the milestones listed below should be improved by > introducing > > some works describing general issues, for they are the > foundations for the group. > > Please indicate if you have different viewpoints then we can take a > > discussion. > > > I may have different viewpoints, but I am keen to find how > others perceive the intended work to be undertaken. It is > important we scope the work correctly. > > I thought (was I right?) that the group understood both the > intended areas of work and had now draft documents (i.e. > drafts that could become BCPs or PS Updates). As I see it, > the currently proposed charted milestones consist of small, > but important, updates to existing specifications, achievable > in 6-12 months. > > If the problem space is larger, this group would need a set > of problem-statements and requirements (for each work item?). Should not be a separate requirement for each item. These two requirements scope two major area that have been filled with the work you think important. > If so, I'd be keen to check that these specific documents > have been widely accepted by other related IETF groups prior > to any BoF. Do you mean to check all the documents have been and will be listed in the milestone? > > > First, there are two requirement drafts which was > submitted to this > > group in the early stage and have had positive influences > on the later work > > submitted. They are respectively "PMIP requirements" and > "Group management > > requirements" drafts, as Behcet listed in a previous mail. > They should > > be improved and included in the milestones. > > > Yes, I was aware of these, but was not aware that the group > intended these for publication - key parts of > problem-statements often mutate into parts of other documents. Should they be deleted because they are mutated. Could we mutate drafts included in current milestone by some manner to some other forms of drafts and then delete them because they haven been mutated? If this is a rule, there should be no requirement draft in IETF, because they mostly have the possibility to be mutated to other documents. > > > Secondly, an architecture draft is needed in the milestone > because it > > helps to make a framework and should support all the work in the > > group, and helps to prevent uselessness and aimlessness of the our > > work. This is also the initiative for me to prepare the > architecture > > draft for "Multicast Mechanism for Receiver Mobility". It > is just a > > startpoint and needs the coorporation of the participants to make a > > good construction based on it. A milestone for architecture > draft should be added. > > > Yes, I saw your contribution, thanks. On this I need to You are welcome. And it's my pleasure that you saw it :) > understand more clearly why we also need a wider-scope Info > architecture document on IPv4, FMIP, etc. Could we take these > wider-items as a part of a future set of milestones, and > initially focus on PMIP and MLD? Yes. It's good that the initial draft is focused on PMIP and MLD. But our future work should not be limited to them. For multicast mobility, to intergrate the multicast and MIP, no matter what kind of group managment protocol, multicast routing protocol and MIP used, there exists a common infrastructure that make this intergration work and scale. It is already abstracted in the draft. Can we definitely say we will not support IPv4 and FMIP in our future work? If they are possible and usable in multicast mobility, why should they be scoped out? If we write a small architecture scoped in PMIP and MLD, will we write other architecture ones when we consider other MIP protocols or other type of IP network? If anyone can stand and say this MIP protocol or this network type will definitely kick out others, I will immediately sit down to revise my draft to only include the winners. Thus small is good manner to start to work, but not necessarily good for an architecture draft. And as you see, it is possible, as the draft show. > > > Thirdly, if PMIP is considered first, may the work for PMIP > handover > > optimization be added to the milestones? Such as: > > > > - Submit an initial document on PMIP handover optimization. > > > So, you see this as an additional charter item? I'd hoped it > could be reflected as a part of the current milestone: > - Submit a document on minimal deployment for PMIPv6 remote > subscription for multicast as a BCP RFC. > > Do you think this is possible? The superficial words do not indicate these milestones include "handover optimization". Handover is a complicated and important issue, . For example the remote subscription in the above milestone requires handover optimization, but the tunnel method should also need one. Sometimes they are close coupled to a solution, sometimes they are relatively independent. > > > Some drafts already includes this aspect and they will > definitely been > > discussed in the future. > > > I was hoping we would have one document that sets out the > architecture and how to do a minimal deployment, and one that > updates PMIP on how to do optimised deployment. Please show your detailed thinking about what's the minimal and optimised deployments and why you think it's necessary to have them. Best Regards, Liu Hui From waehlisch@ieee.org Wed Jun 24 06:11:43 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD043A63CB for ; Wed, 24 Jun 2009 06:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnUuU2-UW8Fs for ; Wed, 24 Jun 2009 06:11:40 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 8A2D33A6A86 for ; Wed, 24 Jun 2009 06:11:40 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.22.27.137] (helo=mw-thinkpad) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MJSG2-0000p7-Tq; Wed, 24 Jun 2009 15:11:23 +0200 Date: Wed, 24 Jun 2009 15:11:22 +0200 From: Matthias Waehlisch To: Liu Hui In-Reply-To: <000b01c9f4be$ff593610$8b0c6f0a@china.huawei.com> Message-ID: References: <000b01c9f4be$ff593610$8b0c6f0a@china.huawei.com> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: multimob@ietf.org Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 13:11:43 -0000 Hi Liu, hi Gorry, I would limit the list of milestones (as proposed) and in particular not add an architecture document. This seems a bit overburden: Desgining a protocol independent, all-fit solution in the timeline of the charter is a bit ambitious. If a strong need arises, we can recharter after 1 1/2 year. Regarding the "minimal and optimised deployments" discussion: I'm not sure, if I understand it correctly. Obviously, a minimal deployment solution has not to be optimal (with respect to tunnel states, traffic flow ...), but it does not require changes to the core specs (MIP, PMIP, ...). However, both classes of solutions provide "handover" support. Regards matthias -- Matthias Waehlisch . FU Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net On Wed, 24 Jun 2009, Liu Hui wrote: > Hi Gorry, > > Thanks for your comments. please see mine inline and forgive me if I'm too > straight. > > > > > > > I think the milestones listed below should be improved by > > introducing > > > some works describing general issues, for they are the > > foundations for the group. > > > Please indicate if you have different viewpoints then we can take a > > > discussion. > > > > > I may have different viewpoints, but I am keen to find how > > others perceive the intended work to be undertaken. It is > > important we scope the work correctly. > > > > I thought (was I right?) that the group understood both the > > intended areas of work and had now draft documents (i.e. > > drafts that could become BCPs or PS Updates). As I see it, > > the currently proposed charted milestones consist of small, > > but important, updates to existing specifications, achievable > > in 6-12 months. > > > > If the problem space is larger, this group would need a set > > of problem-statements and requirements (for each work item?). > > Should not be a separate requirement for each item. These two requirements > scope two major area that have been filled with the work you think > important. > > > If so, I'd be keen to check that these specific documents > > have been widely accepted by other related IETF groups prior > > to any BoF. > > Do you mean to check all the documents have been and will be listed in the > milestone? > > > > > > First, there are two requirement drafts which was > > submitted to this > > > group in the early stage and have had positive influences > > on the later work > > > submitted. They are respectively "PMIP requirements" and > > "Group management > > > requirements" drafts, as Behcet listed in a previous mail. > > They should > > > be improved and included in the milestones. > > > > > Yes, I was aware of these, but was not aware that the group > > intended these for publication - key parts of > > problem-statements often mutate into parts of other documents. > > Should they be deleted because they are mutated. Could we mutate drafts > included in current milestone by some manner to some other forms of drafts > and then delete them because they haven been mutated? > > If this is a rule, there should be no requirement draft in IETF, because > they mostly have the possibility to be mutated to other documents. > > > > > > Secondly, an architecture draft is needed in the milestone > > because it > > > helps to make a framework and should support all the work in the > > > group, and helps to prevent uselessness and aimlessness of the our > > > work. This is also the initiative for me to prepare the > > architecture > > > draft for "Multicast Mechanism for Receiver Mobility". It > > is just a > > > startpoint and needs the coorporation of the participants to make a > > > good construction based on it. A milestone for architecture > > draft should be added. > > > > > Yes, I saw your contribution, thanks. On this I need to > > You are welcome. And it's my pleasure that you saw it :) > > > understand more clearly why we also need a wider-scope Info > > architecture document on IPv4, FMIP, etc. Could we take these > > wider-items as a part of a future set of milestones, and > > initially focus on PMIP and MLD? > > Yes. It's good that the initial draft is focused on PMIP and MLD. But our > future work should not be limited to them. > > For multicast mobility, to intergrate the multicast and MIP, no matter what > kind of group managment protocol, multicast routing protocol and MIP used, > there exists a common infrastructure that make this intergration work and > scale. It is already abstracted in the draft. > > Can we definitely say we will not support IPv4 and FMIP in our future work? > If they are possible and usable in multicast mobility, why should they be > scoped out? If we write a small architecture scoped in PMIP and MLD, will > we write other architecture ones when we consider other MIP protocols or > other type of IP network? If anyone can stand and say this MIP protocol or > this network type will definitely kick out others, I will immediately sit > down to revise my draft to only include the winners. > > Thus small is good manner to start to work, but not necessarily good for an > architecture draft. And as you see, it is possible, as the draft show. > > > > > > Thirdly, if PMIP is considered first, may the work for PMIP > > handover > > > optimization be added to the milestones? Such as: > > > > > > - Submit an initial document on PMIP handover optimization. > > > > > So, you see this as an additional charter item? I'd hoped it > > could be reflected as a part of the current milestone: > > - Submit a document on minimal deployment for PMIPv6 remote > > subscription for multicast as a BCP RFC. > > > > Do you think this is possible? > > The superficial words do not indicate these milestones include "handover > optimization". Handover is a complicated and important issue, . For > example the remote subscription in the above milestone requires handover > optimization, but the tunnel method should also need one. Sometimes they > are close coupled to a solution, sometimes they are relatively independent. > > > > > > Some drafts already includes this aspect and they will > > definitely been > > > discussed in the future. > > > > > I was hoping we would have one document that sets out the > > architecture and how to do a minimal deployment, and one that > > updates PMIP on how to do optimised deployment. > > Please show your detailed thinking about what's the minimal and optimised > deployments and why you think it's necessary to have them. > > > Best Regards, > Liu Hui > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From behcetsarikaya@yahoo.com Wed Jun 24 09:12:53 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04F53A6FA2 for ; Wed, 24 Jun 2009 09:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4hYyTRKmDjt for ; Wed, 24 Jun 2009 09:12:53 -0700 (PDT) Received: from n79.bullet.mail.sp1.yahoo.com (n79.bullet.mail.sp1.yahoo.com [98.136.44.39]) by core3.amsl.com (Postfix) with SMTP id 01F1C3A67FF for ; Wed, 24 Jun 2009 09:12:52 -0700 (PDT) Received: from [69.147.84.145] by n79.bullet.mail.sp1.yahoo.com with NNFMP; 24 Jun 2009 16:08:47 -0000 Received: from [67.195.9.83] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 24 Jun 2009 16:08:47 -0000 Received: from [67.195.9.108] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 24 Jun 2009 16:08:46 -0000 Received: from [127.0.0.1] by omp112.mail.gq1.yahoo.com with NNFMP; 24 Jun 2009 16:08:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 823008.7525.bm@omp112.mail.gq1.yahoo.com Received: (qmail 1384 invoked by uid 60001); 24 Jun 2009 16:08:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245859726; bh=PcTs8aeuhKNrE+iv0/GgmukEi4yLi3NaYWKfVvAFqFI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zAFAmBeRNad/nZ/FvqdWdgL45Y9ng0lLQH/DchT0nbSzkkCtyqC68VqhR7nUK1q6nPYgR234D2PDvjVbiRYKMLvVSJtMaPpAEQowKSB3Un8aIklb5rZVPwdbE682raybN/pVWBUQubHyfkCdkJrcH6VgOIeXh5o1gN+73sRzyZg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=El7LrlTN7Pamu+hhF8V5Y1Jt59Hv2hiCboJaZuFWUEn9Qmd7KDy43M4wBIwTlD/o3ZA3v0svHOR5CzMmMsOQEUMrDOf590PQt8oe8pcDZZByc7bBtNRgVHl/3AoIvHaqqrvFkTXgW+pzQgqfvPE8Tmmha/fnMh9munxf4QYQqPc=; Message-ID: <588188.99645.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: 7yu_6ngVM1n4SLsZgXnb8asUijFMPlTE1sFsmeCO4YNJ2NYuxLvqm8QqrwPjzjSuRereM328UNWmzsOsOrbaMLbxd9J4cPm.6vHu7rN2eTHoR26by0z0dsb.8qjFD0Q301zFqbK3P7GbZe8L21GkgAznmmwYmcwFESP0BV8QVDxPZJ.cFRWDBjU9X62r0UZMYba7qfKHMOSoTkus6gy1n0q_rko3d0M.YzzwzTtf6WGqzEE9YjOlwGoelC.k3SdawPdsaRBeSkAvcY70rYRy0MFc0lvV3XglFkjRNqY4EKBoJTg05zLrt2V2PBkKMaywRx4A2LKL7gLlytHggv4UF545yA-- Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Wed, 24 Jun 2009 09:08:46 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 References: <692113.93816.qm@web111405.mail.gq1.yahoo.com> <4A3FA683.3010908@erg.abdn.ac.uk> Date: Wed, 24 Jun 2009 09:08:46 -0700 (PDT) From: Behcet Sarikaya To: gorry@erg.abdn.ac.uk, multimob@ietf.org In-Reply-To: <4A3FA683.3010908@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 16:12:53 -0000 Hello everybody,=0A=0A=A0=0A=0A=0A----- Original Message ----=0A> From: Gor= ry Fairhurst =0A> To: multimob@ietf.org=0A> Cc: Behce= t Sarikaya =0A> Sent: Monday, June 22, 2009 10:42:59 AM= =0A> Subject: Re: [multimob] Charter discussion=0A> =0Asnipped=0A=0A> Six m= onths:=0A> - Submit a document on minimal deployment for PMIPv6 remote subs= cription for =0A> multicast as a BCP RFC=0A> =0A> One year:=0A> - Submit a = document on tuning of IGMP/MLD in mobile multicast mobility as a BCP =0A> R= FC.=0A> - Submit a document on IGMP/MLD extensions for multicast mobility a= s an EXP/PS =0A> RFC.=0A> - Submit a document on extensions for multicast m= obility in PMIPv6 as an EXP/PS =0A> RFC.=0A> - Submit a document on multiho= ming requirements for multicast as a INFO RFC.=0A> =0A=0ACan we say that th= ere is consensus on the above? If yes, we can set the above as=A0our milest= ones.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A From xiayangsong@huawei.com Wed Jun 24 09:16:14 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E95E3A6CBE for ; Wed, 24 Jun 2009 09:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzafZyHiEeCx for ; Wed, 24 Jun 2009 09:16:14 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CB6933A69A4 for ; Wed, 24 Jun 2009 09:16:13 -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 <0KLR00ARG3TFHD@szxga03-in.huawei.com> for multimob@ietf.org; Thu, 25 Jun 2009 00:15:15 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLR00BUR3TFCO@szxga03-in.huawei.com> for multimob@ietf.org; Thu, 25 Jun 2009 00:15:15 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLR00KHV3T7Q5@szxml04-in.huawei.com> for multimob@ietf.org; Thu, 25 Jun 2009 00:15:15 +0800 (CST) Date: Wed, 24 Jun 2009 11:15:06 -0500 From: Frank Xia To: Behcet Sarikaya , gorry@erg.abdn.ac.uk, multimob@ietf.org Message-id: <00a601c9f4e6$f46b54e0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <692113.93816.qm@web111405.mail.gq1.yahoo.com> <4A3FA683.3010908@erg.abdn.ac.uk> <588188.99645.qm@web111405.mail.gq1.yahoo.com> Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 16:16:14 -0000 I am fine with the these. BR Frank ----- Original Message ----- From: "Behcet Sarikaya" To: ; Sent: Wednesday, June 24, 2009 11:08 AM Subject: Re: [multimob] Charter discussion Hello everybody, ----- Original Message ---- > From: Gorry Fairhurst > To: multimob@ietf.org > Cc: Behcet Sarikaya > Sent: Monday, June 22, 2009 10:42:59 AM > Subject: Re: [multimob] Charter discussion > snipped > Six months: > - Submit a document on minimal deployment for PMIPv6 remote subscription > for > multicast as a BCP RFC > > One year: > - Submit a document on tuning of IGMP/MLD in mobile multicast mobility as > a BCP > RFC. > - Submit a document on IGMP/MLD extensions for multicast mobility as an > EXP/PS > RFC. > - Submit a document on extensions for multicast mobility in PMIPv6 as an > EXP/PS > RFC. > - Submit a document on multihoming requirements for multicast as a INFO > RFC. > Can we say that there is consensus on the above? If yes, we can set the above as our milestones. Regards, Behcet _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Wed Jun 24 13:29:24 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2C813A6A21 for ; Wed, 24 Jun 2009 13:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijuOnRB4jmIg for ; Wed, 24 Jun 2009 13:29:22 -0700 (PDT) Received: from n71.bullet.mail.sp1.yahoo.com (n71.bullet.mail.sp1.yahoo.com [98.136.44.36]) by core3.amsl.com (Postfix) with SMTP id BB04F3A6CA6 for ; Wed, 24 Jun 2009 13:29:22 -0700 (PDT) Received: from [216.252.122.219] by n71.bullet.mail.sp1.yahoo.com with NNFMP; 24 Jun 2009 20:28:47 -0000 Received: from [67.195.9.81] by t4.bullet.sp1.yahoo.com with NNFMP; 24 Jun 2009 20:28:47 -0000 Received: from [67.195.9.105] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 24 Jun 2009 20:28:47 -0000 Received: from [127.0.0.1] by omp109.mail.gq1.yahoo.com with NNFMP; 24 Jun 2009 20:28:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 667991.7247.bm@omp109.mail.gq1.yahoo.com Received: (qmail 90312 invoked by uid 60001); 24 Jun 2009 20:28:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245875327; bh=3E8Gp5EN0kz2OEWGTiJ3cPJNAJQeVvX/0hGkEBVQwac=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ORDawhW7VD+huhOoCj40xLGorrjbHEnfhTpLeHTQJRMwZ/EfBkdL1Q6/DCAYT8DvjTRqv3KmAgEXj09xe080+kUbFQ3qfhte8H4zB+nqEyoLOx1vvPD5RD1edBt+L8Aak2NmAzQin+cv1MNhLPZIbn+W+qaK31ycrL5MLuI1sUw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=e2EMLpuTQHRPk+MdxveHFbMs1LB0WUPdTEcDBwrqyWryKF8YaG9peGV0SH5+4XFmfh1LMrEKMEpRm2tT+eREMppI2bkLbpbxkgAKwuv8LPIGzm64U1jQkUzclUXlnh0BEMFGXwwgH/wk1fNb+/fib9yUK5a2OwLcAbTYz3+e/GI=; Message-ID: <105872.90150.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: 8pXtTzkVM1k3zHH8sb5kGdbpW2tixFq1Cc1300NkdE_k82xIYiRoKUrNiCC.q.7X1Odz6zoAO7TMv21suScc_stly1AVU47eZBK61Dpn_XwCk_Px34L9p4m2GChHguCLOO4oPayHxV2gtDSS4PIXs.EwkJMXYuQ666NssDjvjm7Qr674wINvrwG.pINO52.AFrrg.XMn99MpQ.qwqL8lfHg6O35L4V1_8ELzrLNy7uvgA_VpuSLa38qSSlwLfdOtLXmJONz_MoRbu5Qd8RiexERbKYbkZy_MEcW5GJmzrkR3Qoa.QSa3JI3pz5PKhnXz4_aoVRaPRJnfGlnMs73F4CitBA-- Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Wed, 24 Jun 2009 13:28:46 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 References: <000b01c9f4be$ff593610$8b0c6f0a@china.huawei.com> Date: Wed, 24 Jun 2009 13:28:46 -0700 (PDT) From: Behcet Sarikaya To: Liu Hui , gorry@erg.abdn.ac.uk In-Reply-To: <000b01c9f4be$ff593610$8b0c6f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 20:29:24 -0000 Hi Hui,=0A=A0 =0A=0A=0A=0A----- Original Message ----=0A> From: Liu Hui =0A> To: gorry@erg.abdn.ac.uk=0A> Cc: multimob@ietf.or= g=0A> Sent: Wednesday, June 24, 2009 6:29:11 AM=0A> Subject: Re: [multimob]= Charter discussion=0A> =0A> Hi Gorry,=0A> =0A> Thanks for your comments. p= lease see mine inline and forgive me if I'm too=0A> straight.=0A> =0A> > > = =0A> > > I think the milestones listed below should be improved by =0A> > i= ntroducing =0A> > > some works describing general issues, for they are the = =0A> > foundations for the group.=0A> > > Please indicate if you have diffe= rent viewpoints then we can take a =0A> > > discussion.=0A> > > =0A> > I ma= y have different viewpoints, but I am keen to find how =0A> > others percei= ve the intended work to be undertaken. It is =0A> > important we scope the = work correctly.=0A> > =0A> > I thought (was I right?) that the group unders= tood both the =0A> > intended areas of work and had now draft documents (i.= e. =0A> > drafts that could become BCPs or PS Updates). As I see it, =0A> >= the currently proposed charted milestones consist of small, =0A> > but imp= ortant, updates to existing specifications, achievable =0A> > in 6-12 month= s.=0A> > =0A> > If the problem space is larger, this group would need a set= =0A> > of problem-statements and requirements (for each work item?). =0A> = =0A> Should not be a separate requirement for each item. These two requirem= ents=0A> scope two major area that have been filled with the work you think= =0A> important.=A0 =0A> =0A> > If so, I'd be keen to check that these speci= fic documents =0A> > have been widely accepted by other related IETF groups= prior =0A> > to any BoF.=0A> =0A> Do you mean to check all the documents h= ave been and will be listed in the=0A> milestone? =0A> =0A> > =0A> > > Firs= t,=A0 there are two requirement drafts which was =0A> > submitted to this = =0A> > > group in the early stage and have had positive influences =0A> > o= n the later work=0A> > > submitted.=A0 They are respectively "PMIP requirem= ents"=A0 and =0A> > "Group management=0A> > > requirements" drafts, as Behc= et listed in a previous mail. =0A> > They should =0A> > > be improved and i= ncluded in the milestones.=0A> > > =0A> > Yes, I was aware of these, but wa= s not aware that the group =0A> > intended these for publication - key part= s of =0A> > problem-statements often mutate into parts of other documents.= =0A> =0A> Should they be deleted because they are mutated. Could we mutate = drafts=0A> included in current milestone by some manner to some other forms= of drafts=0A> and then delete them because they haven been mutated? =0A> = =0A> If this is a rule, there should be no requirement draft in IETF, becau= se=0A> they mostly have the possibility to be mutated to other documents. = =0A> =0A> > =0A> > > Secondly, an architecture draft is needed in the miles= tone =0A> > because it =0A> > > helps to make a framework and should suppor= t all the work in the =0A> > > group, and helps to prevent uselessness and = aimlessness of the our =0A> > > work. This is also the initiative for me to= prepare the =0A> > architecture =0A> > > draft for "Multicast Mechanism fo= r Receiver Mobility".=A0 It =0A> > is just a =0A> > > startpoint and needs = the coorporation of the participants to make a =0A> > > good construction b= ased on it. A milestone for architecture =0A> > draft should be added.=0A> = > > =0A> > Yes, I saw your contribution, thanks. On this I need to =0A> =0A= > You are welcome. And it's my pleasure that you saw it :)=0A> =0A> > under= stand more clearly why we also need a wider-scope Info =0A> > architecture = document on IPv4, FMIP, etc. Could we take these =0A> > wider-items as a pa= rt of a future set of milestones, and =0A> > initially focus on PMIP and ML= D?=0A> =0A=0A=0AI think this is a good suggestion. If you wish to revise yo= ur draft, it is a good idea to revise it in this direction, i.e. focus the = architecture on PMIP and MLD.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A From liuhui47967@huawei.com Wed Jun 24 18:47:43 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8180F28C4F9 for ; Wed, 24 Jun 2009 18:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=-0.824, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RN0MD3JhxiiR for ; Wed, 24 Jun 2009 18:47:42 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id B2CBE28C139 for ; Wed, 24 Jun 2009 18:47:42 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLR002CDU9WXX@szxga02-in.huawei.com> for multimob@ietf.org; Thu, 25 Jun 2009 09:46:44 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLR0017HU9WWN@szxga02-in.huawei.com> for multimob@ietf.org; Thu, 25 Jun 2009 09:46:44 +0800 (CST) Received: from l47967b ([10.111.12.139]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLR00LHGU9VMS@szxml06-in.huawei.com> for multimob@ietf.org; Thu, 25 Jun 2009 09:46:44 +0800 (CST) Date: Thu, 25 Jun 2009 09:46:43 +0800 From: Liu Hui In-reply-to: <105872.90150.qm@web111402.mail.gq1.yahoo.com> To: 'Behcet Sarikaya' , gorry@erg.abdn.ac.uk Message-id: <000a01c9f536$caffca50$8b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Thread-index: Acn1CrmnJIoJW37mSVufOFKabBytQgAKiJFw Cc: multimob@ietf.org Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 01:47:43 -0000 Hi, Behcet, > > > understand more clearly why we also need a wider-scope Info > > > architecture document on IPv4, FMIP, etc. Could we take these > > > wider-items as a part of a future set of milestones, and > initially > > > focus on PMIP and MLD?> > > > > I think this is a good suggestion. If you wish to revise your > draft, it is a good idea to revise it in this direction, i.e. > focus the architecture on PMIP and MLD. Yes. Gorry's suggestion is really good. And I suggest it's better that the work is taken by the cooperation of the group. Best Regards, Liu Hui From liuhui47967@huawei.com Wed Jun 24 19:01:58 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39923A6DAA for ; Wed, 24 Jun 2009 19:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.216 X-Spam-Level: X-Spam-Status: No, score=-1.216 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WL+HeZv2jdAw for ; Wed, 24 Jun 2009 19:01:58 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 168203A685A for ; Wed, 24 Jun 2009 19:01:58 -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 <0KLR00CAFU9DZ0@szxga03-in.huawei.com> for multimob@ietf.org; Thu, 25 Jun 2009 09:46:25 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLR00BAAU9DCO@szxga03-in.huawei.com> for multimob@ietf.org; Thu, 25 Jun 2009 09:46:25 +0800 (CST) Received: from l47967b ([10.111.12.139]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLR00F5FU9C19@szxml04-in.huawei.com> for multimob@ietf.org; Thu, 25 Jun 2009 09:46:25 +0800 (CST) Date: Thu, 25 Jun 2009 09:46:24 +0800 From: Liu Hui In-reply-to: To: 'Matthias Waehlisch' Message-id: <000901c9f536$bfe36640$8b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Thread-index: Acn00Q/3vYAdNzrXT5+KfZIaYO9fHQAXsItA Cc: multimob@ietf.org Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 02:01:58 -0000 Hi Matthias > I would limit the list of milestones (as proposed) and in > particular not add an architecture document. This seems a bit > overburden: Desgining a protocol independent, all-fit > solution in the timeline of the charter is a bit ambitious. > If a strong need arises, we can recharter after 1 1/2 year. It should not be an all-fit solution. As I see it, the work of this group has some differences from other group that it majorly should not be the design of new protocols, but should be the intergration of different independent protocols in MIP and multicast area. An architecture is useful for picking out the appropriate components from these miscellaneous techniques and make the construction. If a timeline must be strictly limited. It's OK not to include this architecture work in current milestone. The draft could be continued to be improved to see the work of other protocols currently not being processed, if I'm able to. > Regarding the "minimal and optimised deployments" > discussion: I'm not sure, if I understand it correctly. > Obviously, a minimal deployment solution has not to be > optimal (with respect to tunnel states, traffic flow ...), > but it does not require changes to the core specs (MIP, PMIP, > ...). However, both classes of solutions provide "handover" support. We'll welcome them if they are good thinking. Best Regards, Liu Hui From jouni.nospam@gmail.com Thu Jun 25 02:35:35 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AAE03A69FC for ; Thu, 25 Jun 2009 02:35:35 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POXvC-rZ1mB1 for ; Thu, 25 Jun 2009 02:35:33 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id E0C2E3A69FD for ; Thu, 25 Jun 2009 02:35:32 -0700 (PDT) Received: by fxm9 with SMTP id 9so1313088fxm.37 for ; Thu, 25 Jun 2009 02:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=cFZZv+hVX4C2n7CzUwF0xeWFmVDlkT9lZbI618R1PTI=; b=vV8UbgP5vhb693v6UZBViXLa4nWJo+NlS3+FL0XE6NmW95O6l+yNzpCquo+LuNLoPN 9SK06bi8KVzJqBjyhiyxHIk6w7l94tjHpdvleI4nL2C7toW+BHazHl2wkFfOSIcA4Irm 9ELHvrhNzKjK1P79NQeuIP8TXmwIvrgPlif3U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=LTEThLFvebbWuib1+UR/NCPsVvduNqdTnGjMjGOY8pFRDG6L2eV7JV6AZ+TfrW8tVs x+9+fkRHJ0i7EKyi7SA5yb5ox3iiXKeQo5i82bRGPwfcyUUypEl2iW70mWDdRjDpa2eS W3+4zqTkYAdyv1A5VAgD1A+aBzC47j1Mk0e4s= Received: by 10.204.101.13 with SMTP id a13mr2288998bko.89.1245922360284; Thu, 25 Jun 2009 02:32:40 -0700 (PDT) Received: from a88-112-140-213.elisa-laajakaista.fi (a88-112-140-213.elisa-laajakaista.fi [88.112.140.213]) by mx.google.com with ESMTPS id z15sm3117961fkz.4.2009.06.25.02.32.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 25 Jun 2009 02:32:38 -0700 (PDT) Message-Id: <924CAEEA-9456-47DD-9170-6E50B28596AC@gmail.com> From: jouni korhonen To: Behcet Sarikaya In-Reply-To: <692113.93816.qm@web111405.mail.gq1.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 25 Jun 2009 12:32:37 +0300 References: <692113.93816.qm@web111405.mail.gq1.yahoo.com> X-Mailer: Apple Mail (2.935.3) Cc: multimob@ietf.org Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 09:35:35 -0000 Hi, I got few comments. My overall feeling is that this proposed charter just tries to tackle too many things. I would start with the absolute minimal work that is needed to identify/clarify/fix possible issues with (network based) mobility and multicast. Once that is done, re- evaluate and re-charter if necessary (assuming the WG would be formed in the first place). Then some more specific comments inline prefixed with [JiK]. I did this based on the "original" charter text and shamelessly bypassed the recent discussion on the mailing list ;) Cheers, Jouni ---------- Description of Working Group The Multicast mobility (multimob) will develop a set of protocol extensions and provide guidance appropriate for IPv4 and IPv6 multicast in a mobile environment. It will consider both source specific multicast (SSM) and any source multicast (ASM) multicast models. The scope of work will be limited to group management and mobile IP protocols - proxied or client-based. Work requiring modifications of multicast routing protocols (PIM-SM, PIM-DM, etc.) is out of scope. Specific goals are: - Specify PMIPv6 extensions to support IPv6 multicast including remote subscription and fast handover. - Specify IGMP/MLD extensions methods for reducing join/leave latency. - Specify a dormant mode operation for IGMPv3/MLDv2. - Provide guidance and specify methods for multi-homing support for multicast. [JiK] imho specific first step goals could be [JiK] - Identify and document issues that prevent use of multicast with IETF defined IP mobility protocols [JiK] - Provide guidance and base line specification how to deploy multicast with IETF defined IP mobility protocols [JiK] Scoping could be more strict. For example, scope the first round mobility protocol only to PMIP and listener mobility. Other stuff can be mentioned to be "in future scope". Unicast mobility protocols (Mobile IPv6, Dual-Stack Mobile IPv6 and also Mobile IPv4) provide basic multicast support and enable mobile nodes to perform bi-directional tunneling and receive multicast traffic anchored at the home agent. However, such basic support suffers from the 'avalanche' problem as the home agents replicate the packets and unicast them to the mobile nodes as well as from non- optimal, triangular routing, 'remote subscription' suffers from possible loss of data during handovers. The WG will address these issues within the context of Proxy Mobile IPv6 (PMIPv6). [JiK] What are "unicast mobility protocol"? The text seems to indicate they actually are client based mobility protocols. [JiK] What does "remote subscription" mean? Does it mean a) the MN is roaming in a visited network using telecom terminology, or b) the MN has joined a multicast group that is not available in the visited foreign network, or c) the MN has joined to a multicast group it intends to receive though the IP mobility solution provided means (i.e. forwarded to the MN via the HA/LMA). [JiK] Honestly, my original impression was that multimob would concentrate on PMIP6 at the beginning. If it is so, then the charter text should also be more biased towards it. There can be a backdoor in the text to add more stuff after re-chartering, for example saying that the WG will study/evaluate whether client MIP or IGMP/MLD needs more work. The current mixing of both client MIP and proxy MIP issues & descriptions make the charter confusing, and I would assume also makes a forming a WG more challenging. Currently PMIPv6 (and mobility extension protocols like FMIPv6 and HMIPv6) does not support multicasting explicitly. Basic support for multicast with bi-directional tunneling will be documented for PMIPv6 (with no new message types or changes to the message parameters). PMIPv6 that handles IPv4 and IPv6 will be extended to also support multicasting with IPv4. Finally, PMIPv6 basic multicast support will be extended to support remote subscription and fast handover. [JiK] I agree that current PMIP specification is vague when it comes to handling of multicast and imho that deserves to be clarified/fixed. Imho the paragraph above should not mix FMIP & HMIP with PMIP here, just for clarity and keeping things simple. [JiK] I would not propose a solution (e.g. bi-directional tunneling) immediately here in the description text, especially as we are not sure bi-directional tunneling type of solution is even applicable in the context of PMIP and unmodified hosts. Just say "a solution" or extension or deployment guidance is needed. Multimob will specify a set of extensions to IGMPv3/MLDv2 for mobile environments. IGMPv3/MLDv2 has been specified for wired networks with shared links. Mobile nodes also have other needs (e.g. entering a dormant mode to conserve battery power, minimising the [JiK] Would say multimob will study/evaluate whether extensions to IGMP3/MLDv2 are needed for supporting mobile environments. latency for joining and leaving a group in support of movement). The working group will assess existing solutions for group management, and determine if these methods are sufficient. This will include defining best current practice for selection of timer values and protocol parameters. If these methods are not sufficient, the working group shall propose new solutions as updates to [JiK] BCP/informational type of guidelines is OK regarding timers and such. Do we actually have operational data on those in wireless/mobile environments? existing protocols (including possible introduction of additional message types). It is a goal for the working group to ensure backward compatibility with the current implementations of group management protocols. Message structures supported in current deployed networks will not be modified. A multi-homed mobile node may wish to join multicast groups and to direct different multicast flows to its interfaces. The working group will define multi-homing support for multicast, including an efficient per-interface subscription management in the case of multi-homed mobility and multicast flow binding. [JiK] I would strongly consider _not_ to include this multihoming topic here. Work on this in Mif or re-charter later. In performing this work, the Multimob working group will work closely with NETLMM working group and will coordinate work on IGMP/MLD extensions with the MBONED working group. GOALS and MILESTONES: six months: - Submit an informational document explaining the use of multicast in PMIPv6. [JiK] This is Ok and imho needed. [JiK] Also would like to see a short evaluation document of issues with mobility & multicast. The IRTF I-D type of thing (by Thomas et'al) but probably slightly more compact and written in a way that it could be used to justify exact possible future work topics.. as a tool for re-chartering. [JiK] Maybe 6 months is a bit too ambitious? One year: - Submit a document on extensions for multicast mobility in PMIPv6 as an EXP/PS RFC. - Submit a BCP document on how to tune MLD best in wireless domains and mobile regimes. [JiK] Would not have these in the first round of goals/documents.. [JiK] Concentrate on the minimum requirements & set of documents (like the first two), work on those few documents and output quality specs. During the course we will learn what is really needed as for the future work and meanwhile we might even get better signals from the deployments where the real weak points are that industry needs to have fixed. Recharter or close working group. On Jun 22, 2009, at 6:06 PM, Behcet Sarikaya wrote: > Hello Folks, > This is the latest charter I have. Please comment. > > Regards, > > Behcet > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Thu Jun 25 13:16:54 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458673A6976 for ; Thu, 25 Jun 2009 13:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSkNvNpJeU5P for ; Thu, 25 Jun 2009 13:16:53 -0700 (PDT) Received: from n60.bullet.mail.sp1.yahoo.com (n60.bullet.mail.sp1.yahoo.com [98.136.44.40]) by core3.amsl.com (Postfix) with SMTP id 621FE3A67E2 for ; Thu, 25 Jun 2009 13:16:53 -0700 (PDT) Received: from [216.252.122.219] by n60.bullet.mail.sp1.yahoo.com with NNFMP; 25 Jun 2009 20:15:22 -0000 Received: from [67.195.9.83] by t4.bullet.sp1.yahoo.com with NNFMP; 25 Jun 2009 20:15:22 -0000 Received: from [67.195.9.106] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jun 2009 20:15:22 -0000 Received: from [127.0.0.1] by omp110.mail.gq1.yahoo.com with NNFMP; 25 Jun 2009 20:15:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 189581.77317.bm@omp110.mail.gq1.yahoo.com Received: (qmail 7039 invoked by uid 60001); 25 Jun 2009 20:15:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245960922; bh=poTDzdqRMhekooccQIzWm+y3IzYDRdgIlZH/mtJtFvc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AQXPOgKFNyEg++rEhyXXCpeq0HzTDVtS62JOgbzQP3wHN6daKbLC4DXtBO1LNfEnzaxTJFTZS+w2kd0+yeU0UMIswwM49nF4M4TUub4ZJ/liqpfSZQDoWT4VOQgnOQpVyAWIgiiX8kBjVMjIvtHENCL3+LCAWyrERworaPh4HWM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Sni3GSTZsCvpRsJFadidgX1dFXSLlPhN9SCut1B0u/aJE/SHauDcu48Pgvs/py1bOm4y0DTUhwf8T8McxkrNJJdeDfUTgb6i1WLKfM9yKU3Q2FNVJ9soTkW2/yzVPcrJplwQBsx0D4u5EhkLI0cDAGWGUzJSUzmp3WmkgZ6ICuo=; Message-ID: <32507.99320.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: c9_0XPoVM1mn4Nf6IftIVkUPkW8_bF3zHeYwtaI8BXP1iU7m5vSQDpPrtgcGSvBxaHwhOWp5KTcVgi4vCheS9EG6z2PnoZCFc73wDOnJM.ck8m96OB.V1dpJNfOGdE.TyiD4nQ_NLMAweCIs9C0Gm3_s54kKsogpjOGPOWRs1_sNXK4nzBUO7mhHKPcOiRsHxKadmRJSLs0vx.ZMf9Tv057gp.G4RLjtowrGwfDaGFe7FM8oAdQxYcFTTa6UEqVCDVij3QO.ND5IBcIaCmBRCoykrEnpKWrLB3UB_XYXJIqH_BzwAz8HuJsB9JRDQ94jMWC23XIDz2PGdQ82UQP6h6UYpiAupNA- Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Thu, 25 Jun 2009 13:15:21 PDT X-Mailer: YahooMailRC/1357.22 YahooMailWebService/0.7.289.15 References: <692113.93816.qm@web111405.mail.gq1.yahoo.com> <924CAEEA-9456-47DD-9170-6E50B28596AC@gmail.com> Date: Thu, 25 Jun 2009 13:15:21 -0700 (PDT) From: Behcet Sarikaya To: jouni korhonen In-Reply-To: <924CAEEA-9456-47DD-9170-6E50B28596AC@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-747361707-1245960921=:99320" Cc: multimob@ietf.org Subject: Re: [multimob] Charter discussion - take 7 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 20:16:54 -0000 --0-747361707-1245960921=:99320 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,=0A=A0 Based on Jouni's comments, I modified the charter. Please fin= d it attached to this mail.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A --0-747361707-1245960921=:99320 Content-Type: text/plain; name="multimobcharter07.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="multimobcharter07.txt" Ck11bHRpY2FzdCBNb2JpbGl0eSAobXVsdGltb2IpDQoNCkNoYWlyczoNClRC RA0KDQpJbnRlcm5ldCBBcmVhIChpbnQpIERpcmVjdG9yczoNCkphcmkgQXJr a28gPGphcmkuYXJra29AcGl1aGEubmV0Pg0KTWFyayBUb3duc2xleSA8dG93 bnNsZXlAY2lzY28uY29tPiANCg0KSW50ZXJuZXQgQXJlYSBBZHZpc29yOg0K SmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+DQoNClNlY3VyaXR5 IEFyZWEgQWR2aXNvcjoNCk1hcnNoYWxsIEV1YmFua3MgPHRtZUBhbWVyaWNh ZnJlZS50dj4uDQoNCk1haWxpbmcgTGlzdHM6DQpHZW5lcmFsIERpc2N1c3Np b246IG11bHRpbW9iQGlldGYub3JnDQpTdWJzY3JpYmUgb25saW5lIGF0OiBo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aW1v Yg0KDQpEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwDQoNClRoZSBNdWx0 aWNhc3QgbW9iaWxpdHkgKG11bHRpbW9iKSB3aWxsIGRldmVsb3AgYSBzZXQg b2YgcHJvdG9jb2wgZXh0ZW5zaW9ucyBhbmQgcHJvdmlkZSBndWlkYW5jZSBh cHByb3ByaWF0ZSBmb3IgSVB2NCBhbmQgSVB2NiBtdWx0aWNhc3QgaW4gYSBt b2JpbGUgZW52aXJvbm1lbnQuIEl0IHdpbGwgY29uc2lkZXIgYm90aCBzb3Vy Y2Ugc3BlY2lmaWMgbXVsdGljYXN0IChTU00pICBhbmQgYW55IHNvdXJjZSBt dWx0aWNhc3QgKEFTTSkgbXVsdGljYXN0IG1vZGVscy4KClRoZSBzY29wZSBv ZiB3b3JrIHdpbGwgYmUgbGltaXRlZCB0byBQcm94eSBNb2JpbGUgSVB2NiBw cm90b2NvbCBhbmQgbGlzdGVuZXIgbW9iaWxpdHkuIFdvcmsgcmVxdWlyaW5n IG1vZGlmaWNhdGlvbnMgb2YgbXVsdGljYXN0IHJvdXRpbmcgcHJvdG9jb2xz IChQSU0tU00sIFBJTS1ETSwgZXRjLikgaXMgb3V0IG9mIHNjb3BlLiBTcGVj aWZpYyBnb2FscyBhcmU6CiAgCi0gSWRlbnRpZnkgYW5kIGRvY3VtZW50IGlz c3VlcyB0aGF0IHByZXZlbnQgdXNlIG9mIG11bHRpY2FzdCB3aXRoIElFVEYg ZGVmaW5lZCBJUCBtb2JpbGl0eSBwcm90b2NvbHMgDQotIFByb3ZpZGUgZ3Vp ZGFuY2UgYW5kIGJhc2UgbGluZSBzcGVjaWZpY2F0aW9uIG9uIGhvdyB0byBk ZXBsb3kgbXVsdGljYXN0IHdpdGggUE1JUHY2CgpDdXJyZW50bHkgUE1JUHY2 IGRvZXMgbm90ICBzdXBwb3J0IG11bHRpY2FzdGluZyBleHBsaWNpdGx5LiBB IHNvbHV0aW9uIG9yIGV4dGVuc2lvbiBvciBkZXBsb3ltZW50IGd1aWRhbmNl IGlzIG5lZWRlZCBzdXBwb3J0aW5nIGJvdGggSVB2NiBhbmQgSVB2NC4gIFRo ZSBzb2x1dGlvbiBtYXkgcG9zc2libHkgYmUgYmFzZWQgb24gdGhlIHJlbW90 ZSBzdWJzY3JpcHRpb24gd2hpY2ggaXMgYSBtZWNoYW5pc20gYnkgd2hpY2gg dGhlIG1vYmlsZSBub2RlcyBqb2luIGEgbXVsdGljYXN0IGdyb3VwIGFuZCBy ZWNlaXZlIHRoZSBtdWx0aWNhc3QgZGF0YSB0aHJvdWdoIHRoZSBJUCBtb2Jp bGl0eSBzb2x1dGlvbiBwcm92aWRlZCBtZWFucyAoaS5lLiBmb3J3YXJkZWQg dG8gdGhlIE1OIHZpYSB0aGUgTE1BKS4gUmVtb3RlIHN1YnNjcmlwdGlvbiAg c3VmZmVycyBmcm9tIHBvc3NpYmxlIGxvc3Mgb2YgZGF0YSBkdXJpbmcgaGFu ZG92ZXJzLiBUaGUgV0cgd2lsbCBhZGRyZXNzIHRoZXNlIGlzc3VlcyB3aXRo aW4gdGhlIGNvbnRleHQgb2YgUHJveHkgTW9iaWxlIElQdjYgKFBNSVB2Niku Cg0KSW4gdGhlIGZ1dHVyZSwgTXVsdGltb2Igd2lsbCBzdHVkeS9ldmFsdWF0 ZSB3aGV0aGVyIGV4dGVuc2lvbnMgdG8gdGhlIGNsaWVudC1iYXNlZCBtb2Jp bGl0eSBwcm90b2NvbHMgKE1vYmlsZSBJUHY2LCBEdWFsLVN0YWNrIE1vYmls ZSBJUHY2IGFuZCBhbHNvIE1vYmlsZSBJUHY0KSBhcmUgbmVlZGVkLiBDdXJy ZW50bHksIGNsaWVudC1iYXNlZCBtb2JpbGl0eSBwcm90b2NvbHMgcHJvdmlk ZSBiYXNpYyBtdWx0aWNhc3Qgc3VwcG9ydCBhbmQgZW5hYmxlIG1vYmlsZSBu b2RlcyB0byBwZXJmb3JtIGJpLWRpcmVjdGlvbmFsIHR1bm5lbGluZyBhbmQg cmVjZWl2ZSBtdWx0aWNhc3QgdHJhZmZpYyBhbmNob3JlZCBhdCB0aGUgaG9t ZSBhZ2VudC4gSG93ZXZlciwgc3VjaCBiYXNpYyBzdXBwb3J0IHN1ZmZlcnMg ZnJvbSB0aGUgJ2F2YWxhbmNoZScgcHJvYmxlbSBhcyB0aGUgaG9tZSBhZ2Vu dHMgcmVwbGljYXRlIHRoZSBwYWNrZXRzIGFuZCB1bmljYXN0IHRoZW0gdG8g dGhlIG1vYmlsZSBub2RlcyBhcyB3ZWxsIGFzIGZyb20gbm9uLW9wdGltYWws IHRyaWFuZ3VsYXIgcm91dGluZy4NCgpJbiB0aGUgZnV0dXJlLCBNdWx0aW1v YiB3aWxsIHN0dWR5L2V2YWx1YXRlIHdoZXRoZXIgZXh0ZW5zaW9ucyB0byBJ R01QdjMvTUxEdjIgYXJlIG5lZWRlZCBmb3Igc3VwcG9ydGluZyBtb2JpbGUg ZW52aXJvbm1lbnRzLiBJR01QdjMvTUxEdjIgaGFzIGJlZW4gc3BlY2lmaWVk IGZvciB3aXJlZCBuZXR3b3JrcyB3aXRoIHNoYXJlZCBsaW5rcy4gTW9iaWxl IG5vZGVzIGFsc28gaGF2ZSBvdGhlciBuZWVkcyAoZS5nLiAgZW50ZXJpbmcg YSBkb3JtYW50IG1vZGUgdG8gY29uc2VydmUgYmF0dGVyeSBwb3dlciwgbWlu aW1pc2luZyB0aGUgbGF0ZW5jeSBmb3Igam9pbmluZyBhbmQgbGVhdmluZyBh IGdyb3VwIGluIHN1cHBvcnQgb2YgbW92ZW1lbnQpLiAgVGhlIHdvcmtpbmcg Z3JvdXAgd2lsbCBhc3Nlc3MgZXhpc3Rpbmcgc29sdXRpb25zIGZvciBncm91 cCBtYW5hZ2VtZW50LCBhbmQgZGV0ZXJtaW5lIGlmIHRoZXNlIG1ldGhvZHMg YXJlIHN1ZmZpY2llbnQuIFRoaXMgd2lsbCBpbmNsdWRlIGRlZmluaW5nIGJl c3QgY3VycmVudCBwcmFjdGljZSBmb3Igc2VsZWN0aW9uIG9mIHRpbWVyIHZh bHVlcyBhbmQgcHJvdG9jb2wgcGFyYW1ldGVycy4gSWYgdGhlc2UgbWV0aG9k cyBhcmUgbm90IHN1ZmZpY2llbnQsIHRoZSB3b3JraW5nIGdyb3VwIHNoYWxs IHByb3Bvc2UgbmV3IHNvbHV0aW9ucyBhcyB1cGRhdGVzIHRvIGV4aXN0aW5n IHByb3RvY29scyAoaW5jbHVkaW5nIHBvc3NpYmxlIGludHJvZHVjdGlvbiBv ZiBhZGRpdGlvbmFsIG1lc3NhZ2UgdHlwZXMpLiBJdCBpcyBhIGdvYWwgZm9y IHRoZSB3b3JraW5nIGdyb3VwIHRvIGVuc3VyZSBiYWNrd2FyZCBjb21wYXRp YmlsaXR5IHdpdGggdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIG9mIGdy b3VwIG1hbmFnZW1lbnQgcHJvdG9jb2xzLiBNZXNzYWdlIHN0cnVjdHVyZXMg c3VwcG9ydGVkIGluIGN1cnJlbnQgZGVwbG95ZWQgbmV0d29ya3Mgd2lsbCBu b3QgYmUgbW9kaWZpZWQuDQoKDQpJbiBwZXJmb3JtaW5nIHRoaXMgd29yaywg dGhlIE11bHRpbW9iIHdvcmtpbmcgZ3JvdXAgd2lsbCB3b3JrIGNsb3NlbHkg d2l0aCBORVRMTU0vTmV0RXh0DQp3b3JraW5nIGdyb3VwIGFuZCB3aWxsIGNv b3JkaW5hdGUgd29yayBvbiBJR01QL01MRCBleHRlbnNpb25zIHdpdGggdGhl IE1CT05FRCB3b3JraW5nIGdyb3VwLg0KDQpHT0FMUyBhbmQgTUlMRVNUT05F UzoNCg0Kc2l4IG1vbnRoczogDQoKLSBTdWJtaXQgYW4gaW5mb3JtYXRpb25h bCBkb2N1bWVudCBleHBsYWluaW5nIHRoZSB1c2Ugb2YgbXVsdGljYXN0IGlu IFBNSVB2Ni4NCg0KT25lIHllYXI6IA0KLSBTdWJtaXQgYSBkb2N1bWVudCBv biBldmFsdWF0aW9uIG9mIGlzc3VlcyB3aXRoIG1vYmlsaXR5IGFuZCBtdWx0 aWNhc3QuIA0KDQpSZWNoYXJ0ZXIgb3IgY2xvc2Ugd29ya2luZyBncm91cC4K --0-747361707-1245960921=:99320-- From gorry@erg.abdn.ac.uk Thu Jun 25 13:31:40 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720C53A67F2 for ; Thu, 25 Jun 2009 13:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwx4idhwHqvr for ; Thu, 25 Jun 2009 13:31:39 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 7055B3A67A3 for ; Thu, 25 Jun 2009 13:31:39 -0700 (PDT) Received: from Gorry-Fairhursts-Laptop-6.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n5PKVdbm008674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Jun 2009 21:31:40 +0100 (BST) Message-ID: <4A43DEAB.7060606@erg.abdn.ac.uk> Date: Thu, 25 Jun 2009 21:31:39 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Behcet Sarikaya References: <692113.93816.qm@web111405.mail.gq1.yahoo.com> <924CAEEA-9456-47DD-9170-6E50B28596AC@gmail.com> <32507.99320.qm@web111415.mail.gq1.yahoo.com> In-Reply-To: <32507.99320.qm@web111415.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org Subject: Re: [multimob] Charter discussion - take 7 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 20:31:40 -0000 Let's talk about all the various proposals in the Chair's chat tomorrow, Gorry Behcet Sarikaya wrote: > > Hi all, > Based on Jouni's comments, I modified the charter. Please find it attached to this mail. > > Regards, > > Behcet > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Thu Jun 25 15:30:45 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9293A68FF for ; Thu, 25 Jun 2009 15:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmcUdNdFYEt8 for ; Thu, 25 Jun 2009 15:30:42 -0700 (PDT) Received: from n65.bullet.mail.sp1.yahoo.com (n65.bullet.mail.sp1.yahoo.com [98.136.44.190]) by core3.amsl.com (Postfix) with SMTP id 9F8E63A6840 for ; Thu, 25 Jun 2009 15:30:42 -0700 (PDT) Received: from [69.147.84.145] by n65.bullet.mail.sp1.yahoo.com with NNFMP; 25 Jun 2009 22:28:50 -0000 Received: from [67.195.9.81] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 25 Jun 2009 22:28:49 -0000 Received: from [67.195.9.104] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jun 2009 22:28:49 -0000 Received: from [127.0.0.1] by omp108.mail.gq1.yahoo.com with NNFMP; 25 Jun 2009 22:28:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 727452.32568.bm@omp108.mail.gq1.yahoo.com Received: (qmail 33044 invoked by uid 60001); 25 Jun 2009 22:28:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245968929; bh=7YSvcP19jzZkY1XyMDC2ALaJNCN1gnQFhEC3f30Rd4k=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CsedxhRzqUHnppOqQVm9vfa/ZRQ6j89NQwXWY5NZzrPPuRsw/+j202wlt4doMct3EKdu45XkSdWxu85w72LqSWD8q51iRxN6N3R+dcDCTgvGqyZXh66xHmw4mWdJuaNmXEA3v3raz5x29KO5yrI+mKFL0dTq1Y6Xv8bspc9RDuc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=e+2uzyOKb1ApUOK7d7TxoghR1TRLtOYaUS8Ww7Fld/tjiO0HZFZDd6VpHp2G0ZewJuCxpR7BCAsYxp3FYsU2pe9ybKwBWWTrfcDpRGvzmJicTfU8mbN7QdzkbFlhz243jmJcb105edksHNEFe6npn1nNdfThNJfkFxXW+g8pPTg=; Message-ID: <545478.31838.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: AI6fXfMVM1k1NIE.GYLttPsVH1.TxLqkNtTVpiqP8rVBGOpn6byO32A5ttzzIZWngBICA0m89MLYWW7Sn44rLtvz43f7SbKKdxQ8prfrWWzeaRIGulNzY.eWJHExl.f7RDWVgq9EfVukH1bhSuz8LSDDpAb_eh3gCtvgyu_K8mzaxO6i01qtWjYqaOVr2pxPjMDIohdHApqNWW_XF.lepItnyUwotTwMftZjdWP0LlR2blCtnYagzi53usYtQ0oBZyl1dJac9JKs.z8xDiDZY14GlQKQyXkUJGSCHozrIbdBpO0BE7zEwQQ2JuXF7gFGqILcZloBMUhFWVflhWJoIgY- Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Thu, 25 Jun 2009 15:28:49 PDT X-Mailer: YahooMailRC/1357.22 YahooMailWebService/0.7.289.15 References: <692113.93816.qm@web111405.mail.gq1.yahoo.com> <924CAEEA-9456-47DD-9170-6E50B28596AC@gmail.com> Date: Thu, 25 Jun 2009 15:28:49 -0700 (PDT) From: Behcet Sarikaya To: jouni korhonen In-Reply-To: <924CAEEA-9456-47DD-9170-6E50B28596AC@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] Charter discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 22:30:45 -0000 Hi Jouni,=0A=A0 Thanks for your detailed comments and insight on our charte= r.=0A=A0 Please see my post on the list. Does it capture everything you wan= ted to see in Multimob charter?=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- = Original Message ----=0A> From: jouni korhonen =0A>= To: Behcet Sarikaya =0A> Cc: multimob@ietf.org=0A> Sent= : Thursday, June 25, 2009 4:32:37 AM=0A> Subject: Re: [multimob] Charter di= scussion=0A> =0A> =0A> Hi,=0A> =0A> I got few comments. My overall feeling = is that this proposed charter just tries =0A> to tackle too many things. I = would start with the absolute minimal work that is =0A> needed to identify/= clarify/fix possible issues with (network based) mobility and =0A> multicas= t. Once that is done, re-evaluate and re-charter if necessary (assuming =0A= > the WG would be formed in the first place).=0A> =0A> Then some more speci= fic comments inline prefixed with [JiK]. I did this based on =0A> the "orig= inal" charter text and shamelessly bypassed the recent discussion on =0A> t= he mailing list ;)=0A> =0A> Cheers,=0A> =A0=A0=A0 Jouni=0A> =0A> ----------= =0A> =0A> Description of Working Group=0A> =0A> The Multicast mobility (mul= timob) will develop a set of protocol extensions and =0A> provide guidance = appropriate for IPv4 and IPv6 multicast in a mobile =0A> environment. It wi= ll consider both source specific multicast (SSM)=A0 and any =0A> source mul= ticast (ASM) multicast models.=0A> =0A> The scope of work will be limited t= o group management and mobile IP protocols - =0A> proxied or client-based. = Work requiring modifications of multicast routing =0A> protocols (PIM-SM, P= IM-DM, etc.) is out of scope. Specific goals are:=0A> =0A> - Specify PMIPv6= extensions to support IPv6 multicast including remote =0A> subscription an= d fast handover.=0A> - Specify IGMP/MLD extensions methods for reducing joi= n/leave latency.=0A> - Specify a dormant mode operation for IGMPv3/MLDv2.= =0A> - Provide guidance and specify methods for multi-homing support for mu= lticast.=0A> =0A> [JiK] imho specific first step goals could be=0A> [JiK] -= Identify and document issues that prevent use of multicast with IETF =0A> = defined IP mobility protocols=0A> [JiK] - Provide guidance and base line sp= ecification how to deploy multicast =0A> with IETF defined IP mobility prot= ocols=0A> [JiK] Scoping could be more strict. For example, scope the first = round mobility =0A> protocol only to PMIP and listener mobility. Other stuf= f can be mentioned to be =0A> "in future scope".=0A> =0A> =0A> Unicast mobi= lity protocols (Mobile IPv6, Dual-Stack Mobile IPv6 and also Mobile =0A> IP= v4) provide basic multicast support and enable mobile nodes to perform =0A>= bi-directional tunneling and receive multicast traffic anchored at the hom= e =0A> agent. However, such basic support suffers from the 'avalanche' prob= lem as the =0A> home agents replicate the packets and unicast them to the m= obile nodes as well =0A> as from non-optimal, triangular routing, 'remote s= ubscription' suffers from =0A> possible loss of data during handovers. The = WG will address these issues within =0A> the context of Proxy Mobile IPv6 (= PMIPv6).=0A> =0A> [JiK] What are "unicast mobility protocol"? The text seem= s to indicate they =0A> actually are client based mobility protocols.=0A> [= JiK] What does "remote subscription" mean? Does it mean a) the MN is roamin= g in =0A> a visited network using telecom terminology, or b) the MN has joi= ned a multicast =0A> group that is not available in the visited foreign net= work, or c) the MN has =0A> joined to a multicast group it intends to recei= ve though the IP mobility =0A> solution provided means (i.e. forwarded to t= he MN via the HA/LMA).=0A> =0A> [JiK] Honestly, my original impression was = that multimob would concentrate on =0A> PMIP6 at the beginning. If it is so= , then the charter text should also be more =0A> biased towards it. There c= an be a backdoor in the text to add more stuff after =0A> re-chartering, fo= r example saying that the WG will study/evaluate whether client =0A> MIP or= IGMP/MLD needs more work. The current mixing of both client MIP and proxy = =0A> MIP issues & descriptions make the charter confusing, and I would assu= me also =0A> makes a forming a WG more challenging.=0A> =0A> Currently PMIP= v6 (and mobility extension protocols like=A0 FMIPv6 and HMIPv6) does =0A> n= ot=A0 support multicasting explicitly. Basic support for multicast with =0A= > bi-directional tunneling will be documented for PMIPv6 (with no new messa= ge =0A> types or=A0 changes to the message parameters). PMIPv6 that handles= IPv4 and IPv6 =0A> will be extended to also support multicasting with IPv4= .. Finally, PMIPv6 basic =0A> multicast support will be extended to support = remote subscription and fast =0A> handover.=0A> =0A> [JiK] I agree that cur= rent PMIP specification is vague when it comes to handling =0A> of multicas= t and imho that deserves to be clarified/fixed. Imho the paragraph =0A> abo= ve should not mix FMIP & HMIP with PMIP here, just for clarity and keeping = =0A> things simple.=0A> =0A> [JiK] I would not propose a solution (e.g. bi-= directional tunneling) immediately =0A> here in the description text, espec= ially as we are not sure bi-directional =0A> tunneling type of solution is = even applicable in the context of PMIP and =0A> unmodified hosts. Just say = "a solution" or extension or deployment guidance is =0A> needed.=0A> =0A> = =0A> Multimob will specify a set of extensions to IGMPv3/MLDv2 for mobile = =0A> environments. IGMPv3/MLDv2 has been specified for wired networks with = shared =0A> links. Mobile nodes also have other needs (e.g.=A0 entering a d= ormant mode to =0A> conserve battery power, minimising the=0A> =0A> [JiK] W= ould say multimob will study/evaluate whether extensions to IGMP3/MLDv2 =0A= > are needed for supporting mobile environments.=0A> =0A> latency for joini= ng and leaving a group in support of movement).=A0 The working =0A> group w= ill assess existing solutions for group management, and determine if =0A> t= hese methods are sufficient. This will include defining best current practi= ce =0A> for selection of timer values and protocol parameters. If these met= hods are not =0A> sufficient, the working group shall propose new solutions= as updates to=0A> =0A> [JiK] BCP/informational type of guidelines is OK re= garding timers and such. Do =0A> we actually have operational data on those= in wireless/mobile environments?=0A> =0A> existing protocols (including po= ssible introduction of additional message =0A> types). It is a goal for the= working group to ensure backward compatibility with =0A> the current imple= mentations of group management protocols. Message structures =0A> supported= in current deployed networks will not be modified.=0A> =0A> A multi-homed = mobile node may wish to join multicast groups and to direct =0A> different = multicast flows to its interfaces. The working group will define =0A> multi= -homing support for multicast, including an efficient per-interface =0A> su= bscription management in the case of multi-homed mobility and multicast flo= w =0A> binding.=0A> =0A> [JiK] I would strongly consider _not_ to include t= his multihoming topic here. =0A> Work on this in Mif or re-charter later.= =0A> =0A> =0A> In performing this work, the Multimob working group will wor= k closely with =0A> NETLMM=0A> working group and will coordinate work on IG= MP/MLD extensions with the MBONED =0A> working group.=0A> =0A> GOALS and MI= LESTONES:=0A> =0A> six months:=0A> =0A> - Submit an informational document = explaining the use of multicast in PMIPv6.=0A> =0A> [JiK] This is Ok and im= ho needed.=0A> [JiK] Also would like to see a short evaluation document of = issues with mobility =0A> & multicast. The IRTF I-D type of thing (by Thoma= s et'al) but probably slightly =0A> more compact and written in a way that = it could be used to justify exact =0A> possible future work topics.. as a t= ool for re-chartering.=0A> [JiK] Maybe 6 months is a bit too ambitious?=0A>= =0A> One year:=0A> - Submit a document on extensions for multicast mobilit= y in PMIPv6 as an EXP/PS =0A> RFC.=0A> - Submit a BCP document on how to tu= ne MLD best in wireless domains and mobile =0A> regimes.=0A> =0A> [JiK] Wou= ld not have these in the first round of goals/documents..=0A> [JiK] Concent= rate on the minimum requirements & set of documents (like the first =0A> tw= o), work on those few documents and output quality specs. During the course= we =0A> will learn what is really needed as for the future work and meanwh= ile we might =0A> even get better signals from the deployments where the re= al weak points are that =0A> industry needs to have fixed.=0A> =0A> =0A> Re= charter or close working group.=0A> =0A> =0A> =0A> =0A> On Jun 22, 2009, at= 6:06 PM, Behcet Sarikaya wrote:=0A> =0A> > Hello Folks,=0A> >=A0 This is t= he latest charter I have. Please comment.=0A> > =0A> > Regards,=0A> > =0A> = > Behcet=0A> > =0A> > =0A> > ______________________________________________= _=0A> > multimob mailing list=0A> > multimob@ietf.org=0A> > https://www.iet= f.org/mailman/listinfo/multimob=0A> =0A> __________________________________= _____________=0A> multimob mailing list=0A> multimob@ietf.org=0A> https://w= ww.ietf.org/mailman/listinfo/multimob=0A=0A=0A=0A From tme@americafree.tv Fri Jun 26 07:02:17 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0073A6B4D for ; Fri, 26 Jun 2009 07:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kpzdo-Op3AOx for ; Fri, 26 Jun 2009 07:02:17 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 17B2E3A6B11 for ; Fri, 26 Jun 2009 07:02:17 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 343C7419FBD6 for ; Fri, 26 Jun 2009 10:02:34 -0400 (EDT) Message-Id: From: Marshall Eubanks To: "multimob@ietf.org" Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 26 Jun 2009 10:02:33 -0400 X-Mailer: Apple Mail (2.935.3) Subject: [multimob] Charter tweak for IGMP/MLD X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 14:02:17 -0000 From the charter discussion of IGMP/MLD extensions methods for reducing join/leave latency. It is a goal for the working group to ensure backward compatibility with the current implementations of group management protocols. Message structures supported in current deployed networks will not be modified. I would suggest making this a little tighter. How does this sound ? It is a goal for the working group to ensure backward compatibility with the current implementations of group management protocols. Any new IGMP/MLD message types created will be to optimize mobile performance and, since they could be ignored, dropped or improperly forwarded by existing hosts, switches, routers and proxies, will not be necessary for proper IGMP/MLD performance, albeit with a partial or total loss of the intended performance optimization in deployments that do not fully support them. Message structures supported in the current deployed networks will not be modified. Regards Marshall From gorry@erg.abdn.ac.uk Fri Jun 26 07:46:54 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9126E3A6B8F for ; Fri, 26 Jun 2009 07:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f61wFH5QcGTM for ; Fri, 26 Jun 2009 07:46:53 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 83F6F3A6B6C for ; Fri, 26 Jun 2009 07:46:52 -0700 (PDT) Received: from dhcp-207-151.erg.abdn.ac.uk (dhcp-207-151.erg.abdn.ac.uk [139.133.207.151]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n5QEl4gN003640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 26 Jun 2009 15:47:04 +0100 (BST) Message-ID: <4A44DF68.8020807@erg.abdn.ac.uk> Date: Fri, 26 Jun 2009 15:47:04 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "multimob@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Subject: Re: [multimob] Charter tweak for IGMP/MLD X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 14:46:54 -0000 Thanks Marshall, to me this seems helpful. Does anyone on the list have other suggestions, if not, we'll add this to the Charter proposal. The BoF Chairs plan to send full final charter text by Monday to the mailing list - after which we plan to close this chartering discussion until the BoF. Gorry Marshall Eubanks wrote: > From the charter discussion of IGMP/MLD extensions methods for > reducing join/leave latency. > > It is a goal for the working group to ensure backward compatibility > with the current implementations of group management protocols. > Message structures supported in current deployed networks will not be > modified. > > I would suggest making this a little tighter. How does this sound ? > > It is a goal for the working group to ensure backward compatibility > with the current implementations of group management protocols. Any > new IGMP/MLD message types created will be to optimize mobile > performance and, since they could be ignored, dropped or improperly > forwarded by existing hosts, switches, routers and proxies, will not > be necessary for proper IGMP/MLD performance, albeit with a partial or > total loss of the intended performance optimization in deployments > that do not fully support them. Message structures supported in the > current deployed networks will not be modified. > > Regards > Marshall > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > From asaeda@sfc.wide.ad.jp Fri Jun 26 09:44:14 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C96C3A6C15 for ; Fri, 26 Jun 2009 09:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.78 X-Spam-Level: ** X-Spam-Status: No, score=2.78 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyNvecqWC5z7 for ; Fri, 26 Jun 2009 09:44:13 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id AD44B3A6C03 for ; Fri, 26 Jun 2009 09:44:07 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 29A5513D06C8 for ; Sat, 27 Jun 2009 01:44:23 +0900 (JST) Date: Sat, 27 Jun 2009 01:44:22 +0900 (JST) Message-Id: <20090627.014422.85415528.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <4A44DF68.8020807@erg.abdn.ac.uk> References: <4A44DF68.8020807@erg.abdn.ac.uk> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Charter tweak for IGMP/MLD X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 16:44:14 -0000 Hi, > Does anyone on the list have other suggestions, if not, we'll add > this to the Charter proposal. I'm fine with it. Regards, -- Hitoshi Asaeda From gorry@erg.abdn.ac.uk Mon Jun 29 12:07:53 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA41128C282 for ; Mon, 29 Jun 2009 12:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF9UxZgfy+dV for ; Mon, 29 Jun 2009 12:07:52 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [139.133.204.82]) by core3.amsl.com (Postfix) with ESMTP id 900AF28C2D1 for ; Mon, 29 Jun 2009 12:07:52 -0700 (PDT) Received: from Gorry-Fairhursts-Laptop-6.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n5TJ1jgR007097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 29 Jun 2009 20:01:46 +0100 (BST) Message-ID: <4A490F9A.8090206@erg.abdn.ac.uk> Date: Mon, 29 Jun 2009 20:01:46 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Subject: [multimob] New Charter proposal - draft for approval. X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 19:07:53 -0000 Here is the revised multimob charter that the WG Chairs have prepared based on the various inputs we have received. There are many small changes, but we think this process has improved the quality and clarity of the text. We both believe this is a strong Charter - we are now asking for notes of support, comments, issues, etc. Please let us have all feedback by midnight 1st July 2009. We then plan to submit this for publication by our ADs. Let us know your thoughts, Behcet and Gorry -- Multicast Mobility (multimob) Chairs: Gorry Fairhurst Behcet Sarikaya Internet Area (int) Directors: Jari Arkko Ralph Droms Internet Area Advisor: Jari Arkko Security Area Advisor: Marshall Eubanks . Mailing Lists: General Discussion: multimob@ietf.org Subscribe online at: https://www1.ietf.org/mailman/listinfo/multimob Description of Working Group The Multicast mobility (multimob) will develop protocol extensions and provide guidance for supporting IPv6 (and also IPv4) multicast in a mobile environment. It will consider both source specific multicast (SSM) and any source multicast (ASM) multicast models. The scope of work will be limited to Proxy Mobile IPv6, MLD/IGMP protocols and listener mobility. Work requiring modifications of multicast routing protocols is out of scope. Specific goals are: - Specify PMIPv6 extensions to support IPv6 multicast including remote subscription and fast handover. - Specify IGMP/MLD extensions methods for mobility. The current Proxy Mobile IPv6 (PMIPv6) specification does not explicitly define support for multicast. The WG will develop a solution for explicit multicast support in PMIPv6. Basic support for multicast with remote subscription will first be documented for PMIPv6 (with no new message types or changes to the message parameters). Remote subscription is a mechanism by which a mobile node joins a multicast group and receives multicast data forwarded via the local mobility anchor. PMIPv6 basic multicast support will then be extended to support optimizations to address the avalanche problem and fast handover. IGMPv3/MLDv2 has been specified for wired networks with shared links. Mobile nodes also have other needs (e.g. entering a dormant mode to conserve battery power, minimising the latency for joining and leaving a group in support of movement). The WG will assess existing solutions for group management, and determine if these methods are sufficient in a mobile environment. This will include recommending appropriate selection of timer values and protocol parameters. If current methods are not sufficient, the WG shall specify updates to existing protocols. It is a goal for the WG to ensure backward compatibility with current implementations of group management protocols. Any new IGMP/MLD message types will be specified to optimize mobile performance. Since these could be ignored, dropped or improperly forwarded by existing hosts, switches, routers and proxies, these will not be necessary for proper IGMP/MLD performance, albeit with a partial or total loss of the intended performance optimization in deployments that do not fully support them. Future work, subject to approval, may study/evaluate whether extensions are needed for the client-based mobility protocols (Mobile IPv6 and Dual-Stack Mobile IPv6). Future work may also include methods to allow a multi-homed mobile node to join multicast groups and direct multicast flows to appropriate local interfaces. In performing this work, the Multimob working group will work closely with NETLMM working group and will coordinate work on IGMP/MLD extensions with the MBONED working group. GOALS and MILESTONES: Six months: - Submit a document explaining use of multicast in PMIPv6, for publication as an INFO/BCP RFC. - Submit a document on how to tune MLD for mobility, for publication as an INFO/BCP RFC. One year: - Submit a document on extensions for multicast mobility in PMIPv6 as an EXP/PS RFC. - Submit a document on IGMP/MLD extensions for multicast mobility as an EXP/PS RFC. Recharter or close working group. From schmidt@informatik.haw-hamburg.de Mon Jun 29 12:44:13 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32743A6A34 for ; Mon, 29 Jun 2009 12:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cDSJcRxE81i for ; Mon, 29 Jun 2009 12:44:12 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 79C823A67B1 for ; Mon, 29 Jun 2009 12:43:47 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178146242.adsl.alicedsl.de ([85.178.146.242] helo=[192.168.178.23]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MLMI4-000CrK-CN; Mon, 29 Jun 2009 21:13:20 +0200 Message-ID: <4A49124D.8040300@informatik.haw-hamburg.de> Date: Mon, 29 Jun 2009 21:13:17 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <4A490F9A.8090206@erg.abdn.ac.uk> In-Reply-To: <4A490F9A.8090206@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] New Charter proposal - draft for approval. X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 19:44:13 -0000 Hi folks, excellent charter: I guess this is going to be a really productive, fast working group :-) Looking forward to working with you all! Thomas Gorry Fairhurst wrote: > > Here is the revised multimob charter that the WG Chairs have prepared > based on the various inputs we have received. There are many small > changes, but we think this process has improved the quality and clarity > of the text. We both believe this is a strong Charter - we are now > asking for notes of support, comments, issues, etc. > > Please let us have all feedback by midnight 1st July 2009. We then plan > to submit this for publication by our ADs. > > Let us know your thoughts, > > Behcet and Gorry > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From asaeda@sfc.wide.ad.jp Mon Jun 29 12:51:57 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38AA928C2C2 for ; Mon, 29 Jun 2009 12:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpYddeUvO1AO for ; Mon, 29 Jun 2009 12:51:56 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 8828A3A6B21 for ; Mon, 29 Jun 2009 12:51:56 -0700 (PDT) Received: from localhost (ATuileries-153-1-77-17.w83-202.abo.wanadoo.fr [83.202.100.17]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 70A6D13D06C8 for ; Tue, 30 Jun 2009 04:52:06 +0900 (JST) Date: Mon, 29 Jun 2009 21:52:06 +0200 (CEST) Message-Id: <20090629.215206.122323171.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <4A490F9A.8090206@erg.abdn.ac.uk> References: <4A490F9A.8090206@erg.abdn.ac.uk> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] New Charter proposal - draft for approval. X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 19:51:57 -0000 > Here is the revised multimob charter that the WG Chairs have > prepared based on the various inputs we have received. There are > many small changes, but we think this process has improved the > quality and clarity of the text. We both believe this is a strong > Charter - we are now asking for notes of support, comments, issues, > etc. I support this charter. Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Mon Jun 29 15:05:49 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5825B3A6C3C for ; Mon, 29 Jun 2009 15:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPEwm8Ymu1vk for ; Mon, 29 Jun 2009 15:05:48 -0700 (PDT) Received: from n6.bullet.re3.yahoo.com (n6.bullet.re3.yahoo.com [68.142.237.91]) by core3.amsl.com (Postfix) with SMTP id 09FCF3A6AAE for ; Mon, 29 Jun 2009 15:05:47 -0700 (PDT) Received: from [68.142.237.87] by n6.bullet.re3.yahoo.com with NNFMP; 29 Jun 2009 22:05:56 -0000 Received: from [67.195.9.82] by t3.bullet.re3.yahoo.com with NNFMP; 29 Jun 2009 22:05:56 -0000 Received: from [67.195.9.105] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 29 Jun 2009 22:05:56 -0000 Received: from [127.0.0.1] by omp109.mail.gq1.yahoo.com with NNFMP; 29 Jun 2009 22:05:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 331678.80340.bm@omp109.mail.gq1.yahoo.com Received: (qmail 32324 invoked by uid 60001); 29 Jun 2009 22:05:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246313156; bh=97h3+/DNuElWeez+b9ELWLP6iyfTVB2JosZGTpeJApo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GAOw/PmxOOg9jUmKXJ2dDrZRkHOFKpsnKnl01C0AIP4VitZt54p/SD23IJPF3uIsedGM4ljj1NJdiNghXDqs+Oz2PGSCf7d2pr2K12VUaYYrSTDqFNCPybd4W9tDRWctEEMn36VyCkTRSK5tklFrKRn6I3VgQMtGy7hlhHGy5ek= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Kz/uLeV4tnDlEiONX5j+6sh8CHO/nsN5MLOez7+1X32ErJi20fncq+Z+BO7A331sndRbOYqNHjGJrqkRJBdACSUvWTNDLlCK71PIpOPIheaxKrd+N497a4g3FnG6OI+oYklPIVNEMb5WxPom2fhsfBbQUFMs7K5EaLeSoSjfO50=; Message-ID: <43929.31853.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: N9qPOp4VM1mJ9iimgRn8.Dt0fejWsYGXq_RuSPZDyWtdlBjZuXkdi.pJE2zX7Dt9ws_2iG5X3D.9mDMXH8peaZDcEqWIir.0XdgzE3rEZ6lnVrwWwjbLivXxOcEcF.vBICDpRqQat9eZCcp0erJsAZ7EQvtS8kCh4_P9dbk._SKeCg9VIVmSLjiN8PntkIbXkELwXhxBobexllqqMvHmMP1k6xBFEec4YTeFnWDlpBs1KfSLUto7KKCY8MVE9o676v4lCD6F4E_yYvYSShTuL88GLvMtFQm4r8fWryV5eoa8R8Qf_Jhe4wt8.oA.fcic.bRI648xzXLflPP232zDKlVHag-- Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Mon, 29 Jun 2009 15:05:55 PDT X-Mailer: YahooMailRC/1357.22 YahooMailWebService/0.7.289.15 References: <4A490F9A.8090206@erg.abdn.ac.uk> Date: Mon, 29 Jun 2009 15:05:55 -0700 (PDT) From: Behcet Sarikaya To: gorry@erg.abdn.ac.uk, multimob@ietf.org In-Reply-To: <4A490F9A.8090206@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] New Charter proposal - draft for approval. X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 22:05:49 -0000 =0A=0A=0A=0A----- Original Message ----=0A> From: Gorry Fairhurst =0A> To: multimob@ietf.org=0A> Sent: Monday, June 29, 2009 2:0= 1:46 PM=0A> Subject: [multimob] New Charter proposal - draft for approval.= =0A> =0A> =0A> Here is the revised multimob charter that the WG Chairs =0A= =0ABoF Chairs=0A=0Ahave prepared based on =0A> the various inputs we have r= eceived. There are many small changes, but we think =0A> this process has i= mproved the quality and clarity of the text. We both believe =0A> this is a= strong Charter - we are now asking for notes of support, comments, =0A> is= sues, etc.=0A> =0A> Please let us have all feedback by midnight 1st July 20= 09. We then plan to =0A> submit this for publication by our ADs.=0A> =0A> L= et us know your thoughts,=0A> =0A> Behcet and Gorry=0A> =0A> -- =0A> Multic= ast Mobility (multimob)=0A> =0A> Chairs:=0A> Gorry Fairhurst =0A> Behcet Sa= rikaya =0A> =0A> Internet Area (int) Directors:=0A> Jari Arkko =0A> Ralph D= roms =0A> =0A> Internet Area Advisor:=0A> Jari Arkko =0A> =0A> Security Are= a Advisor:=0A> Marshall Eubanks .=0A> =0A> Mailing Lists:=0A> General Discu= ssion: multimob@ietf.org=0A> Subscribe online at: https://www1.ietf.org/mai= lman/listinfo/multimob=0A> =0A> Description of Working Group=0A> =0A> The M= ulticast mobility (multimob) will develop protocol extensions=0A> and provi= de guidance for supporting IPv6 (and also IPv4)=0A> multicast in a mobile e= nvironment. It will consider both source=0A> specific multicast (SSM) and a= ny source multicast (ASM) multicast=0A> models. The scope of work will be l= imited to Proxy Mobile IPv6, MLD/IGMP=0A> protocols and listener mobility. = Work requiring modifications of=0A> multicast routing protocols is out of s= cope.=0A> =0A> Specific goals are:=0A> - Specify PMIPv6 extensions to suppo= rt IPv6 multicast including remote =0A> subscription and fast handover.=0A>= - Specify IGMP/MLD extensions methods for mobility.=0A> =0A> The current P= roxy Mobile IPv6 (PMIPv6) specification does not=0A> explicitly define supp= ort for multicast. The WG will develop a solution=0A> for explicit multicas= t support in PMIPv6. Basic support for multicast=0A> with remote subscripti= on will first be documented for PMIPv6 (with=0A> no new message types or ch= anges to the message parameters).=A0 Remote=0A> subscription is a mechanism= by which a mobile node joins a multicast=0A> group and receives multicast = data forwarded via the local mobility=0A> anchor. PMIPv6 basic multicast su= pport will then be extended to support=0A> optimizations to address the ava= lanche problem and fast handover.=0A> =0A> IGMPv3/MLDv2 has been specified = for wired networks with=0A> shared links. Mobile nodes also have other need= s (e.g.=A0 entering a=0A> dormant mode to conserve battery power, minimisin= g the latency for=0A> joining and leaving a group in support of movement).= =0A> =0A> The WG will assess existing solutions for group management, and= =0A> determine if these methods are sufficient in a mobile environment.=0A>= This will include recommending appropriate selection of timer values=0A> a= nd protocol parameters. If current methods are not sufficient, the WG=0A> s= hall specify updates to existing protocols. It is a goal for the WG to=0A> = ensure backward compatibility with current implementations of=0A> group man= agement protocols. Any new IGMP/MLD message types=0A> will be specified to = optimize mobile performance. Since these=0A> could be ignored, dropped or i= mproperly forwarded by existing hosts,=0A> switches, routers and proxies, t= hese will not be necessary for proper=0A> IGMP/MLD performance, albeit with= a partial or total loss of the=0A> intended performance optimization in de= ployments that do not fully=0A> support them.=0A> =0A> Future work, subject= to approval, may study/evaluate whether=0A> extensions are needed for the = client-based mobility protocols=0A> (Mobile IPv6 and Dual-Stack Mobile IPv6= ). Future work may also include=0A> methods to allow a multi-homed mobile n= ode to join multicast=0A> groups and direct multicast flows to appropriate = local interfaces.=0A> =0A> In performing this work, the Multimob working gr= oup will work closely=0A> with NETLMM working group and will coordinate wor= k on IGMP/MLD=0A> extensions with the MBONED working group.=0A> =0A> GOALS = and MILESTONES:=0A> =0A> Six months:=0A> - Submit a document explaining use= of multicast in PMIPv6, for publication as an =0A> INFO/BCP RFC.=0A> - Sub= mit a document on how to tune MLD for mobility, for publication as an =0A> = INFO/BCP RFC.=0A> =0A> One year:=0A> - Submit a document on extensions for = multicast mobility in PMIPv6 as an EXP/PS =0A> RFC.=0A> - Submit a document= on IGMP/MLD extensions for multicast mobility as an EXP/PS =0A> RFC.=0A> = =0A> Recharter or close working group.=0A> =0A> =0A> ______________________= _________________________=0A> multimob mailing list=0A> multimob@ietf.org= =0A> https://www.ietf.org/mailman/listinfo/multimob=0A=0A=0A=0A From huimin.cmcc@gmail.com Mon Jun 29 23:33:30 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 867B728C1F3 for ; Mon, 29 Jun 2009 23:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBMsO+o9A3SP for ; Mon, 29 Jun 2009 23:33:29 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id BC2CD3A6E02 for ; Mon, 29 Jun 2009 23:33:29 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so228404wff.31 for ; Mon, 29 Jun 2009 23:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=XXYvOBySKjnW8FI8BX7D5bVeTia95BDgRdGk+5AB8BY=; b=jwyy6xZ8UWQomTurdIA855/GFX4Mr4BR8iwEYP4AWgIrzYLa6V8+nlO/qEm4dOVytQ DKA8XTpBbHAIK+CAz4S7iiQp9FEn6eR0kat32eY0fiEe9vyaa9OviYFVIOCiOrhSbXAB h8TzdMfJX8sZZEdCzadHf1GjcVz1ilky6HhKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=hGu7bBC9lg4XunlgwBff6VZ2hnba/ZTHBJYENJ28C7QujLlVSGbJDv8EOFN5AwAS5x QwXopaniQifuGkL4OI7wd5BfZe8nXlCxgW85lz0/Hs5o8dbMDHFbiHcexxnCTkxpqVWU p4U0HJOHUMRMmjqjSd4uUx3ba/KqyZnJh1oVU= MIME-Version: 1.0 Received: by 10.114.93.1 with SMTP id q1mr13066270wab.209.1246343614858; Mon, 29 Jun 2009 23:33:34 -0700 (PDT) In-Reply-To: <20090630062742.4AFFC28C17D@core3.amsl.com> References: <20090630062742.4AFFC28C17D@core3.amsl.com> Date: Tue, 30 Jun 2009 14:33:34 +0800 Message-ID: <5dca10d30906292333l3e324401nc213f03624de480e@mail.gmail.com> From: Min Hui To: multimob@ietf.org Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Subject: [multimob] Fwd: New Version Notification for draft-hui-multimob-fast-handover-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 06:33:30 -0000 Hi, all I just submitted a new draft to Multimob BOF, http://www.ietf.org/internet-drafts/draft-hui-multimob-fast-handover-00.txt The draft specifies the fast handover mechanism to solve the problem of handover latency and packet loss in Proxy Mobile IPv6 Multicast. Any comment is welcome, thanks. ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: 2009/6/30 Subject: New Version Notification for draft-hui-multimob-fast-handover-00 To: huimin.cmcc@gmail.com =B3=AD=CB=CD=A3=BA phdgang@gmail.com, denghui02@gmail.com A new version of I-D, draft-hui-multimob-fast-handover-00.txt has been successfuly submitted by Min Hui and posted to the IETF repository. Filename: draft-hui-multimob-fast-handover Revision: 00 Title: Fast Handover for Multicast in Proxy Mobile IPv6 Creation_date: 2009-06-29 WG ID: Independent Submission Number_of_pages: 16 Abstract: This document specifies the fast handover mechanism to solve the problem of handover latency and packet loss in Proxy Mobile IPv6 Multicast. Necessary extensions are specified for Handover Initiate (HI) and Handover Acknowledgement (HAck) messages to support multicast handover procedure. The IETF Secretariat. From gorry@erg.abdn.ac.uk Mon Jun 29 23:40:39 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AEDC28C209 for ; Mon, 29 Jun 2009 23:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-P32JKlFusj for ; Mon, 29 Jun 2009 23:40:38 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id E66DF28C1F2 for ; Mon, 29 Jun 2009 23:40:37 -0700 (PDT) Received: from Gorry-Fairhursts-Laptop-6.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n5U6eaLV021688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 30 Jun 2009 07:40:38 +0100 (BST) Message-ID: <4A49B364.5050805@erg.abdn.ac.uk> Date: Tue, 30 Jun 2009 07:40:36 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Behcet Sarikaya References: <4A490F9A.8090206@erg.abdn.ac.uk> <43929.31853.qm@web111413.mail.gq1.yahoo.com> In-Reply-To: <43929.31853.qm@web111413.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org Subject: Re: [multimob] New Charter proposal - draft for approval. X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 06:40:39 -0000 Yes indeed - Behcet and I are only signed-up to chair the BoF, Jari will select the WG chairs, if a WG is actually formed ! Gorry Behcet Sarikaya wrote: > > ----- Original Message ---- >> From: Gorry Fairhurst >> To: multimob@ietf.org >> Sent: Monday, June 29, 2009 2:01:46 PM >> Subject: [multimob] New Charter proposal - draft for approval. >> >> >> Here is the revised multimob charter that the WG Chairs > > BoF Chairs > > have prepared based on >> the various inputs we have received. There are many small changes, but we think >> this process has improved the quality and clarity of the text. We both believe >> this is a strong Charter - we are now asking for notes of support, comments, >> issues, etc. >> >> Please let us have all feedback by midnight 1st July 2009. We then plan to >> submit this for publication by our ADs. >> >> Let us know your thoughts, >> >> Behcet and Gorry >> >> -- >> Multicast Mobility (multimob) >> >> Chairs: >> Gorry Fairhurst >> Behcet Sarikaya >> >> Internet Area (int) Directors: >> Jari Arkko >> Ralph Droms >> >> Internet Area Advisor: >> Jari Arkko >> >> Security Area Advisor: >> Marshall Eubanks . >> >> Mailing Lists: >> General Discussion: multimob@ietf.org >> Subscribe online at: https://www1.ietf.org/mailman/listinfo/multimob >> >> Description of Working Group >> >> The Multicast mobility (multimob) will develop protocol extensions >> and provide guidance for supporting IPv6 (and also IPv4) >> multicast in a mobile environment. It will consider both source >> specific multicast (SSM) and any source multicast (ASM) multicast >> models. The scope of work will be limited to Proxy Mobile IPv6, MLD/IGMP >> protocols and listener mobility. Work requiring modifications of >> multicast routing protocols is out of scope. >> >> Specific goals are: >> - Specify PMIPv6 extensions to support IPv6 multicast including remote >> subscription and fast handover. >> - Specify IGMP/MLD extensions methods for mobility. >> >> The current Proxy Mobile IPv6 (PMIPv6) specification does not >> explicitly define support for multicast. The WG will develop a solution >> for explicit multicast support in PMIPv6. Basic support for multicast >> with remote subscription will first be documented for PMIPv6 (with >> no new message types or changes to the message parameters). Remote >> subscription is a mechanism by which a mobile node joins a multicast >> group and receives multicast data forwarded via the local mobility >> anchor. PMIPv6 basic multicast support will then be extended to support >> optimizations to address the avalanche problem and fast handover. >> >> IGMPv3/MLDv2 has been specified for wired networks with >> shared links. Mobile nodes also have other needs (e.g. entering a >> dormant mode to conserve battery power, minimising the latency for >> joining and leaving a group in support of movement). >> >> The WG will assess existing solutions for group management, and >> determine if these methods are sufficient in a mobile environment. >> This will include recommending appropriate selection of timer values >> and protocol parameters. If current methods are not sufficient, the WG >> shall specify updates to existing protocols. It is a goal for the WG to >> ensure backward compatibility with current implementations of >> group management protocols. Any new IGMP/MLD message types >> will be specified to optimize mobile performance. Since these >> could be ignored, dropped or improperly forwarded by existing hosts, >> switches, routers and proxies, these will not be necessary for proper >> IGMP/MLD performance, albeit with a partial or total loss of the >> intended performance optimization in deployments that do not fully >> support them. >> >> Future work, subject to approval, may study/evaluate whether >> extensions are needed for the client-based mobility protocols >> (Mobile IPv6 and Dual-Stack Mobile IPv6). Future work may also include >> methods to allow a multi-homed mobile node to join multicast >> groups and direct multicast flows to appropriate local interfaces. >> >> In performing this work, the Multimob working group will work closely >> with NETLMM working group and will coordinate work on IGMP/MLD >> extensions with the MBONED working group. >> >> GOALS and MILESTONES: >> >> Six months: >> - Submit a document explaining use of multicast in PMIPv6, for publication as an >> INFO/BCP RFC. >> - Submit a document on how to tune MLD for mobility, for publication as an >> INFO/BCP RFC. >> >> One year: >> - Submit a document on extensions for multicast mobility in PMIPv6 as an EXP/PS >> RFC. >> - Submit a document on IGMP/MLD extensions for multicast mobility as an EXP/PS >> RFC. >> >> Recharter or close working group. >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > > > > > > > From jouni.nospam@gmail.com Tue Jun 30 01:21:48 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F12B28C33E for ; Tue, 30 Jun 2009 01:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.227 X-Spam-Level: X-Spam-Status: No, score=-1.227 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8Yc0cwyP9Hc for ; Tue, 30 Jun 2009 01:21:47 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 13D1A28C1A5 for ; Tue, 30 Jun 2009 01:21:46 -0700 (PDT) Received: by ewy6 with SMTP id 6so6394537ewy.37 for ; Tue, 30 Jun 2009 01:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=BSboSwpnTyrdAPxr3NfRUMCjwEYUAVNGEjOhIi09rzM=; b=aVIuODvKt3tVFW6uZI2NfI6/P/spmqZI5H6PXa/cWY8izkQTfo9J4RU8goZ9xnCBr9 ggFBxC5GPcUH7adkfFdp65rF/dfZg4LErAj73BORll31GvvjzwfwzKVS6b1Q8uxc7t2Z 1n5LOgeXdYeyaQ7TxPBgbxQWuM4HllRZaIu9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=Oy/9jOgQ63YkdhqpkO09CdB41qsqwvKczxz3CRIHiccCkxwsqMYv83PivULB+FT+hS zAzAlmoCxIyRUai+PFHbqZhSP1PXaLvRLmUoS3tq2VfouUr3JTyZ19MaRX6Vl4VTrbKb KxRuqSFd9ZTTlNps07xx2IbAJPb419RgPpY60= Received: by 10.210.13.12 with SMTP id 12mr1663296ebm.98.1246349718710; Tue, 30 Jun 2009 01:15:18 -0700 (PDT) Received: from ?10.254.0.173? ([192.100.123.77]) by mx.google.com with ESMTPS id 10sm2324786eyd.18.2009.06.30.01.15.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Jun 2009 01:15:18 -0700 (PDT) Message-Id: From: jouni korhonen To: gorry@erg.abdn.ac.uk In-Reply-To: <4A490F9A.8090206@erg.abdn.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 30 Jun 2009 11:15:14 +0300 References: <4A490F9A.8090206@erg.abdn.ac.uk> X-Mailer: Apple Mail (2.935.3) Cc: multimob@ietf.org Subject: Re: [multimob] New Charter proposal - draft for approval. X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 08:21:48 -0000 Hi Gorry, et al, The new revision of the charter looks much better and addresses most of the comments I had. Some minor nits and suggestions inline. Again prefixed with [JiK]: On Jun 29, 2009, at 10:01 PM, Gorry Fairhurst wrote: > > Here is the revised multimob charter that the WG Chairs have > prepared based on the various inputs we have received. There are > many small changes, but we think this process has improved the > quality and clarity of the text. We both believe this is a strong > Charter - we are now asking for notes of support, comments, issues, > etc. > > Please let us have all feedback by midnight 1st July 2009. We then > plan to submit this for publication by our ADs. > > Let us know your thoughts, > > Behcet and Gorry > > -- > > Multicast Mobility (multimob) > > Chairs: > Gorry Fairhurst > Behcet Sarikaya > > Internet Area (int) Directors: > Jari Arkko > Ralph Droms > > Internet Area Advisor: > Jari Arkko > > Security Area Advisor: > Marshall Eubanks . > > Mailing Lists: > General Discussion: multimob@ietf.org > Subscribe online at: https://www1.ietf.org/mailman/listinfo/multimob > > Description of Working Group > > The Multicast mobility (multimob) will develop protocol extensions > and provide guidance for supporting IPv6 (and also IPv4) > multicast in a mobile environment. It will consider both source > specific multicast (SSM) and any source multicast (ASM) multicast > models. The scope of work will be limited to Proxy Mobile IPv6, MLD/ > IGMP > protocols and listener mobility. Work requiring modifications of > multicast routing protocols is out of scope. > > Specific goals are: > - Specify PMIPv6 extensions to support IPv6 multicast including > remote subscription and fast handover. > - Specify IGMP/MLD extensions methods for mobility. > > The current Proxy Mobile IPv6 (PMIPv6) specification does not [JiK] Scope it explicitly as "The current Proxy Mobile IPv6 (PMIPv6) base protocol specification as defined in RFC 5213.." > > explicitly define support for multicast. The WG will develop a > solution > for explicit multicast support in PMIPv6. Basic support for multicast > with remote subscription will first be documented for PMIPv6 (with > no new message types or changes to the message parameters). Remote [JiK] I would reword a bit: "The WG will work on solutions for multicast support in PMIPv6. A basic support for multicast with a remote subscription will first be documented. The basic support does not require any additions or changes to RFC 5213 specified message types and parameters, and assumes an unmodified mobile host." I would think the "basic support" should explicitly be a minimal effort, and require no changes to mobile hosts. > > subscription is a mechanism by which a mobile node joins a multicast > group and receives multicast data forwarded via the local mobility > anchor. PMIPv6 basic multicast support will then be extended to > support > optimizations to address the avalanche problem and fast handover. [JiK] How about: "PMIPv6 multicast support may later be extended to support.." I don't think the "basic support" needs to be extended.. rather the whole multicast support in PMIPv6 context may be extended with specific tweaks, and then (later) we can discuss whether those tweaks are PMIPv6 specific or generic to most wireless environments. > > > IGMPv3/MLDv2 has been specified for wired networks with > shared links. Mobile nodes also have other needs (e.g. entering a > dormant mode to conserve battery power, minimising the latency for > joining and leaving a group in support of movement). [JiK] The second sentence somehow seems to end too early.. I would write something like: "Mobile nodes also have other needs that are specific to wireless networks and mobility." > > > The WG will assess existing solutions for group management, and > determine if these methods are sufficient in a mobile environment. > This will include recommending appropriate selection of timer values > and protocol parameters. If current methods are not sufficient, the WG > shall specify updates to existing protocols. It is a goal for the WG > to [JiK] updates or extensions? > > ensure backward compatibility with current implementations of > group management protocols. Any new IGMP/MLD message types > will be specified to optimize mobile performance. Since these [JiK] "Any new IGMP/MLD.." is supposed to mean what? Did you mean: "New IGMP/MLD message types may be specified to optimize performance in mobile and wireless environments." > > could be ignored, dropped or improperly forwarded by existing hosts, > switches, routers and proxies, these will not be necessary for proper > IGMP/MLD performance, albeit with a partial or total loss of the > intended performance optimization in deployments that do not fully > support them. > > Future work, subject to approval, may study/evaluate whether > extensions are needed for the client-based mobility protocols > (Mobile IPv6 and Dual-Stack Mobile IPv6). Future work may also include > methods to allow a multi-homed mobile node to join multicast > groups and direct multicast flows to appropriate local interfaces. > > In performing this work, the Multimob working group will work closely > with NETLMM working group and will coordinate work on IGMP/MLD > extensions with the MBONED working group. > > GOALS and MILESTONES: > > Six months: > - Submit a document explaining use of multicast in PMIPv6, for > publication as an INFO/BCP RFC. > - Submit a document on how to tune MLD for mobility, for publication > as an INFO/BCP RFC. > > One year: > - Submit a document on extensions for multicast mobility in PMIPv6 > as an EXP/PS RFC. > - Submit a document on IGMP/MLD extensions for multicast mobility as > an EXP/PS RFC. > > Recharter or close working group. [JiK] Ok. Cheers, Jouni > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From Dirk.von-Hugo@telekom.de Tue Jun 30 02:04:22 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07AC53A6E0B for ; Tue, 30 Jun 2009 02:04:22 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEbFRoQ7XCEG for ; Tue, 30 Jun 2009 02:04:20 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id EB5C03A68EA for ; Tue, 30 Jun 2009 02:04:19 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 30 Jun 2009 11:03:08 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Jun 2009 11:03:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jun 2009 11:03:05 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC8027848011441C1@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] New Charter proposal - draft for approval. Thread-Index: Acn5W9+0IXGYR4QeQl+XK+DSqkoIgwABN7+A References: <4A490F9A.8090206@erg.abdn.ac.uk> From: To: , , X-OriginalArrivalTime: 30 Jun 2009 09:03:08.0425 (UTC) FILETIME=[96394790:01C9F961] Cc: multimob@ietf.org Subject: Re: [multimob] New Charter proposal - draft for approval. X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 09:04:22 -0000 Dear all, I support the new version of the charter - thanks to great work of all = active contributors!=20 I also find the comments by Jouni quite helpful to sharpen the focus and = improve understanding. If I could make a wish ... I would like to see the topic of 'source = mobility' as 'nice to have' for very future work :-) Best regards, Dirk -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von jouni korhonen Gesendet: Dienstag, 30. Juni 2009 10:15 An: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org Betreff: Re: [multimob] New Charter proposal - draft for approval. Hi Gorry, et al, The new revision of the charter looks much better and addresses most =20 of the comments I had. Some minor nits and suggestions inline. Again =20 prefixed with [JiK]: On Jun 29, 2009, at 10:01 PM, Gorry Fairhurst wrote: > > Here is the revised multimob charter that the WG Chairs have =20 > prepared based on the various inputs we have received. There are =20 > many small changes, but we think this process has improved the =20 > quality and clarity of the text. We both believe this is a strong =20 > Charter - we are now asking for notes of support, comments, issues, =20 > etc. > > Please let us have all feedback by midnight 1st July 2009. We then =20 > plan to submit this for publication by our ADs. > > Let us know your thoughts, > > Behcet and Gorry > > --=20 > > Multicast Mobility (multimob) > > Chairs: > Gorry Fairhurst > Behcet Sarikaya > > Internet Area (int) Directors: > Jari Arkko > Ralph Droms > > Internet Area Advisor: > Jari Arkko > > Security Area Advisor: > Marshall Eubanks . > > Mailing Lists: > General Discussion: multimob@ietf.org > Subscribe online at: https://www1.ietf.org/mailman/listinfo/multimob > > Description of Working Group > > The Multicast mobility (multimob) will develop protocol extensions > and provide guidance for supporting IPv6 (and also IPv4) > multicast in a mobile environment. It will consider both source > specific multicast (SSM) and any source multicast (ASM) multicast > models. The scope of work will be limited to Proxy Mobile IPv6, MLD/=20 > IGMP > protocols and listener mobility. Work requiring modifications of > multicast routing protocols is out of scope. > > Specific goals are: > - Specify PMIPv6 extensions to support IPv6 multicast including =20 > remote subscription and fast handover. > - Specify IGMP/MLD extensions methods for mobility. > > The current Proxy Mobile IPv6 (PMIPv6) specification does not [JiK] Scope it explicitly as "The current Proxy Mobile IPv6 (PMIPv6) =20 base protocol specification as defined in RFC 5213.." > > explicitly define support for multicast. The WG will develop a =20 > solution > for explicit multicast support in PMIPv6. Basic support for multicast > with remote subscription will first be documented for PMIPv6 (with > no new message types or changes to the message parameters). Remote [JiK] I would reword a bit: "The WG will work on solutions for multicast support in PMIPv6. A =20 basic support for multicast with a remote subscription will first be =20 documented. The basic support does not require any additions or =20 changes to RFC 5213 specified message types and parameters, and =20 assumes an unmodified mobile host." I would think the "basic support" should explicitly be a minimal =20 effort, and require no changes to mobile hosts. > > subscription is a mechanism by which a mobile node joins a multicast > group and receives multicast data forwarded via the local mobility > anchor. PMIPv6 basic multicast support will then be extended to =20 > support > optimizations to address the avalanche problem and fast handover. [JiK] How about: "PMIPv6 multicast support may later be extended to support.." I don't think the "basic support" needs to be extended.. rather the =20 whole multicast support in PMIPv6 context may be extended with =20 specific tweaks, and then (later) we can discuss whether those tweaks =20 are PMIPv6 specific or generic to most wireless environments. > > > IGMPv3/MLDv2 has been specified for wired networks with > shared links. Mobile nodes also have other needs (e.g. entering a > dormant mode to conserve battery power, minimising the latency for > joining and leaving a group in support of movement). [JiK] The second sentence somehow seems to end too early.. I would =20 write something like: "Mobile nodes also have other needs that are specific to wireless =20 networks and mobility." > > > The WG will assess existing solutions for group management, and > determine if these methods are sufficient in a mobile environment. > This will include recommending appropriate selection of timer values > and protocol parameters. If current methods are not sufficient, the WG > shall specify updates to existing protocols. It is a goal for the WG =20 > to [JiK] updates or extensions? > > ensure backward compatibility with current implementations of > group management protocols. Any new IGMP/MLD message types > will be specified to optimize mobile performance. Since these [JiK] "Any new IGMP/MLD.." is supposed to mean what? Did you mean: "New IGMP/MLD message types may be specified to optimize performance =20 in mobile and wireless environments." > > could be ignored, dropped or improperly forwarded by existing hosts, > switches, routers and proxies, these will not be necessary for proper > IGMP/MLD performance, albeit with a partial or total loss of the > intended performance optimization in deployments that do not fully > support them. > > Future work, subject to approval, may study/evaluate whether > extensions are needed for the client-based mobility protocols > (Mobile IPv6 and Dual-Stack Mobile IPv6). Future work may also include > methods to allow a multi-homed mobile node to join multicast > groups and direct multicast flows to appropriate local interfaces. > > In performing this work, the Multimob working group will work closely > with NETLMM working group and will coordinate work on IGMP/MLD > extensions with the MBONED working group. > > GOALS and MILESTONES: > > Six months: > - Submit a document explaining use of multicast in PMIPv6, for =20 > publication as an INFO/BCP RFC. > - Submit a document on how to tune MLD for mobility, for publication =20 > as an INFO/BCP RFC. > > One year: > - Submit a document on extensions for multicast mobility in PMIPv6 =20 > as an EXP/PS RFC. > - Submit a document on IGMP/MLD extensions for multicast mobility as =20 > an EXP/PS RFC. > > Recharter or close working group. [JiK] Ok. Cheers, Jouni > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From asaeda@sfc.wide.ad.jp Tue Jun 30 02:49:25 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C36CC3A6BE4 for ; Tue, 30 Jun 2009 02:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZp+WpXjx2hK for ; Tue, 30 Jun 2009 02:49:25 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 148373A6A1A for ; Tue, 30 Jun 2009 02:49:24 -0700 (PDT) Received: from localhost (unknown [132.227.100.122]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id D81D313D06C8; Tue, 30 Jun 2009 18:22:44 +0900 (JST) Date: Tue, 30 Jun 2009 11:22:41 +0200 (CEST) Message-Id: <20090630.112241.47233712.asaeda@sfc.wide.ad.jp> To: jouni.nospam@gmail.com From: Hitoshi Asaeda In-Reply-To: References: <4A490F9A.8090206@erg.abdn.ac.uk> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] New Charter proposal - draft for approval. X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 09:49:25 -0000 Jouni, > > anchor. PMIPv6 basic multicast support will then be extended to support > > optimizations to address the avalanche problem and fast handover. > > [JiK] How about: > "PMIPv6 multicast support may later be extended to support.." My personal thought is that the protocol extensions can be discussed in parallel, and hence I may say "protocol extensions for PMIPv6 multicast will be also discussed to support optimization to address the avalanche problems and fast handover." would be better. What do you think? Regards, -- Hitoshi Asaeda From jouni.nospam@gmail.com Tue Jun 30 03:19:37 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FDCB3A6BE4 for ; Tue, 30 Jun 2009 03:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdOG7-4X2mVV for ; Tue, 30 Jun 2009 03:19:36 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 8FC533A6B7D for ; Tue, 30 Jun 2009 03:19:36 -0700 (PDT) Received: by ewy6 with SMTP id 6so29074ewy.37 for ; Tue, 30 Jun 2009 03:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=T+PHMb23SQLSn2DBaU7ecPLbhMPR+qpIWw7dRskmzN8=; b=Ur9bTF1qmMkWUlfPv2qew7sxRfkI6eDy9kkDETdyNhvYB7mWlrd6S2FBc1yXIbZhkg X4BsATuptWNIAuZ8IZqLZ5qQ7/Yim+S3l786BXp8NZ1tpywl+49/yV1jmtt5QKOSNY9l oMQu+X/1KrVVil3G9h6RpLxeeorrnuYLhRW9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=oZa542Fs1p6FdqXRJO477KPOtOuvsZd5NtDnIsztv6jFMtIY0dtg46koJH4ieK/Ztt +4kdCgEk0a0QckaU83xH6yBFkD4BXo/XfVrO8qrh07zexehpMGljxjcWQxLvsKQH8EPy kivhn5eaLySmCje7crBwO92shWPq1GT/5ufYM= Received: by 10.210.34.2 with SMTP id h2mr3352837ebh.57.1246356824687; Tue, 30 Jun 2009 03:13:44 -0700 (PDT) Received: from ?10.254.0.173? ([192.100.123.77]) by mx.google.com with ESMTPS id 28sm1733122eye.46.2009.06.30.03.13.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Jun 2009 03:13:43 -0700 (PDT) Message-Id: <5AC35C53-2AF1-417A-B8A7-8890F1268BE7@gmail.com> From: jouni korhonen To: Hitoshi Asaeda In-Reply-To: <20090630.112241.47233712.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 30 Jun 2009 13:13:39 +0300 References: <4A490F9A.8090206@erg.abdn.ac.uk> <20090630.112241.47233712.asaeda@sfc.wide.ad.jp> X-Mailer: Apple Mail (2.935.3) Cc: multimob@ietf.org Subject: Re: [multimob] New Charter proposal - draft for approval. X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 10:19:37 -0000 Hi, On Jun 30, 2009, at 12:22 PM, Hitoshi Asaeda wrote: > Jouni, > >>> anchor. PMIPv6 basic multicast support will then be extended to >>> support >>> optimizations to address the avalanche problem and fast handover. >> >> [JiK] How about: >> "PMIPv6 multicast support may later be extended to support.." > > My personal thought is that the protocol extensions can be discussed > in parallel, and hence I may say "protocol extensions for PMIPv6 > multicast will be also discussed to support optimization to address > the avalanche problems and fast handover." would be better. > > What do you think? Nothing against discussing issues while working on others. The current text just implied to me that extension will be done no matter what and I think that is not right. The text you propose is fine. May be changing "discussed" to studied or evaluated.. Cheers, Jouni > > > Regards, > -- > Hitoshi Asaeda From tme@americafree.tv Tue Jun 30 03:50:50 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7957128C393 for ; Tue, 30 Jun 2009 03:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4Cze6McNzrd for ; Tue, 30 Jun 2009 03:50:49 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id E758028C392 for ; Tue, 30 Jun 2009 03:50:48 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 32BE2420F01C; Tue, 30 Jun 2009 06:51:05 -0400 (EDT) Message-Id: From: Marshall Eubanks To: jouni korhonen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 30 Jun 2009 06:51:04 -0400 References: <4A490F9A.8090206@erg.abdn.ac.uk> X-Mailer: Apple Mail (2.935.3) Cc: multimob@ietf.org Subject: Re: [multimob] New Charter proposal - draft for approval. X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 10:50:50 -0000 I like the suggested text changes below. Regards Marshall On Jun 30, 2009, at 4:15 AM, jouni korhonen wrote: > Hi Gorry, et al, > > The new revision of the charter looks much better and addresses most > of the comments I had. Some minor nits and suggestions inline. Again > prefixed with [JiK]: > > > > On Jun 29, 2009, at 10:01 PM, Gorry Fairhurst wrote: > >> >> Here is the revised multimob charter that the WG Chairs have >> prepared based on the various inputs we have received. There are >> many small changes, but we think this process has improved the >> quality and clarity of the text. We both believe this is a strong >> Charter - we are now asking for notes of support, comments, issues, >> etc. >> >> Please let us have all feedback by midnight 1st July 2009. We then >> plan to submit this for publication by our ADs. >> >> Let us know your thoughts, >> >> Behcet and Gorry >> >> -- >> >> Multicast Mobility (multimob) >> >> Chairs: >> Gorry Fairhurst >> Behcet Sarikaya >> >> Internet Area (int) Directors: >> Jari Arkko >> Ralph Droms >> >> Internet Area Advisor: >> Jari Arkko >> >> Security Area Advisor: >> Marshall Eubanks . >> >> Mailing Lists: >> General Discussion: multimob@ietf.org >> Subscribe online at: https://www1.ietf.org/mailman/listinfo/multimob >> >> Description of Working Group >> >> The Multicast mobility (multimob) will develop protocol extensions >> and provide guidance for supporting IPv6 (and also IPv4) >> multicast in a mobile environment. It will consider both source >> specific multicast (SSM) and any source multicast (ASM) multicast >> models. The scope of work will be limited to Proxy Mobile IPv6, MLD/ >> IGMP >> protocols and listener mobility. Work requiring modifications of >> multicast routing protocols is out of scope. >> >> Specific goals are: >> - Specify PMIPv6 extensions to support IPv6 multicast including >> remote subscription and fast handover. >> - Specify IGMP/MLD extensions methods for mobility. >> >> The current Proxy Mobile IPv6 (PMIPv6) specification does not > > [JiK] Scope it explicitly as "The current Proxy Mobile IPv6 (PMIPv6) > base protocol specification as defined in RFC 5213.." > >> >> explicitly define support for multicast. The WG will develop a >> solution >> for explicit multicast support in PMIPv6. Basic support for multicast >> with remote subscription will first be documented for PMIPv6 (with >> no new message types or changes to the message parameters). Remote > > [JiK] I would reword a bit: > "The WG will work on solutions for multicast support in PMIPv6. A > basic support for multicast with a remote subscription will first be > documented. The basic support does not require any additions or > changes to RFC 5213 specified message types and parameters, and > assumes an unmodified mobile host." > > > I would think the "basic support" should explicitly be a minimal > effort, and require no changes to mobile hosts. > > >> >> subscription is a mechanism by which a mobile node joins a multicast >> group and receives multicast data forwarded via the local mobility >> anchor. PMIPv6 basic multicast support will then be extended to >> support >> optimizations to address the avalanche problem and fast handover. > > [JiK] How about: > "PMIPv6 multicast support may later be extended to support.." > > I don't think the "basic support" needs to be extended.. rather the > whole multicast support in PMIPv6 context may be extended with > specific tweaks, and then (later) we can discuss whether those > tweaks are PMIPv6 specific or generic to most wireless environments. > > >> >> >> IGMPv3/MLDv2 has been specified for wired networks with >> shared links. Mobile nodes also have other needs (e.g. entering a >> dormant mode to conserve battery power, minimising the latency for >> joining and leaving a group in support of movement). > > [JiK] The second sentence somehow seems to end too early.. I would > write something like: > "Mobile nodes also have other needs that are specific to wireless > networks and mobility." > > >> >> >> The WG will assess existing solutions for group management, and >> determine if these methods are sufficient in a mobile environment. >> This will include recommending appropriate selection of timer values >> and protocol parameters. If current methods are not sufficient, the >> WG >> shall specify updates to existing protocols. It is a goal for the >> WG to > > [JiK] updates or extensions? > >> >> ensure backward compatibility with current implementations of >> group management protocols. Any new IGMP/MLD message types >> will be specified to optimize mobile performance. Since these > > [JiK] "Any new IGMP/MLD.." is supposed to mean what? Did you mean: > "New IGMP/MLD message types may be specified to optimize performance > in mobile and wireless environments." > > >> >> could be ignored, dropped or improperly forwarded by existing hosts, >> switches, routers and proxies, these will not be necessary for proper >> IGMP/MLD performance, albeit with a partial or total loss of the >> intended performance optimization in deployments that do not fully >> support them. >> >> Future work, subject to approval, may study/evaluate whether >> extensions are needed for the client-based mobility protocols >> (Mobile IPv6 and Dual-Stack Mobile IPv6). Future work may also >> include >> methods to allow a multi-homed mobile node to join multicast >> groups and direct multicast flows to appropriate local interfaces. >> >> In performing this work, the Multimob working group will work closely >> with NETLMM working group and will coordinate work on IGMP/MLD >> extensions with the MBONED working group. >> >> GOALS and MILESTONES: >> >> Six months: >> - Submit a document explaining use of multicast in PMIPv6, for >> publication as an INFO/BCP RFC. >> - Submit a document on how to tune MLD for mobility, for >> publication as an INFO/BCP RFC. >> >> One year: >> - Submit a document on extensions for multicast mobility in PMIPv6 >> as an EXP/PS RFC. >> - Submit a document on IGMP/MLD extensions for multicast mobility >> as an EXP/PS RFC. >> >> Recharter or close working group. > > > [JiK] Ok. > > Cheers, > Jouni > >> >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > Regards Marshall Eubanks CEO / AmericaFree.TV From behcetsarikaya@yahoo.com Tue Jun 30 09:19:45 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D92A3A6973 for ; Tue, 30 Jun 2009 09:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnRLCg4y7WJp for ; Tue, 30 Jun 2009 09:19:42 -0700 (PDT) Received: from n9.bullet.re3.yahoo.com (n9.bullet.re3.yahoo.com [68.142.237.94]) by core3.amsl.com (Postfix) with SMTP id 1C0D83A680D for ; Tue, 30 Jun 2009 09:19:20 -0700 (PDT) Received: from [68.142.237.87] by n9.bullet.re3.yahoo.com with NNFMP; 30 Jun 2009 16:17:43 -0000 Received: from [67.195.9.81] by t3.bullet.re3.yahoo.com with NNFMP; 30 Jun 2009 16:17:43 -0000 Received: from [67.195.9.107] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 30 Jun 2009 16:17:43 -0000 Received: from [127.0.0.1] by omp111.mail.gq1.yahoo.com with NNFMP; 30 Jun 2009 16:17:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 427344.53962.bm@omp111.mail.gq1.yahoo.com Received: (qmail 2176 invoked by uid 60001); 30 Jun 2009 16:17:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246378663; bh=/tHD89/InMbGvVEwIQhkmgBwGSjCX3qnJp7r2ZKSZgw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=jmJTEnByX7jSC9cpRNvW56zJtRVdtl6Wi7je45IUtZRZTICTmYUD9DhXqXgq/Xy2fzLM90vqzrr0cSNvSHN0SsAcCRMdArU2FiB8egdrnr47nUX/K7AbnR6X9+gHjXBQMPKzA/FN49GHGczDqZMKUqyNaibopz1dluhnUq1FboQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=3onb4J/TGbDaJqIjwMbucuEOAKTw+FKdAx/1nPiToE9T3DOg40k0bVX49q7bims5qI+fYNHTqW0+V9ZbssW/hbeFrfD8rdKkcCtCdShzKXlAuG/KSMiy9BLCykiHPpLD05rX8hIxz0eeSE/eLk/OwY0wT/TgiNYa6J2WRCt4WEs=; Message-ID: <216321.1528.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: dJ37qA0VM1kuHCQ.M.hC5EdnWFHQek1sT21ifM5jFXz4MRspQgYTqZ29 Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Tue, 30 Jun 2009 09:17:42 PDT X-Mailer: YahooMailRC/1357.22 YahooMailWebService/0.7.289.15 Date: Tue, 30 Jun 2009 09:17:42 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1244139834-1246378662=:1528" Subject: [multimob] New Charter proposal - draft for approval. X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 16:19:45 -0000 --0-1244139834-1246378662=:1528 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,=0A=A0 This is the new charter incorporating the comments made.=0A= =0ARegards,=0A=0ABehcet=0A=0A=0A --0-1244139834-1246378662=:1528 Content-Type: text/plain; name="multimob_official_v3_charter.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="multimob_official_v3_charter.txt" TXVsdGljYXN0IE1vYmlsaXR5IChtdWx0aW1vYikNCg0KQ2hhaXJzOg0KR29y cnkgRmFpcmh1cnN0IDxnb3JyeUBlcmcuYWJkbi5hYy51az4NCkJlaGNldCBT YXJpa2F5YSA8c2FyaWtheWFAaWVlZS5vcmc+DQoNCkludGVybmV0IEFyZWEg KGludCkgRGlyZWN0b3JzOg0KSmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVo YS5uZXQ+DQpSYWxwaCBEcm9tcyA8cmRyb21zQGNpc2NvLmNvbT4NCg0KSW50 ZXJuZXQgQXJlYSBBZHZpc29yOg0KSmFyaSBBcmtrbyA8amFyaS5hcmtrb0Bw aXVoYS5uZXQ+DQoNClNlY3VyaXR5IEFyZWEgQWR2aXNvcjoNCk1hcnNoYWxs IEV1YmFua3MgPHRtZUBhbWVyaWNhZnJlZS50dj4uDQoNCk1haWxpbmcgTGlz dHM6DQpHZW5lcmFsIERpc2N1c3Npb246IG11bHRpbW9iQGlldGYub3JnDQpT dWJzY3JpYmUgb25saW5lIGF0OiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tdWx0aW1vYg0KDQpEZXNjcmlwdGlvbiBvZiBXb3Jr aW5nIEdyb3VwDQoNClRoZSBNdWx0aWNhc3QgbW9iaWxpdHkgKG11bHRpbW9i KSB3aWxsIGRldmVsb3AgcHJvdG9jb2wgZXh0ZW5zaW9ucw0KYW5kIHByb3Zp ZGUgZ3VpZGFuY2UgZm9yIHN1cHBvcnRpbmcgSVB2NiAoYW5kIGFsc28gSVB2 NCkNCm11bHRpY2FzdCBpbiBhIG1vYmlsZSBlbnZpcm9ubWVudC4gSXQgd2ls bCBjb25zaWRlciBib3RoIHNvdXJjZQ0Kc3BlY2lmaWMgbXVsdGljYXN0IChT U00pIGFuZCBhbnkgc291cmNlIG11bHRpY2FzdCAoQVNNKSBtdWx0aWNhc3QN Cm1vZGVscy4gVGhlIHNjb3BlIG9mIHdvcmsgd2lsbCBiZSBsaW1pdGVkIHRv IFByb3h5IE1vYmlsZSBJUHY2LCBNTEQvSUdNUA0KcHJvdG9jb2xzIGFuZCBs aXN0ZW5lciBtb2JpbGl0eS4gV29yayByZXF1aXJpbmcgbW9kaWZpY2F0aW9u cyBvZg0KbXVsdGljYXN0IHJvdXRpbmcgcHJvdG9jb2xzIGlzIG91dCBvZiBz Y29wZS4NCg0KU3BlY2lmaWMgZ29hbHMgYXJlOg0KLSBTcGVjaWZ5IFBNSVB2 NiBleHRlbnNpb25zIHRvIHN1cHBvcnQgSVB2NiBtdWx0aWNhc3QgaW5jbHVk aW5nIHJlbW90ZSBzdWJzY3JpcHRpb24gYW5kIGZhc3QgaGFuZG92ZXIuDQot IFNwZWNpZnkgSUdNUC9NTEQgZXh0ZW5zaW9ucyBtZXRob2RzIGZvciBtb2Jp bGl0eS4NCg0KVGhlIGN1cnJlbnQgUHJveHkgTW9iaWxlIElQdjYgKFBNSVB2 Nikgc3BlY2lmaWNhdGlvbiBhcyBkZWZpbmVkIGluIFJGQyA1MjEzIGRvZXMg bm90DQpleHBsaWNpdGx5IGRlZmluZSBzdXBwb3J0IGZvciBtdWx0aWNhc3Qu IFRoZSBXRyB3aWxsIHdvcmsgb24gc29sdXRpb25zIGZvciBtdWx0aWNhc3Qg c3VwcG9ydCBpbiBQTUlQdjYuIEEgYmFzaWMgc3VwcG9ydCBmb3IgbXVsdGlj YXN0IHdpdGggYSByZW1vdGUgc3Vic2NyaXB0aW9uIHdpbGwgZmlyc3QgYmUg ZG9jdW1lbnRlZC4gVGhlIGJhc2ljIHN1cHBvcnQgZG9lcyBub3QgcmVxdWly ZSBhbnkgYWRkaXRpb25zIG9yIGNoYW5nZXMgdG8gUkZDIDUyMTMgc3BlY2lm aWVkIG1lc3NhZ2UgdHlwZXMgYW5kIHBhcmFtZXRlcnMsIGFuZCBhc3N1bWVz IGFuIHVubW9kaWZpZWQgbW9iaWxlIGhvc3QuICBSZW1vdGUNCnN1YnNjcmlw dGlvbiBpcyBhIG1lY2hhbmlzbSBieSB3aGljaCBhIG1vYmlsZSBub2RlIGpv aW5zIGEgbXVsdGljYXN0DQpncm91cCBhbmQgcmVjZWl2ZXMgbXVsdGljYXN0 IGRhdGEgZm9yd2FyZGVkIHZpYSB0aGUgbG9jYWwgbW9iaWxpdHkNCmFuY2hv ci4gUE1JUHY2IG11bHRpY2FzdCBzdXBwb3J0IG1heSBsYXRlciBiZSBleHRl bmRlZCB0byBzdXBwb3J0DQpvcHRpbWl6YXRpb25zIHRvIGFkZHJlc3MgdGhl IGF2YWxhbmNoZSBwcm9ibGVtIGFuZCBmYXN0IGhhbmRvdmVyLg0KDQpJR01Q djMvTUxEdjIgaGFzIGJlZW4gc3BlY2lmaWVkIGZvciB3aXJlZCBuZXR3b3Jr cyB3aXRoDQpzaGFyZWQgbGlua3MuIE1vYmlsZSBub2RlcyBhbHNvIGhhdmUg b3RoZXIgbmVlZHMgdGhhdCBhcmUgc3BlY2lmaWMgdG8gd2lyZWxlc3MgbmV0 d29ya3MgYW5kIG1vYmlsaXR5IChlLmcuICBlbnRlcmluZyBhIGRvcm1hbnQg bW9kZSB0byBjb25zZXJ2ZSBiYXR0ZXJ5IHBvd2VyLCBtaW5pbWlzaW5nIHRo ZSBsYXRlbmN5IGZvcg0Kam9pbmluZyBhbmQgbGVhdmluZyBhIGdyb3VwIGlu IHN1cHBvcnQgb2YgbW92ZW1lbnQpLg0KDQpUaGUgV0cgd2lsbCBhc3Nlc3Mg ZXhpc3Rpbmcgc29sdXRpb25zIGZvciBncm91cCBtYW5hZ2VtZW50LCBhbmQN CmRldGVybWluZSBpZiB0aGVzZSBtZXRob2RzIGFyZSBzdWZmaWNpZW50IGlu IGEgbW9iaWxlIGVudmlyb25tZW50Lg0KVGhpcyB3aWxsIGluY2x1ZGUgcmVj b21tZW5kaW5nIGFwcHJvcHJpYXRlIHNlbGVjdGlvbiBvZiB0aW1lciB2YWx1 ZXMNCmFuZCBwcm90b2NvbCBwYXJhbWV0ZXJzLiBJZiBjdXJyZW50IG1ldGhv ZHMgYXJlIG5vdCBzdWZmaWNpZW50LCB0aGUgV0cNCnNoYWxsIHNwZWNpZnkg ZXh0ZW5zaW9ucyB0byBleGlzdGluZyBwcm90b2NvbHMuIEl0IGlzIGEgZ29h bCBmb3IgdGhlIFdHIHRvDQplbnN1cmUgYmFja3dhcmQgY29tcGF0aWJpbGl0 eSB3aXRoIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIG9mDQpncm91cCBtYW5h Z2VtZW50IHByb3RvY29scy4gTmV3IElHTVAvTUxEIG1lc3NhZ2UgdHlwZXMg bWF5IGJlIHNwZWNpZmllZCB0byBvcHRpbWl6ZSBwZXJmb3JtYW5jZSBpbiBt b2JpbGUgYW5kIHdpcmVsZXNzIGVudmlyb25tZW50cy4gU2luY2UgdGhlc2UN CmNvdWxkIGJlIGlnbm9yZWQsIGRyb3BwZWQgb3IgaW1wcm9wZXJseSBmb3J3 YXJkZWQgYnkgZXhpc3RpbmcgaG9zdHMsDQpzd2l0Y2hlcywgcm91dGVycyBh bmQgcHJveGllcywgdGhlc2Ugd2lsbCBub3QgYmUgbmVjZXNzYXJ5IGZvciBw cm9wZXINCklHTVAvTUxEIHBlcmZvcm1hbmNlLCBhbGJlaXQgd2l0aCBhIHBh cnRpYWwgb3IgdG90YWwgbG9zcyBvZiB0aGUNCmludGVuZGVkIHBlcmZvcm1h bmNlIG9wdGltaXphdGlvbiBpbiBkZXBsb3ltZW50cyB0aGF0IGRvIG5vdCBm dWxseQ0Kc3VwcG9ydCB0aGVtLg0KDQpGdXR1cmUgd29yaywgc3ViamVjdCB0 byBhcHByb3ZhbCwgbWF5IHN0dWR5L2V2YWx1YXRlIHdoZXRoZXINCmV4dGVu c2lvbnMgYXJlIG5lZWRlZCBmb3IgdGhlIGNsaWVudC1iYXNlZCBtb2JpbGl0 eSBwcm90b2NvbHMNCihNb2JpbGUgSVB2NiBhbmQgRHVhbC1TdGFjayBNb2Jp bGUgSVB2NikuIEZ1dHVyZSB3b3JrIG1heSBhbHNvIGluY2x1ZGUgcHJvdG9j b2wgZXh0ZW5zaW9ucyB0byBzdXBwb3J0IHNvdXJjZSBtb2JpbGl0eSBhbmQN Cm1ldGhvZHMgdG8gYWxsb3cgYSBtdWx0aS1ob21lZCBtb2JpbGUgbm9kZSB0 byBqb2luIG11bHRpY2FzdA0KZ3JvdXBzLCAgYW5kIGRpcmVjdCBtdWx0aWNh c3QgZmxvd3MgdG8gYXBwcm9wcmlhdGUgbG9jYWwgaW50ZXJmYWNlcy4NCg0K SW4gcGVyZm9ybWluZyB0aGlzIHdvcmssIHRoZSBNdWx0aW1vYiB3b3JraW5n IGdyb3VwIHdpbGwgd29yayBjbG9zZWx5DQp3aXRoIE5FVExNTSB3b3JraW5n IGdyb3VwIGFuZCB3aWxsIGNvb3JkaW5hdGUgd29yayBvbiBJR01QL01MRA0K ZXh0ZW5zaW9ucyB3aXRoIHRoZSBNQk9ORUQgd29ya2luZyBncm91cC4NCg0K R09BTFMgYW5kIE1JTEVTVE9ORVM6DQoNClNpeCBtb250aHM6DQotIFN1Ym1p dCBhIGRvY3VtZW50IGV4cGxhaW5pbmcgdXNlIG9mIG11bHRpY2FzdCBpbiBQ TUlQdjYsIGZvciBwdWJsaWNhdGlvbiBhcyBhbiBJTkZPL0JDUCBSRkMuDQot IFN1Ym1pdCBhIGRvY3VtZW50IG9uIGhvdyB0byB0dW5lIE1MRCBmb3IgbW9i aWxpdHksIGZvciBwdWJsaWNhdGlvbiBhcyBhbiBJTkZPL0JDUCBSRkMuDQoN Ck9uZSB5ZWFyOg0KLSBTdWJtaXQgYSBkb2N1bWVudCBvbiBleHRlbnNpb25z IGZvciBtdWx0aWNhc3QgbW9iaWxpdHkgaW4gUE1JUHY2IGFzIGFuIEVYUC9Q UyBSRkMuDQotIFN1Ym1pdCBhIGRvY3VtZW50IG9uIElHTVAvTUxEIGV4dGVu c2lvbnMgZm9yIG11bHRpY2FzdCBtb2JpbGl0eSBhcyBhbiBFWFAvUFMgUkZD Lg0KDQpSZWNoYXJ0ZXIgb3IgY2xvc2Ugd29ya2luZyBncm91cC4NCg== --0-1244139834-1246378662=:1528-- From behcetsarikaya@yahoo.com Tue Jun 30 10:50:25 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5D5D3A6C33 for ; Tue, 30 Jun 2009 10:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIYUs7XA5Q6V for ; Tue, 30 Jun 2009 10:50:24 -0700 (PDT) Received: from n62a.bullet.mail.sp1.yahoo.com (n62a.bullet.mail.sp1.yahoo.com [98.136.45.9]) by core3.amsl.com (Postfix) with SMTP id 2125E3A63CB for ; Tue, 30 Jun 2009 10:50:24 -0700 (PDT) Received: from [216.252.122.216] by n62.bullet.mail.sp1.yahoo.com with NNFMP; 30 Jun 2009 17:50:35 -0000 Received: from [67.195.9.82] by t1.bullet.sp1.yahoo.com with NNFMP; 30 Jun 2009 17:50:35 -0000 Received: from [67.195.9.100] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 30 Jun 2009 17:50:35 -0000 Received: from [127.0.0.1] by omp104.mail.gq1.yahoo.com with NNFMP; 30 Jun 2009 17:50:26 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 365355.17577.bm@omp104.mail.gq1.yahoo.com Received: (qmail 36798 invoked by uid 60001); 30 Jun 2009 17:50:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246384235; bh=DeYUQZH2TiCYbNgX8K/7n55o6RdxizBWp1yeevM8vu0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Q7j5nZSyxwdt6zrnckdInwI6XdmjgjKY0R/nPsGaRKd5/Wr/WcExv5Nr8MpUu6mM1AFJKUAaP485H8I7vgdyU8gKRBf/1lRldgCJKKnXrb8vvJ7/MNCCayHednwTI2TJxo6qDdQCqpv1wIxlWls7z1vMhDv/RUoa8BB3chESTLA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=b239ZJFmUFMWmjhSaXnN20+TLqOnZ55/RYkMZghBFVERH5xkRkPi+mRAW0UJbyNwUd1VEWfb/Vy+R2eTOZfT/EFFjwjvzrhB3L9o50ko8y0i4bD8Ux7mulVdje627ik3FdwKVFo6YsaiYXH7FpNLSj/W4YJKI+00xmFNbIyb19k=; Message-ID: <181372.10533.qm@web111408.mail.gq1.yahoo.com> X-YMail-OSG: JnThvp0VM1nFJpN8Jx..AtxY.6vuz6TcI5wPYFVG789O8PWzcQIQKIgrWnh3zqS1sjHTQE7W7xeB2UdTMuLdS0NM_XB9O6FdO4jGwX0q3RcNasO3yCJlf2CXEeAQbxxU7HigIaggXnaVYzP6k_uMdkf1MEmIkKyArV5uWHM2aufnUflwWJAPfQtOVPNFhsbTJCdLi36TDNH_E5SqPoplTo5URPB4oqMkQFrqCsqFahFXisdRc51Uav9xkKLfeddoc6hyNIlPuoYb.VKqQc3l9_Fd9fM7RZhPsGJ13wlu6KIzsmJeMdpZNqklyq1_8EViOHHd2_0Ids4IS7COQiLgdpQ- Received: from [206.16.17.212] by web111408.mail.gq1.yahoo.com via HTTP; Tue, 30 Jun 2009 10:50:35 PDT X-Mailer: YahooMailRC/1357.22 YahooMailWebService/0.7.289.15 References: <4A490F9A.8090206@erg.abdn.ac.uk> <20090630.112241.47233712.asaeda@sfc.wide.ad.jp> Date: Tue, 30 Jun 2009 10:50:35 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda In-Reply-To: <20090630.112241.47233712.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] New Charter proposal - draft for approval. X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 17:50:26 -0000 =0A=0A=0A=0A----- Original Message ----=0A> From: Hitoshi Asaeda =0A> To: jouni.nospam@gmail.com=0A> Cc: multimob@ietf.org=0A> = Sent: Tuesday, June 30, 2009 4:22:41 AM=0A> Subject: Re: [multimob] New Cha= rter proposal - draft for approval.=0A> =0A> Jouni,=0A> =0A> > > anchor. PM= IPv6 basic multicast support will then be extended to support=0A> > > optim= izations to address the avalanche problem and fast handover.=0A> > =0A> > [= JiK] How about:=0A> > "PMIPv6 multicast support may later be extended to su= pport.."=0A> =0A> My personal thought is that the protocol extensions can b= e discussed=0A> in parallel, and hence I may say "protocol extensions for P= MIPv6=0A> multicast will be also discussed to support optimization to addre= ss=0A> the avalanche problems and fast handover." would be better.=0A=0AWe = can discuss issues on the list. We don't have to write=A0what will be discu= ssed into the charter.=0A=0AI hope you agree with this.=0A=0ARegards,=0A=0A= Behcet=0A=0A=0A=0A From behcetsarikaya@yahoo.com Tue Jun 30 15:08:41 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E433A6D03 for ; Tue, 30 Jun 2009 15:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APXl82w0WRkp for ; Tue, 30 Jun 2009 15:08:40 -0700 (PDT) Received: from n1.bullet.mail.re3.yahoo.com (n1.bullet.mail.re3.yahoo.com [68.142.237.108]) by core3.amsl.com (Postfix) with SMTP id 92A933A6C1A for ; Tue, 30 Jun 2009 15:08:40 -0700 (PDT) Received: from [68.142.230.28] by n1.bullet.mail.re3.yahoo.com with NNFMP; 30 Jun 2009 22:08:59 -0000 Received: from [67.195.9.82] by t1.bullet.re2.yahoo.com with NNFMP; 30 Jun 2009 22:08:59 -0000 Received: from [67.195.9.100] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 30 Jun 2009 22:08:59 -0000 Received: from [127.0.0.1] by omp104.mail.gq1.yahoo.com with NNFMP; 30 Jun 2009 22:08:50 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 544497.76585.bm@omp104.mail.gq1.yahoo.com Received: (qmail 85081 invoked by uid 60001); 30 Jun 2009 22:08:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246399739; bh=C0lhCVxLJGlVnGENvzBjIdJhVUJSdvNjyQZt0PRW5XY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=M8vJoP2sfi7bcWeyi9CvDDaklF5DCFXnp1WnfK2CsLNqFZU1dU08T9f7Amqa1P72g268I9pot9RMzo+l23w9bZY/WK8bjbRCClW8XBxVCN98cFBSBu2dGMl63I/iLdhkFX6J1kzpc2hsK4MVL+QlMZI0o/JIk6JH48TX/Rp6K8U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bZSvjuEpuG9B4OjDpnyBhXOzKVpusGpGGoN2O50r+CmIRLIoCt2wQ9c/HVnxxgaPz/w78UHbEkwA2ZBQM1ZeTuz7rcUsno9NY80KrHWo80ghY44ichabtu9cuIF4rGUviIMRvYPALw5OQwhnxryYACgI7Zn6hdyUQUIMvIzZkFg=; Message-ID: <364018.83135.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: B1RWdGsVM1mhXHSOf4c2H8VpX7ZuuVcnKjk832nCU9WZWve4j.xLdIIC5hzz9ooaEajqm52oREhp91H9y2PdVGfhUHbA09tpJBNhwKxFsbYkeKUEw022T41Ft5z_R.8dUW8_xBJIGKxleCqCTcKtix32OrYxEEpgvMH3c5y.7w8vWsd7FVREdpJ0ZHvlPI9Ktv9qG6QqLaECLH34je66r.nu4Q.2yJ_cTXCR1xhKhRNkZffM5le16y9T5tB5nHG0G8NzpLPy1H3V1cD7WsULT6U9JpV45N52YM03okQS3C.IdJi8lqM2qL3cj.rzkFrkXcYo80oZw9IVwzwkwiVK00FZIw-- Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Tue, 30 Jun 2009 15:08:59 PDT X-Mailer: YahooMailRC/1357.22 YahooMailWebService/0.7.289.15 References: <20090630.112241.47233712.asaeda@sfc.wide.ad.jp> <181372.10533.qm@web111408.mail.gq1.yahoo.com> <20090630.234555.225018119.asaeda@sfc.wide.ad.jp> Date: Tue, 30 Jun 2009 15:08:59 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda , multimob@ietf.org In-Reply-To: <20090630.234555.225018119.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] New Charter proposal - draft for approval. X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 22:08:41 -0000 Hi Hitoshi,=0A=0A=0A=0A----- Original Message ----=0A> From: Hitoshi Asaeda= =0A> To: sarikaya@ieee.org; behcetsarikaya@yahoo.co= m=0A> Cc: gorry@erg.abdn.ac.uk=0A> Sent: Tuesday, June 30, 2009 4:45:55 PM= =0A> Subject: Re: [multimob] New Charter proposal - draft for approval.=0A>= =0A> > > > [JiK] How about:=0A> > > > "PMIPv6 multicast support may later = be extended to support.."=0A> > > =0A> > > My personal thought is that the = protocol extensions can be discussed=0A> > > in parallel, and hence I may s= ay "protocol extensions for PMIPv6=0A> > > multicast will be also discussed= to support optimization to address=0A> > > the avalanche problems and fast= handover." would be better.=0A> > =0A> > We can discuss issues on the list= .. We don't have to write=A0what will=0A> > be discussed into the charter.= =0A> > =0A> > I hope you agree with this.=0A> =0A> Hmm, you've still not un= derstood what I mean...=0A> =0A> Now in the charter,=0A> - Specify PMIPv6 e= xtensions to support IPv6 multicast including remote=0A> subscription and f= ast handover.=0A> This means "we will provide protocol extension".=0A=0AThi= s is a goal or one of the goals, just like IGMP/MLD goal.=0A=0A> =0A> But i= n the charter, you said "PMIPv6 multicast support *may later* be=0A> extend= ed". It means we may not propose protocol extension. It's=0A> contradictory= ..=0A> =0A> Hence I proposed to say, "protocol extensions for PMIPv6 multica= st=0A> will be also discussed to support optimization to address the=0A> av= alanche problems and fast handover.=0A> Here, as Jouni said, if it's better= to change the word "discussed" to=0A> "studied", it's no problem. You can = change it.=0A=0APotocol extensions for PMIPv6 multicast will be studied=A0 = to support=0Aoptimizations to address the avalanche problem and fast handov= er.=0A=0AWhat do you think about the above?=0A=0ARegards,=0A=0ABehcet=0A=0A= =0A From asaeda@sfc.wide.ad.jp Tue Jun 30 15:23:19 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F009E3A6EC8 for ; Tue, 30 Jun 2009 15:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZrGNUH-or2i for ; Tue, 30 Jun 2009 15:23:19 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 3B6643A6AAF for ; Tue, 30 Jun 2009 15:23:18 -0700 (PDT) Received: from localhost (ATuileries-153-1-16-145.w82-123.abo.wanadoo.fr [82.123.247.145]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 4956B13D06C8; Wed, 1 Jul 2009 07:23:29 +0900 (JST) Date: Wed, 01 Jul 2009 00:23:23 +0200 (CEST) Message-Id: <20090701.002323.178081913.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <364018.83135.qm@web111403.mail.gq1.yahoo.com> References: <181372.10533.qm@web111408.mail.gq1.yahoo.com> <20090630.234555.225018119.asaeda@sfc.wide.ad.jp> <364018.83135.qm@web111403.mail.gq1.yahoo.com> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] New Charter proposal - draft for approval. X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 22:23:20 -0000 Behcet, > Potocol extensions for PMIPv6 multicast will be studied=A0 to support= > optimizations to address the avalanche problem and fast handover. > = > What do you think about the above? Thanks. Yes, it's good. BTW (sorry, again, I hope this is the last comment), = "Remote subscription is a mechanism by which a mobile node joins a multicast group and receives multicast data forwarded via the local mobility anchor." Is this definition for "remote subscription" correct? -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Tue Jun 30 15:41:39 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67EA73A6A17 for ; Tue, 30 Jun 2009 15:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96hx+g5T8KDO for ; Tue, 30 Jun 2009 15:41:38 -0700 (PDT) Received: from n65.bullet.mail.sp1.yahoo.com (n65.bullet.mail.sp1.yahoo.com [98.136.44.190]) by core3.amsl.com (Postfix) with SMTP id BF0423A69DC for ; Tue, 30 Jun 2009 15:41:38 -0700 (PDT) Received: from [216.252.122.219] by n65.bullet.mail.sp1.yahoo.com with NNFMP; 30 Jun 2009 22:41:03 -0000 Received: from [67.195.9.83] by t4.bullet.sp1.yahoo.com with NNFMP; 30 Jun 2009 22:41:03 -0000 Received: from [67.195.9.101] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 30 Jun 2009 22:41:03 -0000 Received: from [127.0.0.1] by omp105.mail.gq1.yahoo.com with NNFMP; 30 Jun 2009 22:41:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 495130.61527.bm@omp105.mail.gq1.yahoo.com Received: (qmail 758 invoked by uid 60001); 30 Jun 2009 22:41:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246401663; bh=RVFI9yYEffaWJyNBw6g2uV1G88bTGaKa2ivDSlNiRhI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gdBiDQLGAwlXBvOBhX7XML8WHiHcG2avASWKCaXU89sAEIgUe/WH7oK5D2S6T03OzfwC5JrJEcIiSP1M+x1pv+MXsoHX6wkMz5Wq0SJLjSXOgJsUHPZIdZ0FPPdxmSzR3PbmElj+MZcG8C5ihn0jvkwvcsrP3J5DjLqVqYYVA44= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6p47NuZNsatH4Sr5vgdqXKNkQ751y0UIEOKZpAufdc4/p3GwOKNhIHteXFPT9cUnRBl3kQqz1nTLZ+O28HI+2OLA1C3BTNWVpZSg44BKvly7AHVf47dwflzjuIiR1Ha63x5VWdG+gdr8VUvsIAhpQWd/c17a92ZqyZXUEbyK89Q=; Message-ID: <243649.692.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: Jssra7wVM1ksMDCV4uzJCE2LDHzvz2tAeTGt8ZYeCAzDLKQgwBCMBgHhK1Fw1_6AT0r_G4KDaKyqzA2lGeq8GfoiDo0OXovu3HdZW6TjJU3nzpqRfNKc2VjKA4_Jj86jsEoYErLyGoZKfi6Vnl_fkVRjgWdUmBblAulW_y6K_wHa6LCwNj2ZpYpJIViFQCVdzZpV8OjI8ZvIPGEo75RBRP..41pvStdK6NXzKTGtL6bz7G1q_nWcn_k2TCwARa9HkrUYgShpt3mVfFJaddZGR5b2Hga4y3ibtV8g7sJ7gc8WWsk6umrsH2l_..1O9Be5L3okm5fJJ3c3iAxEoDCPM0E- Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Tue, 30 Jun 2009 15:41:02 PDT X-Mailer: YahooMailRC/1357.22 YahooMailWebService/0.7.289.15 References: <181372.10533.qm@web111408.mail.gq1.yahoo.com> <20090630.234555.225018119.asaeda@sfc.wide.ad.jp> <364018.83135.qm@web111403.mail.gq1.yahoo.com> <20090701.002323.178081913.asaeda@sfc.wide.ad.jp> Date: Tue, 30 Jun 2009 15:41:02 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda In-Reply-To: <20090701.002323.178081913.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] New Charter proposal - draft for approval. X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 22:41:39 -0000 =0A=0A=0A=0A----- Original Message ----=0A> From: Hitoshi Asaeda =0A> To: sarikaya@ieee.org; behcetsarikaya@yahoo.com=0A> Cc: m= ultimob@ietf.org=0A> Sent: Tuesday, June 30, 2009 5:23:23 PM=0A> Subject: R= e: [multimob] New Charter proposal - draft for approval.=0A> =0A> Behcet,= =0A> =0A> > Potocol extensions for PMIPv6 multicast will be studied=A0 to s= upport=0A> > optimizations to address the avalanche problem and fast handov= er.=0A> > =0A> > What do you think about the above?=0A> =0A> Thanks. Yes, i= t's good.=0A> =0A> BTW (sorry, again, I hope this is the last comment), =0A= > "Remote subscription is a mechanism by which a mobile node joins a=0A> mu= lticast group and receives multicast data forwarded via the local=0A> mobil= ity anchor."=0A> =0A> Is this definition for "remote subscription" correct?= =0A=0AYes, I think so, in the context of PMIPv6.=0ADo you have a better des= cription?=0A=0ARegards,=0A=0ABehcet=0A=0A=0A