From multimob-bounces@ietf.org Thu Dec 4 01:58:21 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 617593A68C1; Thu, 4 Dec 2008 01:58:21 -0800 (PST) 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 EE4763A68C1 for ; Thu, 4 Dec 2008 01:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_44=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 T7pyxhEERqCt for ; Thu, 4 Dec 2008 01:58:20 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id B1FA43A6885 for ; Thu, 4 Dec 2008 01:58:19 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Thu, 4 Dec 2008 10:58:14 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Dec 2008 10:58:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Dec 2008 10:58:12 +0100 Message-Id: <643B0A1D1A13AB498304E0BBC8027848564E4B@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <005101c95394$6a2a44b0$a864a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Comments ondraft-deng-multimob-pmip6-requirement-01.txt Thread-Index: AclPJqTbR7KAkKtdQ8qpXQW+VVG6ewEbGtbgAJfwVkA= References: <167758.33851.qm@web111413.mail.gq1.yahoo.com> <005101c95394$6a2a44b0$a864a8c0@china.huawei.com> From: "von Hugo, Dirk" To: , , , X-OriginalArrivalTime: 04 Dec 2008 09:58:14.0114 (UTC) FILETIME=[D2A56420:01C955F6] Subject: Re: [multimob] Comments ondraft-deng-multimob-pmip6-requirement-01.txt 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="===============1899323703==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org This is a multi-part message in MIME format. --===============1899323703== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C955F6.D259C983" This is a multi-part message in MIME format. ------_=_NextPart_001_01C955F6.D259C983 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, from my point of view the requirements deal with minimization of bandwidth consumption in terms of signalling effort and path lengths (reduce amount of hops, overcome traffic replication for every individual receiver), which is currently reflected in the draft as =20 R11 - Multicast mobility SHOULD minimize transport costs on the forwarding link, as well as any additional overhead on the multicast delivery path =20 Surely this could be elaborated towards efficient resource usage e.g. in terms of differentiating traffic for different service requirements (QoS). =20 Best regards Dirk _____ =20 Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftrag von John.zhao Gesendet: Montag, 1. Dezember 2008 10:09 An: 'Behcet Sarikaya'; multimob@ietf.org; 'Suresh Krishnan' Betreff: Re: [multimob] Comments ondraft-deng-multimob-pmip6-requirement-01.txt Hi,Behcet and all =20 My two cents. As my understanding,we need optimize the traffics between MAG and LMA and also include the tunnel between old MAG and new MAG.=20 =20 Best Rgds Thanks, john.zhao =20 Hello all, At Multimob BoF last week it became clear that PMIPv6 requirements draft concentrated (probably) too much on the operating requirements and failed to state some simple traffic requirements. I remember these traffic requirements were already stated in the pre BoF meeting we had in Dublin. Any comments? Suresh? Regards, Behcet ------_=_NextPart_001_01C955F6.D259C983 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all,
from my point of view the requirements deal = with minimization of bandwidth=20 consumption in terms of signalling effort and path lengths (reduce = amount of=20 hops, overcome traffic replication for every individual receiver), which = is=20 currently reflected in the draft as  
R11 - Multicast mobility SHOULD = minimize=20 transport costs on the forwarding link, as well as any additional = overhead on=20 the multicast delivery=20 path
 
Surely=20 this could be elaborated towards efficient resource usage e.g. in terms = of=20 differentiating traffic for different service requirements=20 (QoS).
 
Best=20 regards
Dirk

Von: multimob-bounces@ietf.org=20 [mailto:multimob-bounces@ietf.org] Im Auftrag von=20 John.zhao
Gesendet: Montag, 1. Dezember 2008 = 10:09
An:=20 'Behcet Sarikaya'; multimob@ietf.org; 'Suresh = Krishnan'
Betreff: Re:=20 [multimob] Comments=20 ondraft-deng-multimob-pmip6-requirement-01.txt

Hi,Behcet=20 and all
 
    My two cents.
     As my understanding,we need = optimize the=20 traffics between MAG and LMA and also include the tunnel between old MAG = and new=20 MAG.
 
    Best Rgds
Thanks,

john.zhao

 
Hello all,
  At Multimob BoF last week it became clear = that=20 PMIPv6 requirements draft concentrated (probably) too much on the = operating=20 requirements and failed to state some simple traffic = requirements.
  I=20 remember these traffic requirements were already stated in the pre BoF = meeting=20 we had in Dublin.
  Any comments?=20 Suresh?

Regards,

Behcet


