From multimob-bounces@ietf.org Wed Apr 2 12:18:40 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FE9D28C62E; Wed, 2 Apr 2008 12:18:40 -0700 (PDT) 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 D29773A6C5D for ; Wed, 2 Apr 2008 12:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.456 X-Spam-Level: X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_38=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 AKAk6p7CSPMQ for ; Wed, 2 Apr 2008 12:18:32 -0700 (PDT) Received: from web84305.mail.re1.yahoo.com (web84305.mail.re1.yahoo.com [69.147.74.184]) by core3.amsl.com (Postfix) with SMTP id E85E128C63B for ; Wed, 2 Apr 2008 12:16:04 -0700 (PDT) Received: (qmail 78124 invoked by uid 60001); 2 Apr 2008 19:16:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=SfoWCRcJSvhEmb0dBbeRxwlxsn+XaX5ALXrlEIu1b29NwKC5KU2RWy1UhU1ksCEuU+QXVgSJ9nhNOJXQZnDV8JS9M4llpQuhumoOh4otTQHeO9hlvf6wmXZGDe4DJsxKAKn9U/tiEi/VtKEFSe+R/H+luflCf96lyWuIOntprTI=; X-YMail-OSG: 8jFsVQsVM1ldNSoHj950NpKWzDVc6F89EtpD0t7u1LrmGhmpB3p1r0MtmO6gB4eDvQ-- Received: from [206.16.17.212] by web84305.mail.re1.yahoo.com via HTTP; Wed, 02 Apr 2008 12:16:05 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.162 Date: Wed, 2 Apr 2008 12:16:05 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <768366.76015.qm@web84305.mail.re1.yahoo.com> Subject: [multimob] Summary from multimob session @ IETF71 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: , Content-Type: multipart/mixed; boundary="===============0161235299==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0161235299== Content-Type: multipart/alternative; boundary="0-1315958421-1207163765=:76015" --0-1315958421-1207163765=:76015 Content-Type: text/plain; charset=us-ascii ----- Original Message ---- From: Suresh Krishnan To: multimob@ietf.org Cc: Behcet Sarikaya Sent: Thursday, March 20, 2008 6:18:41 PM Subject: [multimob] Summary from multimob session @ IETF71 Hi Folks, Here is the summary from the multimob session we had at IETF71. I was too involved in the discussions to take very good notes but I think the essence of the discussions is covered. Cheers Suresh -----Inline Attachment Follows----- Behcet presented his overview slides about draft-sarikaya-multimob-ps Marshall Eubanks mentioned that light weight MLD may or may not be standardized or implemented. We should not base multimob work on the assumption that it will be there Dave Thaler mentions his presentation about source mobility in multicast Here is the URL for this presentation: http://www.ietf.org/proceedings/01dec/slides/magma-2.pdf please read HA as HoA (Home Address). Frank Xia about draft-xia-multimob-hybrid-00 Dave points out you can already subscribe to a multicast stream without using MIPv6 and the application on the MN will choose. Dave wants to know who makes the choice about taking the direct or the home tunneled path. The stack on the MN or the Application? Frank mentions that when the application joins the multicast group on the home interface the stack can switch to the local interface. Bharat wants to know how the MN knows that the multicast service is available locally Bill Atwood talks about charging on the AR (for local streams) being different from that on the home network. He thinks that the decision for this should be in the hands of the end user Dave agrees and wants to have the costs predictable. Dave wants to define optimality (what we are trying to optimize) Bill has issues with picking paths without user involvement Christophe Janneteau wants the user involved but not necessarily the application Frank Xia about FMIP multicast draft Dave wants to quantify the advantages, since the propogation from the NAR to the common point might be pretty close. He also wants to know about the tunnel management interference between unicast and multicast tunnels. Thomas presented his slides about Proxy architectures for mobile multicast receivers (no draft) Dave wants to see a topology Frank asks about whether the PAR or NAR must be the proxy agent in case of FMIP Suresh mentions define "what"(the functionality) but not "where"(physical node) Dave wants a definition of proxy agent Bill wants to stress that the functionality is colocated but not inside. Dave thinks that the proxy definition still not clear. Suresh wondering if this proxy is an unicast/mcast proxy? Thomas thinks feeding mcast to proxy is not our(multimob's)job Dave mentions the proxy is useful only for unicast-multicast and multicast-unicast topologies but not for native multicast topologies Dave does not think protocol extensions are required and he thinks that the switching per client basis not per mc group basis Thomas wants to build a toolbox for future work --0-1315958421-1207163765=:76015 Content-Type: text/html; charset=us-ascii


----- Original Message ----
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: multimob@ietf.org
Cc: Behcet Sarikaya <bsarikaya@huawei.com>
Sent: Thursday, March 20, 2008 6:18:41 PM
Subject: [multimob] Summary from multimob session @ IETF71

Hi Folks,
  Here is the summary from the multimob session we had at IETF71. I was
too involved in the discussions to take very good notes but I think the
essence of the discussions is covered.

Cheers
Suresh


