From behcetsarikaya@yahoo.com Fri May 8 08:26:13 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E7828C16B for ; Fri, 8 May 2009 08:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.134 X-Spam-Level: X-Spam-Status: No, score=-0.134 tagged_above=-999 required=5 tests=[AWL=-1.532, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVxVA9qgY46l for ; Fri, 8 May 2009 08:26:12 -0700 (PDT) Received: from n3.bullet.mail.re3.yahoo.com (n3.bullet.mail.re3.yahoo.com [68.142.237.110]) by core3.amsl.com (Postfix) with SMTP id E909E28C261 for ; Fri, 8 May 2009 08:25:50 -0700 (PDT) Received: from [68.142.237.88] by n3.bullet.mail.re3.yahoo.com with NNFMP; 08 May 2009 15:27:17 -0000 Received: from [67.195.9.83] by t4.bullet.re3.yahoo.com with NNFMP; 08 May 2009 15:27:17 -0000 Received: from [67.195.9.106] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 08 May 2009 15:27:17 -0000 Received: from [127.0.0.1] by omp110.mail.gq1.yahoo.com with NNFMP; 08 May 2009 15:25:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 334118.27363.bm@omp110.mail.gq1.yahoo.com Received: (qmail 8626 invoked by uid 60001); 8 May 2009 15:27:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241796436; bh=HLGLl68fRx553FlVPTJmzs+VBdhn6Ut3yMA1nbhYctc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=SfcxRFn18yNG8nCawkn1NTUXxuM4SO4lJurJvkkRKixLYrH32/DQDVn0D7ML3WHdDPo7+Isr8rHnfJjIgQUKv2DVMxjcQmAnGqghnmbYWqiav7rOXncaYFyeM9AKhusxqYObYHRl89Rygz2qSljBNSEJrke8ER+RgBGPboSlaJw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=E1gSrDEs0n44yMCf8ONCC5PIelC1q2l1UY7o6i8sbT/OV0s/ArJT05zIYwf6pR5rJPVcvur6UFikvdrSoPyrV6dBTivm++sUE3xc0qu8in/0VFB1d63y/r+OeoUmzwP4tcb6X6kAp8u2lvU55kfVwTq/VfwJDMMKNRp6OUXwOfc=; Message-ID: <824000.1898.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: igK2yLsVM1kWkWLHa3G5ybkRgYmkr3u_mEhLz.GFIr0C10CPWKGdZIfzE7DHVSo4N4A4dNsiqk2gLr0yBYejIN4PRQ4mc4wTTKjHS5B1j7eArbtqsYI7LYXdR1S9us0kwcBa5XaQ3Vf92MJLciAAmFFiLz.g62qnuc1dyBN3je1sK.GETIf9W9so1nM4UDN6zAetvLE1AahlwLbulCX4l8pHsWhRR5EqM5AXgflWyf8rAQmTQCbp8TQGm9iFQigIcZrRQCDnRe89Kyck2mvyH6kfZR_r2.2fJx.Xqvq2dU8pPnAxxjgF Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Fri, 08 May 2009 08:27:16 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 Date: Fri, 8 May 2009 08:27:16 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1660545878-1241796436=:1898" Subject: [multimob] Teleconference on May 14 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, 08 May 2009 15:26:13 -0000 --0-1660545878-1241796436=:1898 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Folks,=0A=A0 There will a teleconference next week on Thursday to discuss t= he BoF.=0AHere are the bridge details:=0ATime and date:=0A7:30am=A0 CDT 8:3= 0am EDT 14:30pm Europe 8:30pm Shanghai =0AThursday May 14th =0ATo begin a c= onference call:=0A1. participants dial:=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Tol= l free:=A0 1-866-866-2244=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0International: 1-= 404-260-1415=0A2. When prompted, the participants dial the access code foll= owed by the # sign:=0A=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Part= icipant:=A0 1002444=0A=A0=0APlease join the call on time.=0A=A0=0ARegards,= =0A=A0=0ABehcet=0A=0A=0A --0-1660545878-1241796436=:1898 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Folks,
=0A
  There will a= teleconference next week on Thursday to discuss the BoF.
=0A
Here= are the bridge details:
=0A
Time and date:
=0A
7:30am&nb= sp; CDT 8:30am EDT 14:30pm Europe 8:30pm Shanghai
=0A
Thursday Ma= y 14th
=0A
=0A

To begin a conference ca= ll:

=0A

1= .. participants dial:
        &nb= sp; Toll free:  1-866-866-2244
     &= nbsp;    International: 1-404-260-1415

=0A

2. When prompted,= the participants dial the acce= ss code followed by the # sign:

=0A

           =      Participant:  1002444

=0A

<= SPAN style=3D"FONT-SIZE: 10pt"> 

=0A

Please join the call on time.

= =0A

 

=0A

Regards,

=0A

 =0A

Behcet


=0A=0A=0A=0A --0-1660545878-1241796436=:1898-- From schmidt@informatik.haw-hamburg.de Sat May 9 05: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 27AD83A69A1 for ; Sat, 9 May 2009 05:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.575 X-Spam-Level: X-Spam-Status: No, score=-0.575 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_40=-0.185, 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 lNDqgdHfY5J8 for ; Sat, 9 May 2009 05:35:24 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 00E463A67D8 for ; Sat, 9 May 2009 05:35:22 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178144110.adsl.alicedsl.de ([85.178.144.110] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1M2lnO-000Or8-Nm for multimob@ietf.org; Sat, 09 May 2009 14:36:50 +0200 Message-ID: <4A0578DD.1080304@informatik.haw-hamburg.de> Date: Sat, 09 May 2009 14:36:45 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Subject: [multimob] Proposal for a work item agenda 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, 09 May 2009 12:35:25 -0000 Hi all, as discussed yesterday on the teleconference, a proposal for a work item agenda has been worked out. And here it is: Proposal for Multimob roadmap 1. MLD over Wireless: BCP document on deployment of RFC 2710 and RFC 3810 with configurations optimized for wireless. 2. MLD extensions for enhanced mobile multicast services: Experimental / standards track document on additional MLD functions that improve multicast in the mobile regime (e.g., listener hold, etc.). 3. Multicast listener deployment for multihomed mobile nodes: BCP document on multicast operations in the presence of multihoming 4. Multicast listener deployment in PMIPv6: BCP document to describe minimal deployment for PMIPv6 remote subscription. 5. Multicast listener optimizations in PMIPv6 (+ extensions) domains: Experimental / standards track document on additional multicast + mobility functions for traffic optimization in PMIPv6 and emerging extensions. 6. Multicast listener extensions for MIPv6 Fast Handovers: Experimental / standards track document on multicast extensions in FMIPv6. 7. Multicast listener extensions for Hierarchical MIPv6: Experimental / standards track document on multicast extensions in HMIPv6. 8. Transparent multicast transmission from mobile nodes: Experimental / standards track document for a basic mobile multicast sender support. As we want to converge rapidly to meet BoF deadlines, please comment sprightly :-) Best wishes from sunny Europe, 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 phdgang@gmail.com Sun May 10 07:49:47 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9813A6C7E for ; Sun, 10 May 2009 07:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.352 X-Spam-Level: *** X-Spam-Status: No, score=3.352 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UNxrvX33Klk for ; Sun, 10 May 2009 07:49:46 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id BE72D3A6AE8 for ; Sun, 10 May 2009 07:49:45 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so1667116rvb.49 for ; Sun, 10 May 2009 07:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=LbKPzmGweiE+kX9TWVL7Ch4ZFfeSu5u/addhBv83jOg=; b=cp4PbyNzaa9U7LP0rSIdLInhSe71ilbvpxf356Jr0kbDvA6Ua6YIi1lHjb4jozZcY7 fvUven9fck+Z9yINQ9k1jCJM0Csa+8WZ4SMxniJ/aw9NTHxlbAoriFK2x/iqvAhvMyR6 0byScJWfq5WCers78SX6G7TzAHmMWHafDhFNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fUOwai2FG1fSRMn3AapnRhtm3KUwWOiQcf6OfuXQgp074JXhzTJCwiAVWWsKH2rP57 SSfG9iMeRa4diOU+KjrogVNA31q6hTJH6+jmF3wNjk/beprM7iNpeT+0MJEaNoVeEMCN BpVl4zIt53QtOMIbc+WzcQgC432bwDZGGl8d4= MIME-Version: 1.0 Received: by 10.141.98.13 with SMTP id a13mr2394862rvm.5.1241967073813; Sun, 10 May 2009 07:51:13 -0700 (PDT) In-Reply-To: <4A0578DD.1080304@informatik.haw-hamburg.de> References: <4A0578DD.1080304@informatik.haw-hamburg.de> Date: Sun, 10 May 2009 22:51:13 +0800 Message-ID: <36ba02b00905100751r40ce390p142721344545ca82@mail.gmail.com> From: =?GB2312?B?s8K41Q==?= To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=000e0cd1b69441e5b304698ffe0b Cc: multimob@ietf.org Subject: Re: [multimob] Proposal for a work item agenda X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2009 14:49:47 -0000 --000e0cd1b69441e5b304698ffe0b Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear all, I want to clarify one thing in work item agenda. With regard to No.6, it should be PMIPv6 Fast handover, other than MIPv6 fast handover. Thanks. Chen Gang China Mobile 2009/5/9 Thomas C. Schmidt > Hi all, > > as discussed yesterday on the teleconference, a proposal for a work item > agenda has been worked out. > > And here it is: > > Proposal for Multimob roadmap > > > 1. MLD over Wireless: BCP document on deployment of RFC 2710 and RFC 381= 0 > with configurations optimized for wireless. > > 2. MLD extensions for enhanced mobile multicast services: Experimental / > standards track document on additional MLD functions that improve > multicast > in the mobile regime (e.g., listener hold, etc.). > > 3. Multicast listener deployment for multihomed mobile nodes: BCP docume= nt > on > multicast operations in the presence of multihoming > > 4. Multicast listener deployment in PMIPv6: BCP document to describe > minimal > deployment for PMIPv6 remote subscription. > > 5. Multicast listener optimizations in PMIPv6 (+ extensions) domains: > Experimental / standards track document on additional multicast + > mobility functions for traffic optimization in PMIPv6 and emerging > extensions. > > 6. Multicast listener extensions for MIPv6 Fast Handovers: Experimental > / standards track document on multicast extensions in FMIPv6. > > 7. Multicast listener extensions for Hierarchical MIPv6: Experimental > / standards track document on multicast extensions in HMIPv6. > > 8. Transparent multicast transmission from mobile nodes: Experimental > / standards track document for a basic mobile multicast sender support= . > > > As we want to converge rapidly to meet BoF deadlines, please comment > sprightly :-) > > Best wishes from sunny Europe, > > Thomas > > -- > > Prof. Dr. Thomas C. Schmidt > =A1=E3 Hamburg University of Applied Sciences Berliner = Tor 7 =A1=E3 > =A1=E3 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Ge= rmany =A1=E3 > =A1=E3 http://www.haw-hamburg.de/inet Fon: +49-40-42875= -8452 > =A1=E3 > =A1=E3 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875= -8409 > =A1=E3 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > --=20 =B3=C2=B8=D5 phdgang@gmail.com --000e0cd1b69441e5b304698ffe0b Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Dear all,
 
I want to clarify one thing in work item agenda.
With regard to No.6, it should be PMIPv6 Fast handover, othe= r than MIPv6 fast handover.
Thanks.
 
Chen Gang
China Mobile

2009/5/9 Thomas C. Schmidt <= ;schmidt@informatik.ha= w-hamburg.de>
Hi all,

as discussed yest= erday on the teleconference, a proposal for a work item agenda has been wor= ked out.

And here it is:

 Proposal for Multimob roadmap


&= nbsp;1. MLD over Wireless: BCP document on deployment of RFC 2710 and RFC 3= 810
   with configurations optimized for wireless.

&nbs= p;2. MLD extensions for enhanced mobile multicast services: Experimental /<= br>    standards track document on additional MLD functions that impr= ove multicast
   in the mobile regime (e.g., listener hold, et= c.).

 3. Multicast listener deployment for multihomed mobile no= des: BCP document on
   multicast operations in the presence of multihoming

&nb= sp;4. Multicast listener deployment in PMIPv6: BCP document to describe min= imal
   deployment for PMIPv6 remote subscription.

&nbs= p;5. Multicast listener optimizations in PMIPv6 (+ extensions) domains:
   Experimental / standards track document on additional multicas= t +
   mobility functions for traffic optimization in PMIPv6 a= nd emerging
   extensions.

 6. Multicast listener = extensions for MIPv6 Fast Handovers:  Experimental
   / standards track document on multicast extensions in FMIPv6.<= br>
 7. Multicast listener extensions for Hierarchical MIPv6:  = ;Experimental
   / standards track document on multicast exten= sions in HMIPv6.

 8. Transparent multicast transmission from mo= bile nodes: Experimental
   / standards track document for a basic mobile multicast sender= support.


As we want to converge rapidly to meet BoF deadlines, = please comment sprightly :-)

Best wishes from sunny Europe,

T= homas

--

Prof. Dr. Thomas C. Schmidt
=A1=E3 Hamburg University of = Applied Sciences                 &n= bsp; Berliner Tor 7 =A1=E3
=A1=E3 Dept. Informatik, Internet Technologie= s Group    20099 Hamburg, Germany =A1=E3
=A1=E3 http://www.haw-hamburg.de/in= et                   Fon: = +49-40-42875-8452 =A1=E3
=A1=E3 http://www.informatik.haw-hamburg.de/~schmidt    Fax:= +49-40-42875-8409 =A1=E3
______________________________________________= _
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob
<= /div>


--
=B3=C2=B8=D5
= phdgang@gmail.com
--000e0cd1b69441e5b304698ffe0b-- From asaeda@sfc.wide.ad.jp Sun May 10 08:58: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 8EAFE3A6962 for ; Sun, 10 May 2009 08:58:28 -0700 (PDT) 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 LKLy4VaUuU1r for ; Sun, 10 May 2009 08:58:27 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id CF3573A6812 for ; Sun, 10 May 2009 08:58:27 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id B45B313D06C4 for ; Mon, 11 May 2009 00:56:56 +0900 (JST) Date: Mon, 11 May 2009 00:59:55 +0900 (JST) Message-Id: <20090511.005955.156589717.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <4A0578DD.1080304@informatik.haw-hamburg.de> References: <4A0578DD.1080304@informatik.haw-hamburg.de> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Proposal for a work item agenda X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2009 15:58:28 -0000 Hi, > 1. MLD over Wireless: BCP document on deployment of RFC 2710 and RFC 3810 > with configurations optimized for wireless. RFC2710 is not explicitly obsolete, but currently no necessary to adapt any spec mentioned in rfc2710. Hence I recommend to describe, "... deployment of RFC3810 with ..." or "... deployment of MLDv2 (or LW-MLDv2) with ...". > 4. Multicast listener deployment in PMIPv6: BCP document to describe minimal > deployment for PMIPv6 remote subscription. > > 5. Multicast listener optimizations in PMIPv6 (+ extensions) domains: > Experimental / standards track document on additional multicast + > mobility functions for traffic optimization in PMIPv6 and emerging > extensions. What is the major difference between 4 and 5? 5 includes "local subscription" but 4 does not? What is the minimal deployment you expexted? Anyway, PBU with multicast extension and/or CT extension is necessary even with remote subscription. Although I need to know the conditon of the minimal deployment described in 4, in my current thought, dividing 4 and 5 is not very useful. Regards, -- Hitoshi Asaeda From schmidt@informatik.haw-hamburg.de Sun May 10 09:27: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 550673A6BBA for ; Sun, 10 May 2009 09:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp0Yszx2t4AY for ; Sun, 10 May 2009 09:27:25 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 19D393A69BF for ; Sun, 10 May 2009 09:27:25 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178187192.adsl.alicedsl.de ([85.178.187.192] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1M3BtW-000Dx2-6U; Sun, 10 May 2009 18:28:54 +0200 Message-ID: <4A0700C3.3090805@informatik.haw-hamburg.de> Date: Sun, 10 May 2009 18:28:51 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?GB2312?B?s8K41Q==?= References: <4A0578DD.1080304@informatik.haw-hamburg.de> <36ba02b00905100751r40ce390p142721344545ca82@mail.gmail.com> In-Reply-To: <36ba02b00905100751r40ce390p142721344545ca82@mail.gmail.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] Proposal for a work item agenda X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2009 16:27:26 -0000 Hi Chen, ³Â¸Õ wrote: > I want to clarify one thing in work item agenda. > With regard to No.6, it should be PMIPv6 Fast handover, other than MIPv6 > fast handover. I would not see a reason why FMIPv6 / PMIPv6 should be mutually exclusive. One might want to add Fast PMIPv6, but I guess there is point in taking FMIPv6 off the agenda. Best regards, Thomas > 2009/5/9 Thomas C. Schmidt > > > Hi all, > > as discussed yesterday on the teleconference, a proposal for a work > item agenda has been worked out. > > And here it is: > > Proposal for Multimob roadmap > > > 1. MLD over Wireless: BCP document on deployment of RFC 2710 and > RFC 3810 > with configurations optimized for wireless. > > 2. MLD extensions for enhanced mobile multicast services: > Experimental / > standards track document on additional MLD functions that improve > multicast > in the mobile regime (e.g., listener hold, etc.). > > 3. Multicast listener deployment for multihomed mobile nodes: BCP > document on > multicast operations in the presence of multihoming > > 4. Multicast listener deployment in PMIPv6: BCP document to > describe minimal > deployment for PMIPv6 remote subscription. > > 5. Multicast listener optimizations in PMIPv6 (+ extensions) domains: > Experimental / standards track document on additional multicast + > mobility functions for traffic optimization in PMIPv6 and emerging > extensions. > > 6. Multicast listener extensions for MIPv6 Fast Handovers: > Experimental > / standards track document on multicast extensions in FMIPv6. > > 7. Multicast listener extensions for Hierarchical MIPv6: Experimental > / standards track document on multicast extensions in HMIPv6. > > 8. Transparent multicast transmission from mobile nodes: Experimental > / standards track document for a basic mobile multicast sender > support. > > > As we want to converge rapidly to meet BoF deadlines, please comment > sprightly :-) > > Best wishes from sunny Europe, > > 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 > > > > > -- > ³Â¸Õ > phdgang@gmail.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 schmidt@informatik.haw-hamburg.de Sun May 10 10:14: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 01A5A3A6B97 for ; Sun, 10 May 2009 10:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.831 X-Spam-Level: X-Spam-Status: No, score=-0.831 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 hbeW0wakDfzA for ; Sun, 10 May 2009 10:14:23 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id F2D1A3A6B3E for ; Sun, 10 May 2009 10:14:21 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178187192.adsl.alicedsl.de ([85.178.187.192] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1M3Ccw-000O3A-FT; Sun, 10 May 2009 19:15:50 +0200 Message-ID: <4A070BC0.8090102@informatik.haw-hamburg.de> Date: Sun, 10 May 2009 19:15:44 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hitoshi Asaeda References: <4A0578DD.1080304@informatik.haw-hamburg.de> <20090511.005955.156589717.asaeda@sfc.wide.ad.jp> In-Reply-To: <20090511.005955.156589717.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] Proposal for a work item agenda X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2009 17:14:24 -0000 Hi Hitoshi, Hitoshi Asaeda wrote: >> 1. MLD over Wireless: BCP document on deployment of RFC 2710 and RFC 3810 >> with configurations optimized for wireless. > > RFC2710 is not explicitly obsolete, but currently no necessary to > adapt any spec mentioned in rfc2710. Hence I recommend to describe, > "... deployment of RFC3810 with ..." or "... deployment of MLDv2 (or > LW-MLDv2) with ...". > Personally, I'm not a friend to restrict views to SSM unless there is a convincing need for it. Currently, we have quite a number of ASM-based IPTV deployments in Europe. So I'd like to argue that MLDv1 aspects should be addressed up to the point at which source-specific restrictions become vital. (Currently I don't see many of those). >> 4. Multicast listener deployment in PMIPv6: BCP document to describe minimal >> deployment for PMIPv6 remote subscription. >> >> 5. Multicast listener optimizations in PMIPv6 (+ extensions) domains: >> Experimental / standards track document on additional multicast + >> mobility functions for traffic optimization in PMIPv6 and emerging >> extensions. > > What is the major difference between 4 and 5? > 5 includes "local subscription" but 4 does not? > What is the minimal deployment you expexted? > This is meant as a simple formal division, at first: 4. is a BCP, thus giving a use / deployment guide of combining solutions standardized elsewhere. In the current model, this will lead to easy, but somewhat inefficient point-to-point transmissions. 5. would address real protocol extensions and be open for additional PMIP work as expected from NETEXP or so. The division is intended to produce a document at first, that is not endangered in tampering with PMIPv6 protocol operations (which appear somewhat counter-intuitive for group communication). It would be easier to complete, as well. 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 phdgang@gmail.com Sun May 10 19:28:47 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4410D3A6F0F for ; Sun, 10 May 2009 19:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.352 X-Spam-Level: *** X-Spam-Status: No, score=3.352 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7P-val8zbAX for ; Sun, 10 May 2009 19:28:46 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id F186F3A6F12 for ; Sun, 10 May 2009 19:28:45 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so1765304rvb.49 for ; Sun, 10 May 2009 19:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=DTJykF1gE+o9LztaBFY1FTKVv4gljgGG1BxP7vkVFWY=; b=WejOZTCydUTDp61blsKWeFd4NXvwwSRL3xa11Z5hYfcWY5CRtYj6Cotzok0r+2Vtvh uZ1/QW6Ci4/xUnx1rqntzfqQKg/o92eegdNvzfmHz9r0pRHT16X98129GMQq237C6SZW zwITVquzH0hPNtApnHKlaSHHZqE1Yz25TEf9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=viBTRB8gbJQQXJyq5wsIYznOZ5pMfOfVw/2QQWLS2qmTnpD05cZEL4py/oYuFl1Fbl OFLKV7edXou4Q96NzVMcm8gDi2UcCEDOlXCURfvhZkVxrwROYG0RJyjmmaA/VplTFPrk 25NeD+RMq9N0M3eB+b07Cj1r67EaJFuZt7Pjk= MIME-Version: 1.0 Received: by 10.141.114.19 with SMTP id r19mr2586539rvm.135.1242009014675; Sun, 10 May 2009 19:30:14 -0700 (PDT) In-Reply-To: <4A0700C3.3090805@informatik.haw-hamburg.de> References: <4A0578DD.1080304@informatik.haw-hamburg.de> <36ba02b00905100751r40ce390p142721344545ca82@mail.gmail.com> <4A0700C3.3090805@informatik.haw-hamburg.de> Date: Mon, 11 May 2009 10:30:14 +0800 Message-ID: <36ba02b00905101930m2ce114d7j5d10fd08a14ff81f@mail.gmail.com> From: =?GB2312?B?s8K41Q==?= To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=000e0cd29cb020aba2046999c228 Cc: multimob@ietf.org Subject: Re: [multimob] Proposal for a work item agenda 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, 11 May 2009 02:28:47 -0000 --000e0cd29cb020aba2046999c228 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Thomas, There is not intention to take FMIPv6 off the agenda. I want to clarify information I have mentioned during the teleconference last week, because we are preparing draft related to FPMIPv6 for 75th IETF. We can put both FMIPv6/FPMIPv6 into agenda, if you think that is necessary. BRs Chen Gang 2009/5/11 Thomas C. Schmidt > Hi Chen, > > =B3=C2=B8=D5 wrote: > > > I want to clarify one thing in work item agenda. > > With regard to No.6, it should be PMIPv6 Fast handover, other than MIPv= 6 > > fast handover. > > I would not see a reason why FMIPv6 / PMIPv6 should be mutually > exclusive. One might want to add Fast PMIPv6, but I guess there is point > in taking FMIPv6 off the agenda. > > Best regards, > > Thomas > > > > 2009/5/9 Thomas C. Schmidt > > > > > > Hi all, > > > > as discussed yesterday on the teleconference, a proposal for a work > > item agenda has been worked out. > > > > And here it is: > > > > Proposal for Multimob roadmap > > > > > > 1. MLD over Wireless: BCP document on deployment of RFC 2710 and > > RFC 3810 > > with configurations optimized for wireless. > > > > 2. MLD extensions for enhanced mobile multicast services: > > Experimental / > > standards track document on additional MLD functions that improv= e > > multicast > > in the mobile regime (e.g., listener hold, etc.). > > > > 3. Multicast listener deployment for multihomed mobile nodes: BCP > > document on > > multicast operations in the presence of multihoming > > > > 4. Multicast listener deployment in PMIPv6: BCP document to > > describe minimal > > deployment for PMIPv6 remote subscription. > > > > 5. Multicast listener optimizations in PMIPv6 (+ extensions) > domains: > > Experimental / standards track document on additional multicast = + > > mobility functions for traffic optimization in PMIPv6 and emergi= ng > > extensions. > > > > 6. Multicast listener extensions for MIPv6 Fast Handovers: > > Experimental > > / standards track document on multicast extensions in FMIPv6. > > > > 7. Multicast listener extensions for Hierarchical MIPv6: > Experimental > > / standards track document on multicast extensions in HMIPv6. > > > > 8. Transparent multicast transmission from mobile nodes: > Experimental > > / standards track document for a basic mobile multicast sender > > support. > > > > > > As we want to converge rapidly to meet BoF deadlines, please commen= t > > sprightly :-) > > > > Best wishes from sunny Europe, > > > > Thomas > > > > -- > > > > Prof. Dr. Thomas C. Schmidt > > =A1=E3 Hamburg University of Applied Sciences Ber= liner > > Tor 7 =A1=E3 > > =A1=E3 Dept. Informatik, Internet Technologies Group 20099 Hambu= rg, > > Germany =A1=E3 > > =A1=E3 http://www.haw-hamburg.de/inet Fon: > > +49-40-42875-8452 =A1=E3 > > =A1=E3 http://www.informatik.haw-hamburg.de/~schmidt Fax: > > +49-40-42875-8409 =A1=E3 > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > > > > > > > > > > -- > > =B3=C2=B8=D5 > > phdgang@gmail.com > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > > -- > > Prof. Dr. Thomas C. Schmidt > =A1=E3 Hamburg University of Applied Sciences Berliner = Tor 7 =A1=E3 > =A1=E3 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Ge= rmany =A1=E3 > =A1=E3 http://www.haw-hamburg.de/inet Fon: +49-40-42875= -8452 > =A1=E3 > =A1=E3 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875= -8409 > =A1=E3 > --=20 =B3=C2=B8=D5 phdgang@gmail.com --000e0cd29cb020aba2046999c228 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi Thomas,
 

The= re is not intention to take FMIPv6 off the agenda.

I w= ant to clarify information I have mentioned during the teleconference last = week, because we are preparing draft related to FPMIPv6 for 75th= IETF.

We = can put both FMIPv6/FPMIPv6 into agenda, if you think that is necessary.

 

BRs=

 

&nb= sp;

C= hen Gang
<= /span> 

 

 


2009/5/11 Thomas C. Schmidt &l= t;schmidt@informatik.h= aw-hamburg.de>
Hi Chen,

=B3=C2=B8=D5 wrote:

> I want to clarify one= thing in work item agenda.
> With regard to No.6, it should be PMIPv= 6 Fast handover, other than MIPv6
> fast handover.

I wou= ld not see a reason why FMIPv6 / PMIPv6 should be mutually
exclusive. One might want to add Fast PMIPv6, but I guess there is pointin taking FMIPv6 off the agenda.

Best regards,

Thomas


> 2009/5/9 Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de
> <mailto:schmidt@informatik.haw-hamburg.de>>
>
>     Hi all,
>
>  =   as discussed yesterday on the teleconference, a proposal for a work=
>     item agenda has been worked out.
>
> &nb= sp;   And here it is:
>
>      Proposal for Multimob roadmap
>
>
&= gt;      1. MLD over Wireless: BCP document on deployment of= RFC 2710 and
>     RFC 3810
>       &= nbsp;with configurations optimized for wireless.
>
>      2. MLD extensions for enhanced mobile multicast se= rvices:
>     Experimental /
>       &= nbsp;standards track document on additional MLD functions that improve
&= gt;     multicast
>        in the mobil= e regime (e.g., listener hold, etc.).
>
>      3. Multicast listener deployment for multi= homed mobile nodes: BCP
>     document on
>   &n= bsp;    multicast operations in the presence of multihoming
&g= t;
>      4. Multicast listener deployment in PMIPv6: = BCP document to
>     describe minimal
>        depl= oyment for PMIPv6 remote subscription.
>
>      = 5. Multicast listener optimizations in PMIPv6 (+ extensions) domains:
&g= t;        Experimental / standards track document on ad= ditional multicast +
>        mobility functions for traffic optimization= in PMIPv6 and emerging
>        extensions.
&= gt;
>      6. Multicast listener extensions for MIPv6 = Fast Handovers:
>      Experimental
>   &nb= sp;    / standards track document on multicast extensions in FMIP= v6.
>
>      7. Multicast listener extensions for Hiera= rchical MIPv6:  Experimental
>        / stan= dards track document on multicast extensions in HMIPv6.
>
> &nb= sp;    8. Transparent multicast transmission from mobile nodes: E= xperimental
>        / standards track document for a basic mobi= le multicast sender
>     support.
>
>
> =     As we want to converge rapidly to meet BoF deadlines, please = comment
>     sprightly :-)
>
>     Best wishes from sunny Europe,
>
> &= nbsp;   Thomas
>
>     --
>
>  =   Prof. Dr. Thomas C. Schmidt
>     =A1=E3 Hamburg Un= iversity of Applied Sciences             &nbs= p;     Berliner
>     Tor 7 =A1=E3
>     =A1=E3 Dept. Informat= ik, Internet Technologies Group    20099 Hamburg,
>   =   Germany =A1=E3
>     =A1=E3 http://www.haw-hamburg.de/inet &nb= sp;                 Fon:
>     +49-40-42875-8452 =A1=E3
>     =A1=E3 h= ttp://www.informatik.haw-hamburg.de/~schmidt    Fax:
> =     +49-40-42875-8409 =A1=E3
>     ______________= _________________________________
>     multimob mailing list
>     = multimob@ietf.org <mailto:multimob@ietf.org>
>     https://www.ietf.org/mailman/listinf= o/multimob
>
>
>
>
> --
> =B3=C2=B8= =D5
> phdgang@gmail.com <mailto:phdgang@gmail.com>=
>
>
> ------------------------------------------------------= ------------------
>
> ________________________________________= _______
> multimob mailing list
> multimob@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/multimob

= --

Prof. Dr. Thomas C. Schmidt
=A1=E3 Hamburg University = of Applied Sciences                =   Berliner Tor 7 =A1=E3
=A1=E3 Dept. Informatik, Internet Technolo= gies Group    20099 Hamburg, Germany =A1=E3
=A1=E3 http://www.haw-hamburg.de= /inet                   Fo= n: +49-40-42875-8452 =A1=E3
=A1=E3 http://www.informatik.haw-hamburg.de/~schmidt    Fax:= +49-40-42875-8409 =A1=E3



--
=B3=C2=B8=D5
= phdgang@gmail.com
--000e0cd29cb020aba2046999c228-- From asaeda@sfc.wide.ad.jp Sun May 10 20:51: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 28AE53A69EF for ; Sun, 10 May 2009 20:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.947 X-Spam-Level: ** X-Spam-Status: No, score=2.947 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_20=-0.74, 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 NRChheL3q3RE for ; Sun, 10 May 2009 20:51:08 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 479453A69E8 for ; Sun, 10 May 2009 20:51:04 -0700 (PDT) Received: from localhost (dhcp-143-215.sfc.wide.ad.jp [203.178.143.215]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id B7E6813D06C4 for ; Mon, 11 May 2009 12:49:30 +0900 (JST) Date: Mon, 11 May 2009 12:52:30 +0900 (JST) Message-Id: <20090511.125230.205320776.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <4A070BC0.8090102@informatik.haw-hamburg.de> References: <4A0578DD.1080304@informatik.haw-hamburg.de> <20090511.005955.156589717.asaeda@sfc.wide.ad.jp> <4A070BC0.8090102@informatik.haw-hamburg.de> X-Mailer: Mew version 6.1 on Emacs 22.2.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Proposal for a work item agenda 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, 11 May 2009 03:51:09 -0000 Thomas, > >> 1. MLD over Wireless: BCP document on deployment of RFC 2710 and RFC 3810 > >> with configurations optimized for wireless. > > RFC2710 is not explicitly obsolete, but currently no necessary to > > adapt any spec mentioned in rfc2710. Hence I recommend to describe, > > "... deployment of RFC3810 with ..." or "... deployment of MLDv2 (or > > LW-MLDv2) with ...". > > Personally, I'm not a friend to restrict views to SSM unless there > is a convincing need for it. Currently, we have quite a > number of ASM-based IPTV deployments in Europe. So I'd like > to argue that MLDv1 aspects should be addressed up to the > point at which source-specific restrictions become > vital. (Currently I don't see many of those). MLDv2 supprots both ASM and SSM. No necessity to explicitly focus on MLDv1 anymore. > >> 4. Multicast listener deployment in PMIPv6: BCP document to describe minimal > >> deployment for PMIPv6 remote subscription. > >> > >> 5. Multicast listener optimizations in PMIPv6 (+ extensions) domains: > >> Experimental / standards track document on additional multicast + > >> mobility functions for traffic optimization in PMIPv6 and emerging > >> extensions. > > What is the major difference between 4 and 5? > > 5 includes "local subscription" but 4 does not? > > What is the minimal deployment you expexted? > > This is meant as a simple formal division, at first: 4. is a BCP, > thus giving a use / deployment guide of combining solutions > standardized elsewhere. In the current model, this will lead > to easy, but somewhat inefficient point-to-point > transmissions. If we need to describe such issues or situations, the draft should be explicitly categorized as "problem statement" or "requirement" draft. And if it just takes a role of some "guidance", it should be intended as informational RFC. > 5. would address real protocol extensions and be open for additional > PMIP work as expected from NETEXP or so. ?? Is there any aspect to give some task to NETEXT for multicast support? (I assume s/NETEXP/NETEXT.) Does this multimob group tend to PMIP extension for multicast support? > The division is intended to produce a document at first, that is not > endangered in tampering with PMIPv6 protocol operations (which > appear somewhat counter-intuitive for group communication). It would > be easier to complete, as well. If our target is to support pure *IP multicast" in PMIP domain, protocol modification is definitely needed. People may say that IP multicast services have already provided in their PMIP domains. I expect their services wouldn't be only with IP multicast, but with a multicast service implementation by some architectural modification or configuration. If describing such *service* implementation (which would be without any protocol modification), you must explicitly say so and should not include remote subscription or some common words in the text. Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Sun May 10 22:37: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 2B7BE3A6EF3 for ; Sun, 10 May 2009 22:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.271 X-Spam-Level: *** X-Spam-Status: No, score=3.271 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_50=0.001, 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 6BFk2VVAcvX9 for ; Sun, 10 May 2009 22:37:24 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 781863A6EE2 for ; Sun, 10 May 2009 22:37:24 -0700 (PDT) Received: from localhost (dhcp-143-215.sfc.wide.ad.jp [203.178.143.215]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 3431E13D06C4 for ; Mon, 11 May 2009 14:35:49 +0900 (JST) Date: Mon, 11 May 2009 14:38:52 +0900 (JST) Message-Id: <20090511.143852.106273584.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <20090511.125230.205320776.asaeda@sfc.wide.ad.jp> References: <20090511.005955.156589717.asaeda@sfc.wide.ad.jp> <4A070BC0.8090102@informatik.haw-hamburg.de> <20090511.125230.205320776.asaeda@sfc.wide.ad.jp> X-Mailer: Mew version 6.1 on Emacs 22.2.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Proposal for a work item agenda 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, 11 May 2009 05:37:25 -0000 > > 5. would address real protocol extensions and be open for additional > > PMIP work as expected from NETEXP or so. > > ?? > Is there any aspect to give some task to NETEXT for multicast support? > (I assume s/NETEXP/NETEXT.) > Does this multimob group tend to PMIP extension for multicast support? I mean, I think this multimob group has the mission to take care of any PMIP extension for multicast support, while NETEXT won't. -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Mon May 11 13:56: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 220DF28C16A for ; Mon, 11 May 2009 13:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.417 X-Spam-Level: X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJi14mrf0-ot for ; Mon, 11 May 2009 13:56:21 -0700 (PDT) Received: from n6.bullet.re3.yahoo.com (n6.bullet.re3.yahoo.com [68.142.237.91]) by core3.amsl.com (Postfix) with SMTP id 917203A68E3 for ; Mon, 11 May 2009 13:56:21 -0700 (PDT) Received: from [68.142.230.29] by n6.bullet.re3.yahoo.com with NNFMP; 11 May 2009 20:57:51 -0000 Received: from [67.195.9.82] by t2.bullet.re2.yahoo.com with NNFMP; 11 May 2009 20:57:50 -0000 Received: from [67.195.9.100] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 11 May 2009 20:57:50 -0000 Received: from [127.0.0.1] by omp104.mail.gq1.yahoo.com with NNFMP; 11 May 2009 20:57:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 935819.21487.bm@omp104.mail.gq1.yahoo.com Received: (qmail 48177 invoked by uid 60001); 11 May 2009 20:57:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242075469; bh=QWsx9bvhCHd0ZCpkMErgbWdsaM+5hDB0EMFVHb8XF4s=; 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=HkMAgFQwhLpz1DZtkghsz5knp1JgVYNx0P2KKf6a0Z6y/R+UboxI/ecInkFxKd15gi449UV9y2Z+uAh4OiquCcXR4SPc3vItNk8ZhiWdO65Lc06UrBJeQT7cuSepcns5tUAqfSaa+hpjm9AzuTGfJ2Q0GaCKBBaRyLqSk+/WNnI= 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=fCtwEARIA+0ja/pMRAAXEmpndt1ETuqj3QbvHc2osEuslXBM9U6k3Ai71LKoxYzCi7EiXlcfBX01WY150/8KzBpNOkGXjDrpDQLU1lHof37NHXQdX71lw33wKLrsgbADBnFeNwSTUjol0GWzSvLgvCbxQ2P9oBfOH+KIWlTOLAY=; Message-ID: <928976.47819.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: sFg0UBYVM1mnDnvx8ULfSmNkZatt80RxgGfKp_7mbBNRVDSCNZygNCxBWM1_SLvLOh5KIlBHmizpNSCTKhaYvc1B6cGU.zQntdSG_Ffubvx5bofO57lnMYNizrypCaj36c91o6vuu5TvBMJCKYm5f60S2aaOI1MMLh0puv1UXsIUUQPrdAfaufk3RuVULzv7RUqMSXItRfzexg_YO1wgaz6sdD7DKn.IzlOtL9LxnQWJRr4o1fqRZnr1YaJYljyRCLqpD8CpSrPHMc.naPQYDrySSiLY7xBPC9oM6u.W57K.c_EhDpgfOH7RxNqU_.sW1K7vo1FeQJto4PuQvFUiFAq1PzGpe5jbma27UA-- Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Mon, 11 May 2009 13:57:49 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <4A0578DD.1080304@informatik.haw-hamburg.de> Date: Mon, 11 May 2009 13:57:49 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org In-Reply-To: <4A0578DD.1080304@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2114276281-1242075469=:47819" Subject: Re: [multimob] Proposal for a work item agenda 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, 11 May 2009 20:56:23 -0000 --0-2114276281-1242075469=:47819 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello all,=0A=A0 This proposal will be discussed in Thursday's call. Please= post your opinion especially if you are not attending the call.=0A=0ARegar= ds,=0A=0ABehcet=0A=0A=0A________________________________=0AFrom: Thomas C. = Schmidt =0ATo: multimob@ietf.org=0ASent:= Saturday, May 9, 2009 7:36:45 AM=0ASubject: [multimob] Proposal for a work= item agenda=0A=0AHi all,=0A=0Aas discussed yesterday on the teleconference= , a proposal for a work item agenda has been worked out.=0A=0AAnd here it i= s:=0A=0A=A0 Proposal for Multimob roadmap=0A=0A=0A1. MLD over Wireless: BCP= document on deployment of RFC 2710 and RFC 3810=0A=A0 =A0 with configurati= ons optimized for wireless.=0A=0A2. MLD extensions for enhanced mobile mult= icast services: Experimental /=0A=A0 =A0 standards track document on additi= onal MLD functions that improve multicast=0A=A0 =A0 in the mobile regime (e= ..g., listener hold, etc.).=0A=0A3. Multicast listener deployment for multih= omed mobile nodes: BCP document on=0A=A0 =A0 multicast operations in the pr= esence of multihoming=0A=0A4. Multicast listener deployment in PMIPv6: BCP = document to describe minimal=0A=A0 =A0 deployment for PMIPv6 remote subscri= ption.=0A=0A5. Multicast listener optimizations in PMIPv6 (+ extensions) do= mains:=0A=A0 =A0 Experimental / standards track document on additional mult= icast +=0A=A0 =A0 mobility functions for traffic optimization in PMIPv6 and= emerging=0A=A0 =A0 extensions.=0A=0A6. Multicast listener extensions for M= IPv6 Fast Handovers:=A0 Experimental=0A=A0 =A0 / standards track document o= n multicast extensions in FMIPv6.=0A=0A7. Multicast listener extensions for= Hierarchical MIPv6:=A0 Experimental=0A=A0 =A0 / standards track document o= n multicast extensions in HMIPv6.=0A=0A8. Transparent multicast transmissio= n from mobile nodes: Experimental=0A=A0 =A0 / standards track document for = a basic mobile multicast sender support.=0A=0A=0AAs we want to converge rap= idly to meet BoF deadlines, please comment sprightly :-)=0A=0ABest wishes f= rom sunny Europe,=0A=0AThomas=0A=0A-- =0AProf. Dr. Thomas C. Schmidt=0A=B0 = Hamburg University of Applied Sciences=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 B= erliner 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://www.inf= ormatik.haw-hamburg.de/~schmidt=A0 =A0 Fax: +49-40-42875-8409 =B0=0A_______= ________________________________________=0Amultimob mailing list=0Amultimob= @ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/multimob=0A=0A=0A=0A = --0-2114276281-1242075469=:47819 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all,
=0A
  This proposal will be d= iscussed in Thursday's call. Please post your opinion especially if you are= not attending the call.
=0A
Regards,
=0A
=  
=0A
Behcet
=0A
=0A=
=0AFrom: Thoma= s C. Schmidt <schmidt@informatik.haw-hamburg.de>
To: multimob@ietf.org
Sent: Saturday, May 9, 2009 7:36:45 AM
<= SPAN style=3D"FONT-WEIGHT: bold">Subject: [multimob] Proposal fo= r a work item agenda

Hi all,

as discussed yesterday on= the teleconference, a proposal for a work item agenda has been worked out.=

And here it is:

  Proposal for Multimob roadmap

=
1. MLD over Wireless: BCP document on deployment of RFC 2710 and RFC 38= 10
    with configurations optimized for wireless.

2. M= LD extensions for enhanced mobile multicast services: Experimental /
&nb= sp;   standards track document on additional MLD functions that improv= e multicast
    in the mobile regime (e.g., listener hold, etc= ..).

3. Multicast listener deployment for multihomed mobile nodes: BCP document on=
    multicast operations in the presence of multihoming
4. Multicast listener deployment in PMIPv6: BCP document to describe mini= mal
    deployment for PMIPv6 remote subscription.

5. M= ulticast listener optimizations in PMIPv6 (+ extensions) domains:
 =   Experimental / standards track document on additional multicast +    mobility functions for traffic optimization in PMIPv6 and e= merging
    extensions.

6. Multicast listener extension= s for MIPv6 Fast Handovers:  Experimental
    / standards= track document on multicast extensions in FMIPv6.

7. Multicast list= ener extensions for Hierarchical MIPv6:  Experimental
   = / standards track document on multicast extensions in HMIPv6.

8. Tr= ansparent multicast transmission from mobile nodes: Experimental
    / standards track document for a basic mobil= e multicast sender support.


As we want to converge rapidly to me= et BoF deadlines, please comment sprightly :-)

Best wishes from sunn= y Europe,

Thomas

--
Prof. Dr. Thomas C. Schmidt
=B0 Ha= mburg University of Applied Sciences          &nbs= p;       Berliner Tor 7 =B0
=B0 Dept. Informatik, Interne= t Technologies Group    20099 Hamburg, Germany =B0
=B0 http://= www.haw-hamburg.de/inet              &nb= sp;   Fon: +49-40-42875-8452 =B0
=B0 http://www.informatik.haw-hamb= urg.de/~schmidt    Fax: +49-40-42875-8409 =B0
________________= _______________________________
multimob mailing list
multimob@ietf.or= g
https://www.ietf.org/mailman/listinfo/multimob

=0A=0A=0A=0A --0-2114276281-1242075469=:47819-- From gorry@erg.abdn.ac.uk Tue May 12 13:07: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 EF2043A69FF for ; Tue, 12 May 2009 13:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 d+CpIzluNYGX for ; Tue, 12 May 2009 13:07:43 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 976583A6E2C for ; Tue, 12 May 2009 13:07:42 -0700 (PDT) Received: from Gorry-Fairhursts-Laptop-6.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n4CK8klN001085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 12 May 2009 21:08:47 +0100 (BST) Message-ID: <4A09D74D.4030301@erg.abdn.ac.uk> Date: Tue, 12 May 2009 21:08:45 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: multimob@ietf.org References: <4A0578DD.1080304@informatik.haw-hamburg.de> <928976.47819.qm@web111411.mail.gq1.yahoo.com> In-Reply-To: <928976.47819.qm@web111411.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Subject: Re: [multimob] Proposal for a work item agenda X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 20:07:44 -0000 Looks good Thomas! - I could help with 1,2 (and have notes pending that I should type up soon). - I am not sure I understand 3 yet. - Can someone remind me how these relate to current drafts? Gorry Behcet Sarikaya wrote: > Hello all, > This proposal will be discussed in Thursday's call. Please post your > opinion especially if you are not attending the call. > Regards, > > Behcet > ------------------------------------------------------------------------ > *From:* Thomas C. Schmidt > *To:* multimob@ietf.org > *Sent:* Saturday, May 9, 2009 7:36:45 AM > *Subject:* [multimob] Proposal for a work item agenda > > Hi all, > > as discussed yesterday on the teleconference, a proposal for a work item > agenda has been worked out. > > And here it is: > > Proposal for Multimob roadmap > > > 1. MLD over Wireless: BCP document on deployment of RFC 2710 and RFC 3810 > with configurations optimized for wireless. > > 2. MLD extensions for enhanced mobile multicast services: Experimental / > standards track document on additional MLD functions that improve > multicast > in the mobile regime (e.g., listener hold, etc..). > > 3. Multicast listener deployment for multihomed mobile nodes: BCP > document on > multicast operations in the presence of multihoming > > 4. Multicast listener deployment in PMIPv6: BCP document to describe minimal > deployment for PMIPv6 remote subscription. > > 5. Multicast listener optimizations in PMIPv6 (+ extensions) domains: > Experimental / standards track document on additional multicast + > mobility functions for traffic optimization in PMIPv6 and emerging > extensions. > > 6. Multicast listener extensions for MIPv6 Fast Handovers: Experimental > / standards track document on multicast extensions in FMIPv6. > > 7. Multicast listener extensions for Hierarchical MIPv6: Experimental > / standards track document on multicast extensions in HMIPv6. > > 8. Transparent multicast transmission from mobile nodes: Experimental > / standards track document for a basic mobile multicast sender support. > > > As we want to converge rapidly to meet BoF deadlines, please comment > sprightly :-) > > Best wishes from sunny Europe, > > 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 > > > ------------------------------------------------------------------------ > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From pierrick.seite@orange-ftgroup.com Wed May 13 03:02:16 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3223A6DB9 for ; Wed, 13 May 2009 03:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 dgB7B9CerloO for ; Wed, 13 May 2009 03:02:15 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id DD8233A6C70 for ; Wed, 13 May 2009 03:02:14 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 May 2009 12:02:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 May 2009 12:02:52 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620D0905@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4A0578DD.1080304@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Proposal for a work item agenda Thread-Index: AcnQotkHOv1Y90AsT9OgoWaYS3nuawC/K7pQ References: <4A0578DD.1080304@informatik.haw-hamburg.de> From: To: , X-OriginalArrivalTime: 13 May 2009 10:02:53.0969 (UTC) FILETIME=[FB8BE010:01C9D3B1] Subject: Re: [multimob] Proposal for a work item agenda 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, 13 May 2009 10:02:16 -0000 Hi all, I agree with this list of items, it would give more consistence to = Multimob. Just one question: It is proposed Multicast listener optimizations in PMIP. However, some = of the current solution drafts are proposing extensions to PMIP, is it = out of scope of the proposed item? Regards, Pierrick > -----Message d'origine----- > De=A0: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] De = la > part de Thomas C. Schmidt > Envoy=E9=A0: samedi 9 mai 2009 14:37 > =C0=A0: multimob@ietf.org > Objet=A0: [multimob] Proposal for a work item agenda >=20 > Hi all, >=20 > as discussed yesterday on the teleconference, a proposal for a work = item > agenda has been worked out. >=20 > And here it is: >=20 > Proposal for Multimob roadmap >=20 >=20 > 1. MLD over Wireless: BCP document on deployment of RFC 2710 and RFC > 3810 > with configurations optimized for wireless. >=20 > 2. MLD extensions for enhanced mobile multicast services: = Experimental / > standards track document on additional MLD functions that improve > multicast > in the mobile regime (e.g., listener hold, etc.). >=20 > 3. Multicast listener deployment for multihomed mobile nodes: BCP > document on > multicast operations in the presence of multihoming >=20 > 4. Multicast listener deployment in PMIPv6: BCP document to describe > minimal > deployment for PMIPv6 remote subscription. >=20 > 5. Multicast listener optimizations in PMIPv6 (+ extensions) = domains: > Experimental / standards track document on additional multicast + > mobility functions for traffic optimization in PMIPv6 and = emerging > extensions. >=20 > 6. Multicast listener extensions for MIPv6 Fast Handovers: = Experimental > / standards track document on multicast extensions in FMIPv6. >=20 > 7. Multicast listener extensions for Hierarchical MIPv6: = Experimental > / standards track document on multicast extensions in HMIPv6. >=20 > 8. Transparent multicast transmission from mobile nodes: = Experimental > / standards track document for a basic mobile multicast sender > support. >=20 >=20 > As we want to converge rapidly to meet BoF deadlines, please comment > sprightly :-) >=20 > Best wishes from sunny Europe, >=20 > Thomas >=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 schmidt@informatik.haw-hamburg.de Wed May 13 03:09: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 124F93A6DB9 for ; Wed, 13 May 2009 03:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.400, 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 3CfqbTe5rXmW for ; Wed, 13 May 2009 03:08:56 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 175453A677D for ; Wed, 13 May 2009 03:08:54 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.22.26.203] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1M4BPt-000EJz-Fs; Wed, 13 May 2009 12:10:25 +0200 Message-ID: <4A0A9C8B.30609@informatik.haw-hamburg.de> Date: Wed, 13 May 2009 12:10:19 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: pierrick.seite@orange-ftgroup.com References: <4A0578DD.1080304@informatik.haw-hamburg.de> <843DA8228A1BA74CA31FB4E111A5C4620D0905@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620D0905@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] Proposal for a work item agenda 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, 13 May 2009 10:09:04 -0000 Thanks Pierrick, pierrick.seite@orange-ftgroup.com wrote: > I agree with this list of items, it would give more consistence to Multimob. Just one question: > > It is proposed Multicast listener optimizations in PMIP. However, some of the current solution drafts are proposing extensions to PMIP, is it out of scope of the proposed item? > No, it was the idea to separate this in 4 and 5. The thought behind this suggestion is the following: A BCP regarding "how to use multicast with the existing PMIPv6 best" is a document that is easy to produce and progress. So this could be a fast, helpful result to the community. Extension to PMIP, either proposed by the PMIP community or by Multimob, are more intricate and probably require longer discussions and coordination. That's why the list suggests to do stuff in separate steps. Best regards, Thomas > >> -----Message d'origine----- >> De : multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] De la >> part de Thomas C. Schmidt >> Envoyé : samedi 9 mai 2009 14:37 >> À : multimob@ietf.org >> Objet : [multimob] Proposal for a work item agenda >> >> Hi all, >> >> as discussed yesterday on the teleconference, a proposal for a work item >> agenda has been worked out. >> >> And here it is: >> >> Proposal for Multimob roadmap >> >> >> 1. MLD over Wireless: BCP document on deployment of RFC 2710 and RFC >> 3810 >> with configurations optimized for wireless. >> >> 2. MLD extensions for enhanced mobile multicast services: Experimental / >> standards track document on additional MLD functions that improve >> multicast >> in the mobile regime (e.g., listener hold, etc.). >> >> 3. Multicast listener deployment for multihomed mobile nodes: BCP >> document on >> multicast operations in the presence of multihoming >> >> 4. Multicast listener deployment in PMIPv6: BCP document to describe >> minimal >> deployment for PMIPv6 remote subscription. >> >> 5. Multicast listener optimizations in PMIPv6 (+ extensions) domains: >> Experimental / standards track document on additional multicast + >> mobility functions for traffic optimization in PMIPv6 and emerging >> extensions. >> >> 6. Multicast listener extensions for MIPv6 Fast Handovers: Experimental >> / standards track document on multicast extensions in FMIPv6. >> >> 7. Multicast listener extensions for Hierarchical MIPv6: Experimental >> / standards track document on multicast extensions in HMIPv6. >> >> 8. Transparent multicast transmission from mobile nodes: Experimental >> / standards track document for a basic mobile multicast sender >> support. >> >> >> As we want to converge rapidly to meet BoF deadlines, please comment >> sprightly :-) >> >> Best wishes from sunny Europe, >> >> 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 gorry@erg.abdn.ac.uk Wed May 13 11:17: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 F35973A6FBA for ; Wed, 13 May 2009 11:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 Y0J01p9CV-Jq for ; Wed, 13 May 2009 11:17:18 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id EFF9C3A6812 for ; Wed, 13 May 2009 11:17:16 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n4DIIid8029016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 13 May 2009 19:18:45 +0100 (BST) Message-ID: <4A0B0F05.2050305@erg.abdn.ac.uk> Date: Wed, 13 May 2009 19:18:45 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Subject: [multimob] Proposal for a work item agenda X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 18:17:19 -0000 Thomas I'm still hoping to be at the conference call - but there could possibly be a conflict, but let's keep the charter discussion going on the list as well.... My questions at the moment are: - can we add a list of draft names to the milestones (where documents exist)? - is the multi-homing a milestone for the original charter and one for which we expect a draft at the BoF? or is it proposed future work for the WG? Best wishes, Gorry From schmidt@informatik.haw-hamburg.de Wed May 13 13:37: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 741923A693D for ; Wed, 13 May 2009 13:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.266, 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 krMjyYUc0iIa for ; Wed, 13 May 2009 13:36:56 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 4DE083A6A12 for ; Wed, 13 May 2009 13:36:55 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.22.26.203] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1M4LDe-000C4m-L9; Wed, 13 May 2009 22:38:26 +0200 Message-ID: <4A0B2FBF.5070007@informatik.haw-hamburg.de> Date: Wed, 13 May 2009 22:38:23 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <4A0B0F05.2050305@erg.abdn.ac.uk> In-Reply-To: <4A0B0F05.2050305@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] Proposal for a work item agenda 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, 13 May 2009 20:37:02 -0000 Hi Gorry, > I'm still hoping to be at the conference call - but there could possibly > be a conflict, but let's keep the charter discussion going on the list > as well.... I won't make it ... so I'll be bound to the list ;) > > My questions at the moment are: > > - can we add a list of draft names to the milestones (where documents > exist)? yes, that's actually easy (if we omit the many PS / Req drafts). I know of drafts for the following work items: 2. MLD extensions for enhanced mobile multicast services: Experimental / standards track document on additional MLD functions that improve multicast in the mobile regime (e.g., listener hold, etc.). http://tools.ietf.org/html/draft-asaeda-multimob-igmp-mld-mobility-extensions 5. Multicast listener optimizations in PMIPv6 (+ extensions) domains: Experimental / standards track document on additional multicast + mobility functions for traffic optimization in PMIPv6 and emerging extensions. http://www.ietf.org/internet-drafts/draft-asaeda-multimob-pmip6-extension-01.txt http://www.ietf.org/internet-drafts/draft-sijeon-netlmm-mms-pmip6-01.txt http://ietfreport.isoc.org/all-ids/draft-yang-multimob-mip6-mc-tunnel-opt-00.txt 6. Multicast listener extensions for MIPv6 Fast Handovers: Experimental / standards track document on multicast extensions in FMIPv6. http://tools.ietf.org/html/draft-suh-mipshop-fmcast-mip6-00 http://tools.ietf.org/id/draft-xia-mipshop-fmip-multicast-01.txt 7. Multicast listener extensions for Hierarchical MIPv6: Experimental / standards track document on multicast extensions in HMIPv6. http://ietfreport.isoc.org/all-ids/draft-schmidt-waehlisch-mhmipv6-04.txt > > - is the multi-homing a milestone for the original charter and one > for which we expect a draft at the BoF? or is it proposed future work > for the WG? > This I don't know: actually, it does not appear particularly difficult to tackle ... but I haven't heard of anybody working on a document. Best, 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 Wed May 13 13:57:44 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322183A6EF8 for ; Wed, 13 May 2009 13:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEvWinpkRUJ5 for ; Wed, 13 May 2009 13:57:43 -0700 (PDT) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id 193923A6CFA for ; Wed, 13 May 2009 13:57:43 -0700 (PDT) Received: (qmail 83059 invoked by uid 60001); 13 May 2009 20:59:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242248354; bh=0yTSavGauA9nF1XfczauCtOQpS3FizEihFws7IEBb1s=; 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=JzgmRlYqgNH9LKGD+tzx4NolvuD9LJpDz/PHLFylltEJol19rynHGPuB1PyxfiFrqinyi5j19M5GviMf1VBVmf+C+moRBCQeHo+5HqV/6tyHgVgYxV5HDHRyd+54ealUK2eI6GIvsg6pi+w1iuT5JY9Bdo+RXOs+97oddjOpGY4= 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=QrOAb44sSmXUY1Po6n/KhGnur8cosHJKbUrSe9KunB35gCcf722maOREuamWw2ukkA8T2ftqSNNMnFd6ZtRP3xXE5BZdTZfHbKBmkeqh8+YeReKhhfmlZh+YLo//0vkW68g/evOpe6WrETYh4mQjBEAmqA6K1WvugHcaGa42+6c=; Message-ID: <154494.82091.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: Zz4sUi8VM1lpqxrqLE0.NgWVOIQsyF7SGMgVwKFNdLAqcVF1e15WEVLDlSe9DRntvQHYAE37xNUrAk66ee3vrQPaPNSsMdTD9b7dn22411Pw8XuhooE6AS9qRuADK1xCp89HeOfZlEaNTEvhO.mo_mVDqM7BEucZgqOkZl1Aq6VLUtDRUdW.Uy6pJrubiGKHT8cbtKopiESjLcr3ntBMEsoNYpuN_ke3e6hot4rt4KmKwr6NjnRezJGK7gWLCQjjlaa2Exk_MKpA5yF.JpkRz25ZRYn8zG__bQtlN1Y5TuPTQc1pLlpYLd0BLBr0TR9KVWCF7E_bmFqItvOrpqBrcPQCf1_ZUtwsOLDxTDEWWCJ_RysVzmplIal1l1gtJJ65.etKv9dOOg-- Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Wed, 13 May 2009 13:59:13 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <4A0B0F05.2050305@erg.abdn.ac.uk> <4A0B2FBF.5070007@informatik.haw-hamburg.de> Date: Wed, 13 May 2009 13:59:13 -0700 (PDT) From: Behcet Sarikaya To: "Thomas C. Schmidt" , gorry@erg.abdn.ac.uk In-Reply-To: <4A0B2FBF.5070007@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-868470400-1242248353=:82091" Cc: multimob@ietf.org Subject: Re: [multimob] Proposal for a work item agenda X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 20:57:44 -0000 --0-868470400-1242248353=:82091 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Here is a more complete list:=0A=A0Proposal for Multimob roadmap=0A=0A1. ML= D over Wireless: BCP document on deployment of RFC 2710/3376 and RFC 3810= =0A=A0=A0=A0 with configurations optimized for wireless.=0A2. MLD extension= s for enhanced mobile multicast services: Experimental /=0A=A0=A0=A0 standa= rds track document on additional MLD functions that improve multicast=0A=A0= =A0=A0 in the mobile regime (e.g., listener hold, etc.).=0Ahttp://tools.iet= f.org/html/draft-asaeda-multimob-igmp-mld-mobility-extensions=0A=0A3. Multi= cast listener deployment for multihomed mobile nodes: BCP document on=0A=A0= =A0=A0 multicast operations in the presence of multihoming=0A=0A4. Multicas= t listener deployment in PMIPv6: BCP document to describe minimal=0A=A0=A0= =A0 deployment for PMIPv6 remote subscription.=0Ahttp://www.ietf.org/intern= et-drafts/draft-gundavelli-multimob-pmip6basicmcast-solution-00.txt =0A5. M= ulticast listener optimizations in PMIPv6 (+ extensions) domains:=0A=A0=A0= =A0 Experimental / standards track document on additional multicast +=0A=A0= =A0=A0 mobility functions for traffic optimization in PMIPv6 and emerging= =0A=A0=A0=A0 extensions.=0A=0Ahttp://www.ietf.org/internet-drafts/draft-asa= eda-multimob-pmip6-extension-01.txt=0Ahttp://www.ietf.org/internet-drafts/d= raft-sijeon-netlmm-mms-pmip6-01.txt=0Ahttp://ietfreport.isoc.org/all-ids/dr= aft-yang-multimob-mip6-mc-tunnel-opt-00.txt=0Ahttp://www.ietf.org/internet-= drafts/draft-zhao-multimob-pmip6-solution-02.txt=0Ahttp://www.ietf.org/inte= rnet-drafts/draft-deng-multimob-mip4-00.txt=0Ahttp://ietfreport.isoc.org/al= l-ids/draft-xia-multimob-hybrid-00.txt=0A6. Multicast listener extensions f= or MIPv6 Fast Handovers:=A0 Experimental=0A=A0=A0=A0 / standards track docu= ment on multicast extensions in FMIPv6.=0Ahttp://tools.ietf.org/html/draft-= suh-mipshop-fmcast-mip6-00=0Ahttp://tools.ietf.org/id/draft-xia-mipshop-fmi= p-multicast-01.txt=0A7. Multicast listener extensions for Hierarchical MIPv= 6:=A0 Experimental=0A=A0=A0=A0 / standards track document on multicast exte= nsions in HMIPv6.=0A=A0=A0=A0 =0Ahttp://ietfreport.isoc.org/all-ids/draft-s= chmidt-waehlisch-mhmipv6-04.txt=0AThis draft is on Nemo multicast extension= :=0Ahttp://ietfreport.isoc.org/all-ids/draft-von-hugo-multimob-agents-02.tx= t=0A8. Transparent multicast transmission from mobile nodes: Experimental= =0A=A0=A0=A0 / standards track document for a basic mobile multicast sender= support.=0A=0A=0A=0A --0-868470400-1242248353=:82091 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Here is a more complete list:
=0A
 Propo= sal for Multimob roadmap
=0A

1. MLD over Wireless: BCP documen= t on deployment of RFC 2710/3376 and RFC 3810
    with co= nfigurations optimized for wireless.
=0A
2. MLD extensions for enh= anced mobile multicast services: Experimental /
    stand= ards track document on additional MLD functions that improve multicast
&= nbsp;   in the mobile regime (e.g., listener hold, etc.).
= =0A=0A

3. Multicast listener deploy= ment for multihomed mobile nodes: BCP document on
    mul= ticast operations in the presence of multihoming
=0A

4. Multic= ast listener deployment in PMIPv6: BCP document to describe minimal
&nbs= p;   deployment for PMIPv6 remote subscription.
=0A=0A
5. Multicas= t listener optimizations in PMIPv6 (+ extensions) domains:
  &= nbsp; Experimental / standards track document on additional multicast +
=     mobility functions for traffic optimization in PMIPv6 an= d emerging
    extensions.
=0A

http://www.ietf.org/internet-drafts/draft-asaeda-multimob-pmip6-extens= ion-01.txt
http://www.ietf.org/internet-drafts/draft-sijeo= n-netlmm-mms-pmip6-01.txt
http://ietfreport.isoc.o= rg/all-ids/draft-yang-multimob-mip6-mc-tunnel-opt-00.txt
http://www.ietf.org/internet-drafts/draft-zhao-multimob-pmip6-solution-= 02.txt
http://www.ietf.org/internet-drafts/draft-deng-multimob-= mip4-00.txt
http://ietfreport.isoc.org/all-ids/draft-xia-multimob-hybrid-00.txt<= /DIV>=0A
6. Multicast listener extensions for MIPv6 Fast Handovers:&nbs= p; Experimental
    / standards track document on multica= st extensions in FMIPv6.
=0A=0A
7. Multicast listener extensions for Hi= erarchical MIPv6:  Experimental
    / standards trac= k document on multicast extensions in HMIPv6.
   
= =0A=0A
8. Transparent multicast transmission from mobile node= s: Experimental
    / standards track document for a basi= c mobile multicast sender support.

=0A=0A --0-868470400-1242248353=:82091-- From liuhui47967@huawei.com Wed May 13 19:38: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 315B93A6D51 for ; Wed, 13 May 2009 19:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[AWL=2.251, BAYES_00=-2.599, J_CHICKENPOX_34=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 neTzwKjwFlRO for ; Wed, 13 May 2009 19:38:25 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 20A393A6B85 for ; Wed, 13 May 2009 19:38:25 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJM001VI4QJNE@szxga04-in.huawei.com> for multimob@ietf.org; Thu, 14 May 2009 10:39:55 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJM00ILK4QJFL@szxga04-in.huawei.com> for multimob@ietf.org; Thu, 14 May 2009 10:39:55 +0800 (CST) Received: from l47967b ([10.111.12.115]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJM009DH4QJG1@szxml06-in.huawei.com> for multimob@ietf.org; Thu, 14 May 2009 10:39:55 +0800 (CST) Date: Thu, 14 May 2009 10:39:55 +0800 From: Liu Hui In-reply-to: <4A0578DD.1080304@informatik.haw-hamburg.de> To: "'Thomas C. Schmidt'" , multimob@ietf.org Message-id: <000501c9d43d$4406a6f0$730c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnQot255NsKl8XzQWyxRsqd6IQ3yQDmQBfw Subject: Re: [multimob] Proposal for a work item agenda 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, 14 May 2009 02:38:26 -0000 Hi, My understanding towards multicast mobility (as the group name "multimob" shown) are: - The receiver mobility (i.e the source and network are not moving) should be considered with some priority because it has more specific requirements, less deployment cost and lest effect on current fixed multicast achitercure. Other senarios should also not be excluded if there is application prototype and practical solution. - The multicast mobility should not be restricted to one or two mobile IP protocol, unless there is clear decision in industry that these one or two mobile IP protocols will be definitely used while others will not. Thus the mainstream mobile IP protocols will be in the scope (e.g MIP,PMIP, even FMIP ) while possibly with priority orders; - The network type should include both IPv4 and IPv6 networks. The reason is that currently IPv4 network is widely used while IPv6 network hasn't seen its scale deployment. It is possible for IPv4 network to support mobile multicast service . - Handover will be payed special consideration because it has direct performace effect on the multicast service delivery. - The extension of any protocol is possible. But it is encouraged that they should be beneficial while not introduce obvious complexity and interoperability issues and should not confuse original mobile and multicast architectures. - And for the solutions under the multicast mobility architecture the *practicability* should be emphisized because it is highly regarded at IETF. For the items Thomas listed below, I suggest IPv4 network and MIP protocol should also be included in the scope with the reasons given above. Other specific comments are listed in line: > > 1. MLD over Wireless: BCP document on deployment of RFC > 2710 and RFC 3810 > with configurations optimized for wireless. IMHO, apart from wirless optimization, optimization for *mobility* may also be considered unless "wireless" is equivalent to "mobility" > 2. MLD extensions for enhanced mobile multicast services: > Experimental / > standards track document on additional MLD functions > that improve multicast > in the mobile regime (e.g., listener hold, etc.). > 3. Multicast listener deployment for multihomed mobile > nodes: BCP document on > multicast operations in the presence of multihoming> > 4. Multicast listener deployment in PMIPv6: BCP document to > describe minimal > deployment for PMIPv6 remote subscription. > 5. Multicast listener optimizations in PMIPv6 (+ > extensions) domains: > Experimental / standards track document on additional multicast + > mobility functions for traffic optimization in PMIPv6 > and emerging extensions. > 6. Multicast listener extensions for MIPv6 Fast Handovers: > Experimental > / standards track document on multicast extensions in FMIPv6.> > 7. Multicast listener extensions for Hierarchical MIPv6: > Experimental > / standards track document on multicast extensions in HMIPv6.> > 8. Transparent multicast transmission from mobile nodes: > Experimental > / standards track document for a basic mobile multicast > sender support. For item 3 and 4 "multicast listener deployment" is not quite clear in meaning. For IP multicast, *multicast listener* is only defined and used in MLD protocol. Does this phrase mean MLD deployment? If does, MLD protocol should be definitely pointed out, otherwise more precise expression should be used. It is same for "Multicast listener optimizations" and "Multicast listener extensions" in the following items. Best Regards, Liu Hui From Dirk.von-Hugo@telekom.de Thu May 14 02:26: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 0A7733A6883 for ; Thu, 14 May 2009 02:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, 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 pLw3P3VfjsrB for ; Thu, 14 May 2009 02:26:31 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 87B0F3A67D4 for ; Thu, 14 May 2009 02:26:30 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 14 May 2009 11:27:24 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 May 2009 11:27:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 May 2009 11:27:22 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC8027848F20378@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <000501c9d43d$4406a6f0$730c6f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Proposal for a work item agenda Thread-Index: AcnQot255NsKl8XzQWyxRsqd6IQ3yQDmQBfwAA3jsOA= References: <4A0578DD.1080304@informatik.haw-hamburg.de> <000501c9d43d$4406a6f0$730c6f0a@china.huawei.com> From: To: , , X-OriginalArrivalTime: 14 May 2009 09:27:24.0083 (UTC) FILETIME=[3072D030:01C9D476] Subject: Re: [multimob] Proposal for a work item agenda 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, 14 May 2009 09:26:32 -0000 =20 Dear all, I agree that it is important to emphasize first that a multicast support = is feasable also for PMIPv6 as this will be deployed by several mobile = operators (following 3GPP/3PGG2 and WiMAX standards). The approach to = set up a BCP document should be beneficial for this. While covering generally all existing MIP solutions and all scenarios we = then should start with priority for - listeners - performance optimization in terms of low HO loss and delay, route = optimization and control effort reduction=20 With regard to the complete list of topics (and e.g. multi-homing): Do = we really need a draft for each issue for the BoF? Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Liu Hui Gesendet: Donnerstag, 14. Mai 2009 04:40 An: 'Thomas C. Schmidt'; multimob@ietf.org Betreff: Re: [multimob] Proposal for a work item agenda Hi, My understanding towards multicast mobility (as the group name = "multimob" shown) are: - The receiver mobility (i.e the source and network are not moving) = should be considered with some priority because it has more specific = requirements, less deployment cost and lest effect on current fixed multicast = achitercure. Other senarios should also not be excluded if there is application = prototype and practical solution.=20 - The multicast mobility should not be restricted to one or two mobile = IP protocol, unless there is clear decision in industry that these one or = two mobile IP protocols will be definitely used while others will not. Thus = the mainstream mobile IP protocols will be in the scope (e.g MIP,PMIP, even = FMIP ) while possibly with priority orders; - The network type should include both IPv4 and IPv6 networks. The = reason is that currently IPv4 network is widely used while IPv6 network hasn't = seen its scale deployment. It is possible for IPv4 network to support mobile multicast service . - Handover will be payed special consideration because it has direct performace effect on the multicast service delivery. - The extension of any protocol is possible. But it is encouraged that = they should be beneficial while not introduce obvious complexity and interoperability issues and should not confuse original mobile and = multicast architectures. - And for the solutions under the multicast mobility architecture the *practicability* should be emphisized because it is highly regarded at = IETF. For the items Thomas listed below, I suggest IPv4 network and MIP = protocol should also be included in the scope with the reasons given above. = Other specific comments are listed in line: =20 >=20 > 1. MLD over Wireless: BCP document on deployment of RFC=20 > 2710 and RFC 3810 > with configurations optimized for wireless. IMHO, apart from wirless optimization, optimization for *mobility* may = also be considered unless "wireless" is equivalent to "mobility"=20 =20 > 2. MLD extensions for enhanced mobile multicast services:=20 > Experimental / > standards track document on additional MLD functions=20 > that improve multicast > in the mobile regime (e.g., listener hold, etc.).=20 > 3. Multicast listener deployment for multihomed mobile=20 > nodes: BCP document on > multicast operations in the presence of multihoming>=20 > 4. Multicast listener deployment in PMIPv6: BCP document to=20 > describe minimal > deployment for PMIPv6 remote subscription.=20 > 5. Multicast listener optimizations in PMIPv6 (+=20 > extensions) domains: > Experimental / standards track document on additional multicast + > mobility functions for traffic optimization in PMIPv6=20 > and emerging extensions.=20 > 6. Multicast listener extensions for MIPv6 Fast Handovers: =20 > Experimental > / standards track document on multicast extensions in FMIPv6.>=20 > 7. Multicast listener extensions for Hierarchical MIPv6: =20 > Experimental > / standards track document on multicast extensions in HMIPv6.>=20 > 8. Transparent multicast transmission from mobile nodes:=20 > Experimental > / standards track document for a basic mobile multicast=20 > sender support. For item 3 and 4 "multicast listener deployment" is not quite clear in meaning. For IP multicast, *multicast listener* is only defined and = used in MLD protocol. Does this phrase mean MLD deployment? If does, MLD = protocol should be definitely pointed out, otherwise more precise expression = should be used. It is same for "Multicast listener optimizations" and = "Multicast listener extensions" in the following items. Best Regards, Liu Hui=20 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From gorry@erg.abdn.ac.uk Thu May 14 03:18: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 F035E28C22E for ; Thu, 14 May 2009 03:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, J_CHICKENPOX_34=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 YOaL1CKZm8F1 for ; Thu, 14 May 2009 03:18:09 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id AF4DB28C227 for ; Thu, 14 May 2009 03:18:07 -0700 (PDT) Received: from Gorry-Fairhursts-Laptop-6.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n4EAINHS019459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 May 2009 11:18:24 +0100 (BST) Message-ID: <4A0BEFEF.4060409@erg.abdn.ac.uk> Date: Thu, 14 May 2009 11:18:23 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dirk.von-Hugo@telekom.de References: <4A0578DD.1080304@informatik.haw-hamburg.de> <000501c9d43d$4406a6f0$730c6f0a@china.huawei.com> <643B0A1D1A13AB498304E0BBC8027848F20378@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <643B0A1D1A13AB498304E0BBC8027848F20378@S4DE8PSAAQC.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org Subject: Re: [multimob] Proposal for a work item agenda X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 10:18:10 -0000 As you suggest, it seems OK to me to have some work items less mature - A talk by someone who wants to use the documents to build real networks is the next best thing to a draft - a promise of a "future" draft by an individual is OK, but less impressive ... These items could even be within the scope of the *Charter*, but not assigned a milestone. I can't speak for the BoF organisers, but generally the most important thing is to show there are PEOPLE willing to write sections of the key documents, and that there are more people willing to review the documents - it is especially good if a group of these people represent implementors and operators (these are ideal people to SAY the work is needed). It is normally necessary to have a good set of drafts that get this sort of support. Is IPv4 multicast to be in or out of scope???? - If so, how do we handle this? Gorry Dirk.von-Hugo@telekom.de wrote: > > Dear all, > I agree that it is important to emphasize first that a multicast support is feasable also for PMIPv6 as this will be deployed by several mobile operators (following 3GPP/3PGG2 and WiMAX standards). The approach to set up a BCP document should be beneficial for this. > > While covering generally all existing MIP solutions and all scenarios we then should start with priority for > - listeners > - performance optimization in terms of low HO loss and delay, route optimization and control effort reduction > > With regard to the complete list of topics (and e.g. multi-homing): Do we really need a draft for each issue for the BoF? > > Best regards > Dirk > > -----Ursprüngliche Nachricht----- > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftrag von Liu Hui > Gesendet: Donnerstag, 14. Mai 2009 04:40 > An: 'Thomas C. Schmidt'; multimob@ietf.org > Betreff: Re: [multimob] Proposal for a work item agenda > > Hi, > > My understanding towards multicast mobility (as the group name "multimob" > shown) are: > > - The receiver mobility (i.e the source and network are not moving) should > be considered with some priority because it has more specific requirements, > less deployment cost and lest effect on current fixed multicast achitercure. > Other senarios should also not be excluded if there is application prototype > and practical solution. > > - The multicast mobility should not be restricted to one or two mobile IP > protocol, unless there is clear decision in industry that these one or two > mobile IP protocols will be definitely used while others will not. Thus the > mainstream mobile IP protocols will be in the scope (e.g MIP,PMIP, even FMIP > ) while possibly with priority orders; > > - The network type should include both IPv4 and IPv6 networks. The reason > is that currently IPv4 network is widely used while IPv6 network hasn't seen > its scale deployment. It is possible for IPv4 network to support mobile > multicast service . > > - Handover will be payed special consideration because it has direct > performace effect on the multicast service delivery. > > - The extension of any protocol is possible. But it is encouraged that they > should be beneficial while not introduce obvious complexity and > interoperability issues and should not confuse original mobile and multicast > architectures. > > - And for the solutions under the multicast mobility architecture the > *practicability* should be emphisized because it is highly regarded at IETF. > > > For the items Thomas listed below, I suggest IPv4 network and MIP protocol > should also be included in the scope with the reasons given above. Other > specific comments are listed in line: > >> 1. MLD over Wireless: BCP document on deployment of RFC >> 2710 and RFC 3810 >> with configurations optimized for wireless. > > IMHO, apart from wirless optimization, optimization for *mobility* may also > be considered unless "wireless" is equivalent to "mobility" > > >> 2. MLD extensions for enhanced mobile multicast services: >> Experimental / >> standards track document on additional MLD functions >> that improve multicast >> in the mobile regime (e.g., listener hold, etc.). >> 3. Multicast listener deployment for multihomed mobile >> nodes: BCP document on >> multicast operations in the presence of multihoming> >> 4. Multicast listener deployment in PMIPv6: BCP document to >> describe minimal >> deployment for PMIPv6 remote subscription. >> 5. Multicast listener optimizations in PMIPv6 (+ >> extensions) domains: >> Experimental / standards track document on additional multicast + >> mobility functions for traffic optimization in PMIPv6 >> and emerging extensions. >> 6. Multicast listener extensions for MIPv6 Fast Handovers: >> Experimental >> / standards track document on multicast extensions in FMIPv6.> >> 7. Multicast listener extensions for Hierarchical MIPv6: >> Experimental >> / standards track document on multicast extensions in HMIPv6.> >> 8. Transparent multicast transmission from mobile nodes: >> Experimental >> / standards track document for a basic mobile multicast >> sender support. > > For item 3 and 4 "multicast listener deployment" is not quite clear in > meaning. For IP multicast, *multicast listener* is only defined and used in > MLD protocol. Does this phrase mean MLD deployment? If does, MLD protocol > should be definitely pointed out, otherwise more precise expression should > be used. It is same for "Multicast listener optimizations" and "Multicast > listener extensions" in the following items. > > > Best Regards, > > Liu Hui > > > > _______________________________________________ > 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 waehlisch@ieee.org Thu May 14 04:43: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 A51D23A6DC0 for ; Thu, 14 May 2009 04:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.649 X-Spam-Level: X-Spam-Status: No, score=-101.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, 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 klT5FSPO7kJQ for ; Thu, 14 May 2009 04:43:31 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 92D003A6F3A for ; Thu, 14 May 2009 04:43:30 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.89.226.145] (helo=mw-thinkpad.hpi.uni-potsdam.de) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1M4ZN0-00052d-Dq; Thu, 14 May 2009 13:45:02 +0200 Date: Thu, 14 May 2009 13:45:01 +0200 From: Matthias Waehlisch To: Gorry Fairhurst In-Reply-To: <4A0BEFEF.4060409@erg.abdn.ac.uk> Message-ID: References: <4A0578DD.1080304@informatik.haw-hamburg.de> <000501c9d43d$4406a6f0$730c6f0a@china.huawei.com> <643B0A1D1A13AB498304E0BBC8027848F20378@S4DE8PSAAQC.mitte.t-com.de> <4A0BEFEF.4060409@erg.abdn.ac.uk> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="774774421-19673-1242301268=:2132" Content-ID: Cc: multimob@ietf.org, Dirk.von-Hugo@telekom.de Subject: Re: [multimob] Proposal for a work item agenda 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, 14 May 2009 11:43:32 -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. --774774421-19673-1242301268=:2132 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hi Gorry, agree ... as far as I know, IPv4 is out of scope, which is probably=20 fine, otherwise it would be two chaotic. Best 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 On Thu, 14 May 2009, Gorry Fairhurst wrote: >=20 > As you suggest, it seems OK to me to have some work items less mature - A= talk > by someone who wants to use the documents to build real networks is the n= ext > best thing to a draft - a promise of a "future" draft by an individual is= OK, > but less impressive ... These items could even be within the scope of the > *Charter*, but not assigned a milestone. >=20 > I can't speak for the BoF organisers, but generally the most important th= ing > is to show there are PEOPLE willing to write sections of the key document= s, > and that there are more people willing to review the documents - it is > especially good if a group of these people represent implementors and > operators (these are ideal people to SAY the work is needed). It is norma= lly > necessary to have a good set of drafts that get this sort of support. >=20 >=20 > Is IPv4 multicast to be in or out of scope???? - If so, how do we handle = this? >=20 > Gorry >=20 >=20 > Dirk.von-Hugo@telekom.de wrote: > > Dear all, > > I agree that it is important to emphasize first that a multicast suppor= t is > > feasable also for PMIPv6 as this will be deployed by several mobile > > operators (following 3GPP/3PGG2 and WiMAX standards). The approach to s= et up > > a BCP document should be beneficial for this. > >=20 > > While covering generally all existing MIP solutions and all scenarios w= e > > then should start with priority for > > - listeners > > - performance optimization in terms of low HO loss and delay, route > > optimization and control effort reduction=20 > > With regard to the complete list of topics (and e.g. multi-homing): Do = we > > really need a draft for each issue for the BoF? > >=20 > > Best regards > > Dirk > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Au= ftrag > > von Liu Hui > > Gesendet: Donnerstag, 14. Mai 2009 04:40 > > An: 'Thomas C. Schmidt'; multimob@ietf.org > > Betreff: Re: [multimob] Proposal for a work item agenda > >=20 > > Hi, > >=20 > > My understanding towards multicast mobility (as the group name "multimo= b" > > shown) are: > >=20 > > - The receiver mobility (i.e the source and network are not moving) sho= uld > > be considered with some priority because it has more specific requireme= nts, > > less deployment cost and lest effect on current fixed multicast achiter= cure. > > Other senarios should also not be excluded if there is application prot= otype > > and practical solution.=20 > > - The multicast mobility should not be restricted to one or two mobile = IP > > protocol, unless there is clear decision in industry that these one or = two > > mobile IP protocols will be definitely used while others will not. Thu= s the > > mainstream mobile IP protocols will be in the scope (e.g MIP,PMIP, even= FMIP > > ) while possibly with priority orders; > >=20 > > - The network type should include both IPv4 and IPv6 networks. The rea= son > > is that currently IPv4 network is widely used while IPv6 network hasn't= seen > > its scale deployment. It is possible for IPv4 network to support mobil= e > > multicast service . > >=20 > > - Handover will be payed special consideration because it has direct > > performace effect on the multicast service delivery. > >=20 > > - The extension of any protocol is possible. But it is encouraged that= they > > should be beneficial while not introduce obvious complexity and > > interoperability issues and should not confuse original mobile and mult= icast > > architectures. > >=20 > > - And for the solutions under the multicast mobility architecture the > > *practicability* should be emphisized because it is highly regarded at = IETF. > >=20 > >=20 > > For the items Thomas listed below, I suggest IPv4 network and MIP proto= col > > should also be included in the scope with the reasons given above. Oth= er > > specific comments are listed in line: > > =20 > > > 1. MLD over Wireless: BCP document on deployment of RFC 2710 and RF= C > > > 3810 > > > with configurations optimized for wireless. > >=20 > > IMHO, apart from wirless optimization, optimization for *mobility* may = also > > be considered unless "wireless" is equivalent to "mobility" =20 > > > 2. MLD extensions for enhanced mobile multicast services: Experimen= tal / > > > standards track document on additional MLD functions that improv= e > > > multicast > > > in the mobile regime (e.g., listener hold, etc.). 3. Multicast > > > listener deployment for multihomed mobile nodes: BCP document on > > > multicast operations in the presence of multihoming> 4. Multic= ast > > > listener deployment in PMIPv6: BCP document to describe minimal > > > deployment for PMIPv6 remote subscription. 5. Multicast listen= er > > > optimizations in PMIPv6 (+ extensions) domains: > > > Experimental / standards track document on additional multicast = + > > > mobility functions for traffic optimization in PMIPv6 and emergi= ng > > > extensions. 6. Multicast listener extensions for MIPv6 Fast Handove= rs: > > > Experimental > > > / standards track document on multicast extensions in FMIPv6.> = 7. > > > Multicast listener extensions for Hierarchical MIPv6: Experimental > > > / standards track document on multicast extensions in HMIPv6.> = 8. > > > Transparent multicast transmission from mobile nodes: Experimental > > > / standards track document for a basic mobile multicast sender > > > support. > >=20 > > For item 3 and 4 "multicast listener deployment" is not quite clear in > > meaning. For IP multicast, *multicast listener* is only defined and us= ed in > > MLD protocol. Does this phrase mean MLD deployment? If does, MLD prot= ocol > > should be definitely pointed out, otherwise more precise expression sho= uld > > be used. It is same for "Multicast listener optimizations" and "Multic= ast > > listener extensions" in the following items. > >=20 > >=20 > > Best Regards, > >=20 > > Liu Hui=20 > >=20 > >=20 > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > >=20 > >=20 >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob >=20 --774774421-19673-1242301268=:2132-- From behcetsarikaya@yahoo.com Thu May 14 07:54: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 3C57228B56A for ; Thu, 14 May 2009 07:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, HTML_MESSAGE=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 qXu1j7JhBhB5 for ; Thu, 14 May 2009 07:54:16 -0700 (PDT) Received: from n69a.bullet.mail.sp1.yahoo.com (n69a.bullet.mail.sp1.yahoo.com [98.136.45.16]) by core3.amsl.com (Postfix) with SMTP id 7BD153A6A74 for ; Thu, 14 May 2009 07:54:16 -0700 (PDT) Received: from [216.252.122.218] by n69.bullet.mail.sp1.yahoo.com with NNFMP; 14 May 2009 14:55:46 -0000 Received: from [67.195.9.83] by t3.bullet.sp1.yahoo.com with NNFMP; 14 May 2009 14:55:45 -0000 Received: from [67.195.9.110] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 14 May 2009 14:55:45 -0000 Received: from [127.0.0.1] by omp114.mail.gq1.yahoo.com with NNFMP; 14 May 2009 14:53:32 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 795133.21451.bm@omp114.mail.gq1.yahoo.com Received: (qmail 47320 invoked by uid 60001); 14 May 2009 14:55:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242312942; bh=iwehwRmiQ7/jI8Zwgp1Bj9CGdL1inyIZCDYA6+bjwTk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=nyBLUZ8V2QQAuImW29VdvfwHE5Ec1ouuBEqw0FAkMKoG5prirJEUwANKjbELQbF8w/3SUbQhpPHPhr2GFv6/ZoMnwX9XwFVHa8SutZBQ4uA4FHA/bd0A/BgQpuxKyURuwMwrAcgxgEM73ZDjwkxqDd9qvvr+ctmGqF4B72Yrtbg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=S8z2kb4i/sXR119z1Lx9wjoL49J+U2DbN19W1a9fz+9Bv9QLx2yJ5RQzEHz69xkUZwH3bR20ShCc2IoY0kHop5UXm8HZUCDlggPo3Jt/4zoeoom2unnCpAOuLLsBdk6KXxIQet++Q5zPPjIQ0AzR32qD3E6uTO79fsP01O07x6I=; Message-ID: <991096.55707.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: NuNaoEoVM1kGnMrnKDOWt5tiTyRXXk04x6ruJU_UfwO_Fcd.Ltj1XlCVW.2B2SN.QyfvW1uv66UVCNE07YBoR0TNDYFkNLA_cexfvqDALrwITfpg0nfG2uM0WrNRy5SE2wUJfhMH.umsZU_2B7L5Rp5VdhhO9EwzELOZiKWuOWa84BGKZpIx0k4gCg1DIrhB8NFO6UJK7_XM7xRSX7YeerztMQGKGLpKBYp3EYfy4WXHp5T8BBKpUSP2Lvb.qGQltUsewFPFmk5RyV1K3k.ia5wtF36QVRXXkNUddjmE6xp6Rq_fwb6m Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Thu, 14 May 2009 07:55:42 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 Date: Thu, 14 May 2009 07:55:42 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1500874044-1242312942=:55707" Subject: [multimob] Teleconference minutes 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, 14 May 2009 14:54:17 -0000 --0-1500874044-1242312942=:55707 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Folks,=0A=A0 There was a short call today. Here is a very short summary:=0A= =0A=A0 In the call Suresh raised some issues similar to the points made dur= ing the BoF last November. He suggested that those questions have to be ans= wered before moving ahead. He will post some text on the list today to init= iate some discussion on this in the hopes of maybe coming up with a draft.= =0A=0A=A0 There was some discussion on whether or not IPv4 multicast is in = scope. Marshall thinks this is mainly IPv6 activity. Behcet said IPv4 is in= cluded. No conclusions were reached.=0A=0A=A0 Marshall thinks that Thomas p= osted a good road map which was followed up on the list by many and he thin= ks this is encouraging for the next BoF. He said coming up witha revised ch= arter and contacting the AD are the next steps.=0A=0ARegards,=0A=0ABehcet= =0A=0A=0A --0-1500874044-1242312942=:55707 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Folks,
=0A
  There was a = short call today. Here is a very short summary:
=0A
 
= =0A
  In the call Suresh raised some issues similar to the points = made during the BoF last November. He suggested that those questions have t= o be answered before moving ahead. He will post some text on the list today= to initiate some discussion on this in the hopes of maybe coming up with a= draft.
=0A
 
=0A
  There was some discussion o= n whether or not IPv4 multicast is in scope. Marshall thinks this is mainly= IPv6 activity. Behcet said IPv4 is included. No conclusions were reached.<= /DIV>=0A
 
=0A
  Marshall thinks that Thomas posted = a good road map which was followed up on the list by many and he thinks thi= s is encouraging for the next BoF. He said coming up witha revised charter = and contacting the AD are the next steps.
=0A
 
=0A
= Regards,
=0A
 
=0A
Behcet

=0A=0A = --0-1500874044-1242312942=:55707-- From tme@americafree.tv Thu May 14 08:08: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 7DA3528C14C for ; Thu, 14 May 2009 08:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 S1R9RtL0RZim for ; Thu, 14 May 2009 08:08:00 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 95AA93A694F for ; Thu, 14 May 2009 08:08:00 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 566E23CC8AF3; Thu, 14 May 2009 11:09:33 -0400 (EDT) Message-Id: <36B4EAA6-9860-4217-B486-B9B50B175843@americafree.tv> From: Marshall Eubanks To: Behcet Sarikaya In-Reply-To: <991096.55707.qm@web111410.mail.gq1.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 14 May 2009 11:09:32 -0400 References: <991096.55707.qm@web111410.mail.gq1.yahoo.com> X-Mailer: Apple Mail (2.930.3) Cc: multimob@ietf.org Subject: Re: [multimob] Teleconference minutes 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, 14 May 2009 15:08:04 -0000 On May 14, 2009, at 10:55 AM, Behcet Sarikaya wrote: > Folks, > There was a short call today. Here is a very short summary: > > In the call Suresh raised some issues similar to the points made > during the BoF last November. He suggested that those questions have > to be answered before moving ahead. He will post some text on the > list today to initiate some discussion on this in the hopes of maybe > coming up with a draft. > The important step here is getting some operators to declare that they see this as a problem that needs to be addressed. (Even if the current deployments are experiments, if there is a foreseeable problem in the future, it still can and IMO should be addressed now.) If anyone knows how to get such operator statements, I think that they should go ahead and try to get them. Regards Marshall > There was some discussion on whether or not IPv4 multicast is in > scope. Marshall thinks this is mainly IPv6 activity. Behcet said > IPv4 is included. No conclusions were reached. > > Marshall thinks that Thomas posted a good road map which was > followed up on the list by many and he thinks this is encouraging > for the next BoF. He said coming up witha revised charter and > contacting the AD are the next steps. > > Regards, > > Behcet > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From gwz@net-zen.net Thu May 14 19:49: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 2C50F3A704C for ; Thu, 14 May 2009 19:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 Mu+J9d46FzCl for ; Thu, 14 May 2009 19:49:25 -0700 (PDT) Received: from smtpout09.prod.mesa1.secureserver.net (smtpout09-01.prod.mesa1.secureserver.net [64.202.165.14]) by core3.amsl.com (Postfix) with SMTP id 688CB3A6BFE for ; Thu, 14 May 2009 19:49:25 -0700 (PDT) Received: (qmail 26670 invoked from network); 15 May 2009 02:50:58 -0000 Received: from unknown (124.120.229.155) by smtpout09.prod.mesa1.secureserver.net (64.202.165.14) with ESMTP; 15 May 2009 02:50:57 -0000 From: "Glen Zorn" To: "'Marshall Eubanks'" , "'Behcet Sarikaya'" References: <991096.55707.qm@web111410.mail.gq1.yahoo.com> <36B4EAA6-9860-4217-B486-B9B50B175843@americafree.tv> In-Reply-To: <36B4EAA6-9860-4217-B486-B9B50B175843@americafree.tv> Date: Fri, 15 May 2009 09:49:52 +0700 Organization: Network Zen Message-ID: <00d401c9d507$d533d100$7f9b7300$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnUpgA2RfGPVc2kSe+eVVHaDJOpmgAYP+qw Content-Language: en-us Cc: multimob@ietf.org Subject: Re: [multimob] Teleconference minutes 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, 15 May 2009 02:49:26 -0000 Marshall Eubanks [mailto://tme@americafree.tv] writes: > > There was a short call today. Here is a very short summary: > > > > In the call Suresh raised some issues similar to the points made > > during the BoF last November. He suggested that those questions have > > to be answered before moving ahead. He will post some text on the > > list today to initiate some discussion on this in the hopes of maybe > > coming up with a draft. > > > > The important step here is getting some operators to declare that they > see this as a problem that needs to be addressed. I agree, with the operative term being "needs to be addressed": even if there are problems, do they really need to be fixed or will things work well enough as they are? ... From tme@americafree.tv Thu May 14 20:24: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 6AF693A709B for ; Thu, 14 May 2009 20:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id embR9D-0+AN4 for ; Thu, 14 May 2009 20:24:24 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 932973A709A for ; Thu, 14 May 2009 20:24:24 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id D4E0F3CDA01F; Thu, 14 May 2009 23:25:57 -0400 (EDT) Message-Id: <1F4878DD-97B7-47C0-9ECB-9B524B5E8B82@americafree.tv> From: Marshall Eubanks To: "Glen Zorn" In-Reply-To: <00d401c9d507$d533d100$7f9b7300$@net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 14 May 2009 23:25:57 -0400 References: <991096.55707.qm@web111410.mail.gq1.yahoo.com> <36B4EAA6-9860-4217-B486-B9B50B175843@americafree.tv> <00d401c9d507$d533d100$7f9b7300$@net> X-Mailer: Apple Mail (2.930.3) Cc: multimob@ietf.org Subject: Re: [multimob] Teleconference minutes 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, 15 May 2009 03:24:25 -0000 On May 14, 2009, at 10:49 PM, Glen Zorn wrote: > Marshall Eubanks [mailto://tme@americafree.tv] writes: > >>> There was a short call today. Here is a very short summary: >>> >>> In the call Suresh raised some issues similar to the points made >>> during the BoF last November. He suggested that those questions have >>> to be answered before moving ahead. He will post some text on the >>> list today to initiate some discussion on this in the hopes of maybe >>> coming up with a draft. >>> >> >> The important step here is getting some operators to declare that >> they >> see this as a problem that needs to be addressed. > > I agree, with the operative term being "needs to be addressed": even > if > there are problems, do they really need to be fixed or will things > work well > enough as they are? > Given the state of things, this will have to be a judgement call. But we need operator input (and judgement). Marshall > ... > > > From behcetsarikaya@yahoo.com Fri May 15 07:44:10 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADBD73A7032 for ; Fri, 15 May 2009 07:44:10 -0700 (PDT) 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, HTML_MESSAGE=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 a4lbfaI2gIAq for ; Fri, 15 May 2009 07:44:09 -0700 (PDT) Received: from n69a.bullet.mail.sp1.yahoo.com (n69a.bullet.mail.sp1.yahoo.com [98.136.45.16]) by core3.amsl.com (Postfix) with SMTP id D26243A6D43 for ; Fri, 15 May 2009 07:44:09 -0700 (PDT) Received: from [69.147.84.145] by n69.bullet.mail.sp1.yahoo.com with NNFMP; 15 May 2009 14:45:40 -0000 Received: from [67.195.9.82] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 15 May 2009 14:45:40 -0000 Received: from [67.195.9.100] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 15 May 2009 14:45:40 -0000 Received: from [127.0.0.1] by omp104.mail.gq1.yahoo.com with NNFMP; 15 May 2009 14:45:30 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 937476.83411.bm@omp104.mail.gq1.yahoo.com Received: (qmail 15962 invoked by uid 60001); 15 May 2009 14:45:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242398739; bh=kVohOPfDLihuzEkWvIOWXBiBnfTbn9lX934P4DjIIbQ=; 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=hsRnF3XZGRnlJbpOSptvuh203nf5EuSj+qz5UnlHeQvHwt6OQrkwIC3J33QFFVr7hp8f5qBykFMno7GFFF+EG4uyQUWonETg+l+Z90uzbQvM3jc+t01q663TTZgT22xoUBjaLpjsi9dQjVKbDBA56w8Al52RnvENYGYS9rG89t0= 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=DtWC7r8z1Y0L1iX32Z9CsS3qSRTagVZBJob33YgMrgw8gTNIK8LxPdbtmwq7vi7S6f/nYNrzFLX2V9w9zFawrDMaUftA1baycU2RVsJGAShzkt9bPzgJVN80vpNsWrM9APVEwYioNpdU7q+OhaCRuUYEdRHmpCQUoYdfoRMnoqQ=; Message-ID: <884959.14756.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: 78KswCUVM1mCm48.1cabHXuQzLtnvSMDyDWNS3iu8yGIndSZ7ZAQhjDprUvks9rcDzSeckzHOAQ9StZUMQ_98rraBjMljWYTc0dX0xIECfj39tt.qUtIebQz0DPOJKQNIzFOCKMxl.kq4WvtLDFzgSXKJLsXbwYxWe.JxLO1NK9t541BToHKPKBVZ98T4EO422zsHMb3Su3vWOpUY_yMJK8CLA3FhBPySd7tRdJef1u1yXaK2JGSGn9goXFjQAly4d_rOkuMRznq5aM5DGQt3ySByzMjfH13DmEszRvxACxAwBOsyYR4PmW9sOSFzrTVbvdCYfSf4qTG7g5oUUDDNzB2OmE- Received: from [195.33.106.4] by web111404.mail.gq1.yahoo.com via HTTP; Fri, 15 May 2009 07:45:39 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <991096.55707.qm@web111410.mail.gq1.yahoo.com> <36B4EAA6-9860-4217-B486-B9B50B175843@americafree.tv> <00d401c9d507$d533d100$7f9b7300$@net> Date: Fri, 15 May 2009 07:45:39 -0700 (PDT) From: Behcet Sarikaya To: Glen Zorn , Marshall Eubanks In-Reply-To: <00d401c9d507$d533d100$7f9b7300$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1296106452-1242398739=:14756" Cc: multimob@ietf.org Subject: Re: [multimob] Teleconference minutes 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, 15 May 2009 14:44:10 -0000 --0-1296106452-1242398739=:14756 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Glen,=0A=0A=A0 See my comments below.=0A=A0 Regards,=0A=0ABehcet=0A=0A__= ______________________________=0A=0AFrom: Glen Zorn =0ATo:= Marshall Eubanks ; Behcet Sarikaya = =0ACc: multimob@ietf.org=0ASent: Thursday, May 14, 2009 9:49:52 PM=0ASubjec= t: RE: [multimob] Teleconference minutes=0A=0AAnother one is multihomed mob= ile nodes. They may receive multiple copies of multicast data. =0A=0ASome o= ther items we have in the proposed charter are of optimization nature, yes = things work as they are but at what price?=0A=0A=0A=0AMarshall Eubanks [mai= lto://tme@americafree.tv] writes:=0A=0A> >=A0 There was a short call today.= Here is a very short summary:=0A> >=0A> >=A0 In the call Suresh raised som= e issues similar to the points made=0A> > during the BoF last November. He = suggested that those questions have=0A> > to be answered before moving ahea= d. He will post some text on the=0A> > list today to initiate some discussi= on on this in the hopes of maybe=0A> > coming up with a draft.=0A> >=0A> = =0A> The important step here is getting some operators to declare that they= =0A> see this as a problem that needs to be addressed. =0A=0AI agree, with = the operative term being "needs to be addressed": even if=0Athere are probl= ems, do they really need to be fixed or will things work well=0Aenough as t= hey are?=0A=0A[behcet] Some would, some others wouldn't. The most notable o= nes: Proxy Mobile IPv6 did not define multicasting support in RFC 5213. Tha= t leaves a gap as to how multicasting can be supported to the mobile nodes.= =0A=0A=0A --0-1296106452-1242398739=:14756 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Glen,
=0A
  See my comments = below.
=0A
  Regards,
=0A
 
=0A<= DIV style=3D"FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZ= E: 12pt">Behcet
=0A
=0A
=0A=
=0A
From: Glen Zorn <= ;gwz@net-zen.net>
To:= Marshall Eubanks <tme@americafree.tv>; Behcet Sarikaya <sarikaya@= ieee.org>
Cc: multimo= b@ietf.org
Sent: Thursda= y, May 14, 2009 9:49:52 PM
Subject:= RE: [multimob] Teleconference minutes

Marshall Eu= banks [mailto://tme@americafree.tv] writes:

> >  The= re was a short call today. Here is a very short summary:
> >
&g= t; >  In the call Suresh raised some issues similar to the points m= ade
> > during the BoF last November. He suggested that those ques= tions have
> > to be answered before moving ahead. He will post some text on the
= > > list today to initiate some discussion on this in the hopes of ma= ybe
> > coming up with a draft.
> >
>
> The = important step here is getting some operators to declare that they
> = see this as a problem that needs to be addressed.

I agree, with the= operative term being "needs to be addressed": even if
there are problem= s, do they really need to be fixed or will things work well
enough as th= ey are?

[behcet] Some would, some othe= rs wouldn't. The most notable ones: Proxy Mobile IPv6 did not define multic= asting support in RFC 5213. That leaves a gap as to how multicasting can be= supported to the mobile nodes.
=0A
Another one is multihomed mobile nodes. They may receive multipl= e copies of multicast data.
=0A
 
=0A
<= FONT color=3D#6000bf>Some other items we have in the proposed charter are o= f optimization nature, yes things work as they are but at what price?



=0A=0A --0-1296106452-1242398739=:14756-- From Dirk.von-Hugo@telekom.de Fri May 15 08:18: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 DA79A3A6ED3 for ; Fri, 15 May 2009 08:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 fVBqiLvp3wpY for ; Fri, 15 May 2009 08:18:54 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 327EF3A6D8F for ; Fri, 15 May 2009 08:18:53 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 15 May 2009 17:20:20 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 May 2009 17:20:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2009 17:20:17 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC8027848F209E5@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <1F4878DD-97B7-47C0-9ECB-9B524B5E8B82@americafree.tv> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Teleconference minutes Thread-Index: AcnVDOKko978aTJQQEaEY4CiCZwvXAAYiQ7Q References: <991096.55707.qm@web111410.mail.gq1.yahoo.com><36B4EAA6-9860-4217-B486-B9B50B175843@americafree.tv><00d401c9d507$d533d100$7f9b7300$@net> <1F4878DD-97B7-47C0-9ECB-9B524B5E8B82@americafree.tv> From: To: , X-OriginalArrivalTime: 15 May 2009 15:20:19.0686 (UTC) FILETIME=[A8812860:01C9D570] Cc: multimob@ietf.org Subject: Re: [multimob] Teleconference minutes 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, 15 May 2009 15:18:54 -0000 Dear all, For a mobile operator using 3GPP/LTE with global customers a broad = deployment of multicast services may become a problem when customers = abroad and on the move are connected via a non-3G access - as using = plain PMIP6 (e.g. with Bi-directional Tunneling) for the interconnection = to home network, as described in = http://www.ietf.org/internet-drafts/draft-sarikaya-multimob-overwireless-= ps-00.txt would create a lot of inter-continental traffic. To save such = expensive resources the extension of mobility protocols and/or multicast = management protocols would be very beneficial. Best regards, Dirk Dirk von Hugo Deutsche Telekom AG Laboratories Deutsche-Telekom-Allee 7 D-64295 Darmstadt Phone: +49 6151 937-2536 =20 Fax: +49 521 92109586 Mobile: +49 151 14620590 E-Mail: Dirk.von-Hugo@telekom.de =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Marshall Eubanks Gesendet: Freitag, 15. Mai 2009 05:26 An: Glen Zorn Cc: multimob@ietf.org Betreff: Re: [multimob] Teleconference minutes On May 14, 2009, at 10:49 PM, Glen Zorn wrote: > Marshall Eubanks [mailto://tme@americafree.tv] writes: > >>> There was a short call today. Here is a very short summary: >>> >>> In the call Suresh raised some issues similar to the points made >>> during the BoF last November. He suggested that those questions have >>> to be answered before moving ahead. He will post some text on the >>> list today to initiate some discussion on this in the hopes of maybe >>> coming up with a draft. >>> >> >> The important step here is getting some operators to declare that =20 >> they >> see this as a problem that needs to be addressed. > > I agree, with the operative term being "needs to be addressed": even =20 > if > there are problems, do they really need to be fixed or will things =20 > work well > enough as they are? > Given the state of things, this will have to be a judgement call. But =20 we need operator input (and judgement). Marshall > ... > > > _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Mon May 18 07:29:47 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C774A28C2F0 for ; Mon, 18 May 2009 07:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW90nFcHDzMh for ; Mon, 18 May 2009 07:29:46 -0700 (PDT) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id BD8853A6824 for ; Mon, 18 May 2009 07:29:46 -0700 (PDT) Received: (qmail 72055 invoked by uid 60001); 18 May 2009 14:31:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242657080; bh=yl6kOx0jMoyCRxWaJr11W51bJoGoeOWN/OOfjbjfItQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=esK3HZGCoqyc0z04XofpatN6kCnz2NQ5TUGg6T4dqc/byWtoOosp+DXNibZqeJ4hxNRDskggC5qYGEA2dgtlPVpxrjNEZbkiUmywxqK1Zs8AGQ+K+2bDQ280C0cJ110qXwKLVO+DUBvPKYSro/RqJSWdqrIQo6ccbOH4Ttx9lfA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=v3NtWNU6L5Ya29FPrAJ/vVBeoorr5JZ1K2MKR1qKWe3fz3/5qVZEfuTV5z/Sa3lHGQShAdINmVJX0k0M24TXtUuxcvxpQuxSjsJIPJgQi94OQHrm6HTEhk61ButsCiI4U2+J3OB7iNSLdRtBo94mi9/i7mAV7fdKm3UKicF90Dc=; Message-ID: <112050.71128.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: L.f4ducVM1mpSSAb4M03cb2pHbjx6A0SR7ZK9fuofBaqBsfurY2VtoTF90ySbg_VR7UqlS5WthxUYVuhm0xpwceXQioO2MigkW.qhvQSpa6k1Hof1TwoSxbU0yXdaeT5vRDSSwVhBegCI_kJ1d2m.xr_TwJVKM_LvAVxsM3LJdgqhdAGjxV5.9m60Eud6SeBPkSpSeJaME0U36DKF2Ka3SDRFlF44f4iVPowJKHzMygYJ0ZDTGuhpkvHcTRZ6Vx9J6NqAAVUrvQ7t4hqAyg.lGlfQwsBzqgg9uao4r_9pHBXuE_ymw-- Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Mon, 18 May 2009 07:31:19 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 Date: Mon, 18 May 2009 07:31:19 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1714521676-1242657079=:71128" Subject: [multimob] Charter for Multimob 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, 18 May 2009 14:29:47 -0000 --0-1714521676-1242657079=:71128 Content-Type: multipart/alternative; boundary="0-591387698-1242657079=:71128" --0-591387698-1242657079=:71128 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Multimob folks,=0A=A0 Here is the charter version 01 based on Thomas' road = map.=0APlease post your comments on the list.=0A=0ABehcet=0A=0A=0A --0-591387698-1242657079=:71128 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Multimob folks,
=0A
  Her= e is the charter version 01 based on Thomas' road map.
=0A
Please = post your comments on the list.
=0A
 
=0A
Behcet

=0A=0A=0A=0A --0-591387698-1242657079=:71128-- --0-1714521676-1242657079=:71128 Content-Type: text/plain; name="multimobcharter01.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="multimobcharter01.txt" TXVsdGljYXN0IE1vYmlsaXR5IChtdWx0aW1vYikNCg0KQ2hhaXJzOg0KVEJE DQoNCkludGVybmV0IEFyZWEgKGludCkgRGlyZWN0b3JzOg0KSmFyaSBBcmtr byA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+DQpNYXJrIFRvd25zbGV5IDx0b3du c2xleUBjaXNjby5jb20+IA0KDQpJbnRlcm5ldCBBcmVhIEFkdmlzb3I6DQpK YXJpIEFya2tvIDxqYXJpLmFya2tvQHBpdWhhLm5ldD4NCg0KU2VjdXJpdHkg QXJlYSBBZHZpc29yOg0KTWFyc2hhbGwgRXViYW5rcyA8dG1lQGFtZXJpY2Fm cmVlLnR2Pi4NCg0KTWFpbGluZyBMaXN0czoNCkdlbmVyYWwgRGlzY3Vzc2lv bjogbXVsdGltb2JAaWV0Zi5vcmcNClN1YnNjcmliZSBvbmxpbmUgYXQ6IGh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211bHRpbW9i DQoNCkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXANCg0KSVAgbXVsdGlj YXN0aW5nIHRlY2hub2xvZ3kgaGFzIG5vdyBzdGFydGVkIHRvIGJlIHVzZWQg aW4gbW9iaWxlIG5ldHdvcmtzIGFuZCB0aGlzIHRyZW5kIGlzIGV4cGVjdGVk IHRvDQpjb250aW51ZS4gTXVsdGljYXN0IG1vYmlsaXR5IChtdWx0aW1vYikg cHJvcG9zZXMgdG8gZGVhbCB3aXRoIHRoZSBwcm9ibGVtcyBhbmQgaW5lZmZp Y2llbmNpZXMgDQp0aGF0IGFyaXNlIGZyb20gdXNpbmcgSVAgbXVsdGljYXN0 aW5nIGluIG1vYmlsZSBlbnZpcm9ubWVudHMuIFRoZSBzY29wZSB3aWxsIGJl IGxpbWl0ZWQgdG8NCnRoZSAgZ3JvdXAgbWFuYWdlbWVudCBhbmQgbW9iaWxl IElQIHByb3RvY29scywgcHJveGllZCBvciBjbGllbnQtYmFzZWQuIEJvdGgg c291cmNlIHNwZWNpZmljIG11bHRpY2FzdCAoU1NNKSANCmFuZCBhbnkgc291 cmNlIG11bHRpY2FzdGluZyB3aWxsIGJlIGNvbnNpZGVyZWQuIFdvcmsgcmVs YXRlZCB0byBhbmQgcmVxdWlyaW5nIG1vZGlmaWNhdGlvbnMgb2YgDQptdWx0 aWNhc3Qgcm91dGluZyBwcm90b2NvbHMgKFBJTS1TTSwgUElNLURNLCBldGMu KSBpcyBvdXQgb2Ygc2NvcGUuIEJvdGggSVB2NCBhbmQgSVB2NiB2ZXJzaW9u cw0Kb2YgdGhlIHNvbHV0aW9ucyB3aWxsIGJlIGRldmVsb3BlZCBpbiB0aGUg c2FtZSBvciBzZXBhcmF0ZSBkb2N1bWVudHMuIA0KDQpJR01QdjMvTUxEdjIg aXMgb3JpZ2luYWxseSBkZWZpbmVkIGZvciB3aXJlZCBuZXR3b3JrcyB3aXRo IHNoYXJlZCBsaW5rcy4gTW9iaWxlIG5vZGVzIGhhdmUgdG8gDQpzYXZlIGJh dHRlcnkgYnkgZW50ZXJpbmcgaW50byB0aGUgZG9ybWFudCBtb2RlLiBUaGVy ZWZvcmUgZG9ybWFudCBtb2RlIG9wZXJhdGlvbiBuZWVkcyB0byBiZSBzdXBw b3J0ZWQgDQpieSBJR01QdjMvTUxEdjIuIFRoZXJlIGFyZSBhbHNvIGNvbmNl cm5zIHJlbGF0ZWQgdG8gdGhlIGxhdGVuY3kgb2Ygam9pbnMgYW5kIGxlYXZl cyB0aGF0IElHTVB2My9NTER2MiBwcm92aWRlcy4gDQpUaGUgbGF0ZW5jeSBu ZWVkcyB0byBiZSBtaW5pbWl6ZWQuIFRoZXJlIGFyZSBjdXJyZW50bHkgZGVw bG95ZWQgZXh0ZW5zaW9ucyB0byByZWR1Y2UgdGhlIGpvaW4gYW5kIGxlYXZl IA0KbGF0ZW5jaWVzLiAgSW4gTXVsdGltb2IgdGhlc2UgaXNzdWVzIHdpbGwg YmUgYWRkcmVzc2VkIGFuZCBJR01QdjMvTUxEdjIgZm9yIG1vYmlsZSBlbnZp cm9ubWVudHMgDQp3aWxsIGJlIHN0YW5kYXJkaXplZC4gRGlmZmVyZW50IHN0 cmF0ZWdpZXMgZm9yIHNvbHZpbmcgdGhlc2UgaXNzdWVzIHdpbGwgYmUgcHVy c3VlZC4gDQpUaGUgc2ltcGxlc3Qgc3RyYXRlZ3kgd291bGQgYmUgZG9jdW1l bnRpbmcgYWxyZWFkeSBpbXBsZW1lbnRlZCBhbmQgZGVwbG95ZWQgZmFzdCBq b2luL2Zhc3QgbGVhdmUgZXh0ZW5zaW9ucy4gDQpUaGUgV0cgbmVlZHMgdG8g YXNjZXJ0YWluIHdoZXRoZXIgdGhlIGV4aXN0aW5nIHNvbHV0aW9ucyBhcmUg c3VmZmljaWVudCB0byBzb2x2ZSB0aGlzIHByb2JsZW0sIGFuZCBpZiBub3Qs IA0KY29tZSB1cCB3aXRoIGJldHRlciBzb2x1dGlvbnMuIEZvciBzdXBwb3J0 aW5nIHRoZSBkb3JtYW50IG1vZGUsIHRoZSBXRyBuZWVkcyB0byBkZWZpbmUg cHJvdG9jb2wgY2hhbmdlcyANCnRoYXQgbWF5IHNpbXBseSBtb2RpZnkgdGhl IHRpbWVycyBpbiB0aGUgcHJvdG9jb2xzIG9yIHN1cHBvcnQgYWRkaXRpb25h bCBtZXNzYWdlIHR5cGVzLiANCg0KSXQgaXMgYSBnb2FsIG9mIE11bHRpbW9i IHRvIGFzY2VydGFpbiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggdGhl IGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIG9mIGdyb3VwIG1hbmFnZW1lbnQg cHJvdG9jb2xzLiBNZXNzYWdlIHN0cnVjdHVyZXMgc3VwcG9ydGVkIGluIHRo ZSBjdXJyZW50IGRlcGxveW1lbnRzIHdpbGwgbm90IGJlIG1vZGlmaWVkLg0K DQpUaGUgdW5pY2FzdCBtb2JpbGl0eSBwcm90b2NvbHMgKE1vYmlsZSBJUHY2 LCBEdWFsLVN0YWNrIE1vYmlsZSBJUHY2IGFuZCBhbHNvIE1vYmlsZSBJUHY0 KSBwcm92aWRlIGJhc2ljIG11bHRpY2FzdCBzdXBwb3J0IGFuZCBlbmFibGUg bW9iaWxlIG5vZGVzIHRvIHBlcmZvcm0gYmktZGlyZWN0aW9uYWwgdHVubmVs aW5nIGFuZCByZWNlaXZlIG11bHRpY2FzdCB0cmFmZmljIGFuY2hvcmVkIGF0 IHRoZSBob21lIGFnZW50LiBIb3dldmVyIHN1Y2ggYSBiYXNpYyBzdXBwb3J0 IHN1ZmZlcnMgZnJvbSB0aGUgJ2F2YWxhbmNoZScgcHJvYmxlbSBhcyB0aGUg aG9tZSBhZ2VudHMgcmVwbGljYXRlIHRoZSBwYWNrZXRzIGFuZCB1bmljYXN0 IHRoZW0gdG8gdGhlIG1vYmlsZSBub2RlcyBhcyB3ZWxsIGFzIGZyb20gbm9u LW9wdGltYWwsIHRyaWFuZ3VsYXIgcm91dGluZy4gIFRoZSBvdGhlciBtZXRo b2QsIGUuZy4gJ3JlbW90ZSBzdWJzY3JpcHRpb24nIGhvd2V2ZXIgc3VmZmVy cyBmcm9tIHBvc3NpYmxlIGxvc3Mgb2YgZGF0YSBkdXJpbmcgaGFuZG92ZXJz Lg0KDQpQcm94eSBNb2JpbGUgSVB2NiAoUE1JUHY2KSBkb2VzIG5vdCBjdXJy ZW50bHkgc3VwcG9ydCBtdWx0aWNhc3RpbmcuIFByb3h5IE1vYmlsZSBJUHY2 IGJhc2ljIG11bHRpY2FzdGluZyBzdXBwb3J0IHdpdGggYmktZGlyZWN0aW9u YWwgdHVubmVsaW5nIHdpbGwgYmUgdGFrZW4gdXAgaW4gTXVsdGltb2IgZmly c3QuIFN1Y2ggYSBzdXBwb3J0IHdpbGwgcmVxdWlyZSBubyBuZXcgbWVzc2Fn ZXMgYXMgd2VsbCBhcyBubyBjaGFuZ2VzIGluIHRoZSBjdXJyZW50IG1lc3Nh Z2Ugc3RydWN0dXJlcy4gDQpQTUlQdjYgYmFzaWMgbXVsdGljYXN0IHN1cHBv cnQgd2lsbCBiZSBleHRlbmRlZCB0byBzdXBwb3J0IHJlbW90ZSBzdWJzY3Jp cHRpb24gYW5kIGZhc3QgaGFuZG92ZXIgd2l0aCBwb3NzaWJpbGl0eSBvZiBp bnRyb2R1Y2luZyBuZXcgbWVzc2FnZXMgYW5kL29yIG5ldyBtZXNzYWdlIHBh cmFtZXRlcnMuIEluIGJvdGggY2FzZXMsIFBNSVB2NiBtdWx0aWNhc3QgcHJv dG9jb2xzIHdpbGwgYmUgZXh0ZW5kZWQNCnRvIHN1cHBvcnQgbXVsdGljYXN0 aW5nIHdpdGggSVB2NC4gDQoNCk11bHRpLWhvbWVkIG1vYmlsZSBub2RlcyBt YXkgam9pbiBhIG11bHRpY2FzdCBncm91cCBmcm9tIHR3byBpbnRlcmZhY2Vz IGFuZCByZWNlaXZlIG11bHRpY2FzdCBkYXRhIGluIGR1cGxpY2F0ZSB3aGlj aCBzaG91bGQgYmUgYXZvaWRlZC4gTXVsdGlob21pbmcgcHJvYmxlbXMgaW4g bXVsdGljYXN0aW5nIGluY2x1ZGluZyBtdWx0aWNhc3QgZmxvdyBiaW5kaW5n IGFyZSBpbiBzY29wZSBvZiBNdWx0aW1vYi4gDQoNCkluIGRvaW5nIGl0cyB3 b3JrLCB0aGUgTXVsdGltb2Igd29ya2luZyBncm91cCB3aWxsIHdvcmsgY2xv c2VseSB3aXRoIE5FVExNTQ0Kd29ya2luZyBncm91cCBhbmQgd2lsbCBjb29y ZGluYXRlIElHTVAvTUxEIGV4dGVuc2lvbnMgd29yayB3aXRoIE1CT05FRCB3 b3JraW5nIGdyb3Vwcy4NCg0KR09BTFMgQU5EIE1JTEVTVE9ORVMNCg0Kc2l4 IG1vbnRoczogDQotIE11bHRpY2FzdCBsaXN0ZW5lciBkZXBsb3ltZW50IGZv ciBtdWx0aWhvbWVkIG1vYmlsZSBub2RlczogQkNQIGRvY3VtZW50IG9uDQog ICAgbXVsdGljYXN0IG9wZXJhdGlvbnMgaW4gdGhlIHByZXNlbmNlIG9mIG11 bHRpaG9taW5nDQotIE11bHRpY2FzdCBsaXN0ZW5lciBkZXBsb3ltZW50IGlu IFBNSVB2NjogQkNQIGRvY3VtZW50IHRvIGRlc2NyaWJlIG1pbmltYWwNCiAg ICBkZXBsb3ltZW50IGZvciBQTUlQdjYgcmVtb3RlIHN1YnNjcmlwdGlvbg0K DQpPbmUgeWVhcjogDQotIElHTVAvTUxEIGV4dGVuc2lvbnMgZm9yIGVuaGFu Y2VkIG1vYmlsZSBtdWx0aWNhc3Qgc2VydmljZXM6IEV4cGVyaW1lbnRhbCAv DQogICAgc3RhbmRhcmRzIHRyYWNrIGRvY3VtZW50IG9uIGFkZGl0aW9uYWwg SUdNUC9NTEQgZnVuY3Rpb25zIHRoYXQgaW1wcm92ZSBtdWx0aWNhc3QNCiAg ICBpbiB0aGUgbW9iaWxlIHJlZ2ltZSBhcyBwcm9wb3NlZCBzdGFuZGFyZA0K LSBNdWx0aWNhc3QgbGlzdGVuZXIgb3B0aW1pemF0aW9ucyBpbiBQTUlQdjYg KCsgZXh0ZW5zaW9ucykgZG9tYWluczoNCiAgICBFeHBlcmltZW50YWwgLyBz dGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQgb24gYWRkaXRpb25hbCBtdWx0aWNh c3QgKw0KICAgIG1vYmlsaXR5IGZ1bmN0aW9ucyBmb3IgdHJhZmZpYyBvcHRp bWl6YXRpb24gaW4gUE1JUHY2IGFuZCBlbWVyZ2luZw0KICAgIGV4dGVuc2lv bnMNCg0KDQpSZWNoYXJ0ZXIgb3IgY2xvc2Ugd29ya2luZyBncm91cA== --0-1714521676-1242657079=:71128-- From liuhui47967@huawei.com Mon May 18 20:48: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 F1E993A6ACE for ; Mon, 18 May 2009 20:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.409 X-Spam-Level: ** X-Spam-Status: No, score=2.409 tagged_above=-999 required=5 tests=[AWL=-1.406, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQpgRswQVLwf for ; Mon, 18 May 2009 20:48:00 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 27F473A6C58 for ; Mon, 18 May 2009 20:48:00 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJV005X8HADMH@szxga02-in.huawei.com> for multimob@ietf.org; Tue, 19 May 2009 11:49:25 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJV00FQ1HADPS@szxga02-in.huawei.com> for multimob@ietf.org; Tue, 19 May 2009 11:49:25 +0800 (CST) Received: from l47967b ([10.111.12.115]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJV00JGBHACI5@szxml06-in.huawei.com> for multimob@ietf.org; Tue, 19 May 2009 11:49:25 +0800 (CST) Date: Tue, 19 May 2009 11:49:24 +0800 From: Liu Hui In-reply-to: <112050.71128.qm@web111407.mail.gq1.yahoo.com> To: 'Behcet Sarikaya' , multimob@ietf.org Message-id: <000901c9d834$cd4e75a0$730c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_n/0huP5AmJO8dRzYzHm1eg)" Thread-index: AcnXxVa0zERYo9pjQRSNjRuQXL+5twAbPQ1w Subject: Re: [multimob] Charter for Multimob 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, 19 May 2009 03:48:02 -0000 This is a multi-part message in MIME format. --Boundary_(ID_n/0huP5AmJO8dRzYzHm1eg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable I have a few comments on the charter: =20 1. The sentence "The WG needs to ascertain whether..." is a useful and general guidence to the work of the group. It should not be restricted within the descriptions of IGMP/MLD parts. I suggest moving it ahead as = the second paragraph of the charter, combined with the sentence "It is a = goal of Multimob...". The new second paragraph looks as following (with capital words indicating the modification): =20 " The WG needs to ascertain whether the existing solutions are = sufficient to solve THESE PROBLEMS, and if not, come up with better solutions. It is a goal of Multimob to ascertain backward compatibility with the current implementations of MULTICAST AND MOBILE IP protocols. Message structures supported in the current deployments will not be modified. " =20 2. For IGMP/MLD part, I feel too many words are explained for "dormant = mode" . Because this is only one aspect of this area, I suggest not to = propose it to so important a level. Instead, more general descriptions may be provided. An example is given as: =20 "IGMP/MLD is originally defined for wired networks with shared links. = They are to be evaluated the necessity to take the extention, modificaiton = and enhancement to make them applicable to wireless and mobile environment, = and to various wireless link types. The aspects of wireless link characteristics, mobile communication features, battery-saving, fast join/leave, and etc. are to be considered when making this = adaptability." =20 3. The passage of "The unicast mobility protocols ..." only lists the current state and problem, but does not gives some specific plan as PMIP does. I suggest add a sentence "Feasible solutions solving the above problems are to be explored" or the like to the end. And It is better = to put this passage after the PMIP one because the latter has more specific plan and if this is done, the "The unicast mobility protocols ..." = should be changed to "Other unicast mobility protocols..." =20 =20 Please check if they are appropriate. =20 Best Regards, Liu Hui =20 =20 _____ =20 From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On = Behalf Of Behcet Sarikaya Sent: 2009=C4=EA5=D4=C218=C8=D5 22:31 To: multimob@ietf.org Subject: [multimob] Charter for Multimob Multimob folks, Here is the charter version 01 based on Thomas' road map. Please post your comments on the list. =20 Behcet --Boundary_(ID_n/0huP5AmJO8dRzYzHm1eg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
I have a few=20 comments on the charter:
 
1. The sentence  "The WG needs to = ascertain=20 whether..." is a = useful and general guidence to the work of = the group.=20 It should not be restricted = within the=20 descriptions of IGMP/MLD parts.  I suggest moving it ahead as the = second=20 paragraph of the charter, combined with the sentence "It is a goal of=20 Multimob...".  The new second paragraph looks as following (with = capital=20 words indicating the modification):
 
" The WG needs to ascertain whether the = existing=20 solutions are sufficient to solve THESE PROBLEMS, and if not, come up = with=20 better solutions. It is a goal = of Multimob=20 to ascertain backward compatibility with the current implementations of=20 MULTICAST AND MOBILE IP protocols. Message structures supported in the=20 current deployments will not be = modified.=20 "
 
2. For IGMP/MLD part, I feel too many words = are=20 explained for "dormant mode" . =20 Because this is only one aspect = of this=20 area,  I suggest not to propose it to so important a level.  = Instead,=20 more general descriptions may be provided. =20 An example is given = as:
 
"IGMP/MLD is originally defined for wired = networks with=20 shared links.  They are to be evaluated the necessity to take the extention, modificaiton and=20 enhancement to make them applicable to wireless and mobile environment, = and to=20 various wireless link types.  The aspects of=20 wireless link characteristics, = mobile=20 communication features, battery-saving, fast join/leave,=20 and etc. are to be = considered when=20 making this adaptability."
 
3. The passage of "The unicast mobility = protocols ..."=20 only lists the current state and problem, but does not gives some specific plan as PMIP = does.  I=20 suggest add a sentence "Feasible solutions solving the above = problems are to be explored" or the like to the end.  And It is better to put this passage = after the=20 PMIP one because the latter has more specific plan and if this is done,  the "The unicast mobility = protocols=20 ..." should be changed to "Other unicast mobility protocols..."  =
 
Please check=20 if they are appropriate.
 
Best Regards,
Liu Hui
 
 

From: multimob-bounces@ietf.org = [mailto:multimob-bounces@ietf.org]=20 On Behalf Of Behcet Sarikaya
Sent: = 2009=C4=EA5=D4=C218=C8=D5=20 22:31
To: multimob@ietf.org
Subject: [multimob] = Charter=20 for Multimob

Multimob folks,
  Here is the charter version 01 based on Thomas' road = map.
Please post your comments on the list.
 
Behcet

--Boundary_(ID_n/0huP5AmJO8dRzYzHm1eg)-- From gorry@erg.abdn.ac.uk Tue May 19 00:01:47 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37DE43A67A1 for ; Tue, 19 May 2009 00:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.187 X-Spam-Level: X-Spam-Status: No, score=-1.187 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMtr8t37QBr6 for ; Tue, 19 May 2009 00:01:46 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id B82363A67B4 for ; Tue, 19 May 2009 00:01:44 -0700 (PDT) Received: from Gorry-Fairhursts-Laptop-6.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n4J733Bu025407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 May 2009 08:03:04 +0100 (BST) Message-ID: <4A1259A7.9000306@erg.abdn.ac.uk> Date: Tue, 19 May 2009 08:03:03 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Liu Hui References: <000901c9d834$cd4e75a0$730c6f0a@china.huawei.com> In-Reply-To: <000901c9d834$cd4e75a0$730c6f0a@china.huawei.com> Content-Type: multipart/mixed; boundary="------------090201010503040709010802" X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org Subject: Re: [multimob] Charter for Multimob X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 07:01:47 -0000 This is a multi-part message in MIME format. --------------090201010503040709010802 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Liu, Becheret, I read the charter proposal, but it took me a little while to understand exactly what was in scope or not, so I tried a little rewording... Here is a reworked version of the proposed charter text. I tried to keep the style simple and in line with other charters I had seen. Please see if any of this is improved or not, and do feel free to copy this (or parts of this) into your charter proposal. Best wishes, Gorry Liu Hui wrote: > I have a few comments on the charter: > > 1. The sentence "The WG needs to ascertain whether..." is a useful and > general guidence to the work of the group. It should not be restricted > within the descriptions of IGMP/MLD parts. I suggest moving it ahead as > the second paragraph of the charter, combined with the sentence "It is a > goal of Multimob...". The new second paragraph looks as following (with > capital words indicating the modification): > > " The WG needs to ascertain whether the existing solutions are > sufficient to solve THESE PROBLEMS, and if not, come up with better > solutions. It is a goal of Multimob to ascertain backward compatibility > with the current implementations of MULTICAST AND MOBILE IP protocols. > Message structures supported in the current deployments will not be > modified. " > > 2. For IGMP/MLD part, I feel too many words are explained for "dormant > mode" . Because this is only one aspect of this area, I suggest not to > propose it to so important a level. Instead, more general descriptions > may be provided. An example is given as: > > "IGMP/MLD is originally defined for wired networks with shared links. > They are to be evaluated the necessity to take the extention, > modificaiton and enhancement to make them applicable to wireless and > mobile environment, and to various wireless link types. The aspects of > wireless link characteristics, mobile communication features, > battery-saving, fast join/leave, and etc. are to be considered when > making this adaptability." > > 3. The passage of "The unicast mobility protocols ..." only lists the > current state and problem, but does not gives some specific plan as PMIP > does. I suggest add a sentence "Feasible solutions solving the above > problems are to be explored" or the like to the end. And It is better > to put this passage after the PMIP one because the latter has more > specific plan and if this is done, the "The unicast mobility protocols > ..." should be changed to "Other unicast mobility protocols..." > > Please check if they are appropriate. > > Best Regards, > Liu Hui > > > > ------------------------------------------------------------------------ > *From:* multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] > *On Behalf Of *Behcet Sarikaya > *Sent:* 2009Äê5ÔÂ18ÈÕ 22:31 > *To:* multimob@ietf.org > *Subject:* [multimob] Charter for Multimob > > Multimob folks, > Here is the charter version 01 based on Thomas' road map. > Please post your comments on the list. > > Behcet > > > ------------------------------------------------------------------------ > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob --------------090201010503040709010802 Content-Type: text/plain; name="multimobcharter01-GF.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="multimobcharter01-GF.txt" Ck11bHRpY2FzdCBNb2JpbGl0eSAobXVsdGltb2IpDQoNCkNoYWlyczoNClRCRA0KDQpJbnRl cm5ldCBBcmVhIChpbnQpIERpcmVjdG9yczoNCkphcmkgQXJra28gPGphcmkuYXJra29AcGl1 aGEubmV0Pg0KTWFyayBUb3duc2xleSA8dG93bnNsZXlAY2lzY28uY29tPiANCg0KSW50ZXJu ZXQgQXJlYSBBZHZpc29yOg0KSmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+DQoN ClNlY3VyaXR5IEFyZWEgQWR2aXNvcjoNCk1hcnNoYWxsIEV1YmFua3MgPHRtZUBhbWVyaWNh ZnJlZS50dj4uDQoNCk1haWxpbmcgTGlzdHM6DQpHZW5lcmFsIERpc2N1c3Npb246IG11bHRp bW9iQGlldGYub3JnDQpTdWJzY3JpYmUgb25saW5lIGF0OiBodHRwczovL3d3dzEuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aW1vYg0KDQpEZXNjcmlwdGlvbiBvZiBXb3JraW5n IEdyb3VwDQoNClRoZSBNdWx0aWNhc3QgbW9iaWxpdHkgKG11bHRpbW9iKSB3aWxsIGRldmVs b3AgYSBzZXQgb2YgcHJvdG9jb2wgZXh0ZW5zaW9ucyBhbmQgcHJvdmlkZSBndWlkYW5jZSBh cHByb3ByaWF0ZSBmb3IgSVB2NCBhbmQgSVB2NiBtdWx0aWNhc3QgaW4gYSBtb2JpbGUgZW52 aXJvbm1lbnQuIEl0IHdpbGwgY29uc2lkZXIgYm90aCBzb3VyY2Ugc3BlY2lmaWMgbXVsdGlj YXN0IChTU00pICBhbmQgYW55IHNvdXJjZSBtdWx0aWNhc3QgKEFNUykgbXVsdGljYXN0IG1v ZGVscy4KClRoZSBzY29wZSBvZiB3b3JrIHdpbGwgYmUgbGltaXRlZCB0byBncm91cCBtYW5h Z2VtZW50IGFuZCBtb2JpbGUgSVAgcHJvdG9jb2xzIC0gcHJveGllZCBvciBjbGllbnQtYmFz ZWQuIFdvcmsgcmVxdWlyaW5nIG1vZGlmaWNhdGlvbnMgb2YgbXVsdGljYXN0IHJvdXRpbmcg cHJvdG9jb2xzIChQSU0tU00sIFBJTS1ETSwgZXRjLikgaXMgb3V0IG9mIHNjb3BlLiBTcGVj aWZpYyBnb2FscyBhcmU6CgotIFByb3ZpZGUgZ3VpZGFuY2UgYW5kIHNwZWNpZnkgbWV0aG9k cyBmb3IgbXVsdGktaG9taW5nIHN1cHBvcnQgZm9yIG11bHRpY2FzdC4gIAotIFNwZWNpZnkg SUdNUC9NTEQgZXh0ZW5zaW9ucyBtZXRob2RzIGZvciByZWR1Y2luZyBqb2luL2xlYXZlIGxh dGVuY3kuCi0gU3BlY2lmeSBhIGRvcm1hbnQgbW9kZSBvcGVyYXRpb24gZm9yIElHTVB2My9N TER2Mi4KLSBVcGRhdGUgUE1JUHY2IHRvIHN1cHBvcnQgSVB2NCBtdWx0aWNhc3QsIHJlbW90 ZSBzdWJzY3JpcHRpb24gYW5kIGZhc3QgaGFuZG92ZXIuIA0KDQpNdWx0aW1vYiB3aWxsIHNw ZWNpZnkgYSBzZXQgb2YgZXh0ZW5zaW9ucyB0byBJR01QdjMvTUxEdjIgZm9yIG1vYmlsZSBl bnZpcm9ubWVudHMuIElHTVB2My9NTER2MiBoYXMgYmVlbiBzcGVjaWZpZWQgZm9yIHdpcmVk IG5ldHdvcmtzIHdpdGggc2hhcmVkIGxpbmtzLiBNb2JpbGUgbm9kZXMgYWxzbyBoYXZlIG90 aGVyIG5lZWRzIChlLmcuICBlbnRlcmluZyBhIGRvcm1hbnQgbW9kZSB0byBjb25zZXJ2ZSBi YXR0ZXJ5IHBvd2VyLCBtaW5pbWlzaW5nIHRoZSBsYXRlbmN5IGZvciBqb2luaW5nIGFuZCBs ZWF2aW5nIGEgZ3JvdXAgaW4gc3VwcG9ydCBvZiBtb3ZlbWVudCkuICBUaGUgd29ya2luZyBn cm91cCB3aWxsIGFzc2VzcyBleGlzdGluZyBzb2x1dGlvbnMgZm9yIGdyb3VwIG1hbmFnZW1l bnQsIGFuZCBkZXRlcm1pbmUgaWYgdGhlc2UgbWV0aG9kcyBhcmUgc3VmZmljaWVudCwgaXQg d2lsbCBkZWZpbmUgYmVzdCBjdXJyZW50IHByYWN0aWNlIGZvciBzZWxlY3Rpb24gb2YgdGlt ZXIgdmFsdWVzIGFuZCBwcm90b2NvbCBwYXJhbWV0ZXJzLiBJZiBub3QsIGl0IHNoYWxsIHBy b3Bvc2UgbmV3IHNvbHV0aW9ucyBhcyB1cGRhdGVzIHRvIGV4aXN0aW5nIHByb3RvY29scyAo aW5jbHVkaW5nIHBvc3NpYmxlIGludHJvZHVjdGlvbiBvZiBhZGRpdGlvbmFsIG1lc3NhZ2Ug dHlwZXMpLiBJdCBpcyBhIGdvYWwgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvIGVuc3VyZSBi YWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb25z IG9mIGdyb3VwIG1hbmFnZW1lbnQgcHJvdG9jb2xzLiBNZXNzYWdlIHN0cnVjdHVyZXMgc3Vw cG9ydGVkIGluIGN1cnJlbnQgZGVwbG95ZWQgbmV0d29ya3Mgd2lsbCBub3QgYmUgbW9kaWZp ZWQuDQoKVW5pY2FzdCBtb2JpbGl0eSBwcm90b2NvbHMgKE1vYmlsZSBJUHY2LCBEdWFsLVN0 YWNrIE1vYmlsZSBJUHY2IGFuZCBhbHNvIE1vYmlsZSBJUHY0KSBwcm92aWRlIGJhc2ljIG11 bHRpY2FzdCBzdXBwb3J0IGFuZCBlbmFibGUgbW9iaWxlIG5vZGVzIHRvIHBlcmZvcm0gYmkt ZGlyZWN0aW9uYWwgdHVubmVsaW5nIGFuZCByZWNlaXZlIG11bHRpY2FzdCB0cmFmZmljIGFu Y2hvcmVkIGF0IHRoZSBob21lIGFnZW50LiBIb3dldmVyLCBzdWNoIGJhc2ljIHN1cHBvcnQg c3VmZmVycyBmcm9tIHRoZSAnYXZhbGFuY2hlJyBwcm9ibGVtIGFzIHRoZSBob21lIGFnZW50 cyByZXBsaWNhdGUgdGhlIHBhY2tldHMgYW5kIHVuaWNhc3QgdGhlbSB0byB0aGUgbW9iaWxl IG5vZGVzIGFzIHdlbGwgYXMgZnJvbSBub24tb3B0aW1hbCwgdHJpYW5ndWxhciByb3V0aW5n LCAncmVtb3RlIHN1YnNjcmlwdGlvbicgc3VmZmVycyBmcm9tIHBvc3NpYmxlIGxvc3Mgb2Yg ZGF0YSBkdXJpbmcgaGFuZG92ZXJzLiBUaGUgV0cgd2lsbCBhZGRyZXNzIHRoZXNlIGlzc3Vl cyB3aXRoaW4gdGhlIGNvbnRleHQgb2YgUE1JUHY2LgoKUHJveHkgTW9iaWxlIElQdjYgKFBN SVB2NikgZG9lcyBub3QgY3VycmVudGx5IHN1cHBvcnQgbXVsdGljYXN0aW5nLiBCYXNpYyBz dXBwb3J0IGZvciBtdWx0aWNhc3Qgd2l0aCBiaS1kaXJlY3Rpb25hbCB0dW5uZWxpbmcgd2ls bCBiZSBkb2N1bWVudGVkIGZvciBQTUlQdjYgKHdpdGggbm8gbmV3IG1lc3NhZ2UgdHlwZXMg b3IgIGNoYW5nZXMgdG8gdGhlIG1lc3NhZ2UgcGFyYW1ldGVycykuIFBNSVB2NiB3aWxsIGJl IGV4dGVuZGVkIHRvIGFsc28gc3VwcG9ydCBtdWx0aWNhc3Rpbmcgd2l0aCBJUHY0LiBGaW5h bGx5LCBQTUlQdjYgYmFzaWMgbXVsdGljYXN0IHN1cHBvcnQgd2lsbCBiZSBleHRlbmRlZCB0 byBzdXBwb3J0IHJlbW90ZSBzdWJzY3JpcHRpb24gYW5kIGZhc3QgaGFuZG92ZXIuCgpBIG11 bHRpLWhvbWVkIG1vYmlsZSBub2RlIG1heSBqb2luIGEgbXVsdGljYXN0IGdyb3VwIHVzaW5n IHR3byBpbnRlcmZhY2VzIGFuZCByZWNlaXZlIG11bHRpY2FzdCBkYXRhIGluIGR1cGxpY2F0 ZSwgd2hpY2ggc2hvdWxkIGJlIGF2b2lkZWQuIFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZGVm aW5lIG11bHRpLWhvbWluZyBzdXBwb3J0IGZvciBtdWx0aWNhc3QsIGluY2x1ZGluZyBtdWx0 aWNhc3QgZmxvdyBiaW5kaW5nLiAKDQpJbiBwZXJmb3JtaW5nIHRoaXMgd29yaywgdGhlIE11 bHRpbW9iIHdvcmtpbmcgZ3JvdXAgd2lsbCB3b3JrIGNsb3NlbHkgd2l0aCBORVRMTU0NCndv cmtpbmcgZ3JvdXAgYW5kIHdpbGwgY29vcmRpbmF0ZSB3b3JrIG9uIElHTVAvTUxEIGV4dGVu c2lvbnMgd2l0aCB0aGUgTUJPTkVEIHdvcmtpbmcgZ3JvdXAuDQoNCkdPQUxTIGFuZCBNSUxF U1RPTkVTOg0KDQpzaXggbW9udGhzOiANCi0gU3VibWl0IGEgZG9jdW1lbnQgb24gbXVsdGlo b21pbmcgc3VwcG9ydCBmb3IgbXVsdGljYXN0IGFzIGEgQkNQIFJGQy4KLSBTdWJtaXQgYSBk b2N1bWVudCBvbiBtaW5pbWFsIGRlcGxveW1lbnQgZm9yIFBNSVB2NiByZW1vdGUgc3Vic2Ny aXB0aW9uIGZvciBtdWx0aWNhc3QgYXMgYSBCQ1AgUkZDDQoNCk9uZSB5ZWFyOiAKLSBTdWJt aXQgYSBkb2N1bWVudCBvbiBJR01QL01MRCBleHRlbnNpb25zIGZvciBtdWx0aWNhc3QgbW9i aWxpdHkgYXMgYW4gRVhQL1BTIFJGQy4NCi0gU3VibWl0IGEgZG9jdW1lbnQgb24gZXh0ZW5z aW9ucyBmb3IgbXVsdGljYXN0IG1vYmlsaXR5IGluIFBNSVB2NiBhcyBhbiBFWFAvUFMgUkZD Lg0KDQpSZWNoYXJ0ZXIgb3IgY2xvc2Ugd29ya2luZyBncm91cC4K --------------090201010503040709010802-- From asaeda@sfc.wide.ad.jp Tue May 19 01:34:52 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0530E3A63EC for ; Tue, 19 May 2009 01:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.018 X-Spam-Level: ** X-Spam-Status: No, score=2.018 tagged_above=-999 required=5 tests=[AWL=1.114, 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 GB1M+yJUy+Rh for ; Tue, 19 May 2009 01:34:51 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 0A92F3A6B13 for ; Tue, 19 May 2009 01:34:51 -0700 (PDT) Received: from localhost (dhcp-143-188.sfc.wide.ad.jp [203.178.143.188]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id CFC9913D06C4 for ; Tue, 19 May 2009 17:32:15 +0900 (JST) Date: Tue, 19 May 2009 17:36:25 +0900 (JST) Message-Id: <20090519.173625.92563919.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <4A1259A7.9000306@erg.abdn.ac.uk> References: <000901c9d834$cd4e75a0$730c6f0a@china.huawei.com> <4A1259A7.9000306@erg.abdn.ac.uk> X-Mailer: Mew version 6.1 on Emacs 22.2.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Charter for Multimob 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, 19 May 2009 08:34:52 -0000 Hi, > The Multicast mobility (multimob) will develop a set of protocol > extensions and provide guidance appropriate for IPv4 and IPv6 > multicast in a mobile environment. It will consider both source > specific multicast (SSM) and any source multicast (AMS) multicast > models. s/AMS/ASM/ > - Provide guidance and specify methods for multi-homing support for > multicast. I don't know if multihoming support is included in the charter. > - Specify IGMP/MLD extensions methods for reducing join/leave latency. This is ok. > - Specify a dormant mode operation for IGMPv3/MLDv2. A "dormant mode operation" is unclear, or rather unnecessary to be mentioned. In my sense, mobile nodes in dormant mode do not care (and do not receive) any signal (and hence it is unnecessary to consider any protocol operation). Something like tuning or optimization of IGMP/MLD protocol behaviors would be reasonable here? > - Update PMIPv6 to support IPv4 multicast, remote subscription and > fast handover. - Provide guidance for multicast service support without protocol modification - Specify PMIPv6 extensions to support IPv6 multicast including remote subscription and fast handover - Specify PMIPv6 extensions to support IPv4 multicast or Provide guidance for supporting IPv4 multicast (I don't know if IPv4 multicast in PMIPv6 is included or not, but according to the discussions in this ML, someone seems to be very interested in it.) > Multimob will specify a set of extensions to IGMPv3/MLDv2 for mobile > environments. IGMPv3/MLDv2 has been specified for wired networks > with shared links. Mobile nodes also have other needs (e.g. > entering a dormant mode to conserve battery power, minimising the > latency for joining and leaving a group in support of movement). Just "e.g. concerving battery power, minimizing the latency for joining and leaving a group in support of movement" is fine for me. ...snip... > A multi-homed mobile node may join a multicast group using two > interfaces and receive multicast data in duplicate, which should be > avoided. The working group will define multi-homing support for > multicast, including multicast flow binding. I'm not sure, but I may doubt multihoming support for multicast is focused on this group. Regards, -- Hitoshi Asaeda From waehlisch@ieee.org Tue May 19 01:59: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 5B4823A708D for ; Tue, 19 May 2009 01:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOCHG51phrtk for ; Tue, 19 May 2009 01:59:20 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 3B3343A7089 for ; Tue, 19 May 2009 01:59:19 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from imp051023.vpn.mi.fu-berlin.de ([130.133.51.23] helo=mw-thinkpad) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1M6LBu-000OOK-Jl; Tue, 19 May 2009 11:00:54 +0200 Date: Tue, 19 May 2009 11:00:54 +0200 From: Matthias Waehlisch To: Gorry Fairhurst In-Reply-To: <4A1259A7.9000306@erg.abdn.ac.uk> Message-ID: References: <000901c9d834$cd4e75a0$730c6f0a@china.huawei.com> <4A1259A7.9000306@erg.abdn.ac.uk> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="69276718-1490-1242721659=:3284" Content-ID: Cc: multimob@ietf.org Subject: Re: [multimob] Charter for Multimob 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, 19 May 2009 08:59:21 -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. --69276718-1490-1242721659=:3284 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hi Gorry, thanks for optimizing the charter ;)! Typo: * 1st para.: AMS -> ASM Questions @all: * 3th para.: "Update PMIPv6 to support IPv4 multicast [...]" -=20 transition scenarios are a new work item?? Who want to work on this? * Maybe one should switch para. 5 and 6: "Proxy Mobile IPv6 does not=20 currently support multicasting [...]" should be discussed before the=20 optimization of the tunnel convergence problem. 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, 19 May 2009, Gorry Fairhurst wrote: > Liu, Becheret, >=20 > I read the charter proposal, but it took me a little while to > understand exactly what was in scope or not, so I tried a little > rewording... Here is a reworked version of the proposed charter text. I > tried to keep the style simple and in line with other charters I had seen= =2E >=20 > Please see if any of this is improved or not, and do feel free to copy > this (or parts of this) into your charter proposal. >=20 > Best wishes, >=20 > Gorry >=20 >=20 >=20 > Liu Hui wrote: > > I have a few comments on the charter: > > =20 > > 1. The sentence "The WG needs to ascertain whether..." is a useful and= =20 > > general guidence to the work of the group. It should not be restricted= =20 > > within the descriptions of IGMP/MLD parts. I suggest moving it ahead a= s=20 > > the second paragraph of the charter, combined with the sentence "It is = a=20 > > goal of Multimob...". The new second paragraph looks as following (wit= h=20 > > capital words indicating the modification): > > =20 > > " The WG needs to ascertain whether the existing solutions are=20 > > sufficient to solve THESE PROBLEMS, and if not, come up with better=20 > > solutions. It is a goal of Multimob to ascertain backward compatibility= =20 > > with the current implementations of MULTICAST AND MOBILE IP protocols.= =20 > > Message structures supported in the current deployments will not be=20 > > modified. " > > =20 > > 2. For IGMP/MLD part, I feel too many words are explained for "dormant= =20 > > mode" . Because this is only one aspect of this area, I suggest not t= o=20 > > propose it to so important a level. Instead, more general descriptions= =20 > > may be provided. An example is given as: > > =20 > > "IGMP/MLD is originally defined for wired networks with shared links. = =20 > > They are to be evaluated the necessity to take the extention,=20 > > modificaiton and enhancement to make them applicable to wireless and=20 > > mobile environment, and to various wireless link types. The aspects of= =20 > > wireless link characteristics, mobile communication features,=20 > > battery-saving, fast join/leave, and etc. are to be considered when=20 > > making this adaptability." > > =20 > > 3. The passage of "The unicast mobility protocols ..." only lists the= =20 > > current state and problem, but does not gives some specific plan as PMI= P=20 > > does. I suggest add a sentence "Feasible solutions solving the above= =20 > > problems are to be explored" or the like to the end. And It is better= =20 > > to put this passage after the PMIP one because the latter has more=20 > > specific plan and if this is done, the "The unicast mobility protocols= =20 > > ..." should be changed to "Other unicast mobility protocols..."=20 > > =20 > > Please check if they are appropriate. > > =20 > > Best Regards, > > Liu Hui > > =20 > > =20 > >=20 > > -------------------------------------------------------------------= ----- > > *From:* multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org= ] > > *On Behalf Of *Behcet Sarikaya > > *Sent:* 2009=C4=EA5=D4=C218=C8=D5 22:31 > > *To:* multimob@ietf.org > > *Subject:* [multimob] Charter for Multimob > >=20 > > Multimob folks, > > Here is the charter version 01 based on Thomas' road map. > > Please post your comments on the list. > > =20 > > Behcet > >=20 > >=20 > > -----------------------------------------------------------------------= - > >=20 > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob >=20 >=20 --69276718-1490-1242721659=:3284-- From gorry@erg.abdn.ac.uk Tue May 19 02:06: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 28C2A3A6BA4 for ; Tue, 19 May 2009 02:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 gH9RFihMV72h for ; Tue, 19 May 2009 02:06:13 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id EE6563A7074 for ; Tue, 19 May 2009 02:06:02 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n4J97Yex028656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 May 2009 10:07:35 +0100 (BST) Message-ID: <4A1276D6.7000204@erg.abdn.ac.uk> Date: Tue, 19 May 2009 10:07:34 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hitoshi Asaeda References: <000901c9d834$cd4e75a0$730c6f0a@china.huawei.com> <4A1259A7.9000306@erg.abdn.ac.uk> <20090519.173625.92563919.asaeda@sfc.wide.ad.jp> In-Reply-To: <20090519.173625.92563919.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org Subject: Re: [multimob] Charter for Multimob X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 09:06:14 -0000 A few thoughts on your comments... Gorry Hitoshi Asaeda wrote: > Hi, > >> The Multicast mobility (multimob) will develop a set of protocol >> extensions and provide guidance appropriate for IPv4 and IPv6 >> multicast in a mobile environment. It will consider both source >> specific multicast (SSM) and any source multicast (AMS) multicast >> models. > > s/AMS/ASM/ > Oh yes! >> - Provide guidance and specify methods for multi-homing support for >> multicast. > > I don't know if multihoming support is included in the charter. > We need to decide - this appears several times. I included it since, it was on the proposed charter that I read. If we request this iun our charter, I think this need a little more clarification. Multihoming for receivers? For senders? Is this only for mobility? - A little more scope may help us understand whether this makes a good charter item. Our suspect our AD will have views too on this. >> - Specify IGMP/MLD extensions methods for reducing join/leave latency. > > This is ok. > >> - Specify a dormant mode operation for IGMPv3/MLDv2. > > A "dormant mode operation" is unclear, or rather unnecessary to be > mentioned. In my sense, mobile nodes in dormant mode do not care (and > do not receive) any signal (and hence it is unnecessary to consider > any protocol operation). > Something like tuning or optimization of IGMP/MLD protocol behaviors > would be reasonable here? > I have no opinion on dormant mode - anyone wish to speak on why we need to reduce signaling in dormant mode? I think tuning and optimisation and tuning sound weak - I'd prefer the goal to be recommendations for deployment in a mobile environment. >> - Update PMIPv6 to support IPv4 multicast, remote subscription and >> fast handover. > > - Provide guidance for multicast service support without protocol > modification ... Is this really a goal? > - Specify PMIPv6 extensions to support IPv6 multicast including > remote subscription and fast handover > - Specify PMIPv6 extensions to support IPv4 multicast ... sounds ok > or > Provide guidance for supporting IPv4 multicast > (I don't know if IPv4 multicast in PMIPv6 is included or not, but > according to the discussions in this ML, someone seems to be very > interested in it.) ... sounds vague? > >> Multimob will specify a set of extensions to IGMPv3/MLDv2 for mobile >> environments. IGMPv3/MLDv2 has been specified for wired networks >> with shared links. Mobile nodes also have other needs (e.g. >> entering a dormant mode to conserve battery power, minimising the >> latency for joining and leaving a group in support of movement). > > Just "e.g. concerving battery power, minimizing the latency for > joining and leaving a group in support of movement" is fine for me. > > ...snip... > >> A multi-homed mobile node may join a multicast group using two >> interfaces and receive multicast data in duplicate, which should be >> avoided. The working group will define multi-homing support for >> multicast, including multicast flow binding. > > I'm not sure, but I may doubt multihoming support for multicast is > focused on this group. > > Regards, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From asaeda@sfc.wide.ad.jp Tue May 19 02:37:16 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B6583A6B7C for ; Tue, 19 May 2009 02:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.577 X-Spam-Level: ** X-Spam-Status: No, score=2.577 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_05=-1.11, 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 7RkTYM6aoi8u for ; Tue, 19 May 2009 02:37:15 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 606C23A69E8 for ; Tue, 19 May 2009 02:37:15 -0700 (PDT) Received: from localhost (dhcp-143-188.sfc.wide.ad.jp [203.178.143.188]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id B5C7C13D06C4 for ; Tue, 19 May 2009 18:34:32 +0900 (JST) Date: Tue, 19 May 2009 18:38:43 +0900 (JST) Message-Id: <20090519.183843.146024090.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <4A1276D6.7000204@erg.abdn.ac.uk> References: <4A1259A7.9000306@erg.abdn.ac.uk> <20090519.173625.92563919.asaeda@sfc.wide.ad.jp> <4A1276D6.7000204@erg.abdn.ac.uk> X-Mailer: Mew version 6.1 on Emacs 22.2.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Charter for Multimob 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, 19 May 2009 09:37:16 -0000 > >> - Update PMIPv6 to support IPv4 multicast, remote subscription and > >> fast handover. > > - Provide guidance for multicast service support without protocol > > modification > ... Is this really a goal? Not for me.:) But the candidate charter proposed Thomas included both "Multicast listener deployment in PMIPv6: BCP" and "Multicast listener optimizations in PMIPv6 extensions: Exp or PS", and hence I thought there was some concensus to focus on both and you meant the former one here. > > - Specify PMIPv6 extensions to support IPv6 multicast including > > remote subscription and fast handover > ... sounds ok Good. > > - Specify PMIPv6 extensions to support IPv4 multicast > > or > > Provide guidance for supporting IPv4 multicast > > (I don't know if IPv4 multicast in PMIPv6 is included or not, but > > according to the discussions in this ML, someone seems to be very > > interested in it.) > ... sounds vague? Maybe. I personally think supporting IPv4 multicast in PMIPv6 is not urgent and can be postponed, but someone may have strong opinion to include it at this time, right? Regards, -- Hitoshi Asaeda From schmidt@informatik.haw-hamburg.de Tue May 19 06:31: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 0DA183A6808 for ; Tue, 19 May 2009 06:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, 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 rfMDYJwLKtEF for ; Tue, 19 May 2009 06:31:41 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id D26EB3A689B for ; Tue, 19 May 2009 06:31:39 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.22.26.203] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1M6PRT-000AlN-9L; Tue, 19 May 2009 15:33:15 +0200 Message-ID: <4A12B511.9000606@informatik.haw-hamburg.de> Date: Tue, 19 May 2009 15:33:05 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hitoshi Asaeda References: <4A1259A7.9000306@erg.abdn.ac.uk> <20090519.173625.92563919.asaeda@sfc.wide.ad.jp> <4A1276D6.7000204@erg.abdn.ac.uk> <20090519.183843.146024090.asaeda@sfc.wide.ad.jp> In-Reply-To: <20090519.183843.146024090.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] Charter for Multimob 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, 19 May 2009 13:31:42 -0000 Hi Gorry, Hitoshi et al., sorry for joining the discussion late. A general remark, at first: The elevation of PMIPv6 by "Proxy Mobile IPv6 (PMIPv6) does not currently support multicasting." is somewhat misleading ... and - as stated in the following charter sentence - not really true. Instead, I would suggest to reword like follows: "Current mobility extension protocols like PMIPv6, FMIPv6, HMIPv6 ... do not support multicasting explicitely. In particular, the current PMIPv6 specification does not allow for unencapsulated, continued multicast reception at the mobility-agnostic mobile node." Hitoshi Asaeda wrote: >>>> - Update PMIPv6 to support IPv4 multicast, remote subscription and >>>> fast handover. >>> - Provide guidance for multicast service support without protocol >>> modification >> ... Is this really a goal? > > Not for me.:) > But the candidate charter proposed Thomas included both "Multicast > listener deployment in PMIPv6: BCP" and "Multicast listener > optimizations in PMIPv6 extensions: Exp or PS", and hence I thought > there was some concensus to focus on both and you meant the former one > here. > Well, this discussion is going somewhat off the road: "- Provide guidance for multicast service support without protocol modification" is certainly not a goal. In defining a document list, I was proposing a strategy for preparing documents. This was not a list of goals ;) >>> - Specify PMIPv6 extensions to support IPv4 multicast >>> or >>> Provide guidance for supporting IPv4 multicast >>> (I don't know if IPv4 multicast in PMIPv6 is included or not, but >>> according to the discussions in this ML, someone seems to be very >>> interested in it.) >> ... sounds vague? > > Maybe. > I personally think supporting IPv4 multicast in PMIPv6 is not urgent > and can be postponed, but someone may have strong opinion to include > it at this time, right? > There are statements in RFC 5213 request simulatneous IPv4 support. Anyway, I guess this is not really a big issue ... Regarding Multihoming: The statement "A multi-homed mobile node may join a multicast group using two interfaces and receive multicast data in duplicate, which should be avoided." seems to lead to the wrong problem. An MN would most likely not accidentally subscribe to a group on all its interfaces. The more interesting affair seems to be an efficient per-interface subscription management in the case of multihomed mobility. In other words: "what should the MN do to optimize service, resource consumption and overall performance." 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 gorry@erg.abdn.ac.uk Tue May 19 08:23:30 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4800C3A6AED for ; Tue, 19 May 2009 08:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 mGXHkZ9KxqJP for ; Tue, 19 May 2009 08:23:29 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id CEE9C3A6E1D for ; Tue, 19 May 2009 08:23:27 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n4JFP0q1009044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 May 2009 16:25:00 +0100 (BST) Message-ID: <4A12CF4C.2020009@erg.abdn.ac.uk> Date: Tue, 19 May 2009 16:25:00 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <4A1259A7.9000306@erg.abdn.ac.uk> <20090519.173625.92563919.asaeda@sfc.wide.ad.jp> <4A1276D6.7000204@erg.abdn.ac.uk> <20090519.183843.146024090.asaeda@sfc.wide.ad.jp> <4A12B511.9000606@informatik.haw-hamburg.de> In-Reply-To: <4A12B511.9000606@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org Subject: Re: [multimob] Charter for Multimob X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 15:23:30 -0000 I'd be happy for someone to make a new charter proposal drawing together the various inputs for this round, ... We're getting there... I'm busy currently, so I can't do this over the next few days. I would however be happy to comment more when we next get a stable version. Gorry Thomas C. Schmidt wrote: > Hi Gorry, Hitoshi et al., > > sorry for joining the discussion late. > > A general remark, at first: > > The elevation of PMIPv6 by "Proxy Mobile IPv6 (PMIPv6) does not > currently support multicasting." is somewhat misleading ... and - as > stated in the following charter sentence - not really true. > > Instead, I would suggest to reword like follows: > > "Current mobility extension protocols like PMIPv6, FMIPv6, HMIPv6 ... do > not support multicasting explicitely. In particular, the current PMIPv6 > specification does not allow for unencapsulated, continued multicast > reception at the mobility-agnostic mobile node." > > > Hitoshi Asaeda wrote: >>>>> - Update PMIPv6 to support IPv4 multicast, remote subscription and >>>>> fast handover. >>>> - Provide guidance for multicast service support without protocol >>>> modification >>> ... Is this really a goal? >> >> Not for me.:) >> But the candidate charter proposed Thomas included both "Multicast >> listener deployment in PMIPv6: BCP" and "Multicast listener >> optimizations in PMIPv6 extensions: Exp or PS", and hence I thought >> there was some concensus to focus on both and you meant the former one >> here. >> > > Well, this discussion is going somewhat off the road: "- Provide > guidance for multicast service support without protocol > modification" is certainly not a goal. In defining a document list, I > was proposing a strategy for preparing documents. This was not a list of > goals ;) > > >>>> - Specify PMIPv6 extensions to support IPv4 multicast >>>> or >>>> Provide guidance for supporting IPv4 multicast >>>> (I don't know if IPv4 multicast in PMIPv6 is included or not, but >>>> according to the discussions in this ML, someone seems to be very >>>> interested in it.) >>> ... sounds vague? >> >> Maybe. >> I personally think supporting IPv4 multicast in PMIPv6 is not urgent >> and can be postponed, but someone may have strong opinion to include >> it at this time, right? >> > > There are statements in RFC 5213 request simulatneous IPv4 support. > Anyway, I guess this is not really a big issue ... > > Regarding Multihoming: > > The statement > "A multi-homed mobile node may join a multicast group using two > interfaces and receive multicast data in duplicate, which should be > avoided." > seems to lead to the wrong problem. An MN would most likely not > accidentally subscribe to a group on all its interfaces. The more > interesting affair seems to be an efficient per-interface subscription > management in the case of multihomed mobility. In other words: "what > should the MN do to optimize service, resource consumption and overall > performance." > > > Best regards, > > Thomas > From behcetsarikaya@yahoo.com Tue May 19 08:44: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 5DC7C3A6F02 for ; Tue, 19 May 2009 08:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.467, 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 E7Rr36E8lFkW for ; Tue, 19 May 2009 08:44:35 -0700 (PDT) Received: from n9.bullet.re3.yahoo.com (n9.bullet.re3.yahoo.com [68.142.237.94]) by core3.amsl.com (Postfix) with SMTP id 063F93A68B9 for ; Tue, 19 May 2009 08:44:34 -0700 (PDT) Received: from [68.142.230.28] by n9.bullet.re3.yahoo.com with NNFMP; 19 May 2009 15:46:10 -0000 Received: from [67.195.9.82] by t1.bullet.re2.yahoo.com with NNFMP; 19 May 2009 15:46:09 -0000 Received: from [67.195.9.101] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 19 May 2009 15:46:09 -0000 Received: from [127.0.0.1] by omp105.mail.gq1.yahoo.com with NNFMP; 19 May 2009 15:46:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 643757.51716.bm@omp105.mail.gq1.yahoo.com Received: (qmail 86838 invoked by uid 60001); 19 May 2009 15:46:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242747969; bh=b8LmNnyMWN9dSrC7PV9OXxeO7PM6ibpox90Srw70JZw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=g3GttdSd61VaS41PVbxH4E3OD0mlrtiQIYi8SqAh2CocJ/bJtl2/6/a3MY3DUX2ASE8grp9fwKL5uDu/fsJ+uu8YLhyM3Cv7UihlNmsE8sSCQUSTIfIXlTb7JbfhJbYjOpNfF5UqHsCcCu+kiEiKC1E4jaSwArpMWlCeIRe63Ow= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=LU8oyI9ojE1m0dA+2+d2aBwWHxWUkGqZV7F4cgA9VSy69s9u9YhYBNfnso6m9uaSiCJwmDGyPtBr4xEEgNwA28WGsW8QqVAWzrhxXsMJv6zXIZ1gfOOWhE8wdT96d15MiDZj7/8D0Ms4kgwYRaLmKTGTQ/fdns7FIX/0zibCcbI=; Message-ID: <336914.85836.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: yZJUL2oVM1mgvXNlbF4UyX1.qSyVembPNEIHOcgP2FCjVSVndXFYK.irneyHW7yYaatwJwc3zbj8DX3CmC_FnHTObC.elprOduYpddbiUBhZQzizuHtR17l0pz6d2ssYAYSOZXabZR2ex8nBJwBVJ0bZ55dmNABtDxRc7r5L9egR2PsF3oxsGm0zqi3frLD_iLZPLBulTpSHs0unizdqn1gzZcIaAGKyLiGItrl5qsTKrq4qWT2px1SUkw0KjCJNOnvNY71gJYm29GTFyYfiTIQf4Mu6rCj.RfBn.dFPi9RCbBtpcXblE8C92qPWmDE8V.Dh8ipOlkPv3AIObVKG_A-- Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Tue, 19 May 2009 08:46:09 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 Date: Tue, 19 May 2009 08:46:09 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1217458013-1242747969=:85836" Subject: [multimob] Multimob charter v2 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, 19 May 2009 15:44:36 -0000 --0-1217458013-1242747969=:85836 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,=0A=A0 I updated the charter based on the discussions.=0A=0ARegards,= =0A=0ABehcet=0A=0A=0A --0-1217458013-1242747969=:85836 Content-Type: text/plain; name="multimobcharter02.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="multimobcharter02.txt" Ck11bHRpY2FzdCBNb2JpbGl0eSAobXVsdGltb2IpDQoNCkNoYWlyczoNClRC RA0KDQpJbnRlcm5ldCBBcmVhIChpbnQpIERpcmVjdG9yczoNCkphcmkgQXJr a28gPGphcmkuYXJra29AcGl1aGEubmV0Pg0KTWFyayBUb3duc2xleSA8dG93 bnNsZXlAY2lzY28uY29tPiANCg0KSW50ZXJuZXQgQXJlYSBBZHZpc29yOg0K SmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+DQoNClNlY3VyaXR5 IEFyZWEgQWR2aXNvcjoNCk1hcnNoYWxsIEV1YmFua3MgPHRtZUBhbWVyaWNh ZnJlZS50dj4uDQoNCk1haWxpbmcgTGlzdHM6DQpHZW5lcmFsIERpc2N1c3Np b246IG11bHRpbW9iQGlldGYub3JnDQpTdWJzY3JpYmUgb25saW5lIGF0OiBo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aW1v Yg0KDQpEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwDQoNClRoZSBNdWx0 aWNhc3QgbW9iaWxpdHkgKG11bHRpbW9iKSB3aWxsIGRldmVsb3AgYSBzZXQg b2YgcHJvdG9jb2wgZXh0ZW5zaW9ucyBhbmQgcHJvdmlkZSBndWlkYW5jZSBh cHByb3ByaWF0ZSBmb3IgSVB2NCBhbmQgSVB2NiBtdWx0aWNhc3QgaW4gYSBt b2JpbGUgZW52aXJvbm1lbnQuIEl0IHdpbGwgY29uc2lkZXIgYm90aCBzb3Vy Y2Ugc3BlY2lmaWMgbXVsdGljYXN0IChTU00pICBhbmQgYW55IHNvdXJjZSBt dWx0aWNhc3QgKEFTTSkgbXVsdGljYXN0IG1vZGVscy4KClRoZSBzY29wZSBv ZiB3b3JrIHdpbGwgYmUgbGltaXRlZCB0byBncm91cCBtYW5hZ2VtZW50IGFu ZCBtb2JpbGUgSVAgcHJvdG9jb2xzIC0gcHJveGllZCBvciBjbGllbnQtYmFz ZWQuIFdvcmsgcmVxdWlyaW5nIG1vZGlmaWNhdGlvbnMgb2YgbXVsdGljYXN0 IHJvdXRpbmcgcHJvdG9jb2xzIChQSU0tU00sIFBJTS1ETSwgZXRjLikgaXMg b3V0IG9mIHNjb3BlLiBTcGVjaWZpYyBnb2FscyBhcmU6CiAgCi0gU3BlY2lm eSBJR01QL01MRCBleHRlbnNpb25zIG1ldGhvZHMgZm9yIHJlZHVjaW5nIGpv aW4vbGVhdmUgbGF0ZW5jeS4KLSBTcGVjaWZ5IGEgZG9ybWFudCBtb2RlIG9w ZXJhdGlvbiBmb3IgSUdNUHYzL01MRHYyLgotIFVwZGF0ZSBQTUlQdjYgdG8g c3VwcG9ydCByZW1vdGUgc3Vic2NyaXB0aW9uLCBmYXN0IGhhbmRvdmVyIGFu ZCBJUHY0IG11bHRpY2FzdC4gDQotIFByb3ZpZGUgZ3VpZGFuY2UgYW5kIHNw ZWNpZnkgbWV0aG9kcyBmb3IgbXVsdGktaG9taW5nIHN1cHBvcnQgZm9yIG11 bHRpY2FzdC4NCg0KTXVsdGltb2Igd2lsbCBzcGVjaWZ5IGEgc2V0IG9mIGV4 dGVuc2lvbnMgdG8gSUdNUHYzL01MRHYyIGZvciBtb2JpbGUgZW52aXJvbm1l bnRzLiBJR01QdjMvTUxEdjIgaGFzIGJlZW4gc3BlY2lmaWVkIGZvciB3aXJl ZCBuZXR3b3JrcyB3aXRoIHNoYXJlZCBsaW5rcy4gTW9iaWxlIG5vZGVzIGFs c28gaGF2ZSBvdGhlciBuZWVkcyAoZS5nLiAgZW50ZXJpbmcgYSBkb3JtYW50 IG1vZGUgdG8gY29uc2VydmUgYmF0dGVyeSBwb3dlciwgbWluaW1pc2luZyB0 aGUgbGF0ZW5jeSBmb3Igam9pbmluZyBhbmQgbGVhdmluZyBhIGdyb3VwIGlu IHN1cHBvcnQgb2YgbW92ZW1lbnQpLiAgVGhlIHdvcmtpbmcgZ3JvdXAgd2ls bCBhc3Nlc3MgZXhpc3Rpbmcgc29sdXRpb25zIGZvciBncm91cCBtYW5hZ2Vt ZW50LCBhbmQgZGV0ZXJtaW5lIGlmIHRoZXNlIG1ldGhvZHMgYXJlIHN1ZmZp Y2llbnQuIFRoaXMgd2lsbCBpbmNsdWRlIGRlZmluaW5nIGJlc3QgY3VycmVu dCBwcmFjdGljZSBmb3Igc2VsZWN0aW9uIG9mIHRpbWVyIHZhbHVlcyBhbmQg cHJvdG9jb2wgcGFyYW1ldGVycy4gSWYgdGhlc2UgbWV0aG9kcyBhcmUgbm90 IHN1ZmZpY2llbnQsIHRoZSB3b3JraW5nIGdyb3VwIHNoYWxsIHByb3Bvc2Ug bmV3IHNvbHV0aW9ucyBhcyB1cGRhdGVzIHRvIGV4aXN0aW5nIHByb3RvY29s cyAoaW5jbHVkaW5nIHBvc3NpYmxlIGludHJvZHVjdGlvbiBvZiBhZGRpdGlv bmFsIG1lc3NhZ2UgdHlwZXMpLiBJdCBpcyBhIGdvYWwgZm9yIHRoZSB3b3Jr aW5nIGdyb3VwIHRvIGVuc3VyZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdp dGggdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIG9mIGdyb3VwIG1hbmFn ZW1lbnQgcHJvdG9jb2xzLiBNZXNzYWdlIHN0cnVjdHVyZXMgc3VwcG9ydGVk IGluIGN1cnJlbnQgZGVwbG95ZWQgbmV0d29ya3Mgd2lsbCBub3QgYmUgbW9k aWZpZWQuDQoKVW5pY2FzdCBtb2JpbGl0eSBwcm90b2NvbHMgKE1vYmlsZSBJ UHY2LCBEdWFsLVN0YWNrIE1vYmlsZSBJUHY2IGFuZCBhbHNvIE1vYmlsZSBJ UHY0KSBwcm92aWRlIGJhc2ljIG11bHRpY2FzdCBzdXBwb3J0IGFuZCBlbmFi bGUgbW9iaWxlIG5vZGVzIHRvIHBlcmZvcm0gYmktZGlyZWN0aW9uYWwgdHVu bmVsaW5nIGFuZCByZWNlaXZlIG11bHRpY2FzdCB0cmFmZmljIGFuY2hvcmVk IGF0IHRoZSBob21lIGFnZW50LiBIb3dldmVyLCBzdWNoIGJhc2ljIHN1cHBv cnQgc3VmZmVycyBmcm9tIHRoZSAnYXZhbGFuY2hlJyBwcm9ibGVtIGFzIHRo ZSBob21lIGFnZW50cyByZXBsaWNhdGUgdGhlIHBhY2tldHMgYW5kIHVuaWNh c3QgdGhlbSB0byB0aGUgbW9iaWxlIG5vZGVzIGFzIHdlbGwgYXMgZnJvbSBu b24tb3B0aW1hbCwgdHJpYW5ndWxhciByb3V0aW5nLCAncmVtb3RlIHN1YnNj cmlwdGlvbicgc3VmZmVycyBmcm9tIHBvc3NpYmxlIGxvc3Mgb2YgZGF0YSBk dXJpbmcgaGFuZG92ZXJzLiBUaGUgV0cgd2lsbCBhZGRyZXNzIHRoZXNlIGlz c3VlcyB3aXRoaW4gdGhlIGNvbnRleHQgb2YgUHJveHkgTW9iaWxlIElQdjYg KFBNSVB2NikuCgpDdXJyZW50bHkgUE1JUHY2IChhbmQgbW9iaWxpdHkgZXh0 ZW5zaW9uIHByb3RvY29scyBsaWtlICBGTUlQdjYgYW5kIEhNSVB2NikgZG9l cyBub3QgIHN1cHBvcnQgbXVsdGljYXN0aW5nIGV4cGxpY2l0bHkuIEJhc2lj IHN1cHBvcnQgZm9yIG11bHRpY2FzdCB3aXRoIGJpLWRpcmVjdGlvbmFsIHR1 bm5lbGluZyB3aWxsIGJlIGRvY3VtZW50ZWQgZm9yIFBNSVB2NiAod2l0aCBu byBuZXcgbWVzc2FnZSB0eXBlcyBvciAgY2hhbmdlcyB0byB0aGUgbWVzc2Fn ZSBwYXJhbWV0ZXJzKS4gUE1JUHY2IHdpbGwgYmUgZXh0ZW5kZWQgdG8gYWxz byBzdXBwb3J0IG11bHRpY2FzdGluZyB3aXRoIElQdjQuIEZpbmFsbHksIFBN SVB2NiBiYXNpYyBtdWx0aWNhc3Qgc3VwcG9ydCB3aWxsIGJlIGV4dGVuZGVk IHRvIHN1cHBvcnQgcmVtb3RlIHN1YnNjcmlwdGlvbiBhbmQgZmFzdCBoYW5k b3Zlci4KCkEgbXVsdGktaG9tZWQgbW9iaWxlIG5vZGUgbWF5IHdpc2ggdG8g am9pbiBtdWx0aWNhc3QgZ3JvdXBzIGFuZCB0byBkaXJlY3QgZGlmZmVyZW50 IG11bHRpY2FzdCBmbG93cyB0byBpdHMgaW50ZXJmYWNlcy4gVGhlIHdvcmtp bmcgZ3JvdXAgd2lsbCBkZWZpbmUgbXVsdGktaG9taW5nIHN1cHBvcnQgZm9y IG11bHRpY2FzdCwgaW5jbHVkaW5nIGFuIGVmZmljaWVudCBwZXItaW50ZXJm YWNlIHN1YnNjcmlwdGlvbiBtYW5hZ2VtZW50IGluIHRoZSBjYXNlIG9mIG11 bHRpLWhvbWVkIG1vYmlsaXR5IGFuZCBtdWx0aWNhc3QgZmxvdyBiaW5kaW5n LiAKDQpJbiBwZXJmb3JtaW5nIHRoaXMgd29yaywgdGhlIE11bHRpbW9iIHdv cmtpbmcgZ3JvdXAgd2lsbCB3b3JrIGNsb3NlbHkgd2l0aCBORVRMTU0NCndv cmtpbmcgZ3JvdXAgYW5kIHdpbGwgY29vcmRpbmF0ZSB3b3JrIG9uIElHTVAv TUxEIGV4dGVuc2lvbnMgd2l0aCB0aGUgTUJPTkVEIHdvcmtpbmcgZ3JvdXAu DQoNCkdPQUxTIGFuZCBNSUxFU1RPTkVTOg0KDQpzaXggbW9udGhzOiANCi0g U3VibWl0IGEgZG9jdW1lbnQgb24gbXVsdGlob21pbmcgc3VwcG9ydCBmb3Ig bXVsdGljYXN0IGFzIGEgQkNQIFJGQy4KLSBTdWJtaXQgYSBkb2N1bWVudCBv biBtaW5pbWFsIGRlcGxveW1lbnQgZm9yIFBNSVB2NiByZW1vdGUgc3Vic2Ny aXB0aW9uIGZvciBtdWx0aWNhc3QgYXMgYSBCQ1AgUkZDDQoNCk9uZSB5ZWFy OiAKLSBTdWJtaXQgYSBkb2N1bWVudCBvbiBJR01QL01MRCBleHRlbnNpb25z IGZvciBtdWx0aWNhc3QgbW9iaWxpdHkgYXMgYW4gRVhQL1BTIFJGQy4NCi0g U3VibWl0IGEgZG9jdW1lbnQgb24gZXh0ZW5zaW9ucyBmb3IgbXVsdGljYXN0 IG1vYmlsaXR5IGluIFBNSVB2NiBhcyBhbiBFWFAvUFMgUkZDLg0KDQpSZWNo YXJ0ZXIgb3IgY2xvc2Ugd29ya2luZyBncm91cC4K --0-1217458013-1242747969=:85836-- From Dirk.von-Hugo@telekom.de Tue May 19 09:14: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 002B23A6E93 for ; Tue, 19 May 2009 09:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.050, 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 djxLTUo6w1dz for ; Tue, 19 May 2009 09:14:31 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 6D2113A6EC7 for ; Tue, 19 May 2009 09:14:29 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 19 May 2009 18:15:54 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 May 2009 18:15:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 May 2009 18:15:57 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC8027848F67320@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <336914.85836.qm@web111416.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Multimob charter v2 thread-index: AcnYmPO3j7u5vdV0RPiVymQFB5OgwgAAobcw References: <336914.85836.qm@web111416.mail.gq1.yahoo.com> From: To: , X-OriginalArrivalTime: 19 May 2009 16:15:52.0502 (UTC) FILETIME=[14AB8560:01C9D89D] Subject: Re: [multimob] Multimob charter v2 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, 19 May 2009 16:14:32 -0000 Dear Behcet, all, Thanks for your effort towards progress of the charter. I agree mainly = with the latest version. Just for reasons of logic and readability I = would however prefer the proposal by Thomas - i.e. after stating the = problems with unicast mobility protocols (...loss of data during = handovers.) not to continue with the somewhat disruptive sentence 'The = WG will address these issues within the context of Proxy Mobile IPv6 = (PMIPv6).' but rather with 'Current mobility extension protocols like PMIPv6, FMIPv6, HMIPv6 ... do = (also) not support multicasting explicitely. In particular, the current = PMIPv6=20 specification does not allow for unencapsulated, continued multicast=20 reception at the mobility-agnostic mobile node.' And BTW we should include the new AD Ralph Droms :-) Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Behcet Sarikaya Gesendet: Dienstag, 19. Mai 2009 17:46 An: multimob@ietf.org Betreff: [multimob] Multimob charter v2 Hi all, =A0 I updated the charter based on the discussions. Regards, Behcet =20 From behcetsarikaya@yahoo.com Tue May 19 11:51: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 7C08A3A70C3 for ; Tue, 19 May 2009 11:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.462, 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 vn+DAGIMOZbj for ; Tue, 19 May 2009 11:51:21 -0700 (PDT) Received: from n4.bullet.mail.re4.yahoo.com (n4.bullet.mail.re4.yahoo.com [206.190.56.23]) by core3.amsl.com (Postfix) with SMTP id EE73B28C180 for ; Tue, 19 May 2009 11:50:48 -0700 (PDT) Received: from [68.142.230.28] by n4.bullet.re4.yahoo.com with NNFMP; 19 May 2009 18:52:23 -0000 Received: from [67.195.9.82] by t1.bullet.re2.yahoo.com with NNFMP; 19 May 2009 18:52:23 -0000 Received: from [67.195.9.110] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 19 May 2009 18:52:23 -0000 Received: from [127.0.0.1] by omp114.mail.gq1.yahoo.com with NNFMP; 19 May 2009 18:50:10 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 576437.27023.bm@omp114.mail.gq1.yahoo.com Received: (qmail 15470 invoked by uid 60001); 19 May 2009 18:52:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242759143; bh=BGONpQWJZgZox22xxO0tjCyftaZ3qIpf4o/px/59RUM=; 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=vierdacd4yW5wBmmEcrmEEi+pJ1haLtDygyAXZ9YEXLTD6qA0o4jA+6hwCqyWPmFmIRstR0V/ai/3at6aHr2d45lkdTc9IKeuYl+uTlsojkieY2cYv0bboYSFD2OmBvOEdSpbQTvIFpBf5qRg0M+LULBsjIjm/GG12zZeqX10YU= 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=QOIr/Wdv4UnQGe4FvAmt2+gX6gFG5+SYARmwu5cRw4z2dP2JHNa/ZmXqzLp0S7gGB402BwJAyXYmROIK/aXG2C41MWQ/4+9Eawsjcl5C7CtVDr+QRbqMsCZBjlNUFQzXfwFUOmWShF9ynQfKi+wNVDITIAxvEtCTmFyBhuHEZHg=; Message-ID: <157595.14595.qm@web111408.mail.gq1.yahoo.com> X-YMail-OSG: bZ2x.E8VM1kWfory7aO6ZPXXutraXG5ctv2EZEbQeTkUrbLgBJvClnxveilVZbnJFuX4j.3bIilT4oRI_pnFWMwkkA7dvYq7rSfIUBPDseejr2IUrntC6tQ7HpmaHTMKcekdp0gcA_8tZFWW3meGYHA3hdve5tpIAnylmPHt9baKFEqZTy41qFeWleqgTGUtX3w_wv4PYrlYsTQ.496SnAjBukGpOxTrbIIrKUxDbM0plkgrskOr1OalTWXmOldx58IHnm2kAdxtizVVIMlXxXJDI01so3EiPaCLdOH6s5vE6ZZpfGgYE._9s.u9.V7HSBF5XJAO Received: from [206.16.17.212] by web111408.mail.gq1.yahoo.com via HTTP; Tue, 19 May 2009 11:52:23 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <336914.85836.qm@web111416.mail.gq1.yahoo.com> <643B0A1D1A13AB498304E0BBC8027848F67320@S4DE8PSAAQC.mitte.t-com.de> Date: Tue, 19 May 2009 11:52:23 -0700 (PDT) From: Behcet Sarikaya To: Dirk.von-Hugo@telekom.de, multimob@ietf.org In-Reply-To: <643B0A1D1A13AB498304E0BBC8027848F67320@S4DE8PSAAQC.mitte.t-com.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] Multimob charter v2 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, 19 May 2009 18:51:22 -0000 Hi Dirk,=0A=A0 Pls see my replies below.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A= =0A----- Original Message ----=0AFrom: "Dirk.von-Hugo@telekom.de" =0ATo: sarikaya@ieee.org; multimob@ietf.org=0ASent: Tuesda= y, May 19, 2009 11:15:57 AM=0ASubject: Re: [multimob] Multimob charter v2= =0A=0ADear Behcet, all,=0AThanks for your effort towards progress of the ch= arter. I agree mainly with the latest version. Just for reasons of logic an= d readability I would however prefer the proposal by Thomas - i.e. after st= ating the problems with unicast mobility protocols (...loss of data during = handovers.) not to continue with the somewhat disruptive sentence 'The WG w= ill address these issues within the context of Proxy Mobile IPv6 (PMIPv6).'= but rather with=0A=0A[behcet] It sounds disruptive but it expresses better= what we have in the charter, esp. the work items. Also this sentence conne= cts better with the next paragraph.=0A=0A'Current mobility extension protoc= ols like PMIPv6, FMIPv6, HMIPv6 ... do =0A(also) not support multicasting e= xplicitely. In particular, the current PMIPv6 =0Aspecification does not all= ow for unencapsulated, continued multicast =0Areception at the mobility-agn= ostic mobile node.'=0A=0A[behcet] I think this sentence provide too much de= tail we possibly don't need in a charter.=0A=0AAnd BTW we should include th= e new AD Ralph Droms :-)=0A=0ABest regards=0A=0ADirk=0A= =0A=0A-----Urspr=FCngliche Nachricht-----=0AVon: multimob-bounces@ietf.org = [mailto:multimob-bounces@ietf.org] Im Auftrag von Behcet Sarikaya=0AGesende= t: Dienstag, 19. Mai 2009 17:46=0AAn: multimob@ietf.org=0ABetreff: [multimo= b] Multimob charter v2=0A=0AHi all,=0A=A0 I updated the charter based on th= e discussions.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=A0 =A0 =A0 =0A___________= ____________________________________=0Amultimob mailing list=0Amultimob@iet= f.org=0Ahttps://www.ietf.org/mailman/listinfo/multimob=0A=0A=0A=0A From suresh.krishnan@ericsson.com Tue May 19 15:17:29 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2494928C36E for ; Tue, 19 May 2009 15:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 2We1gdNDW8nk for ; Tue, 19 May 2009 15:17:28 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 06C1A28C383 for ; Tue, 19 May 2009 15:16:09 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n4JMSOlh014194 for ; Tue, 19 May 2009 17:28:24 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 17:17:24 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 17:17:24 -0500 Message-ID: <4A132FAF.2040602@ericsson.com> Date: Tue, 19 May 2009 18:16:15 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: multimob@ietf.org References: <991096.55707.qm@web111410.mail.gq1.yahoo.com> In-Reply-To: <991096.55707.qm@web111410.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2009 22:17:24.0961 (UTC) FILETIME=[96621510:01C9D8CF] Subject: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 19 May 2009 22:17:29 -0000 Hi Folks, Before we try for a BOF we need to answer the following question so that we do not spend the BOF discussing whether PMIPv6 already supports multicast or not. * Is the performance penalty experienced by the operator using PMIPv6 (AS IS) with multicast significant enough to warrant changing PMIPv6 and/or the multicast protocols? This question needs to be answered by the operators who are planning to deploy PMIPv6 and multicast along with deployment scenarios (if possible) before we can make any headway. Thanks Suresh From liuhui47967@huawei.com Tue May 19 18:53: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 BAC5F28C152 for ; Tue, 19 May 2009 18:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.447 X-Spam-Level: X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[AWL=2.152, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uYnr4UVsNV6 for ; Tue, 19 May 2009 18:53:01 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id C41E23A680D for ; Tue, 19 May 2009 18:53:00 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJX00DP56MYF9@szxga02-in.huawei.com> for multimob@ietf.org; Wed, 20 May 2009 09:54:34 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJX005416MXUF@szxga02-in.huawei.com> for multimob@ietf.org; Wed, 20 May 2009 09:54:33 +0800 (CST) Received: from l47967b ([10.111.12.115]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJX001046MXWA@szxml06-in.huawei.com> for multimob@ietf.org; Wed, 20 May 2009 09:54:33 +0800 (CST) Date: Wed, 20 May 2009 09:54:33 +0800 From: Liu Hui In-reply-to: <336914.85836.qm@web111416.mail.gq1.yahoo.com> To: 'Behcet Sarikaya' , multimob@ietf.org Message-id: <001b01c9d8ed$ec1fb700$730c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Thread-index: AcnYmPhZYvN0LxZNSaOloOhWq/FcigAUYV1g Subject: Re: [multimob] Multimob charter v2 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, 20 May 2009 01:53:07 -0000 Behcet, I have some questions in the charter v2: 1 " Unicast mobility protocols (Mobile IPv6, Dual-Stack Mobile IPv6 and = also Mobile IPv4)..." Why in the beginning of this paragraph MIPv6, Dual-Stack Mobile IPv6 and = MIPv4 is mentioned, while in the end they should be considered "within = the context of Proxy Mobile IPv6 (PMIPv6)" ? 2 "Currently PMIPv6 (and mobility extension protocols like FMIPv6 and = HMIPv6)" :=20 Why FMIP and HMIP are mentioned combined with PMIP, what's the = relationship between PMIP and FMIP and HMIP ? I feel it's not so clear to illustrate so many mip protocols and make = this classification Because the wg hasn't yet seen clearly many works for other unicast MIP = protocols except for PMIP. These protocols should be mentioned with = some examples instead being listed "exhaustively". Otherwise the charter = may look too inclusive or miscellaneous to be accepted. Best Regards, Liu Hui > -----Original Message----- > From: multimob-bounces@ietf.org=20 > [mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya > Sent: 2009=E5=B9=B45=E6=9C=8819=E6=97=A5 23:46 > To: multimob@ietf.org > Subject: [multimob] Multimob charter v2 >=20 > Hi all, > I updated the charter based on the discussions. >=20 > Regards, >=20 > Behcet >=20 >=20 > =20 From gorry@erg.abdn.ac.uk Wed May 20 02:02: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 0970C28C365 for ; Wed, 20 May 2009 02:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 fG3UaooE-68W for ; Wed, 20 May 2009 02:02:02 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id C88223A6B77 for ; Wed, 20 May 2009 02:02:01 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n4K92uCc005410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 20 May 2009 10:02:56 +0100 (BST) Message-ID: <4A13C740.1060605@erg.abdn.ac.uk> Date: Wed, 20 May 2009 10:02:56 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Liu Hui References: <001b01c9d8ed$ec1fb700$730c6f0a@china.huawei.com> In-Reply-To: <001b01c9d8ed$ec1fb700$730c6f0a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org Subject: Re: [multimob] Multimob charter v2 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 09:02:03 -0000 I see what you are saying, and this really depends on what the WG has hopes to study.... others please "speak-up" too on this list. I'd personally like to keep the text focussed on the goals, but we should also identify any wider possibilities in the (near) future - if people hope to work on FMIP or HMIP, it could be OK to include this in the charter text. The *goals* listed should be driven by need and current energy (we can update these later with IESG support, and would not necessarily need to re-charter). The Milestones should be *very* focussed, and specific. If approved, an AD can add new milestones consistent with the charter text and goals. That said - would anyone like to say something about their hopes (in future or otherwise) of working on HMIP or FMIP - if nobody thinks this is important, we can indeed safely condense these words.... Gorry Liu Hui wrote: > Behcet, > > I have some questions in the charter v2: > > 1 " Unicast mobility protocols (Mobile IPv6, Dual-Stack Mobile IPv6 and also Mobile IPv4)..." > > Why in the beginning of this paragraph MIPv6, Dual-Stack Mobile IPv6 and MIPv4 is mentioned, while in the end they should be considered "within the context of Proxy Mobile IPv6 (PMIPv6)" ? > > 2 "Currently PMIPv6 (and mobility extension protocols like FMIPv6 and HMIPv6)" : > > Why FMIP and HMIP are mentioned combined with PMIP, what's the relationship between PMIP and FMIP and HMIP ? > > > I feel it's not so clear to illustrate so many mip protocols and make this classification > > Because the wg hasn't yet seen clearly many works for other unicast MIP protocols except for PMIP. These protocols should be mentioned with some examples instead being listed "exhaustively". Otherwise the charter may look too inclusive or miscellaneous to be accepted. > > > > Best Regards, > > Liu Hui > > > >> -----Original Message----- >> From: multimob-bounces@ietf.org >> [mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya >> Sent: 2009å¹´5月19æ—¥ 23:46 >> To: multimob@ietf.org >> Subject: [multimob] Multimob charter v2 >> >> Hi all, >> I updated the charter based on the discussions. >> >> Regards, >> >> Behcet >> >> >> > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > From liuhui47967@huawei.com Wed May 20 03:26: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 65F953A6CA1 for ; Wed, 20 May 2009 03:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbKMGvlpffeB for ; Wed, 20 May 2009 03:26:23 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 539713A6CD6 for ; Wed, 20 May 2009 03:26:16 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJX00952SJS31@szxga04-in.huawei.com> for multimob@ietf.org; Wed, 20 May 2009 17:47:52 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJX00K6RSJSFJ@szxga04-in.huawei.com> for multimob@ietf.org; Wed, 20 May 2009 17:47:52 +0800 (CST) Received: from l47967b ([10.111.12.115]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJX00G7ISJRRI@szxml04-in.huawei.com> for multimob@ietf.org; Wed, 20 May 2009 17:47:52 +0800 (CST) Date: Wed, 20 May 2009 17:47:51 +0800 From: Liu Hui In-reply-to: <4A13C740.1060605@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk Message-id: <001f01c9d930$0ad8fca0$730c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcnZKjK+nbW7pgzgTKO6Y2H0DK7hNgAAZXgQ Cc: multimob@ietf.org Subject: Re: [multimob] Multimob charter v2 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, 20 May 2009 10:26:24 -0000 Hi Gorry, I agree that the work of the group should not be too restrictive. Previously I think if a unicast MIP protocol itself is too complicated, = it even has little chance to be deployed when incoorperated with multicast support. Thus maybe not all of the MIP protocols will produce feasible solutions. But maybe it is too earlier to make this judgment or = decision. =20 Of course it's OK to include all of them at present and make adjustment = of the charter in the future according to the situations of the work = presented, as you suggested. As long as there is interests in the work, it should = not be excluded from the group.=20 Thanks, Liu Hui=20 >=20 > I see what you are saying, and this really depends on what=20 > the WG has hopes to study.... others please "speak-up" too on=20 > this list. >=20 > I'd personally like to keep the text focussed on the goals,=20 > but we should also identify any wider possibilities in the=20 > (near) future - if people hope to work on FMIP or HMIP, it=20 > could be OK to include this in the charter text. >=20 > The *goals* listed should be driven by need and current=20 > energy (we can update these later with IESG support, and=20 > would not necessarily need to re-charter). >=20 > The Milestones should be *very* focussed, and specific. If=20 > approved, an AD can add new milestones consistent with the=20 > charter text and goals. >=20 > That said - would anyone like to say something about their=20 > hopes (in future or otherwise) of working on HMIP or FMIP -=20 > if nobody thinks this is important, we can indeed safely=20 > condense these words.... >=20 > Gorry >=20 >=20 > Liu Hui wrote: > > Behcet, > >=20 > > I have some questions in the charter v2: > >=20 > > 1 " Unicast mobility protocols (Mobile IPv6, Dual-Stack=20 > Mobile IPv6 and also Mobile IPv4)..." > >=20 > > Why in the beginning of this paragraph MIPv6, Dual-Stack=20 > Mobile IPv6 and MIPv4 is mentioned, while in the end they=20 > should be considered "within the context of Proxy Mobile IPv6=20 > (PMIPv6)" ? > >=20 > > 2 "Currently PMIPv6 (and mobility extension protocols like =20 > FMIPv6 and HMIPv6)" :=20 > >=20 > > Why FMIP and HMIP are mentioned combined with PMIP, what's=20 > the relationship between PMIP and FMIP and HMIP ? > >=20 > >=20 > > I feel it's not so clear to illustrate so many mip=20 > protocols and make=20 > > this classification > >=20 > > Because the wg hasn't yet seen clearly many works for other=20 > unicast MIP protocols except for PMIP. These protocols=20 > should be mentioned with some examples instead being listed=20 > "exhaustively". Otherwise the charter may look too inclusive=20 > or miscellaneous to be accepted. > >=20 > >=20 > >=20 > > Best Regards, > >=20 > > Liu Hui > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: multimob-bounces@ietf.org > >> [mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya > >> Sent: 2009=C4=EA5=D4=C219=C8=D5 23:46 > >> To: multimob@ietf.org > >> Subject: [multimob] Multimob charter v2 > >> > >> Hi all, > >> I updated the charter based on the discussions. > >> > >> Regards, > >> > >> Behcet > >> > >> > >> =20 > >=20 > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > >=20 > >=20 >=20 From gorry@erg.abdn.ac.uk Wed May 20 04:01: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 B65C03A6B21 for ; Wed, 20 May 2009 04:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.173 X-Spam-Level: X-Spam-Status: No, score=-1.173 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1H469Xmn8Ih for ; Wed, 20 May 2009 04:01:26 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 01A0828C376 for ; Wed, 20 May 2009 04:01:03 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n4KB2Qd8008307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 20 May 2009 12:02:26 +0100 (BST) Message-ID: <4A13E343.4020000@erg.abdn.ac.uk> Date: Wed, 20 May 2009 12:02:27 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Liu Hui References: <001f01c9d930$0ad8fca0$730c6f0a@china.huawei.com> In-Reply-To: <001f01c9d930$0ad8fca0$730c6f0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org Subject: Re: [multimob] Multimob charter v2 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 11:01:27 -0000 So, Let me check - you're saying it is OK to have the MIP variants in the "charter", but that it is more important to devote energy to PMIP - because this is so much nearer to deployment? To me, the latter means we should focus energy on PMIP, and seems to suggest the milestones should ONLY relate to PMIP. Anyone disagree? Gorry Liu Hui wrote: > Hi Gorry, > > I agree that the work of the group should not be too restrictive. > Previously I think if a unicast MIP protocol itself is too complicated, it > even has little chance to be deployed when incoorperated with multicast > support. Thus maybe not all of the MIP protocols will produce feasible > solutions. But maybe it is too earlier to make this judgment or decision. > > Of course it's OK to include all of them at present and make adjustment of > the charter in the future according to the situations of the work presented, > as you suggested. As long as there is interests in the work, it should not > be excluded from the group. > > > > Thanks, > > Liu Hui > > >> I see what you are saying, and this really depends on what >> the WG has hopes to study.... others please "speak-up" too on >> this list. >> >> I'd personally like to keep the text focussed on the goals, >> but we should also identify any wider possibilities in the >> (near) future - if people hope to work on FMIP or HMIP, it >> could be OK to include this in the charter text. >> >> The *goals* listed should be driven by need and current >> energy (we can update these later with IESG support, and >> would not necessarily need to re-charter). >> >> The Milestones should be *very* focussed, and specific. If >> approved, an AD can add new milestones consistent with the >> charter text and goals. >> >> That said - would anyone like to say something about their >> hopes (in future or otherwise) of working on HMIP or FMIP - >> if nobody thinks this is important, we can indeed safely >> condense these words.... >> >> Gorry >> >> >> Liu Hui wrote: >>> Behcet, >>> >>> I have some questions in the charter v2: >>> >>> 1 " Unicast mobility protocols (Mobile IPv6, Dual-Stack >> Mobile IPv6 and also Mobile IPv4)..." >>> Why in the beginning of this paragraph MIPv6, Dual-Stack >> Mobile IPv6 and MIPv4 is mentioned, while in the end they >> should be considered "within the context of Proxy Mobile IPv6 >> (PMIPv6)" ? >>> 2 "Currently PMIPv6 (and mobility extension protocols like >> FMIPv6 and HMIPv6)" : >>> Why FMIP and HMIP are mentioned combined with PMIP, what's >> the relationship between PMIP and FMIP and HMIP ? >>> >>> I feel it's not so clear to illustrate so many mip >> protocols and make >>> this classification >>> >>> Because the wg hasn't yet seen clearly many works for other >> unicast MIP protocols except for PMIP. These protocols >> should be mentioned with some examples instead being listed >> "exhaustively". Otherwise the charter may look too inclusive >> or miscellaneous to be accepted. >>> >>> >>> Best Regards, >>> >>> Liu Hui >>> >>> >>> >>>> -----Original Message----- >>>> From: multimob-bounces@ietf.org >>>> [mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya >>>> Sent: 2009Äê5ÔÂ19ÈÕ 23:46 >>>> To: multimob@ietf.org >>>> Subject: [multimob] Multimob charter v2 >>>> >>>> Hi all, >>>> I updated the charter based on the discussions. >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>> >>>> >>> _______________________________________________ >>> multimob mailing list >>> multimob@ietf.org >>> https://www.ietf.org/mailman/listinfo/multimob >>> >>> > > > From gorry@erg.abdn.ac.uk Wed May 20 04:03: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 608EF3A70A4 for ; Wed, 20 May 2009 04:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 NQc7vANNYpIL for ; Wed, 20 May 2009 04:03:54 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 2CC0E3A6A62 for ; Wed, 20 May 2009 04:03:53 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n4KB5SBG008358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 20 May 2009 12:05:28 +0100 (BST) Message-ID: <4A13E3F8.9090102@erg.abdn.ac.uk> Date: Wed, 20 May 2009 12:05:28 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: multimob@ietf.org References: <991096.55707.qm@web111410.mail.gq1.yahoo.com> <4A132FAF.2040602@ericsson.com> In-Reply-To: <4A132FAF.2040602@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 11:03:55 -0000 I agree this is now the core issue to understand. Gorry Suresh Krishnan wrote: > Hi Folks, > Before we try for a BOF we need to answer the following question so > that we do not spend the BOF discussing whether PMIPv6 already supports > multicast or not. > > * Is the performance penalty experienced by the operator using PMIPv6 > (AS IS) with multicast significant enough to warrant changing PMIPv6 > and/or the multicast protocols? > > This question needs to be answered by the operators who are planning to > deploy PMIPv6 and multicast along with deployment scenarios (if > possible) before we can make any headway. > > Thanks > Suresh > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > From schmidt@fhtw-berlin.de Wed May 20 04:36:30 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72CD828C305 for ; Wed, 20 May 2009 04:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDBArfVEmvuq for ; Wed, 20 May 2009 04:36:29 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 90C363A69D0 for ; Wed, 20 May 2009 04:35:50 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.22.26.203] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1M6k6w-000I8y-Jw; Wed, 20 May 2009 13:37:26 +0200 Message-ID: <4A13EB6C.6050808@fhtw-berlin.de> Date: Wed, 20 May 2009 13:37:16 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <991096.55707.qm@web111410.mail.gq1.yahoo.com> <4A132FAF.2040602@ericsson.com> <4A13E3F8.9090102@erg.abdn.ac.uk> In-Reply-To: <4A13E3F8.9090102@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 20 May 2009 11:36:30 -0000 Hi Suresh, you are right - the issue is in two ways: * first is the "real" penalty inherited from home tunneling - we have done simulation analysis on that some years ago: this is strongly dependent on the HA position and on the actual topology. * probably the more important aspect is the experience or "feeling" of operators. This is more on "how do operators want a PMIP multicast to be". It would be good to hear opinions and experiences. Thomas Gorry Fairhurst wrote: > > I agree this is now the core issue to understand. > > Gorry > > Suresh Krishnan wrote: >> Hi Folks, >> Before we try for a BOF we need to answer the following question so >> that we do not spend the BOF discussing whether PMIPv6 already >> supports multicast or not. >> >> * Is the performance penalty experienced by the operator using PMIPv6 >> (AS IS) with multicast significant enough to warrant changing PMIPv6 >> and/or the multicast protocols? >> >> This question needs to be answered by the operators who are planning >> to deploy PMIPv6 and multicast along with deployment scenarios (if >> possible) before we can make any headway. >> >> Thanks >> Suresh >> _______________________________________________ >> 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 schmidt@informatik.haw-hamburg.de Wed May 20 04:46: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 82BF03A6B07 for ; Wed, 20 May 2009 04:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.160, 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 sXm2gmfVQFrF for ; Wed, 20 May 2009 04:46:20 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 847123A69FE for ; Wed, 20 May 2009 04:46:19 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.22.26.203] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1M6kH5-000LSV-PS; Wed, 20 May 2009 13:47:55 +0200 Message-ID: <4A13EDE5.5060208@informatik.haw-hamburg.de> Date: Wed, 20 May 2009 13:47:49 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <001b01c9d8ed$ec1fb700$730c6f0a@china.huawei.com> <4A13C740.1060605@erg.abdn.ac.uk> In-Reply-To: <4A13C740.1060605@erg.abdn.ac.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] Multimob charter v2 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, 20 May 2009 11:46:21 -0000 Hi Gorry, Gorry Fairhurst wrote: > The Milestones should be *very* focussed, and specific. If approved, an > AD can add new milestones consistent with the charter text and goals. > > That said - would anyone like to say something about their hopes (in > future or otherwise) of working on HMIP or FMIP - if nobody thinks this > is important, we can indeed safely condense these words.... > We would argue for keeping HMIPv6 and FMIPv6 in the agenda - being placed next to PMIPv6 or elsewhere. HMIPv6 / FMIPv6 are the mobility optimization protocols that sustain the end-to-end design principle. I guess that's important at least for a systematic Internet development, even if operators don't like this end-to-end concept. We also would want to continue work in this direction. Cheers, Thomas > > Liu Hui wrote: >> Behcet, >> >> I have some questions in the charter v2: >> >> 1 " Unicast mobility protocols (Mobile IPv6, Dual-Stack Mobile IPv6 >> and also Mobile IPv4)..." >> >> Why in the beginning of this paragraph MIPv6, Dual-Stack Mobile IPv6 >> and MIPv4 is mentioned, while in the end they should be considered >> "within the context of Proxy Mobile IPv6 (PMIPv6)" ? >> >> 2 "Currently PMIPv6 (and mobility extension protocols like FMIPv6 and >> HMIPv6)" : >> Why FMIP and HMIP are mentioned combined with PMIP, what's the >> relationship between PMIP and FMIP and HMIP ? >> >> >> I feel it's not so clear to illustrate so many mip protocols and make >> this classification >> >> Because the wg hasn't yet seen clearly many works for other unicast >> MIP protocols except for PMIP. These protocols should be mentioned >> with some examples instead being listed "exhaustively". Otherwise the >> charter may look too inclusive or miscellaneous to be accepted. >> >> >> >> Best Regards, >> >> Liu Hui >> >> >> >>> -----Original Message----- >>> From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On >>> Behalf Of Behcet Sarikaya >>> Sent: 2009å¹´5月19æ—¥ 23:46 >>> To: multimob@ietf.org >>> Subject: [multimob] Multimob charter v2 >>> >>> Hi all, >>> I updated the charter based on the discussions. >>> >>> Regards, >>> >>> Behcet >>> >>> >>> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> >> > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- 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 Wed May 20 07:02:17 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42AC3A6BF1 for ; Wed, 20 May 2009 07:02:17 -0700 (PDT) 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 CXMlOEY7VQJo for ; Wed, 20 May 2009 07:02:17 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id DA4E13A6A9A for ; Wed, 20 May 2009 07:02:16 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 2EB5213D06C4 for ; Wed, 20 May 2009 22:59:32 +0900 (JST) Date: Wed, 20 May 2009 23:03:52 +0900 (JST) Message-Id: <20090520.230352.209594827.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <4A13EB6C.6050808@fhtw-berlin.de> References: <4A132FAF.2040602@ericsson.com> <4A13E3F8.9090102@erg.abdn.ac.uk> <4A13EB6C.6050808@fhtw-berlin.de> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 20 May 2009 14:02:17 -0000 I totally agree with Suresh, while I have some concern for Thomas's comments. > * first is the "real" penalty inherited from home tunneling - we > have done simulation analysis on that some years ago: this is > strongly dependent on the HA position and on the actual topology. I don't think it is the "real" penalty. Home subscription (or bi-directional tunneling) is simple and may be Okay for some situation or providers. Living with bi-dir tunnel is not the real problem. (Thomas said HA above, but I assume we have been discussing PMIPv6 multicast and follow it.) The real problem in PMIPv6 multicast is that PMIPv6 does not provide any "multicast state transition" for "both home and remote subscription". This causes the "real" performance penalty and may cause heavy packet loss. In PMIPv6, LMA or MAG joins multicast tree but MN does not. MN just subscribes interesting channels with MLD. When MN moves and attach nMAG, both LMA and nMAG do not forward multicast data to that MN as they don't have any multicast state for that MN and the MN does not send *unsolicited* MLD reports for all subscribed channels again after he attaches nMAG. (The current MLD sends unsolicited report only once upon subscription; hence it is impossible to do it at the protocol level.) This major problem exists in both home and remote subscription. Hence "supporting remote subscription" is not our sole goal or rather inappropriate wording in the charter. > * probably the more important aspect is the experience or > "feeling" of operators. This is more on "how do operators want a > PMIP multicast to be". It's good to clarify the expected condition from operator's viewpoint. If this discussion can be based on some operators experiences, it'd be nicer. Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Wed May 20 07:06: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 B06303A6C3C for ; Wed, 20 May 2009 07:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.83 X-Spam-Level: ** X-Spam-Status: No, score=2.83 tagged_above=-999 required=5 tests=[AWL=0.419, 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 9hzO5+tKdtUp for ; Wed, 20 May 2009 07:06:55 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 05B133A6C30 for ; Wed, 20 May 2009 07:06:54 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 1439813D06C4 for ; Wed, 20 May 2009 23:04:11 +0900 (JST) Date: Wed, 20 May 2009 23:08:30 +0900 (JST) Message-Id: <20090520.230830.227592298.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <4A13EDE5.5060208@informatik.haw-hamburg.de> References: <001b01c9d8ed$ec1fb700$730c6f0a@china.huawei.com> <4A13C740.1060605@erg.abdn.ac.uk> <4A13EDE5.5060208@informatik.haw-hamburg.de> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Multimob charter v2 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, 20 May 2009 14:06:55 -0000 > > The Milestones should be *very* focussed, and specific. If > > approved, an AD can add new milestones consistent with the charter > > text and goals. > > That said - would anyone like to say something about their hopes > > (in future or otherwise) of working on HMIP or FMIP - if nobody > > thinks this is important, we can indeed safely condense these > > words.... I agree. > We would argue for keeping HMIPv6 and FMIPv6 in the agenda - being > placed next to PMIPv6 or elsewhere. > > HMIPv6 / FMIPv6 are the mobility optimization protocols that sustain > the end-to-end design principle. I guess that's important at least > for a systematic Internet development, even if operators don't like > this end-to-end concept. I don't have strong opinions for HMIP6/FMIP6, but is (are) there Standards Track document(s) for these protocols, like RFC5213? If not, this multimob group cannot propose any Standards Track document for them. Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Wed May 20 07:14: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 582673A6CD1 for ; Wed, 20 May 2009 07:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.676 X-Spam-Level: *** X-Spam-Status: No, score=3.676 tagged_above=-999 required=5 tests=[AWL=-0.595, 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 jlXmjB2RbBpM for ; Wed, 20 May 2009 07:14:27 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id A4A0D3A6B14 for ; Wed, 20 May 2009 07:14:27 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 3EDF413D06C4 for ; Wed, 20 May 2009 23:11:44 +0900 (JST) Date: Wed, 20 May 2009 23:16:04 +0900 (JST) Message-Id: <20090520.231604.175479105.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <20090520.230352.209594827.asaeda@sfc.wide.ad.jp> References: <4A13E3F8.9090102@erg.abdn.ac.uk> <4A13EB6C.6050808@fhtw-berlin.de> <20090520.230352.209594827.asaeda@sfc.wide.ad.jp> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 20 May 2009 14:14:28 -0000 > Hence "supporting remote subscription" is not our sole goal or rather > inappropriate wording in the charter. I'm sorry. I wanted to say; we can mention "supporting remote subscription" in the charter, but it is not the main aim of PMIP6 multicast extension and not our sole goal. -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Wed May 20 07:39: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 8A1D93A6822 for ; Wed, 20 May 2009 07:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.286, 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 sDQNFhBCg2ss for ; Wed, 20 May 2009 07:39:06 -0700 (PDT) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id D111B3A6BF1 for ; Wed, 20 May 2009 07:39:06 -0700 (PDT) Received: (qmail 81647 invoked by uid 60001); 20 May 2009 14:39:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242830376; bh=6Yy/u3CvRdfyUaoT2zluU+hyMilfbFfGf6cOJC2tMk4=; 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=g6EeJbvknM6X5SDjgYa7+JBFE5kJUuJPx+1GdYj4Fh+IxQ/asEU5gUYp89oEFogvPNQ/CLetYQTMI7zDZd2jNz7vv2YQmP4GvQWNNLj5r54lijhXT2M65Y6nFPR4sTja2KENn+c5H5bTl1/Aq7Dp6/B6UpNM8vBxCIjeU8BGw3U= 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=zJswrzORlJLqgmUhMCrkuVOi33JU8aV9mJVN1HsGNbTltbEyCETNOcbooehIJlRXTELq16NHij/tCR7CRqinEpYE9YaeVwHEH9VHvjI0H1l5tVkL63H8Mb3ssAfQIpcOwW/3/Scmqbj861kXGLnZWExfjqrtQixwi726/b7W1Ys=; Message-ID: <131898.79883.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: 6ZWzSnQVM1nub7PQFdV9Toft4ZxZde3cNLmwH13EOo5NtzpR6t3aCMSTTUYcz_sU0wGC.G9tz_.lffJosC9HarLqoHlV7hRbeBIAwAFr1TecnoXFZchrXDrNLeuIuT.NKm8_2oMyDsCCe_27EShD7MvvioFLBVnOSwtYAqI4czSPMoTsmM4qQZZWkqlx0un_zCun6ErEToNiyR8bSUkEWy2V.e.P71d6KhQ5.Ty4ta__IfPdqGnGuEUA7_O_qzp.Tl7aYiWyQ.VIrWW4D6A- Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Wed, 20 May 2009 07:39:35 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <001b01c9d8ed$ec1fb700$730c6f0a@china.huawei.com> <4A13C740.1060605@erg.abdn.ac.uk> <4A13EDE5.5060208@informatik.haw-hamburg.de> <20090520.230830.227592298.asaeda@sfc.wide.ad.jp> Date: Wed, 20 May 2009 07:39:35 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda , multimob@ietf.org In-Reply-To: <20090520.230830.227592298.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] Multimob charter v2 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 14:39:07 -0000 Hello Folks,=0A=A0 It seems like v2 charter is acceptable to most so we kee= p it.=0ARegarding Hitoshi's comment, please see my reply below.=0A=0AIf you= have any other comments please post.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A= ----- Original Message ----=0AFrom: Hitoshi Asaeda = =0ATo: multimob@ietf.org=0ASent: Wednesday, May 20, 2009 9:08:30 AM=0ASubje= ct: Re: [multimob] Multimob charter v2=0A=0A> > The Milestones should be *v= ery* focussed, and specific. If=0A> > approved, an AD can add new milestone= s consistent with the charter=0A> > text and goals.=0A> > That said - would= anyone like to say something about their hopes=0A> > (in future or otherwi= se) of working on HMIP or FMIP - if nobody=0A> > thinks this is important, = we can indeed safely condense these=0A> > words....=0A=0AI agree.=0A=0A> We= would argue for keeping HMIPv6 and FMIPv6 in the agenda - being=0A> placed= next to PMIPv6 or elsewhere.=0A> =0A> HMIPv6 / FMIPv6 are the mobility opt= imization protocols that sustain=0A> the end-to-end design principle. I gue= ss that's important at least=0A> for a systematic Internet development, eve= n if operators don't like=0A> this end-to-end concept.=0A=0AI don't have st= rong opinions for HMIP6/FMIP6, but is (are) there=0AStandards Track documen= t(s) for these protocols, like RFC5213?=0AIf not, this multimob group canno= t propose any Standards Track=0Adocument for them.=0A=0A=0A[behcet] HMIP6 R= FC 4140 is experimental. but the new one RFC 5380 is standards track=A0FMIP= 6 RFC 5268 is standards track. So maybe we should keep both?=0A=0A=0A From behcetsarikaya@yahoo.com Wed May 20 07:50: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 7F1D83A6822 for ; Wed, 20 May 2009 07:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 HM2J13ZsZxLN for ; Wed, 20 May 2009 07:50:18 -0700 (PDT) Received: from n76.bullet.mail.sp1.yahoo.com (n76.bullet.mail.sp1.yahoo.com [98.136.44.48]) by core3.amsl.com (Postfix) with SMTP id 8392E3A69B5 for ; Wed, 20 May 2009 07:50:12 -0700 (PDT) Received: from [216.252.122.219] by n76.bullet.mail.sp1.yahoo.com with NNFMP; 20 May 2009 14:51:46 -0000 Received: from [67.195.9.82] by t4.bullet.sp1.yahoo.com with NNFMP; 20 May 2009 14:51:46 -0000 Received: from [67.195.9.104] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 20 May 2009 14:51:46 -0000 Received: from [127.0.0.1] by omp108.mail.gq1.yahoo.com with NNFMP; 20 May 2009 14:50:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 103374.5253.bm@omp108.mail.gq1.yahoo.com Received: (qmail 35438 invoked by uid 60001); 20 May 2009 14:51:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242831106; bh=OQohVdEd00mhck25GjaoJLxVNbm+AtONKlh4BowA1/M=; 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=XXtMPOe/bnGE0W6Jg74yF5M337X94+x3i5rSgDbvijBh91uUaREGKu1eyeJajjNsrSQxpsN/dLIDzhD3GS84EE+WUb0YeIiBkhAtsRdQEx6BJfJfCqPYwFFEZt2diUJcSuxmYou9Z9cfFakEK6h9iFKTsHczYuw5gOaDfZsdP+M= 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=yU5YQi86pFCWOSDSTMoDfnEKmVD0VeRlJQL6p/1IYCZPS3k/Q5R4s1z+rHiLZlwzYM4f0WfupAHdH8W6FqkMCnoqoh7DALv5oWCY2FRgAiW7WYBKgFPSVgdUn/xWVfOM7DgpgGJmP1CQTBI1jJmDZA1v3IRLsFrLNbv/Tqs6sfM=; Message-ID: <394134.34152.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: u75DB98VM1ktMskNVXyrcpkEbUkTdsg5JpklpFl3KfNlQHAJbHiglytR2JVz1qzN7m0sdr3sHVMIR0iCIScokhi4giRdl0JUw0A.NdUEPtfv5xkDkwJcDqbQkCbStUp3AljJMPx.K_siocEuQyxz4PTmQhs3ZMKU_8cYbP0zb35TltEm9zbXSiSckARfQ8ihrRJ5RG37_UWmxqGmEiH93aB9ZXilJZtAQc5eMSAHqbL_RZoVp9p.aUCZ4UtUDIQWmm.7zXAFpqR59kVfAEIAsA-- Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Wed, 20 May 2009 07:51:46 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <991096.55707.qm@web111410.mail.gq1.yahoo.com> <4A132FAF.2040602@ericsson.com> Date: Wed, 20 May 2009 07:51:46 -0700 (PDT) From: Behcet Sarikaya To: Suresh Krishnan , multimob@ietf.org In-Reply-To: <4A132FAF.2040602@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 14:50:19 -0000 Hi Suresh,=0A=A0 I have a specific comment which you can see below. =0AIn g= eneral I would like to know what your answer would be yourself? I know you = and I are not operators, but we do have opinions, don't we? :)=0A=0ARegards= ,=0A=0ABehcet=0A=0A=0A=0A----- Original Message ----=0AFrom: Suresh Krishna= n =0ATo: multimob@ietf.org=0ASent: Tuesday, M= ay 19, 2009 5:16:15 PM=0ASubject: [multimob] Gauging need for enhancing PMI= Pv6 multicast support=0A=0AHi Folks,=0A=A0 Before we try for a BOF we need = to answer the following question so that we do not spend the BOF discussing= whether PMIPv6 already supports multicast or not.=0A=0A* Is the performanc= e penalty experienced by the operator using PMIPv6 (AS IS) with multicast s= ignificant enough to warrant changing PMIPv6 and/or the multicast protocols= ?=0A=0A[behcet] Hitoshi mentioned some real performance problems. I would l= ike to point out that PMIPv6 currently does not support multicasting explic= itly.=0AThis fact has been acknowledged by a=A0PMIPv6 author by saying info= rmally that we should have put=A0this in the base spec, but we missed.=0ASo= any operator trying to deploy multicast with PMIPv6 would be at loss on ho= w to do it. =0ADuring the first BoF in Minneapolis this was discussed, I re= member different people suggesting different ways of deploying multicast in= PMIPv6.=0AHow would an operator do this? Which suggestion do they follow?= =0A=0AOur answer is it should be IETF to standardize a solution so that all= operators can use it.=0A=0A=0A=0A From asaeda@sfc.wide.ad.jp Wed May 20 08:47: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 8DDD43A6A74 for ; Wed, 20 May 2009 08:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.053 X-Spam-Level: **** X-Spam-Status: No, score=4.053 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_40=-0.185, 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 Qw7ReQPnIwMH for ; Wed, 20 May 2009 08:47:01 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id DBB5F3A6932 for ; Wed, 20 May 2009 08:47:00 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id ED35513D06C4 for ; Thu, 21 May 2009 00:44:15 +0900 (JST) Date: Thu, 21 May 2009 00:48:36 +0900 (JST) Message-Id: <20090521.004836.180001716.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <131898.79883.qm@web111407.mail.gq1.yahoo.com> References: <4A13EDE5.5060208@informatik.haw-hamburg.de> <20090520.230830.227592298.asaeda@sfc.wide.ad.jp> <131898.79883.qm@web111407.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 Subject: Re: [multimob] Multimob charter v2 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, 20 May 2009 15:47:01 -0000 > [behcet] HMIP6 RFC 4140 is experimental. but the new one RFC 5380 is > standards track=A0FMIP6 RFC 5268 is standards track. So maybe we > should keep both? If there are many supporters and no negative opinion, I think they could be kept in it. Regards, -- Hitoshi Asaeda From I.Romdhani@napier.ac.uk Wed May 20 08:49: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 E14BC3A6BC3 for ; Wed, 20 May 2009 08:49:02 -0700 (PDT) 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 9OWQ3bVazeov for ; Wed, 20 May 2009 08:49:01 -0700 (PDT) Received: from WA4EHSOBE003.bigfish.com (wa4ehsobe003.messaging.microsoft.com [216.32.181.13]) by core3.amsl.com (Postfix) with ESMTP id 689C83A6932 for ; Wed, 20 May 2009 08:49:01 -0700 (PDT) Received: from mail161-wa4-R.bigfish.com (10.8.14.239) by WA4EHSOBE003.bigfish.com (10.8.40.23) with Microsoft SMTP Server id 8.1.340.0; Wed, 20 May 2009 15:50:34 +0000 Received: from mail161-wa4 (localhost.localdomain [127.0.0.1]) by mail161-wa4-R.bigfish.com (Postfix) with ESMTP id 5CEFA4C03F5 for ; Wed, 20 May 2009 15:50:34 +0000 (UTC) X-BigFish: VPS-88(zz13feK542N1432R1417L9370P62a3L936eNaf6W1805M9371Pzz1202hzz1033ILz2ei6bh61h) X-Spam-TCS-SCL: 0:0 Received: by mail161-wa4 (MessageSwitch) id 1242834629611869_17491; Wed, 20 May 2009 15:50:29 +0000 (UCT) Received: from EVS1.napier-mail.napier.ac.uk (mer-w2003-1.napier.ac.uk [146.176.222.4]) by mail161-wa4.bigfish.com (Postfix) with ESMTP id AEBED6F8070 for ; Wed, 20 May 2009 15:50:06 +0000 (UTC) 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, 20 May 2009 16:50:03 +0100 Received: from E2K7MBX.napier-mail.napier.ac.uk ([146.176.222.86]) by mer-hub-1.napier-mail.napier.ac.uk ([146.176.222.88]) with mapi; Wed, 20 May 2009 16:50:19 +0100 From: "Romdhani, Imed" To: "multimob@ietf.org" Date: Wed, 20 May 2009 16:50:02 +0100 Thread-Topic: [multimob] Multimob charter v2 Thread-Index: AcnZWPg15mhWokehSAWa/do4KjayPAACRtag Message-ID: <78F1C759D89E1C44A6DD4C06B9A4B270AE8A492561@E2K7MBX.napier-mail.napier.ac.uk> References: <001b01c9d8ed$ec1fb700$730c6f0a@china.huawei.com> <4A13C740.1060605@erg.abdn.ac.uk> <4A13EDE5.5060208@informatik.haw-hamburg.de> <20090520.230830.227592298.asaeda@sfc.wide.ad.jp> <131898.79883.qm@web111407.mail.gq1.yahoo.com> In-Reply-To: <131898.79883.qm@web111407.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: 20 May 2009 15:50:03.0539 (UTC) FILETIME=[A3D44630:01C9D962] Subject: Re: [multimob] Multimob charter v2 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, 20 May 2009 15:49:03 -0000 Dear Folks, Substantial progress has been made to finalise the second version of the ch= apter. I would like to share with you these extra comments about it: . It seems to me that we are omitting the source mobility issues, however i= n RFC5110, section 2.6.1, it is stated that (In intra-domain or Embedded-RP= scenarios, ASM senders may move to a new IP address without significant im= pact on the delivery of their transmission. SSM senders cannot change the I= P address unless receivers join the new channel or the sender uses an IP mo= bility technique that is transparent to the receivers). I think we need her= e to decide whether we are going to investigate and define a possible mobil= ity technique that can help to sort out this problem or not. If source mobi= lity is out of the scope of our work, we need to clarify it too. . I think multicast data loss during handover is a common issue for both re= mote and bi-directional subscription methods and it is not a specific probl= em for remote subscription only. Therefore, Multimob can focus on how to re= duce packet loss by enhancing the functionality of the mobility agents (Hom= e Agent, Access Router, Mobility Anchor Point, Mobile Proxy, etc.). Example= of enhancement could include buffering techniques on these agents (not onl= y on PMIPv6). = . The statement "PMIPv6 will be extended to also support multicasting in IP= v4" seems confusing. Are we going to specify another version for IPv4 (PMIP= v4) or a more generic version for both (PMIP that handles IPv4 and IPv6). . If our group is going to propose solutions for the receiver's issues (tun= nel avalanche, triangle routing, packet loss and fast handover capability) = by considering PMIPv6 only, in this case the scope of the work should be re= phrased: "the scope of this work will be limited to group management and PM= IPv6 protocols". . In my own point of view, the multi-homing issue is not a key problem to a= ddress. A Multi-homed receiver inherits the same problem (Join delay, packe= t loss, battery consumption, etc.) as a simple receiver with a single netwo= rk interface. The multicasting issues are linked to the type of the subscr= iption method used and not the number of network interfaces or the number o= f multicast groups. In brief, I do believe that multicast mobility issues can be addressed by e= ither enhancing Mobile IP protocols (Functionality and behaviour of mobile = IP components) or adapting current multicast protocols to handle mobile dev= ices. In both cases, we need to choose which roadmap we are going to take. = For future direction, we can focus on security issues and multicast routing= extensions for Mobile IPv4 and IPv6. Cheers, Imed --------------------------------------------------- Imed Romdhani, PhD IEEE Member = 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: 20 May 2009 15:40 To: Hitoshi Asaeda; multimob@ietf.org Subject: Re: [multimob] Multimob charter v2 Hello Folks, =A0 It seems like v2 charter is acceptable to most so we keep it. Regarding Hitoshi's comment, please see my reply below. If you have any other comments please post. Regards, Behcet ----- Original Message ---- From: Hitoshi Asaeda To: multimob@ietf.org Sent: Wednesday, May 20, 2009 9:08:30 AM Subject: Re: [multimob] Multimob charter v2 > > The Milestones should be *very* focussed, and specific. If > > approved, an AD can add new milestones consistent with the charter > > text and goals. > > That said - would anyone like to say something about their hopes > > (in future or otherwise) of working on HMIP or FMIP - if nobody > > thinks this is important, we can indeed safely condense these > > words.... I agree. > We would argue for keeping HMIPv6 and FMIPv6 in the agenda - being > placed next to PMIPv6 or elsewhere. > = > HMIPv6 / FMIPv6 are the mobility optimization protocols that sustain > the end-to-end design principle. I guess that's important at least > for a systematic Internet development, even if operators don't like > this end-to-end concept. I don't have strong opinions for HMIP6/FMIP6, but is (are) there Standards Track document(s) for these protocols, like RFC5213? If not, this multimob group cannot propose any Standards Track document for them. [behcet] HMIP6 RFC 4140 is experimental. but the new one RFC 5380 is standa= rds track=A0FMIP6 RFC 5268 is standards track. So maybe we should keep both= ? = _______________________________________________ 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 the number one in Scotland for graduate empl= oyability (HESA 2008) 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 xiayangsong@huawei.com Wed May 20 08:56: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 C43B93A6E18 for ; Wed, 20 May 2009 08:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4g5zx4F+cEDg for ; Wed, 20 May 2009 08:56:58 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A796C28C0F1 for ; Wed, 20 May 2009 08:56:37 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJY00BFD9OSZE@szxga04-in.huawei.com> for multimob@ietf.org; Wed, 20 May 2009 23:58:04 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJY00II89OS0C@szxga04-in.huawei.com> for multimob@ietf.org; Wed, 20 May 2009 23:58:04 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJY00FEY9OH6F@szxml04-in.huawei.com> for multimob@ietf.org; Wed, 20 May 2009 23:57:55 +0800 (CST) Date: Wed, 20 May 2009 10:57:54 -0500 From: Frank Xia To: "Romdhani, Imed" , multimob@ietf.org Message-id: <002001c9d963$bdfbdf40$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <001b01c9d8ed$ec1fb700$730c6f0a@china.huawei.com> <4A13C740.1060605@erg.abdn.ac.uk> <4A13EDE5.5060208@informatik.haw-hamburg.de> <20090520.230830.227592298.asaeda@sfc.wide.ad.jp> <131898.79883.qm@web111407.mail.gq1.yahoo.com> <78F1C759D89E1C44A6DD4C06B9A4B270AE8A492561@E2K7MBX.napier-mail.napier.ac.uk> Subject: Re: [multimob] Multimob charter v2 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, 20 May 2009 15:56:59 -0000 Hi Imed IMHO, receiver mobility seems to be more pragmatical, such as IPTV. It is better to start small. BR Frank ----- Original Message ----- From: "Romdhani, Imed" To: Sent: Wednesday, May 20, 2009 10:50 AM Subject: Re: [multimob] Multimob charter v2 Dear Folks, Substantial progress has been made to finalise the second version of the chapter. I would like to share with you these extra comments about it: . It seems to me that we are omitting the source mobility issues, however in RFC5110, section 2.6.1, it is stated that (In intra-domain or Embedded-RP scenarios, ASM senders may move to a new IP address without significant impact on the delivery of their transmission. SSM senders cannot change the IP address unless receivers join the new channel or the sender uses an IP mobility technique that is transparent to the receivers). I think we need here to decide whether we are going to investigate and define a possible mobility technique that can help to sort out this problem or not. If source mobility is out of the scope of our work, we need to clarify it too. . I think multicast data loss during handover is a common issue for both remote and bi-directional subscription methods and it is not a specific problem for remote subscription only. Therefore, Multimob can focus on how to reduce packet loss by enhancing the functionality of the mobility agents (Home Agent, Access Router, Mobility Anchor Point, Mobile Proxy, etc.). Example of enhancement could include buffering techniques on these agents (not only on PMIPv6). . The statement "PMIPv6 will be extended to also support multicasting in IPv4" seems confusing. Are we going to specify another version for IPv4 (PMIPv4) or a more generic version for both (PMIP that handles IPv4 and IPv6). . If our group is going to propose solutions for the receiver's issues (tunnel avalanche, triangle routing, packet loss and fast handover capability) by considering PMIPv6 only, in this case the scope of the work should be rephrased: "the scope of this work will be limited to group management and PMIPv6 protocols". . In my own point of view, the multi-homing issue is not a key problem to address. A Multi-homed receiver inherits the same problem (Join delay, packet loss, battery consumption, etc.) as a simple receiver with a single network interface. The multicasting issues are linked to the type of the subscription method used and not the number of network interfaces or the number of multicast groups. In brief, I do believe that multicast mobility issues can be addressed by either enhancing Mobile IP protocols (Functionality and behaviour of mobile IP components) or adapting current multicast protocols to handle mobile devices. In both cases, we need to choose which roadmap we are going to take. For future direction, we can focus on security issues and multicast routing extensions for Mobile IPv4 and IPv6. Cheers, Imed --------------------------------------------------- Imed Romdhani, PhD IEEE Member 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 Behalf Of Behcet Sarikaya Sent: 20 May 2009 15:40 To: Hitoshi Asaeda; multimob@ietf.org Subject: Re: [multimob] Multimob charter v2 Hello Folks, It seems like v2 charter is acceptable to most so we keep it. Regarding Hitoshi's comment, please see my reply below. If you have any other comments please post. Regards, Behcet ----- Original Message ---- From: Hitoshi Asaeda To: multimob@ietf.org Sent: Wednesday, May 20, 2009 9:08:30 AM Subject: Re: [multimob] Multimob charter v2 > > The Milestones should be *very* focussed, and specific. If > > approved, an AD can add new milestones consistent with the charter > > text and goals. > > That said - would anyone like to say something about their hopes > > (in future or otherwise) of working on HMIP or FMIP - if nobody > > thinks this is important, we can indeed safely condense these > > words.... I agree. > We would argue for keeping HMIPv6 and FMIPv6 in the agenda - being > placed next to PMIPv6 or elsewhere. > > HMIPv6 / FMIPv6 are the mobility optimization protocols that sustain > the end-to-end design principle. I guess that's important at least > for a systematic Internet development, even if operators don't like > this end-to-end concept. I don't have strong opinions for HMIP6/FMIP6, but is (are) there Standards Track document(s) for these protocols, like RFC5213? If not, this multimob group cannot propose any Standards Track document for them. [behcet] HMIP6 RFC 4140 is experimental. but the new one RFC 5380 is standards track FMIP6 RFC 5268 is standards track. So maybe we should keep both? _______________________________________________ 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 the number one in Scotland for graduate employability (HESA 2008) 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 permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Edinburgh Napier University does not 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. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University. Edinburgh Napier University is a registered Scottish charity. Registration number SC018373 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From waehlisch@ieee.org Wed May 20 09:07: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 19D053A6932 for ; Wed, 20 May 2009 09:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LTESs2QwBWH for ; Wed, 20 May 2009 09:07:05 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 11C913A6822 for ; Wed, 20 May 2009 09:07:05 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from imp051023.vpn.mi.fu-berlin.de ([130.133.51.23] helo=mw-thinkpad) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1M6oLR-0003v7-E0; Wed, 20 May 2009 18:08:41 +0200 Date: Wed, 20 May 2009 18:08:40 +0200 From: Matthias Waehlisch To: Hitoshi Asaeda In-Reply-To: <20090520.230352.209594827.asaeda@sfc.wide.ad.jp> Message-ID: References: <4A132FAF.2040602@ericsson.com> <4A13E3F8.9090102@erg.abdn.ac.uk> <4A13EB6C.6050808@fhtw-berlin.de> <20090520.230352.209594827.asaeda@sfc.wide.ad.jp> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: multimob@ietf.org Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 20 May 2009 16:07:06 -0000 Hitoshi, Behcet, sorry, but I'm really confused. Hitoshi, you said: "The real problem in PMIPv6 multicast is that PMIPv6 does not provide any "multicast state transition" for "both home and remote subscription". as well as "[...] both LMA and nMAG do not forward multicast data to that MN as they don't have any multicast state for that MN [...]". RFC5213 clearly states that the LMA has the functional capabilities of a HA as defined in RFC3775. Thus it supports bidir-tunneling. One may argue that the MAG acts in the sense of the MN according to RFC3775, which implies multicast capabilities, as well. However, RFC5213 states in section 6.10.5: "[...] the mobile access gateway MUST use the destination address of the inner packet for forwarding it on the interface where the destination network prefix is hosted." and (more important) "If the mobile access gateway cannot find the connected interface for that destination address, it MUST silently drop the packet." ... I think we should try to argue very clearly. Otherwise we get the same problems as in the last BoF. Anyhow, any opinions from the operators subscribed to the list - there are some: Do you prefer an improved PMIP multicast support (cf. Suresh question)? Cheers matthias -- Matthias Waehlisch . FU Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net On Wed, 20 May 2009, Hitoshi Asaeda wrote: > I totally agree with Suresh, while I have some concern for Thomas's > comments. > > > * first is the "real" penalty inherited from home tunneling - we > > have done simulation analysis on that some years ago: this is > > strongly dependent on the HA position and on the actual topology. > > I don't think it is the "real" penalty. Home subscription (or > bi-directional tunneling) is simple and may be Okay for some situation > or providers. Living with bi-dir tunnel is not the real problem. > > (Thomas said HA above, but I assume we have been discussing PMIPv6 > multicast and follow it.) > The real problem in PMIPv6 multicast is that PMIPv6 does not provide > any "multicast state transition" for "both home and remote > subscription". This causes the "real" performance penalty and may > cause heavy packet loss. > > In PMIPv6, LMA or MAG joins multicast tree but MN does not. MN just > subscribes interesting channels with MLD. When MN moves and attach > nMAG, both LMA and nMAG do not forward multicast data to that MN as > they don't have any multicast state for that MN and the MN does not > send *unsolicited* MLD reports for all subscribed channels again after > he attaches nMAG. (The current MLD sends unsolicited report only once > upon subscription; hence it is impossible to do it at the protocol > level.) > > This major problem exists in both home and remote subscription. > Hence "supporting remote subscription" is not our sole goal or rather > inappropriate wording in the charter. > > > * probably the more important aspect is the experience or > > "feeling" of operators. This is more on "how do operators want a > > PMIP multicast to be". > > It's good to clarify the expected condition from operator's > viewpoint. If this discussion can be based on some operators > experiences, it'd be nicer. > > Regards, > -- > Hitoshi Asaeda > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From asaeda@sfc.wide.ad.jp Wed May 20 09:37: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 A453F3A6E54 for ; Wed, 20 May 2009 09:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.956 X-Spam-Level: ** X-Spam-Status: No, score=2.956 tagged_above=-999 required=5 tests=[AWL=0.544, 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 cxQfq1cyx+Tb for ; Wed, 20 May 2009 09:37:07 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 798AB3A6E3B for ; Wed, 20 May 2009 09:37:01 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 362E613D06C4 for ; Thu, 21 May 2009 01:34:17 +0900 (JST) Date: Thu, 21 May 2009 01:38:37 +0900 (JST) Message-Id: <20090521.013837.180043133.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: References: <4A13EB6C.6050808@fhtw-berlin.de> <20090520.230352.209594827.asaeda@sfc.wide.ad.jp> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 20 May 2009 16:37:07 -0000 Matthias, > Hitoshi, you said: "The real problem in PMIPv6 multicast is that PMIPv6 > does not provide any "multicast state transition" for "both home and > remote subscription". as well as "[...] both LMA and nMAG do not forward > multicast data to that MN as they don't have any multicast state for that > MN [...]". > > RFC5213 clearly states that the LMA has the functional capabilities of a > HA as defined in RFC3775. Thus it supports bidir-tunneling. Whether LMA has the functionality of HA or not doesn't matter. > One may argue that the MAG acts in the sense of the MN according to > RFC3775, which implies multicast capabilities, as well. However, RFC5213 > states in section 6.10.5: It doesn't matter. MN or other equipment does not notify his multicast state to its LMA or upstream router when he moves. In home subscription in MIP, for instance, MN is the tunnel end point and hence he can continuously receive multicast packets even if he moves. This does not require any multicast state transition to HA. But in PMIP6, MN is not the tunnel end point. When MN moves, nMAG must inherit his multicast state, but no way to do it. This is the point. > "[...] the mobile access gateway MUST use the destination address of the > inner packet for forwarding it on the interface where the destination > network prefix is hosted." > > and (more important) > > "If the mobile access gateway cannot find the connected interface for that > destination address, it MUST silently drop the packet." I cannot understand what point solves the problem.. Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Wed May 20 09:40: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 6677128C112 for ; Wed, 20 May 2009 09:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOzsvhbmkWaR for ; Wed, 20 May 2009 09:39:59 -0700 (PDT) Received: from n70a.bullet.mail.sp1.yahoo.com (n70a.bullet.mail.sp1.yahoo.com [98.136.45.17]) by core3.amsl.com (Postfix) with SMTP id A496E3A6E7F for ; Wed, 20 May 2009 09:39:59 -0700 (PDT) Received: from [216.252.122.218] by n70.bullet.mail.sp1.yahoo.com with NNFMP; 20 May 2009 16:41:33 -0000 Received: from [68.142.230.29] by t3.bullet.sp1.yahoo.com with NNFMP; 20 May 2009 16:41:33 -0000 Received: from [67.195.9.81] by t2.bullet.re2.yahoo.com with NNFMP; 20 May 2009 16:41:33 -0000 Received: from [67.195.9.108] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 20 May 2009 16:41:32 -0000 Received: from [127.0.0.1] by omp112.mail.gq1.yahoo.com with NNFMP; 20 May 2009 16:41:32 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 756941.61517.bm@omp112.mail.gq1.yahoo.com Received: (qmail 73745 invoked by uid 60001); 20 May 2009 16:41:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242837692; bh=rXiUdMGSi3NoeAOr5NK/+dATH2u8ninyfJcvwkqNEE0=; 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=OHlPmeEaqEZ4GB2rpClhtXzZONl2BnRRlsTTZzmgieWCYG98Ayh4kZ0gaDG3jxG9o6qcLAnajGIiT3lX7gd+eDqTxrwCN6sZGfXkM2c+YIipj6GyxyBeABLcmQ/59XjPk0jGLfcP5Usnj6b3VwuH4sQ7lMxlzQbRgwUI6pasBHo= 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=HU3DmMulmfnZxjLZ9KO80VfU5C6aPGa1lMnEh7tIqQPV9vHlGKSk/tCZdlV8DKbKN8VFocUkXg2u3azlnsHTshNHe5JdT9Ao7Gx3PtBIEQZC28HNmyMbpcm/HWLs2TjpOcEJD31OoDJikIIdmog95MflvAAdRv3TzlGZuPsxy8Q=; Message-ID: <550191.73469.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: O6FgvsMVM1kei9nL9OWgmjOwBrczP0Jsap2i08A.ojHLOUhzs.qSFrMFZrwhAzb3VNo58_0QPvodPXXGRSzKvv4dSiR05lshblgl1Fv85CRSSQ40_PlT7RAOGCh0q_wPqNOEex0KLimpoFBTzE.QQt6ZdTcdEeC6VfL1d9Qh2Euywh82UC8ogcLFsZfH0kL8ub_kkEsxTWRnhithxJBA3IpiruZmknVl3tjs2cFj1L8CEjSnp2d4pvwZLdNr9Y8iktXPmycxWuvlOUoH2CushKky6FxLkQ7NDAyWl10OV25.Sr64i4aBDCkpcjLOCeyFxlVsrLIr Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Wed, 20 May 2009 09:41:32 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <4A132FAF.2040602@ericsson.com> <4A13E3F8.9090102@erg.abdn.ac.uk> <4A13EB6C.6050808@fhtw-berlin.de> <20090520.230352.209594827.asaeda@sfc.wide.ad.jp> Date: Wed, 20 May 2009 09:41:32 -0700 (PDT) From: Behcet Sarikaya To: Matthias Waehlisch , Hitoshi Asaeda 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] Gauging need for enhancing PMIPv6 multicast support X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 16:40:00 -0000 =0A=0A=0A=0A----- Original Message ----=0AFrom: Matthias Waehlisch =0ATo: Hitoshi Asaeda =0ACc: multimob@ie= tf.org=0ASent: Wednesday, May 20, 2009 11:08:40 AM=0ASubject: Re: [multimob= ] Gauging need for enhancing PMIPv6 multicast support=0A=0AHitoshi, Behcet,= =0A=0A=A0 sorry, but I'm really confused.=0A=0A[behcet] Why?=0A=0A=A0 Hitos= hi, you said: "The real problem in PMIPv6 multicast is that PMIPv6 =0Adoes = not provide any "multicast state transition" for "both home and =0Aremote s= ubscription". as well as "[...] both LMA and nMAG do not forward =0Amultica= st data to that MN as they don't have any multicast state for that =0AMN [.= ...]".=0A=0A=A0 RFC5213 clearly states that the LMA has the functional capab= ilities of a =0AHA as defined in RFC3775. Thus it supports bidir-tunneling.= =0A=0A[behcet] That's why the charter says PMIPv6 does not support multicas= ting explicitly. Yes there are some implicit things.=0A=0A=A0 One may argue= that the MAG acts in the sense of the MN according to =0ARFC3775, which im= plies multicast capabilities, as well. =0A=0A[behcet] Maybe but how? We are= saying that let's define it clearly.=0A=0AHowever, RFC5213 =0Astates in se= ction 6.10.5: =0A=0A"[...] the mobile access gateway MUST use the destinati= on address of the =0Ainner packet for forwarding it on the interface where = the destination =0Anetwork prefix is hosted."=0A=0Aand (more important)=0A= =0A"If the mobile access gateway cannot find the connected interface for th= at =0Adestination address, it MUST silently drop the packet."=0A=0A[behcet]= So=A0unicast packets are addressed here, that's my interpreration.=0A=0A= =A0 ... I think we should try to argue very clearly. Otherwise we get the = =0Asame problems as in the last BoF.=0A=0A=0A=A0 Anyhow, any opinions from = the operators subscribed to the list - there =0Aare some: Do you prefer an = improved PMIP multicast support (cf. Suresh =0Aquestion)?=0A=0A[behcet] Mat= thias, if you are unhappy about anything in the charter, please state it cl= early and also pls. provide an alternative text. That could take us somewhe= re.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A From waehlisch@ieee.org Wed May 20 10:14:34 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 7EA723A6D1C for ; Wed, 20 May 2009 10:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZf5DDx0guzn for ; Wed, 20 May 2009 10:14:33 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 6A0543A6CC1 for ; Wed, 20 May 2009 10:14:33 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from imp051023.vpn.mi.fu-berlin.de ([130.133.51.23] helo=mw-thinkpad) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1M6pOj-000N71-L2; Wed, 20 May 2009 19:16:09 +0200 Date: Wed, 20 May 2009 19:16:08 +0200 From: Matthias Waehlisch To: Hitoshi Asaeda In-Reply-To: <20090521.013837.180043133.asaeda@sfc.wide.ad.jp> Message-ID: References: <4A13EB6C.6050808@fhtw-berlin.de> <20090520.230352.209594827.asaeda@sfc.wide.ad.jp> <20090521.013837.180043133.asaeda@sfc.wide.ad.jp> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: multimob@ietf.org Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 20 May 2009 17:14:34 -0000 Hi again, On Thu, 21 May 2009, Hitoshi Asaeda wrote: > > One may argue that the MAG acts in the sense of the MN according to > > RFC3775, which implies multicast capabilities, as well. However, > > RFC5213 states in section 6.10.5: > > It doesn't matter. MN or other equipment does not notify his multicast > state to its LMA or upstream router when he moves. > > In home subscription in MIP, for instance, MN is the tunnel end point > and hence he can continuously receive multicast packets even if he > moves. This does not require any multicast state transition to HA. But > in PMIP6, MN is not the tunnel end point. When MN moves, nMAG must > inherit his multicast state, but no way to do it. This is the point. > No - that's unclear for me. If a MN moves from MAG to nMAG, the LMA does not change. In particular, the LMA holds its previous states for a certain amount of time (cf. pg. 15 RFC5213). When the MN is attached to the nMAG, the LMA updates its binding and forwards data. If the LMA has sent multicast data before the movement, the LMA will sent mcast data afterwards. This corresponds to MIPv6. If the state timer of the LMA expires, it doesn't matter. The MAG is a function on an access router. Thus this entity operates MLD in the router part, which includes sending General Queries. This corresponds to MIPv6. > > "[...] the mobile access gateway MUST use the destination address of the > > inner packet for forwarding it on the interface where the destination > > network prefix is hosted." > > > > and (more important) > > > > "If the mobile access gateway cannot find the connected interface for that > > destination address, it MUST silently drop the packet." > > I cannot understand what point solves the problem.. > I would say it prevent multicast. Anyhow, I'm just saying that we need stringent argumentation. Refering to Rajeev at the last BoF: We "need to enumerate the problems clearly." - otherwise we will end with the same result. Cheers matthias -- Matthias Waehlisch . FU Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From behcetsarikaya@yahoo.com Wed May 20 12:05: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 2874C3A6DC0 for ; Wed, 20 May 2009 12:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, 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 eIlX6MiDF-sI for ; Wed, 20 May 2009 12:05:14 -0700 (PDT) Received: from n1.bullet.mail.re3.yahoo.com (n1.bullet.mail.re3.yahoo.com [68.142.237.108]) by core3.amsl.com (Postfix) with SMTP id 320E03A6C3C for ; Wed, 20 May 2009 12:05:14 -0700 (PDT) Received: from [68.142.230.29] by n1.bullet.mail.re3.yahoo.com with NNFMP; 20 May 2009 19:06:49 -0000 Received: from [67.195.9.82] by t2.bullet.re2.yahoo.com with NNFMP; 20 May 2009 19:06:49 -0000 Received: from [67.195.9.105] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 20 May 2009 19:06:49 -0000 Received: from [127.0.0.1] by omp109.mail.gq1.yahoo.com with NNFMP; 20 May 2009 19:07:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 209385.66961.bm@omp109.mail.gq1.yahoo.com Received: (qmail 43232 invoked by uid 60001); 20 May 2009 19:06:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242846409; bh=opVNwpUER8pCMkkrGr3nEmCgVEsF3/ZEKf9NQHqsaZU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YMNQd4cCIkZgbry6Ua+eNRYK7wFcz3n1jf3hWuULp2udjbGM3UVlZFRBXm2QJgOIbZAG5cD5zJpPwnXr+erZbDpv5QCjepaci4zNtT7761+KTrzwUfgw3IGIrIXnGC10/hwC7+wpcm6eUs4i4CFR3ELSzVpxPbG5x1navLjhecs= 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:Content-Transfer-Encoding; b=43AdHm7hlrJgkLNSx/v1FgfzmQmqBAgUAzAMrhfeeoWS11YyNEES4LHukJdtlJX9ES2xy4sLK+F0ilkjLc+xL9Xq3xmOcgyvc1WuGCkmDl/8khhWdoY8ZDtqZsoQLMcqhLZTAD2lutMcVMhpFi/94MLJosK8HwAI/xHY2ev0QS8=; Message-ID: <352577.42066.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: Ylxj6kYVM1nyWqb68uhD3MkcPCfe4Nca3sog3DuA5N2cfWTGeK39Shot98UoyBTkHZNl_xF3R4eONM6zPZNlY0pLWKZikDTurhfEhX8wyNZZVPtYOlTAMVh8xq_KKWLkow3p5FE9eirHTij5gFGDSdnUQbQmf2cjrxEbTzjAtZCNvNZo9K8hZAKRQQ4hpOyOeOJ0JXWX.8A9tQb1uuKsOAA.XLyI8K5MSXZhH9._3raWvaoPfEQFPE8w1jc2j0yzX4FrLFPy1vbt7STN7QUojV4SCEVJXaFgMOt9Jpa2kPR9Q7tM5jUiO29aPegjta2ojnk25z8KE4LFr6N5QQI7dFINeWJ0kzcawJKlQrSrl1cfUN1wPRBI6vzO1RgKZcADFfvsm_L.T4RxMF0rDuZ9kPP40Onsdh7lrPrxLY2Uzym27cJqDT1Qp6c- Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Wed, 20 May 2009 12:06:49 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 Date: Wed, 20 May 2009 12:06:49 -0700 (PDT) From: Behcet Sarikaya To: Vidya Narayanan , "Soininen Jonne \(NSN FI/Espoo\)" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: [multimob] PMIP6 Multicast Deployment Draft X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 19:05:15 -0000 Dear Netlmm Chairs,=0A=A0 Both of you attended Multimob BoF last year in Mi= nneapolis and expressed some opinions on how multicast can be deployed in P= roxy Mobile IPv6. During the meeting it was mentioned that a short draft is= needed.=0A=0A=A0 We have recently written such a draft, it is at:=0Ahttp:/= /www.ietf.org/internet-drafts/draft-gundavelli-multimob-pmip6basicmcast-sol= ution-00.txt=A0or=0Ahttp://www.ietf.org/internet-drafts/draft-gundavelli-mu= ltimob-pmip6basicmcast-solution-01.txt=0AThere is a small problem with the = author list and Sri's involvement. He was going to add some text based on h= is internal discussions which didn't happen. Authoring will be fixed soon a= nd the draft will be published without Sri.=0A=0A=A0 I would like to invite= you to please comment on the draft's technical contents and let us know wh= at you think, if you think that this draft could be the basis of PMIPv6 bas= ic multicast deployment, etc. =0A=0AKind regards,=0A=0ABehcet=0A=0A=0A = From asaeda@sfc.wide.ad.jp Wed May 20 17:04: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 DC79B3A6D49 for ; Wed, 20 May 2009 17:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.888 X-Spam-Level: ** X-Spam-Status: No, score=2.888 tagged_above=-999 required=5 tests=[AWL=0.476, 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 D8y3bPRfYVXT for ; Wed, 20 May 2009 17:04:37 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 21C413A69CD for ; Wed, 20 May 2009 17:04:36 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 4FC9713D06C4 for ; Thu, 21 May 2009 09:01:49 +0900 (JST) Date: Thu, 21 May 2009 09:06:14 +0900 (JST) Message-Id: <20090521.090614.171079249.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: References: <20090521.013837.180043133.asaeda@sfc.wide.ad.jp> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 21 May 2009 00:04:37 -0000 > No - that's unclear for me. If a MN moves from MAG to nMAG, the LMA does > not change. In particular, the LMA holds its previous states for a certain > amount of time (cf. pg. 15 RFC5213). When the MN is attached to the nMAG, > the LMA updates its binding and forwards data. For unicast, yes. > If the LMA has sent > multicast data before the movement, the LMA will sent mcast data > afterwards. This corresponds to MIPv6. How LMA knows which multicast channels should be forwarded when *that* MN moves to nMAG? > If the state timer of the LMA expires, it doesn't matter. The MAG is a > function on an access router. Thus this entity operates MLD in the router > part, which includes sending General Queries. This corresponds to MIPv6. Then MN replys *solicit* report and finally could receive multicast data. But this time lag is not negligible at all and this *is* the real performance problem I said. Regards, -- Hitoshi Asaeda From xiajinwei@huawei.com Thu May 21 02:41: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 DB08428C0EB for ; Thu, 21 May 2009 02:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shgWkbi93qBP for ; Thu, 21 May 2009 02:41:16 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 6740128C10E for ; Thu, 21 May 2009 02:40:55 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJZ000D7MVY9U@szxga03-in.huawei.com> for multimob@ietf.org; Thu, 21 May 2009 17:40:46 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJZ0033OMVYSY@szxga03-in.huawei.com> for multimob@ietf.org; Thu, 21 May 2009 17:40:46 +0800 (CST) Received: from x65217 ([10.164.12.67]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJZ000E1MVYHJ@szxml04-in.huawei.com> for multimob@ietf.org; Thu, 21 May 2009 17:40:46 +0800 (CST) Date: Thu, 21 May 2009 17:40:46 +0800 From: Jinwei Xia In-reply-to: To: 'Matthias Waehlisch' , 'Hitoshi Asaeda' Message-id: <004f01c9d9f8$37d7dbe0$430ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnZbrHWLxVzjLECQJ2YhnJ2UXJTMgAh9www Cc: multimob@ietf.org Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 21 May 2009 09:41:17 -0000 Hi Matthias > > > "[...] the mobile access gateway MUST use the destination > address of > > > the inner packet for forwarding it on the interface where the > > > destination network prefix is hosted." > > > > > > and (more important) > > > > > > "If the mobile access gateway cannot find the connected interface > > > for that destination address, it MUST silently drop the packet." > > > > I cannot understand what point solves the problem.. > > > I would say it prevent multicast. > Other questions you listed above have been answered by Hitoshi in another mail. However this point you concern is a drawback of RFC5213, which only consider unicast. The IP destination address in downstream packet is MN-HoA, whereas it is multicast group address in IPdestination address field in multicast downstream packet. This issue is not negligible for multicast support in PMIPv6. This is why we should extend PMIP to support multicast. BR Jinwei > > Anyhow, I'm just saying that we need stringent > argumentation. Refering to Rajeev at the last BoF: We "need > to enumerate the problems clearly." - otherwise we will end > with the same result. > > > Cheers > matthias > > -- > Matthias Waehlisch > . FU Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, > D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. > http://www.inf.fu-berlin.de/~waehl > :. Also: http://inet.cpt.haw-hamburg.de .. > http://www.link-lab.net > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From waehlisch@ieee.org Thu May 21 08:09: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 0505C3A6FBA for ; Thu, 21 May 2009 08:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UavwhlexlD6u for ; Thu, 21 May 2009 08:09:06 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id C1E793A6DB3 for ; Thu, 21 May 2009 08:09:06 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178134163.adsl.alicedsl.de ([85.178.134.163] helo=mw-thinkpad) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1M79uo-0004gT-Bw; Thu, 21 May 2009 17:10:38 +0200 Date: Thu, 21 May 2009 17:10:36 +0200 From: Matthias Waehlisch To: Hitoshi Asaeda In-Reply-To: <20090521.090614.171079249.asaeda@sfc.wide.ad.jp> Message-ID: References: <20090521.013837.180043133.asaeda@sfc.wide.ad.jp> <20090521.090614.171079249.asaeda@sfc.wide.ad.jp> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: multimob@ietf.org Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 21 May 2009 15:09:08 -0000 Hi Hitoshi, sorry for the late reply. On Thu, 21 May 2009, Hitoshi Asaeda wrote: > > No - that's unclear for me. If a MN moves from MAG to nMAG, the LMA > > does not change. In particular, the LMA holds its previous states for > > a certain amount of time (cf. pg. 15 RFC5213). When the MN is attached > > to the nMAG, the LMA updates its binding and forwards data. > > For unicast, yes. > Please refer to the section/page in RFC5213 where it is defined that states are tied to unicast only. > > If the LMA has sent multicast data before the movement, the LMA will > > sent mcast data afterwards. This corresponds to MIPv6. > > How LMA knows which multicast channels should be forwarded when *that* > MN moves to nMAG? > cf. RFC3775. Again, if the LMA is HA compliant, the LMA is enabled to act as mcast proxy. After movement, the nMAG will send a binding update to the LMA, which updates the tunnel endpoint. Multicast data will be sent to the updated tunnel - only the tunnel endpoint address changed. > > If the state timer of the LMA expires, it doesn't matter. The MAG is > > a function on an access router. Thus this entity operates MLD in the > > router part, which includes sending General Queries. This corresponds > > to MIPv6. > > Then MN replys *solicit* report and finally could receive multicast > data. But this time lag is not negligible at all and this *is* the real > performance problem I said. > What is PMIP-specific in this scenario? It corresponds to MIPv6: The HA maintains a binding cache, as well. Regards matthias -- Matthias Waehlisch . FU Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From schmidt@informatik.haw-hamburg.de Thu May 21 08:48: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 9ED2C28C125 for ; Thu, 21 May 2009 08:48:11 -0700 (PDT) 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=0.681, 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 BctpvuIGDV2D for ; Thu, 21 May 2009 08:48:10 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id A062F28C0FF for ; Thu, 21 May 2009 08:48:09 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178134163.adsl.alicedsl.de ([85.178.134.163] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1M7AWg-000Eph-2o; Thu, 21 May 2009 17:49:46 +0200 Message-ID: <4A15780E.4090707@informatik.haw-hamburg.de> Date: Thu, 21 May 2009 17:49:34 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Matthias Waehlisch References: <20090521.013837.180043133.asaeda@sfc.wide.ad.jp> <20090521.090614.171079249.asaeda@sfc.wide.ad.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 21 May 2009 15:48:11 -0000 Hi all, sorry for returning late into the discussion. What I read from the continued argument: it does not seem to be transparently clear how to deploy a minimal multicast support in a PMIPv6 environment. So this again stresses the need for a BCP document as proposed in the agenda. Let's allow for some time to write up this document - and return to discussing details on its basis. Best regards, Thomas Matthias Waehlisch wrote: > Hi Hitoshi, > > sorry for the late reply. > > On Thu, 21 May 2009, Hitoshi Asaeda wrote: > >>> No - that's unclear for me. If a MN moves from MAG to nMAG, the LMA >>> does not change. In particular, the LMA holds its previous states for >>> a certain amount of time (cf. pg. 15 RFC5213). When the MN is attached >>> to the nMAG, the LMA updates its binding and forwards data. >> For unicast, yes. >> > Please refer to the section/page in RFC5213 where it is defined that > states are tied to unicast only. > >>> If the LMA has sent multicast data before the movement, the LMA will >>> sent mcast data afterwards. This corresponds to MIPv6. >> How LMA knows which multicast channels should be forwarded when *that* >> MN moves to nMAG? >> > cf. RFC3775. > > Again, if the LMA is HA compliant, the LMA is enabled to act as mcast > proxy. After movement, the nMAG will send a binding update to the LMA, > which updates the tunnel endpoint. Multicast data will be sent to the > updated tunnel - only the tunnel endpoint address changed. > >>> If the state timer of the LMA expires, it doesn't matter. The MAG is >>> a function on an access router. Thus this entity operates MLD in the >>> router part, which includes sending General Queries. This corresponds >>> to MIPv6. >> Then MN replys *solicit* report and finally could receive multicast >> data. But this time lag is not negligible at all and this *is* the real >> performance problem I said. >> > What is PMIP-specific in this scenario? It corresponds to MIPv6: The HA > maintains a binding cache, as well. > > > Regards > matthias > -- 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 May 21 09:38:44 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5DC3A6EA7 for ; Thu, 21 May 2009 09:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.835 X-Spam-Level: ** X-Spam-Status: No, score=2.835 tagged_above=-999 required=5 tests=[AWL=0.423, 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 UOFf06vusLLZ for ; Thu, 21 May 2009 09:38:43 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 91EA23A682F for ; Thu, 21 May 2009 09:38:43 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 3453313D06C4 for ; Fri, 22 May 2009 01:35:40 +0900 (JST) Date: Fri, 22 May 2009 01:40:09 +0900 (JST) Message-Id: <20090522.014009.268204351.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: References: <20090521.090614.171079249.asaeda@sfc.wide.ad.jp> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 21 May 2009 16:38:44 -0000 > Again, if the LMA is HA compliant, the LMA is enabled to act as mcast > proxy. After movement, the nMAG will send a binding update to the LMA, > which updates the tunnel endpoint. Multicast data will be sent to the > updated tunnel - only the tunnel endpoint address changed. Ok, now I understand we are not expecting the same situation. You are talking about somehow providing multicast services without protocol modification, while I'm talking the required function (or required optimization?) for IP multicast support in PMIP6 domain. In a nutshell, transmitting same multicast data over a number of bi-dir tunnels established with LMA and MAG is not the real demand or expectation of pure IP multicast, and we have been thinking about the solution with the effective PMIP6 protocol modification. Regards, -- Hitoshi Asaeda From Dirk.von-Hugo@telekom.de Fri May 22 09:09: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 69DD63A67FC for ; Fri, 22 May 2009 09:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=-1.257, BAYES_50=0.001, 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 6m7WY6fzAwJq for ; Fri, 22 May 2009 09:09:56 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id DDD803A6CF0 for ; Fri, 22 May 2009 09:09:55 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 22 May 2009 18:11:25 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 May 2009 18:11:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 May 2009 18:11:24 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC8027848F679DF@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <20090520.230352.209594827.asaeda@sfc.wide.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Gauging need for enhancing PMIPv6 multicast support thread-index: AcnZU9NinviNs1XKSzysOCO76YiUJwBoRocQ References: <4A132FAF.2040602@ericsson.com> <4A13E3F8.9090102@erg.abdn.ac.uk><4A13EB6C.6050808@fhtw-berlin.de> <20090520.230352.209594827.asaeda@sfc.wide.ad.jp> From: To: , X-OriginalArrivalTime: 22 May 2009 16:11:25.0670 (UTC) FILETIME=[F4DD7060:01C9DAF7] Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 22 May 2009 16:09:57 -0000 Dear all, As stated before unfortunately I am not yet able to report operational = experience since 3GPP Rel. 9 specifying the PMIP6 option for Enhance = Packet Core of packet based LTE radio access (4G) is not yet concrete = enough for planning deployment - but in case a scenario as foreseen by = T-Mobile US (http://www.theonlyphoneyouneed.com/) for 2G and WLAN and = for voice at present will be upgraded to multicast services (messaging, = video, ...) a practible solution as planned by multimob is definitely = required. Perhaps other operators can add experimental results here?=20 Best regards, Dirk -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Hitoshi Asaeda Gesendet: Mittwoch, 20. Mai 2009 16:04 An: multimob@ietf.org Betreff: Re: [multimob] Gauging need for enhancing PMIPv6 multicast = support I totally agree with Suresh, while I have some concern for Thomas's comments. > * first is the "real" penalty inherited from home tunneling - we > have done simulation analysis on that some years ago: this is > strongly dependent on the HA position and on the actual topology. I don't think it is the "real" penalty. Home subscription (or bi-directional tunneling) is simple and may be Okay for some situation or providers. Living with bi-dir tunnel is not the real problem. (Thomas said HA above, but I assume we have been discussing PMIPv6 multicast and follow it.) The real problem in PMIPv6 multicast is that PMIPv6 does not provide any "multicast state transition" for "both home and remote subscription". This causes the "real" performance penalty and may cause heavy packet loss. In PMIPv6, LMA or MAG joins multicast tree but MN does not. MN just subscribes interesting channels with MLD. When MN moves and attach nMAG, both LMA and nMAG do not forward multicast data to that MN as they don't have any multicast state for that MN and the MN does not send *unsolicited* MLD reports for all subscribed channels again after he attaches nMAG. (The current MLD sends unsolicited report only once upon subscription; hence it is impossible to do it at the protocol level.) This major problem exists in both home and remote subscription. Hence "supporting remote subscription" is not our sole goal or rather inappropriate wording in the charter. > * probably the more important aspect is the experience or > "feeling" of operators. This is more on "how do operators want a > PMIP multicast to be". It's good to clarify the expected condition from operator's viewpoint. If this discussion can be based on some operators experiences, it'd be nicer. Regards, -- Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Fri May 22 09:16: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 B65953A6976 for ; Fri, 22 May 2009 09:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.275, 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 PQJvMs3ErVtf for ; Fri, 22 May 2009 09:16:25 -0700 (PDT) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id BE8DF3A6A6D for ; Fri, 22 May 2009 09:16:25 -0700 (PDT) Received: (qmail 1476 invoked by uid 60001); 22 May 2009 16:18:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243009081; bh=i7gkqg8DD7vJwtxxytn2ej4+8KlojPN0+s4mAXclt34=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Hc8Dkm/MujA88G8XBhwpYu5ruo64FdiA9g5O673OUWZ0bIbrwdKTIE/FkiXb6kpu5kL6iSmFzSaeSy46giqOKfB3lp1NP4sgKirIGmZRLlTLApgLKwnx5601P2qpvjNB8xSTBCG59qXSXTHvP/7BieWeZmSzaIPsIbdsfQijGEQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=xbkmzJNstpbmsupSAindcudGmKXtynhkcneAgpp4S4pQqTK2dDH82oJVZh9yY/2zVmqwxl5ckSYZBfSPyaREM/h/1w1ZitpXH0x5FA9k3F2XZ3PjmhoIJGnmk6v9MgYzml3/jOiKuYEDHgz2ra3Y9qLMgt6Foqg7nnB539J+JZ8=; Message-ID: <577864.445.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: xXkswMMVM1lYJ2Gc7ult4EQf76cAyUvj2UvyAb11hMEBbws_.Nn1E2T.xc9uqDYxg68U1VLDmcSmlivFPejsXHy7pS8YW7VMW6Tr7Ne0pmU3LbIx_NbWZtzb69CHnf_DlPqX41ersXjQ96urIlrHerXbAQ7uiXC4jOuJFEta_IbhwcyZ9nurGxP_Iqj5.iTMfiVDl7sxm4zkNoEks04DW3Hht1RVEZV_5tRgYvwOnAGQrpsbTeWFPSK52rlQsIou7ZxxpKpfrSRsKfETWLXN3p90aNoxVTGAd2ZZaGLUypFJyBcVTWMtfjobFrOhC6Uu8feP6RsrLYVESJtNAdeg3A-- Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Fri, 22 May 2009 09:18:01 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 Date: Fri, 22 May 2009 09:18:01 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-2078300191-1243009081=:445" Subject: [multimob] Multimob Charter v3 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, 22 May 2009 16:16:26 -0000 --0-2078300191-1243009081=:445 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Folks,=0A=A0 I updated a little bit the charter based on Imed's comments.= =0A=0APlease continue to scrutinize the charter and post your comments on t= he list.=0A=0ABehcet=0A=0A=0A --0-2078300191-1243009081=:445 Content-Type: text/plain; name="multimobcharter03.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="multimobcharter03.txt" Ck11bHRpY2FzdCBNb2JpbGl0eSAobXVsdGltb2IpDQoNCkNoYWlyczoNClRC RA0KDQpJbnRlcm5ldCBBcmVhIChpbnQpIERpcmVjdG9yczoNCkphcmkgQXJr a28gPGphcmkuYXJra29AcGl1aGEubmV0Pg0KTWFyayBUb3duc2xleSA8dG93 bnNsZXlAY2lzY28uY29tPiANCg0KSW50ZXJuZXQgQXJlYSBBZHZpc29yOg0K SmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+DQoNClNlY3VyaXR5 IEFyZWEgQWR2aXNvcjoNCk1hcnNoYWxsIEV1YmFua3MgPHRtZUBhbWVyaWNh ZnJlZS50dj4uDQoNCk1haWxpbmcgTGlzdHM6DQpHZW5lcmFsIERpc2N1c3Np b246IG11bHRpbW9iQGlldGYub3JnDQpTdWJzY3JpYmUgb25saW5lIGF0OiBo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aW1v Yg0KDQpEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwDQoNClRoZSBNdWx0 aWNhc3QgbW9iaWxpdHkgKG11bHRpbW9iKSB3aWxsIGRldmVsb3AgYSBzZXQg b2YgcHJvdG9jb2wgZXh0ZW5zaW9ucyBhbmQgcHJvdmlkZSBndWlkYW5jZSBh cHByb3ByaWF0ZSBmb3IgSVB2NCBhbmQgSVB2NiBtdWx0aWNhc3QgaW4gYSBt b2JpbGUgZW52aXJvbm1lbnQuIEl0IHdpbGwgY29uc2lkZXIgYm90aCBzb3Vy Y2Ugc3BlY2lmaWMgbXVsdGljYXN0IChTU00pICBhbmQgYW55IHNvdXJjZSBt dWx0aWNhc3QgKEFTTSkgbXVsdGljYXN0IG1vZGVscy4KClRoZSBzY29wZSBv ZiB3b3JrIHdpbGwgYmUgbGltaXRlZCB0byBncm91cCBtYW5hZ2VtZW50IGFu ZCBtb2JpbGUgSVAgcHJvdG9jb2xzIC0gcHJveGllZCBvciBjbGllbnQtYmFz ZWQuIFdvcmsgcmVxdWlyaW5nIG1vZGlmaWNhdGlvbnMgb2YgbXVsdGljYXN0 IHJvdXRpbmcgcHJvdG9jb2xzIChQSU0tU00sIFBJTS1ETSwgZXRjLikgaXMg b3V0IG9mIHNjb3BlLiBTcGVjaWZpYyBnb2FscyBhcmU6CiAgCi0gU3BlY2lm eSBJR01QL01MRCBleHRlbnNpb25zIG1ldGhvZHMgZm9yIHJlZHVjaW5nIGpv aW4vbGVhdmUgbGF0ZW5jeS4KLSBTcGVjaWZ5IGEgZG9ybWFudCBtb2RlIG9w ZXJhdGlvbiBmb3IgSUdNUHYzL01MRHYyLgotIFVwZGF0ZSBQTUlQdjYgdG8g c3VwcG9ydCByZW1vdGUgc3Vic2NyaXB0aW9uLCBmYXN0IGhhbmRvdmVyIGFu ZCBJUHY0IG11bHRpY2FzdC4gDQotIFByb3ZpZGUgZ3VpZGFuY2UgYW5kIHNw ZWNpZnkgbWV0aG9kcyBmb3IgbXVsdGktaG9taW5nIHN1cHBvcnQgZm9yIG11 bHRpY2FzdC4NCg0KTXVsdGltb2Igd2lsbCBzcGVjaWZ5IGEgc2V0IG9mIGV4 dGVuc2lvbnMgdG8gSUdNUHYzL01MRHYyIGZvciBtb2JpbGUgZW52aXJvbm1l bnRzLiBJR01QdjMvTUxEdjIgaGFzIGJlZW4gc3BlY2lmaWVkIGZvciB3aXJl ZCBuZXR3b3JrcyB3aXRoIHNoYXJlZCBsaW5rcy4gTW9iaWxlIG5vZGVzIGFs c28gaGF2ZSBvdGhlciBuZWVkcyAoZS5nLiAgZW50ZXJpbmcgYSBkb3JtYW50 IG1vZGUgdG8gY29uc2VydmUgYmF0dGVyeSBwb3dlciwgbWluaW1pc2luZyB0 aGUgbGF0ZW5jeSBmb3Igam9pbmluZyBhbmQgbGVhdmluZyBhIGdyb3VwIGlu IHN1cHBvcnQgb2YgbW92ZW1lbnQpLiAgVGhlIHdvcmtpbmcgZ3JvdXAgd2ls bCBhc3Nlc3MgZXhpc3Rpbmcgc29sdXRpb25zIGZvciBncm91cCBtYW5hZ2Vt ZW50LCBhbmQgZGV0ZXJtaW5lIGlmIHRoZXNlIG1ldGhvZHMgYXJlIHN1ZmZp Y2llbnQuIFRoaXMgd2lsbCBpbmNsdWRlIGRlZmluaW5nIGJlc3QgY3VycmVu dCBwcmFjdGljZSBmb3Igc2VsZWN0aW9uIG9mIHRpbWVyIHZhbHVlcyBhbmQg cHJvdG9jb2wgcGFyYW1ldGVycy4gSWYgdGhlc2UgbWV0aG9kcyBhcmUgbm90 IHN1ZmZpY2llbnQsIHRoZSB3b3JraW5nIGdyb3VwIHNoYWxsIHByb3Bvc2Ug bmV3IHNvbHV0aW9ucyBhcyB1cGRhdGVzIHRvIGV4aXN0aW5nIHByb3RvY29s cyAoaW5jbHVkaW5nIHBvc3NpYmxlIGludHJvZHVjdGlvbiBvZiBhZGRpdGlv bmFsIG1lc3NhZ2UgdHlwZXMpLiBJdCBpcyBhIGdvYWwgZm9yIHRoZSB3b3Jr aW5nIGdyb3VwIHRvIGVuc3VyZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdp dGggdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIG9mIGdyb3VwIG1hbmFn ZW1lbnQgcHJvdG9jb2xzLiBNZXNzYWdlIHN0cnVjdHVyZXMgc3VwcG9ydGVk IGluIGN1cnJlbnQgZGVwbG95ZWQgbmV0d29ya3Mgd2lsbCBub3QgYmUgbW9k aWZpZWQuDQoKVW5pY2FzdCBtb2JpbGl0eSBwcm90b2NvbHMgKE1vYmlsZSBJ UHY2LCBEdWFsLVN0YWNrIE1vYmlsZSBJUHY2IGFuZCBhbHNvIE1vYmlsZSBJ UHY0KSBwcm92aWRlIGJhc2ljIG11bHRpY2FzdCBzdXBwb3J0IGFuZCBlbmFi bGUgbW9iaWxlIG5vZGVzIHRvIHBlcmZvcm0gYmktZGlyZWN0aW9uYWwgdHVu bmVsaW5nIGFuZCByZWNlaXZlIG11bHRpY2FzdCB0cmFmZmljIGFuY2hvcmVk IGF0IHRoZSBob21lIGFnZW50LiBIb3dldmVyLCBzdWNoIGJhc2ljIHN1cHBv cnQgc3VmZmVycyBmcm9tIHRoZSAnYXZhbGFuY2hlJyBwcm9ibGVtIGFzIHRo ZSBob21lIGFnZW50cyByZXBsaWNhdGUgdGhlIHBhY2tldHMgYW5kIHVuaWNh c3QgdGhlbSB0byB0aGUgbW9iaWxlIG5vZGVzIGFzIHdlbGwgYXMgZnJvbSBu b24tb3B0aW1hbCwgdHJpYW5ndWxhciByb3V0aW5nLCAncmVtb3RlIHN1YnNj cmlwdGlvbicgc3VmZmVycyBmcm9tIHBvc3NpYmxlIGxvc3Mgb2YgZGF0YSBk dXJpbmcgaGFuZG92ZXJzLiBUaGUgV0cgd2lsbCBhZGRyZXNzIHRoZXNlIGlz c3VlcyB3aXRoaW4gdGhlIGNvbnRleHQgb2YgUHJveHkgTW9iaWxlIElQdjYg KFBNSVB2NikuCgpDdXJyZW50bHkgUE1JUHY2IChhbmQgbW9iaWxpdHkgZXh0 ZW5zaW9uIHByb3RvY29scyBsaWtlICBGTUlQdjYgYW5kIEhNSVB2NikgZG9l cyBub3QgIHN1cHBvcnQgbXVsdGljYXN0aW5nIGV4cGxpY2l0bHkuIEJhc2lj IHN1cHBvcnQgZm9yIG11bHRpY2FzdCB3aXRoIGJpLWRpcmVjdGlvbmFsIHR1 bm5lbGluZyB3aWxsIGJlIGRvY3VtZW50ZWQgZm9yIFBNSVB2NiAod2l0aCBu byBuZXcgbWVzc2FnZSB0eXBlcyBvciAgY2hhbmdlcyB0byB0aGUgbWVzc2Fn ZSBwYXJhbWV0ZXJzKS4gUE1JUHY2IHRoYXQgaGFuZGxlcyBJUHY0IGFuZCBJ UHY2IHdpbGwgYmUgZXh0ZW5kZWQgdG8gYWxzbyBzdXBwb3J0IG11bHRpY2Fz dGluZyB3aXRoIElQdjQuIEZpbmFsbHksIFBNSVB2NiBiYXNpYyBtdWx0aWNh c3Qgc3VwcG9ydCB3aWxsIGJlIGV4dGVuZGVkIHRvIHN1cHBvcnQgcmVtb3Rl IHN1YnNjcmlwdGlvbiBhbmQgZmFzdCBoYW5kb3Zlci4KCkEgbXVsdGktaG9t ZWQgbW9iaWxlIG5vZGUgbWF5IHdpc2ggdG8gam9pbiBtdWx0aWNhc3QgZ3Jv dXBzIGFuZCB0byBkaXJlY3QgZGlmZmVyZW50IG11bHRpY2FzdCBmbG93cyB0 byBpdHMgaW50ZXJmYWNlcy4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZWZp bmUgbXVsdGktaG9taW5nIHN1cHBvcnQgZm9yIG11bHRpY2FzdCwgaW5jbHVk aW5nIGFuIGVmZmljaWVudCBwZXItaW50ZXJmYWNlIHN1YnNjcmlwdGlvbiBt YW5hZ2VtZW50IGluIHRoZSBjYXNlIG9mIG11bHRpLWhvbWVkIG1vYmlsaXR5 IGFuZCBtdWx0aWNhc3QgZmxvdyBiaW5kaW5nLiAKDQpJbiBwZXJmb3JtaW5n IHRoaXMgd29yaywgdGhlIE11bHRpbW9iIHdvcmtpbmcgZ3JvdXAgd2lsbCB3 b3JrIGNsb3NlbHkgd2l0aCBORVRMTU0NCndvcmtpbmcgZ3JvdXAgYW5kIHdp bGwgY29vcmRpbmF0ZSB3b3JrIG9uIElHTVAvTUxEIGV4dGVuc2lvbnMgd2l0 aCB0aGUgTUJPTkVEIHdvcmtpbmcgZ3JvdXAuDQoNCkdPQUxTIGFuZCBNSUxF U1RPTkVTOg0KDQpzaXggbW9udGhzOiANCi0gU3VibWl0IGEgZG9jdW1lbnQg b24gbXVsdGlob21pbmcgc3VwcG9ydCBmb3IgbXVsdGljYXN0IGFzIGEgQkNQ IFJGQy4KLSBTdWJtaXQgYSBkb2N1bWVudCBvbiBtaW5pbWFsIGRlcGxveW1l bnQgZm9yIFBNSVB2NiByZW1vdGUgc3Vic2NyaXB0aW9uIGZvciBtdWx0aWNh c3QgYXMgYSBCQ1AgUkZDDQoNCk9uZSB5ZWFyOiAKLSBTdWJtaXQgYSBkb2N1 bWVudCBvbiBJR01QL01MRCBleHRlbnNpb25zIGZvciBtdWx0aWNhc3QgbW9i aWxpdHkgYXMgYW4gRVhQL1BTIFJGQy4NCi0gU3VibWl0IGEgZG9jdW1lbnQg b24gZXh0ZW5zaW9ucyBmb3IgbXVsdGljYXN0IG1vYmlsaXR5IGluIFBNSVB2 NiBhcyBhbiBFWFAvUFMgUkZDLg0KDQpSZWNoYXJ0ZXIgb3IgY2xvc2Ugd29y a2luZyBncm91cC4K --0-2078300191-1243009081=:445-- From behcetsarikaya@yahoo.com Fri May 22 09:20: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 817CD3A6847 for ; Fri, 22 May 2009 09:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.439, 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 sZPPkooXpY2j for ; Fri, 22 May 2009 09:20:24 -0700 (PDT) Received: from n3.bullet.mail.re3.yahoo.com (n3.bullet.mail.re3.yahoo.com [68.142.237.110]) by core3.amsl.com (Postfix) with SMTP id 913BE3A6B1B for ; Fri, 22 May 2009 09:20:24 -0700 (PDT) Received: from [68.142.230.29] by n3.bullet.mail.re3.yahoo.com with NNFMP; 22 May 2009 16:22:01 -0000 Received: from [67.195.9.81] by t2.bullet.re2.yahoo.com with NNFMP; 22 May 2009 16:22:01 -0000 Received: from [67.195.9.109] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 22 May 2009 16:22:01 -0000 Received: from [127.0.0.1] by omp113.mail.gq1.yahoo.com with NNFMP; 22 May 2009 16:21:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 526980.53297.bm@omp113.mail.gq1.yahoo.com Received: (qmail 15623 invoked by uid 60001); 22 May 2009 16:22:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243009320; bh=kcpA5o9usijmz4oLvilG9nrAI4I8rElYlyUZpi5xQY4=; 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=xcuDQ1KIuHZwV/hWv8ZoAq70SPIcQl7swSxhX6G1xO59IiE7LbVPuUeARTtBcYqRJVuR4K/MvQ2hy4fAOa8VNk4WViu/FpTByeeuzov+O5E7LDvtcy8N2LRSCst7+rnN2tNDq8+BXNS11GyKQzB/IUFSiLJOv/d95cGKt3Giz7w= 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=FIOHWC+2jY3UMQ11xVInLafGkSsquzIxxtuwoNPuvZ/bqJrvst5MtUpQy6qUoZT26ZCYBJzmFkJLkEKyxCf4ixycG1TwdYlt4052/EcMTLykipoO6S0KnJ5ZYmDMBtceKsCHYyXLCp/xWN8A5qxjabye8qZ/RZdVjYFy5fGCX+U=; Message-ID: <387359.15518.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: psE.k60VM1kTpsOXbjLJaGghBnwhC4xYinw0Fmkt96PezLaBCWwq.OK0A07ciwahX2Z7iKtDv3R8k.NGex_IPuvef5iQl5zaCnL0P3yu8as2qMKqwSFWo5D4aIhRPttWq7GG0Uts1RnjkOT17441n_2dfkNI8sqlcUdpJ.bAVWiiSFxs5bTmk2wsxLdt9vMsCOktAP2B42uXWFhYM6S4XRyK6B2L5NL2QpgeMqoBvjmwUYIdbl_6Ii6tZhPy97G26N1EwGuh_8bV5FQMRepqA1GQVFW.9YN0D4p.KcSCtdVLLe3iv3tHLRTKNnq9QCx57cU8frXt Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Fri, 22 May 2009 09:22:00 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <20090521.090614.171079249.asaeda@sfc.wide.ad.jp> <20090522.014009.268204351.asaeda@sfc.wide.ad.jp> Date: Fri, 22 May 2009 09:22:00 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda , multimob@ietf.org In-Reply-To: <20090522.014009.268204351.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 22 May 2009 16:20:25 -0000 Hi Hitoshi,=0A=A0 Can you please explain more? Here you are pointing to the= avalance problem which is well known. But I think that Matthias' point was= related to the handover. How do you justify your handover processing?=0A= =0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Original Message ----=0AFrom: Hito= shi Asaeda =0ATo: multimob@ietf.org=0ASent: Thursday= , May 21, 2009 11:40:09 AM=0ASubject: Re: [multimob] Gauging need for enhan= cing PMIPv6 multicast support=0A=0A>=A0 Again, if the LMA is HA compliant, = the LMA is enabled to act as mcast =0A> proxy. After movement, the nMAG wil= l send a binding update to the LMA, =0A> which updates the tunnel endpoint.= Multicast data will be sent to the =0A> updated tunnel - only the tunnel e= ndpoint address changed.=0A=0AOk, now I understand we are not expecting the= same situation.=0AYou are talking about somehow providing multicast servic= es without=0Aprotocol modification, while I'm talking the required function= (or=0Arequired optimization?) for IP multicast support in PMIP6 domain.=0A= =0AIn a nutshell, transmitting same multicast data over a number of=0Abi-di= r tunnels established with LMA and MAG is not the real demand or=0Aexpectat= ion of pure IP multicast, and we have been thinking about the=0Asolution wi= th the effective PMIP6 protocol modification.=0A=0ARegards,=0A--=0AHitoshi = Asaeda=0A_______________________________________________=0Amultimob mailing= list=0Amultimob@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/multimob= =0A=0A=0A=0A From pierrick.seite@orange-ftgroup.com Mon May 25 03:14:29 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65FA13A6E84 for ; Mon, 25 May 2009 03:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 7Bdk4374Gp5j for ; Mon, 25 May 2009 03:14:28 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id CE3F73A6E80 for ; Mon, 25 May 2009 03:14:27 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 May 2009 12:15:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 May 2009 12:15:45 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46210DDAF@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <643B0A1D1A13AB498304E0BBC8027848F679DF@S4DE8PSAAQC.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Gauging need for enhancing PMIPv6 multicast support Thread-Index: AcnZU9NinviNs1XKSzysOCO76YiUJwBoRocQAIlKq0A= References: <4A132FAF.2040602@ericsson.com> <4A13E3F8.9090102@erg.abdn.ac.uk><4A13EB6C.6050808@fhtw-berlin.de> <20090520.230352.209594827.asaeda@sfc.wide.ad.jp> <643B0A1D1A13AB498304E0BBC8027848F679DF@S4DE8PSAAQC.mitte.t-com.de> From: To: , , X-OriginalArrivalTime: 25 May 2009 10:15:39.0408 (UTC) FILETIME=[C0BD9900:01C9DD21] Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 25 May 2009 10:14:29 -0000 Hi all, I share Dirk's opinion. Specification of PMIPv6 in 3GPP/EPC is not = enough mature for planning deployment and, thus, we are far from being = able to report experience. However there are motivations for multicast = in mobility situation. Today, Mobile IPTV on 3G network is a pure = unicast service; but growth of video traffic on 3G will require soon = solutions for a better resource management. A solution is the offload = where video traffic is handoff from 3G and WLAN when it is possible, so = efficient mobility management is required. A complementary solution is = obviously to leverage on multicast delivery especially as multicast is = currently used for IPTV on fixed network. In this context multimob = outcomes could help. Regards Pierrick =20 > -----Message d'origine----- > De=A0: Dirk.von-Hugo@telekom.de [mailto:Dirk.von-Hugo@telekom.de] > Envoy=E9=A0: vendredi 22 mai 2009 18:11 > =C0=A0: asaeda@sfc.wide.ad.jp; multimob@ietf.org > Objet=A0: AW: [multimob] Gauging need for enhancing PMIPv6 multicast = support >=20 > Dear all, > As stated before unfortunately I am not yet able to report operational > experience since 3GPP Rel. 9 specifying the PMIP6 option for Enhance > Packet Core of packet based LTE radio access (4G) is not yet concrete > enough for planning deployment - but in case a scenario as foreseen by = T- > Mobile US (http://www.theonlyphoneyouneed.com/) for 2G and WLAN and = for > voice at present will be upgraded to multicast services (messaging, = video, > ...) a practible solution as planned by multimob is definitely = required. > Perhaps other operators can add experimental results here? >=20 >=20 > Best regards, > Dirk > -----Urspr=FCngliche Nachricht----- > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im > Auftrag von Hitoshi Asaeda > Gesendet: Mittwoch, 20. Mai 2009 16:04 > An: multimob@ietf.org > Betreff: Re: [multimob] Gauging need for enhancing PMIPv6 multicast > support >=20 > I totally agree with Suresh, while I have some concern for Thomas's > comments. >=20 > > * first is the "real" penalty inherited from home tunneling - we > > have done simulation analysis on that some years ago: this is > > strongly dependent on the HA position and on the actual topology. >=20 > I don't think it is the "real" penalty. Home subscription (or > bi-directional tunneling) is simple and may be Okay for some situation > or providers. Living with bi-dir tunnel is not the real problem. >=20 > (Thomas said HA above, but I assume we have been discussing PMIPv6 > multicast and follow it.) > The real problem in PMIPv6 multicast is that PMIPv6 does not provide > any "multicast state transition" for "both home and remote > subscription". This causes the "real" performance penalty and may > cause heavy packet loss. >=20 > In PMIPv6, LMA or MAG joins multicast tree but MN does not. MN just > subscribes interesting channels with MLD. When MN moves and attach > nMAG, both LMA and nMAG do not forward multicast data to that MN as > they don't have any multicast state for that MN and the MN does not > send *unsolicited* MLD reports for all subscribed channels again after > he attaches nMAG. (The current MLD sends unsolicited report only once > upon subscription; hence it is impossible to do it at the protocol > level.) >=20 > This major problem exists in both home and remote subscription. > Hence "supporting remote subscription" is not our sole goal or rather > inappropriate wording in the charter. >=20 > > * probably the more important aspect is the experience or > > "feeling" of operators. This is more on "how do operators want a > > PMIP multicast to be". >=20 > It's good to clarify the expected condition from operator's > viewpoint. If this discussion can be based on some operators > experiences, it'd be nicer. >=20 > Regards, > -- > Hitoshi Asaeda >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From schmidt@informatik.haw-hamburg.de Mon May 25 03:19:49 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0303A69A2 for ; Mon, 25 May 2009 03:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.429 X-Spam-Level: X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_40=-0.185, 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 HLjcsJwxV94F for ; Mon, 25 May 2009 03:19:47 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 888EA3A6E90 for ; Mon, 25 May 2009 03:19:45 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178168007.adsl.alicedsl.de ([85.178.168.7] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1M8XJ1-000Crf-Ey; Mon, 25 May 2009 12:21:19 +0200 Message-ID: <4A1A711A.5000505@informatik.haw-hamburg.de> Date: Mon, 25 May 2009 12:21:14 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: pierrick.seite@orange-ftgroup.com References: <4A132FAF.2040602@ericsson.com> <4A13E3F8.9090102@erg.abdn.ac.uk><4A13EB6C.6050808@fhtw-berlin.de> <20090520.230352.209594827.asaeda@sfc.wide.ad.jp> <643B0A1D1A13AB498304E0BBC8027848F679DF@S4DE8PSAAQC.mitte.t-com.de> <843DA8228A1BA74CA31FB4E111A5C46210DDAF@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46210DDAF@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org, Dirk.von-Hugo@telekom.de Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 25 May 2009 10:19:49 -0000 Hi Pierrick, great to hear - and yes, we want to be ahead of operator deployment :-). Right now we are working on this minimal multicast deployment solution for PMIPv6 - so hopefully, we will soon have a track to a converging view on how multicast can be rolled out in PMIPv6 without any "headstanding". Best regards, Thomas pierrick.seite@orange-ftgroup.com wrote: > Hi all, > > I share Dirk's opinion. Specification of PMIPv6 in 3GPP/EPC is not enough mature for planning deployment and, thus, we are far from being able to report experience. However there are motivations for multicast in mobility situation. Today, Mobile IPTV on 3G network is a pure unicast service; but growth of video traffic on 3G will require soon solutions for a better resource management. A solution is the offload where video traffic is handoff from 3G and WLAN when it is possible, so efficient mobility management is required. A complementary solution is obviously to leverage on multicast delivery especially as multicast is currently used for IPTV on fixed network. In this context multimob outcomes could help. > > Regards > Pierrick > >> -----Message d'origine----- >> De : Dirk.von-Hugo@telekom.de [mailto:Dirk.von-Hugo@telekom.de] >> Envoyé : vendredi 22 mai 2009 18:11 >> À : asaeda@sfc.wide.ad.jp; multimob@ietf.org >> Objet : AW: [multimob] Gauging need for enhancing PMIPv6 multicast support >> >> Dear all, >> As stated before unfortunately I am not yet able to report operational >> experience since 3GPP Rel. 9 specifying the PMIP6 option for Enhance >> Packet Core of packet based LTE radio access (4G) is not yet concrete >> enough for planning deployment - but in case a scenario as foreseen by T- >> Mobile US (http://www.theonlyphoneyouneed.com/) for 2G and WLAN and for >> voice at present will be upgraded to multicast services (messaging, video, >> ...) a practible solution as planned by multimob is definitely required. >> Perhaps other operators can add experimental results here? >> >> >> Best regards, >> Dirk >> -----Ursprüngliche Nachricht----- >> Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im >> Auftrag von Hitoshi Asaeda >> Gesendet: Mittwoch, 20. Mai 2009 16:04 >> An: multimob@ietf.org >> Betreff: Re: [multimob] Gauging need for enhancing PMIPv6 multicast >> support >> >> I totally agree with Suresh, while I have some concern for Thomas's >> comments. >> >>> * first is the "real" penalty inherited from home tunneling - we >>> have done simulation analysis on that some years ago: this is >>> strongly dependent on the HA position and on the actual topology. >> I don't think it is the "real" penalty. Home subscription (or >> bi-directional tunneling) is simple and may be Okay for some situation >> or providers. Living with bi-dir tunnel is not the real problem. >> >> (Thomas said HA above, but I assume we have been discussing PMIPv6 >> multicast and follow it.) >> The real problem in PMIPv6 multicast is that PMIPv6 does not provide >> any "multicast state transition" for "both home and remote >> subscription". This causes the "real" performance penalty and may >> cause heavy packet loss. >> >> In PMIPv6, LMA or MAG joins multicast tree but MN does not. MN just >> subscribes interesting channels with MLD. When MN moves and attach >> nMAG, both LMA and nMAG do not forward multicast data to that MN as >> they don't have any multicast state for that MN and the MN does not >> send *unsolicited* MLD reports for all subscribed channels again after >> he attaches nMAG. (The current MLD sends unsolicited report only once >> upon subscription; hence it is impossible to do it at the protocol >> level.) >> >> This major problem exists in both home and remote subscription. >> Hence "supporting remote subscription" is not our sole goal or rather >> inappropriate wording in the charter. >> >>> * probably the more important aspect is the experience or >>> "feeling" of operators. This is more on "how do operators want a >>> PMIP multicast to be". >> It's good to clarify the expected condition from operator's >> viewpoint. If this discussion can be based on some operators >> experiences, it'd be nicer. >> >> Regards, >> -- >> Hitoshi Asaeda >> >> _______________________________________________ >> 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 -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From gorry@erg.abdn.ac.uk Tue May 26 03:07:40 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3933A6A03 for ; Tue, 26 May 2009 03:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 tbPZcIrPDSZX for ; Tue, 26 May 2009 03:07:32 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 149763A6B3D for ; Tue, 26 May 2009 03:07:31 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n4QA982M017701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2009 11:09:08 +0100 (BST) Message-ID: <4A1BBFC4.70909@erg.abdn.ac.uk> Date: Tue, 26 May 2009 11:09:08 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: pierrick.seite@orange-ftgroup.com References: <4A132FAF.2040602@ericsson.com> <4A13E3F8.9090102@erg.abdn.ac.uk><4A13EB6C.6050808@fhtw-berlin.de> <20090520.230352.209594827.asaeda@sfc.wide.ad.jp> <643B0A1D1A13AB498304E0BBC8027848F679DF@S4DE8PSAAQC.mitte.t-com.de> <843DA8228A1BA74CA31FB4E111A5C46210DDAF@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46210DDAF@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org, Dirk.von-Hugo@telekom.de Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 10:07:40 -0000 I think I am more concerned whether there is a perceived need for this work, rather than a standard that relies on this. Specifically, is this likely to be the correct solution for this need? This may require a prediction of the future deployment, and it would be good to see then that we all agree on the use-cases and needs that would result. Gorry pierrick.seite@orange-ftgroup.com wrote: > Hi all, > > I share Dirk's opinion. Specification of PMIPv6 in 3GPP/EPC is not enough mature for planning deployment and, thus, we are far from being able to report experience. However there are motivations for multicast in mobility situation. Today, Mobile IPTV on 3G network is a pure unicast service; but growth of video traffic on 3G will require soon solutions for a better resource management. A solution is the offload where video traffic is handoff from 3G and WLAN when it is possible, so efficient mobility management is required. A complementary solution is obviously to leverage on multicast delivery especially as multicast is currently used for IPTV on fixed network. In this context multimob outcomes could help. > > Regards > Pierrick > >> -----Message d'origine----- >> De : Dirk.von-Hugo@telekom.de [mailto:Dirk.von-Hugo@telekom.de] >> Envoyé : vendredi 22 mai 2009 18:11 >> À : asaeda@sfc.wide.ad.jp; multimob@ietf.org >> Objet : AW: [multimob] Gauging need for enhancing PMIPv6 multicast support >> >> Dear all, >> As stated before unfortunately I am not yet able to report operational >> experience since 3GPP Rel. 9 specifying the PMIP6 option for Enhance >> Packet Core of packet based LTE radio access (4G) is not yet concrete >> enough for planning deployment - but in case a scenario as foreseen by T- >> Mobile US (http://www.theonlyphoneyouneed.com/) for 2G and WLAN and for >> voice at present will be upgraded to multicast services (messaging, video, >> ...) a practible solution as planned by multimob is definitely required. >> Perhaps other operators can add experimental results here? >> >> >> Best regards, >> Dirk >> -----Ursprüngliche Nachricht----- >> Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im >> Auftrag von Hitoshi Asaeda >> Gesendet: Mittwoch, 20. Mai 2009 16:04 >> An: multimob@ietf.org >> Betreff: Re: [multimob] Gauging need for enhancing PMIPv6 multicast >> support >> >> I totally agree with Suresh, while I have some concern for Thomas's >> comments. >> >>> * first is the "real" penalty inherited from home tunneling - we >>> have done simulation analysis on that some years ago: this is >>> strongly dependent on the HA position and on the actual topology. >> I don't think it is the "real" penalty. Home subscription (or >> bi-directional tunneling) is simple and may be Okay for some situation >> or providers. Living with bi-dir tunnel is not the real problem. >> >> (Thomas said HA above, but I assume we have been discussing PMIPv6 >> multicast and follow it.) >> The real problem in PMIPv6 multicast is that PMIPv6 does not provide >> any "multicast state transition" for "both home and remote >> subscription". This causes the "real" performance penalty and may >> cause heavy packet loss. >> >> In PMIPv6, LMA or MAG joins multicast tree but MN does not. MN just >> subscribes interesting channels with MLD. When MN moves and attach >> nMAG, both LMA and nMAG do not forward multicast data to that MN as >> they don't have any multicast state for that MN and the MN does not >> send *unsolicited* MLD reports for all subscribed channels again after >> he attaches nMAG. (The current MLD sends unsolicited report only once >> upon subscription; hence it is impossible to do it at the protocol >> level.) >> >> This major problem exists in both home and remote subscription. >> Hence "supporting remote subscription" is not our sole goal or rather >> inappropriate wording in the charter. >> >>> * probably the more important aspect is the experience or >>> "feeling" of operators. This is more on "how do operators want a >>> PMIP multicast to be". >> It's good to clarify the expected condition from operator's >> viewpoint. If this discussion can be based on some operators >> experiences, it'd be nicer. >> >> Regards, >> -- >> Hitoshi Asaeda >> >> _______________________________________________ >> 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 jari.arkko@piuha.net Tue May 26 03:41:47 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193603A6A59 for ; Tue, 26 May 2009 03:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, J_CHICKENPOX_42=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 qiraV94N3eBD for ; Tue, 26 May 2009 03:41:46 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 48C213A69A7 for ; Tue, 26 May 2009 03:41:46 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id ACB41198714; Tue, 26 May 2009 13:43:26 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 74E8219870C; Tue, 26 May 2009 13:43:26 +0300 (EEST) Message-ID: <4A1BC7CB.7090207@piuha.net> Date: Tue, 26 May 2009 13:43:23 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Suresh Krishnan References: <991096.55707.qm@web111410.mail.gq1.yahoo.com> <4A132FAF.2040602@ericsson.com> In-Reply-To: <4A132FAF.2040602@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: multimob@ietf.org Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 26 May 2009 10:41:47 -0000 Suresh, > * Is the performance penalty experienced by the operator using PMIPv6 > (AS IS) with multicast significant enough to warrant changing PMIPv6 > and/or the multicast protocols? My key takeaway from the previous BOF was that we had no agreement on what"AS IS" means. That is, some people felt that the specification clearly dictated an inefficient model, and others -- including one of the chairs of the NETLMM WG -- felt that the specification allowed different ways to build and configure networks, including at least some forms of efficient multicast treatment. So I think the question is actually more complex. I think we have a continuum: (a) we don't even care, because we are not going to use multicast with proxy mip (b) no new protocol mechanisms needed, and specifications are clear on how to use existing ones efficiently (c) no new protocol mechanisms needed, but we need better operational instructions on how set up proxy mobility in the most efficient way (d) better operational instructions and new protocol mechanisms are needed Jari From jari.arkko@piuha.net Tue May 26 03:43: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 87BFE3A6A59 for ; Tue, 26 May 2009 03:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 RyutcZHuY1Nk for ; Tue, 26 May 2009 03:43:23 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id B47E13A69A7 for ; Tue, 26 May 2009 03:43:23 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id C50A719878C for ; Tue, 26 May 2009 13:45:04 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 8CF4C19869F for ; Tue, 26 May 2009 13:45:04 +0300 (EEST) Message-ID: <4A1BC82D.6080607@piuha.net> Date: Tue, 26 May 2009 13:45:01 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [multimob] Another question X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 10:43:24 -0000 Also, I have another question of my own. This does not have anything to do with the technical parts, but more about groups of people who are interested in this. Are the people interested in multimob and proxy mip disjoint groups? For instance, are there people who are interested in Multimob going forward AND who are, e.g., proxy MIP implementors? Jari From schmidt@informatik.haw-hamburg.de Tue May 26 04:06:46 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 35FC43A7078 for ; Tue, 26 May 2009 04:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.582 X-Spam-Level: X-Spam-Status: No, score=-1.582 tagged_above=-999 required=5 tests=[AWL=0.667, 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 72SGbJ+lBC3a for ; Tue, 26 May 2009 04:06:45 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id E1DEC3A6991 for ; Tue, 26 May 2009 04:06:42 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178128213.adsl.alicedsl.de ([85.178.128.213] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1M8uVz-000266-8J; Tue, 26 May 2009 13:08:15 +0200 Message-ID: <4A1BCD9A.9010902@informatik.haw-hamburg.de> Date: Tue, 26 May 2009 13:08:10 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jari Arkko References: <991096.55707.qm@web111410.mail.gq1.yahoo.com> <4A132FAF.2040602@ericsson.com> <4A1BC7CB.7090207@piuha.net> In-Reply-To: <4A1BC7CB.7090207@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 26 May 2009 11:06:46 -0000 Hi Jari, thanks for clarification! Jari Arkko wrote: > > So I think the question is actually more complex. I think we have a > continuum: > > (a) we don't even care, because we are not going to use multicast with > proxy mip This, I guess, should be answered by operators and service providers - there have been a few strong statements for the use of multicast, but silence from many others. > (b) no new protocol mechanisms needed, and specifications are clear on > how to use existing ones efficiently Discussions on mailing lists and in meetings seem to speak a clear language: there is quite some confusion, ranging from "PMIPv6 objects multicast" up to "clearly it works with multicast". Clear or not: RFC5213 does not discuss multicast and seems to leave room for open questions. > (c) no new protocol mechanisms needed, but we need better operational > instructions on how set up proxy mobility in the most efficient way As we believe it is needed, we are currently working on such an operational instruction document - without modifying protocols. However, the current PMIPv6 architecture does not allow for multicast route optimization, so minimal solutions cannot follow the "most efficient way". > (d) better operational instructions and new protocol mechanisms are needed > There is plenty of room for optimization: The question, whether it's needed and desired, is more of an operational/political one. 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 jari.arkko@piuha.net Tue May 26 04:46:16 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0D528C1DD for ; Tue, 26 May 2009 04:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 hn511cVgq0QO for ; Tue, 26 May 2009 04:46:16 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 2FFFE3A6B20 for ; Tue, 26 May 2009 04:46:11 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id B11A819878C; Tue, 26 May 2009 14:47:41 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 7541619870C; Tue, 26 May 2009 14:47:41 +0300 (EEST) Message-ID: <4A1BD6DA.4030403@piuha.net> Date: Tue, 26 May 2009 14:47:38 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <991096.55707.qm@web111410.mail.gq1.yahoo.com> <4A132FAF.2040602@ericsson.com> <4A1BC7CB.7090207@piuha.net> <4A1BCD9A.9010902@informatik.haw-hamburg.de> In-Reply-To: <4A1BCD9A.9010902@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: multimob@ietf.org Subject: Re: [multimob] Gauging need for enhancing PMIPv6 multicast support 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, 26 May 2009 11:46:16 -0000 Thomas, > >> (b) no new protocol mechanisms needed, and specifications are clear >> on how to use existing ones efficiently > > Discussions on mailing lists and in meetings seem to speak a clear > language: there is quite some confusion, ranging from "PMIPv6 objects > multicast" up to "clearly it works with multicast". > > Clear or not: RFC5213 does not discuss multicast and seems to leave > room for open questions. I tend to agree with this -- if we need to have a debate, then at least some better documentation is warranted. Jari From behcetsarikaya@yahoo.com Tue May 26 09:37: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 B7A463A6CA7 for ; Tue, 26 May 2009 09:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.435, 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 RojKQyAf1Vk9 for ; Tue, 26 May 2009 09:37:32 -0700 (PDT) Received: from n9.bullet.re3.yahoo.com (n9.bullet.re3.yahoo.com [68.142.237.94]) by core3.amsl.com (Postfix) with SMTP id 765F83A693D for ; Tue, 26 May 2009 09:37:32 -0700 (PDT) Received: from [68.142.230.28] by n9.bullet.re3.yahoo.com with NNFMP; 26 May 2009 16:37:55 -0000 Received: from [67.195.9.83] by t1.bullet.re2.yahoo.com with NNFMP; 26 May 2009 16:37:55 -0000 Received: from [67.195.9.101] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 26 May 2009 16:37:55 -0000 Received: from [127.0.0.1] by omp105.mail.gq1.yahoo.com with NNFMP; 26 May 2009 16:37:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 470597.41570.bm@omp105.mail.gq1.yahoo.com Received: (qmail 78905 invoked by uid 60001); 26 May 2009 16:37:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243355875; bh=pscjRjUCww0D2U1ZFcdyWYDmVS4ZVEGMu9jSAVe0R4M=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ahlExGWCvpnxD5NhBu5G7y/qQPFlNV8sFGpGLw6p3dRy1no+kGQzUl/It2gJJAzPJDFbW6c6F6kz+JTdExEa25Np6rOeyPC3iE2eLDUZ22WRB8iuDNwYbQ1uuXzdfo4TNJxNXeBgooHdv9UPTKCZ7Ky3g2QeyziaunbAYQur7Aw= 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=u7P/5zSs4CHmjPoEkEcebG7k8lNt1nX8AudzSGBGGWfaATbhffBEaLS/sX/knXTeDb7O2eft+DKWN9rWetxjGdSPVr3wCRGr9QQaXgwu9Buf+tNXa6tlJmVUE63nCph0RKZzvYKVrvSJz7xI3QxhJtqcDigb6OxCqqWc1DESEVM=; Message-ID: <153765.78612.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: CZyKN.MVM1lZtWex5S7DD.4uiY6R4cl5YrPlgJTKKj6qRDn8nO4xynS0vHzlKH5SSDdcMwJyT6fOfRqzenK3gqdVfU4VJytlvxiGMMMm6qFUZcTey3pzGO5EYR48Gil6lyzfcT1AjZ_WepEhTvqrAIaLLJmZNp_wVrP5i0gTmIlM_hB8uLCeH.A_7FAP5mv3DeVjlBUFz7GM4uPKCo4YVZAqSB0Ua2BXlmhEgFdFcNjbskbTDREDUdX7XxyIAVevgKHxyKavqwOzMIyiShQ_ceKC1meMD2KQbQH8qGU2Zi9AgQNlp5qt5f2ATo.y8mxNNO4yGLCxrJaUkmQadUrLvXb9bm4kn6i.t6_RJCdVoQEYZLjvi19mEgtKPa2beVA_V4o- Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Tue, 26 May 2009 09:37:54 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 Date: Tue, 26 May 2009 09:37:54 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multimob] IETF-75 BoF Request 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, 26 May 2009 16:37:33 -0000 Hi all,=0A=A0 We are going for a BoF in Stockholm, you can follow it from I= ESG's BoF page:=0Ahttp://tools.ietf.org/bof/trac/wiki/WikiStart=0A=0ARegard= s,=0A=0ABehcet=0A=0A=0A From pierrick.seite@orange-ftgroup.com Thu May 28 08:20: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 3931C3A6F34 for ; Thu, 28 May 2009 08:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_50=0.001, 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 oDdYjx2Ad-pX for ; Thu, 28 May 2009 08:20:27 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 12E813A6E21 for ; Thu, 28 May 2009 08:20:26 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 17:21:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 May 2009 17:21:16 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46214F665@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <577864.445.qm@web111407.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Multimob Charter v3 Thread-Index: Acna+Oa5t6y+phAlTg6K5SjDtwe/jAErdIOg References: <577864.445.qm@web111407.mail.gq1.yahoo.com> From: To: , X-OriginalArrivalTime: 28 May 2009 15:21:17.0789 (UTC) FILETIME=[F281B8D0:01C9DFA7] Subject: Re: [multimob] Multimob Charter v3 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, 28 May 2009 15:20:28 -0000 Hi, This version does not take into account the issue raised up by Hitoshi = with regards to the item: - Update PMIPv6 to support remote subscription, fast handover and IPv4 = multicast. In a previous email, it was proposed to reword as: - Specify PMIPv6 extensions to support IPv6 multicast including remote = subscription and fast handover IMHO it sounds much better. 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: vendredi 22 mai 2009 18:18 > =C0=A0: multimob@ietf.org > Objet=A0: [multimob] Multimob Charter v3 >=20 > Folks, > =A0 I updated a little bit the charter based on Imed's comments. >=20 > Please continue to scrutinize the charter and post your comments on = the > list. >=20 > Behcet >=20 >=20 >=20