------_=_NextPart_001_01C955F6.D259C983-- --===============1899323703== 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 --===============1899323703==-- From multimob-bounces@ietf.org Fri Dec 5 15:09:54 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ECAA3A6836; Fri, 5 Dec 2008 15:09:54 -0800 (PST) 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 4F1DB3A6836 for ; Fri, 5 Dec 2008 15:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 euFcElso4KNL for ; Fri, 5 Dec 2008 15:09:52 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 879353A6403 for ; Fri, 5 Dec 2008 15:09:52 -0800 (PST) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id mB5NCk7W001248; Fri, 5 Dec 2008 17:12:48 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Dec 2008 17:08:23 -0600 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Dec 2008 17:08:23 -0600 Message-ID: <4939B460.3010908@ericsson.com> Date: Fri, 05 Dec 2008 18:08:16 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Behcet Sarikaya References: <49130E13.8040805@informatik.haw-hamburg.de> <20081107.005253.179720275.asaeda@sfc.wide.ad.jp> <49131786.2030100@informatik.haw-hamburg.de> <20081107.013921.242149102.asaeda@sfc.wide.ad.jp> <49132333.3020403@informatik.haw-hamburg.de> <1d38a3350811090759n146c643jb709781328bd4c33@mail.gmail.com> <167758.33851.qm@web111413.mail.gq1.yahoo.com> In-Reply-To: <167758.33851.qm@web111413.mail.gq1.yahoo.com> X-OriginalArrivalTime: 05 Dec 2008 23:08:23.0498 (UTC) FILETIME=[5F410AA0:01C9572E] Cc: multimob@ietf.org Subject: Re: [multimob] Comments on draft-deng-multimob-pmip6-requirement-01.txt 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi all, From many of the comments raised at the BOF, my main observation is that there was insufficient description of the intended deployment model(s) for multicast with PMIP. I think we need to put this down on paper before we start listing the problems out. Without a common understanding of the scenario it will be hard to agree on the problems. Cheers Suresh Behcet Sarikaya wrote: > Hello all, > At Multimob BoF last week it became clear that PMIPv6 requirements > draft concentrated (probably) too much on the operating requirements and > failed to state some simple traffic requirements. > I remember these traffic requirements were already stated in the pre > BoF meeting we had in Dublin. > Any comments? Suresh? > > Regards, > > Behcet > > _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Mon Dec 8 09:12:36 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 658943A6A78; Mon, 8 Dec 2008 09:12:36 -0800 (PST) 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 6F98A3A6A78 for ; Mon, 8 Dec 2008 09:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loaEZklIWgrq for ; Mon, 8 Dec 2008 09:12:34 -0800 (PST) Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by core3.amsl.com (Postfix) with ESMTP id 19CCF3A688C for ; Mon, 8 Dec 2008 09:12:34 -0800 (PST) Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.5]) by mailer.gwdg.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L9jeg-0007LH-8P; Mon, 08 Dec 2008 18:12:22 +0100 Message-ID: <493D5577.5050300@cs.uni-goettingen.de> Date: Mon, 08 Dec 2008 18:12:23 +0100 From: Niklas Neumann Organization: University of Goettingen User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Behcet Sarikaya References: <49130E13.8040805@informatik.haw-hamburg.de> <20081107.005253.179720275.asaeda@sfc.wide.ad.jp> <49131786.2030100@informatik.haw-hamburg.de> <20081107.013921.242149102.asaeda@sfc.wide.ad.jp> <49132333.3020403@informatik.haw-hamburg.de> <1d38a3350811090759n146c643jb709781328bd4c33@mail.gmail.com> <167758.33851.qm@web111413.mail.gq1.yahoo.com> In-Reply-To: <167758.33851.qm@web111413.mail.gq1.yahoo.com> X-Virus-Scanned: (clean) by exiscan+sophie Cc: multimob@ietf.org Subject: Re: [multimob] Comments on draft-deng-multimob-pmip6-requirement-01.txt 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hy everybody, are we satisfied with the charter proposal and the problem statement? It was my impression that a lot of people didn't agree with some of the assumptions made there. For example, LMA vs. MAG as multicast endpoints. So maybe we should revise those documents and be a little more conservative about the assumptions and statements made there. Something along the lines of examining current multicast behavior in PMIP with the goal of working on a best-practice guide or optimizations where needed. At least the discussion during the BOF showed, that the specifications are not clear about multicast in PMIP and clarifications are needed. Best regards Niklas Behcet Sarikaya wrote: > Hello all, > At Multimob BoF last week it became clear that PMIPv6 requirements > draft concentrated (probably) too much on the operating requirements and > failed to state some simple traffic requirements. > I remember these traffic requirements were already stated in the pre > BoF meeting we had in Dublin. > Any comments? Suresh? > > Regards, > > Behcet > > > > ------------------------------------------------------------------------ > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Niklas Neumann - University of Goettingen, Institute of Computer Science http://user.informatik.uni-goettingen.de/~nneuman1/ Tel: +49 551 39-172053 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Mon Dec 8 12:08:06 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BADE28C18B; Mon, 8 Dec 2008 12:08:06 -0800 (PST) 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 13CF228C18F for ; Mon, 8 Dec 2008 12:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUchx1ZmzP7j for ; Mon, 8 Dec 2008 12:08:04 -0800 (PST) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id 16D9C28C18B for ; Mon, 8 Dec 2008 12:08:03 -0800 (PST) Received: from ([128.244.206.11]) by pilot.jhuapl.edu with ESMTP with TLS id 5502123.127796056; Mon, 08 Dec 2008 15:07:44 -0500 Message-ID: <493D7E90.5010307@innovationslab.net> Date: Mon, 08 Dec 2008 15:07:44 -0500 From: Brian Haberman User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Niklas Neumann References: <49130E13.8040805@informatik.haw-hamburg.de> <20081107.005253.179720275.asaeda@sfc.wide.ad.jp> <49131786.2030100@informatik.haw-hamburg.de> <20081107.013921.242149102.asaeda@sfc.wide.ad.jp> <49132333.3020403@informatik.haw-hamburg.de> <1d38a3350811090759n146c643jb709781328bd4c33@mail.gmail.com> <167758.33851.qm@web111413.mail.gq1.yahoo.com> <493D5577.5050300@cs.uni-goettingen.de> In-Reply-To: <493D5577.5050300@cs.uni-goettingen.de> Cc: multimob@ietf.org Subject: Re: [multimob] Comments on draft-deng-multimob-pmip6-requirement-01.txt 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Niklas, I have two take aways from the BoF held in Minneapolis. I will start two separate threads on the mailing list to discuss them, but at the high level they are: 1. Rather than focus on optimizations (i.e., LMA to MAG), focus on the basics needed to deploy multicast in the current PMIPv6 architecture. 2. Identify whether there is interest in investigating the performance of IGMP/MLD over wireless networks. Regards, Brian Niklas Neumann wrote: > Hy everybody, > > are we satisfied with the charter proposal and the problem statement? It > was my impression that a lot of people didn't agree with some of the > assumptions made there. For example, LMA vs. MAG as multicast endpoints. > > So maybe we should revise those documents and be a little more > conservative about the assumptions and statements made there. Something > along the lines of examining current multicast behavior in PMIP with the > goal of working on a best-practice guide or optimizations where needed. > > At least the discussion during the BOF showed, that the specifications > are not clear about multicast in PMIP and clarifications are needed. > > Best regards > Niklas > > > Behcet Sarikaya wrote: >> Hello all, >> At Multimob BoF last week it became clear that PMIPv6 requirements >> draft concentrated (probably) too much on the operating requirements >> and failed to state some simple traffic requirements. >> I remember these traffic requirements were already stated in the pre >> BoF meeting we had in Dublin. >> Any comments? Suresh? >> >> Regards, >> >> Behcet _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Mon Dec 8 12:08:15 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D268D28C197; Mon, 8 Dec 2008 12:08:15 -0800 (PST) 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 1D24F28C197 for ; Mon, 8 Dec 2008 12:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ccZRJVp0MLJ for ; Mon, 8 Dec 2008 12:08:14 -0800 (PST) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id 2390928C174 for ; Mon, 8 Dec 2008 12:08:14 -0800 (PST) Received: from ([128.244.206.11]) by pilot.jhuapl.edu with ESMTP with TLS id 5502123.127796082; Mon, 08 Dec 2008 15:07:55 -0500 Message-ID: <493D7E9B.4060303@innovationslab.net> Date: Mon, 08 Dec 2008 15:07:55 -0500 From: Brian Haberman User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: multimob@ietf.org Subject: [multimob] Group management protocol operation over wireless links 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org All, As I mentioned in an earlier message, one of the takeaways from the BoF involved investigating optimizing IGMP/MLD for wireless links. One of the issues with this item is the vast array of underlying wireless technologies. The initial task would have to focus on identifying those link types (or at least their shared characteristics) and what issues arise from the current IGMP/MLD operational model operating over those links. Ways forward could range from a BCP describing feasible timer/parameter settings for various link types up to proposed protocol changes to IGMP/MLD for operation over those link types. One issue with this is the perceived reluctance on the part of primary multicast routing vendors to change their implementations (based on Marshall's comments at the BoF). Thoughts? Comments? Regards, Brian _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Mon Dec 8 12:08:18 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB82328C1AA; Mon, 8 Dec 2008 12:08:17 -0800 (PST) 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 AB33D28C174 for ; Mon, 8 Dec 2008 12:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jq1pmqNFakfq for ; Mon, 8 Dec 2008 12:08:14 -0800 (PST) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id 9C95628C195 for ; Mon, 8 Dec 2008 12:08:14 -0800 (PST) Received: from ([128.244.206.11]) by pilot.jhuapl.edu with ESMTP with TLS id 5502123.127796071; Mon, 08 Dec 2008 15:07:51 -0500 Message-ID: <493D7E97.5060400@innovationslab.net> Date: Mon, 08 Dec 2008 15:07:51 -0500 From: Brian Haberman User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: multimob@ietf.org Subject: [multimob] Multicast deployment in PMIPv6 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org All, As I mentioned in an earlier message, one of the takeaways from the BoF is that there is some confusion of how multicast can be deployed in the current PMIPv6 architecture. Some people argued that multicast in PMIPv6 already exists using the base MIPv6 protocol. Others argued that either the MIPv6 multicast extensions can't be used or that they were insufficient. From those arguments, I would see a work item being the investigation of what the baseline deployment of multicast in PMIPv6 would look like. This would preclude (for the time being) optimizations such as different approaches to supporting LMA to MAG multicast transit. I view this task as requiring a tight involvement with the NETLMM working group in order to ensure complete understanding of their evolving PMIPv6 specification. Thoughts? Comments? Regards, Brian _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Mon Dec 8 12:23:08 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261D53A6807; Mon, 8 Dec 2008 12:23:08 -0800 (PST) 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 91A323A6807 for ; Mon, 8 Dec 2008 12:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.174 X-Spam-Level: X-Spam-Status: No, score=-1.174 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, HTML_IMAGE_ONLY_24=1.552, 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 PDEj2lsQcbY6 for ; Mon, 8 Dec 2008 12:23:05 -0800 (PST) Received: from web111411.mail.gq1.yahoo.com (web111411.mail.gq1.yahoo.com [67.195.15.192]) by core3.amsl.com (Postfix) with SMTP id 223FE3A6804 for ; Mon, 8 Dec 2008 12:23:05 -0800 (PST) Received: (qmail 33990 invoked by uid 60001); 8 Dec 2008 20:22:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=3vrkjOsCTN4ZZzHOazj/CpvDtZJ+YXyhdy3vUjt4M7XkCQoPx19DBLN8JfKWTdDYz2FRU8jeszDsJ1EA08R7WJPeAGUneLyirsWAxe7tUDdexMzd4N6evRyGHBQSdyx6sfbHRFIXpsfEoVO4ymDa4rSzlyOmDXhuIafrGoGDess=; X-YMail-OSG: 5S.3ZuQVM1mgFeEGEaMpXrnUPrpgy3Ka3dLFdjAqPuroKg59WwhkGKNISZFHpO9ZLqqAe.yLPg5tePvkWRs.RIPU57zPMeLNJa2Js0TjcxyGDS.v4rqvJP2BnRQYyaLEe8P5p.dlqzRcf9X22qDSO6m9L0GrGOdJF5xtXDoZub4Q3JI- Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Mon, 08 Dec 2008 12:22:59 PST X-Mailer: YahooMailRC/1155.32 YahooMailWebService/0.7.260.1 References: <493D7E97.5060400@innovationslab.net> Date: Mon, 8 Dec 2008 12:22:59 -0800 (PST) From: Behcet Sarikaya To: Brian Haberman , multimob@ietf.org MIME-Version: 1.0 Message-ID: <877767.33889.qm@web111411.mail.gq1.yahoo.com> Subject: Re: [multimob] Multicast deployment in PMIPv6 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="===============1574554252==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============1574554252== Content-Type: multipart/alternative; boundary="0-206789416-1228767779=:33889" --0-206789416-1228767779=:33889 Content-Type: text/plain; charset=us-ascii Brian, I suggest combining this thread with Suresh's idea of coming up with a description of the intended deployment model(s) for multicast with PMIP. A quick draft could help stimulate the discussions and I am hoping that Suresh will do something . Regards, Behcet ________________________________ From: Brian Haberman To: multimob@ietf.org Sent: Monday, December 8, 2008 2:07:51 PM Subject: [multimob] Multicast deployment in PMIPv6 All, As I mentioned in an earlier message, one of the takeaways from the BoF is that there is some confusion of how multicast can be deployed in the current PMIPv6 architecture. Some people argued that multicast in PMIPv6 already exists using the base MIPv6 protocol. Others argued that either the MIPv6 multicast extensions can't be used or that they were insufficient. From those arguments, I would see a work item being the investigation of what the baseline deployment of multicast in PMIPv6 would look like. This would preclude (for the time being) optimizations such as different approaches to supporting LMA to MAG multicast transit. I view this task as requiring a tight involvement with the NETLMM working group in order to ensure complete understanding of their evolving PMIPv6 specification. Thoughts? Comments? Regards, Brian _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --0-206789416-1228767779=:33889 Content-Type: text/html; charset=us-ascii
Brian, I suggest combining this thread with Suresh's idea of coming up with a description of the intended deployment model(s) for multicast with PMIP.

A quick draft could help stimulate the discussions and I am hoping that Suresh will do something .

Regards,

Behcet

From: Brian Haberman <brian@innovationslab.net>
To: multimob@ietf.org
Sent: Monday, December 8, 2008 2:07:51 PM
Subject: [multimob] Multicast deployment in PMIPv6

All,
    As I mentioned in an earlier message, one of the takeaways from the BoF is that there is some confusion of how multicast can be deployed in the current PMIPv6 architecture.  Some people argued that multicast in PMIPv6 already exists using the base MIPv6 protocol.  Others argued that either the MIPv6 multicast extensions can't be used or that they were insufficient.

    From those arguments, I would see a work item being the investigation of what the baseline deployment of multicast in PMIPv6 would look like.  This would preclude (for the time being) optimizations such as different approaches to supporting LMA to MAG multicast transit.  I view this task as requiring a tight involvement with the NETLMM working group in order to ensure complete understanding of their evolving PMIPv6 specification.

    Thoughts?  Comments?

Regards,
Brian
_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

--0-206789416-1228767779=:33889-- --===============1574554252== 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 --===============1574554252==-- From multimob-bounces@ietf.org Mon Dec 8 22:51:29 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997CE3A6AA1; Mon, 8 Dec 2008 22:51:29 -0800 (PST) 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 B7ADC3A6A9F for ; Mon, 8 Dec 2008 22:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.22 X-Spam-Level: * X-Spam-Status: No, score=1.22 tagged_above=-999 required=5 tests=[AWL=-1.075, BAYES_00=-2.599, CN_BODY_35=0.339, 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 7AcXWtQnb3fT for ; Mon, 8 Dec 2008 22:51:28 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id CAB773A6A9E for ; Mon, 8 Dec 2008 22:51:27 -0800 (PST) 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 <0KBL00HI1KDBY0@szxga02-in.huawei.com> for multimob@ietf.org; Tue, 09 Dec 2008 14:51:12 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBL00GGVKDBA8@szxga02-in.huawei.com> for multimob@ietf.org; Tue, 09 Dec 2008 14:51:11 +0800 (CST) Received: from z49950 ([10.121.148.100]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KBL008AKKD8PK@szxml04-in.huawei.com> for multimob@ietf.org; Tue, 09 Dec 2008 14:51:11 +0800 (CST) Date: Tue, 09 Dec 2008 14:51:08 +0800 From: "john.zhao" In-reply-to: <493D7E97.5060400@innovationslab.net> To: 'Brian Haberman' , multimob@ietf.org Message-id: <009801c959ca$83eb6dc0$6494790a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: AclZcLVRhF1qAc/WRrClYssWknz1qAAWH/ng Subject: Re: [multimob] Multicast deployment in PMIPv6 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="gb2312" Content-Transfer-Encoding: base64 Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org SGksQnJpYW4gYW5kIGFsbAoJSU1ITywgd2hhdCBpcyB0aGUgc2NvcGUgb2YgdGhlIGRpc2N1c3Np b24gYWJvdXQgdGhlIGRlcGxveW1lbnQgaXMKbmVlZGVkIHRvIGJlIGRlZmluZWQgb3Igc3VnZ2Vz dGVkLiBXaXRob3V0IHRoZSBjb21wYXJpc29uIG9mIHRoZSBzb2x1dGlvbgpiZXR3ZWVuIG11bHRp Y2FzdCB3aXRoIE1JUHY2IG9yIFBNSVB2NiwgaG93IHRvIGRlY2lkZSBpZiBpdCBuZWVkIHRvIGJl IGRvbmUKYWdhaW4/IEkgcmVtZW1iZXIgdGhpcyBraW5kIG9mIGRpc2N1c3Npb24gaGFzIGJlZW4g YWxyZWFkeSBleGlzdGVkIGluIER1YmxpbgouIFNvIG15IHN1Z2dlc3Rpb24gaXMgYSBhc3N1bXB0 aW9uIGlzIHZlcnkgaW1wb3J0YW50IGFuZCBjYW4gYmUgdHJlYXRlZCBhcwpvdXIgc3RhcnR1cCBw b2ludCBmb3IgbmV4dCBzdGVwLiBTbyB3aGF0IGlzIG91ciBjdXJyZW50IGNvbW1vbiBpZGVhPyBO b25lIG9yCnNvbWV0aGluZz8gQW5kIGluIHdoaWNoIHNjb3BlIGFuZCBsZXZlbCAsIHRoZSBkZXBs b3ltZW50IHNob3VsZCBiZQpkaXNjdXNzZWQ/CgoJQmVzdCBSZ2RzLApUaGFua3MKCkpvaG4uemhh bwoKLS0tLS3Tyrz+1K28/i0tLS0tCkFsbCwKICAgICAgQXMgSSBtZW50aW9uZWQgaW4gYW4gZWFy bGllciBtZXNzYWdlLCBvbmUgb2YgdGhlIHRha2Vhd2F5cyBmcm9tIAp0aGUgQm9GIGlzIHRoYXQg dGhlcmUgaXMgc29tZSBjb25mdXNpb24gb2YgaG93IG11bHRpY2FzdCBjYW4gYmUgZGVwbG95ZWQg CmluIHRoZSBjdXJyZW50IFBNSVB2NiBhcmNoaXRlY3R1cmUuICBTb21lIHBlb3BsZSBhcmd1ZWQg dGhhdCBtdWx0aWNhc3QgCmluIFBNSVB2NiBhbHJlYWR5IGV4aXN0cyB1c2luZyB0aGUgYmFzZSBN SVB2NiBwcm90b2NvbC4gIE90aGVycyBhcmd1ZWQgCnRoYXQgZWl0aGVyIHRoZSBNSVB2NiBtdWx0 aWNhc3QgZXh0ZW5zaW9ucyBjYW4ndCBiZSB1c2VkIG9yIHRoYXQgdGhleSAKd2VyZSBpbnN1ZmZp Y2llbnQuCiAgICAgIEZyb20gdGhvc2UgYXJndW1lbnRzLCBJIHdvdWxkIHNlZSBhIHdvcmsgaXRl bSBiZWluZyB0aGUgCmludmVzdGlnYXRpb24gb2Ygd2hhdCB0aGUgYmFzZWxpbmUgZGVwbG95bWVu dCBvZiBtdWx0aWNhc3QgaW4gUE1JUHY2IAp3b3VsZCBsb29rIGxpa2UuICBUaGlzIHdvdWxkIHBy ZWNsdWRlIChmb3IgdGhlIHRpbWUgYmVpbmcpIG9wdGltaXphdGlvbnMgCnN1Y2ggYXMgZGlmZmVy ZW50IGFwcHJvYWNoZXMgdG8gc3VwcG9ydGluZyBMTUEgdG8gTUFHIG11bHRpY2FzdCB0cmFuc2l0 LiAKICBJIHZpZXcgdGhpcyB0YXNrIGFzIHJlcXVpcmluZyBhIHRpZ2h0IGludm9sdmVtZW50IHdp dGggdGhlIE5FVExNTSAKd29ya2luZyBncm91cCBpbiBvcmRlciB0byBlbnN1cmUgY29tcGxldGUg dW5kZXJzdGFuZGluZyBvZiB0aGVpciAKZXZvbHZpbmcgUE1JUHY2IHNwZWNpZmljYXRpb24uCgog ICAgICBUaG91Z2h0cz8gIENvbW1lbnRzPwoKUmVnYXJkcywKQnJpYW4KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbXVsdGltb2IgbWFpbGluZyBsaXN0Cm11 bHRpbW9iQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXVs dGltb2IKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpt dWx0aW1vYiBtYWlsaW5nIGxpc3QKbXVsdGltb2JAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aW1vYgo= From multimob-bounces@ietf.org Tue Dec 9 02:00:51 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89FEC3A6838; Tue, 9 Dec 2008 02:00:51 -0800 (PST) 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 499303A6838 for ; Tue, 9 Dec 2008 02:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tplNA4WOANg4 for ; Tue, 9 Dec 2008 02:00:50 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 0C3C63A63D3 for ; Tue, 9 Dec 2008 02:00:49 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Dec 2008 11:00:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Dec 2008 11:00:26 +0100 Message-ID: In-Reply-To: <493D7E90.5010307@innovationslab.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Commentson draft-deng-multimob-pmip6-requirement-01.txt thread-index: AclZcL8g6EL0emShTIG2h5lxWzqQsAAcSG8w References: <49130E13.8040805@informatik.haw-hamburg.de> <20081107.005253.179720275.asaeda@sfc.wide.ad.jp> <49131786.2030100@informatik.haw-hamburg.de> <20081107.013921.242149102.asaeda@sfc.wide.ad.jp> <49132333.3020403@informatik.haw-hamburg.de> <1d38a3350811090759n146c643jb709781328bd4c33@mail.gmail.com> <167758.33851.qm@web111413.mail.gq1.yahoo.com><493D5577.5050300@cs.uni-goettingen.de> <493D7E90.5010307@innovationslab.net> From: To: , X-OriginalArrivalTime: 09 Dec 2008 10:00:27.0203 (UTC) FILETIME=[F609E930:01C959E4] Cc: multimob@ietf.org Subject: Re: [multimob] Commentson draft-deng-multimob-pmip6-requirement-01.txt 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi all, The requirement draft allows different multicast deployment models for PMIP= . The problem is that the document is focusing also on operator requirement= s for IPTV deployment and it made confusion during boF meeting. So, I agree= we should clarify basics and focus on the problem we are trying to solve w= ith PMIP. A separate document, as suggested by Suresh, could help. I guess = work over this document could start with Brian's threads, right? Regards, Pierrick > -----Message d'origine----- > De=A0: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] De la > part de Brian Haberman > Envoy=E9=A0: lundi 8 d=E9cembre 2008 21:08 > =C0=A0: Niklas Neumann > Cc=A0: multimob@ietf.org > Objet=A0: Re: [multimob] Commentson draft-deng-multimob-pmip6-requirement- > 01.txt > = > Niklas, > I have two take aways from the BoF held in Minneapolis. I will > start two separate threads on the mailing list to discuss them, but at > the high level they are: > = > 1. Rather than focus on optimizations (i.e., LMA to MAG), focus on the > basics needed to deploy multicast in the current PMIPv6 architecture. > = > 2. Identify whether there is interest in investigating the performance > of IGMP/MLD over wireless networks. > = > Regards, > Brian > = > = > Niklas Neumann wrote: > > Hy everybody, > > > > are we satisfied with the charter proposal and the problem statement? It > > was my impression that a lot of people didn't agree with some of the > > assumptions made there. For example, LMA vs. MAG as multicast endpoints. > > > > So maybe we should revise those documents and be a little more > > conservative about the assumptions and statements made there. Something > > along the lines of examining current multicast behavior in PMIP with the > > goal of working on a best-practice guide or optimizations where needed. > > > > At least the discussion during the BOF showed, that the specifications > > are not clear about multicast in PMIP and clarifications are needed. > > > > Best regards > > Niklas > > > > > > Behcet Sarikaya wrote: > >> Hello all, > >> At Multimob BoF last week it became clear that PMIPv6 requirements > >> draft concentrated (probably) too much on the operating requirements > >> and failed to state some simple traffic requirements. > >> I remember these traffic requirements were already stated in the pre > >> BoF meeting we had in Dublin. > >> Any comments? Suresh? > >> > >> Regards, > >> > >> Behcet > = > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Wed Dec 10 05:41:03 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C61928C14C; Wed, 10 Dec 2008 05:41:03 -0800 (PST) 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 1173028C138 for ; Wed, 10 Dec 2008 05:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.412 X-Spam-Level: ** X-Spam-Status: No, score=2.412 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+rfKZBky-76 for ; Wed, 10 Dec 2008 05:41:01 -0800 (PST) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 81DAA28C132 for ; Wed, 10 Dec 2008 05:41:00 -0800 (PST) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 43EBF13D03DC; Wed, 10 Dec 2008 22:13:02 +0900 (JST) Date: Wed, 10 Dec 2008 22:40:53 +0900 (JST) Message-Id: <20081210.224053.57285660.asaeda@sfc.wide.ad.jp> To: brian@innovationslab.net From: Hitoshi Asaeda In-Reply-To: <493D7E9B.4060303@innovationslab.net> References: <493D7E9B.4060303@innovationslab.net> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] Group management protocol operation over wireless links 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, > As I mentioned in an earlier message, one of the takeaways > from the BoF involved investigating optimizing IGMP/MLD for wireless > links. One of the issues with this item is the vast array of > underlying wireless technologies. The initial task would have to > focus on identifying those link types (or at least their shared > characteristics) and what issues arise from the current IGMP/MLD > operational model operating over those links. I think lack of clarification of problem statement has been making many people confuse the working item in this group. Regarding the use of IGMP/MLD for mobility, some problems may depend on link types, and the others may not. But the basic problems and requirements for host-and-router communication with IGMP/MLD in mobile multicast would be common. IMO, problem statement should be clarified in some place (charter or draft). This is the first step. The optimized timer/parameter depends on link types and link conditions or usages. However, although the values may be different in link types, the concepts and methods for effective host-and-router communication with IGMP/MLD are not different from various wireless link types. And if IGMP/MLD protocol modification or extension may give better effectiveness, the proposed extension should be shared for any mobile multicast on any link type. > Ways forward could range from a BCP describing feasible > timer/parameter settings for various link types up to proposed > protocol changes to IGMP/MLD for operation over those link types. > One issue with this is the perceived reluctance on the part of > primary multicast routing vendors to change their implementations > (based on Marshall's comments at the BoF). Even if we guarantee the interoperability with the proposed solutions and the standard IGMP/MLD specifications, is there any potential problem? Regards, -- Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Wed Dec 10 07:54:41 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8043A698D; Wed, 10 Dec 2008 07:54:41 -0800 (PST) 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 C38233A6BAE for ; Wed, 10 Dec 2008 07:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.412 X-Spam-Level: ** X-Spam-Status: No, score=2.412 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kqk2S4uygIER for ; Wed, 10 Dec 2008 07:54:40 -0800 (PST) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id D587A3A6988 for ; Wed, 10 Dec 2008 07:54:39 -0800 (PST) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id ECEDF13D03DC; Thu, 11 Dec 2008 00:26:40 +0900 (JST) Date: Thu, 11 Dec 2008 00:54:32 +0900 (JST) Message-Id: <20081211.005432.157921739.asaeda@sfc.wide.ad.jp> To: brian@innovationslab.net From: Hitoshi Asaeda In-Reply-To: <493D7E97.5060400@innovationslab.net> References: <493D7E97.5060400@innovationslab.net> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] Multicast deployment in PMIPv6 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 > As I mentioned in an earlier message, one of the takeaways > from the BoF is that there is some confusion of how multicast can be > deployed in the current PMIPv6 architecture. Some people argued > that multicast in PMIPv6 already exists using the base MIPv6 > protocol. Others argued that either the MIPv6 multicast extensions > can't be used or that they were insufficient. I suppose their solutions are "home subscription only". It is possible to give multicast services in PMIPv6-domain without any protocol modification or special configuration, especially in home subscription only PMIPv6-domain. But whether home subscription or remote subscription is adopted, multicast protocol modification or special configuration will be required for "effective" communication, such as effective network resource use, effective (smooth/seamless) handover, effective traffic or quality control, and so on. For instance, the same multicast data may be replicated on LMA and unicasted multiple times (for individual MNs) over an LMA-MAG bi-directional tunnel if PMIPv6 adopts home subscription only configuration. This unwilling situation can be avoided if MAG is configured as a multicast router or MLD proxy. But if MAG is configured as a multicast router or MLD proxy, how LMA can be configured and interoperate with MAG effectively (i.e. low traffic cost but high convergence)? And in what kind of situation or requirement MAG should work as a router, not an MLD proxy? What is the benefit for each? In either case, how MAG can support MNs' movement with smooth handover? I believe these considerations and clarifications necessary. To obtain much consensus for the work, creating a problem statement document is the first step. After the problem statement clarification, the requirement statements become much feasible, and people understand the discussion about protocol extension or tuning is necessary. > From those arguments, I would see a work item being the > investigation of what the baseline deployment of multicast in PMIPv6 > would look like. This would preclude (for the time being) > optimizations such as different approaches to supporting LMA to MAG > multicast transit. I don't know whether we should start discussion from the baseline deployment. The important steps are that we provide scenarios to enable multicast routing functions in PMIPv6-domain (from protocol-oriented perspective), clarify PS and requirements, and consider effective solutions including special configurations and protocol extensions if needed. Regards, -- Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Wed Dec 10 13:26:19 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078D03A689E; Wed, 10 Dec 2008 13:26:19 -0800 (PST) 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 2A8F13A68FA for ; Wed, 10 Dec 2008 13:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[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 kPpWJYsiMrXV for ; Wed, 10 Dec 2008 13:26:17 -0800 (PST) Received: from n2.bullet.mail.gq1.yahoo.com (n2.bullet.mail.gq1.yahoo.com [67.195.9.85]) by core3.amsl.com (Postfix) with SMTP id 1CA393A689E for ; Wed, 10 Dec 2008 13:26:17 -0800 (PST) Received: from [67.195.9.81] by n2.bullet.mail.gq1.yahoo.com with NNFMP; 10 Dec 2008 21:26:11 -0000 Received: from [67.195.9.104] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 10 Dec 2008 21:26:11 -0000 Received: from [127.0.0.1] by omp108.mail.gq1.yahoo.com with NNFMP; 10 Dec 2008 21:26:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 492558.47083.bm@omp108.mail.gq1.yahoo.com Received: (qmail 99313 invoked by uid 60001); 10 Dec 2008 21:26:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=uyVt5/xH4FwHqRYkB5VLhrjACu63sW0+p6YHe9aMbL2a7ZaiXRyggwc9oZhYJIQ/9cDia964QJyWSbimLMGdfK0rMjUpnVV6YJ2VyUj1lk5MuLi1ErsYT3+L+xwFYVqO51f9fVT6t6mMcGxL3/cWn/HaOQyFZuDsy0j2TfT8WNw=; X-YMail-OSG: WHVKkzwVM1mI.b5GyRywOV4fJLTjUJXZX4KclFeXWgeIbKdMJqCjRSmrV8WRKX1ZOzjkDrRB2ik8fo5Cybyy9qArYY0YYYRyznYNKsPCz.E9S044vMRb577R2EWvcqIoWA4sBchZHGq8v.XKqPJU6sBma.17HEDWVok8TyLytYkXo8Y- Received: from [71.252.158.246] by web111404.mail.gq1.yahoo.com via HTTP; Wed, 10 Dec 2008 13:26:08 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <493D7E97.5060400@innovationslab.net> <20081211.005432.157921739.asaeda@sfc.wide.ad.jp> Date: Wed, 10 Dec 2008 13:26:08 -0800 (PST) From: Behcet Sarikaya To: Hitoshi Asaeda , brian@innovationslab.net MIME-Version: 1.0 Message-ID: <392604.99172.qm@web111404.mail.gq1.yahoo.com> Cc: multimob@ietf.org Subject: Re: [multimob] Multicast deployment in PMIPv6 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="===============0248790068==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0248790068== Content-Type: multipart/alternative; boundary="0-446713323-1228944368=:99172" --0-446713323-1228944368=:99172 Content-Type: text/plain; charset=us-ascii ________________________________ From: Hitoshi Asaeda To: brian@innovationslab.net Cc: multimob@ietf.org Sent: Wednesday, December 10, 2008 9:54:32 AM Subject: Re: [multimob] Multicast deployment in PMIPv6 > As I mentioned in an earlier message, one of the takeaways > from the BoF is that there is some confusion of how multicast can be > deployed in the current PMIPv6 architecture. Some people argued > that multicast in PMIPv6 already exists using the base MIPv6 > protocol. Others argued that either the MIPv6 multicast extensions > can't be used or that they were insufficient. I suppose their solutions are "home subscription only". It is possible to give multicast services in PMIPv6-domain without any protocol modification or special configuration, especially in home subscription only PMIPv6-domain. But whether home subscription or remote subscription is adopted, multicast protocol modification or special configuration will be required for "effective" communication, such as effective network resource use, effective (smooth/seamless) handover, effective traffic or quality control, and so on. For instance, the same multicast data may be replicated on LMA and unicasted multiple times (for individual MNs) over an LMA-MAG bi-directional tunnel if PMIPv6 adopts home subscription only configuration. This unwilling situation can be avoided if MAG is configured as a multicast router or MLD proxy. But if MAG is configured as a multicast router or MLD proxy, how LMA can be configured and interoperate with MAG effectively (i.e. low traffic cost but high convergence)? And in what kind of situation or requirement MAG should work as a router, not an MLD proxy? What is the benefit for each? In either case, how MAG can support MNs' movement with smooth handover? I believe these considerations and clarifications necessary. To obtain much consensus for the work, creating a problem statement document is the first step. After the problem statement clarification, the requirement statements become much feasible, and people understand the discussion about protocol extension or tuning is necessary. [behcet] The considerations you mentioned are all described in Thomas' draft and even more. In the past Suresh and I attempted to write a PS draft. Later on it became evident that there was no need. Jari told us that we can take draft-irtf-mobopts-mmcastv6-ps as PS draft and there is no need to write another PS draft. Please take a look at Multimob BoF agenda at http://www.ietf.org/proceedings/08nov/agenda/multimob.html, it is clearly shown that that PS draft is draft-irtf-mobopts-mmcastv6-ps-04.txt. We did not emphasize this strongly enough at the BoF, I guess. Or no matter what we did, there would be some people to question the PS. Regards, Behcet --0-446713323-1228944368=:99172 Content-Type: text/html; charset=us-ascii


From: Hitoshi Asaeda <asaeda@sfc.wide.ad.jp>
To: brian@innovationslab.net
Cc: multimob@ietf.org
Sent: Wednesday, December 10, 2008 9:54:32 AM
Subject: Re: [multimob] Multicast deployment in PMIPv6

>      As I mentioned in an earlier message, one of the takeaways
> from the BoF is that there is some confusion of how multicast can be
> deployed in the current PMIPv6 architecture.  Some people argued
> that multicast in PMIPv6 already exists using the base MIPv6
> protocol.  Others argued that either the MIPv6 multicast extensions
> can't be used or that they were insufficient.

I suppose their solutions are "home subscription only".
It is possible to give multicast services in PMIPv6-domain without any
protocol modification or special configuration, especially in home
subscription only PMIPv6-domain. But whether home subscription or
remote subscription is adopted, multicast protocol modification or
special configuration will be required for "effective" communication,
such as effective network resource use, effective (smooth/seamless)
handover, effective traffic or quality control, and so on.

For instance, the same multicast data may be replicated on LMA and
unicasted multiple times (for individual MNs) over an LMA-MAG
bi-directional tunnel if PMIPv6 adopts home subscription only
configuration. This unwilling situation can be avoided if MAG is
configured as a multicast router or MLD proxy. But if MAG is
configured as a multicast router or MLD proxy, how LMA can be
configured and interoperate with MAG effectively (i.e. low traffic
cost but high convergence)?
And in what kind of situation or requirement MAG should work as a
router, not an MLD proxy? What is the benefit for each? In either
case, how MAG can support MNs' movement with smooth handover?

I believe these considerations and clarifications necessary. To obtain
much consensus for the work, creating a problem statement document
is the first step. After the problem statement clarification, the
requirement statements become much feasible, and people understand the
discussion about protocol extension or tuning is necessary.

[behcet] The considerations you mentioned are all described in Thomas' draft and even more.
In the past Suresh and I attempted to write a PS draft. Later on it became evident that there was no need.
Jari told us that we can take draft-irtf-mobopts-mmcastv6-ps as PS draft and there is no need to write another PS draft.

Please take a look at Multimob BoF agenda at http://www.ietf.org/proceedings/08nov/agenda/multimob.html, it is clearly shown that that PS draft is draft-irtf-mobopts-mmcastv6-ps-04.txt.

We did not emphasize this strongly enough at the BoF, I guess.
Or no matter what we did, there would be some people to question the PS.

Regards,

Behcet

--0-446713323-1228944368=:99172-- --===============0248790068== 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 --===============0248790068==-- From multimob-bounces@ietf.org Wed Dec 10 17:39:53 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6593A67D0; Wed, 10 Dec 2008 17:39:53 -0800 (PST) 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 20E273A67D0 for ; Wed, 10 Dec 2008 17:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.412 X-Spam-Level: ** X-Spam-Status: No, score=2.412 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81AafXJjMnwh for ; Wed, 10 Dec 2008 17:39:52 -0800 (PST) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 66C283A67C1 for ; Wed, 10 Dec 2008 17:39:52 -0800 (PST) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 484B213D03DC; Thu, 11 Dec 2008 10:11:48 +0900 (JST) Date: Thu, 11 Dec 2008 10:39:45 +0900 (JST) Message-Id: <20081211.103945.31613576.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <392604.99172.qm@web111404.mail.gq1.yahoo.com> References: <493D7E97.5060400@innovationslab.net> <20081211.005432.157921739.asaeda@sfc.wide.ad.jp> <392604.99172.qm@web111404.mail.gq1.yahoo.com> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] Multicast deployment in PMIPv6 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 > [behcet] The considerations you mentioned are all described in > Thomas' draft and even more. > In the past Suresh and I attempted to write a PS draft. Later on it > became evident that there was no need. > Jari told us that we can take draft-irtf-mobopts-mmcastv6-ps as PS > draft and there is no need to write another PS draft. > > We did not emphasize this strongly enough at the BoF, I guess. > Or no matter what we did, there would be some people to question the PS. Ok, so I'm more curious why no good consensus for the working items? Am I missing something? -- Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Thu Dec 11 08:20:10 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 233953A6C5B; Thu, 11 Dec 2008 08:20:10 -0800 (PST) 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 AA61E3A679F; Mon, 8 Dec 2008 11:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 bA0WzulADXMC; Mon, 8 Dec 2008 11:15:57 -0800 (PST) Received: from relay2.mail.vrmd.de (relay2.mail.vrmd.de [81.28.224.28]) by core3.amsl.com (Postfix) with ESMTP id 2770A3A6A9D; Mon, 8 Dec 2008 11:15:57 -0800 (PST) Received: from [87.79.236.249] (helo=[192.168.1.102]) by relay2.mail.vrmd.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1L9la2-0007UE-9K; Mon, 08 Dec 2008 20:15:42 +0100 Message-Id: <0BB96D27-921B-4F6D-BFA5-32B657E7EEA7@let.de> From: Marc Manthey To: sam In-Reply-To: <4ce32a820812080607r7623e964i77ae3400faa9d39d@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 8 Dec 2008 20:15:40 +0100 References: <4ce32a820812080607r7623e964i77ae3400faa9d39d@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Relay-User: marc@let.de X-Mailman-Approved-At: Thu, 11 Dec 2008 08:20:09 -0800 Cc: mipshop , multimob@ietf.org, mobopts Subject: Re: [multimob] [SAM] XCAST at IETF 76 in Hiroshima 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="===============1357019128==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============1357019128== Content-Type: multipart/alternative; boundary=Apple-Mail-333--799045718 --Apple-Mail-333--799045718 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Am 08.12.2008 um 15:07 schrieb John Buford: > Dear XCAST-team, > > Please comment to the RG mailing list regarding what > XCAST-related activities we could cover at a SAM RG > meeting if we scheduled it at IETF 76. > > Thanks, > John hello i am curious if some of them might read this too https://sourceforge.net/project/memberlist.php?group_id=3D30760 > As I wrote on the BBS in linux-xcast6 of sourceforge, we don't have > patches for Mac OS X. I heard some want to try but currently I think > nobody working on porting XCAST6 on Mac. > >> What does a universal P2P overlay protocol mean in detail? Is it =20 >> similar to the common API by Dabek et al. ("Towards a Common API =20 >> for Structured Peer-to-Peer Overlays", 2003)? > > Probably general p2p overlay protocol is not directly targeted =20 > within the RG, but p2p/overlay multicast issues may do. There are =20 > some current efforts within the P2PSIP WG, not sure what about =20 > P2PRG... > >> Btw: It makes sense to have an interface definition between ALM =20 >> 'stack' and application. But this should be a part of a common =20 >> group membership framework maybe borrowed from IGMP/MLD. That could =20= >> be also an outcome of SAM RG. > > Re: group member management seems a good item to work on, maybe we =20 > can work out something within the group... regards marc -- Les Enfants Terribles - WWW.LET.DE Marc Manthey 50672 K=F6ln - Germany Hildeboldplatz 1a Tel.:0049-221-3558032 Mobil:0049-1577-3329231 mail: marc@let.de PGP/GnuPG: 0x1ac02f3296b12b4d jabber :marc@kgraff.net IRC: #opencu freenode.net twitter: http://twitter.com/macbroadcast web: http://www.let.de Opinions expressed may not even be mine by the time you read them, and =20= certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, =20 information on every electronic information exchange with me is =20 retained for a period of six months. --Apple-Mail-333--799045718 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Am 08.12.2008 um = 15:07 schrieb John Buford:

Dear XCAST-team,
 
=
Please comment to the RG mailing list regarding what
=
XCAST-related activities we could cover at a SAM RG
=
meeting if we scheduled it at IETF 76.
 
=
Thanks,
=
John

hello 

<= /div>i am curious if  some of them might read this = too


As = I wrote on the BBS in linux-xcast6 of sourceforge, we don't = have
patches for Mac OS X. I heard some want to = try but currently I think
nobody working on porting XCAST6 on = Mac.


 What does a universal = P2P overlay protocol mean in detail? Is it similar to the common API by = Dabek et al. ("Towards a Common API for Structured Peer-to-Peer = Overlays", 2003)?

Probably general p2p overlay = protocol is not directly targeted within the RG, but p2p/overlay = multicast issues may do. There are some current efforts within the = P2PSIP WG, not sure what about P2PRG...

 Btw: It makes sense to have an interface definition = between ALM 'stack' and application. But this should be a part of a = common group membership framework maybe borrowed from IGMP/MLD. That = could be also an outcome of SAM RG.

Re: group member = management seems a good item to work on, maybe we can work out something = within the = group...


re= gards

marc
--
Les Enfants Terribles - = WWW.LET.DE
Marc Manthey 50672 K=F6ln - = Germany
Hildeboldplatz = 1a
Tel.:0049-221-3558032
Mobil:0049-1577-3329231
mail: marc@let.de
PGP/GnuPG: = 0x1ac02f3296b12b4d 
IRC: #o= pencu  freenode.net

=
Opinions expressed may not even be mine by the time = you read them, and certainly don't reflect those of any other = entity (legal or otherwise).

Please note that = according to the German law on data retention, information on every = electronic information exchange with me is retained for a period of = six months.
=
= --Apple-Mail-333--799045718-- --===============1357019128== 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 --===============1357019128==-- From multimob-bounces@ietf.org Thu Dec 18 07:43:08 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDC3C3A68C3; Thu, 18 Dec 2008 07:43:08 -0800 (PST) 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 4A39C3A68B3 for ; Thu, 18 Dec 2008 07:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.184 X-Spam-Level: *** X-Spam-Status: No, score=3.184 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_53=0.6, J_CHICKENPOX_72=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, 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 a1Nydv3Lppo9 for ; Thu, 18 Dec 2008 07:43:00 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 357B33A6768 for ; Thu, 18 Dec 2008 07:43:00 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KC200GPGWZEF5@szxga01-in.huawei.com> for multimob@ietf.org; Thu, 18 Dec 2008 23:42:51 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KC200MOEWZE5G@szxga01-in.huawei.com> for multimob@ietf.org; Thu, 18 Dec 2008 23:42:50 +0800 (CST) Received: from jys3108050091fd (193.120.171.61.broad.xw.sh.dynamic.163data.com.cn [61.171.120.193]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KC200KL1WZCVQ@szxml02-in.huawei.com>; Thu, 18 Dec 2008 23:42:50 +0800 (CST) Date: Thu, 18 Dec 2008 23:43:25 +0800 From: "John.zhao" To: "john.zhao" , 'Brian Haberman' , "multimob@ietf.org" Message-id: <0KC200KL3WZEVQ@szxml02-in.huawei.com> Organization: Huawei Technologies Co.,LTD MIME-version: 1.0 X-Mailer: Foxmail 5.0 beta1 [cn] Subject: Re: [multimob] Multicast deployment in PMIPv6 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: john.zhao@huawei.com List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org SGksQnJpYW4gYW5kIGFsbA0KDQoJVGhlIGFuc3dlciB0byBteSBsYXN0IGVtYWlsIGJ5IG15c2Vs ZiBpcyB0aGUgYmFzZWxpbmUgZGVwbG95bWVudCBvZiBtdWx0aWNhc3QgaW4gUE1JUHY2IGlzIHJl YWxseSBuZWVkZWQgdG8gYmUgZG9uZS4gQmFzZWQgb24gY3VycmVudCB3aGF0IGNhbiBiZSBvZmZl cmVkIGFib3V0IG11bHRpY2FzdCBieSBjdXJyZW50IFBNSVB2NiAsIHdlIGNhbiBnZXQgYSB2ZXJ5 IGdvb2Qgc3RhcnQgcG9pbnQuIEFuZCB0aGVuIHdlIGNhbiBqdXN0IGRlY2lkZSB3aGljaCBhbmQg aG93IGFib3V0IG5ldyBmZWF0dXJlcyBuZWVkIHRvIGJlIGFwcGVuZGVkLiBJdCBzZWVtcyBjYW4g bWFrZSB1cyBnZXQgdGhlIGNvbnNlbnN1cyBjb250aW51YWxseS5JbiBmYWN0LCBqdXN0IGxpa2Ug UkZDMzc3NSwgaXQgZGlkbid0IHNwZWNpZnkgdGhlIHJlcXVpcmVtZW50IG9uIHRoZSBob3cgYWJv dXQgdGhlIGZ1bmN0aW9uIHRvIGFjaGlldmUgdGhlIG11bHRpY2FzdCBoYW5kbGluZyBnb2FsIGlu IGhvbWUgYWdlbnQsTUxEIFJvdXRlciBvciBNTEQgcHJveHkuU2ltaWxpYXJseSwgd2UgYXJlIGFs c28gZG9uJ3QgbmVlZCB0byBkbyB0aGF0IGluIHRoZSBiYXNlbGluZSBkb2MuIE9yIHNwZWNpZnkg TUxEIFJvdXRlciBhcyB0aGUgZGVmYXVsdCBjaG9pY2UuIFdpdGhpbiB0aGUgYmFzZWxpbmUgc2Nv cGUsIHRoZSBNQUcgbm8gbmVlZCB0byBkbyBhbnl0aGluZyBoZWxwIE1vYmlsZSBub2RlLCBidXQg aWYgd2UgY2FyZSBhYm91dCB0aGUgZWZmaWNpZW50IHByb2JsZW0gLCB0aGVuIGl0IGlzIHRoZSBm aXJzdCBjaG9pY2UgdG8gZG8gZm9yIHVzIHRvIGltcHJvdmUgdGhlIHBlcmZvcm1hbmNlIGZyb20g bmV0d29yayBzaWRlLkFuZCB0aGUgdHJhZmZpYyBiZXR3ZWVuIG1vYmlsZSBub2RlIGFuZCBNQUcg Y2FuIGJlIHNhdmUgZWZmZWN0aXZlbHkuIEFuZCBoYW5kb3ZlciBjYW4gYmVjb21lIGEgcmVzdWx0 IG9mIHRoYXQgcGFydC4gTWVhbndoaWxlLCB0aGUgdHJhZmZpYyBiZXR3ZWVuIE1BRyBhbmQgaG9t ZSBhZ2VudCBjYW4gYWxzbyBiZSBkZXNpZ25lZCB0byBvcHRpbWF6ZSBvbiB0cmFmZmljIGNvc3Qg YW5kL29yIG1hbmFnZW1lbnQgY29udHJvbCBjb25zaWRlcmF0aW9uLg0KCU9uIHN1bW1hcnksYnkg dGhpcyB3YXksIHdlIGNhbiBnYXRoZXIgb3VyIGNvbnNlbnN1cyB0b2dldGhlciBhbmQgc3RlcCBi eSBzdGVwLkhvdyBhYm91dCBpdD8NCg0KCUJlc3QgUmdkcywNClRoYW5rcw0KDQpKb2huLnpoYW8N Cj09PT09PT0gMjAwOC0xMi0wOSAxNDo1MTowMCBZb3UgaGF2ZSBzYWlkOj09PT09PT0NCg0KPkhp LEJyaWFuIGFuZCBhbGwNCj4JSU1ITywgd2hhdCBpcyB0aGUgc2NvcGUgb2YgdGhlIGRpc2N1c3Np b24gYWJvdXQgdGhlIGRlcGxveW1lbnQgaXMNCj5uZWVkZWQgdG8gYmUgZGVmaW5lZCBvciBzdWdn ZXN0ZWQuIFdpdGhvdXQgdGhlIGNvbXBhcmlzb24gb2YgdGhlIHNvbHV0aW9uDQo+YmV0d2VlbiBt dWx0aWNhc3Qgd2l0aCBNSVB2NiBvciBQTUlQdjYsIGhvdyB0byBkZWNpZGUgaWYgaXQgbmVlZCB0 byBiZSBkb25lDQo+YWdhaW4/IEkgcmVtZW1iZXIgdGhpcyBraW5kIG9mIGRpc2N1c3Npb24gaGFz IGJlZW4gYWxyZWFkeSBleGlzdGVkIGluIER1Ymxpbg0KPi4gU28gbXkgc3VnZ2VzdGlvbiBpcyBh IGFzc3VtcHRpb24gaXMgdmVyeSBpbXBvcnRhbnQgYW5kIGNhbiBiZSB0cmVhdGVkIGFzDQo+b3Vy IHN0YXJ0dXAgcG9pbnQgZm9yIG5leHQgc3RlcC4gU28gd2hhdCBpcyBvdXIgY3VycmVudCBjb21t b24gaWRlYT8gTm9uZSBvcg0KPnNvbWV0aGluZz8gQW5kIGluIHdoaWNoIHNjb3BlIGFuZCBsZXZl bCAsIHRoZSBkZXBsb3ltZW50IHNob3VsZCBiZQ0KPmRpc2N1c3NlZD8NCj4NCj4JQmVzdCBSZ2Rz LA0KPlRoYW5rcw0KPg0KPkpvaG4uemhhbw0KPg0KPi0tLS0t08q8/tStvP4tLS0tLQ0KPkFsbCwN Cj4gICAgICBBcyBJIG1lbnRpb25lZCBpbiBhbiBlYXJsaWVyIG1lc3NhZ2UsIG9uZSBvZiB0aGUg dGFrZWF3YXlzIGZyb20gDQo+dGhlIEJvRiBpcyB0aGF0IHRoZXJlIGlzIHNvbWUgY29uZnVzaW9u IG9mIGhvdyBtdWx0aWNhc3QgY2FuIGJlIGRlcGxveWVkIA0KPmluIHRoZSBjdXJyZW50IFBNSVB2 NiBhcmNoaXRlY3R1cmUuICBTb21lIHBlb3BsZSBhcmd1ZWQgdGhhdCBtdWx0aWNhc3QgDQo+aW4g UE1JUHY2IGFscmVhZHkgZXhpc3RzIHVzaW5nIHRoZSBiYXNlIE1JUHY2IHByb3RvY29sLiAgT3Ro ZXJzIGFyZ3VlZCANCj50aGF0IGVpdGhlciB0aGUgTUlQdjYgbXVsdGljYXN0IGV4dGVuc2lvbnMg Y2FuJ3QgYmUgdXNlZCBvciB0aGF0IHRoZXkgDQo+d2VyZSBpbnN1ZmZpY2llbnQuDQo+ICAgICAg RnJvbSB0aG9zZSBhcmd1bWVudHMsIEkgd291bGQgc2VlIGEgd29yayBpdGVtIGJlaW5nIHRoZSAN Cj5pbnZlc3RpZ2F0aW9uIG9mIHdoYXQgdGhlIGJhc2VsaW5lIGRlcGxveW1lbnQgb2YgbXVsdGlj YXN0IGluIFBNSVB2NiANCj53b3VsZCBsb29rIGxpa2UuICBUaGlzIHdvdWxkIHByZWNsdWRlIChm b3IgdGhlIHRpbWUgYmVpbmcpIG9wdGltaXphdGlvbnMgDQo+c3VjaCBhcyBkaWZmZXJlbnQgYXBw cm9hY2hlcyB0byBzdXBwb3J0aW5nIExNQSB0byBNQUcgbXVsdGljYXN0IHRyYW5zaXQuIA0KPiAg SSB2aWV3IHRoaXMgdGFzayBhcyByZXF1aXJpbmcgYSB0aWdodCBpbnZvbHZlbWVudCB3aXRoIHRo ZSBORVRMTU0gDQo+d29ya2luZyBncm91cCBpbiBvcmRlciB0byBlbnN1cmUgY29tcGxldGUgdW5k ZXJzdGFuZGluZyBvZiB0aGVpciANCj5ldm9sdmluZyBQTUlQdjYgc3BlY2lmaWNhdGlvbi4NCj4N Cj4gICAgICBUaG91Z2h0cz8gIENvbW1lbnRzPw0KPg0KPlJlZ2FyZHMsDQo+QnJpYW4NCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm11bHRpbW9iIG1h aWxpbmcgbGlzdA0KPm11bHRpbW9iQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tdWx0aW1vYg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+bXVsdGltb2IgbWFpbGluZyBsaXN0DQo+bXVsdGltb2JA aWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211bHRpbW9i DQoNCj0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPQ0KCQkJDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm11bHRpbW9iIG1haWxp bmcgbGlzdAptdWx0aW1vYkBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL211bHRpbW9iCg==