-----Inline Attachment Follows-----

Behcet presented his overview slides about draft-sarikaya-multimob-ps

Marshall Eubanks mentioned that light weight MLD may or may not be standardized or implemented. We should not base multimob work on the assumption that it will be there

Dave Thaler mentions his presentation about source mobility in multicast

Here is the URL for this presentation:
http://www.ietf.org/proceedings/01dec/slides/magma-2.pdf
please read HA as HoA (Home Address).

Frank Xia about draft-xia-multimob-hybrid-00

Dave points out you can already subscribe to a multicast stream without using MIPv6 and the application on the MN will choose.

Dave wants to know who makes the choice about taking the direct or the home tunneled path. The stack on the MN or the Application?

Frank mentions that when the application joins the multicast group on the home interface the stack can switch to the local interface.

Bharat wants to know how the MN knows that the multicast service is available locally

Bill Atwood talks about charging on the AR (for local streams) being different from that on the home network. He thinks that the decision for this should be in the hands of the end user

Dave agrees and  wants to have the costs predictable.

Dave wants to define optimality (what we are trying to optimize)

Bill has issues with picking paths without user involvement

Christophe Janneteau wants the user involved but not necessarily the application



Frank Xia about FMIP multicast draft

Dave wants to quantify the advantages, since the propogation from the NAR to the common point might be pretty close.

He also wants to know about the tunnel management interference between unicast and multicast tunnels.

Thomas presented his slides about Proxy architectures for mobile multicast receivers (no draft)

Dave wants to see a topology

Frank asks about whether the PAR or NAR must be the proxy agent in case of FMIP

Suresh mentions define "what"(the functionality) but not "where"(physical node)

Dave wants a definition of proxy agent

Bill wants to stress that the functionality is colocated but not inside.

Dave thinks that the proxy definition still not clear.

Suresh wondering if this proxy is an unicast/mcast proxy?

