From waehlisch@ieee.org Tue Dec 1 04:50: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 ACF333A68D4 for ; Tue, 1 Dec 2009 04:50:00 -0800 (PST) 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 4Vje3L23nQ3Q for ; Tue, 1 Dec 2009 04:50:00 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id D51B53A6808 for ; Tue, 1 Dec 2009 04:49:59 -0800 (PST) Envelope-to: multimob@ietf.org Received: from dhcp68.rm.cnr.it ([150.146.113.68] helo=mw-thinkpad.convegni.cnr.it) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NFSAx-000O3X-5u; Tue, 01 Dec 2009 13:49:51 +0100 Date: Tue, 1 Dec 2009 13:49:48 +0100 From: Matthias Waehlisch To: Behcet Sarikaya In-Reply-To: <32617.6250.qm@web111412.mail.gq1.yahoo.com> Message-ID: References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> <74406.71791.qm@web111411.mail.gq1.yahoo.com> <383491.68900.qm@web111405.mail.gq1.yahoo.com> <32617.6250.qm@web111412.mail.gq1.yahoo.com> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="566512718-16127-1259671788=:960" X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 01 Dec 2009 12:50:00 -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. --566512718-16127-1259671788=:960 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Behcet, On Mon, 30 Nov 2009, Behcet Sarikaya wrote: >=A0 Is host interface a tunnel interface? > > My answer is no. Tell me if your answer is yes? > not mandatory, but it may be a tunnel interface. The difference notation= =20 -- "Host interface" and "Router interfaces" -- results from the different= =20 roles of the proxy ... If you are afflicted by doubts, please ask your question within the=20 MAGMA mailing list. They should definitely know the answer. > So I think this closes the discussion. > Hopefully. Regards matthias --=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 --566512718-16127-1259671788=:960-- From stig@venaas.com Tue Dec 1 05:16:15 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 B3FAF28C363 for ; Tue, 1 Dec 2009 05:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.568 X-Spam-Level: X-Spam-Status: No, score=-1.568 tagged_above=-999 required=5 tests=[AWL=-1.032, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=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 1LNJVaJ94BtO for ; Tue, 1 Dec 2009 05:15:50 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id CAFA328C55F for ; Tue, 1 Dec 2009 05:11:36 -0800 (PST) Received: from [10.21.88.48] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTP id 2D5FA33B6A; Tue, 1 Dec 2009 14:11:23 +0100 (CET) Message-ID: <4B15159D.7030909@venaas.com> Date: Tue, 01 Dec 2009 05:09:49 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Matthias Waehlisch References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> <74406.71791.qm@web111411.mail.gq1.yahoo.com> <383491.68900.qm@web111405.mail.gq1.yahoo.com> <32617.6250.qm@web111412.mail.gq1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 01 Dec 2009 13:16:15 -0000 Matthias Waehlisch wrote: > Hi Behcet, > > On Mon, 30 Nov 2009, Behcet Sarikaya wrote: > >> Is host interface a tunnel interface? >> >> My answer is no. Tell me if your answer is yes? >> > not mandatory, but it may be a tunnel interface. The difference notation > -- "Host interface" and "Router interfaces" -- results from the different > roles of the proxy ... The thing is that the proxy draft doesn't talk about link types at all. Why should it care if POS, Ethernet, GRE tunnel or whatever? It doesn't change how the proxy operates. Just like say PIM or OSPF RFCs doesn't specify link types. What link or interface types you have do not matter. > If you are afflicted by doubts, please ask your question within the > MAGMA mailing list. They should definitely know the answer. You could certainly ask there if you like. It might actually be a better place than this list :) I think we should start focusing on coming up with a best possible MLD proxy proposal, there was consensus at our meeting for that to be the direction to go for the basic multicast solution. Stig > >> So I think this closes the discussion. >> > Hopefully. > > > > Regards > matthias > > > > ------------------------------------------------------------------------ > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Tue Dec 1 07:54: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 8E24B3A68F7 for ; Tue, 1 Dec 2009 07:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.261, 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 6bLAEV5E-zf0 for ; Tue, 1 Dec 2009 07:54:27 -0800 (PST) Received: from web111416.mail.gq1.yahoo.com (web111416.mail.gq1.yahoo.com [67.195.15.222]) by core3.amsl.com (Postfix) with SMTP id CE3B63A6782 for ; Tue, 1 Dec 2009 07:54:27 -0800 (PST) Received: (qmail 96121 invoked by uid 60001); 1 Dec 2009 15:54:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259682858; bh=Kx+4mULtouqB7G2Qglh/apnUJdjsH1Ak1/oRyCBMU0o=; 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=5UtNdCTGwsiw5mmImTS7ler2fgSP1KtPlOm8tXoUuiizq0tHVtXSlXGZAcnTYlMJaJL5rGdhbk1+BkHFv9d+OOhPG7xgVzZb8O+M8tOzL7kOB30r9bPpPDJjgle8wG16o3BzjOR1tZmjnEpdSYgYPXkGgHjJz7x18rYVTJUwcjw= 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=FVMH0ID1oHJaqxU2fTcpX2zetD+h5/Xoawor2oy5kwpvvtXcU4FbB5OEAhZbDmafjDwtmqbrNbEHHI/ofvJ4r21mTLYFZHoge2vwS1WMsQRvRsT0izXEvI4H4ri9oQnIcg3vjQjmzqsAcjU9Gyi1Ets01c7iKZseDYYR+/fBMcY=; Message-ID: <211302.96096.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: aLGcn7IVM1l8wllAbcqxgQi5G7Uo.pJBXVP9BuVfMX4JOxcwSRvL7OQk9o4DopyGYkNbRxH_dmEnklYZ4LPa5Hx2eWLK_l1pJK8.g7RbEcyWrHbf5ks0lR3l_ivGFsLOzS22F2kdO1gFhVOsWHlPioOOZPqNDNGpHPOt6T2mvE4Gb.EIBf8iBUssW9KyqxbGD4XoxblJI8mNrPAgA_QnFNteVCju6AEaFJS7vV4hJyJL3tjVkqm0HutrZzgfrMu3wetjIbllbNAzz5_e6lZ6NbnI70m0AYjmByke7letKgj7n70QKKHjQkIpccKv1SmTFJw8Kv08AE.TQeKnh1m7LGrdNP5Pbk6ViIX_sElk Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Tue, 01 Dec 2009 07:54:17 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> <74406.71791.qm@web111411.mail.gq1.yahoo.com> <383491.68900.qm@web111405.mail.gq1.yahoo.com> <32617.6250.qm@web111412.mail.gq1.yahoo.com> Date: Tue, 1 Dec 2009 07:54:17 -0800 (PST) From: Behcet Sarikaya To: Matthias Waehlisch In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 01 Dec 2009 15:54:28 -0000 =0A=0A=0A=0A----- Original Message ----=0A> From: Matthias Waehlisch =0A> To: Behcet Sarikaya =0A> Cc: multimob= @ietf.org=0A> Sent: Tue, December 1, 2009 6:49:48 AM=0A> Subject: Re: [mult= imob] IGMP/MLD Proxy at the MAG=0A> =0A> Hi Behcet,=0A> =0A> On Mon, 30 Nov= 2009, Behcet Sarikaya wrote:=0A> =0A> >=A0 Is host interface a tunnel inte= rface?=0A> >=0A> > My answer is no. Tell me if your answer is yes?=0A> >=0A= > =A0 not mandatory, but it may be a tunnel interface. The difference notat= ion =0A> -- "Host interface" and "Router interfaces" -- results from the di= fferent =0A> roles of the proxy ...=0A> =0A> =A0 If you are afflicted by do= ubts, please ask your question within the =0A> MAGMA mailing list. They sho= uld definitely know the answer.=0A=0ASo I think we are in agreement :).=0AY= es it may be but it is not as defined in RFC 4605.=0A=0AAs I said many time= s,=A0it is=A0a protocol extension to have this interface=A0as tunneling int= erface.=0A=0A=A0I think that=A0we are all agreeing on this, right?=0A=0AReg= ards,=0A=0ABehcet=0A=0A=0A=0A From schmidt@informatik.haw-hamburg.de Tue Dec 1 08:15: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 ED86E28C0EB for ; Tue, 1 Dec 2009 08:15:44 -0800 (PST) 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 Ikz6F3gcNZEt for ; Tue, 1 Dec 2009 08:15:43 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 8E9F13A68B9 for ; Tue, 1 Dec 2009 08:15:42 -0800 (PST) Envelope-to: multimob@ietf.org Received: from dhcp172.rm.cnr.it ([150.146.113.172]) by mail2.rz.htw-berlin.de with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NFVO2-0000Y6-92; Tue, 01 Dec 2009 17:15:34 +0100 Message-ID: <4B15411E.1030309@informatik.haw-hamburg.de> Date: Tue, 01 Dec 2009 17:15:26 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behcet Sarikaya References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> <74406.71791.qm@web111411.mail.gq1.yahoo.com> <383491.68900.qm@web111405.mail.gq1.yahoo.com> <32617.6250.qm@web111412.mail.gq1.yahoo.com> <211302.96096.qm@web111416.mail.gq1.yahoo.com> In-Reply-To: <211302.96096.qm@web111416.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 01 Dec 2009 16:15:45 -0000 Hi, seems this debate is not coming to an end ... see below. Behcet Sarikaya wrote: > > > > ----- Original Message ---- >> From: Matthias Waehlisch >> To: Behcet Sarikaya >> Cc: multimob@ietf.org >> Sent: Tue, December 1, 2009 6:49:48 AM >> Subject: Re: [multimob] IGMP/MLD Proxy at the MAG >> >> Hi Behcet, >> >> On Mon, 30 Nov 2009, Behcet Sarikaya wrote: >> >>> Is host interface a tunnel interface? >>> >>> My answer is no. Tell me if your answer is yes? >>> >> not mandatory, but it may be a tunnel interface. The difference notation >> -- "Host interface" and "Router interfaces" -- results from the different >> roles of the proxy ... >> >> If you are afflicted by doubts, please ask your question within the >> MAGMA mailing list. They should definitely know the answer. > > So I think we are in agreement :). > Yes it may be but it is not as defined in RFC 4605. > > As I said many times, it is a protocol extension to have this interface as tunneling interface. > > I think that we are all agreeing on this, right? > Definitely *not*. Behcet: Matthias & Stig are trying to explain to you patiently and in many emails what the meaning of an IP interface of a router is. You are looking at the link type, which is layer 2 ... virtual or physical. Putting it more direct: you are in the wrong movie, largely missing the context. I guess: now we can end the discussion finally. 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 Tue Dec 1 08:34: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 1EC423A68FD for ; Tue, 1 Dec 2009 08:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.246, 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 gnu2fxkdxeif for ; Tue, 1 Dec 2009 08:34:22 -0800 (PST) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id 474B53A68D6 for ; Tue, 1 Dec 2009 08:34:22 -0800 (PST) Received: (qmail 69173 invoked by uid 60001); 1 Dec 2009 16:34:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259685252; bh=o8/ki10LgvZW6STnldpHHTCXYXOg1+1liGrK3fMdE5s=; 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=a3Dfu+pte9k7ddPZHlUliFIG4nZGfDPn4JoIKjnk1duJRqaRLZ/fF8Gs8373OCH2N07vnO3yNSTKKciTemWiUpC0UhyzyCZJ7r0w59sgbxNYVtl8GLv7t6pE9iwg/rFOxAcWwKvUbx7ajJfkTQw/E2iNm7tcoVcUEKdbJwUZffw= 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=ijL1ZUvPN+xLfaTuzR3VHvFv4Uc4qjf8XiQFwWXftRtltOv96A7hqI4Bid2L5ez95SV3fXT3TKOEHrJ2zc3Pwxd2SzK86onAM/NP4oFxIA1hKLlTX94nJyI8ZxNytOvvYcQYSenNX75c5fdZDOI2TfHNoYE6UH1Rqp8c9zCSK9A=; Message-ID: <501852.67838.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: e.O6u34VM1nYqYI2Mwy.wC3rDDq8W3f6HX6UJOy0cKag343mJiueAiZPZ0VlJ6jmT8.B__Pib9eL.VqMwc2dSjFy9kprkAef6qmegutrEZ0acvNYvAvOSn6RuaTphoB7zyd8DtL9RvkxARXhoMxQxUWGPIO6uWZxdFWUKYofkDrdst_fWK5nlLNPlMLd6txGKim_PuitTHX9qiFh67ATrvE5dxRQJS.LLZ3LBJvSuxj5FLlyt2bUBtnvJNOHgnlx8SxRSPoq5fNgLKvxTPnSK6I_8wpdZ1JWnzjPDAIUN_wL13oKWnntELtD01aWtnD1e9TlUyzdKCaJNVco_ZS2G7nRgBqjvRCiBS0.VZlg2yIgn93af8HdigTccU_03DOx4BRuF0QEn5YArJvi_Nkmoo4GKb_w869zzQpBlwgh.agY8gMo8OS8Aw-- Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Tue, 01 Dec 2009 08:34:12 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> <74406.71791.qm@web111411.mail.gq1.yahoo.com> <383491.68900.qm@web111405.mail.gq1.yahoo.com> <32617.6250.qm@web111412.mail.gq1.yahoo.com> <211302.96096.qm@web111416.mail.gq1.yahoo.com> <4B15411E.1030309@informatik.haw-hamburg.de> Date: Tue, 1 Dec 2009 08:34:12 -0800 (PST) From: Behcet Sarikaya To: "Thomas C. Schmidt" In-Reply-To: <4B15411E.1030309@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 01 Dec 2009 16:34:23 -0000 Hi Thomas,=0A=A0 I think you should be patient and agree with the right thi= ng.=0A=0AI have never said we can not do this extension. In my reply to you= I said we can do this extension =0A=0Abut not at the base protocol design = stage.=0A=0AI suggest we discuss all the issues calmly.=0A=0A=0ARegards,=0A= =0ABehcet=0A=0A=0A=0A----- Original Message ----=0A> From: Thomas C. Schmid= t =0A> To: Behcet Sarikaya =0A> Cc: Matthias Waehlisch ; multimob@ietf.org= =0A> Sent: Tue, December 1, 2009 10:15:26 AM=0A> Subject: Re: [multimob] IG= MP/MLD Proxy at the MAG=0A> =0A> Hi,=0A> =0A> seems this debate is not comi= ng to an end ... see below.=0A> =0A> Behcet Sarikaya wrote:=0A> > =0A> > = =0A> > =0A> > ----- Original Message ----=0A> >> From: Matthias Waehlisch = =0A> >> To: Behcet Sarikaya =0A> >> Cc: multimob@ietf.org=0A> >> Sent: Tue,= December 1, 2009 6:49:48 AM=0A> >> Subject: Re: [multimob] IGMP/MLD Proxy = at the MAG=0A> >> =0A> >> Hi Behcet,=0A> >> =0A> >> On Mon, 30 Nov 2009, Be= hcet Sarikaya wrote:=0A> >> =0A> >>>=A0 Is host interface a tunnel interfac= e?=0A> >>> =0A> >>> My answer is no. Tell me if your answer is yes?=0A> >>>= =0A> >>=A0 not mandatory, but it may be a tunnel interface. The difference= notation -- =0A> "Host interface" and "Router interfaces" -- results from = the different roles of =0A> the proxy ...=0A> >> =0A> >>=A0 If you are affl= icted by doubts, please ask your question within the MAGMA =0A> mailing lis= t. They should definitely know the answer.=0A> > =0A> > So I think we are i= n agreement :).=0A> > Yes it may be but it is not as defined in RFC 4605.= =0A> > =0A> > As I said many times, it is a protocol extension to have this= interface as =0A> tunneling interface.=0A> > =0A> >=A0 I think that we are= all agreeing on this, right?=0A> > =0A> =0A> Definitely *not*.=0A> =0A> Be= hcet: Matthias & Stig are trying to explain to you patiently and in many = =0A> emails what the meaning of an IP interface of a router is. You are loo= king at =0A> the link type, which is layer 2 ... virtual or physical.=0A> = =0A> Putting it more direct: you are in the wrong movie, largely missing th= e context.=0A> =0A> I guess: now we can end the discussion finally.=0A> =0A= > Cheers,=0A> =0A> Thomas=0A> -- =0A> Prof. Dr. Thomas C. Schmidt=0A> =B0 H= amburg University of Applied Sciences=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Be= rliner Tor 7 =B0=0A> =B0 Dept. Informatik, Internet Technologies Group=A0 = =A0 20099 Hamburg, Germany =B0=0A> =B0 http://www.haw-hamburg.de/inet=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fon: +49-40-42875-8452 =B0=0A> =B0 http://w= ww.informatik.haw-hamburg.de/~schmidt=A0 =A0 Fax: +49-40-42875-8409 =B0=0A= =0A=0A=0A From schmidt@informatik.haw-hamburg.de Tue Dec 1 08:48: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 53F3E3A68C6 for ; Tue, 1 Dec 2009 08:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 iWypHNCi6Lgz for ; Tue, 1 Dec 2009 08:48:53 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 35C2F3A67B6 for ; Tue, 1 Dec 2009 08:48:52 -0800 (PST) Envelope-to: multimob@ietf.org Received: from dhcp172.rm.cnr.it ([150.146.113.172]) by mail2.rz.htw-berlin.de with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NFVu8-0007hz-BA; Tue, 01 Dec 2009 17:48:44 +0100 Message-ID: <4B1548E4.8090005@informatik.haw-hamburg.de> Date: Tue, 01 Dec 2009 17:48:36 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behcet Sarikaya References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> <74406.71791.qm@web111411.mail.gq1.yahoo.com> <383491.68900.qm@web111405.mail.gq1.yahoo.com> <32617.6250.qm@web111412.mail.gq1.yahoo.com> <211302.96096.qm@web111416.mail.gq1.yahoo.com> <4B15411E.1030309@informatik.haw-hamburg.de> <501852.67838.qm@web111414.mail.gq1.yahoo.com> In-Reply-To: <501852.67838.qm@web111414.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 01 Dec 2009 16:48:54 -0000 Hi Behcet, Behcet Sarikaya wrote: > I think you should be patient and agree with the right thing. > Sorry for being impatient. However, just because you keep repeating an obvious mistake, this fault does not become a tiny bit more correct. > > I suggest we discuss all the issues calmly. The issue is: there is nothing to discuss. As I said more than a week ago: "Nothing new, just IP routing". This whole debate is just about a misunderstanding of IP/interfaces at your side. If you don't believe Matthias, Stig and me, please go ahead and ask the folks at Magma. But please let us release the list from the discussion on "what changes does a tunnel interface impose on MLD signaling". ... this is just about to make any serious work on this list go bust. Thanks for your understanding, Thomas > > ----- Original Message ---- >> From: Thomas C. Schmidt >> To: Behcet Sarikaya >> Cc: Matthias Waehlisch ; multimob@ietf.org >> Sent: Tue, December 1, 2009 10:15:26 AM >> Subject: Re: [multimob] IGMP/MLD Proxy at the MAG >> >> Hi, >> >> seems this debate is not coming to an end ... see below. >> >> Behcet Sarikaya wrote: >>> >>> >>> ----- Original Message ---- >>>> From: Matthias Waehlisch >>>> To: Behcet Sarikaya >>>> Cc: multimob@ietf.org >>>> Sent: Tue, December 1, 2009 6:49:48 AM >>>> Subject: Re: [multimob] IGMP/MLD Proxy at the MAG >>>> >>>> Hi Behcet, >>>> >>>> On Mon, 30 Nov 2009, Behcet Sarikaya wrote: >>>> >>>>> Is host interface a tunnel interface? >>>>> >>>>> My answer is no. Tell me if your answer is yes? >>>>> >>>> not mandatory, but it may be a tunnel interface. The difference notation -- >> "Host interface" and "Router interfaces" -- results from the different roles of >> the proxy ... >>>> If you are afflicted by doubts, please ask your question within the MAGMA >> mailing list. They should definitely know the answer. >>> So I think we are in agreement :). >>> Yes it may be but it is not as defined in RFC 4605. >>> >>> As I said many times, it is a protocol extension to have this interface as >> tunneling interface. >>> I think that we are all agreeing on this, right? >>> >> Definitely *not*. >> >> Behcet: Matthias & Stig are trying to explain to you patiently and in many >> emails what the meaning of an IP interface of a router is. You are looking at >> the link type, which is layer 2 ... virtual or physical. >> >> Putting it more direct: you are in the wrong movie, largely missing the context. >> >> I guess: now we can end the discussion finally. >> >> 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 ° > > > > > _______________________________________________ > 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 behcetsarikaya@yahoo.com Tue Dec 1 10:05:04 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 8FCCA3A6A46 for ; Tue, 1 Dec 2009 10:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.233, 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 5VPzK8A-rTy6 for ; Tue, 1 Dec 2009 10:05:02 -0800 (PST) Received: from web111404.mail.gq1.yahoo.com (web111404.mail.gq1.yahoo.com [67.195.15.150]) by core3.amsl.com (Postfix) with SMTP id 82C283A6910 for ; Tue, 1 Dec 2009 10:05:01 -0800 (PST) Received: (qmail 90388 invoked by uid 60001); 1 Dec 2009 18:04:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259690690; bh=+jSM1hfTL92vYnDRDsCp5ftzm3C2+hSB9fsZaHPhX4s=; 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=S/tfVribxHLH3xcCVzfffVj3vB6ZuZh/RQ55Sw2/a4UHl8B6R1GnPa+R+8FcHwU/M5ghj6hxmEPTeVd40IHEO/X+Tf8qknbjFJGxyWTZdqHV0aPa2I/C07bvJgY7UTdYqNJtY9mxnWP+idWv6EeLKf4WdQh9KOWUQvnOvMrb0u8= 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=Ag+4Hje0Niv3bz/ffWhyzIz6Ps4zMcmVYWEXNgzJwXwzoZq9SQ3MdI4+zoGa/WpL4ARAxJ7/s5AVwTPGO8YiXh1/Pckbd7RBfjAjTUjMjK1RPzGN+ElEduHOkVa+krF9y8jhMgpFExGK+o627deZ8o5O0HzMQEviFMW782MOd1Q=; Message-ID: <870222.88651.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: QJXuNFoVM1mf0hfk9Kl7MQ.U84MjSO5UuC9lvZBs45m4OdjAauohjf6hLuQIK4mm5ZjSIgGzq.ltFt_kALbqKZ6Ev5tZD.p_zpCKSN4hTJiNAwb1aohToo2p5MKz2ab8yowMR0OzzAOcqfcVKAAlE_vAjMEYFch4Ou9iDgnP5CQkqeXdNNShH1UV4tFKKpAY2N_Q3bFkd0R8d7c67SVYChvMx0ZvMYZbkEG3Agu98IvcHwXzfCG2FyAtEAoV7.6E6bh1b6u0xrMl7T0cS09vxlXDfUsXyc3WM5GPezvw9P4I2UNyX_iKoYo9mHWY.IGDamM8FiWLq.0YrO_ModK7Y9g- Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Tue, 01 Dec 2009 10:04:50 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> <74406.71791.qm@web111411.mail.gq1.yahoo.com> <383491.68900.qm@web111405.mail.gq1.yahoo.com> <32617.6250.qm@web111412.mail.gq1.yahoo.com> <4B15159D.7030909@venaas.com> Date: Tue, 1 Dec 2009 10:04:50 -0800 (PST) From: Behcet Sarikaya To: multimob@ietf.org In-Reply-To: <4B15159D.7030909@venaas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 01 Dec 2009 18:05:04 -0000 Hi all,=0A=0AWith my chair hat on.=0A=0A=0A=0A----- Original Message ----= =0A> I think we should start focusing on coming up with a best possible MLD= =0A> proxy proposal, there was consensus at our meeting for that to be the= =0A> direction to go for the basic multicast solution.=0A> =0A=0AYes it is = true that in the meeting MLD Proxy was the direction to go. =0A=0AHere are = some facts:=0A=0A- we have four solution drafts that takes this direction. = =0A=0A- after the meeting a WG member (happens to be myself) presented some= new facts on MLD Proxy that were not discussed at the meeting=A0=0A=0Asuch= as MLD Proxy solves avalanche problem which is=A0mentioned in the charter= =A0to be done at the next stage;=A0=0A=0Asuch as MLD Proxy incorporated ins= ide MAG-LMA tunnel is an extension to RFC 4605;=0A=0AI am OK if WG says tha= t we should ignore these facts=A0and continue on the next steps with MLD Pr= oxy as the fixed direction for the base solution.=0A=0AAny thoughts?=0A=0AB= ehcet=0A=0A=0A From waehlisch@ieee.org Tue Dec 1 14:57:55 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 DAB523A6827 for ; Tue, 1 Dec 2009 14:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 kOb+Hg7K32CV for ; Tue, 1 Dec 2009 14:57:54 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id C26223A6783 for ; Tue, 1 Dec 2009 14:57:54 -0800 (PST) Envelope-to: multimob@ietf.org Received: from 93-40-137-39.ip39.fastwebnet.it ([93.40.137.39] helo=mw-thinkpad.fastwebnet.it) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NFbfF-0005wo-Jg; Tue, 01 Dec 2009 23:57:46 +0100 Date: Tue, 1 Dec 2009 23:57:40 +0100 From: Matthias Waehlisch To: Behcet Sarikaya In-Reply-To: <870222.88651.qm@web111404.mail.gq1.yahoo.com> Message-ID: References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> <74406.71791.qm@web111411.mail.gq1.yahoo.com> <383491.68900.qm@web111405.mail.gq1.yahoo.com> <32617.6250.qm@web111412.mail.gq1.yahoo.com> <4B15159D.7030909@venaas.com> <870222.88651.qm@web111404.mail.gq1.yahoo.com> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="602037281-11268-1259707312=:960" Content-ID: X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 01 Dec 2009 22:57:55 -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. --602037281-11268-1259707312=:960 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hi Behcet, see comments inline: On Tue, 1 Dec 2009, Behcet Sarikaya wrote: > > I think we should start focusing on coming up with a best possible MLD= =20 > > proxy proposal, there was consensus at our meeting for that to be the= =20 > > direction to go for the basic multicast solution. > >=20 >=20 > Yes it is true that in the meeting MLD Proxy was the direction to go. >=20 > Here are some facts: >=20 > - we have four solution drafts that takes this direction.=20 >=20 > - after the meeting a WG member (happens to be myself) presented some=20 > new facts on MLD Proxy that were not discussed at the meeting=A0 >=20 > such as MLD Proxy solves avalanche problem which is=A0mentioned in the=20 > charter=A0to be done at the next stage;=A0 >=20 > such as MLD Proxy incorporated inside MAG-LMA tunnel is an extension to= =20 > RFC 4605; >=20 > I am OK if WG says that we should ignore these facts=A0and continue on th= e=20 > next steps with MLD Proxy as the fixed direction for the base solution. >=20 again, that's not (completely) a fact ... Additionally, you are the only= =20 person on this list who argue that "MAG-LMA tunnel is an extension to=20 RFC4605". From my impression it seems to be an appropriate procedure that= =20 you, Behcet, ask the right people in this 'controversial' case, i.e., the= =20 MAGMA people - don't be shy. Everything else is ridiculous. > Any thoughts? >=20 Yes, see above. And to be honest, Behcet, if you have your "chair hat=20 on", you should act in a more reasonable way. Thanks matthias PS: It would be a nice Christmas present to finish this discussion in=20 2009 - that's semi-fun. --=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 --602037281-11268-1259707312=:960-- From behcetsarikaya@yahoo.com Tue Dec 1 15:11: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 BA65B3A691C for ; Tue, 1 Dec 2009 15:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.201, 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 Z-ljOC0P9LVV for ; Tue, 1 Dec 2009 15:11:09 -0800 (PST) Received: from web111411.mail.gq1.yahoo.com (web111411.mail.gq1.yahoo.com [67.195.15.192]) by core3.amsl.com (Postfix) with SMTP id E75CE3A6783 for ; Tue, 1 Dec 2009 15:11:08 -0800 (PST) Received: (qmail 4514 invoked by uid 60001); 1 Dec 2009 23:10:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259709058; bh=QVVaZqheepIZmbmdb/lsj3ZDL3Q9mu7b/230N9WeoA0=; 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=QBsMCWzY8ie9NRHRBZXDWpzwKjvsPW2iAanvyR68CxN7Wa9d/4hTwOB47sN9P4D+JclVQibQHa8nd6Rkzmhj7C8idoe00B8rSZjuZViB9tgAAqtS6BEBtr6CKS77WxEFByV0cdv47Auugvot2+73eNyAkGWfiO6l6W3zf3TA/lg= 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=HDkJzD6qwIgcghUAPgAIzpxK7XQIZ0w37/1tHoJx4rwG9Gh5Vlak9iLQ6Bl0qS9WqqVW2l6jgdp//xfOGzLZokYzeWs+Xr7jHZij+oI/ni3l4AM1pGfq3ypFvTS9LCTUKavScIx6Lf4oBZd4yTHyM59vaSWrlM56eCo+tohn5lM=; Message-ID: <988321.4474.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: cWx.pGQVM1mM9ysgB.n6SevL4udAXhrZlwj3i6BD74EIhcRbo0bI9m0Z0bnFbgjz7SvWynII_h3oF8yG_435VE97UBaxGEgjyz4zjr.4Id8EmMYuxUp_9RLsDjKxXNh0FrEZ0yPO3TUox87YhdwK3GnVTmhzaSpLoCS.M50vlC2VoR5q8eTOK4946g564henwRdmFOGOc1dTlU4ZfU981HX4BFsQHLcAL.vgdNB4oz2Od1FQH93.OzzIdO9oYt3qW_hKze_b1U27FrMiHwuGyENx_pCUdLS_zokPgaUCxEv4eV5S_TMlvd8P.1F0c2Lhz1CkNB8- Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Tue, 01 Dec 2009 15:10:58 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> <74406.71791.qm@web111411.mail.gq1.yahoo.com> <383491.68900.qm@web111405.mail.gq1.yahoo.com> <32617.6250.qm@web111412.mail.gq1.yahoo.com> <4B15159D.7030909@venaas.com> <870222.88651.qm@web111404.mail.gq1.yahoo.com> Date: Tue, 1 Dec 2009 15:10:58 -0800 (PST) From: Behcet Sarikaya To: Matthias Waehlisch In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 01 Dec 2009 23:11:09 -0000 Hi Matthias, =0A=0A=A0 So you are for ignoring these facts=A0and continuing= on the next steps with MLD Proxy as the fixed direction for the base solut= ion?=0A=0AThx.=0A=0A=0A=0ABehcet=0A=0A=0A From waehlisch@ieee.org Tue Dec 1 15: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 451043A69D5 for ; Tue, 1 Dec 2009 15:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 2Av8KFvIUQIW for ; Tue, 1 Dec 2009 15:18:21 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 13D593A6957 for ; Tue, 1 Dec 2009 15:18:21 -0800 (PST) Envelope-to: multimob@ietf.org Received: from 93-40-137-39.ip39.fastwebnet.it ([93.40.137.39] helo=mw-thinkpad.fastwebnet.it) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NFbz1-0008nH-Kv; Wed, 02 Dec 2009 00:18:12 +0100 Date: Wed, 2 Dec 2009 00:18:09 +0100 From: Matthias Waehlisch To: Behcet Sarikaya In-Reply-To: <988321.4474.qm@web111411.mail.gq1.yahoo.com> Message-ID: References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> <74406.71791.qm@web111411.mail.gq1.yahoo.com> <383491.68900.qm@web111405.mail.gq1.yahoo.com> <32617.6250.qm@web111412.mail.gq1.yahoo.com> <4B15159D.7030909@venaas.com> <870222.88651.qm@web111404.mail.gq1.yahoo.com> <988321.4474.qm@web111411.mail.gq1.yahoo.com> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="604118140-7505-1259709393=:960" Content-ID: X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 01 Dec 2009 23:18:22 -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. --604118140-7505-1259709393=:960 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hi Behcet, On Tue, 1 Dec 2009, Behcet Sarikaya wrote: >=A0 So you are for ignoring these facts=A0and continuing on the next steps= =20 > with MLD Proxy as the fixed direction for the base solution? > (1) I don't see that your facts are correct. It seems that we have=20 different meanings on this. Thus, I proposed a way to find a consensus -=20 ask the MAGMA people, Behcet. (2) Personally (having my Nick Knatterton hat on), I have no objections= =20 to go ahead with the proxy solution. Regards matthias --=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 --604118140-7505-1259709393=:960-- From stig@venaas.com Tue Dec 1 23:21:42 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 4F9543A67F7 for ; Tue, 1 Dec 2009 23:21:42 -0800 (PST) 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=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=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 xzNj0EAHiBAg for ; Tue, 1 Dec 2009 23:21:41 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 9B7AF3A67B0 for ; Tue, 1 Dec 2009 23:21:40 -0800 (PST) Received: from [192.168.1.101] (cm-84.209.163.61.getinternet.no [84.209.163.61]) by ufisa.uninett.no (Postfix) with ESMTP id 7AE6622926; Wed, 2 Dec 2009 08:21:32 +0100 (CET) Message-ID: <4B161523.90102@venaas.com> Date: Tue, 01 Dec 2009 23:20:03 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behcet Sarikaya References: <917218.31788.qm@web111406.mail.gq1.yahoo.com><6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <004d01ca6cd7$11d6f8f0$9d7213ac@dcn0d4b06d5df0> <32541.76745.qm@web111414.mail.gq1.yahoo.com> <4B0D9430.5000308@informatik.haw-hamburg.de> <74406.71791.qm@web111411.mail.gq1.yahoo.com> <383491.68900.qm@web111405.mail.gq1.yahoo.com> <32617.6250.qm@web111412.mail.gq1.yahoo.com> <4B15159D.7030909@venaas.com> <870222.88651.qm@web111404.mail.gq1.yahoo.com> In-Reply-To: <870222.88651.qm@web111404.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 02 Dec 2009 07:21:42 -0000 Behcet Sarikaya wrote: > Hi all, > > With my chair hat on. OK, and this is with my chair hat on then. > > > ----- Original Message ---- >> I think we should start focusing on coming up with a best possible MLD >> proxy proposal, there was consensus at our meeting for that to be the >> direction to go for the basic multicast solution. >> > > Yes it is true that in the meeting MLD Proxy was the direction to go. > > Here are some facts: > > - we have four solution drafts that takes this direction. > > - after the meeting a WG member (happens to be myself) presented some new facts on MLD Proxy that were not discussed at the meeting > > such as MLD Proxy solves avalanche problem which is mentioned in the charter to be done at the next stage; MLD Proxy does have some benefits, in particular that there is no replication until the topology branches out. This is the way multicast generally behaves, and it provides the same behavior. That this may avoid avalanche problem and that that is listed as a possible thing to work on later does not mean that it cannot be solved now if we find a simple solution that takes care of it. It's not that we are forced to find a poorer solution. > such as MLD Proxy incorporated inside MAG-LMA tunnel is an extension to RFC 4605; You are the only person claiming that so far, and from the discussion we have had on the list, I don't buy your argument for why it is an extension. > I am OK if WG says that we should ignore these facts and continue on the next steps with MLD Proxy as the fixed direction for the base solution. I don't agree with how you put the "facts" above, I would not call them facts. I would like to hear if people on the list disagree, but it was consensus (which is pretty much "WG says") at the meeting. I don't see anyone ignoring your issues, only disagreeing that they are issues. It would be important if there were technical issues with the MLD Proxy approach, I've not seen any so far. I would like to hear about any issues. You have brought up possible issues with MLD Proxy and the charter. I don't see that it is against the charter. It would of course be an issue if it were, but so far I haven't seen any indication. Although I believe that it is in the charter, I also want to say that generally speaking, it can be possible to deviate from the charter slightly too if there is WG Consensus and there are good technical reasons. As Jari said in the meeting, the charter is not set in stone. It's mostly there to guide us. (I hope I got that right, that is what I remember). It is possible for a WG and an AD to decide to deviate to some degree. So far, I don't see that we are deviating from the charter though. And we should try not to, unless we have good reasons. Stig > Any thoughts? > > Behcet > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From jari.arkko@piuha.net Wed Dec 2 04:22: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 2F64C28C0EA for ; Wed, 2 Dec 2009 04:22:58 -0800 (PST) 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 VjjzkOw1lAku for ; Wed, 2 Dec 2009 04:22:57 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 41DB53A684A for ; Wed, 2 Dec 2009 04:22:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3FED7D4927 for ; Wed, 2 Dec 2009 14:22:49 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrRCGuAL6POJ for ; Wed, 2 Dec 2009 14:22:48 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id BD846D4903 for ; Wed, 2 Dec 2009 14:22:48 +0200 (EET) Message-ID: <4B165C18.7060509@piuha.net> Date: Wed, 02 Dec 2009 14:22:48 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: multimob@ietf.org References: <917218.31788.qm@web111406.mail.gq1.yahoo.com> <6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <4B0AE50D.4020905@venaas.com> In-Reply-To: <4B0AE50D.4020905@venaas.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 02 Dec 2009 12:22:58 -0000 I wanted to reply and explain the rationale behind what the charter says (as opposed to the specific words in the current charter that may turn out to be misleading). The group was prohibited to work on certain topics for a couple of reasons, mainly to prevent you from jumping ahead to complex solutions before the simple thing was tried, forcing you to use existing tools before designing new ones, and to limit your first task to an achievable size. From my perspective the key requirements are that you do not design any new protocol messaging and that you do not spend any time in the optimization aspect. However, I'm more than happy to see the use of an existing RFC (such as 4605), explanation of its application for this node and link type, and I do not mind if you get other benefits such as optimization in the same deal. However, I am going to insist that including this optimization really comes for free through the use of the existing RFC. If your specification ends up having significant behaviour rules about it, you are over the line and should probably leave it for later. By the way, one of the possible outcomes of the first phase of this working group's effort is that if the existing protocol & existing RFC support is good enough, we might not need any additional optimization work. I'm getting the sense that the proxy solution is quite optimal already. I also had a few questions about MLD proxies in the MAG. I do not fully understand how you plan to aggregate the state and forwarding across the different MLD instances (draft-schmidt says that there's one instance per MN). Wouldn't you run one instance, really, subscribe through just one tunnel, and forward multicast packets from one MN's tunnel to the others? Jari From schmidt@informatik.haw-hamburg.de Wed Dec 2 04:42: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 5BE413A659B for ; Wed, 2 Dec 2009 04:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 HSfGYQAqloMk for ; Wed, 2 Dec 2009 04:42:56 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id B179828C181 for ; Wed, 2 Dec 2009 04:42:16 -0800 (PST) Envelope-to: multimob@ietf.org Received: from dhcp154.rm.cnr.it ([150.146.113.154]) by mail2.rz.htw-berlin.de with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NFoX1-000GZr-AT; Wed, 02 Dec 2009 13:42:07 +0100 Message-ID: <4B166096.9020609@informatik.haw-hamburg.de> Date: Wed, 02 Dec 2009 13:41:58 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jari Arkko References: <917218.31788.qm@web111406.mail.gq1.yahoo.com> <6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <4B0AE50D.4020905@venaas.com> <4B165C18.7060509@piuha.net> In-Reply-To: <4B165C18.7060509@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 02 Dec 2009 12:42:57 -0000 Hi Jari, Jari Arkko wrote: > > I also had a few questions about MLD proxies in the MAG. I do not fully > understand how you plan to aggregate the state and forwarding across the > different MLD instances (draft-schmidt says that there's one instance > per MN). Wouldn't you run one instance, really, subscribe through just > one tunnel, and forward multicast packets from one MN's tunnel to the > others? There seems to be a slight misunderstanding here: the draft states "It therefore needs to implement an instance of the MLD proxy function [RFC4605] for each upstream tunnel interface that has been established with an LMA." that is an instance per LMA-MAG tunnel, not per MN. Thus multicast listener states of all MNs at one MAG that share a specific LMA (and hence the tunnel) may be aggregated. Aggregation is an inherent feature of RFC 4605. In this sense, there is some traffic aggregation inherited from the MLD proxy function, but the proposed solution is not optimal: There may be MNs at a MAG that are associated with different LMAs, and thus are treated in different MLD proxy instances which prevents an overall state aggregation. So there should be room for future improvements on PMIP multicast ;) 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 stig@venaas.com Wed Dec 2 05:03: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 9F6833A6891 for ; Wed, 2 Dec 2009 05:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=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 52+dHznVGVTY for ; Wed, 2 Dec 2009 05:03:08 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 6147E3A681C for ; Wed, 2 Dec 2009 05:03:08 -0800 (PST) Received: from [10.21.118.65] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTP id 6E563231FD; Wed, 2 Dec 2009 14:02:58 +0100 (CET) Message-ID: <4B166522.9030300@venaas.com> Date: Wed, 02 Dec 2009 05:01:22 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <917218.31788.qm@web111406.mail.gq1.yahoo.com> <6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <4B0AE50D.4020905@venaas.com> <4B165C18.7060509@piuha.net> <4B166096.9020609@informatik.haw-hamburg.de> In-Reply-To: <4B166096.9020609@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 02 Dec 2009 13:03:09 -0000 Thomas C. Schmidt wrote: > Hi Jari, > > Jari Arkko wrote: >> >> I also had a few questions about MLD proxies in the MAG. I do not >> fully understand how you plan to aggregate the state and forwarding >> across the different MLD instances (draft-schmidt says that there's >> one instance per MN). Wouldn't you run one instance, really, subscribe >> through just one tunnel, and forward multicast packets from one MN's >> tunnel to the others? > > There seems to be a slight misunderstanding here: the draft states > "It therefore needs to > implement an instance of the MLD proxy function [RFC4605] for each > upstream tunnel interface that has been established with an LMA." > > that is an instance per LMA-MAG tunnel, not per MN. Thus multicast > listener states of all MNs at one MAG that share a specific LMA (and > hence the tunnel) may be aggregated. Aggregation is an inherent feature > of RFC 4605. The reason for having multiple instances, is that RFC 4605 assumes a single upstream interface. In this way, each instance can operate according to 4605. I believe what happens then, is that when a new MN arrives, the MAG will first determine which LMA the MN belongs to. When that is done, it can reconfigure the proxy instance which has that LMA-MAG tunnel as its upstream, adding the interface the MN is on, to the list of downstream interfaces that proxy instance manages. Thomas, you said something about supporting multiple MNs on the same link a while ago, not just the current point-to-point. Wouldn't that be difficult if different MNs on the link are using different LMAs, and hence different proxy instances? Stig > In this sense, there is some traffic aggregation inherited from the MLD > proxy function, but the proposed solution is not optimal: There may be > MNs at a MAG that are associated with different LMAs, and thus are > treated in different MLD proxy instances which prevents an overall state > aggregation. > > So there should be room for future improvements on PMIP multicast ;) > > Best regards, > > Thomas From schmidt@informatik.haw-hamburg.de Wed Dec 2 05:36: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 8CA8F28C1C9 for ; Wed, 2 Dec 2009 05:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 VwHQZ5pO8HLM for ; Wed, 2 Dec 2009 05:36:02 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 6D3433A6925 for ; Wed, 2 Dec 2009 05:36:02 -0800 (PST) Envelope-to: multimob@ietf.org Received: from dhcp154.rm.cnr.it ([150.146.113.154]) by mail2.rz.htw-berlin.de with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NFpN3-0005G1-8K; Wed, 02 Dec 2009 14:35:53 +0100 Message-ID: <4B166D2D.60403@informatik.haw-hamburg.de> Date: Wed, 02 Dec 2009 14:35:41 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stig Venaas References: <917218.31788.qm@web111406.mail.gq1.yahoo.com> <6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <4B0AE50D.4020905@venaas.com> <4B165C18.7060509@piuha.net> <4B166096.9020609@informatik.haw-hamburg.de> <4B166522.9030300@venaas.com> In-Reply-To: <4B166522.9030300@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 02 Dec 2009 13:36:03 -0000 Hi Stig, Stig Venaas wrote: > Thomas C. Schmidt wrote: >> Jari Arkko wrote: >>> >>> I also had a few questions about MLD proxies in the MAG. I do not >>> fully understand how you plan to aggregate the state and forwarding >>> across the different MLD instances (draft-schmidt says that there's >>> one instance per MN). Wouldn't you run one instance, really, >>> subscribe through just one tunnel, and forward multicast packets from >>> one MN's tunnel to the others? >> >> There seems to be a slight misunderstanding here: the draft states >> "It therefore needs to >> implement an instance of the MLD proxy function [RFC4605] for each >> upstream tunnel interface that has been established with an LMA." >> >> that is an instance per LMA-MAG tunnel, not per MN. Thus multicast >> listener states of all MNs at one MAG that share a specific LMA (and >> hence the tunnel) may be aggregated. Aggregation is an inherent >> feature of RFC 4605. > > The reason for having multiple instances, is that RFC 4605 assumes a > single upstream interface. In this way, each instance can operate > according to 4605. > > I believe what happens then, is that when a new MN arrives, the MAG > will first determine which LMA the MN belongs to. When that is done, > it can reconfigure the proxy instance which has that LMA-MAG tunnel > as its upstream, adding the interface the MN is on, to the list of > downstream interfaces that proxy instance manages. > Yes, exactly so. > Thomas, you said something about supporting multiple MNs on the same > link a while ago, not just the current point-to-point. Wouldn't that be > difficult if different MNs on the link are using different LMAs, and > hence different proxy instances? Well, I mentioned that we are trying to prepare the details of the mechanisms in a way that they should equally work on a shared link model in PMIP, which might come out of the mobility work. But I see two issues here: (i) The reaction of the MAG, sending a general query once the MN arrives at the link (ii) The problem of multiple MLD proxy instances operating on the same shared link (what you mentioned) Ad (i): Following the discussion in Hiroshima, we have experimentally tried out the behavior of a Cisco and a Linux router: Both send a general query immediately after a link goes up (and the link-local address of the router interface is configured). This will of course not happen, if an MN arrives on a shared link. In this case, router behavior needed the extension of sending the query in response to a router solicitation, which I guess is not standard behavior now. Ad (ii): There may be several issues resulting from mixing proxy instances at a single shared link. The first question, how to provide a correct mapping of MN to proxy instance, should be solvable based on the (link-local) addresses of the MNs that need to be unique in a shared link model, as well. On the downstream, I'm not so sure now. In any case it would result in two (or more) proxy instances operating on forwarding states at one interface. I guess we have to think & discuss about this further - its future stuff anyway, since we have point-to-point links in current PMIP and target at this network model. Thanks for pointing at this! 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 luisc@it.uc3m.es Wed Dec 2 06:01:15 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 9A9D63A6AC8 for ; Wed, 2 Dec 2009 06:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 1TVp9Kr-usHP for ; Wed, 2 Dec 2009 06:01:14 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 99E243A6AC7 for ; Wed, 2 Dec 2009 06:01:14 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id E13486C1992; Wed, 2 Dec 2009 15:01:04 +0100 (CET) Received: from 85.62.13.197.static.abi.uni2.es (85.62.13.197.static.abi.uni2.es [85.62.13.197]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Wed, 02 Dec 2009 15:01:02 +0100 Message-ID: <20091202150102.enbxyzqf40osswwg@webcartero01.uc3m.es> Date: Wed, 02 Dec 2009 15:01:02 +0100 From: "Luis M. Contreras" To: "Thomas C. Schmidt" References: <917218.31788.qm@web111406.mail.gq1.yahoo.com> <6D5EC89C-8D3E-4FD0-8732-069112A2B964@gmail.com> <555186.69483.qm@web111406.mail.gq1.yahoo.com> <4B0AE50D.4020905@venaas.com> <4B165C18.7060509@piuha.net> <4B166096.9020609@informatik.haw-hamburg.de> In-Reply-To: <4B166096.9020609@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17044.007 Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 02 Dec 2009 14:01:15 -0000 "Thomas C. Schmidt" dijo: > > In this sense, there is some traffic aggregation inherited from the > MLD proxy function, but the proposed solution is not optimal: There > may be MNs at a MAG that are associated with different LMAs, and thus > are treated in different MLD proxy instances which prevents an > overall state aggregation. > > So there should be room for future improvements on PMIP multicast ;) > Please, note that today there are other proposals which state a single MLD instance per MAG. As far as I know, there is not a closed solution yet. regards, Luis From luisc@it.uc3m.es Wed Dec 2 06:07: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 373113A6A2F for ; Wed, 2 Dec 2009 06:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 9T+ydrHmtgc6 for ; Wed, 2 Dec 2009 06:07:18 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 7A6E13A6AC6 for ; Wed, 2 Dec 2009 06:07:07 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 2E26E6556D3; Wed, 2 Dec 2009 15:06:58 +0100 (CET) Received: from 85.62.13.197.static.abi.uni2.es (85.62.13.197.static.abi.uni2.es [85.62.13.197]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Wed, 02 Dec 2009 15:06:56 +0100 Message-ID: <20091202150656.i0ah7snw1s0kosgc@webcartero01.uc3m.es> Date: Wed, 02 Dec 2009 15:06:56 +0100 From: "Luis M. Contreras" To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17044.007 Subject: [multimob] Evaluation of the solution proposals presentation 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, 02 Dec 2009 14:07:19 -0000 Dear chairs, during last meeting at Hiroshima you presented an evaluation of the solution proposals. Such evaluation is not yet available at IETF Multimob Agenda web page. Please, could you upload the presentation? Thanks in advance, Luis From asaeda@sfc.wide.ad.jp Wed Dec 2 22:54: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 696833A6A51 for ; Wed, 2 Dec 2009 22:54:45 -0800 (PST) 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 F0X8FclglS30 for ; Wed, 2 Dec 2009 22:54:44 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id A11173A69F5 for ; Wed, 2 Dec 2009 22:54:44 -0800 (PST) Received: from localhost (dhcp-143-234.sfc.wide.ad.jp [203.178.143.234]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1192C4D876; Thu, 3 Dec 2009 15:54:32 +0900 (JST) Date: Thu, 03 Dec 2009 15:54:31 +0900 (JST) Message-Id: <20091203.155431.189432716.asaeda@sfc.wide.ad.jp> To: jari.arkko@piuha.net From: Hitoshi Asaeda In-Reply-To: <4B165C18.7060509@piuha.net> References: <555186.69483.qm@web111406.mail.gq1.yahoo.com> <4B0AE50D.4020905@venaas.com> <4B165C18.7060509@piuha.net> 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 Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 03 Dec 2009 06:54:45 -0000 Jari, > By the way, one of the possible outcomes of the first phase of this > working group's effort is that if the existing protocol & existing RFC > support is good enough, we might not need any additional optimization > work. I'm getting the sense that the proxy solution is quite optimal > already. MLD proxy is NOT the optimal solution. (Well, the word, "optimization" is vague as I said in the last meeting, though, anyway...) MLD proxy is good to use and the possible implementation to aggregate multicast join/leave requests and data packets. However, the following points must be addressed with protocol extension. 1. One of the most emergent topics is about handover. There is no way to make a seamless handover for MN's multicast join state by MLD proxy or other existing protocols. The solution may also include the discussion about a context transfer mechanism. 2. Basic design of MLD proxy requires configuring a single upstream interface, and hence some extension to support that MAG connects multiple LMAs would be necessary. 3. No local routing supported only with MLD proxy. If local routing should be supported, dual-mode implementation (MLD proxy and PIM on MAG or LMA) should be also discussed. 4. How about following netext's discussions (multi-LMA, multi-IF, roaming, etc.) for multicast? Some of the necessary discussions are already described in; http://tools.ietf.org/html/draft-asaeda-multimob-pmip6-extension-02 Discussing the protocol extension is hence necessary. Regards, -- Hitoshi Asaeda From luisc@it.uc3m.es Thu Dec 3 10:10: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 0B5843A67A5 for ; Thu, 3 Dec 2009 10:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 308AEZEDTiKJ for ; Thu, 3 Dec 2009 10:10:40 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 77CB53A67F3 for ; Thu, 3 Dec 2009 10:10:39 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id E0CC2B4D3B8; Thu, 3 Dec 2009 19:10:27 +0100 (CET) Received: from 85.62.13.197.static.abi.uni2.es (85.62.13.197.static.abi.uni2.es [85.62.13.197]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Thu, 03 Dec 2009 19:10:24 +0100 Message-ID: <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> Date: Thu, 03 Dec 2009 19:10:24 +0100 From: "Luis M. Contreras" To: Hitoshi Asaeda References: <555186.69483.qm@web111406.mail.gq1.yahoo.com> <4B0AE50D.4020905@venaas.com> <4B165C18.7060509@piuha.net> <20091203.155431.189432716.asaeda@sfc.wide.ad.jp> In-Reply-To: <20091203.155431.189432716.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: multimob@ietf.org, isoto@it.uc3m.es Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 03 Dec 2009 18:10:43 -0000 Hi Hitoshi, some comments below: Hitoshi Asaeda dijo: > MLD proxy is NOT the optimal solution. > (Well, the word, "optimization" is vague as I said in the last > meeting, though, anyway...) > > MLD proxy is good to use and the possible implementation to > aggregate multicast join/leave requests and data packets. However, the > following points must be addressed with protocol extension. > > 1. One of the most emergent topics is about handover. > There is no way to make a seamless handover for MN's multicast join > state by MLD proxy or other existing protocols. > The solution may also include the discussion about a context > transfer mechanism. IMO, the concept of seamless handover applies basically to the multicast service subscribed by the MN as it moves. If we are able of guaranteeing no service disruption we are compliant with the idea of seamless handover. I think that some of the current solution proposals could satisfy this point at this stage, without protocol modifications. Other aspect is the multicast subscription status at the MLD proxy instance. In that case, for transferring the status between MLD instances in different MAGs some extra signalling is needed. This could imply some protocol modification. > 2. Basic design of MLD proxy requires configuring a single upstream > interface, and hence some extension to support that MAG connects > multiple LMAs would be necessary. I think we can separate here MLD-proxy upstream configuration from MAG-LMA binding. The MLD proxy instance ignores any mobility process. As far as the MAG has some interface active, the MLD proxy instance could configure that interface as upstream interface for the proxy function. From the MLD instance point of view it is not relevant if there is an LMA function at the other end of the upstream interface. The MLD instance needs at the other end a multicast router or another MLD proxy device. If the equipment at the other end of the upstream interface implements additional functions (such LMA one) is not relevant from the MLD proxy function point of view. > 3. No local routing supported only with MLD proxy. If local routing > should be supported, dual-mode implementation (MLD proxy and PIM on > MAG or LMA) should be also discussed. It is not clear to me what could be the behaviour of a mixed MLD-proxy/PIM-multicast router. For instance, if some multicast group is reacheable through the LMA, which is the way of requesting the content? An MLD query or a PIM join? Both of them could make use of the same tunnel between MAG and LMA ... I think that considering a pure MLD-proxy or a pure multicast router behaviour is more realistic. IMO, both could be considered at this stage (in my understanding, since the MN subscribes the content through the MAG either acting as MLD proxy or multicast router, both roles are compliant with the remote subscription condition) > 4. How about following netext's discussions (multi-LMA, multi-IF, > roaming, etc.) for multicast? I'm afraid that this could drive to protocol extensions not valid at this stage Best regards, Luis From behcetsarikaya@yahoo.com Fri Dec 4 08:51: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 4D4E23A688E for ; Fri, 4 Dec 2009 08:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.191, 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 hx7tuegd0ejL for ; Fri, 4 Dec 2009 08:51:06 -0800 (PST) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id 5BE293A684A for ; Fri, 4 Dec 2009 08:51:06 -0800 (PST) Received: (qmail 25991 invoked by uid 60001); 4 Dec 2009 16:50:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259945455; bh=zrUWg4+0YZQqTjDhPROI4PLoQBK4xofNl/yBqPJPSJI=; 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=eJ5aJxMz06MZ84BSzfrhEmXg/Es/GWDK9B98nhSM60RO9+QC3HtlF3UyLfPqI7OJou5zP1/otCs3JjT7aNrJ1d2N0s8RmRH8s53VtjEYYefSBO1LcqzO+FANTlc49+zpF63RU4IzsUPGzH2fZNxw1z5nUHU1u19G6N4IdqNZKt8= 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=cyDiDifmRI8s0bO10hLgFH7BUgodAK0I3lRBt9Rw+HW5YPIMu9fI1e1YXYT19s2+KfG7Ir58QrHKtIYYK2CHTHBna+8G6ObxSBS48AEuAUeVg+/pHvLqqon4+oRTl/2yOjS5Pw/hbh/en9YqcL8t7tdspw/IR6qCKCyT4+SSBkg=; Message-ID: <448311.25773.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: Hf3bmpMVM1lCnXVyWRVohjWp6aQOMBKrOL7Uj.vZLCZwAqja8Xo7XFk2yEDYPfscIyuBc.tgbdqpT5qnq2gEVFUxsypWyfQyAtX12Yv.bKt2u6jeIGlPKyTdt2GpUlqDnL9oh.UpnFyJfGfgjgdUcQ0goHnPuh5XLmUo_.Pcud04bsQCXKLTzAoWVnVaKV7frHU__ILjzCqX1HGNYM4bt5474ktgEues5LLUapLHpnJ3NHKV2gUbr2kMKYzMbxW6fY1A.sv8j9NseJzQk_V_PvSxgQGFksspyIAFVx2deTvMcmITcguPUVuIRiBpJZIUSEOPtLGKTCrrHhvXUffG5I0VRTIKOtTz6RmsgMFz Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Fri, 04 Dec 2009 08:50:55 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: <555186.69483.qm@web111406.mail.gq1.yahoo.com> <4B0AE50D.4020905@venaas.com> <4B165C18.7060509@piuha.net> <20091203.155431.189432716.asaeda@sfc.wide.ad.jp> Date: Fri, 4 Dec 2009 08:50:55 -0800 (PST) From: Behcet Sarikaya To: Hitoshi Asaeda In-Reply-To: <20091203.155431.189432716.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] IGMP/MLD Proxy at the MAG 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, 04 Dec 2009 16:51:07 -0000 Hitoshi, all,=0A=A0 As it seems there is common misunderstanding by some me= mbers in the working group, I thought I should explain the background.=0A= =0A=A0 There are different multicast architectures that can be used for mob= ility. The currently accepted architecture is based on providing multicast = to MNs from the home network by HA/LMA. This architecture is characterized = as remote subscription and bi-directional tunneling (also as in draft-irtf-= mobopts-mmcastv6-ps-09).=0A=0A=A0 Mobile IP also recognized locally availab= le multicast using proxy or MR at the local network. It does allow such use= but no session continuity is provided.=0A=0A=A0 Is the home networking arc= hitecture "inferior"? I don't think so. It fixes multicast tree in view of = MN mobility which is a big plus. Packet duplication is not a big problem if= there are only a few MNs in the multicast group. Also in Mobile IPv6, HA d= irectly tunnels to MN. The current approach still allows the use of locally= available multicast, so overall it is not bad.=0A=0A=A0 Is home networking= architecture optimal? Certainly it is not. This issue was covered in the l= iterature and draft-irtf-mobopts-mmcastv6 nicely surveys it.=0A=0A=A0 When = Multimob charter was written, the home networking architecture was taken as= the basis. When we mentioned optimizations, we considered optimizations vi= s-a-vis home networking architecture. Based on this, solving avalanche prob= lem as in locally available multicast solutions, is an optimization.=0A=0A= =A0 I have two observations based on the above: one is maybe we should have= arranged a presentation/tutorial on the state-of-the-art in Hiroshima to s= et the stage correctly (this was needed because we do have many new comers = to mobility in the WG).=0A=0A=A0 The second point is that our BoF charter h= ad both base and optimization solutions. IESG gave us only the base solutio= ns to start with. This seems to have broken the proper link between the two= somehow. Am I right?=0A=0ARegards,=0A=0ABehcet=0A=0A=0A----- Original Mess= age ----=0A> From: Hitoshi Asaeda =0A> To: jari.arkk= o@piuha.net=0A> Cc: multimob@ietf.org=0A> Sent: Thu, December 3, 2009 12:54= :31 AM=0A> Subject: Re: [multimob] IGMP/MLD Proxy at the MAG=0A> =0A> Jari,= =0A> =0A> > By the way, one of the possible outcomes of the first phase of = this=0A> > working group's effort is that if the existing protocol & existi= ng RFC=0A> > support is good enough, we might not need any additional optim= ization=0A> > work. I'm getting the sense that the proxy solution is quite = optimal=0A> > already.=0A> =0A> MLD proxy is NOT the optimal solution.=0A> = (Well, the word, "optimization" is vague as I said in the last=0A> meeting,= though, anyway...)=0A> =0A> MLD proxy is good to use and the possible impl= ementation to=0A> aggregate multicast join/leave requests and data packets.= However, the=0A> following points must be addressed with protocol extensio= n.=0A> =0A> 1. One of the most emergent topics is about handover.=0A> =A0 T= here is no way to make a seamless handover for MN's multicast join=0A> =A0 = state by MLD proxy or other existing protocols.=0A> =A0 The solution may al= so include the discussion about a context=0A> =A0 transfer mechanism.=0A> 2= . Basic design of MLD proxy requires configuring a single upstream=0A> =A0 = interface, and hence some extension to support that MAG connects=0A> =A0 mu= ltiple LMAs would be necessary.=0A> 3. No local routing supported only with= MLD proxy. If local routing=0A> =A0 should be supported, dual-mode impleme= ntation (MLD proxy and PIM on=0A> =A0 MAG or LMA) should be also discussed.= =0A> 4. How about following netext's discussions (multi-LMA, multi-IF,=0A> = =A0 roaming, etc.) for multicast?=0A> =0A> Some of the necessary discussion= s are already described in;=0A> http://tools.ietf.org/html/draft-asaeda-mul= timob-pmip6-extension-02=0A> =0A> Discussing the protocol extension is henc= e necessary.=0A> =0A> Regards,=0A> --=0A> Hitoshi Asaeda=0A> ______________= _________________________________=0A> multimob mailing list=0A> multimob@ie= tf.org=0A> https://www.ietf.org/mailman/listinfo/multimob=0A=0A=0A=0A From asaeda@sfc.wide.ad.jp Fri Dec 4 22:14:38 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 689403A67B1 for ; Fri, 4 Dec 2009 22:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.412 X-Spam-Level: ** X-Spam-Status: No, score=2.412 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] 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 SLjTKYeMCG6Q for ; Fri, 4 Dec 2009 22:14:31 -0800 (PST) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 0A08C3A6405 for ; Fri, 4 Dec 2009 22:14:30 -0800 (PST) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 6C84213D06C4; Sat, 5 Dec 2009 15:14:20 +0900 (JST) Date: Sat, 05 Dec 2009 15:14:20 +0900 (JST) Message-Id: <20091205.151420.60711179.asaeda@sfc.wide.ad.jp> To: luisc@it.uc3m.es From: Hitoshi Asaeda In-Reply-To: <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> References: <4B165C18.7060509@piuha.net> <20091203.155431.189432716.asaeda@sfc.wide.ad.jp> <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> 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, isoto@it.uc3m.es Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 05 Dec 2009 06:14:42 -0000 Luis, >> 1. One of the most emergent topics is about handover. >> There is no way to make a seamless handover for MN's multicast join >> state by MLD proxy or other existing protocols. >> The solution may also include the discussion about a context >> transfer mechanism. > > IMO, the concept of seamless handover applies basically to the > multicast service subscribed by the MN as it moves. If we are able of > guaranteeing no service disruption we are compliant with the idea of > seamless handover. I think that some of the current solution proposals > could satisfy this point at this stage, without protocol > modifications. MLD modification on a host-side implementation is not needed. I've been saying, since a MN does not give its join state to its upstream router (incl. proxy) unless no query reception, the MN cannot continue to reveive streams from nMAG until nMAG completes joins for all the subscribed channels. We are trying to tune some MLD timer value to *reduce* this join latency (a few seconds or more?) without protocol modification at this stage, but it does not *eliminate* or effectively reduce the latency. > Other aspect is the multicast subscription status at the MLD proxy > instance. In that case, for transferring the status between MLD > instances in different MAGs some extra signalling is needed. This > could imply some protocol modification. Right. It is the approach to address above issue I'm saying. >> 2. Basic design of MLD proxy requires configuring a single upstream >> interface, and hence some extension to support that MAG connects >> multiple LMAs would be necessary. > > I think we can separate here MLD-proxy upstream configuration from > MAG-LMA binding. The MLD proxy instance ignores any mobility > process. As far as the MAG has some interface active, the MLD proxy > instance could configure that interface as upstream interface for the > proxy function. From the MLD instance point of view it is not relevant > if there is an LMA function at the other end of the upstream > interface. The MLD instance needs at the other end a multicast router > or another MLD proxy device. If the equipment at the other end of the > upstream interface implements additional functions (such LMA one) is > not relevant from the MLD proxy function point of view. This is the way to escape from protocol modification, by configuring "multicast enable (MLD proxy enable) MAG" and "unicast only MAG". However, it does not enable to establish the shortest multicast path for every channel and will use triangle routes. And also it may require special operational or resource costs, I guess. Is it an optimal way this group's charter aims anyway? >> 3. No local routing supported only with MLD proxy. If local routing >> should be supported, dual-mode implementation (MLD proxy and PIM on >> MAG or LMA) should be also discussed. > > It is not clear to me what could be the behaviour of a mixed > MLD-proxy/PIM-multicast router. For instance, if some multicast group > is reacheable through the LMA, which is the way of requesting the > content? An MLD query or a PIM join? Both of them could make use of > the same tunnel between MAG and LMA ... Right. I've not confirmed the requirement from operator side to support dual-mode implementation, but the point we know is that enabling routing protocols on MAG does not require configuring its upstream interface and supports local routing. It also eliminates the limitation to make a MN become a multicast data source, while it is not in the current charter but good for the further "optimization". > I think that considering a pure MLD-proxy or a pure multicast router > behaviour is more realistic. IMO, both could be considered at this > stage (in my understanding, since the MN subscribes the content > through the MAG either acting as MLD proxy or multicast router, both > roles are compliant with the remote subscription condition) In fact, there is no big difference for the solution either with MLD proxy or PIM router on MAG. MLD proxy is simpler while PIM is more flexible due to no requirement of upstream interface configuration and local routing support. If PIM router model with no protocol modification should be described in a separate draft at this stage, I'm happy to cooperate for it. BTW, the complete solution with PMIP protocol modification will be shared with the scenario for both MLD proxy and PIM-enabled MAG because it mainly depends on a new join state transition mechanism, I expect. >> 4. How about following netext's discussions (multi-LMA, multi-IF, >> roaming, etc.) for multicast? > > I'm afraid that this could drive to protocol extensions not valid at > this stage At this stage, yes, I agree. Regards, -- Hitoshi Asaeda From stig@venaas.com Fri Dec 4 23:53:18 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 DCC663A687B for ; Fri, 4 Dec 2009 23:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.793 X-Spam-Level: X-Spam-Status: No, score=-0.793 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=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 cbASdByVLDG5 for ; Fri, 4 Dec 2009 23:53:17 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id C0D843A67B7 for ; Fri, 4 Dec 2009 23:53:16 -0800 (PST) Received: from [10.21.78.237] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTP id 25A2F22F40; Sat, 5 Dec 2009 08:53:03 +0100 (CET) Message-ID: <4B1A1101.6000607@venaas.com> Date: Fri, 04 Dec 2009 23:51:29 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hitoshi Asaeda References: <4B165C18.7060509@piuha.net> <20091203.155431.189432716.asaeda@sfc.wide.ad.jp> <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> <20091205.151420.60711179.asaeda@sfc.wide.ad.jp> In-Reply-To: <20091205.151420.60711179.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: isoto@it.uc3m.es, multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 05 Dec 2009 07:53:19 -0000 Hitoshi Asaeda wrote: > Luis, > >>> 1. One of the most emergent topics is about handover. >>> There is no way to make a seamless handover for MN's multicast join >>> state by MLD proxy or other existing protocols. >>> The solution may also include the discussion about a context >>> transfer mechanism. >> IMO, the concept of seamless handover applies basically to the >> multicast service subscribed by the MN as it moves. If we are able of >> guaranteeing no service disruption we are compliant with the idea of >> seamless handover. I think that some of the current solution proposals >> could satisfy this point at this stage, without protocol >> modifications. > > MLD modification on a host-side implementation is not needed. > I've been saying, since a MN does not give its join state to its > upstream router (incl. proxy) unless no query reception, the MN cannot > continue to reveive streams from nMAG until nMAG completes joins > for all the subscribed channels. > We are trying to tune some MLD timer value to *reduce* this join > latency (a few seconds or more?) without protocol modification at this > stage, but it does not *eliminate* or effectively reduce the latency. > >> Other aspect is the multicast subscription status at the MLD proxy >> instance. In that case, for transferring the status between MLD >> instances in different MAGs some extra signalling is needed. This >> could imply some protocol modification. > > Right. It is the approach to address above issue I'm saying. > >>> 2. Basic design of MLD proxy requires configuring a single upstream >>> interface, and hence some extension to support that MAG connects >>> multiple LMAs would be necessary. >> I think we can separate here MLD-proxy upstream configuration from >> MAG-LMA binding. The MLD proxy instance ignores any mobility >> process. As far as the MAG has some interface active, the MLD proxy >> instance could configure that interface as upstream interface for the >> proxy function. From the MLD instance point of view it is not relevant >> if there is an LMA function at the other end of the upstream >> interface. The MLD instance needs at the other end a multicast router >> or another MLD proxy device. If the equipment at the other end of the >> upstream interface implements additional functions (such LMA one) is >> not relevant from the MLD proxy function point of view. Right. With respect to the MLD-proxy at the MAG, it can really be policy and/or configuration which upstream interface is used for the various MNs. Which means, which MLD-proxy instance handles the particular MAG-MN interface. Depending on policy/config it can be the usual LMA for the MN, but can possibly be any interface, like an interface to a local router (if you want to subscribe in the local network instead of home subscription), or it could be through say a tunnel interface to another remote router handling multicast, this could also maybe be a "multicast LMA", although I'm not sure yet whether that is a good term. What I'm trying to say is that having an MLD-proxy at the MAG allows for other approaches than just using the LMA-MAG, and it can maybe be done on a per MN basis. > This is the way to escape from protocol modification, by configuring > "multicast enable (MLD proxy enable) MAG" and "unicast only MAG". > However, it does not enable to establish the shortest multicast path > for every channel and will use triangle routes. And also it may > require special operational or resource costs, I guess. > Is it an optimal way this group's charter aims anyway? I feel we need a solution that does not require multicast support in the local network and which does subscription through the MAG-LMA tunnel. Which also the charter says. But as I wrote above, the proxy approach could allow local subscription too. Describing that should maybe be left for later, but I believe it is a simple extension. I think it's good if we describe a base model, but which is easily extensible. >>> 3. No local routing supported only with MLD proxy. If local routing >>> should be supported, dual-mode implementation (MLD proxy and PIM on >>> MAG or LMA) should be also discussed. >> It is not clear to me what could be the behaviour of a mixed >> MLD-proxy/PIM-multicast router. For instance, if some multicast group >> is reacheable through the LMA, which is the way of requesting the >> content? An MLD query or a PIM join? Both of them could make use of >> the same tunnel between MAG and LMA ... > > Right. > I've not confirmed the requirement from operator side to support > dual-mode implementation, but the point we know is that enabling > routing protocols on MAG does not require configuring its upstream > interface and supports local routing. It also eliminates the > limitation to make a MN become a multicast data source, while it is > not in the current charter but good for the further "optimization". > >> I think that considering a pure MLD-proxy or a pure multicast router >> behaviour is more realistic. IMO, both could be considered at this >> stage (in my understanding, since the MN subscribes the content >> through the MAG either acting as MLD proxy or multicast router, both >> roles are compliant with the remote subscription condition) > > In fact, there is no big difference for the solution either with MLD > proxy or PIM router on MAG. > MLD proxy is simpler while PIM is more flexible due to no requirement > of upstream interface configuration and local routing support. If PIM > router model with no protocol modification should be described in a > separate draft at this stage, I'm happy to cooperate for it. I'm not so sure about mixing MLD proxy and PIM router either. You could certainly do PIM instead of MLD proxy, it's almost identical, but as you say, a bit more flexible. My only worry about doing PIM on the MAG is that it's more heavy duty. It also requires LMAs to support PIM I think, at least if you think of doing the equivalent of base MLD-proxy approach with PIM instead. While with MLD-proxy you have a choice whether the LMA should be another MLD-proxy or a PIM router. In a way this can be a deployment choice, but you have a problem if your MAG only supports PIM and LMA only MLD. I think this point is certainly worth discussing. Maybe we can keep discussing it now and see what people think. I'm leaning towards MLD-proxy as a more simple basic solution (with PIM a possible later improvement), but depending on the resources available at MAGs, PIM could certainly be an option. One consideration here is the complexity of a single PIM instance with multiple upstream interfaces, compared to multiple MLD-proxy instances serving those same upstream interfaces. PIM is significantly more complex (and it comes in addition to doing MLD on the downstream interfaces), but with many upstream interfaces, PIM might be easier. I also want to say though that if we later describe new solutions involving protocol changes, I think one could also imagine a proxy implementation that handles multiple upstream interfaces. Or it is in a way an implementation detail how you implement multiple proxy instances in the most efficient way. Stig > BTW, the complete solution with PMIP protocol modification will be > shared with the scenario for both MLD proxy and PIM-enabled MAG > because it mainly depends on a new join state transition mechanism, I > expect. > >>> 4. How about following netext's discussions (multi-LMA, multi-IF, >>> roaming, etc.) for multicast? >> I'm afraid that this could drive to protocol extensions not valid at >> this stage > > At this stage, yes, I agree. > > Regards, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From luisc@it.uc3m.es Sat Dec 5 03:45: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 E105A3A683B for ; Sat, 5 Dec 2009 03:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 nmMdW1aFdoj8 for ; Sat, 5 Dec 2009 03:45:37 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id D52CE3A6860 for ; Sat, 5 Dec 2009 03:45:35 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 6344BBA65F2; Sat, 5 Dec 2009 12:45:23 +0100 (CET) Received: from 96.pool85-49-221.dynamic.orange.es (96.pool85-49-221.dynamic.orange.es [85.49.221.96]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Sat, 05 Dec 2009 12:45:22 +0100 Message-ID: <20091205124522.4q9osw00w0s8wck8@webcartero01.uc3m.es> Date: Sat, 05 Dec 2009 12:45:22 +0100 From: "Luis M. Contreras" To: Hitoshi Asaeda References: <4B165C18.7060509@piuha.net> <20091203.155431.189432716.asaeda@sfc.wide.ad.jp> <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> <20091205.151420.60711179.asaeda@sfc.wide.ad.jp> In-Reply-To: <20091205.151420.60711179.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: isoto@it.uc3m.es, multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 05 Dec 2009 11:45:38 -0000 Hitoshi Asaeda dijo: > > MLD modification on a host-side implementation is not needed. > I've been saying, since a MN does not give its join state to its > upstream router (incl. proxy) unless no query reception, the MN cannot > continue to reveive streams from nMAG until nMAG completes joins > for all the subscribed channels. > We are trying to tune some MLD timer value to *reduce* this join > latency (a few seconds or more?) without protocol modification at this > stage, but it does not *eliminate* or effectively reduce the latency. > I think the method we propose in draft-contreras-multimob-msd-00 to support the MN handover by temporally redirecting the current multicast flow (subscribed by the MN) from pMAG to nMAG till (normal or tuned) subscription renewal can effectively reduce the latency in the reception of the multicast content once the MN is attached to nMAG, at the cost of more bandwidth temporally in the core network, as well as some other inefficiencies (temporal routing ineficiency, MTU reduction, etc). I think it is something we have to trade off. Regards, Luis From schmidt@informatik.haw-hamburg.de Sat Dec 5 05: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 41D273A6816 for ; Sat, 5 Dec 2009 05:34:02 -0800 (PST) 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 RY0yGd2Rvza9 for ; Sat, 5 Dec 2009 05:34:01 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 1ACD63A6837 for ; Sat, 5 Dec 2009 05:33:59 -0800 (PST) Envelope-to: multimob@ietf.org Received: from 93-40-137-39.ip39.fastwebnet.it ([93.40.137.39] helo=[192.168.2.29]) by mail2.rz.htw-berlin.de with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NGulg-0002iM-VL; Sat, 05 Dec 2009 14:33:49 +0100 Message-ID: <4B1A612F.9050005@informatik.haw-hamburg.de> Date: Sat, 05 Dec 2009 14:33:35 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Luis M. Contreras" References: <4B165C18.7060509@piuha.net> <20091203.155431.189432716.asaeda@sfc.wide.ad.jp> <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> <20091205.151420.60711179.asaeda@sfc.wide.ad.jp> <20091205124522.4q9osw00w0s8wck8@webcartero01.uc3m.es> In-Reply-To: <20091205124522.4q9osw00w0s8wck8@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: isoto@it.uc3m.es, multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 05 Dec 2009 13:34:02 -0000 Hi Luis, Luis M. Contreras wrote: > Hitoshi Asaeda dijo: > >> >> MLD modification on a host-side implementation is not needed. >> I've been saying, since a MN does not give its join state to its >> upstream router (incl. proxy) unless no query reception, the MN cannot >> continue to reveive streams from nMAG until nMAG completes joins >> for all the subscribed channels. >> We are trying to tune some MLD timer value to *reduce* this join >> latency (a few seconds or more?) without protocol modification at this >> stage, but it does not *eliminate* or effectively reduce the latency. >> > > I think the method we propose in draft-contreras-multimob-msd-00 to > support the MN handover by temporally redirecting the current multicast > flow (subscribed by the MN) from pMAG to nMAG till (normal or tuned) > subscription renewal can effectively reduce the latency in the reception > of the multicast content once the MN is attached to nMAG, at the cost of > more bandwidth temporally in the core network, as well as some other > inefficiencies (temporal routing ineficiency, MTU reduction, etc). I > think it is something we have to trade off. > You do point at the proposal redirecting via the LMA? Mhmm, then are you sure about this? We discussed the temporal handover behavior prior to IETF 76 online, and if I remember correctly, timing was exactly the same as for the "full" handover ?? 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 asaeda@sfc.wide.ad.jp Sun Dec 6 23:39: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 1E5843A67D6 for ; Sun, 6 Dec 2009 23:39:48 -0800 (PST) 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 pYsOECwnJY5v for ; Sun, 6 Dec 2009 23:39:47 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id E50893A67DB for ; Sun, 6 Dec 2009 23:39:46 -0800 (PST) Received: from localhost (unknown [IPv6:2001:200:0:8801:225:ff:feee:626f]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 353D54CF06; Mon, 7 Dec 2009 16:39:32 +0900 (JST) Date: Mon, 07 Dec 2009 16:39:20 +0900 (JST) Message-Id: <20091207.163920.115915916.asaeda@sfc.wide.ad.jp> To: stig@venaas.com From: Hitoshi Asaeda In-Reply-To: <4B1A1101.6000607@venaas.com> References: <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> <20091205.151420.60711179.asaeda@sfc.wide.ad.jp> <4B1A1101.6000607@venaas.com> 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 Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 07 Dec 2009 07:39:48 -0000 Stig, I agree that discussing many technical issues in this ML is beneficial to decide the current and future direction of this group. On the other hand, I thought the primary point raised by Jari was regarding the necessity of protocol modification for "optimized" mobile multicast. Although I don't restart the discussion about the "optimization", what we should know now is what functions should be taken into account for mobile multicast and which functions may not properly work without protocol modification or how such functions can be revived by effective protocol modification. I think a seamless handover (bullet 1) requires protocol modification. It is impossible to provide a seamless handover without protocol modification. This is the main concern. I also raised other scenarios (bullet 2 to 4). In the current charter, although some of them could be implemented by some methods without protocol modification. However, for them, as well as bullet 1, protocol performance may be improved or operational cost may be reduced if protocol modification is allowed. This is still my guess, though. Again, I don't deny the current MLD proxy approach. My point is that it is beneficial for this group to move forward by rechartering after the current basic proposal (i.e. implementation with no protocol modification) is clarified and completed. Ok, then I reply Stig's comments below. > Right. With respect to the MLD-proxy at the MAG, it can really be policy > and/or configuration which upstream interface is used for the various > MNs. Which means, which MLD-proxy instance handles the particular MAG-MN > interface. Depending on policy/config it can be the usual LMA for the > MN, but can possibly be any interface, like an interface to a local > router (if you want to subscribe in the local network instead of home > subscription), or it could be through say a tunnel interface to another > remote router handling multicast, this could also maybe be a "multicast > LMA", although I'm not sure yet whether that is a good term. > > What I'm trying to say is that having an MLD-proxy at the MAG allows for > other approaches than just using the LMA-MAG, and it can maybe be done > on a per MN basis. How do you do it? By configuration? Per MN? Per channel? It is called "static route", isn't it? :) > > This is the way to escape from protocol modification, by configuring > > "multicast enable (MLD proxy enable) MAG" and "unicast only MAG". > > However, it does not enable to establish the shortest multicast path > > for every channel and will use triangle routes. And also it may > > require special operational or resource costs, I guess. > > Is it an optimal way this group's charter aims anyway? > > I feel we need a solution that does not require multicast support in > the local network and which does subscription through the MAG-LMA > tunnel. Which also the charter says. But as I wrote above, the proxy > approach could allow local subscription too. Describing that should > maybe be left for later, but I believe it is a simple extension. I think > it's good if we describe a base model, but which is easily extensible. I cannot imagine such mechanism by a simple extension, but I agree it'd be good if possible. > >>> 3. No local routing supported only with MLD proxy. If local routing > >>> should be supported, dual-mode implementation (MLD proxy and PIM on > >>> MAG or LMA) should be also discussed. > > I'm not so sure about mixing MLD proxy and PIM router either. You > could certainly do PIM instead of MLD proxy, it's almost identical, > but as you say, a bit more flexible. My only worry about doing PIM > on the MAG is that it's more heavy duty. It also requires LMAs to > support PIM I think, at least if you think of doing the equivalent > of base MLD-proxy approach with PIM instead. While with MLD-proxy > you have a choice whether the LMA should be another MLD-proxy or a > PIM router. In a way this can be a deployment choice, but you have > a problem if your MAG only supports PIM and LMA only MLD. Right. Hence I said the requirement of "dual-mode implementation". > I think this point is certainly worth discussing. Maybe we can keep > discussing it now and see what people think. I'm leaning towards > MLD-proxy as a more simple basic solution (with PIM a possible later > improvement), but depending on the resources available at MAGs, PIM > could certainly be an option. One consideration here is the complexity > of a single PIM instance with multiple upstream interfaces, compared to > multiple MLD-proxy instances serving those same upstream interfaces. PIM > is significantly more complex (and it comes in addition to doing MLD on > the downstream interfaces), but with many upstream interfaces, PIM might > be easier. Yes, that is the point. > I also want to say though that if we later describe new solutions > involving protocol changes, I think one could also imagine a proxy > implementation that handles multiple upstream interfaces. Or it is > in a way an implementation detail how you implement multiple proxy > instances in the most efficient way. Well, according to its concept, proxy modification is more difficult, because it behaves as a host (from a view of its upstream router) and does not select an incoming interface. If it selects an incoming interface intelligently and dynamically, it's called a router. :) For PMIP modification, adding the state transition mechanism with defining new messages and CT mechanism would address most issues and work with any multicast instance (e.g. proxy or router). Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Sun Dec 6 23:51:15 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 D042528C127 for ; Sun, 6 Dec 2009 23:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.111 X-Spam-Level: ** X-Spam-Status: No, score=2.111 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 iCWh0Hr-YKzu for ; Sun, 6 Dec 2009 23:51:15 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 170A828C123 for ; Sun, 6 Dec 2009 23:51:15 -0800 (PST) Received: from localhost (dhcp-143-254.sfc.wide.ad.jp [203.178.143.254]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 89C6F4CFD2; Mon, 7 Dec 2009 16:50:59 +0900 (JST) Date: Mon, 07 Dec 2009 16:50:58 +0900 (JST) Message-Id: <20091207.165058.223254814.asaeda@sfc.wide.ad.jp> To: luisc@it.uc3m.es From: Hitoshi Asaeda In-Reply-To: <20091205124522.4q9osw00w0s8wck8@webcartero01.uc3m.es> References: <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> <20091205.151420.60711179.asaeda@sfc.wide.ad.jp> <20091205124522.4q9osw00w0s8wck8@webcartero01.uc3m.es> 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 Cc: isoto@it.uc3m.es, multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 07 Dec 2009 07:51:15 -0000 > > We are trying to tune some MLD timer value to *reduce* this join > > latency (a few seconds or more?) without protocol modification at this > > stage, but it does not *eliminate* or effectively reduce the latency. > > I think the method we propose in draft-contreras-multimob-msd-00 to > support the MN handover by temporally redirecting the current > multicast flow (subscribed by the MN) from pMAG to nMAG till > (normal or tuned) subscription renewal can effectively reduce the > latency in the reception of the multicast content once the MN is > attached to nMAG, at the cost of more bandwidth temporally in the > core network, as well as some other inefficiencies (temporal > routing ineficiency, MTU reduction, etc). I think it is something > we have to trade off. I took a glance at section 7 in your draft. I'm sorry, but I cannot imagine that your idea mentioned in this section does not require any protocol modification. Or it seems to me that some original implementation is required. No? Is it obvious that every function you propose is implemented by an ordinal PMIP implementation (i.e. only with standard spec)? For instance, regarding pMAG-assisted handover, you say; "the pMAG can be able to temporally forward via the LMA a copy of the multicast content within an unicast flow towards the new location of the MN, brahbrah", but is this a common behavior of rfc5213 compliant MAG? Regards, -- Hitoshi Asaeda From stig@venaas.com Mon Dec 7 00:15: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 6DFAD3A6814 for ; Mon, 7 Dec 2009 00:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.742 X-Spam-Level: X-Spam-Status: No, score=-0.742 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=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 6c9JMOKEEdVS for ; Mon, 7 Dec 2009 00:15:34 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 7099F28C12A for ; Mon, 7 Dec 2009 00:15:33 -0800 (PST) Received: from [10.21.68.55] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTP id 8207E33B66; Mon, 7 Dec 2009 09:15:21 +0100 (CET) Message-ID: <4B1CB939.8090902@venaas.com> Date: Mon, 07 Dec 2009 00:13:45 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hitoshi Asaeda References: <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> <20091205.151420.60711179.asaeda@sfc.wide.ad.jp> <4B1A1101.6000607@venaas.com> <20091207.163920.115915916.asaeda@sfc.wide.ad.jp> In-Reply-To: <20091207.163920.115915916.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 07 Dec 2009 08:15:35 -0000 Hitoshi Asaeda wrote: > Stig, > > I agree that discussing many technical issues in this ML is beneficial > to decide the current and future direction of this group. > On the other hand, I thought the primary point raised by Jari was > regarding the necessity of protocol modification for "optimized" > mobile multicast. > Although I don't restart the discussion about the "optimization", what > we should know now is what functions should be taken into account for > mobile multicast and which functions may not properly work without > protocol modification or how such functions can be revived by > effective protocol modification. > > I think a seamless handover (bullet 1) requires protocol modification. > It is impossible to provide a seamless handover without protocol > modification. This is the main concern. I agree with you. And we have already seen several drafts that discuss various optimizations. Although we should not work on optimizations now, it might be worthwhile documenting the shortcomings of whatever basic solution we come up with. > I also raised other scenarios (bullet 2 to 4). In the current charter, > although some of them could be implemented by some methods without > protocol modification. However, for them, as well as bullet 1, > protocol performance may be improved or operational cost may be > reduced if protocol modification is allowed. This is still my guess, > though. > > Again, I don't deny the current MLD proxy approach. > My point is that it is beneficial for this group to move forward by > rechartering after the current basic proposal (i.e. implementation > with no protocol modification) is clarified and completed. We are in agreement then :) > > > Ok, then I reply Stig's comments below. > >> Right. With respect to the MLD-proxy at the MAG, it can really be policy >> and/or configuration which upstream interface is used for the various >> MNs. Which means, which MLD-proxy instance handles the particular MAG-MN >> interface. Depending on policy/config it can be the usual LMA for the >> MN, but can possibly be any interface, like an interface to a local >> router (if you want to subscribe in the local network instead of home >> subscription), or it could be through say a tunnel interface to another >> remote router handling multicast, this could also maybe be a "multicast >> LMA", although I'm not sure yet whether that is a good term. >> >> What I'm trying to say is that having an MLD-proxy at the MAG allows for >> other approaches than just using the LMA-MAG, and it can maybe be done >> on a per MN basis. > > How do you do it? By configuration? Per MN? Per channel? > It is called "static route", isn't it? :) OK, I didn't want to go into details, but for instance today you may have that your MNs are using different LMAs. In the same way I can imagine for instance that an operator could configure that MNs that use one LMA for unicast should get multicast locally, while MNs that use another LMA should get multicast from that LMA. There could be other ways of determining which proxy instance/upstream interface to use for a given MN. My point is just that I think there is a lot of flexibility in this approach. >>> This is the way to escape from protocol modification, by configuring >>> "multicast enable (MLD proxy enable) MAG" and "unicast only MAG". >>> However, it does not enable to establish the shortest multicast path >>> for every channel and will use triangle routes. And also it may >>> require special operational or resource costs, I guess. >>> Is it an optimal way this group's charter aims anyway? >> I feel we need a solution that does not require multicast support in >> the local network and which does subscription through the MAG-LMA >> tunnel. Which also the charter says. But as I wrote above, the proxy >> approach could allow local subscription too. Describing that should >> maybe be left for later, but I believe it is a simple extension. I think >> it's good if we describe a base model, but which is easily extensible. > > I cannot imagine such mechanism by a simple extension, but I agree > it'd be good if possible. > >>>>> 3. No local routing supported only with MLD proxy. If local routing >>>>> should be supported, dual-mode implementation (MLD proxy and PIM on >>>>> MAG or LMA) should be also discussed. >> I'm not so sure about mixing MLD proxy and PIM router either. You >> could certainly do PIM instead of MLD proxy, it's almost identical, >> but as you say, a bit more flexible. My only worry about doing PIM >> on the MAG is that it's more heavy duty. It also requires LMAs to >> support PIM I think, at least if you think of doing the equivalent >> of base MLD-proxy approach with PIM instead. While with MLD-proxy >> you have a choice whether the LMA should be another MLD-proxy or a >> PIM router. In a way this can be a deployment choice, but you have >> a problem if your MAG only supports PIM and LMA only MLD. > > Right. Hence I said the requirement of "dual-mode implementation". > >> I think this point is certainly worth discussing. Maybe we can keep >> discussing it now and see what people think. I'm leaning towards >> MLD-proxy as a more simple basic solution (with PIM a possible later >> improvement), but depending on the resources available at MAGs, PIM >> could certainly be an option. One consideration here is the complexity >> of a single PIM instance with multiple upstream interfaces, compared to >> multiple MLD-proxy instances serving those same upstream interfaces. PIM >> is significantly more complex (and it comes in addition to doing MLD on >> the downstream interfaces), but with many upstream interfaces, PIM might >> be easier. > > Yes, that is the point. > >> I also want to say though that if we later describe new solutions >> involving protocol changes, I think one could also imagine a proxy >> implementation that handles multiple upstream interfaces. Or it is >> in a way an implementation detail how you implement multiple proxy >> instances in the most efficient way. > > Well, according to its concept, proxy modification is more difficult, > because it behaves as a host (from a view of its upstream router) and > does not select an incoming interface. If it selects an incoming > interface intelligently and dynamically, it's called a router. :) I see your point, but I had a more static binding in mind. That according to some policy the upstream interface could be determined in a more static way. I'm not talking about say RPF here. Anyway, I think this is something we can discuss later if you like. > For PMIP modification, adding the state transition mechanism with > defining new messages and CT mechanism would address most issues and > work with any multicast instance (e.g. proxy or router). I think you're right, but need to think more about it. Stig > Regards, > -- > Hitoshi Asaeda From Dirk.von-Hugo@telekom.de Mon Dec 7 01:35: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 D878B3A67E4 for ; Mon, 7 Dec 2009 01:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[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 QHr7druMQGv3 for ; Mon, 7 Dec 2009 01:35:22 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id B9CC33A6778 for ; Mon, 7 Dec 2009 01:35:21 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 07 Dec 2009 10:35:05 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 10:35:05 +0100 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: Mon, 7 Dec 2009 10:35:03 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC8027848019F7DEA@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <4B1CB939.8090902@venaas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] IGMP/MLD Proxy at the MAG Thread-Index: Acp3FYWYmdnqMjfmSKyBOI8rZnvGQgABwELw References: <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> <20091205.151420.60711179.asaeda@sfc.wide.ad.jp> <4B1A1101.6000607@venaas.com><20091207.163920.115915916.asaeda@sfc.wide.ad.jp> <4B1CB939.8090902@venaas.com> From: To: , X-OriginalArrivalTime: 07 Dec 2009 09:35:05.0395 (UTC) FILETIME=[8EEBB030:01CA7720] Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 07 Dec 2009 09:35:23 -0000 Dear all, Thanks to all for this discussion! Especially concerning the proposed optimizations I would appreciate if = we could document such open issues in an I-D like the very draft one I = had prepared for Hiroshima = (http://tools.ietf.org/id/draft-von-hugo-multimob-future-work-00.txt) - = e.g. with your contributions for an updated version - or with a = completely new one, if this is more appropriate. What do you think? Best regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Stig Venaas Gesendet: Montag, 7. Dezember 2009 09:14 An: Hitoshi Asaeda Cc: multimob@ietf.org Betreff: Re: [multimob] IGMP/MLD Proxy at the MAG Hitoshi Asaeda wrote: > Stig, >=20 > I agree that discussing many technical issues in this ML is beneficial > to decide the current and future direction of this group. > On the other hand, I thought the primary point raised by Jari was > regarding the necessity of protocol modification for "optimized" > mobile multicast. > Although I don't restart the discussion about the "optimization", what > we should know now is what functions should be taken into account for > mobile multicast and which functions may not properly work without > protocol modification or how such functions can be revived by > effective protocol modification. > > I think a seamless handover (bullet 1) requires protocol modification. > It is impossible to provide a seamless handover without protocol > modification. This is the main concern. I agree with you. And we have already seen several drafts that discuss various optimizations. Although we should not work on optimizations now, it might be worthwhile documenting the shortcomings of whatever basic solution we come up with. > I also raised other scenarios (bullet 2 to 4). In the current charter, > although some of them could be implemented by some methods without > protocol modification. However, for them, as well as bullet 1, > protocol performance may be improved or operational cost may be > reduced if protocol modification is allowed. This is still my guess, > though. >=20 > Again, I don't deny the current MLD proxy approach. > My point is that it is beneficial for this group to move forward by > rechartering after the current basic proposal (i.e. implementation > with no protocol modification) is clarified and completed. We are in agreement then :) >=20 >=20 > Ok, then I reply Stig's comments below. >=20 >> Right. With respect to the MLD-proxy at the MAG, it can really be = policy >> and/or configuration which upstream interface is used for the various >> MNs. Which means, which MLD-proxy instance handles the particular = MAG-MN >> interface. Depending on policy/config it can be the usual LMA for the >> MN, but can possibly be any interface, like an interface to a local >> router (if you want to subscribe in the local network instead of home >> subscription), or it could be through say a tunnel interface to = another >> remote router handling multicast, this could also maybe be a = "multicast >> LMA", although I'm not sure yet whether that is a good term. >> >> What I'm trying to say is that having an MLD-proxy at the MAG allows = for >> other approaches than just using the LMA-MAG, and it can maybe be = done >> on a per MN basis. >=20 > How do you do it? By configuration? Per MN? Per channel? > It is called "static route", isn't it? :) OK, I didn't want to go into details, but for instance today you may have that your MNs are using different LMAs. In the same way I can imagine for instance that an operator could configure that MNs that use one LMA for unicast should get multicast locally, while MNs that use another LMA should get multicast from that LMA. There could be other ways of determining which proxy instance/upstream interface to use for a given MN. My point is just that I think there is a lot of flexibility in this approach. >>> This is the way to escape from protocol modification, by configuring >>> "multicast enable (MLD proxy enable) MAG" and "unicast only MAG". >>> However, it does not enable to establish the shortest multicast path >>> for every channel and will use triangle routes. And also it may >>> require special operational or resource costs, I guess. >>> Is it an optimal way this group's charter aims anyway? >> I feel we need a solution that does not require multicast support in >> the local network and which does subscription through the MAG-LMA >> tunnel. Which also the charter says. But as I wrote above, the proxy >> approach could allow local subscription too. Describing that should >> maybe be left for later, but I believe it is a simple extension. I = think >> it's good if we describe a base model, but which is easily = extensible. >=20 > I cannot imagine such mechanism by a simple extension, but I agree > it'd be good if possible. >=20 >>>>> 3. No local routing supported only with MLD proxy. If local = routing >>>>> should be supported, dual-mode implementation (MLD proxy and PIM = on >>>>> MAG or LMA) should be also discussed. >> I'm not so sure about mixing MLD proxy and PIM router either. You >> could certainly do PIM instead of MLD proxy, it's almost identical, >> but as you say, a bit more flexible. My only worry about doing PIM >> on the MAG is that it's more heavy duty. It also requires LMAs to >> support PIM I think, at least if you think of doing the equivalent >> of base MLD-proxy approach with PIM instead. While with MLD-proxy >> you have a choice whether the LMA should be another MLD-proxy or a >> PIM router. In a way this can be a deployment choice, but you have >> a problem if your MAG only supports PIM and LMA only MLD. >=20 > Right. Hence I said the requirement of "dual-mode implementation". >=20 >> I think this point is certainly worth discussing. Maybe we can keep >> discussing it now and see what people think. I'm leaning towards >> MLD-proxy as a more simple basic solution (with PIM a possible later >> improvement), but depending on the resources available at MAGs, PIM >> could certainly be an option. One consideration here is the = complexity >> of a single PIM instance with multiple upstream interfaces, compared = to >> multiple MLD-proxy instances serving those same upstream interfaces. = PIM >> is significantly more complex (and it comes in addition to doing MLD = on >> the downstream interfaces), but with many upstream interfaces, PIM = might >> be easier. >=20 > Yes, that is the point. >=20 >> I also want to say though that if we later describe new solutions >> involving protocol changes, I think one could also imagine a proxy >> implementation that handles multiple upstream interfaces. Or it is >> in a way an implementation detail how you implement multiple proxy >> instances in the most efficient way. >=20 > Well, according to its concept, proxy modification is more difficult, > because it behaves as a host (from a view of its upstream router) and > does not select an incoming interface. If it selects an incoming > interface intelligently and dynamically, it's called a router. :) I see your point, but I had a more static binding in mind. That according to some policy the upstream interface could be determined in a more static way. I'm not talking about say RPF here. Anyway, I think this is something we can discuss later if you like. > For PMIP modification, adding the state transition mechanism with > defining new messages and CT mechanism would address most issues and > work with any multicast instance (e.g. proxy or router). I think you're right, but need to think more about it. Stig > Regards, > -- > Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Mon Dec 7 07:37:18 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 C589E3A6A6E for ; Mon, 7 Dec 2009 07:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.215, 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 libhpovh-0TZ for ; Mon, 7 Dec 2009 07:37:18 -0800 (PST) Received: from web111409.mail.gq1.yahoo.com (web111409.mail.gq1.yahoo.com [67.195.15.180]) by core3.amsl.com (Postfix) with SMTP id B12FE3A68C4 for ; Mon, 7 Dec 2009 07:37:17 -0800 (PST) Received: (qmail 38042 invoked by uid 60001); 7 Dec 2009 15:37:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1260200224; bh=QZvwwCQcELkGER0Ry/a82ZEi+O+knSuI1/DesnO3ydE=; 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=UG+ehTOAnmXdBQHKXCSvYsUlhu6nkWDmwnLH7HvEcAuJ4kSpzW7eo3CW2A5H6zqrZpZir+8immXWw9jQhgZTVYgQLpRcK2K9Vl+Lf6J8xA7BPH93n+IMFEouO1eML+IvfpYT8efOURLSA9UDZaek0MdF5oonbDaGvJcTsUJ4kbQ= 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=mMGcEWvsHYVx9JGrt96tkv43aSVeytGM1YGzyUjQpOlV9RSUpRDeNeV+IbWYIJxrh+sPdxlIOPYZnIQ9w3DUAAFotG9iivO3jyltolW8TmK54dR9/x1dcX226WKg3ymo5sQv8H3oB6NdzlBeAXKflTCJh/ARLyGXETLXzh5Sv5g=; Message-ID: <689617.37361.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: eGo2UVYVM1n3UUoHRZtcchx0IuqmEkXv6KVLFc2irXkVNHE5OHEjfJf4ugoeGlH3sMxrJ4g5WCV_gKGp.nhXm5TSfaWqHgqdNbCFHU20FDEjCOZtX6ohMjW_yFuEyJl6L4_k6PEiEe8hK1_PxzuXOkvl74kva3.FV6cVCWQYrI0pE6Lxl7aWVlq5KQxXXQQnzNagD4230UL.U4TmtBS3EYx3S4plxRJ.lsCLLOAJjjo0HzwM6RtGQHm4nfim.embayDe1qBcj23cR37zD23Hf3cFRPo.UYcqS0CHA0WgIg_mveKMOKttTwEF1P.ivBbeSI5KLfGSrXbyV31GMBO9XfLnYe4.TnzbhrQYVj0b Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Mon, 07 Dec 2009 07:37:04 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> <20091205.151420.60711179.asaeda@sfc.wide.ad.jp> <4B1A1101.6000607@venaas.com><20091207.163920.115915916.asaeda@sfc.wide.ad.jp> <4B1CB939.8090902@venaas.com> <643B0A1D1A13AB498304E0BBC8027848019F7DEA@S4DE8PSAAQC.mitte.t-com.de> Date: Mon, 7 Dec 2009 07:37:04 -0800 (PST) From: Behcet Sarikaya To: Dirk.von-Hugo@telekom.de In-Reply-To: <643B0A1D1A13AB498304E0BBC8027848019F7DEA@S4DE8PSAAQC.mitte.t-com.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 07 Dec 2009 15:37:18 -0000 ----- Original Message ---- > From: "Dirk.von-Hugo@telekom.de" > To: stig@venaas.com; asaeda@sfc.wide.ad.jp > Cc: multimob@ietf.org; sarikaya@ieee.org > Sent: Mon, December 7, 2009 3:35:03 AM > Subject: AW: [multimob] IGMP/MLD Proxy at the MAG > > Dear all, > Thanks to all for this discussion! > Especially concerning the proposed optimizations I would appreciate if we could > document such open issues in an I-D like the very draft one I had prepared for > Hiroshima (http://tools.ietf.org/id/draft-von-hugo-multimob-future-work-00.txt) > - e.g. with your contributions for an updated version - or with a completely new > one, if this is more appropriate. > What do you think? This is a good initiative. It would help us at this stage to start working on a problem statement draft on IGMP/MLD Proxy issues which could later on be used in rechartering. --behcet From behcetsarikaya@yahoo.com Tue Dec 8 08:53: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 3D62028C122 for ; Tue, 8 Dec 2009 08:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.195, 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 MKAhS7jFlIvu for ; Tue, 8 Dec 2009 08:53:02 -0800 (PST) Received: from web111409.mail.gq1.yahoo.com (web111409.mail.gq1.yahoo.com [67.195.15.180]) by core3.amsl.com (Postfix) with SMTP id 6899B3A6A1C for ; Tue, 8 Dec 2009 08:53:02 -0800 (PST) Received: (qmail 10560 invoked by uid 60001); 8 Dec 2009 16:52:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1260291169; bh=gAZlpTZsJ2NxuyOa2KxHbzIGu8Yvdy7kE2zzL8KC1nE=; 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=Ah7qVk6Z/iIvgkIamWminHMyjA4NoPbfMOnSadRW7ArBtsXagCNrpzdtbxwKAKaZKEqdsl8pUtRF4ChefRPDevcEg+0bTLjbEFZj9QC+dJdPxj52PjdKzO4rK5s94TM3PLg1onQINZ2whiQgm7DAPWxb2FjkupW2jb6GhGcSfnU= 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=C0aMnEndJIumZyxDswyPa/fjbs9G9SkRAY2Awop2Qvi8ZYH8o2lnOGPmJg1jJ4qoAJs/X/7xxyMZqSoOKGE97cGsgaY59XS42sj9ubSabFGPZQx2046JJlPTeQnmCkVvjMkuUBiYHquEzg+TgTNqC4TqEljimXC8ztKYstWQi3M=; Message-ID: <553771.9779.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: x4hvvY8VM1kyEQQOWJcXVRhuSx.ye6jDjvpXi_EdHm2BhcSFd7SxEP2LZuB8x8Aqkf.Jcnw84ijHhwrXYdatfINWXq6WOkfrvsboYraE_9pAcvSbn4ZcwHUaXcy5GeM1nVLVHZq8YaDFfpqIvxl8EUKKf9CpiRG5ig_Oy0VC4fqn55xPRKhGJ407Yq.rC4p8RYa2dTWyylWPi0xB.Q8wlWSidDtuWaY7aKbgSo89gaDUI2Vkz5gDO7o6W7UKmnd1R_meFu0TH8a.0nQgQylr9WaMoJVOHv034PYKzx5xUm.Ghl59BU1L_PhMpRMtfHmZq9Hwu5DCA3VXkfWtVNy6iyOQpz5J7QKbXsBNaqBR Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Tue, 08 Dec 2009 08:52:49 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: <555186.69483.qm@web111406.mail.gq1.yahoo.com> <4B0AE50D.4020905@venaas.com> <4B165C18.7060509@piuha.net> <20091203.155431.189432716.asaeda@sfc.wide.ad.jp> <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> Date: Tue, 8 Dec 2009 08:52:49 -0800 (PST) From: Behcet Sarikaya To: "Luis M. Contreras" , Hitoshi Asaeda In-Reply-To: <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: isoto@it.uc3m.es, multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 08 Dec 2009 16:53:03 -0000 =0A=0A=0A=0A----- Original Message ----=0A> From: Luis M. Contreras =0A> To: Hitoshi Asaeda =0A> Cc: multimob= @ietf.org; isoto@it.uc3m.es=0A> Sent: Thu, December 3, 2009 12:10:24 PM=0A>= Subject: Re: [multimob] IGMP/MLD Proxy at the MAG=0A> =0A> Hi Hitoshi,=0A>= =0A> some comments below:=0A> =0A> Hitoshi Asaeda dijo:=0A> =0Asnipped=0A= =0A> =0A> > 2. Basic design of MLD proxy requires configuring a single upst= ream=0A> >=A0 interface, and hence some extension to support that MAG conne= cts=0A> >=A0 multiple LMAs would be necessary.=0A> =0A> I think we can sepa= rate here MLD-proxy upstream configuration from MAG-LMA =0A> binding. The M= LD proxy instance ignores any mobility process. As far as the MAG =0A> has = some interface active, the MLD proxy instance could configure that interfac= e =0A> as upstream interface for the proxy function. From the MLD instance = point of =0A> view it is not relevant if there is an LMA function at the ot= her end of the =0A> upstream interface. The MLD instance needs at the other= end a multicast router =0A> or another MLD proxy device. If the equipment = at the other end of the upstream =0A> interface implements additional funct= ions (such LMA one) is not relevant from =0A> the MLD proxy function point = of view.=0A=0AAren't we talking about extending RFC 4605 here? These are go= od ideas that we should probably pursue but for extending what RFC 4605 def= ined?=0A=0A> =0A> > 3. No local routing supported only with MLD proxy. If l= ocal routing=0A> >=A0 should be supported, dual-mode implementation (MLD pr= oxy and PIM on=0A> >=A0 MAG or LMA) should be also discussed.=0A> =0A> It i= s not clear to me what could be the behaviour of a mixed =0A> MLD-proxy/PIM= -multicast router. For instance, if some multicast group is =0A> reacheable= through the LMA, which is the way of requesting the content? An MLD =0A> q= uery or a PIM join? Both of them could make use of the same tunnel between = MAG =0A> and LMA ...=0A> I think that considering a pure MLD-proxy or a pur= e multicast router behaviour =0A> is more realistic. IMO, both could be con= sidered at this stage (in my =0A> understanding, since the MN subscribes th= e content through the MAG either acting =0A> as MLD proxy or multicast rout= er, both roles are compliant with the remote =0A> subscription condition)= =0A> =0A=0A=0ALocal routing is not yet defined in Netext. Even if it was de= fined, I don't see how it would affect our work as we are restricted with r= eceiver mobility in the charter?=0A=0A=0A--behcet=0A=0A=0A From behcetsarikaya@yahoo.com Tue Dec 8 10:04: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 4BCA33A67A7 for ; Tue, 8 Dec 2009 10:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.751 X-Spam-Level: X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[AWL=-1.086, BAYES_50=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 ph2voNgmDnoN for ; Tue, 8 Dec 2009 10:04:49 -0800 (PST) Received: from web111406.mail.gq1.yahoo.com (web111406.mail.gq1.yahoo.com [67.195.15.162]) by core3.amsl.com (Postfix) with SMTP id 7B72B3A63EC for ; Tue, 8 Dec 2009 10:04:49 -0800 (PST) Received: (qmail 34732 invoked by uid 60001); 8 Dec 2009 18:04:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1260295476; bh=3qzyms4dOjwjt/KifyFQ/T8s3waHBvTJ2KeVYcIGT48=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hDm6St8maGuXL8bB31ijJ/yDR8yVaabhDVg3tVuglNwb5TlYP36eGMvp9U7p6Wp1wjMLhRwGGXaG88TWz07FHKN4N/j21CbDisAC4TzHfYXXpX2XWkQ1/oL+yqVrlUWw6OQWNRi/36+7bxeiLwk7/XDqUDC8/ytOFXzXlIis0zo= 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=O29yEdj9KQyDijdHnvO/pMHUXpjoiWay7a5x/Q+ws2N+9F2jmhGUYr6EKcSPFuww6Q7+oqhp00DwapQ0R19TFHAU0LLbcjOrjZ7t/ESB5lrrIo9kWKXlNwEDgvMR8iCSrIx5q18brlF31OJ92k/HgF3E1xeb29jJP1nCU59hvEc=; Message-ID: <746476.34430.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: 3x9YTIgVM1n2WPSta7GFBgEN0K3WjwT5DPbhvs67zNi5f3didXfSTVo.53iXku5Dcax_kSi3vcq98p.we_WbNLhpFICOgwswTXLz4rRklhtv3gmB52xyAK5FchHcjsGdfHIr50C_X66NwMnVGn0dOjjlDQR9xg1ZAvbiWypplmJQ.Qdt8cszumnsDxJrLboTM6uNKLLGdE4t0_vLybNrAqK1xYPJtcQTg4X3sURghW5n.IkyTleZbVuAHERCddQbes3aK1mIYUG9_5Q2lIe.dWka9UdxlImnpWnknIOK7u3Vi11Yqac- Received: from [206.16.17.212] by web111406.mail.gq1.yahoo.com via HTTP; Tue, 08 Dec 2009 10:04:36 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 Date: Tue, 8 Dec 2009 10:04:36 -0800 (PST) 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] Consensus call for MLD Proxy 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, 08 Dec 2009 18:04:50 -0000 Hello all,=0A=A0 =0A=A0 We have had a lot of good discussion and heard argu= ments on various aspects on this:=0AIGMP/MLD Proxy at the MAG should be the= approach taken for the charter item:=0A=0AInitial version of a document ex= plaining the use of multicast in PMIPv6=0A=0A=0APlease respond if you SUPPO= RT or=0A=0ADO NOT SUPPORT=0A=0Ait.=0A=0AChairs.=0A=0A=0A From sgundave@cisco.com Tue Dec 8 10:05:59 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 361E128C1C6 for ; Tue, 8 Dec 2009 10:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 TYQKbPnxjn2C for ; Tue, 8 Dec 2009 10:05:58 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 486DA28C168 for ; Tue, 8 Dec 2009 10:05:58 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAN8jHkurR7Ht/2dsb2JhbACQHbIDlyGEMgSBaA X-IronPort-AV: E=Sophos;i="4.47,363,1257120000"; d="scan'208";a="446637734" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 08 Dec 2009 18:05:48 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB8I5mGk000392; Tue, 8 Dec 2009 18:05:48 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 10:05:47 -0800 Received: from 10.32.246.211 ([10.32.246.211]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 Dec 2009 18:05:47 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 08 Dec 2009 10:06:18 -0800 From: Sri Gundavelli To: Behcet Sarikaya Message-ID: Thread-Topic: IGMP/MLD Proxy - Breaking the Deadlock Thread-Index: Acp4MSOh5Fjg6blLh0C0bb7lM77Mug== In-Reply-To: <553771.9779.qm@web111409.mail.gq1.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Dec 2009 18:05:47.0888 (UTC) FILETIME=[11AECF00:01CA7831] Cc: multimob@ietf.org Subject: [multimob] IGMP/MLD Proxy - Breaking the Deadlock 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, 08 Dec 2009 18:05:59 -0000 My thoughts on this. I'm bit concerned the way this is heading. First, this is a new working group and folks have joined with lot of interest and willingness to solve some issues. But, here we are at a deadlock at step-1. This is not a good sign. I want to see this work to move forward as its helping solve some of the Proxy Mobile IPv6 issues and so I've some vested interest in the success of this group. My suggestions taking a neutral stand. 1.) I see that the WG chairs have some strong opinions on technical approaches and strong disagreement between the chairs, that's not helping in the issue resolution. Chairs should be moderators and help in setting the discussion go in the right direction. Surely, the chairs are entitled for their opinions, but if they have to remove the Chair hat every other minute, or passionately argue about technical matters, why not take the chair hat and let some one else run the business ? 2.) I don't see any consensus calls on this issue. Let the WG decide the approach and have the consensus validated by the AD. If the chosen approach is not inline with the charter, let the AD state that and resend it back the group. But, deadlock at this stage needs to be resolved. 3.) There is a high risk of this WG getting killed, either lack of progress, or lack of interest. Either way, mainly due to the way the business is conducted. I hope we can avoid that. My humble 2c. No offense to any one person or to the chairs. I hope, we can go for consensus call to resolve this issue. Regards Sri On 12/8/09 8:52 AM, "Behcet Sarikaya" wrote: > > From asaeda@sfc.wide.ad.jp Wed Dec 9 02:23: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 9B9763A68FF for ; Wed, 9 Dec 2009 02:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.156 X-Spam-Level: *** X-Spam-Status: No, score=3.156 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 ZMzsfBh+-noq for ; Wed, 9 Dec 2009 02:23:31 -0800 (PST) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id D9A503A67B7 for ; Wed, 9 Dec 2009 02:23:30 -0800 (PST) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id C141F13D06C4; Wed, 9 Dec 2009 19:23:18 +0900 (JST) Date: Wed, 09 Dec 2009 19:23:18 +0900 (JST) Message-Id: <20091209.192318.243287675.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <746476.34430.qm@web111406.mail.gq1.yahoo.com> References: <746476.34430.qm@web111406.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] Consensus call for MLD Proxy 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, 09 Dec 2009 10:23:31 -0000 > =A0 We have had a lot of good discussion and heard arguments on vario= us aspects on this: > IGMP/MLD Proxy at the MAG should be the approach taken for the charte= r item: > = > Initial version of a document explaining the use of multicast in PMIP= v6 > = > = > Please respond if you SUPPORT or > = > DO NOT SUPPORT > = > it. My comment is MLD proxy at MAG is good and should become the base implementation which the current charter defines. But please don't simply discard other mechanism whose approach is within the current charter even after MLD proxy becomes our base line. Discussing various technical issues and knowing many pros. and cons. are not only beneficial but necessary for defining the next direction. Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Wed Dec 9 02:24: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 493203A67AB for ; Wed, 9 Dec 2009 02:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.784 X-Spam-Level: ** X-Spam-Status: No, score=2.784 tagged_above=-999 required=5 tests=[AWL=0.372, 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 jrI3pFhU8lvZ for ; Wed, 9 Dec 2009 02:24:47 -0800 (PST) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 836083A6778 for ; Wed, 9 Dec 2009 02:24:47 -0800 (PST) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 1D43713D06C4; Wed, 9 Dec 2009 19:24:36 +0900 (JST) Date: Wed, 09 Dec 2009 19:24:35 +0900 (JST) Message-Id: <20091209.192435.165518270.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <20091209.192318.243287675.asaeda@sfc.wide.ad.jp> References: <746476.34430.qm@web111406.mail.gq1.yahoo.com> <20091209.192318.243287675.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 Cc: multimob@ietf.org Subject: Re: [multimob] Consensus call for MLD Proxy 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, 09 Dec 2009 10:24:48 -0000 > > Please respond if you SUPPORT or > > > > DO NOT SUPPORT > > > > it. > > My comment is MLD proxy at MAG is good and should become the base > implementation which the current charter defines. Oops, so, yes, I support it. > But please don't simply discard other mechanism whose approach is > within the current charter even after MLD proxy becomes our base > line. Discussing various technical issues and knowing many > pros. and cons. are not only beneficial but necessary for defining the > next direction. > > Regards, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From Dirk.von-Hugo@telekom.de Wed Dec 9 03:00:42 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 24D1C3A67A6 for ; Wed, 9 Dec 2009 03:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[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 qk4eTTp91Bpc for ; Wed, 9 Dec 2009 03:00:41 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id B75AB3A6781 for ; Wed, 9 Dec 2009 03:00:39 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 09 Dec 2009 12:00:24 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 12:00:24 +0100 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: Wed, 9 Dec 2009 12:00:22 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC802784801A3D9B9@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <746476.34430.qm@web111406.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Consensus call for MLD Proxy Thread-Index: Acp4MPYKWL+ThlX9STyNEMBT6nwpZAAjUxlA References: <746476.34430.qm@web111406.mail.gq1.yahoo.com> From: To: , X-OriginalArrivalTime: 09 Dec 2009 11:00:24.0487 (UTC) FILETIME=[CEF6A370:01CA78BE] Subject: Re: [multimob] Consensus call for MLD Proxy 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, 09 Dec 2009 11:00:42 -0000 Dear all, I also SUPPORT to go for MLD proxy as basic solution without extension. = Next step would be to merge the different proposals proposing this = approach, right? And - perhaps in parallel - to collect issues from = other drafts for future optimization-extension work ... Best regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Behcet Sarikaya Gesendet: Dienstag, 8. Dezember 2009 19:05 An: multimob@ietf.org Betreff: [multimob] Consensus call for MLD Proxy Hello all, =A0=20 =A0 We have had a lot of good discussion and heard arguments on various = aspects on this: IGMP/MLD Proxy at the MAG should be the approach taken for the charter = item: Initial version of a document explaining the use of multicast in PMIPv6 Please respond if you SUPPORT or DO NOT SUPPORT it. Chairs. =20 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From I.Romdhani@napier.ac.uk Wed Dec 9 03:48: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 47F7428C0F8 for ; Wed, 9 Dec 2009 03:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 NSISdJTjAikg for ; Wed, 9 Dec 2009 03:48:13 -0800 (PST) Received: from VA3EHSOBE006.bigfish.com (va3ehsobe005.messaging.microsoft.com [216.32.180.15]) by core3.amsl.com (Postfix) with ESMTP id E84FC28C133 for ; Wed, 9 Dec 2009 03:48:12 -0800 (PST) Received: from mail22-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 8.1.240.5; Wed, 9 Dec 2009 11:48:01 +0000 Received: from mail22-va3 (localhost.localdomain [127.0.0.1]) by mail22-va3-R.bigfish.com (Postfix) with ESMTP id CDDDC560301; Wed, 9 Dec 2009 11:48:00 +0000 (UTC) X-SpamScore: -62 X-BigFish: VPS-62(zz1be0L13feK542N1417J9370J14ffOaf6Oa2dbP62a3Lzz1202hz4fhz1033ILz2ei6bh61h) X-Spam-TCS-SCL: 0:0 Received: from mail22-va3 (localhost.localdomain [127.0.0.1]) by mail22-va3 (MessageSwitch) id 1260359276684686_25529; Wed, 9 Dec 2009 11:47:56 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.249]) by mail22-va3.bigfish.com (Postfix) with ESMTP id 9E2781A100A7; Wed, 9 Dec 2009 11:47:55 +0000 (UTC) Received: from EVS1.napier-mail.napier.ac.uk (146.176.222.5) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server id 14.0.482.32; Wed, 9 Dec 2009 11:47:55 +0000 Received: from mer-hub-1.napier-mail.napier.ac.uk ([146.176.222.88]) by EVS1.napier-mail.napier.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 11:47:53 +0000 Received: from E2K7MBX.napier-mail.napier.ac.uk ([146.176.250.56]) by mer-hub-1.napier-mail.napier.ac.uk ([146.176.222.88]) with mapi; Wed, 9 Dec 2009 11:47:54 +0000 From: "Romdhani, Imed" To: Behcet Sarikaya , "multimob@ietf.org" Date: Wed, 9 Dec 2009 11:47:52 +0000 Thread-Topic: [multimob] Consensus call for MLD Proxy Thread-Index: Acp4MPeZ6UCkhCXoQ1qMCZOLPrGLqAAkaWnQ Message-ID: <78F1C759D89E1C44A6DD4C06B9A4B270BA6E92B8EC@E2K7MBX.napier-mail.napier.ac.uk> References: <746476.34430.qm@web111406.mail.gq1.yahoo.com> In-Reply-To: <746476.34430.qm@web111406.mail.gq1.yahoo.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Dec 2009 11:47:53.0670 (UTC) FILETIME=[71357660:01CA78C5] X-Reverse-DNS: mer-w2003-2.napier.ac.uk Subject: Re: [multimob] Consensus call for MLD Proxy 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, 09 Dec 2009 11:48:14 -0000 Dear all, I do SUPPORT the use of MLD Proxy at the MAG and I would prefer to introduc= e new intelligent mechanisms on the MAG to: - Aggregate MDL Membership Reports for MNs = - Tune MLD Membership Query messages to adapt to different wireless connect= ion characteristics with MNs (save battery, avoid unnecessary query message= s, etc.) - Select next-hop multicast on-tree router based on multicast group profile= and not only on mobility association with the Mobility Anchor Point = - and consider load-balancing issues and fast handover support if more than= one MAP can be selected at a time for a multicast group or channel. Kind regards, Imed --------------------------------------------------- Imed Romdhani, PhD IEEE Member, FHEA (UK) = Lecturer in Networking Room C 64 Edinburgh Napier University School of Computing 10 Colinton Road Edinburgh, EH10 5DT UK E-Mail: I.Romdhani@napier.ac.uk Home Page: http://www.dcs.napier.ac.uk/~cs244/ Telephone: +44(0)131 455 2726 Fax: +44(0)131 455 2727 --------------------------------------------------- -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behal= f Of Behcet Sarikaya Sent: 08 December 2009 18:05 To: multimob@ietf.org Subject: [multimob] Consensus call for MLD Proxy Hello all, =A0 = =A0 We have had a lot of good discussion and heard arguments on various asp= ects on this: IGMP/MLD Proxy at the MAG should be the approach taken for the charter item= : Initial version of a document explaining the use of multicast in PMIPv6 Please respond if you SUPPORT or DO NOT SUPPORT it. Chairs. = _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob On 25 February 2009, the University launched its new name, Edinburgh Napier= University. = For more information please visit our website. Edinburgh Napier University is one of the top 10 universities in the UK for= graduate employability (HESA 2009) This message is intended for the addressee(s) only and should not be read, = copied or disclosed to anyone else out-with the University without the perm= ission of the sender. It is your responsibility to ensure that this message and any attachments a= re scanned for viruses or other defects. Edinburgh Napier University does n= ot accept liability for any loss or damage which may result from this email= or any attachment, or for errors or omissions arising after it was sent. E= mail is not a secure medium. Email entering the University's system is subj= ect to routine monitoring and filtering by the University. Edinburgh Napier University is a registered Scottish charity. Registration = number SC018373 From sijeon79@gmail.com Wed Dec 9 04:25: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 58C1D3A6860 for ; Wed, 9 Dec 2009 04:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWBcD8Is22sQ for ; Wed, 9 Dec 2009 04:25:00 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 56DB93A67AF for ; Wed, 9 Dec 2009 04:25:00 -0800 (PST) Received: by pwi20 with SMTP id 20so2693492pwi.29 for ; Wed, 09 Dec 2009 04:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:reply-to:from:to:cc :references:subject:date:organization:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=T+QPXFev3bQaoEapk38tCtSYX7UqORITvQpvDLzGki4=; b=Lxmf7kjefDpjU39GZhNMz0/2JIUhNzACkdg11tbUSFCspQEP2ZFLmRFv/bKJA18NIh VrMwZelaMSlhuK1rucAbsMO60dk9I2X5/QKlDwQ4QCNtAEKeoDcBuwZKmSwvsJgk/aTL jqWUq62ee3RYOZV0+Sf2mS+slSbw8NvGx/H8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=reply-to:from:to:cc:references:subject:date:organization:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :in-reply-to:thread-index:x-mimeole; b=GegVnJZfAjbBV+p8KK/ehd/nMkf93oSnBRZVDv6Sk6A6VXxiKJfgyLLaLX3TUico1d xoub/V4d6GsWf6YAMuwAcQgADMqZcI2ktX9wrLxBc3bPtrdpfrkB7Lw98tQPzNEdtQtE NkHPKo0ZJdm9I2oshsXUxA1jaqo47IxAYA3Bc= Received: by 10.141.108.2 with SMTP id k2mr145269rvm.125.1260361486681; Wed, 09 Dec 2009 04:24:46 -0800 (PST) Received: from dcn0d4b06d5df0 ([220.149.84.225]) by mx.google.com with ESMTPS id 22sm6924046pzk.2.2009.12.09.04.24.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Dec 2009 04:24:45 -0800 (PST) From: "Seil Jeon" To: "'Behcet Sarikaya'" References: <746476.34430.qm@web111406.mail.gq1.yahoo.com> Date: Wed, 9 Dec 2009 21:24:39 +0900 Organization: dcn Message-ID: <001701ca78ca$965ec2c0$c27113ac@dcn0d4b06d5df0> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <746476.34430.qm@web111406.mail.gq1.yahoo.com> thread-index: Acp4MO6VL/qoL6zzQtqPnUsDZBu1tgAmCTfg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: multimob@ietf.org Subject: Re: [multimob] Consensus call for MLD Proxy X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sijeon79@gmail.com List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 12:25:01 -0000 Dear multimob, Absolutely, I SUPPORT to go for MLD proxy as basic solution without = extension. I think MLD proxy at MAG is appropriate approach to make base document = which the charter defines Regards, Seil Jeon -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On = Behalf Of Behcet Sarikaya Sent: Wednesday, December 09, 2009 3:05 AM To: multimob@ietf.org Subject: [multimob] Consensus call for MLD Proxy Hello all, =20 We have had a lot of good discussion and heard arguments on various = aspects on this: IGMP/MLD Proxy at the MAG should be the approach taken for the charter = item: Initial version of a document explaining the use of multicast in PMIPv6 Please respond if you SUPPORT or DO NOT SUPPORT it. Chairs. =20 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From suresh.krishnan@ericsson.com Wed Dec 9 09:58: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 A012B3A6A1C for ; Wed, 9 Dec 2009 09:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 zXDZI3FeVWS8 for ; Wed, 9 Dec 2009 09:58:07 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id DBA973A67E6 for ; Wed, 9 Dec 2009 09:58:06 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nB9HwDx8007498; Wed, 9 Dec 2009 11:58:15 -0600 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.1.375.2; Wed, 9 Dec 2009 12:57:49 -0500 Message-ID: <4B1FE4D3.4080601@ericsson.com> Date: Wed, 9 Dec 2009 12:56:35 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Behcet Sarikaya References: <746476.34430.qm@web111406.mail.gq1.yahoo.com> In-Reply-To: <746476.34430.qm@web111406.mail.gq1.yahoo.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "multimob@ietf.org" Subject: Re: [multimob] Consensus call for MLD Proxy 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, 09 Dec 2009 17:58:07 -0000 Hi Behcet/Stig, I believe that the "MLD Proxy at the MAG" solution is the simplest and best way forward and I SUPPORT this approach. Thanks Suresh (back online after 3 weeks offline) On 09-12-08 01:04 PM, Behcet Sarikaya wrote: > Hello all, > > We have had a lot of good discussion and heard arguments on various aspects on this: > IGMP/MLD Proxy at the MAG should be the approach taken for the charter item: > > Initial version of a document explaining the use of multicast in PMIPv6 > > > Please respond if you SUPPORT or > > DO NOT SUPPORT > > it. > > Chairs. > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From xiayangsong@huawei.com Wed Dec 9 12:41: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 BFC183A67AE for ; Wed, 9 Dec 2009 12:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 9OrQB+NikRB9 for ; Wed, 9 Dec 2009 12:41:31 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 07BD93A65A6 for ; Wed, 9 Dec 2009 12:41:31 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUE003D8K4VIL@usaga04-in.huawei.com> for multimob@ietf.org; Wed, 09 Dec 2009 14:41:20 -0600 (CST) Received: from X24512z ([10.124.12.64]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUE00JB1K4U8V@usaga04-in.huawei.com> for multimob@ietf.org; Wed, 09 Dec 2009 14:41:19 -0600 (CST) Date: Wed, 09 Dec 2009 14:41:17 -0600 From: Frank Xia To: Behcet Sarikaya , multimob@ietf.org Message-id: <004601ca790f$f5d81590$400c7c0a@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.3598 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: <746476.34430.qm@web111406.mail.gq1.yahoo.com> Subject: Re: [multimob] Consensus call for MLD Proxy 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, 09 Dec 2009 20:41:31 -0000 Hello Chairs I SUPPORT the IGMP/MLD proxy function that integrated into MAG. BR Frank ----- Original Message ----- From: "Behcet Sarikaya" To: Sent: Tuesday, December 08, 2009 12:04 PM Subject: [multimob] Consensus call for MLD Proxy Hello all, We have had a lot of good discussion and heard arguments on various aspects on this: IGMP/MLD Proxy at the MAG should be the approach taken for the charter item: Initial version of a document explaining the use of multicast in PMIPv6 Please respond if you SUPPORT or DO NOT SUPPORT it. Chairs. _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From JuanCarlos.Zuniga@InterDigital.com Wed Dec 9 12:58: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 3C1D63A6B0F for ; Wed, 9 Dec 2009 12:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puVUMYppw7+a for ; Wed, 9 Dec 2009 12:58:25 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 46A393A6B08 for ; Wed, 9 Dec 2009 12:58:25 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 15:58:13 -0500 Received: from SAM.InterDigital.com ([10.30.2.12]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 15:57:20 -0500 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: Wed, 9 Dec 2009 15:58:18 -0500 Message-ID: In-reply-to: <746476.34430.qm@web111406.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Consensus call for MLD Proxy Thread-Index: Acp4MO5PssAAJA1tQMWcm3EirY4HuQA4NDjA References: <746476.34430.qm@web111406.mail.gq1.yahoo.com> From: "Zuniga, Juan Carlos" To: "Behcet Sarikaya" , "Stig Venaas" , X-OriginalArrivalTime: 09 Dec 2009 20:57:20.0428 (UTC) FILETIME=[32ED86C0:01CA7912] Subject: Re: [multimob] Consensus call for MLD Proxy 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, 09 Dec 2009 20:58:26 -0000 Hello, =20 I agree that the MLD Proxy is a simple solution and therefore I SUPPORT = the MLD Proxy at the MAG for the basic approach. Furthermore, I also agree with many others in the list that we should = keep the momentum and quickly start working on solving the shortcomings = of such a simple approach. Regards, Juan Carlos -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On = Behalf Of Behcet Sarikaya Sent: Tuesday, 08 December, 2009 1:05 PM To: multimob@ietf.org Subject: [multimob] Consensus call for MLD Proxy Hello all, =A0=20 =A0 We have had a lot of good discussion and heard arguments on various = aspects on this: IGMP/MLD Proxy at the MAG should be the approach taken for the charter = item: Initial version of a document explaining the use of multicast in PMIPv6 Please respond if you SUPPORT or DO NOT SUPPORT it. Chairs. =20 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From waehlisch@ieee.org Wed Dec 9 13:22: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 E5F343A67B1 for ; Wed, 9 Dec 2009 13:22:40 -0800 (PST) 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 TLgBS1xU1OaX for ; Wed, 9 Dec 2009 13:22:39 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id B16FD3A677D for ; Wed, 9 Dec 2009 13:22:39 -0800 (PST) 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 1NITzP-000FKd-E6; Wed, 09 Dec 2009 22:22:27 +0100 Date: Wed, 9 Dec 2009 22:22:25 +0100 From: Matthias Waehlisch To: Behcet Sarikaya In-Reply-To: <746476.34430.qm@web111406.mail.gq1.yahoo.com> Message-ID: References: <746476.34430.qm@web111406.mail.gq1.yahoo.com> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1288428953-23061-1260393704=:960" Content-ID: X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] Consensus call for MLD Proxy 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, 09 Dec 2009 21:22:41 -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. --1288428953-23061-1260393704=:960 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: I SUPPORT IGMP/MLD Proxy at the MAG ... Cheers matthias --=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 On Tue, 8 Dec 2009, Behcet Sarikaya wrote: > Hello all, =A0 =A0 We have had a lot of good discussion and heard argumen= ts=20 > on various aspects on this: IGMP/MLD Proxy at the MAG should be the=20 > approach taken for the charter item: >=20 > Initial version of a document explaining the use of multicast in PMIPv6 >=20 >=20 > Please respond if you SUPPORT or >=20 > DO NOT SUPPORT >=20 > it. >=20 > Chairs. >=20 >=20 > =20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob >=20 --1288428953-23061-1260393704=:960-- From schmidt@informatik.haw-hamburg.de Wed Dec 9 13:23: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 2B28D3A67B1 for ; Wed, 9 Dec 2009 13:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.099, 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 tA8LjoilpeCd for ; Wed, 9 Dec 2009 13:23:11 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id AB52428C1CE for ; Wed, 9 Dec 2009 13:23:10 -0800 (PST) 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 1NITzu-000FSU-DX; Wed, 09 Dec 2009 22:22:58 +0100 Message-ID: <4B20152F.8080107@informatik.haw-hamburg.de> Date: Wed, 09 Dec 2009 22:22:55 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behcet Sarikaya References: <746476.34430.qm@web111406.mail.gq1.yahoo.com> In-Reply-To: <746476.34430.qm@web111406.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] Consensus call for MLD Proxy 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, 09 Dec 2009 21:23:12 -0000 Hi all, this is also a vote in SUPPORT of the MLD/IGMP proxy solution at the MAG. Thomas Behcet Sarikaya wrote: > Hello all, > > We have had a lot of good discussion and heard arguments on various aspects on this: > IGMP/MLD Proxy at the MAG should be the approach taken for the charter item: > > Initial version of a document explaining the use of multicast in PMIPv6 > > > Please respond if you SUPPORT or > > DO NOT SUPPORT > > it. > > Chairs. > > > > _______________________________________________ > 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 Guang.Lu@InterDigital.com Wed Dec 9 13:28: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 D16A528C1CE for ; Wed, 9 Dec 2009 13:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 UBt6Pt3nWkYk for ; Wed, 9 Dec 2009 13:28:31 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id C1AB828C1AB for ; Wed, 9 Dec 2009 13:28:31 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 16:28:20 -0500 Received: from SAM.InterDigital.com ([10.30.2.12]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 16:27:47 -0500 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: Wed, 9 Dec 2009 16:27:48 -0500 Message-ID: In-reply-to: <4B20152F.8080107@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Consensus call for MLD Proxy Thread-Index: Acp5FcxtyHCkkkpmQce04KXIxjxMpgAAIdmg References: <746476.34430.qm@web111406.mail.gq1.yahoo.com> <4B20152F.8080107@informatik.haw-hamburg.de> From: "Lu, Guang" To: X-OriginalArrivalTime: 09 Dec 2009 21:27:47.0799 (UTC) FILETIME=[74203670:01CA7916] Subject: Re: [multimob] Consensus call for MLD Proxy 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, 09 Dec 2009 21:28:32 -0000 I also SUPPORT IGMP/MLD proxy solution at MAG as the approach within the = current charter.=20 Best regards, Guang > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Thomas C. Schmidt > Sent: Wednesday, December 09, 2009 4:23 PM > To: Behcet Sarikaya > Cc: multimob@ietf.org > Subject: Re: [multimob] Consensus call for MLD Proxy >=20 > Hi all, >=20 > this is also a vote in SUPPORT of the MLD/IGMP proxy solution at the > MAG. >=20 > Thomas >=20 > Behcet Sarikaya wrote: > > Hello all, > > > > We have had a lot of good discussion and heard arguments on = various > aspects on this: > > IGMP/MLD Proxy at the MAG should be the approach taken for the > charter item: > > > > Initial version of a document explaining the use of multicast in > PMIPv6 > > > > > > Please respond if you SUPPORT or > > > > DO NOT SUPPORT > > > > it. > > > > Chairs. > > > > > > > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob >=20 > -- >=20 > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner = Tor > 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, > Germany =B0 > =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875- > 8452 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875- > 8409 =B0 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From luisc@it.uc3m.es Wed Dec 9 14:27:42 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 BD0C83A6A80 for ; Wed, 9 Dec 2009 14:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 iAB672XZbw0j for ; Wed, 9 Dec 2009 14:27:41 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id B50EE3A6A85 for ; Wed, 9 Dec 2009 14:27:41 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp03.uc3m.es (Postfix) with ESMTP id 14BFB72DC58; Wed, 9 Dec 2009 23:27:27 +0100 (CET) Received: from 29.pool85-49-213.dynamic.orange.es (29.pool85-49-213.dynamic.orange.es [85.49.213.29]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Wed, 09 Dec 2009 23:27:24 +0100 Message-ID: <20091209232724.cbyv4lc8cgw4gkcw@webcartero01.uc3m.es> Date: Wed, 09 Dec 2009 23:27:24 +0100 From: "Luis M. Contreras" To: "Thomas C. Schmidt" References: <4B165C18.7060509@piuha.net> <20091203.155431.189432716.asaeda@sfc.wide.ad.jp> <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> <20091205.151420.60711179.asaeda@sfc.wide.ad.jp> <20091205124522.4q9osw00w0s8wck8@webcartero01.uc3m.es> <4B1A612F.9050005@informatik.haw-hamburg.de> In-Reply-To: <4B1A612F.9050005@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: isoto@it.uc3m.es, multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 09 Dec 2009 22:27:42 -0000 Hi Thomas, "Thomas C. Schmidt" dijo: > > You do point at the proposal redirecting via the LMA? > Mhmm, then are you sure about this? We discussed the temporal > handover behavior prior to IETF 76 online, and if I remember > correctly, timing was exactly the same as for the "full" handover ?? > Yes, I refer to the redirection of the multicast flow via the LMA (called pMAG-assisted HO in our draft). We discussed in the past about this. Nevertheless I miss some delay contributions to be taken into account in the "full" handover or subscription re-signalling case. For instance, a complete PBA/PBU sequence is needed before the MAG could send any MLD message, because the MAG gets the link-local address on the point-to-point link with the MN just after the PBU (as per bullet 15, section 6.9.1.3 of RFC 5213). Additionally, MAG should wait at least for the complete MLD Query / MLD Report sequence before to start the delivery of the content to the MN. I think the subscription re-signalling involves more signalling messages than the redirection case. In any case, I know it would be needed a deeper analysis and system characterization to confirm if the redirection method is actually faster (and to which extend) that the subscription re-signalling under all circunstances. Regards, Luis From luisc@it.uc3m.es Wed Dec 9 14:35: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 A49713A682F for ; Wed, 9 Dec 2009 14:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 CVUMP2gNyzjm for ; Wed, 9 Dec 2009 14:35:21 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 978303A67EF for ; Wed, 9 Dec 2009 14:35:21 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 7E7096C2E6D; Wed, 9 Dec 2009 23:35:07 +0100 (CET) Received: from 29.pool85-49-213.dynamic.orange.es (29.pool85-49-213.dynamic.orange.es [85.49.213.29]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Wed, 09 Dec 2009 23:35:04 +0100 Message-ID: <20091209233504.8mwgk21r28c440so@webcartero01.uc3m.es> Date: Wed, 09 Dec 2009 23:35:04 +0100 From: "Luis M. Contreras" To: Hitoshi Asaeda References: <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> <20091205.151420.60711179.asaeda@sfc.wide.ad.jp> <20091205124522.4q9osw00w0s8wck8@webcartero01.uc3m.es> <20091207.165058.223254814.asaeda@sfc.wide.ad.jp> In-Reply-To: <20091207.165058.223254814.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17060.002 Cc: isoto@it.uc3m.es, multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 09 Dec 2009 22:35:22 -0000 Hi Hitoshi, > > I took a glance at section 7 in your draft. > I'm sorry, but I cannot imagine that your idea mentioned in this > section does not require any protocol modification. Or it seems to me > that some original implementation is required. No? > Is it obvious that every function you propose is implemented by an > ordinal PMIP implementation (i.e. only with standard spec)? > > For instance, regarding pMAG-assisted handover, you say; "the pMAG can > be able to temporally forward via the LMA a copy of the multicast > content within an unicast flow towards the new location of the MN, > brahbrah", but is this a common behavior of rfc5213 compliant MAG? > I see this as an additional functionality added to MAG elements to support multicast service, as could be the case for the proposal of using context transfer methods to transfer multicast status to nMAG, or the case of implementing more than one MLD instance in a MAG. All of them are new functionalities proposed in the framework of multicast support in PMIP without extending basic protocol defined in RFC5213. Regards, Luis From luisc@it.uc3m.es Wed Dec 9 14:46: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 011F93A69A6 for ; Wed, 9 Dec 2009 14:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 5eJVTY9hv6V1 for ; Wed, 9 Dec 2009 14:46:23 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id F0E363A697F for ; Wed, 9 Dec 2009 14:46:22 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 42AA86C3212; Wed, 9 Dec 2009 23:46:05 +0100 (CET) Received: from 29.pool85-49-213.dynamic.orange.es (29.pool85-49-213.dynamic.orange.es [85.49.213.29]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Wed, 09 Dec 2009 23:46:02 +0100 Message-ID: <20091209234602.h15mfvo48w048sc0@webcartero01.uc3m.es> Date: Wed, 09 Dec 2009 23:46:02 +0100 From: "Luis M. Contreras" To: Behcet Sarikaya , Behcet Sarikaya References: <555186.69483.qm@web111406.mail.gq1.yahoo.com> <4B0AE50D.4020905@venaas.com> <4B165C18.7060509@piuha.net> <20091203.155431.189432716.asaeda@sfc.wide.ad.jp> <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> <553771.9779.qm@web111409.mail.gq1.yahoo.com> In-Reply-To: <553771.9779.qm@web111409.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17060.002 Cc: isoto@it.uc3m.es, multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 09 Dec 2009 22:46:24 -0000 Hi Behcet, Behcet Sarikaya dijo: >> > 2. Basic design of MLD proxy requires configuring a single upstream >> >=A0 interface, and hence some extension to support that MAG connects >> >=A0 multiple LMAs would be necessary. >> >> I think we can separate here MLD-proxy upstream configuration from MAG-L= MA >> binding. The MLD proxy instance ignores any mobility process. As far >> as the MAG >> has some interface active, the MLD proxy instance could configure >> that interface >> as upstream interface for the proxy function. From the MLD instance poin= t of >> view it is not relevant if there is an LMA function at the other end of = the >> upstream interface. The MLD instance needs at the other end a >> multicast router >> or another MLD proxy device. If the equipment at the other end of >> the upstream >> interface implements additional functions (such LMA one) is not >> relevant from >> the MLD proxy function point of view. > > Aren't we talking about extending RFC 4605 here? These are good ideas > that we should probably pursue but for extending what RFC 4605 > defined? > I don't think so. Separating MLD-proxy upstream configuration from MAG-LMA binding ensures that RFC 4605 is not altered. >> >> > 3. No local routing supported only with MLD proxy. If local routing >> >=A0 should be supported, dual-mode implementation (MLD proxy and PIM on >> >=A0 MAG or LMA) should be also discussed. >> >> It is not clear to me what could be the behaviour of a mixed >> MLD-proxy/PIM-multicast router. For instance, if some multicast group is >> reacheable through the LMA, which is the way of requesting the >> content? An MLD >> query or a PIM join? Both of them could make use of the same tunnel >> between MAG >> and LMA ... >> I think that considering a pure MLD-proxy or a pure multicast router >> behaviour >> is more realistic. IMO, both could be considered at this stage (in my >> understanding, since the MN subscribes the content through the MAG >> either acting >> as MLD proxy or multicast router, both roles are compliant with the remo= te >> subscription condition) >> > > > Local routing is not yet defined in Netext. Even if it was defined, I > don't see how it would affect our work as we are restricted with > receiver mobility in the charter? > > The MAG could play the role of multicast router (no proxy function) in a receiver mobility scenario also. This is not in the framework of the charter nowadays, but it could be possible in the future. Regards, Luis From luisc@it.uc3m.es Wed Dec 9 14:55: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 B239A3A6831 for ; Wed, 9 Dec 2009 14:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 InhCzbWhCXqz for ; Wed, 9 Dec 2009 14:55:09 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id C7A983A67C1 for ; Wed, 9 Dec 2009 14:55:08 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 1C694BA7C35; Wed, 9 Dec 2009 23:54:56 +0100 (CET) Received: from 29.pool85-49-213.dynamic.orange.es (29.pool85-49-213.dynamic.orange.es [85.49.213.29]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Wed, 09 Dec 2009 23:54:53 +0100 Message-ID: <20091209235453.ixrfwqsc4kw8ock0@webcartero01.uc3m.es> Date: Wed, 09 Dec 2009 23:54:53 +0100 From: "Luis M. Contreras" To: Behcet Sarikaya , Behcet Sarikaya References: <746476.34430.qm@web111406.mail.gq1.yahoo.com> In-Reply-To: <746476.34430.qm@web111406.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: isoto@it.uc3m.es, multimob@ietf.org Subject: Re: [multimob] Consensus call for MLD Proxy 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, 09 Dec 2009 22:55:09 -0000 I think it is usefull to concentrate in one scenario, so I also SUPPORT the IGMP/MLD Proxy function at the MAG scenario. Note that this case by itself opens some other interesting debates as the following ones: one MLD proxy instance per MAG vs several ones; upstream interface configuration restricted to point to an LMA or open to point whatever router in the network, etc. Best regards, Luis Behcet Sarikaya dijo: > Hello all, > =A0 > =A0 We have had a lot of good discussion and heard arguments on various > aspects on this: > IGMP/MLD Proxy at the MAG should be the approach taken for the charter it= em: > > Initial version of a document explaining the use of multicast in PMIPv6 > > > Please respond if you SUPPORT or > > DO NOT SUPPORT > > it. > > Chairs. > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From jean@iijlab.net Wed Dec 9 20:57: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 8C5513A67E7 for ; Wed, 9 Dec 2009 20:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 q1iqcv3Q+Jqw for ; Wed, 9 Dec 2009 20:57:53 -0800 (PST) Received: from omgo.iij.ad.jp (mo30.iij.ad.jp [202.232.30.71]) by core3.amsl.com (Postfix) with ESMTP id 6D9A53A6359 for ; Wed, 9 Dec 2009 20:57:53 -0800 (PST) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iijlab.net;h=Message-ID: Date:From:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding;i=jean@iijlab.net;s=omgo1;t=1260421053;x= 1261630653; bh=Gq2TA1L/DHSFiPsfFXuKrHBiB5P+sQ/CDLAV0skwzvA=; b=PSb7sKO1yQpxT9kk ag2DinK3eRb5LEh4rmjKmzfZ60Ryl0jqQjcotRBUApxVXKADGgE2YR+xE1dbEUsKn97PSoaE+ADIB rhFB+AdG64NaQPXvZoPdp3kMiP6wt0wo0P8ggWuO5DmCMHol72Wd8cUWqXyj0ua0S9nKVDI8AGukQ Y=; Received: by omgo.iij.ad.jp (mo30) id nBA4vX3u031972; Thu, 10 Dec 2009 13:57:33 +0900 Message-ID: <4B207F9F.4060001@iijlab.net> Date: Thu, 10 Dec 2009 13:57:03 +0900 From: Jean Lorchat User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Behcet Sarikaya References: <746476.34430.qm@web111406.mail.gq1.yahoo.com> In-Reply-To: <746476.34430.qm@web111406.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] Consensus call for MLD Proxy 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, 10 Dec 2009 04:57:54 -0000 Hello, I also SUPPORT this, hoping that we can proceed afterwards to more elaborate solutions Cheers, -------------- Jean Lorchat Internet Initiative Japan WIDE Project Behcet Sarikaya wrote: > Hello all, > > We have had a lot of good discussion and heard arguments on various aspects on this: > IGMP/MLD Proxy at the MAG should be the approach taken for the charter item: > > Initial version of a document explaining the use of multicast in PMIPv6 > > > Please respond if you SUPPORT or > > DO NOT SUPPORT > > it. > > Chairs. > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From pierrick.seite@orange-ftgroup.com Thu Dec 10 01:54: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 14A423A68D3 for ; Thu, 10 Dec 2009 01:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=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 xjWf6+jYQoaY for ; Thu, 10 Dec 2009 01:54:35 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id EB73E3A6A88 for ; Thu, 10 Dec 2009 01:54:33 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 10:54:10 +0100 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: Thu, 10 Dec 2009 10:54:09 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46285CB38@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <746476.34430.qm@web111406.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Consensus call for MLD Proxy Thread-Index: Acp4MOz6xyoYD9pISx6xiNolimVyewBS6z3g References: <746476.34430.qm@web111406.mail.gq1.yahoo.com> From: To: , X-OriginalArrivalTime: 10 Dec 2009 09:54:10.0523 (UTC) FILETIME=[B8B59AB0:01CA797E] Subject: Re: [multimob] Consensus call for MLD Proxy 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, 10 Dec 2009 09:54:36 -0000 Hi Behcet, I support MLD/IGMP proxy at the MAG, this is a pragmatic approach and = the simplest way to solve the issue. However, I think this solution should not preclude further work on = optimisation. Regards, Pierrick > -----Message d'origine----- > De=A0: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] De = la > part de Behcet Sarikaya > Envoy=E9=A0: mardi 8 d=E9cembre 2009 19:05 > =C0=A0: multimob@ietf.org > Objet=A0: [multimob] Consensus call for MLD Proxy >=20 > Hello all, >=20 > =A0 We have had a lot of good discussion and heard arguments on = various > aspects on this: > IGMP/MLD Proxy at the MAG should be the approach taken for the charter > item: >=20 > Initial version of a document explaining the use of multicast in = PMIPv6 >=20 >=20 > Please respond if you SUPPORT or >=20 > DO NOT SUPPORT >=20 > it. >=20 > Chairs. >=20 >=20 >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From christophe.janneteau@cea.fr Thu Dec 10 02:02: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 154293A690D for ; Thu, 10 Dec 2009 02:02:50 -0800 (PST) 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_FR=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 lQeL6nwA9zeB for ; Thu, 10 Dec 2009 02:02:49 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 03AEA3A6886 for ; Thu, 10 Dec 2009 02:02:48 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nBAA2ak9016134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 10 Dec 2009 11:02:36 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nBAA2ZOi017097 for ; Thu, 10 Dec 2009 11:02:35 +0100 (envelope-from christophe.janneteau@cea.fr) Received: from mansart.intra.cea.fr (mansart.intra.cea.fr [132.166.88.54]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nBAA2WIW031336 for ; Thu, 10 Dec 2009 11:02:35 +0100 Received: from LODERI.intra.cea.fr ([132.166.64.44]) by mansart.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 11:02:18 +0100 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: Thu, 10 Dec 2009 11:02:16 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Consensus call for MLD Proxy Thread-Index: Acp5FcxtyHCkkkpmQce04KXIxjxMpgAAIdmgABnzpjA= References: <746476.34430.qm@web111406.mail.gq1.yahoo.com><4B20152F.8080107@informatik.haw-hamburg.de> From: "JANNETEAU Christophe" To: X-OriginalArrivalTime: 10 Dec 2009 10:02:18.0309 (UTC) FILETIME=[DB73D750:01CA797F] Subject: Re: [multimob] Consensus call for MLD Proxy 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, 10 Dec 2009 10:02:50 -0000 Hi all, I also SUPPORT the IGMP/MLD proxy solution at MAG. Christophe -----Message d'origine----- De=A0: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] De = la part de Lu, Guang Envoy=E9=A0: mercredi 9 d=E9cembre 2009 22:28 =C0=A0: multimob@ietf.org Objet=A0: Re: [multimob] Consensus call for MLD Proxy I also SUPPORT IGMP/MLD proxy solution at MAG as the approach within the = current charter.=20 Best regards, Guang > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Thomas C. Schmidt > Sent: Wednesday, December 09, 2009 4:23 PM > To: Behcet Sarikaya > Cc: multimob@ietf.org > Subject: Re: [multimob] Consensus call for MLD Proxy >=20 > Hi all, >=20 > this is also a vote in SUPPORT of the MLD/IGMP proxy solution at the > MAG. >=20 > Thomas >=20 > Behcet Sarikaya wrote: > > Hello all, > > > > We have had a lot of good discussion and heard arguments on = various > aspects on this: > > IGMP/MLD Proxy at the MAG should be the approach taken for the > charter item: > > > > Initial version of a document explaining the use of multicast in > PMIPv6 > > > > > > Please respond if you SUPPORT or > > > > DO NOT SUPPORT > > > > it. > > > > Chairs. > > > > > > > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob >=20 > -- >=20 > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner = Tor > 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, > Germany =B0 > =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875- > 8452 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875- > 8409 =B0 > _______________________________________________ > 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 Thu Dec 10 08:03: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 1927F3A6A50 for ; Thu, 10 Dec 2009 08:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_50=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 GyVB3X8leL+8 for ; Thu, 10 Dec 2009 08:03:57 -0800 (PST) Received: from web111405.mail.gq1.yahoo.com (web111405.mail.gq1.yahoo.com [67.195.15.156]) by core3.amsl.com (Postfix) with SMTP id 5D6503A6A09 for ; Thu, 10 Dec 2009 08:03:57 -0800 (PST) Received: (qmail 64788 invoked by uid 60001); 10 Dec 2009 16:03:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1260461026; bh=+uZ60vBZM9Bv6hrvmwYUbBzcpsNWd0EsQlfX4YuGZH0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lj/YwEAm7uRcsbjvIXXyJs2Ogp1SxVjhJee+ux7uL2cHuR7nC3Bk1l3kPjqEhRisLgXbapYXVXDqf79gfZWFEjlJPsKvOyzlRTPToxY3pPOdi/TGvxDzWLNMI6kdljMHtvTCTFwE3vpO0vBFSbDvrCVbJJY1byzgv6lcXj1qX9Q= 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=Oec038U4IIN00q1xnkWLU6MB2y9CzMuMpaqU9vVOIkKYUhXnWD4rAc9PNFdOOSS0COuYfob+hjPDr7yUaXRv02oHQWL22BkzIthrWm8Uro6kXxThHA5vgt0LPJqapkfvtj472gIC9MAQ60IouCHpxgdxA0xgDaJd+1K85PKiseQ=; Message-ID: <323854.63535.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: c3pFD_QVM1nCqpumk1boZ2JqRnO.Uw8GwhrFBWc._pd9Uu3tJw6mxp45d8eHos8qpwrGn9beORvtv1FqD2wr8VtgivDmiNBwTyztLPtcSypC2z1Pnu.nttul3KGIBg_l7AvG6Yq8KwoTe63IFQkbH_80gRU_j.ldOZgfX_p5sqdprluJic5SJTB.5OFi2kwBqOn_.tExdZdLaMlmYlHn3Oqak9lWUySFsFBYGSTFjYiIlyd_gdYJZWh5hzFcaG_AZWKOZpxrV_agX2QTV10A_BBfhIDutjZtK8bI.srJ7k0Dqo433H.yW5hxEU91l0DbHc2UajnSDvy98RmHm_CufajDcL2KV3a76Ro8sff2BDiAwwY3LbjeXTuHIQ5wRdILIZZWErqh8CsinsJMUD.YF3fqQrARvuo0ir01KxxbWUQpOaKphHur6_wpk.mZWQXkeIQBBP_FoTlysPJWif_D2gPNWVLZdkbyyIirxm3OKLGeBOoqa2m80PAi Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Thu, 10 Dec 2009 08:03:45 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 Date: Thu, 10 Dec 2009 08:03:45 -0800 (PST) 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] Adoption of draft-schmidt-multimob-pmipv6-mcast-deployment as a WG document 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, 10 Dec 2009 16:03:58 -0000 Hello all,=0A=A0 Consensus=A0on IGMP/MLD Proxy at MAG has been confirmed. B= ased on=A0 evaluation of the four solution drafts, draft-schmidt-multimob-p= mipv6-mcast-deployment comes closest to the charter item:=0A=0AInitial vers= ion of a document explaining the use of multicast in=A0PMIPv6. =0A=0AThe la= test version of this document can be found at:=0Ahttp://tools.ietf.org/id/d= raft-schmidt-multimob-pmipv6-mcast-deployment-02.txt=0A=0AThis mail starts = a WG adoption call on this draft.=0A=0AThe intended status for this documen= t is BCP.=0AIf adopted, the draft will be named:=0A=0Adraft-ietf-multimob-p= mipv6-base-solution.=0A=0APlease respond if you=A0are for ADOPTING=A0or=0A= =0Ayou are NOT for ADOPTING it by December 18, 2009.=0A=0A=0AChairs=0A=0A= =0A From cjbc@it.uc3m.es Thu Dec 10 08:15:08 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 3AC713A69F9 for ; Thu, 10 Dec 2009 08:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.709 X-Spam-Level: X-Spam-Status: No, score=-4.709 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 1M2teEkkWY8S for ; Thu, 10 Dec 2009 08:15:06 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 0AD753A6882 for ; Thu, 10 Dec 2009 08:15:06 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id B2181BA61AC; Thu, 10 Dec 2009 17:14:53 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Behcet Sarikaya In-Reply-To: <323854.63535.qm@web111405.mail.gq1.yahoo.com> References: <323854.63535.qm@web111405.mail.gq1.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-z5Th0C+ubTchjHXjZbK6" Organization: Universidad Carlos III de Madrid Date: Thu, 10 Dec 2009 17:14:59 +0100 Message-Id: <1260461699.3439.175.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: multimob@ietf.org Subject: Re: [multimob] Adoption of draft-schmidt-multimob-pmipv6-mcast-deployment as a WG document X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 16:15:08 -0000 --=-z5Th0C+ubTchjHXjZbK6 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Behcet, I do NOT support the ADOPTION of this document. We have just confirmed consensus on an approach and this is translated in adopting a particular document? AFAIK, there are several documents following the same IGMP/MLD approach and we haven't had much discussion on the pros and cons of each of them. IMHO, it is early to make such an adoption call and I strongly disagree with it. Thanks, Carlos On Thu, 2009-12-10 at 08:03 -0800, Behcet Sarikaya wrote: > Hello all, > Consensus on IGMP/MLD Proxy at MAG has been confirmed. Based on evalua= tion of the four solution drafts, draft-schmidt-multimob-pmipv6-mcast-deplo= yment comes closest to the charter item: >=20 > Initial version of a document explaining the use of multicast in PMIPv6.=20 >=20 > The latest version of this document can be found at: > http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-mcast-deployment-0= 2.txt >=20 > This mail starts a WG adoption call on this draft. >=20 > The intended status for this document is BCP. > If adopted, the draft will be named: >=20 > draft-ietf-multimob-pmipv6-base-solution. >=20 > Please respond if you are for ADOPTING or >=20 > you are NOT for ADOPTING it by December 18, 2009. >=20 >=20 > Chairs >=20 >=20 > =20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-z5Th0C+ubTchjHXjZbK6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkshHoMACgkQNdy6TdFwT2fmzgCeOCnLxlzzSQEbJ8ZcM81N6Tyv 2IUAmQEAA5b+mjwbbuzqzu03Haw+OOKi =sK29 -----END PGP SIGNATURE----- --=-z5Th0C+ubTchjHXjZbK6-- From JuanCarlos.Zuniga@InterDigital.com Thu Dec 10 11:01: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 161B83A6A2D for ; Thu, 10 Dec 2009 11:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEKfwO2b2UDK for ; Thu, 10 Dec 2009 11:01:31 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id E82413A6A1C for ; Thu, 10 Dec 2009 11:01:30 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 14:01:19 -0500 Received: from SAM.InterDigital.com ([10.30.2.12]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 14:01:15 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Dec 2009 14:02:10 -0500 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <323854.63535.qm@web111405.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Adoption ofdraft-schmidt-multimob-pmipv6-mcast-deployment as a WG document Thread-Index: Acp5sl+zhc29lIrFRw+7qqLkU3BLfAAFsXPg References: <323854.63535.qm@web111405.mail.gq1.yahoo.com> From: "Zuniga, Juan Carlos" To: "Behcet Sarikaya" , X-OriginalArrivalTime: 10 Dec 2009 19:01:15.0229 (UTC) FILETIME=[25C240D0:01CA79CB] Subject: Re: [multimob] Adoption ofdraft-schmidt-multimob-pmipv6-mcast-deployment as a WG document 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, 10 Dec 2009 19:01:35 -0000 Behcet, I see that the evaluation slides have finally been posted as I requested = at the meeting, and I appreciate that. However, they were never = presented and I believe that some discussion on this evaluation slides = is required before jumping to a conclusion and adopting a draft. We have agreed that the MLD Proxy be at the MAG. Nonetheless, there are = still open issues. For instance, we have not discussed about the role of = the LMA and this could imply different solutions depending on whether we = want to first solve the avalanche or the tunnel convergence problem. I = believe that some discussion is still needed. Therefore, at this point I DO NOT SUPPORT ADOPTING = draft-schmidt-multimob-pmipv6-mcast-deployment as a WG draft. Regards, Juan Carlos -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On = Behalf Of Behcet Sarikaya Sent: Thursday, 10 December, 2009 11:04 AM To: multimob@ietf.org Subject: [multimob] Adoption = ofdraft-schmidt-multimob-pmipv6-mcast-deployment as a WG document Hello all, =A0 Consensus=A0on IGMP/MLD Proxy at MAG has been confirmed. Based on=A0 = evaluation of the four solution drafts, = draft-schmidt-multimob-pmipv6-mcast-deployment comes closest to the = charter item: Initial version of a document explaining the use of multicast = in=A0PMIPv6.=20 The latest version of this document can be found at: http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-mcast-deployment-0= 2.txt This mail starts a WG adoption call on this draft. The intended status for this document is BCP. If adopted, the draft will be named: draft-ietf-multimob-pmipv6-base-solution. Please respond if you=A0are for ADOPTING=A0or you are NOT for ADOPTING it by December 18, 2009. Chairs =20 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From schmidt@informatik.haw-hamburg.de Thu Dec 10 15:02: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 E216F3A685E for ; Thu, 10 Dec 2009 15:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 H3Z7W7wNYpus for ; Thu, 10 Dec 2009 15:02:17 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 94B003A67D6 for ; Thu, 10 Dec 2009 15:02:17 -0800 (PST) Envelope-to: multimob@ietf.org Received: from e178157053.adsl.alicedsl.de ([85.178.157.53] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NIs1M-000Eo0-Gu; Fri, 11 Dec 2009 00:02:04 +0100 Message-ID: <4B217DE0.5050409@informatik.haw-hamburg.de> Date: Fri, 11 Dec 2009 00:01:52 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behcet Sarikaya References: <323854.63535.qm@web111405.mail.gq1.yahoo.com> In-Reply-To: <323854.63535.qm@web111405.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] Adoption of draft-schmidt-multimob-pmipv6-mcast-deployment as a WG document 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, 10 Dec 2009 23:02:19 -0000 Hi Behcet, hi all, I don't understand this "call for adoption" at the current moment. We had the consensus at the Hiroshima meeting (affirmed by the recent mailing) that MLD/IGMP proxy at the MAG should be the favorite approach to a base solution. We also had a number of questions and issues raised at the Hiroshima meeting that were to be addressed in updates of the corresponding proposals currently around. To recall, we had three original solutions: [Direct Routing Option:] If native multicast routing reaches all MAGs in a PMIP domain, then straight-forward MLD proxying can be applied at MAGs with neither participation of the LMAs, nor tunneling. This is proposed in parts of [draft-sijeon-multimob-mms-pmip6-01], if you strip context transfer and predictive operations off the document. [Dedicated Multicast LMA:] If all multicast traffic of an entire PMIP domain is managed by a single LMA, then all MAGs may choose a tunnel with this particular LMA for multicast uplink. There is no need for proxy binding caches and MN-specific states at the LMA. This is proposed in section 3. of [draft-zuniga-multimob-smspmip-00], if you strip handover-specifics off the document. [Proxy instance per LMA:] If multicast traffic in PMIP should follow unicast paths, then it arrives at the MN via MN-specific LMAs and MAGs on the basis of proxy binding caches. This approach is a direct extension of unicast, facilitated by placing a proxy instance per MAG-LMA uplink on MAGs and proposed in [draft-schmidt-multimob-pmipv6-mcast-deployment]. Questions and issues raised at the meeting were concerned with efficiency, the MLD-related behavior of current router implementations and "the right way to organize an uplink". Contributers were asked to update the drafts following further investigations. The latter has not happened, now. Personally, we are working on "our homework" and furthermore have indicated an elegant path to merge draft-sijeon-multimob-mms-pmip6-01 into draft-schmidt-multimob-pmipv6-mcast-deployment. We are about to prepare our update and I guess some room for discussion should be left once all updates have been prepared. So I don't see why this call for working group adoption precedes the updates of the drafts. I would suggest to await updates and perform the call after the discussion has reached some level of insight. Best regards, Thomas Behcet Sarikaya wrote: > Hello all, > Consensus on IGMP/MLD Proxy at MAG has been confirmed. Based on evaluation of the four solution drafts, draft-schmidt-multimob-pmipv6-mcast-deployment comes closest to the charter item: > > Initial version of a document explaining the use of multicast in PMIPv6. > > The latest version of this document can be found at: > http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-mcast-deployment-02.txt > > This mail starts a WG adoption call on this draft. > > The intended status for this document is BCP. > If adopted, the draft will be named: > > draft-ietf-multimob-pmipv6-base-solution. > > Please respond if you are for ADOPTING or > > you are NOT for ADOPTING it by December 18, 2009. > > > Chairs > > > > _______________________________________________ > 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 Thu Dec 10 17:45: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 29D123A695B for ; Thu, 10 Dec 2009 17:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.59 X-Spam-Level: *** X-Spam-Status: No, score=3.59 tagged_above=-999 required=5 tests=[AWL=-0.681, 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 TZQA7E2-od8b for ; Thu, 10 Dec 2009 17:45:16 -0800 (PST) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 727893A6900 for ; Thu, 10 Dec 2009 17:45:16 -0800 (PST) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 8563613D06C4; Fri, 11 Dec 2009 10:45:03 +0900 (JST) Date: Fri, 11 Dec 2009 10:45:05 +0900 (JST) Message-Id: <20091211.104505.29035747.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <323854.63535.qm@web111405.mail.gq1.yahoo.com> References: <323854.63535.qm@web111405.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] Adoption of draft-schmidt-multimob-pmipv6-mcast-deployment as a WG document 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, 11 Dec 2009 01:45:17 -0000 > If adopted, the draft will be named: > = > draft-ietf-multimob-pmipv6-base-solution. > = > Please respond if you=A0are for ADOPTING=A0or > = > you are NOT for ADOPTING it by December 18, 2009. I agree with others. We don't say whether this draft is appropriate for the basic solution or not. This call for consensus is not appropriate at this moment. Regards, -- Hitoshi Asaeda From pierrick.seite@orange-ftgroup.com Fri Dec 11 02:10:51 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 DA6903A677C for ; Fri, 11 Dec 2009 02:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6] 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 vAlOl4i2buFj for ; Fri, 11 Dec 2009 02:10:48 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 37B723A6AAB for ; Fri, 11 Dec 2009 02:10:45 -0800 (PST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 11:10:28 +0100 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: Fri, 11 Dec 2009 11:10:27 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46285CED9@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <1260461699.3439.175.camel@acorde.it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Adoption of draft-schmidt-multimob-pmipv6-mcast-deployment as a WG document Thread-Index: Acp5s/uT6+6q6OENRy65/UQcIg0VhAAAQQkw References: <323854.63535.qm@web111405.mail.gq1.yahoo.com> <1260461699.3439.175.camel@acorde.it.uc3m.es> From: To: , X-OriginalArrivalTime: 11 Dec 2009 10:10:28.0340 (UTC) FILETIME=[29F26340:01CA7A4A] Cc: multimob@ietf.org Subject: Re: [multimob] Adoption of draft-schmidt-multimob-pmipv6-mcast-deployment as a WG document 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, 11 Dec 2009 10:10:52 -0000 I second what have been already said. There are other proposals which = are worth to be considered and discussed. It is too early for a WGLC. BR, Pierrick > -----Message d'origine----- > De=A0: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] De = la > part de Carlos Jes=FAs Bernardos Cano > Envoy=E9=A0: jeudi 10 d=E9cembre 2009 17:15 > =C0=A0: Behcet Sarikaya > Cc=A0: multimob@ietf.org > Objet=A0: Re: [multimob] Adoption of = draft-schmidt-multimob-pmipv6-mcast- > deployment as a WG document >=20 > Hi Behcet, >=20 > I do NOT support the ADOPTION of this document. We have just confirmed > consensus on an approach and this is translated in adopting a > particular document? AFAIK, there are several documents following the > same IGMP/MLD approach and we haven't had much discussion on the pros > and cons of each of them. IMHO, it is early to make such an adoption > call and I strongly disagree with it. >=20 > Thanks, >=20 > Carlos >=20 > On Thu, 2009-12-10 at 08:03 -0800, Behcet Sarikaya wrote: > > Hello all, > > Consensus on IGMP/MLD Proxy at MAG has been confirmed. Based on > evaluation of the four solution drafts, draft-schmidt-multimob-pmipv6- > mcast-deployment comes closest to the charter item: > > > > Initial version of a document explaining the use of multicast in = PMIPv6. > > > > The latest version of this document can be found at: > > = http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-mcast-deployment- > 02.txt > > > > This mail starts a WG adoption call on this draft. > > > > The intended status for this document is BCP. > > If adopted, the draft will be named: > > > > draft-ietf-multimob-pmipv6-base-solution. > > > > Please respond if you are for ADOPTING or > > > > you are NOT for ADOPTING it by December 18, 2009. > > > > > > Chairs > > > > > > > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > -- > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 From Guang.Lu@InterDigital.com Fri Dec 11 06:17: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 6F1AB3A6944 for ; Fri, 11 Dec 2009 06:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 Dp61FMNUB7aB for ; Fri, 11 Dec 2009 06:17:56 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 7AEF63A6934 for ; Fri, 11 Dec 2009 06:17:52 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 09:17:40 -0500 Received: from SAM.InterDigital.com ([10.30.2.12]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 09:17:26 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Dec 2009 09:17:24 -0500 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46285CED9@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Adoption ofdraft-schmidt-multimob-pmipv6-mcast-deployment as a WG document Thread-Index: Acp5s/uT6+6q6OENRy65/UQcIg0VhAAAQQkwAC3TmEA= References: <323854.63535.qm@web111405.mail.gq1.yahoo.com><1260461699.3439.175.camel@acorde.it.uc3m.es> <843DA8228A1BA74CA31FB4E111A5C46285CED9@ftrdmel0.rd.francetelecom.fr> From: "Lu, Guang" To: X-OriginalArrivalTime: 11 Dec 2009 14:17:26.0417 (UTC) FILETIME=[AA358010:01CA7A6C] Subject: Re: [multimob] Adoption ofdraft-schmidt-multimob-pmipv6-mcast-deployment as a WG document 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, 11 Dec 2009 14:17:58 -0000 It is TOO EARLY for the WG to adopt any solution right now. The multiple = drafts should be updated, and further evaluated before any adoption = should be made. IMO, if different solutions work well in different use = cases, the WG draft should make recommendations that allow various = solutions to be used. =20 At the IETF 76 meeting, the WG reached consensus on two things.=20 First is to adopt the approach of IGMP/MLD proxy at the MAG (which was = voted again recently on the mailing list) Second, there are several proposed solutions under the IGMP/MLD proxy = approach. The WG agreed that no specific draft was adopted. This is = because more work needs to be done on the "basic" stuff. Below are quotes from IETF 76 minutes regarding:=20 " Consensus call: Multicast not locally available (no MLD Proxy at the MAG) forward = IGMP/MLD to LMA, decap multicast data from LMA? None. IGMP/MLD Proxy at the MAG? 16 votes. Chairs. There is a consensus on proxy approaches. We have decided on a (technical) direction to go, not on a particular = draft. " "Jari: Basic stuff has to be done to move to the interesting problems. However, we have not to sacrifice anything if solution space needs = further investigation." Best Regards, Guang > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of pierrick.seite@orange-ftgroup.com > Sent: Friday, December 11, 2009 5:10 AM > To: cjbc@it.uc3m.es; sarikaya@ieee.org > Cc: multimob@ietf.org > Subject: Re: [multimob] Adoption = ofdraft-schmidt-multimob-pmipv6-mcast- > deployment as a WG document >=20 >=20 > I second what have been already said. There are other proposals which > are worth to be considered and discussed. It is too early for a WGLC. >=20 > BR, > Pierrick >=20 > > -----Message d'origine----- > > De=A0: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] = De > la > > part de Carlos Jes=FAs Bernardos Cano > > Envoy=E9=A0: jeudi 10 d=E9cembre 2009 17:15 > > =C0=A0: Behcet Sarikaya > > Cc=A0: multimob@ietf.org > > Objet=A0: Re: [multimob] Adoption of draft-schmidt-multimob-pmipv6- > mcast- > > deployment as a WG document > > > > Hi Behcet, > > > > I do NOT support the ADOPTION of this document. We have just > confirmed > > consensus on an approach and this is translated in adopting a > > particular document? AFAIK, there are several documents following = the > > same IGMP/MLD approach and we haven't had much discussion on the = pros > > and cons of each of them. IMHO, it is early to make such an adoption > > call and I strongly disagree with it. > > > > Thanks, > > > > Carlos > > > > On Thu, 2009-12-10 at 08:03 -0800, Behcet Sarikaya wrote: > > > Hello all, > > > Consensus on IGMP/MLD Proxy at MAG has been confirmed. Based on > > evaluation of the four solution drafts, draft-schmidt-multimob- > pmipv6- > > mcast-deployment comes closest to the charter item: > > > > > > Initial version of a document explaining the use of multicast in > PMIPv6. > > > > > > The latest version of this document can be found at: > > > http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-mcast- > deployment- > > 02.txt > > > > > > This mail starts a WG adoption call on this draft. > > > > > > The intended status for this document is BCP. > > > If adopted, the draft will be named: > > > > > > draft-ietf-multimob-pmipv6-base-solution. > > > > > > Please respond if you are for ADOPTING or > > > > > > you are NOT for ADOPTING it by December 18, 2009. > > > > > > > > > Chairs > > > > > > > > > > > > _______________________________________________ > > > multimob mailing list > > > multimob@ietf.org > > > https://www.ietf.org/mailman/listinfo/multimob > > -- > > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From sijeon79@gmail.com Fri Dec 11 06:56: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 9D93C3A693D for ; Fri, 11 Dec 2009 06:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fK2Xhi8USZr for ; Fri, 11 Dec 2009 06:56:06 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id CB9E33A69DF for ; Fri, 11 Dec 2009 06:56:06 -0800 (PST) Received: by pwi20 with SMTP id 20so688831pwi.29 for ; Fri, 11 Dec 2009 06:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:reply-to:from:to:cc :references:subject:date:organization:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=n98GrhNNEVEpOAKEygGuJRkhSI6L3rWcoLJIyxq+yVY=; b=jgTBZVm45MPgYrpm11Noy+RdI8YfzKqssCbQI/f+pxC7c9MzM4otZuFIUoB3396vUr 9+F79kRIMatDTUNINfvsX4UmCk+HtiUAS+bnQvJayRASgc3i3kNa7IoAtXbpqIXCUklx Ih+kRMwa1gFac10mubmZJAMpmf1gKp/8x65B0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=reply-to:from:to:cc:references:subject:date:organization:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :in-reply-to:thread-index:x-mimeole; b=b8B75A5B0pUq05mDVOsyCFzrdYi57Ru9vQY+j8ile4d88qocEjYFkTGct/XNt+M/42 w3aU7F6nVskK+gd0R1Qc1PmvL2a04xEvsKqEEDxpCF8/gnug+MrRX2HhWmZ8J37rwf7R PNYb/zLljL7tXwALijU7iR0qiEEURMSfd6lDQ= Received: by 10.114.188.21 with SMTP id l21mr865702waf.138.1260543352694; Fri, 11 Dec 2009 06:55:52 -0800 (PST) Received: from dcn0d4b06d5df0 ([220.149.84.225]) by mx.google.com with ESMTPS id 22sm1833557pzk.2.2009.12.11.06.55.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 11 Dec 2009 06:55:51 -0800 (PST) From: "Seil Jeon" To: "'Behcet Sarikaya'" References: <323854.63535.qm@web111405.mail.gq1.yahoo.com> Date: Fri, 11 Dec 2009 23:55:46 +0900 Organization: dcn Message-ID: <007e01ca7a72$06a55780$c27113ac@dcn0d4b06d5df0> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <323854.63535.qm@web111405.mail.gq1.yahoo.com> thread-index: Acp5sl+wKsyiwpQOQ9i5Us1UGAYU9wAu/1tA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: multimob@ietf.org Subject: Re: [multimob] Adoption ofdraft-schmidt-multimob-pmipv6-mcast-deployment as a WG document X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sijeon79@gmail.com List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 14:56:07 -0000 Hi Behcet and multimob friends, I also totally agree with other's opinions that we need discussion to = determine the WG solution because we have just got consensus of = direction to go where. Consensus means that proxy MLD at the MAG as we know. Of course, for a long time, we have talked about the various solutions = through multimob mailing. As the first result, we have arranged the issues of each solution at the = hiroshima meeting. As a next step, as schmidt says, it would be better discussion on the = updated drafts, if necessarilly. Best Regards, Seil Jeon -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On = Behalf Of Behcet Sarikaya Sent: Friday, December 11, 2009 1:04 AM To: multimob@ietf.org Subject: [multimob] Adoption = ofdraft-schmidt-multimob-pmipv6-mcast-deployment as a WG document Hello all, Consensus on IGMP/MLD Proxy at MAG has been confirmed. Based on = evaluation of the four solution drafts, = draft-schmidt-multimob-pmipv6-mcast-deployment comes closest to the = charter item: Initial version of a document explaining the use of multicast in PMIPv6. = The latest version of this document can be found at: http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-mcast-deployment-0= 2.txt This mail starts a WG adoption call on this draft. The intended status for this document is BCP. If adopted, the draft will be named: draft-ietf-multimob-pmipv6-base-solution. Please respond if you are for ADOPTING or you are NOT for ADOPTING it by December 18, 2009. Chairs =20 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Fri Dec 11 12:44:27 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 CBFEF3A677E for ; Fri, 11 Dec 2009 12:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6] 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 FY4ioYjxjT-1 for ; Fri, 11 Dec 2009 12:44:26 -0800 (PST) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id D1DED3A6824 for ; Fri, 11 Dec 2009 12:44:26 -0800 (PST) Received: (qmail 32082 invoked by uid 60001); 11 Dec 2009 20:44:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1260564252; bh=bYc6qwp/u/uKvBFfOyxCNfKHPhlTfmhaePK+WecPwbo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aBKKoAzlkAwEkrFnNJbDTgBGv88uLi9FCLgzTY5nwaGS0plrkWU8IOPadwiuyRDU1Tr+hRnBOjEe6ouZbXsKo2Oxqc3x5JHADKli/Sq0vva64tpruBQ0WXO4HyHJ/MvhJMoYn21qr3XwCuJB86Ie++CRitogj/CCeEkl7oRwIh8= 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:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ccg8Y4giGv1h5wh5R66iuCjYbRMCaKhfbp/toua7J6JUGdggydwOEuGj/7Ij1UpVLklKIc4hDKCTWfa/z6QDC3qUmCkO6mukOUZ2TPbTXXTx/SZUdL3Mq+wXx96htQXyaDh+uraL2jK5oyokRmDGMbzxNyI7G6hVa7Kng/ClWHI=; Message-ID: <250017.31094.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: WhJItY4VM1kfC7bNOrVVfhMf3RLYghB3eHAuMuj_YSf5LRmUoABPNzadGnB5FvUWFq8JIHeGOzvcfNO1evBFbo.DEyGQctZE.uY1JK1t7wWP0XbULaI_DRsBoUm2Nx3VJ2Mt5fEQQYEfaHeIJ03MHK.In3JoOLUv22565xi3YC6UMzsr8y2CQmFg53l.StoptBgVWMu358u3k.80lolU.A_ElDqC.kxgE9lZMX4pjmE9_j6m6Jj8JxUqu35VARH1P2OdL4bqFDPAF_1ZFbCWnGVMUOcpeuxXe3JBju8zmsYBXqKMAgV.rvfq0USf9iHIoRhzwmSvRsmGyYuPJJgW9bFKw8BMu0LZ6w0HSLI4lBvf2Iae9uNFRWDEknqR_u8_N2GKMrkRSplaGXFG.Lgi_CUl5QHuV3i7Qxdf3XZe864V9txOsRXQW0ke Received: from [68.142.242.119] by web111414.mail.gq1.yahoo.com via HTTP; Fri, 11 Dec 2009 12:44:12 PST X-Mailer: YahooMailWebService/0.8.100.260964 Date: Fri, 11 Dec 2009 12:44:12 -0800 (PST) From: Behcet Sarikaya To: "" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 11 Dec 2009 12:53:08 -0800 Cc: "multimob@ietf.org" Subject: Re: [multimob] Adoption of draft-schmidt-multimob-pmipv6-mcast-deployment as a WG document 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, 11 Dec 2009 20:44:27 -0000 Let me clarify this.=0A=0AThis is not wglc.=0AIt is WG draft adoption call.= Replying to this call WG members can provide technical comments to improve= the draft.=0A=0AAlso after becoming a WG draft (if it does) the draft goes= thru revisions.=0A=0AWe are not sending the document to IESG :)=0A=0ARegar= ds,=0A=0ABehcet=0A=0AOn Dec 11, 2009, at 4:10 AM, wrote:=0A=0A=0AI second what have been already said. There are o= ther proposals which are worth to be considered and discussed. It is too ea= rly for a WGLC.=0A=0ABR,=0APierrick=0A=0A-----Message d'origine-----=0ADe := multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] De la=0Apart = de Carlos Jes=FAs Bernardos Cano=0AEnvoy=E9 : jeudi 10 d=E9cembre 2009 17:1= 5=0A=C0 : Behcet Sarikaya=0ACc : multimob@ietf.org=0AObjet : Re: [multimob]= Adoption of draft-schmidt-multimob-pmipv6-mcast-=0Adeployment as a WG docu= ment=0A=0AHi Behcet,=0A=0AI do NOT support the ADOPTION of this document. W= e have just confirmed=0Aconsensus on an approach and this is translated in= adopting a=0Aparticular document? AFAIK, there are several documents follo= wing the=0Asame IGMP/MLD approach and we haven't had much discussion on the= pros=0Aand cons of each of them. IMHO, it is early to make such an adoptio= n=0Acall and I strongly disagree with it.=0A=0AThanks,=0A=0ACarlos=0A=0AOn = Thu, 2009-12-10 at 08:03 -0800, Behcet Sarikaya wrote:=0AHello all,=0A Cons= ensus on IGMP/MLD Proxy at MAG has been confirmed. Based on=0Aevaluation of= the four solution drafts, draft-schmidt-multimob-pmipv6-=0Amcast-deploymen= t comes closest to the charter item:=0A=0AInitial version of a document exp= laining the use of multicast in PMIPv6.=0A=0AThe latest version of this doc= ument can be found at:=0Ahttp://tools.ietf.org/id/draft-schmidt-multimob-pm= ipv6-mcast-deployment-=0A02.txt=0A=0AThis mail starts a WG adoption call on= this draft.=0A=0AThe intended status for this document is BCP.=0AIf adopte= d, the draft will be named:=0A=0Adraft-ietf-multimob-pmipv6-base-solution.= =0A=0APlease respond if you are for ADOPTING or=0A=0Ayou are NOT for ADOPTI= NG it by December 18, 2009.=0A=0A=0AChairs=0A=0A=0A=0A_____________________= __________________________=0Amultimob mailing list=0Amultimob@ietf.org=0Aht= tps://www.ietf.org/mailman/listinfo/multimob=0A--=0ACarlos Jes=FAs Bernardo= s Cano http://www.netcoms.net=0AGPG FP: D29B 0A6A 639A A561 93CA 4D55 = 35DC BA4D D170 4F67=0A=0A=0A=0A From asaeda@sfc.wide.ad.jp Fri Dec 11 21:00: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 7C2DF3A67C1 for ; Fri, 11 Dec 2009 21:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.318 X-Spam-Level: *** X-Spam-Status: No, score=3.318 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 IOppHhB1zK9I for ; Fri, 11 Dec 2009 21:00:05 -0800 (PST) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id BA1E63A68BD for ; Fri, 11 Dec 2009 21:00:05 -0800 (PST) Received: from localhost (dhcp-246-253.mag.keio.ac.jp [133.27.246.253]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 04E9D13D06C4; Sat, 12 Dec 2009 13:59:51 +0900 (JST) Date: Sat, 12 Dec 2009 13:59:50 +0900 (JST) Message-Id: <20091212.135950.120629157.asaeda@sfc.wide.ad.jp> To: behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <250017.31094.qm@web111414.mail.gq1.yahoo.com> References: <250017.31094.qm@web111414.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=us-ascii Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] Adoption of draft-schmidt-multimob-pmipv6-mcast-deployment as a WG document 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, 12 Dec 2009 05:00:06 -0000 > It is WG draft adoption call. Replying to this call WG members can > provide technical comments to improve the draft. > > Also after becoming a WG draft (if it does) the draft goes thru revisions. Everyone knows a WG draft will be revised based on discussions in any time. The point everyone has been saying is that the decision which draft should be the WG draft should not be made at this timing. Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Fri Dec 11 22:31: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 7F6A03A67EF for ; Fri, 11 Dec 2009 22:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.111 X-Spam-Level: ** X-Spam-Status: No, score=2.111 tagged_above=-999 required=5 tests=[AWL=1.207, 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 xueUHOP+xdR6 for ; Fri, 11 Dec 2009 22:31:10 -0800 (PST) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 13A9F3A67DD for ; Fri, 11 Dec 2009 22:31:09 -0800 (PST) Received: from localhost (dhcp-246-253.mag.keio.ac.jp [133.27.246.253]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 769CC13D06C4; Sat, 12 Dec 2009 15:30:56 +0900 (JST) Date: Sat, 12 Dec 2009 15:30:56 +0900 (JST) Message-Id: <20091212.153056.104339241.asaeda@sfc.wide.ad.jp> To: luisc@it.uc3m.es From: Hitoshi Asaeda In-Reply-To: <20091209233504.8mwgk21r28c440so@webcartero01.uc3m.es> References: <20091205124522.4q9osw00w0s8wck8@webcartero01.uc3m.es> <20091207.165058.223254814.asaeda@sfc.wide.ad.jp> <20091209233504.8mwgk21r28c440so@webcartero01.uc3m.es> 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] IGMP/MLD Proxy at the MAG 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, 12 Dec 2009 06:31:11 -0000 Hi Luis, > > For instance, regarding pMAG-assisted handover, you say; "the pMAG can > > be able to temporally forward via the LMA a copy of the multicast > > content within an unicast flow towards the new location of the MN, > > brahbrah", but is this a common behavior of rfc5213 compliant MAG? > > I see this as an additional functionality added to MAG elements to > support multicast service, as could be the case for the proposal > of using context transfer methods to transfer multicast status to > nMAG, or the case of implementing more than one MLD instance in a > MAG. All of them are new functionalities proposed in the framework > of multicast support in PMIP without extending basic protocol > defined in RFC5213. ^^^^^^^ It seems that we are not in the same assumption regarding "protocol extension". IMO, whether a new signal or message type is used or not, if a proposed function cannot be implemented based on existing RFCs, that function is categorized "protocol extension". Folks, what do you think? Regards, -- Hitoshi Asaeda From schmidt@informatik.haw-hamburg.de Sat Dec 12 02:45: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 8A76F3A694C for ; Sat, 12 Dec 2009 02:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 p5+r3TTIOMnx for ; Sat, 12 Dec 2009 02:45:05 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 5504B3A68B3 for ; Sat, 12 Dec 2009 02:45:04 -0800 (PST) Envelope-to: multimob@ietf.org Received: from e178165248.adsl.alicedsl.de ([85.178.165.248] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NJPSy-0001yL-Bh; Sat, 12 Dec 2009 11:44:50 +0100 Message-ID: <4B237417.9010306@informatik.haw-hamburg.de> Date: Sat, 12 Dec 2009 11:44:39 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hitoshi Asaeda References: <20091205124522.4q9osw00w0s8wck8@webcartero01.uc3m.es> <20091207.165058.223254814.asaeda@sfc.wide.ad.jp> <20091209233504.8mwgk21r28c440so@webcartero01.uc3m.es> <20091212.153056.104339241.asaeda@sfc.wide.ad.jp> In-Reply-To: <20091212.153056.104339241.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] IGMP/MLD Proxy at the MAG 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, 12 Dec 2009 10:45:06 -0000 Hi Hitoshi, hi Luis, see below: Hitoshi Asaeda wrote: > Hi Luis, > >>> For instance, regarding pMAG-assisted handover, you say; "the pMAG can >>> be able to temporally forward via the LMA a copy of the multicast >>> content within an unicast flow towards the new location of the MN, >>> brahbrah", but is this a common behavior of rfc5213 compliant MAG? >> I see this as an additional functionality added to MAG elements to >> support multicast service, as could be the case for the proposal >> of using context transfer methods to transfer multicast status to >> nMAG, or the case of implementing more than one MLD instance in a >> MAG. All of them are new functionalities proposed in the framework >> of multicast support in PMIP without extending basic protocol >> defined in RFC5213. ^^^^^^^ > > It seems that we are not in the same assumption regarding "protocol > extension". > IMO, whether a new signal or message type is used or not, if a > proposed function cannot be implemented based on existing RFCs, that > function is categorized "protocol extension". > > Folks, what do you think? > That's IMO exactly so. Using the same messages, but changing the protocol semantics or the behavior of the entities is a clear protocol extension (example: RTP was updated without changing the bits on the wire, but with altered RTCP signaling coordination in multicast scenarios). Jari in his last mail to the group also stated it very clearly: "However, I am going to insist that including this optimization really comes for free through the use of the existing RFC. If your specification ends up having significant behaviour rules about it, you are over the line and should probably leave it for later." So, pMAG forwarding via the LMA is clearly *not* covered by RFC5213 ... 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 Sun Dec 13 15:51:33 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 352F53A6970 for ; Sun, 13 Dec 2009 15:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_20=-0.74, 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 WlZTzZBdIUtH for ; Sun, 13 Dec 2009 15:51:32 -0800 (PST) Received: from web111415.mail.gq1.yahoo.com (web111415.mail.gq1.yahoo.com [67.195.15.216]) by core3.amsl.com (Postfix) with SMTP id 636A13A6874 for ; Sun, 13 Dec 2009 15:51:32 -0800 (PST) Received: (qmail 1127 invoked by uid 60001); 13 Dec 2009 23:51:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1260748277; bh=A0Is7uH5G6RAYZ1ftS0kOsqcKqDXp6Ff3Le4B1VW2o0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=x2aIteIqm87eVPJkgO/gGpkNyCjpAra8dAowj6lu5G2glVSuGpgVBgdb7q30iyWDlKUgWHYWphlbC/uEF4VWNME3YTUDO62uuMGATghdw5jD3kb/0qUDEzqgyIVWt59g3r2iJJPNh+RBc5J3PvSeK5eUREq2mmBR09ZBTPhLeVI= 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=WRr8kmZkP1qDAkSgWhK730skw4wrI73p3rWXDHr+iLYCuEPwzc5ThmWpYGIfE6Mi107xF9pjz0BxS0shxz02dpjUaj6iz+9ndY1ycQgqq/llhzIpgoXwfVfbD5n8dCRELCuytISj0awN26V19dTCN4n/AtW6yCle0QOCJ9X/xz4=; Message-ID: <271941.99514.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: juYZKYMVM1kYngByP9AjPYl57CCigWf7raYmqZQkLf6Sms.8pLOUCQqDh2x7Gtgek4GQYXmEJeFSvAVwYr1XI8pYF7nzwCGVziYwjSGJbXrMqIiQma040rk78angjFtHnpBkdJDl8EuPUWXDX_Oyz9k7H0VifqqmvWdpjG5G3WVL8MKREsqKgaReWS0.2mtuZzZopoicErG0Kl3H9K9mQ9Pp27wBbNeL.IbfdcggK_FPj8TW8iEw8CI0KrM8FnwhjVbyPc1ijNB3aSjIuuKu7esk8I6PrcHLp5MCoIJFF.C8haC2cPxpuCxiRjy9tUFWq0Xj6ql8 Received: from [72.64.108.212] by web111415.mail.gq1.yahoo.com via HTTP; Sun, 13 Dec 2009 15:51:17 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 Date: Sun, 13 Dec 2009 15:51:17 -0800 (PST) From: Behcet Sarikaya To: "Thomas C. Schmidt" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] Adoption of draft-schmidt-multimob-pmipv6-mcast-deployment as a WG document 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: Sun, 13 Dec 2009 23:51:33 -0000 Hi Thomas, Please see more comments below, my understanding of the consensus was IGMP/MLD Proxy at MAG integrated with LMA. Maybe we need to clarify the consensus. > > On Dec 10, 2009, at 5:01 PM, "Thomas C. Schmidt" > wrote: > > Hi Behcet, hi all, > > I don't understand this "call for adoption" at the current moment. > > We had the consensus at the Hiroshima meeting (affirmed by the recent mailing) > that MLD/IGMP proxy at the MAG should be the favorite approach to a base > solution. > > We also had a number of questions and issues raised at the Hiroshima meeting > that were to be addressed in updates of the corresponding proposals currently > around. > > To recall, we had three original solutions: > > [Direct Routing Option:] > If native multicast routing reaches all MAGs in a PMIP domain, then > straight-forward MLD proxying can be applied at MAGs with neither participation > of the LMAs, nor tunneling. > This is proposed in parts of [draft-sijeon-multimob-mms-pmip6-01], if you strip > context transfer and predictive operations off the document. Local MR is a specific solution, the implication of it is that PMIPv6 is not in charge of mobility of multicast data. In these cases multicast becomes tangential to mobility. How is it different than locally available multicast that MN can use without bothering with any mobility protocol? It is similar to MAG operation as multicast routerdiscussed in Section 6.2 of draft-contreras-multimob-msd-00.txt. We have not discussed these types of solutions where multicast is provided separately of mobility in detail yet possibly because it probably requires a separate charter item for us. > > [Dedicated Multicast LMA:] > If all multicast traffic of an entire PMIP domain is managed by a single LMA, > then all MAGs may choose a tunnel with this particular LMA for multicast uplink. > There is no need for proxy binding caches and MN-specific states at the LMA. > This is proposed in section 3. of [draft-zuniga-multimob-smspmip-00], if you > strip handover-specifics off the document. Isn't LMA-M effectively Local MR in draft-sijeon-multimob-mms-pmip6-01? > > [Proxy instance per LMA:] > If multicast traffic in PMIP should follow unicast paths, then it arrives at the > MN via MN-specific LMAs and MAGs on the basis of proxy binding caches. This > approach is a direct extension of unicast, facilitated by placing a proxy > instance per MAG-LMA uplink on MAGs and proposed in > [draft-schmidt-multimob-pmipv6-mcast-deployment]. > What is the point with this, I could not understand? > > Questions and issues raised at the meeting were concerned with efficiency, the > MLD-related behavior of current router implementations and "the right way to > organize an uplink". Contributers were asked to update the drafts following > further investigations. > > The latter has not happened, now. Personally, we are working on "our homework" > and furthermore have indicated an elegant path to merge > draft-sijeon-multimob-mms-pmip6-01 into > draft-schmidt-multimob-pmipv6-mcast-deployment. We are about to prepare our > update and I guess some room for discussion should be left once all updates > have been prepared. See above. > > So I don't see why this call for working group adoption precedes the updates of > the drafts. I would suggest to await updates and perform the call after the > discussion has reached some level of insight. > ? Regards, Behcet From schmidt@informatik.haw-hamburg.de Mon Dec 14 04:35: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 403FB3A687D for ; Mon, 14 Dec 2009 04:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.037, 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 mw09+Zlo0HpJ for ; Mon, 14 Dec 2009 04:35:24 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 31E573A6836 for ; Mon, 14 Dec 2009 04:35:23 -0800 (PST) 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 1NKA8q-0002b4-FN; Mon, 14 Dec 2009 13:35:08 +0100 Message-ID: <4B2630F5.80902@informatik.haw-hamburg.de> Date: Mon, 14 Dec 2009 13:35:01 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behcet Sarikaya References: <271941.99514.qm@web111415.mail.gq1.yahoo.com> In-Reply-To: <271941.99514.qm@web111415.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] Adoption of draft-schmidt-multimob-pmipv6-mcast-deployment as a WG document 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, 14 Dec 2009 12:35:25 -0000 Hi Behcet, if I comprehend your point correctly, then you argue that multicast locally available at MAGs is tangential to a PMIP multicast solution. On that we fully agree. The outcome of Hiroshima, repeated in my previous mail, was the following: * Everyone should address the issues raised in Hiroshima regarding all individual approaches, update the drafts, and then find consensus on the base document. * In the case that draft-schmidt-multimob-pmipv6-mcast-deployment is chosen as the base document, we already offered to include the local routing as option, as this easily integrates and is technically almost for free. So there is not much novelty - my main point of the previous mail was that the adoption call came too early. Cheers, Thomas Behcet Sarikaya wrote: > Hi Thomas, > > Please see more comments below, my understanding of the consensus was > IGMP/MLD Proxy at MAG integrated with LMA. > > Maybe we need to clarify the consensus. > > >> On Dec 10, 2009, at 5:01 PM, "Thomas C. Schmidt" >> wrote: >> >> Hi Behcet, hi all, >> >> I don't understand this "call for adoption" at the current moment. >> >> We had the consensus at the Hiroshima meeting (affirmed by the recent mailing) >> that MLD/IGMP proxy at the MAG should be the favorite approach to a base >> solution. >> >> We also had a number of questions and issues raised at the Hiroshima meeting >> that were to be addressed in updates of the corresponding proposals currently >> around. >> >> To recall, we had three original solutions: >> >> [Direct Routing Option:] >> If native multicast routing reaches all MAGs in a PMIP domain, then >> straight-forward MLD proxying can be applied at MAGs with neither participation >> of the LMAs, nor tunneling. >> This is proposed in parts of [draft-sijeon-multimob-mms-pmip6-01], if you strip >> context transfer and predictive operations off the document. > > Local MR is a specific solution, the implication of it is that PMIPv6 is not in charge of mobility of multicast data. In these cases multicast becomes tangential to mobility. > > How is it different than locally available multicast that MN can use without bothering with any mobility protocol? > > It is similar to > MAG operation as multicast routerdiscussed in Section 6.2 of draft-contreras-multimob-msd-00.txt. > > We have not discussed these types of solutions where multicast is provided separately of mobility in detail yet possibly because it probably requires a separate charter item for us. > > >> [Dedicated Multicast LMA:] >> If all multicast traffic of an entire PMIP domain is managed by a single LMA, >> then all MAGs may choose a tunnel with this particular LMA for multicast uplink. >> There is no need for proxy binding caches and MN-specific states at the LMA. >> This is proposed in section 3. of [draft-zuniga-multimob-smspmip-00], if you >> strip handover-specifics off the document. > > Isn't LMA-M effectively Local MR in draft-sijeon-multimob-mms-pmip6-01? > > >> [Proxy instance per LMA:] >> If multicast traffic in PMIP should follow unicast paths, then it arrives at the >> MN via MN-specific LMAs and MAGs on the basis of proxy binding caches. This >> approach is a direct extension of unicast, facilitated by placing a proxy >> instance per MAG-LMA uplink on MAGs and proposed in >> [draft-schmidt-multimob-pmipv6-mcast-deployment]. >> > > What is the point with this, I could not understand? > >> Questions and issues raised at the meeting were concerned with efficiency, the >> MLD-related behavior of current router implementations and "the right way to >> organize an uplink". Contributers were asked to update the drafts following >> further investigations. >> >> The latter has not happened, now. Personally, we are working on "our homework" >> and furthermore have indicated an elegant path to merge >> draft-sijeon-multimob-mms-pmip6-01 into >> draft-schmidt-multimob-pmipv6-mcast-deployment. We are about to prepare our >> update and I guess some room for discussion should be left once all updates >> have been prepared. > > See above. > > >> So I don't see why this call for working group adoption precedes the updates of >> the drafts. I would suggest to await updates and perform the call after the >> discussion has reached some level of insight. >> > > ? > > Regards, > > Behcet > > > > -- 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 Mon Dec 14 07:34: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 39DC13A6A16 for ; Mon, 14 Dec 2009 07:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=0.250, 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 5NS0TS19WXLM for ; Mon, 14 Dec 2009 07:34:25 -0800 (PST) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id 718FE3A68FB for ; Mon, 14 Dec 2009 07:34:25 -0800 (PST) Received: (qmail 26626 invoked by uid 60001); 14 Dec 2009 15:34:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1260804850; bh=iU+e/XFR4o8qH7NtrO3wThfpz63WCdwM84RDe21Lnb0=; 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=5kNoP8dS6R1rpAWTIzv3sVBgcq1lcz4wotilQB9Wda2Zah8RHhuT5+TYS8gQWDp7MdgAo0TXkKP/cYK2pGz0NrlDMvUKeNGKio9rpCrBM/gZxXAAh7EOrZmtJuBPpnZVoUcoeGluOK8XOpKbQ0ZC1pr/beZv2wlxG4/VDzKISVw= 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=ov0WvGDGwJaa+HYFDGdEL3ay/0pbyxDMj7ABJgY1MW5yLIl5cyT5Z/5lH7+HvP3qEKaN+YwvdA9sUlPJBvXbSPpltKQxHag0V9lHeTJIdvY6JfZhr9cErg+Sd9Jo3Ay94Mhp4m2YhrDDEBYV7qGUH8jiNJ140ZHryWFScyDLBu8=; Message-ID: <222306.16291.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: cRXRqgkVM1ms17A152jY6cL5xl5W.0M2dNKrq0cflfYg.lhVUbl_XfyhuYIhKXQ3QvNLoQovSs4P8nce0c4SvGsCZsuEN4yAHaPxoPZg7s7CPHIskrpEGnq7eSJfQIz5zblwsM_AKl6vx8jfco3LIlZVTSCGzilIgF4Iiw78NFBD6iD1wBeFtUzteDT4r07rDKQGVb6zhQv8QI8vgK9G_3a0qKHsQktzLSNkSufBFDPBR3adx2HVlDCOFfw6qrkAuApC7vFISlE8m8qjFT9hlkwqSehUaNXevKX_rwLfir6u2kciGAjkUOZCt9ig.1NFghcaFjunHqk9wqQUoKHtVdJzyVDXW2SJL517yEJr Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Mon, 14 Dec 2009 07:34:10 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: <271941.99514.qm@web111415.mail.gq1.yahoo.com> <4B2630F5.80902@informatik.haw-hamburg.de> Date: Mon, 14 Dec 2009 07:34:10 -0800 (PST) From: Behcet Sarikaya To: "Thomas C. Schmidt" In-Reply-To: <4B2630F5.80902@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] Adoption of draft-schmidt-multimob-pmipv6-mcast-deployment as a WG document 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, 14 Dec 2009 15:34:26 -0000 =0A=0A=0A=0A----- Original Message ----=0A> From: Thomas C. Schmidt =0A> To: Behcet Sarikaya =0A= > Cc: multimob@ietf.org=0A> Sent: Mon, December 14, 2009 6:35:01 AM=0A> Sub= ject: Re: Adoption of draft-schmidt-multimob-pmipv6-mcast-deployment as a W= G document=0A> =0A> Hi Behcet,=0A> =0A> if I comprehend your point correctl= y, then you argue that multicast locally =0A> available at MAGs is tangenti= al to a PMIP multicast solution. On that we fully =0A> agree.=0A> =0A=0AIf = you look at Section 4.1 in draft-sijeon-multimob-mms-pmip6-01.txt which is = where direct routing or local routing is described, there is no multicast r= outing function on the LMA.=0A=0AThis is clearly against remote subscriptio= n in the charter which says that remote subscription is a mechanism by whic= h a mobile node joins a=0A=A0 multicast group and receives multicast data f= orwarded via the local=0A=A0 mobility anchor.=0A=0AHere I want to clarify t= hat =0Areceives multicast data forwarded via the local=0A=A0 mobility ancho= r =0A=0Ashould be understood as =0A=0Areceives multicast data forwarded via= =A0ITS local=0A=A0 mobility anchor=0A=0Abecause in PMIPv6 each MN may have = a different LMA.=0A=0ADue to the above and the consensus reached, draft-sch= midt is the only draft.=0A=0A=0A=0A> The outcome of Hiroshima, repeated in = my previous mail, was the following:=0A> =0A> * Everyone should address the= issues raised in Hiroshima regarding all =0A> individual approaches, updat= e the drafts, and then find consensus on the base =0A> document.=0A> =0A> *= In the case that draft-schmidt-multimob-pmipv6-mcast-deployment is chosen = as =0A> the base document, we already offered to include the local routing = as option, as =0A> this easily integrates and is technically almost for fre= e.=0A=0ANot so free, as you can see above=0A=0A=0ARegards,=0A=0ABehcet=0A= =0A=0A From schmidt@informatik.haw-hamburg.de Wed Dec 16 09:55: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 BB49C3A69F1 for ; Wed, 16 Dec 2009 09:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_05=-1.11, 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 V4rPK+iQuzJn for ; Wed, 16 Dec 2009 09:55:20 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 78E853A69F9 for ; Wed, 16 Dec 2009 09:55:20 -0800 (PST) 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 1NKy5Z-000Nyt-4S for multimob@ietf.org; Wed, 16 Dec 2009 18:55:05 +0100 Message-ID: <4B291EF2.7070808@informatik.haw-hamburg.de> Date: Wed, 16 Dec 2009 18:54:58 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 16 Dec 2009 17:55:21 -0000 Hi folks, we've completed our homework from Hiroshima now and submitted a new version of the pmipv6-mcast-deployment draft. Please see http://www.ietf.org/id/draft-schmidt-multimob-pmipv6-mcast-deployment-03.txt. From the Change Log: The following changes have been made from draft-schmidt-multimob-pmipv6-mcast-deployment-02. 1. Many editorial improvements, in particular as response to draft reviews. 2. Section on IPv4 support added. 3. Added clarifications on initial IGMP/MLD Queries and supplementary information in appendix. 4. Appendix added on comparative performance evaluation regarding mixed/dedicated deployment of multicast at LMAs. I hope this will stimulate/progress some of the technical discussions that are around. Best wishes, Thomas -------- Original Message -------- A new version of I-D, draft-schmidt-multimob-pmipv6-mcast-deployment-03.txt has been successfuly submitted by Thomas Schmidt and posted to the IETF repository. Filename: draft-schmidt-multimob-pmipv6-mcast-deployment Revision: 03 Title: A Minimal Deployment Option for Multicast Listeners in PMIPv6 Domains Creation_date: 2009-12-16 WG ID: Independent Submission Number_of_pages: 16 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. The IETF Secretariat. -- 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 °