Thomas thinks feeding mcast to proxy is not our(multimob's)job

Dave mentions the proxy is useful only for unicast-multicast and multicast-unicast topologies but not for native multicast topologies

Dave does not think protocol extensions are required and he thinks that the switching per client basis not per mc group basis

Thomas wants to build a toolbox for future work

<END OF MEETING, OUT OF TIME>

--0-1315958421-1207163765=:76015-- --===============0161235299== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0161235299==-- From multimob-bounces@ietf.org Thu Apr 10 08:18:25 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5924D3A6D17; Thu, 10 Apr 2008 08:18:25 -0700 (PDT) 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 DCC5E3A69E2 for ; Thu, 10 Apr 2008 08:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_38=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 F3-WNDSksodu for ; Thu, 10 Apr 2008 08:18:13 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 0F51B28C503 for ; Thu, 10 Apr 2008 08:18:13 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Thu, 10 Apr 2008 17:18:31 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Apr 2008 17:18:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Apr 2008 17:18:29 +0200 Message-Id: <1B309B6DC3B05440ACC14187BCB308A403A9D0A1@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <768366.76015.qm@web84305.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Summary from multimob session @ IETF71 Thread-Index: AciU9yb7rZT1XBmwTsmGMo5pHWUqUgGJV5Fg From: "Von-Hugo, Dirk" To: , X-OriginalArrivalTime: 10 Apr 2008 15:18:30.0531 (UTC) FILETIME=[22356D30:01C89B1E] Cc: multimob@ietf.org Subject: Re: [multimob] Summary from multimob session @ IETF71 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: , Content-Type: multipart/mixed; boundary="===============0750482138==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org This is a multi-part message in MIME format. --===============0750482138== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89B1E.21B264FC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89B1E.21B264FC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear MultiMob chairs, thanks for your effort to proceed with our barBoF during last IETF-71 = which I was not able to attend. As my colleague Gerhard reported to me = and I could see from the minutes there was no time for a presentation of = my draft = http://www.ietf.org/internet-drafts/draft-von-hugo-multimob-agents-01.txt= which is going to expire this month. I had hoped that there would be = some suggestions from the audience for further improvement during that = meeting so that I could include them in the next version. Up to now = there are only minor corrections provided by my colleagues ... so if you = have any ideas (of course I have to admit that at the moment I have no = time to do a deep diving re-writing ;-( ) please feel free to comment! =20 Perhaps until next BoF I could extend the topic of multimob agents to = cover not only NEMO applicability=20 =20 Thanks for that - hope to see you in Dublin!=20 =20 Best regards=20 Dirk=20 -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Behcet Sarikaya Gesendet: Mittwoch, 2. April 2008 21:16 An: multimob@ietf.org Betreff: [multimob] Summary from multimob session @ IETF71 =20 =20 ----- Original Message ---- From: Suresh Krishnan To: multimob@ietf.org Cc: Behcet Sarikaya Sent: Thursday, March 20, 2008 6:18:41 PM Subject: [multimob] Summary from multimob session @ IETF71 Hi Folks, Here is the summary from the multimob session we had at IETF71. I was=20 too involved in the discussions to take very good notes but I think the=20 essence of the discussions is covered. Cheers Suresh -----Inline Attachment Follows----- Behcet presented his overview slides about draft-sarikaya-multimob-ps Marshall Eubanks mentioned that light weight MLD may or may not be = standardized or implemented. We should not base multimob work on the = assumption that it will be there Dave Thaler mentions his presentation about source mobility in multicast = Here is the URL for this presentation: http://www.ietf.org/proceedings/01dec/slides/magma-2.pdf please read HA as HoA (Home Address). Frank Xia about draft-xia-multimob-hybrid-00 Dave points out you can already subscribe to a multicast stream without = using MIPv6 and the application on the MN will choose. Dave wants to know who makes the choice about taking the direct or the = home tunneled path. The stack on the MN or the Application? Frank mentions that when the application joins the multicast group on = the home interface the stack can switch to the local interface. Bharat wants to know how the MN knows that the multicast service is = available locally Bill Atwood talks about charging on the AR (for local streams) being = different from that on the home network. He thinks that the decision for = this should be in the hands of the end user Dave agrees and wants to have the costs predictable. Dave wants to define optimality (what we are trying to optimize) Bill has issues with picking paths without user involvement=20 Christophe Janneteau wants the user involved but not necessarily the = application Frank Xia about FMIP multicast draft Dave wants to quantify the advantages, since the propogation from the = NAR to the common point might be pretty close. He also wants to know about the tunnel management interference between = unicast and multicast tunnels. Thomas presented his slides about Proxy architectures for mobile = multicast receivers (no draft) Dave wants to see a topology Frank asks about whether the PAR or NAR must be the proxy agent in case = of FMIP Suresh mentions define "what"(the functionality) but not = "where"(physical node) Dave wants a definition of proxy agent Bill wants to stress that the functionality is colocated but not inside. Dave thinks that the proxy definition still not clear. Suresh wondering if this proxy is an unicast/mcast proxy?=20 Thomas thinks feeding mcast to proxy is not our(multimob's)job=20 Dave mentions the proxy is useful only for unicast-multicast and = multicast-unicast topologies but not for native multicast topologies Dave does not think protocol extensions are required and he thinks that = the switching per client basis not per mc group basis Thomas wants to build a toolbox for future work =20 ------_=_NextPart_001_01C89B1E.21B264FC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear MultiMob = chairs,

thanks for your = effort to proceed with our barBoF during last IETF-71 which I was not able to = attend. As my colleague Gerhard reported to me and I could see from the minutes = there was no time for a presentation of my draft http://www.ietf.org/internet-drafts/draft-von-hugo-multimob-age= nts-01.txt which is going to expire this month. I had hoped that there would be = some suggestions from the audience for further improvement during that meeting so that I = could include them in the next version. Up to now there are only minor = corrections provided by my colleagues … so if you have any ideas (of course I have to = admit that at the moment I have no time to do a deep diving re-writing ;-( ) please = feel free to comment!

 

Perhaps until = next BoF I could extend the topic of multimob agents to cover not only NEMO = applicability

 

Thanks for that = – hope to see you in Dublin!

 

Best regards =

Dirk =

-----Urspr=FCngliche = Nachricht-----
Von: = multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftrag von Behcet Sarikaya
Gesendet: Mittwoch, 2. = April 2008 21:16
An: multimob@ietf.org
Betreff: [multimob] = Summary from multimob session @ IETF71

 

 

----- Original = Message ----
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: multimob@ietf.org
Cc: Behcet Sarikaya <bsarikaya@huawei.com>
Sent: Thursday, March 20, 2008 6:18:41 PM
Subject: [multimob] Summary from multimob session @ IETF71

Hi Folks,
  Here is the summary from the multimob session we had at IETF71. I = was
too involved in the discussions to take very good notes but I think the =
essence of the discussions is covered.

Cheers
Suresh



-----Inline Attachment Follows-----

Behcet presented his overview slides about = draft-sarikaya-multimob-ps

Marshall Eubanks mentioned that light weight MLD may or may not be = standardized or implemented. We should not base multimob work on the assumption that = it will be there

Dave Thaler mentions his presentation about source mobility in multicast =

Here is the URL for this presentation:
http://www.ietf.org/proceedings/01dec/slides/magma-2.pd= f
please read HA as HoA (Home Address).

Frank Xia about draft-xia-multimob-hybrid-00

Dave points out you can already subscribe to a multicast stream without = using MIPv6 and the application on the MN will choose.

Dave wants to know who makes the choice about taking the direct or the = home tunneled path. The stack on the MN or the Application?

Frank mentions that when the application joins the multicast group on = the home interface the stack can switch to the local interface.

Bharat wants to know how the MN knows that the multicast service is = available locally

Bill Atwood talks about charging on the AR (for local streams) being = different from that on the home network. He thinks that the decision for this = should be in the hands of the end user

Dave agrees and  wants to have the costs predictable.

Dave wants to define optimality (what we are trying to optimize)

Bill has issues with picking paths without user involvement

Christophe Janneteau wants the user involved but not necessarily the application



Frank Xia about FMIP multicast draft

Dave wants to quantify the advantages, since the propogation from the = NAR to the common point might be pretty close.

He also wants to know about the tunnel management interference between = unicast and multicast tunnels.

Thomas presented his slides about Proxy architectures for mobile = multicast receivers (no draft)

Dave wants to see a topology

Frank asks about whether the PAR or NAR must be the proxy agent in case = of FMIP

Suresh mentions define "what"(the functionality) but not "where"(physical node)

Dave wants a definition of proxy agent

Bill wants to stress that the functionality is colocated but not = inside.

Dave thinks that the proxy definition still not clear.

Suresh wondering if this proxy is an unicast/mcast proxy?

Thomas thinks feeding mcast to proxy is not our(multimob's)job

Dave mentions the proxy is useful only for unicast-multicast and multicast-unicast topologies but not for native multicast topologies

Dave does not think protocol extensions are required and he thinks that = the switching per client basis not per mc group basis

Thomas wants to build a toolbox for future work

<END OF MEETING, OUT OF TIME>

 

------_=_NextPart_001_01C89B1E.21B264FC-- --===============0750482138== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0750482138==-- From multimob-bounces@ietf.org Mon Apr 14 04:05:27 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3ED3A6E75; Mon, 14 Apr 2008 04:05:26 -0700 (PDT) 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 B80893A6E65 for ; Mon, 14 Apr 2008 04:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6AVlSq7Oxu2 for ; Mon, 14 Apr 2008 04:05:23 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (unknown [IPv6:2001:200:0:8801:203:47ff:fedf:73cc]) by core3.amsl.com (Postfix) with ESMTP id 646453A6E6F for ; Mon, 14 Apr 2008 04:05:18 -0700 (PDT) Received: from localhost (wifi-139-171.sfc.wide.ad.jp [203.178.139.171]) (authenticated bits=0) by pione.sfc.wide.ad.jp (8.13.1/8.13.1) with ESMTP id m3EAnT9w002491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 19:49:56 +0900 Date: Mon, 14 Apr 2008 20:04:04 +0900 (JST) Message-Id: <20080414.200404.213470728.asaeda@sfc.wide.ad.jp> To: schmidt@informatik.haw-hamburg.de From: Hitoshi Asaeda In-Reply-To: <47EB81BB.4040801@informatik.haw-hamburg.de> References: <623942.11346.qm@web84309.mail.re1.yahoo.com> <20080327.122746.11606627.asaeda@sfc.wide.ad.jp> <47EB81BB.4040801@informatik.haw-hamburg.de> X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] Summary from multimob session @ IETF71 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi Thomas, Sorry for the late reply. > This is mechanism is a (subscription-) proxy function used at relays > already today. A multicast relay maintains a group subscription without > forwarding traffic, e.g., down a wireless link to assist a fast > forwarding in case a listener for that group arrives on the link / in > the domain. > > This mechanism is described in the section "5.2.4 MLD Extensions" of the > problem statement > http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps > > and a protocol realization in the form of an MLD extension is given in > section "4.5 Router attendance control in MLD" of the M-HMIPv6 draft > > http://tools.ietf.org/html/draft-schmidt-waehlisch-mhmipv6 I read this draft. It assumes the use of HMIP6 but this MLD extension would be in general useful with other mobile protocols. I could support this idea. I'm interested in the discussion regarding how this extension would need more improvement as the spec (e.g. how long proxy or mrouter (i.e. MAPs or HA) can keep or maintain "hold" state reported by MN). On the other hand, I'd like to hear other opinions. One may think that it is not necessary to notify MLD hold state to MAPs (or HA in MIP6) as the fast handover would be much faster than the time of membership expiration maintained by MLD. I don't know if this thought is fairly reasonable or not. If we agree to include this extension, I'm happy to discuss the future direction and how we can cooperate in both of our future drafts. Thank you for your input. Regards, -- Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Mon Apr 14 15:32:50 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07D3D3A6EF8; Mon, 14 Apr 2008 15:32:50 -0700 (PDT) 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 4272928C0FF for ; Mon, 14 Apr 2008 15:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.398, 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 eKC4pPFaxaKB for ; Mon, 14 Apr 2008 15:32:47 -0700 (PDT) Received: from web84315.mail.re1.yahoo.com (web84315.mail.re1.yahoo.com [69.147.74.194]) by core3.amsl.com (Postfix) with SMTP id 379993A6870 for ; Mon, 14 Apr 2008 15:32:47 -0700 (PDT) Received: (qmail 54377 invoked by uid 60001); 14 Apr 2008 22:33:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=j+RPieQvCj23bM9ppLmU5iW+SHCL60Pn7M/Y8WFUIKriuJ+6UVXwUupNmOlO4/iBtNv53csH4SUrDYKpptBE+Gys9Omw0Xl3mIeJYLW+1n5bq26jhUjm/vFZBHZZwRO818HfCFtr3sF2LMogVe8BBZWMHH9Gzxvk3Om6aT+Nhq4=; X-YMail-OSG: nQUDsC0VM1kzmn.K._przR3x54VOEEXqL1mtW2hoTi68lNv0nKs33Abo8jVrSEqQ0I9Vj.zcnW1DON2WZNyHUwJe.rdeyJzPfSU32sfSOFqCggxD6f9T5djE2naMg00i3_qCQQG.yFau_mw- Received: from [206.16.17.212] by web84315.mail.re1.yahoo.com via HTTP; Mon, 14 Apr 2008 15:33:13 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.162 Date: Mon, 14 Apr 2008 15:33:13 -0700 (PDT) From: Behcet Sarikaya To: Hui Deng MIME-Version: 1.0 Message-ID: <280807.52401.qm@web84315.mail.re1.yahoo.com> Cc: multimob@ietf.org Subject: Re: [multimob] MC Notification 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: , Content-Type: multipart/mixed; boundary="===============0099010019==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0099010019== Content-Type: multipart/alternative; boundary="0-1778573114-1208212393=:52401" --0-1778573114-1208212393=:52401 Content-Type: text/plain; charset=us-ascii Hello Hui, In your draft draft-yang-multimob-mip6-mc-tunnel-opt-01 you did not define the multicast notification message and its operation. What are your plans on this? Regards, Behcet ----- Original Message ---- From: Hui Deng To: Jari Arkko Cc: multimob@ietf.org Sent: Tuesday, February 26, 2008 5:48:39 PM Subject: Re: [multimob] moving forward? thanks Jari's arrangement, we also updated the draft below: http://www.ietf.org/internet-drafts/draft-yang-multimob-mip6-mc-tunnel-opt-01.txt http://www.ietf.org/internet-drafts/draft-deng-multimob-ps-mobilemulticast-01.txt Many thanks -Hui --0-1778573114-1208212393=:52401 Content-Type: text/html; charset=us-ascii
Hello Hui,
  In your draft draft-yang-multimob-mip6-mc-tunnel-opt-01
you did not define the multicast notification message and its operation. What are your plans on this?

Regards,

Behcet

----- Original Message ----
From: Hui Deng <denghui02@gmail.com>
To: Jari Arkko <jari.arkko@piuha.net>
Cc: multimob@ietf.org
Sent: Tuesday, February 26, 2008 5:48:39 PM
Subject: Re: [multimob] moving forward?

thanks Jari's arrangement,
we also updated the draft below:
http://www.ietf.org/internet-drafts/draft-yang-multimob-mip6-mc-tunnel-opt-01.txt
http://www.ietf.org/internet-drafts/draft-deng-multimob-ps-mobilemulticast-01.txt

Many thanks

-Hui

--0-1778573114-1208212393=:52401-- --===============0099010019== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0099010019==-- From multimob-bounces@ietf.org Mon Apr 14 19:47:04 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4533A6BA5; Mon, 14 Apr 2008 19:47:04 -0700 (PDT) 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 207B93A6BA5 for ; Mon, 14 Apr 2008 19:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.292 X-Spam-Level: * X-Spam-Status: No, score=1.292 tagged_above=-999 required=5 tests=[AWL=-1.442, BAYES_05=-1.11, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATICB=1.372, HOST_MISMATCH_COM=0.311, 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 yo2ZMzKApwPT for ; Mon, 14 Apr 2008 19:47:02 -0700 (PDT) Received: from hitachihk8.hitachi.cn (static-ip-174-194-65-202.rev.dyxnet.com [202.65.194.174]) by core3.amsl.com (Postfix) with ESMTP id D7FAC3A6AF6 for ; Mon, 14 Apr 2008 19:47:00 -0700 (PDT) Received: (qmail 17599 invoked from network); 15 Apr 2008 02:47:32 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk8;26ff5569be3d0f66549336612adfbf6d; Received: from unknown (HELO hitachihk7.hitachi.cn) (170.95.94.4) by 170.95.94.11 with SMTP; 15 Apr 2008 02:47:31 -0000 Received: (qmail 30432 invoked from network); 15 Apr 2008 02:47:30 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk7;5f17a8617407b01b3cdc17504a8cdc9f; Received: from hchidc401.hitachi-china.com (170.95.94.69) by 172.16.10.10 with SMTP; 15 Apr 2008 02:47:30 -0000 Received: from hchibjrdpyang ([10.96.2.35]) by hchidc401.hitachi-china.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 10:47:29 +0800 From: "Peng Yang" To: "'Behcet Sarikaya'" , "'Hui Deng'" Date: Tue, 15 Apr 2008 10:47:33 +0800 Message-ID: <00bc01c89ea3$0f5d26c0$2302600a@hitachichina.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <280807.52401.qm@web84315.mail.re1.yahoo.com> Importance: Normal X-OriginalArrivalTime: 15 Apr 2008 02:47:29.0822 (UTC) FILETIME=[0BFFA3E0:01C89EA3] X-Scanned-By-hitachihk7: Virus scan performed by network-box X-Scanned-By-hitachihk7: Scanner file id is hitachihk7-1208227650.723-30427-000 X-Scanned-By-hitachihk7: No known viruses found in message (received+scanned in 0.02/0.03 secs) X-Scanned-By-hitachihk7: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk8: Virus scan performed by network-box X-Scanned-By-hitachihk8: Scanner file id is hitachihk8-1208227651.227-17583-000 X-Scanned-By-hitachihk8: No known viruses found in message (received+scanned in 0.04/0.20 secs) X-Scanned-By-hitachihk8: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk8: Whitelisted with valid signature (outbound via Network Box hitachihk7) Cc: multimob@ietf.org Subject: Re: [multimob] MC Notification 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org SGksIEJlaGNldDogCgpUaGFua3MgZm9yIHlvdXIgY29tbWVudC4KCldlIGhhdmUgdGhvdWdodCBh IGxvdCBhYm91dCB0aGlzIG5vdGlmaWNhdGlvbiBtZXNzYWdlLiBCYXNpY2FsbHksIHdlIHdhbnQg dG8gcmUtdXNlIHRoZSBnZW5lcmljIG5vdGlmaWNhdGlvbiBtZXNzYWdlIGluIGRyYWZ0IGJlbG93 77yaCi0gZHJhZnQtaWV0Zi1taXA2LWdlbmVyaWMtbm90aWZpY2F0aW9uLW1lc3NhZ2UtMDAKCkFu ZCwgSSBkbyB0aGluayBzb21lIGV4dGVuc2lvbnMgYXJlIG5lZWRlZCB0byBkbyB0aGUgbm90aWZp Y2F0aW9uIGluIG91ciBzb2x1dGlvbi4gSW4gdGhlIG5leHQgdXBkYXRlIG9mIG91ciBkcmFmdCwg d2Ugd2lsbCBtYWtlIGl0IG9uIHRoaXMgcGFydC4gCgpUaGFua3MgYSBsb3QKQlJHClBlbnkuIFlh bmcKCgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9tOiBtdWx0aW1vYi1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86bXVsdGltb2ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJl aGNldCBTYXJpa2F5YQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxNSwgMjAwOCA2OjMzIEFNClRvOiBI dWkgRGVuZwpDYzogbXVsdGltb2JAaWV0Zi5vcmcKU3ViamVjdDogUmU6IFttdWx0aW1vYl0gTUMg Tm90aWZpY2F0aW9uCgpIZWxsbyBIdWksCiAgSW4geW91ciBkcmFmdCBkcmFmdC15YW5nLW11bHRp bW9iLW1pcDYtbWMtdHVubmVsLW9wdC0wMQp5b3UgZGlkIG5vdCBkZWZpbmUgdGhlIG11bHRpY2Fz dCBub3RpZmljYXRpb24gbWVzc2FnZSBhbmQgaXRzIG9wZXJhdGlvbi4gV2hhdCBhcmUgeW91ciBw bGFucyBvbiB0aGlzPwoKUmVnYXJkcywKCkJlaGNldAotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0KRnJvbTogSHVpIERlbmcgPGRlbmdodWkwMkBnbWFpbC5jb20+ClRvOiBKYXJpIEFya2tvIDxq YXJpLmFya2tvQHBpdWhhLm5ldD4KQ2M6IG11bHRpbW9iQGlldGYub3JnClNlbnQ6IFR1ZXNkYXks IEZlYnJ1YXJ5IDI2LCAyMDA4IDU6NDg6MzkgUE0KU3ViamVjdDogUmU6IFttdWx0aW1vYl0gbW92 aW5nIGZvcndhcmQ/Cgp0aGFua3MgSmFyaSdzIGFycmFuZ2VtZW50LAp3ZSBhbHNvIHVwZGF0ZWQg dGhlIGRyYWZ0IGJlbG93OgpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC15YW5nLW11bHRpbW9iLW1pcDYtbWMtdHVubmVsLW9wdC0wMS50eHQKaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZGVuZy1tdWx0aW1vYi1wcy1tb2JpbGVtdWx0aWNh c3QtMDEudHh0CgpNYW55IHRoYW5rcwoKLUh1aQoKCkRpc2NsYWltZXI6ClRoZSBjb250ZW50cyBv ZiB0aGlzIGUtbWFpbCwgYW5kIGl0cyBhdHRhY2htZW50cywgaWYgYW55LCBhcmUgY29uZmlkZW50 aWFsIGFuZCBtYXkgYmUgcHJvdGVjdGVkCmJ5IGxhdyBhZ2FpbnN0IGFueSB1bmF1dGhvcml6ZWQg dXNlLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlLW1haWwgYnkgbWlzdGFrZSBvciBoYXZl CnJlYXNvbiB0byBiZWxpZXZlIHRoYXQgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJlcGx5CmUtbWFpbCBhcyBzb29uIGFzIHBv c3NpYmxlIGFuZCBkZWxldGUgaXQgZnJvbSB5b3VyIGNvbXB1dGVyIHN5c3RlbSBpbW1lZGlhdGVs eSB0aGVyZWFmdGVyLgpJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ug bXVzdCBub3QgY29weSB0aGlzIGUtbWFpbCBvciBhdHRhY2htZW50IG9yIGRpc2Nsb3NlCnRoZSBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLiAgV2hpbGUgd2UgaGF2ZSBtYWRlIGV2ZXJ5IGVm Zm9ydCB0byBrZWVwIG91ciBuZXR3b3JrIHZpcnVzIGZyZWUsCndlIHRha2Ugbm8gcmVzcG9uc2li aWxpdHkgZm9yIGFueSBjb21wdXRlciB2aXJ1cyB3aGljaCBtaWdodCBiZSB0cmFuc2ZlcnJlZCBi eSB3YXkgb2YgdGhpcyBlLW1haWwuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCm11bHRpbW9iIG1haWxpbmcgbGlzdAptdWx0aW1vYkBpZXRmLm9yZwpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211bHRpbW9iCg== From multimob-bounces@ietf.org Tue Apr 15 15:17:14 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F57828C286; Tue, 15 Apr 2008 15:17:14 -0700 (PDT) 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 259123A6854 for ; Tue, 15 Apr 2008 15:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.345, 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 mDGK22Loa55C for ; Tue, 15 Apr 2008 15:17:12 -0700 (PDT) Received: from web84304.mail.re1.yahoo.com (web84304.mail.re1.yahoo.com [69.147.74.183]) by core3.amsl.com (Postfix) with SMTP id 276163A69D5 for ; Tue, 15 Apr 2008 15:17:12 -0700 (PDT) Received: (qmail 23680 invoked by uid 60001); 15 Apr 2008 22:17:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=ZePunRDcfkB9O9bimpGfubgxSXn2dl4sMpV3qpheb++skVZ7doXENJLY+fEGVnblf541WNGYLaOyDYH+1WUu+wxIZ0ZHlpkUP49KKLzTV34gGB46wlmeH2/bnRIJkY3wlTPBVSo8XE8D1t301VeSp6BYRSZdvKqu9BY5jRb81Xo=; X-YMail-OSG: ALsJqtUVM1kEhHAjQmoem7iuHlj0MHzS1HFHg0eUadKlbYjCcroTLTUF8hsa1YIDZgZLLZhvXoQz.TCv3EoSALotmuTCdlw- Received: from [206.16.17.212] by web84304.mail.re1.yahoo.com via HTTP; Tue, 15 Apr 2008 15:17:45 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.162 Date: Tue, 15 Apr 2008 15:17:45 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <857449.19322.qm@web84304.mail.re1.yahoo.com> Subject: [multimob] MC Notification 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: , Content-Type: multipart/mixed; boundary="===============1195521675==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============1195521675== Content-Type: multipart/alternative; boundary="0-1074717815-1208297865=:19322" --0-1074717815-1208297865=:19322 Content-Type: text/plain; charset=us-ascii Hi Peng, Another question: you mentioned in Section 2 yourprotocol provides optimized MIPv6 multicast, do you have anyjustification why is it optimized? Dave Thaler asked similarquestions during Multimob session in IETF-71. If you have done anyanalysis, please share with us the results. Regards, Behcet -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Tuesday, April 15, 2008 6:33 AM To: Hui Deng Cc: multimob@ietf.org Subject: Re: [multimob] MC Notification Hello Hui, In your draft draft-yang-multimob-mip6-mc-tunnel-opt-01 you did not define the multicast notification message and its operation. What are your plans on this? Regards, Behcet --0-1074717815-1208297865=:19322 Content-Type: text/html; charset=us-ascii
Hi Peng,
  Another question: you mentioned in Section 2 your protocol provides optimized MIPv6 multicast, do you have any justification why is it optimized?
  Dave Thaler asked similar questions during Multimob session in IETF-71. If you have done any analysis, please share with us the results.

Regards,

Behcet


-----Original Message-----
From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Tuesday, April 15, 2008 6:33 AM
To: Hui Deng
Cc: multimob@ietf.org
Subject: Re: [multimob] MC Notification

Hello Hui,
  In your draft draft-yang-multimob-mip6-mc-tunnel-opt-01
you did not define the multicast notification message and its operation. What are your plans on this?

Regards,

Behcet
--0-1074717815-1208297865=:19322-- --===============1195521675== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============1195521675==-- From multimob-bounces@ietf.org Thu Apr 24 09:56:52 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16AFD3A6B06; Thu, 24 Apr 2008 09:56:52 -0700 (PDT) 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 DB0D63A6B0F for ; Thu, 24 Apr 2008 09:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.681 X-Spam-Level: X-Spam-Status: No, score=-1.681 tagged_above=-999 required=5 tests=[AWL=0.583, 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 n8M31-eO20lz for ; Thu, 24 Apr 2008 09:56:50 -0700 (PDT) Received: from web84308.mail.re1.yahoo.com (web84308.mail.re1.yahoo.com [69.147.74.187]) by core3.amsl.com (Postfix) with SMTP id DF2A73A69C7 for ; Thu, 24 Apr 2008 09:56:49 -0700 (PDT) Received: (qmail 42109 invoked by uid 60001); 24 Apr 2008 16:56:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=0fwK1/7ShOefthP21OcwlZY6rDqp6NYIawmBSlWV2GuST0iWMFqrndr94eZnwAOqQ0PjpLDOqW3DzsEigRcUqpFGsHmKyME+LEaxjUs/sM9FW7kzYqEA4zEAOjVJU9IKflg0kFT27cmD4ZYKrLC2x7Kq1GTuLefBlO7Lrgs6Evw=; X-YMail-OSG: uHTGXH4VM1ml_EZUuaCKbpj8NMtxUHdy1Jp88gqwp.X3uYL9jEnMp3fEqC21EiDJjBQ192VN6rAlxawlgBABEe4GfVTECcaIrD1jRg-- Received: from [206.16.17.212] by web84308.mail.re1.yahoo.com via HTTP; Thu, 24 Apr 2008 09:56:54 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Thu, 24 Apr 2008 09:56:54 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <638468.42044.qm@web84308.mail.re1.yahoo.com> Subject: [multimob] Solution drafts 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: , Content-Type: multipart/mixed; boundary="===============1124913297==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============1124913297== Content-Type: multipart/alternative; boundary="0-1994470425-1209056214=:42044" --0-1994470425-1209056214=:42044 Content-Type: text/plain; charset=us-ascii Hi Folks, We have a few solution drafts. We need these drafts revised based on the feedback received. New drafts related to IGMP/MLD and mobility protocols (v4/v6) are also solicited. If your draft is based on optimizations over the state-of-the-art techniques such as bi-directional tunneling please perform an analysis possibly using simulation to show that your draft is really optimizing things. You may wish to state the analysis results, the amount of savings, etc. as an annex (Appendix B of RFC 4067 is an example). Other avenues are also possible such as a separate draft, posting it on Multimob mailing list and including it in the presentation. Regards, Suresh & Behcet --0-1994470425-1209056214=:42044 Content-Type: text/html; charset=us-ascii
Hi Folks,
  We have a few solution drafts. We need these drafts revised based on the feedback received.
  New drafts related to IGMP/MLD and mobility protocols (v4/v6) are also solicited.
  If your draft is based on optimizations over the state-of-the-art techniques such as bi-directional tunneling please perform an analysis possibly using simulation to show  that your draft is really optimizing things.  You may wish to state the analysis results, the amount of savings, etc. as an annex (Appendix B of RFC 4067 is an example). Other avenues are also possible such as a separate draft, posting it on Multimob mailing list and including it in the presentation.
 Regards,

Suresh & Behcet
--0-1994470425-1209056214=:42044-- --===============1124913297== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============1124913297==-- From multimob-bounces@ietf.org Mon Apr 28 01:12:02 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1EAF3A6ACC; Mon, 28 Apr 2008 01:12:02 -0700 (PDT) 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 97D333A6A35 for ; Mon, 28 Apr 2008 01:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-PYqDFOmXLM for ; Mon, 28 Apr 2008 01:12:00 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 49ED13A68B9 for ; Mon, 28 Apr 2008 01:11:59 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP for multimob@ietf.org; Mon, 28 Apr 2008 10:12:00 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Apr 2008 10:11:59 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 28 Apr 2008 10:11:58 +0200 Message-Id: <1B309B6DC3B05440ACC14187BCB308A403A9D0E7@S4DE8PSAAGM.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-von-hugo-multimob-agents-02 Thread-Index: Acim5cdvUuOd8KJCQ9KwT29BTOawFQCIUdrg From: "Von-Hugo, Dirk" To: X-OriginalArrivalTime: 28 Apr 2008 08:11:59.0997 (UTC) FILETIME=[887F52D0:01C8A907] Subject: [multimob] WG: New Version Notification for draft-von-hugo-multimob-agents-02 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Dear all, This is to announce that a new (but only slightly) updated version of draft-von-hugo-multimob-agents-02 is available at http://www.ietf.org/internet-drafts/draft-von-hugo-multimob-agents-02.tx t and any comments are very welcome. Best regards Dirk Filename: draft-von-hugo-multimob-agents Revision: 02 Title: Agent-based multicast support for moving networks (NEMO) Creation_date: 2008-04-25 WG ID: Independent Submission Number_of_pages: 11 Abstract: This document describes an approach to support multicast listeners and senders located within a moving IPv6 network (NEMO). A NEMO is built up by at least one Mobile Router (MR) and a set of Mobile Network Nodes (MNNs). The MR handles all routing related tasks to provide connectivity between the MNNs and an access network including mobility management. Correspondingly the MR also subscribes to multicast groups and forwards emerging multicast traffic on behalf of a MNN. For optimised routing of multicast data a hierarchical multicast agent is introduced as a logical entity providing an anchor to the multicast tree. In the MR a corresponding functionality is defined which decides on the location of the specific agent to be used for a distinct multicast traffic. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. The IETF Secretariat. _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob