From stig@venaas.com Wed Apr 3 10:17:18 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2879A21F8F41 for ; Wed, 3 Apr 2013 10:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rc+yjfHbTlEw for ; Wed, 3 Apr 2013 10:17:17 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5C821F8F33 for ; Wed, 3 Apr 2013 10:17:17 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id AF7757FEE for ; Wed, 3 Apr 2013 19:17:15 +0200 (CEST) Message-ID: <515C63D5.5020207@venaas.com> Date: Wed, 03 Apr 2013 10:16:05 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: multimob@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [multimob] draft-ietf-multimob-pmipv6-ropt-03 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:17:18 -0000 Please folks respond to this last call. It ends April 8th. I haven't seen a single response yet. Stig On 3/15/2013 7:51 AM, Behcet Sarikaya wrote: > Folks, > Since there was consensus in the meeting on Wednesday this week, this message starts a three week Multimob Working Group last call > on advancing: > Title : Multicast Mobility Routing Optimizations for > Proxy Mobile IPv6 > Author(s) : Juan Carlos Zuniga > Luis M. Contreras > Carlos J. Bernardos > Seil Jeon > Younghan Kim > Filename : draft-ietf-multimob-pmipv6-ropt-03.txt > Pages : 25 > Date : 2013-02-25 > > as Experimental. Substantive comments and statements of support > for advancing this document should be directed to the mailing list. > Editorial suggestions can be sent to the authors. This last call will > end on April 8, 2013. > > We also indicate that there was an IPR claim made according to IETF rules on version 00 of this draft, for details, seehttps://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-multimob-pmipv6-ropt. > > > Regards, > Behcet > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From Akbar.Rahman@InterDigital.com Wed Apr 3 11:04:36 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FB721F8D8C for ; Wed, 3 Apr 2013 11:04:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtNZOiPv9rFS for ; Wed, 3 Apr 2013 11:04:36 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id F1E1B21F8D86 for ; Wed, 3 Apr 2013 11:04:35 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Apr 2013 14:04:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Apr 2013 14:04:31 -0400 Message-ID: In-Reply-To: <515C63D5.5020207@venaas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] draft-ietf-multimob-pmipv6-ropt-03 Thread-Index: Ac4wjxxvP8AG4WzxT6OD5mklaosjZAABje6g References: <515C63D5.5020207@venaas.com> From: "Rahman, Akbar" To: "Stig Venaas" , X-OriginalArrivalTime: 03 Apr 2013 18:04:35.0276 (UTC) FILETIME=[B31018C0:01CE3095] Subject: Re: [multimob] draft-ietf-multimob-pmipv6-ropt-03 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 18:04:36 -0000 Sorry for the delay, Stig. I lost track of time as winter seems to be never ending here in Canada. I reviewed the latest version of the I-D and it addresses all the issues that I had raised in previous discussions and reviews. So, I support in advancing this I-D to Experimental RFC status. Best Regards, Akbar -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Stig Venaas Sent: Wednesday, April 03, 2013 1:16 PM To: multimob@ietf.org Subject: Re: [multimob] draft-ietf-multimob-pmipv6-ropt-03 Please folks respond to this last call. It ends April 8th. I haven't seen a single response yet. Stig On 3/15/2013 7:51 AM, Behcet Sarikaya wrote: > Folks, > Since there was consensus in the meeting on Wednesday this week, this message starts a three week Multimob Working Group last call > on advancing: > Title : Multicast Mobility Routing Optimizations for > Proxy Mobile IPv6 > Author(s) : Juan Carlos Zuniga > Luis M. Contreras > Carlos J. Bernardos > Seil Jeon > Younghan Kim > Filename : draft-ietf-multimob-pmipv6-ropt-03.txt > Pages : 25 > Date : 2013-02-25 > > as Experimental. Substantive comments and statements of support > for advancing this document should be directed to the mailing list. > Editorial suggestions can be sent to the authors. This last call will > end on April 8, 2013. > > We also indicate that there was an IPR claim made according to IETF rules on version 00 of this draft, for details, seehttps://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&docu= m ent_search=3Ddraft-ietf-multimob-pmipv6-ropt. > > > 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 sfigueiredo@av.it.pt Thu Apr 4 11:24:50 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2789421F8C78 for ; Thu, 4 Apr 2013 11:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QI0NLRt-srN4 for ; Thu, 4 Apr 2013 11:24:49 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4F77821F8CF8 for ; Thu, 4 Apr 2013 11:24:48 -0700 (PDT) Received: from [192.168.25.56] (account sfigueiredo@av.it.pt [192.168.25.56] verified) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 68563446 for multimob@ietf.org; Thu, 04 Apr 2013 19:24:44 +0100 Message-ID: <515DC56C.9050907@av.it.pt> Date: Thu, 04 Apr 2013 19:24:44 +0100 From: =?ISO-8859-1?Q?S=E9rgio_Figueiredo?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: multimob@ietf.org References: <515C63D5.5020207@venaas.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [multimob] draft-ietf-multimob-pmipv6-ropt-03 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 18:24:50 -0000 Dear Chairs, all, I went through the latest version of the document. I am fine with the current content and as such I support moving it forward. Best regards, Sérgio On 04/03/2013 07:04 PM, Rahman, Akbar wrote: > Sorry for the delay, Stig. I lost track of time as winter seems to be > never ending here in Canada. > > > I reviewed the latest version of the I-D and it addresses all the issues > that I had raised in previous discussions and reviews. So, I support in > advancing this I-D to Experimental RFC status. > > > Best Regards, > > > Akbar > > > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Stig Venaas > Sent: Wednesday, April 03, 2013 1:16 PM > To: multimob@ietf.org > Subject: Re: [multimob] draft-ietf-multimob-pmipv6-ropt-03 > > Please folks respond to this last call. It ends April 8th. > I haven't seen a single response yet. > > Stig > > On 3/15/2013 7:51 AM, Behcet Sarikaya wrote: >> Folks, >> Since there was consensus in the meeting on Wednesday this week, > this message starts a three week Multimob Working Group last call >> on advancing: >> Title : Multicast Mobility Routing Optimizations for >> Proxy Mobile IPv6 >> Author(s) : Juan Carlos Zuniga >> Luis M. Contreras >> Carlos J. Bernardos >> Seil Jeon >> Younghan Kim >> Filename : draft-ietf-multimob-pmipv6-ropt-03.txt >> Pages : 25 >> Date : 2013-02-25 >> >> as Experimental. Substantive comments and statements of support >> for advancing this document should be directed to the mailing list. >> Editorial suggestions can be sent to the authors. This last call will >> end on April 8, 2013. >> >> We also indicate that there was an IPR claim made according to IETF > rules on version 00 of this draft, for details, > seehttps://datatracker.ietf.org/ipr/search/?option=document_search&docum > ent_search=draft-ietf-multimob-pmipv6-ropt. >> >> Regards, >> Behcet >> >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From sarikaya2012@gmail.com Thu Apr 4 15:12:30 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415A821F8910 for ; Thu, 4 Apr 2013 15:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6bitc1hpDcr for ; Thu, 4 Apr 2013 15:12:29 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id B51D621F86DC for ; Thu, 4 Apr 2013 15:12:29 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id kl13so1706298pab.18 for ; Thu, 04 Apr 2013 15:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:date:message-id:subject:from:to :content-type; bh=EcD61qUMOw8SQoDX8+N5CxoK11Rx7ISwKKYwS1ZsnPI=; b=sY9itwZLPI/mgvS9FTl+m+Oy33cy3q13R1nLoNq/crMDo6aef+3D4qZxu9mZVUgdOM sKsLvDwHTV5a7NipkdK5KI4kHrI5vk8jX7eIpKU+P7A47Mj9JLx6CUZgjae2Oogi4MIe SH9PMxdY020J82AJNN0SeBQJGxms1OxhX8c99l7sMwUn5AYmP0mf0beFrdnvsumnaaF9 jcUveBI+WHpOMPPj1QZvBJFj6dCGX2Qux6J8uaGBuxsmZDGXYZT2jFg+0YGH9G3qlfDj FtJUFVge0rQNxHU8xUPVpDFWKpz6BzUFS1p3uQg9Wa80NXRFcTAivjL5DeH2sPTkYM5q IT+g== MIME-Version: 1.0 X-Received: by 10.66.52.50 with SMTP id q18mr11957767pao.201.1365113549497; Thu, 04 Apr 2013 15:12:29 -0700 (PDT) Received: by 10.66.237.100 with HTTP; Thu, 4 Apr 2013 15:12:29 -0700 (PDT) Date: Thu, 4 Apr 2013 17:12:29 -0500 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: multipart/alternative; boundary=bcaec543098a322c8404d99044b7 Subject: [multimob] LC Comments on draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 22:12:30 -0000 --bcaec543098a322c8404d99044b7 Content-Type: text/plain; charset=ISO-8859-1 Hi Authors, >From my previous review on Feb. 11, 2013: How do you avoid tunnel convergence problem if there are more than one MTMA? You have some hints in Appendix A.3, related to Fig. 8 but it is still not clear. Please explain it here in 3.1 We discussed this in Orlando, here are excerpts from the minutes: Behcet - But tunnel convergence is if mobile receives multiple copies of the same data JC - I am not sure I understand? Carlos - A single group will be linked to a single MTMA. So cannot receive multiple copies in the mobile Please add a good explanation of how the tunnel convergence is avoided in the presence of multiple MTMAs in Section 3.1. Regards, Behcet --bcaec543098a322c8404d99044b7 Content-Type: text/html; charset=ISO-8859-1 Hi Authors,

From my previous review on Feb. 11, 2013:

How do you avoid tunnel convergence problem if there are more than one MTMA? You have some hints in Appendix A.3, related to Fig. 8 but it is still not clear. Please explain it here in 3.1

We discussed this in Orlando, here are excerpts from the minutes:

Behcet - But tunnel convergence is if mobile receives multiple copies
          of the same data
          
          JC - I am not sure I understand?
          
          Carlos - A single group will be linked to a single MTMA.  So cannot
          receive multiple copies in the mobile
Please add a good explanation of how the tunnel convergence is avoided in the presence of multiple MTMAs in Section 3.1.

Regards,

Behcet
--bcaec543098a322c8404d99044b7-- From Dirk.von-Hugo@telekom.de Mon Apr 8 05:08:27 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B828921F93D3 for ; Mon, 8 Apr 2013 05:08:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MFwAxh+B8zS for ; Mon, 8 Apr 2013 05:08:27 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id CDDCF21F93B0 for ; Mon, 8 Apr 2013 05:08:26 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 08 Apr 2013 14:08:18 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 8 Apr 2013 14:08:06 +0200 From: To: , Date: Mon, 8 Apr 2013 14:08:05 +0200 Thread-Topic: [multimob] draft-ietf-multimob-pmipv6-ropt-03 Thread-Index: Ac4xSW5zUaVvKydGTWOEHgciiAuWSwDBkX2A Message-ID: <05C81A773E48DD49B181B04BA21A342A2BAC9A85AC@HE113484.emea1.cds.t-internal.com> References: <515C63D5.5020207@venaas.com> In-Reply-To: <515C63D5.5020207@venaas.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multimob] draft-ietf-multimob-pmipv6-ropt-03 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 12:08:28 -0000 Dear all, I think the draft is ready to go forward after some nits removal (see separ= ate mail). Furthermor I propose to add in ch. 3.1 a sentence like ... Deployment of multiple MTMAs by an operator dedicated to different mult= icast groups would resolve the tunnel convergence problem in case of MN han= dover. ... Moreover one should mention now in ch. 9 (IANA considerations) the newly in= troduced "Dynamic IP Multicast Selector" option described in ch.5.1. Best regards Dirk Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftra= g von Stig Venaas Gesendet: Mittwoch, 3. April 2013 19:16 An: multimob@ietf.org Betreff: Re: [multimob] draft-ietf-multimob-pmipv6-ropt-03 Please folks respond to this last call. It ends April 8th. I haven't seen a single response yet. Stig On 3/15/2013 7:51 AM, Behcet Sarikaya wrote: > Folks, > Since there was consensus in the meeting on Wednesday this week, th= is message starts a three week Multimob Working Group last call > on advancing: > Title : Multicast Mobility Routing Optimizations for > Proxy Mobile IPv6 > Author(s) : Juan Carlos Zuniga > Luis M. Contreras > Carlos J. Bernardos > Seil Jeon > Younghan Kim > Filename : draft-ietf-multimob-pmipv6-ropt-03.txt > Pages : 25 > Date : 2013-02-25 > > as Experimental. Substantive comments and statements of support > for advancing this document should be directed to the mailing list. > Editorial suggestions can be sent to the authors. This last call will > end on April 8, 2013. > > We also indicate that there was an IPR claim made according to IETF rules= on version 00 of this draft, for details, seehttps://datatracker.ietf.org/= ipr/search/?option=3Ddocument_search&document_search=3Ddraft-ietf-multimob-= pmipv6-ropt. > > > 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 cjbc@it.uc3m.es Mon Apr 8 11:14:44 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C7421F939F for ; Mon, 8 Apr 2013 11:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAbnxc8I1ewe for ; Mon, 8 Apr 2013 11:14:43 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 661EE21F938F for ; Mon, 8 Apr 2013 11:14:43 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B8EA2CD5236; Mon, 8 Apr 2013 20:14:33 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id AD08AC35B3E; Mon, 8 Apr 2013 20:14:33 +0200 (CEST) Message-ID: <1365444873.4802.85.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Dirk.von-Hugo@telekom.de Date: Mon, 08 Apr 2013 20:14:33 +0200 In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2BAC9A85AC@HE113484.emea1.cds.t-internal.com> References: <515C63D5.5020207@venaas.com> <05C81A773E48DD49B181B04BA21A342A2BAC9A85AC@HE113484.emea1.cds.t-internal.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19784.001 X-TM-AS-Result: No--37.799-7.0-31-1 X-imss-scan-details: No--37.799-7.0-31-1 Cc: multimob@ietf.org Subject: Re: [multimob] draft-ietf-multimob-pmipv6-ropt-03 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 18:14:44 -0000 Hi Dirk, Thanks a lot for your comments. We'll apply them in the next revision of the draft. Carlos On Mon, 2013-04-08 at 14:08 +0200, Dirk.von-Hugo@telekom.de wrote: > Dear all, > I think the draft is ready to go forward after some nits removal (see separate mail). Furthermor I propose to add in ch. 3.1 a sentence like > ... Deployment of multiple MTMAs by an operator dedicated to different multicast groups would resolve the tunnel convergence problem in case of MN handover. ... > > Moreover one should mention now in ch. 9 (IANA considerations) the newly introduced "Dynamic IP Multicast Selector" option described in ch.5.1. > > Best regards > Dirk > > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftrag von Stig Venaas > Gesendet: Mittwoch, 3. April 2013 19:16 > An: multimob@ietf.org > Betreff: Re: [multimob] draft-ietf-multimob-pmipv6-ropt-03 > > Please folks respond to this last call. It ends April 8th. > I haven't seen a single response yet. > > Stig > > On 3/15/2013 7:51 AM, Behcet Sarikaya wrote: > > Folks, > > Since there was consensus in the meeting on Wednesday this week, this message starts a three week Multimob Working Group last call > > on advancing: > > Title : Multicast Mobility Routing Optimizations for > > Proxy Mobile IPv6 > > Author(s) : Juan Carlos Zuniga > > Luis M. Contreras > > Carlos J. Bernardos > > Seil Jeon > > Younghan Kim > > Filename : draft-ietf-multimob-pmipv6-ropt-03.txt > > Pages : 25 > > Date : 2013-02-25 > > > > as Experimental. Substantive comments and statements of support > > for advancing this document should be directed to the mailing list. > > Editorial suggestions can be sent to the authors. This last call will > > end on April 8, 2013. > > > > We also indicate that there was an IPR claim made according to IETF rules on version 00 of this draft, for details, seehttps://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-multimob-pmipv6-ropt. > > > > > > Regards, > > Behcet > > > > > > > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From cjbc@it.uc3m.es Tue Apr 9 18:08:37 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7679821F97B5 for ; Tue, 9 Apr 2013 18:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9I6jS70Fj30T for ; Tue, 9 Apr 2013 18:08:37 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id DB98D21F97B4 for ; Tue, 9 Apr 2013 18:08:36 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0827ECD53A7; Wed, 10 Apr 2013 03:08:36 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [192.168.1.3] (82.158.126.26.dyn.user.ono.com [82.158.126.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id E3245CC5DEF; Wed, 10 Apr 2013 03:08:35 +0200 (CEST) Message-ID: <1365556115.4323.27.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: sarikaya@ieee.org Date: Wed, 10 Apr 2013 03:08:35 +0200 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19786.003 X-TM-AS-Result: No--21.014-7.0-31-1 X-imss-scan-details: No--21.014-7.0-31-1 Cc: multimob@ietf.org Subject: Re: [multimob] LC Comments on draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 01:08:37 -0000 Hi Behcet, We did modify the text in A.3 as a result of your comment before Orlando. Did you check that version? is it still not clear? Basically, there may be more than one MTMA, but in this case each of them will be associated to different contents (mcast groups), not to different MNs, so the tunnel converge problem cannot appear. Thanks, Carlos On Thu, 2013-04-04 at 17:12 -0500, Behcet Sarikaya wrote: > Hi Authors, > > From my previous review on Feb. 11, 2013: > > How do you avoid tunnel convergence problem if there are more than one > MTMA? You have some hints in Appendix A.3, related to Fig. 8 but it is > still not clear. Please explain it here in 3.1 > > We discussed this in Orlando, here are excerpts from the minutes: > > Behcet - But tunnel convergence is if mobile receives multiple copies > of the same data > > JC - I am not sure I understand? > > Carlos - A single group will be linked to a single MTMA. So cannot > receive multiple copies in the mobile > Please add a good explanation of how the tunnel convergence is avoided > in the presence of multiple MTMAs in Section 3.1. > > Regards, > > Behcet > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From lmcm@tid.es Wed Apr 10 00:49:46 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AEF21F8F2C for ; Wed, 10 Apr 2013 00:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4e0PCXnunncM for ; Wed, 10 Apr 2013 00:49:45 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9DD821F8F22 for ; Wed, 10 Apr 2013 00:49:44 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0ML100KO54ENAD@tid.hi.inet> for multimob@ietf.org; Wed, 10 Apr 2013 09:49:38 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id C5.02.01293.19915615; Wed, 10 Apr 2013 09:49:37 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0ML100KOV4EPAD@tid.hi.inet> for multimob@ietf.org; Wed, 10 Apr 2013 09:49:37 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Wed, 10 Apr 2013 09:49:37 +0200 Date: Wed, 10 Apr 2013 07:49:37 +0000 From: LUIS MIGUEL CONTRERAS MURILLO X-Originating-IP: [10.95.64.115] To: "multimob@ietf.org" Message-id: <823234EF5C7C334998D973D822FF801B44F3B06C@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_RwvWuwRW1CzxaiaO7adhlg)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization Thread-index: Ac41v9OZ+4IIQcIETzu6AFg3ZJE8Rg== X-AuditID: 0a5f4068-b7f006d00000050d-46-516519914791 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsXCFe/ApTtRMjXQ4OFGU4sZH/tYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMbP5MVvBDp2K4+dbmRoYl6l1MXJySAiYSFy70cwEYYtJXLi3 nq2LkYtDSGAjo8T/xdNYIZzfjBLXDn5lgXCmMUq8+vCRsYuRg4NFQFXi+oYQkG42AUOJWTsn sYKEhQXyJKYdSoAYqiDx59xjFhBbREBb4s3LP2DLmAXSJD6evwoW5xXwlni3eS47hC0o8WPy PRaImlygTRPZIWxxiTm/JrKC2IwCshIrz59mhJhZLLHx00k2CFtPonHmajaIvQISS/acZ4aw RSVePv7HOoFRZBaSFbOQrJiFZAWErSdxY+oUNghbW2LZwtfMELauxIx/h1iQxRcwsq9iFCtO KspMzyjJTczMSTcw1MvI1MvMSy3ZxAiJoowdjMt3qhxiFOBgVOLhVXibEijEmlhWXJl7iFGC g1lJhPfmd6AQb0piZVVqUX58UWlOavEhRiYOTqkGRkMRzcD2R9KvTseW/1+/W6FoovvFj5Ib git8lso659ZFhmsfvLph+zfVTZavW3duPpu0PmDSFfmpXZp3T31Myz7TEzgrmW3eqvSGPOPM V5Ee5ZfCWfklPyptauFieiqpsWehj35a6qONF0zs/0j8Xrb3hNJptu15q7aUnXuuFjrt1oMD q7LTHJRYijMSDbWYi4oTAWZrJIGAAgAA Subject: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 07:49:46 -0000 --Boundary_(ID_RwvWuwRW1CzxaiaO7adhlg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Dear all, After the Orlando meeting discussions on the flag A mechanism described in = draft-ietf-multimob-handover-optimization-02 for mitigating the internal si= gnaling within the network in case of reactive handover, we would like to c= onsult WG members about your preference: Option 1.- To include the flag A mechanism as an integral (and mandatory) p= art of the solution, as described in the draft today. Option 2.- To consider the flag A mechanism as an option to reduce signalin= g in the core, then removing the reference to this mechanism from the draft= . The final document would consider that the LMA always queries the pMAG by= default, but mentioning that some mechanism (out-of-scope) could be used t= o reduce this signaling (by avoiding to query the pMAG). Thanks in advance, Best regards, Luis ________________________________ Luis M. Contreras Technology / Global CTO / Telef=F3nica Efficiency Projects / Telef=F3nica I+D Distrito Telef=F3nica, Edificio Sur 3, Planta 3 28050 Madrid Espa=F1a / Spain lmcm@tid.es ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_RwvWuwRW1CzxaiaO7adhlg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Dear all,

 

After the Orlando meeting discussions on the flag= A mechanism described in draft-ietf-multimob-handover-optimization-02 for = mitigating the internal signaling within the network in case of reactive ha= ndover, we would like to consult WG members about your preference:

 

Option 1.- To include the flag A mechanism as an = integral (and mandatory) part of the solution, as described in the draft to= day.

 

Option 2.- To consider the flag A mechanism as an= option to reduce signaling in the core, then removing the reference to thi= s mechanism from the draft. The final document would consider that the LMA = always queries the pMAG by default, but mentioning that some mechanism (out-of-scope) could be used to reduce = this signaling (by avoiding to query the pMAG).

 

Thanks in advance,

 

Best regards,

 

Luis

 

________________________________

Luis M. Contreras

 

Technology / Global CTO / Telef=F3= nica

Efficiency Projects / Telef=F3nica= I+D

 

Distrito Telef=F3nica, Edificio Su= r 3, Planta 3

28050 Madrid

Espa=F1a / Spain

 

lmcm@tid.es

 



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_RwvWuwRW1CzxaiaO7adhlg)-- From sarikaya2012@gmail.com Wed Apr 10 08:45:59 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD7F21F973B for ; Wed, 10 Apr 2013 08:45:59 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j979AN7FrELx for ; Wed, 10 Apr 2013 08:45:58 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 298F921F8F69 for ; Wed, 10 Apr 2013 08:45:57 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id gw10so583136lab.4 for ; Wed, 10 Apr 2013 08:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OQMIOuwpM6s4S7jPb+4Ml+XxaKOrgXT+9m1mnA7sW0I=; b=wVs6cvSE2tjAvElQXQPEXClKfRLfHUKDw3jyDMKF4dtvgzjc3g2DQTRKbLwhotyLOo B9Wt0tZ9StERGt53V9n2htIXNBvW30jGABKIxFWCwtXiJ/uxSQeMkotFiGM/ZIYtuvgj l40hxVaIdK9KzwUmRZHVvh4hjkZ0nhyKnmelSP0bcVQ0Jw1QeQazkNFo6MweiWgSwcLC +xgYQLFHMnyn9OpCGTAdCfnOlYFX1PEIysgl1GkCBFJK6jAw1uebMXbDgaU2bmSMYicl xej6zkVJRZKL8S0UEun+WGj9ryde6nyAHN3w5JZq3DlC35zD/Rz+b9u7RuqlVQ/hpcLu rInw== MIME-Version: 1.0 X-Received: by 10.112.140.1 with SMTP id rc1mr1506434lbb.43.1365608756995; Wed, 10 Apr 2013 08:45:56 -0700 (PDT) Received: by 10.114.17.104 with HTTP; Wed, 10 Apr 2013 08:45:56 -0700 (PDT) In-Reply-To: <1365556115.4323.27.camel@acorde.it.uc3m.es> References: <1365556115.4323.27.camel@acorde.it.uc3m.es> Date: Wed, 10 Apr 2013 10:45:56 -0500 Message-ID: From: Behcet Sarikaya To: cjbc@it.uc3m.es Content-Type: multipart/alternative; boundary=001a11c38e9adcedf804da03908f Cc: multimob@ietf.org Subject: Re: [multimob] LC Comments on draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 15:45:59 -0000 --001a11c38e9adcedf804da03908f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlos, On Tue, Apr 9, 2013 at 8:08 PM, Carlos Jes=FAs Bernardos Cano wrote: > Hi Behcet, > > We did modify the text in A.3 as a result of your comment before > Orlando. Did you check that version? is it still not clear? > > The comment was to explain this important issue in the main text, e.g. Sec. 3.1. That said, I am OK with Dirk's comments. That is going to resolve the issue= . Regards, Behcet > Basically, there may be more than one MTMA, but in this case each of > them will be associated to different contents (mcast groups), not to > different MNs, so the tunnel converge problem cannot appear. > > Thanks, > > Carlos > > On Thu, 2013-04-04 at 17:12 -0500, Behcet Sarikaya wrote: > > Hi Authors, > > > > From my previous review on Feb. 11, 2013: > > > > How do you avoid tunnel convergence problem if there are more than one > > MTMA? You have some hints in Appendix A.3, related to Fig. 8 but it is > > still not clear. Please explain it here in 3.1 > > > > We discussed this in Orlando, here are excerpts from the minutes: > > > > Behcet - But tunnel convergence is if mobile receives multiple copies > > of the same data > > > > JC - I am not sure I understand? > > > > Carlos - A single group will be linked to a single MTMA. So > cannot > > receive multiple copies in the mobile > > Please add a good explanation of how the tunnel convergence is avoided > > in the presence of multiple MTMAs in Section 3.1. > > > > Regards, > > > > Behcet > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > > > --001a11c38e9adcedf804da03908f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlos,

On Tue, Apr 9, 2013 at 8:08 PM= , Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es> wrote:
Hi Behcet,

We did modify the text in A.3 as a result of your comment before
Orlando. Did you check that version? is it still not clear?


The comment was to explain this important issue i= n the main text, e.g. Sec. 3.1.

That said, I am OK with Dirk's c= omments. That is going to resolve the issue.

Regards,

Behcet =
Basically, there may be more than one MTMA, but in this case each of
them will be associated to different contents (mcast groups), not to
different MNs, so the tunnel converge problem cannot appear.

Thanks,

Carlos

On Thu, 2013-04-04 at 17:12 -0500, Behcet Sarikaya wrote:
> Hi Authors,
>
> From my previous review on Feb. 11, 2013:
>
> How do you avoid tunnel convergence problem if there are more than one=
> MTMA? You have some hints in Appendix A.3, related to Fig. 8 but it is=
> still not clear. Please explain it here in 3.1
>
> We discussed this in Orlando, here are excerpts from the minutes:
>
> Behcet - But tunnel convergence is if mobile receives multiple copies<= br> > =A0 =A0 =A0 =A0 =A0 of the same data
>
> =A0 =A0 =A0 =A0 =A0 JC - I am not sure I understand?
>
> =A0 =A0 =A0 =A0 =A0 Carlos - A single group will be linked to a single= MTMA. =A0So cannot
> =A0 =A0 =A0 =A0 =A0 receive multiple copies in the mobile
> Please add a good explanation of how the tunnel convergence is avoided=
> in the presence of multiple MTMAs in Section 3.1.
>
> Regards,
>
> Behcet
> _______________________________________________
> multimob mailing list
> multimob@ietf.org
> https://www.ietf.org/mailman/listinfo/multimob



--001a11c38e9adcedf804da03908f-- From cjbc@it.uc3m.es Wed Apr 10 09:30:39 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C19B21F88B9 for ; Wed, 10 Apr 2013 09:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPQ+quNf5NiT for ; Wed, 10 Apr 2013 09:30:38 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9DA21F888B for ; Wed, 10 Apr 2013 09:30:38 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 371DFFA9960; Wed, 10 Apr 2013 18:30:36 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 1673EFA9896; Wed, 10 Apr 2013 18:30:36 +0200 (CEST) Message-ID: <1365611435.4348.45.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: sarikaya@ieee.org Date: Wed, 10 Apr 2013 18:30:35 +0200 In-Reply-To: References: <1365556115.4323.27.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19788.000 X-TM-AS-Result: No--21.793-7.0-31-1 X-imss-scan-details: No--21.793-7.0-31-1 Cc: multimob@ietf.org Subject: Re: [multimob] LC Comments on draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 16:30:39 -0000 Hi Behcet, OK, thanks. Carlos On Wed, 2013-04-10 at 10:45 -0500, Behcet Sarikaya wrote: > Hi Carlos, > > On Tue, Apr 9, 2013 at 8:08 PM, Carlos Jesús Bernardos Cano > wrote: > Hi Behcet, > > We did modify the text in A.3 as a result of your comment > before > Orlando. Did you check that version? is it still not clear? > > > The comment was to explain this important issue in the main text, e.g. > Sec. 3.1. > > That said, I am OK with Dirk's comments. That is going to resolve the > issue. > > Regards, > > Behcet > > Basically, there may be more than one MTMA, but in this case > each of > them will be associated to different contents (mcast groups), > not to > different MNs, so the tunnel converge problem cannot appear. > > Thanks, > > Carlos > > On Thu, 2013-04-04 at 17:12 -0500, Behcet Sarikaya wrote: > > Hi Authors, > > > > From my previous review on Feb. 11, 2013: > > > > How do you avoid tunnel convergence problem if there are > more than one > > MTMA? You have some hints in Appendix A.3, related to Fig. 8 > but it is > > still not clear. Please explain it here in 3.1 > > > > We discussed this in Orlando, here are excerpts from the > minutes: > > > > Behcet - But tunnel convergence is if mobile receives > multiple copies > > of the same data > > > > JC - I am not sure I understand? > > > > Carlos - A single group will be linked to a single > MTMA. So cannot > > receive multiple copies in the mobile > > Please add a good explanation of how the tunnel convergence > is avoided > > in the presence of multiple MTMAs in Section 3.1. > > > > Regards, > > > > Behcet > > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > > > From stig@venaas.com Wed Apr 10 10:50:17 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5629321F8EDE for ; Wed, 10 Apr 2013 10:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_ABOUTYOU=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfisCee9+KI9 for ; Wed, 10 Apr 2013 10:50:16 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 76DC521F8EB9 for ; Wed, 10 Apr 2013 10:50:16 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id 7BC5B801E for ; Wed, 10 Apr 2013 19:50:14 +0200 (CEST) Message-ID: <5165A5FF.1080805@venaas.com> Date: Wed, 10 Apr 2013 10:48:47 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: multimob@ietf.org References: <823234EF5C7C334998D973D822FF801B44F3B06C@EX10-MB2-MAD.hi.inet> In-Reply-To: <823234EF5C7C334998D973D822FF801B44F3B06C@EX10-MB2-MAD.hi.inet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 17:50:17 -0000 Hi I'm responding here with my personal view, and hopefully also the same as I was saying in the meeting. On 4/10/2013 12:49 AM, LUIS MIGUEL CONTRERAS MURILLO wrote: > Dear all, > > After the Orlando meeting discussions on the flag A mechanism described > in draft-ietf-multimob-handover-optimization-02 for mitigating the > internal signaling within the network in case of reactive handover, we > would like to consult WG members about your preference: > > Option 1.- To include the flag A mechanism as an integral (and > mandatory) part of the solution, as described in the draft today. > > Option 2.- To consider the flag A mechanism as an option to reduce > signaling in the core, then removing the reference to this mechanism > from the draft. The final document would consider that the LMA always > queries the pMAG by default, but mentioning that some mechanism > (out-of-scope) could be used to reduce this signaling (by avoiding to > query the pMAG). Wouldn't a 3rd option be to keep it in the draft, but not make the A flag mandatory to implement/enable? I think that may require additional work though, because you may need to know whether the A flag is being used. Basically you need to know that A flag not set, doesn't mean that there is no subscription when A-flag support isn't enabled. My concern is that the A-flag mechanism may not be worth the effort, or even worse, if clients often switch between having multicast subscriptions and not (basically that A is frequently often updated). If the A flag is mostly stable, then I think it is useful. So at least my thinking is that unless we know with some certainty what the usage pattern is, then it is better to make it optional. If we agree on making it optional, then the question is whether we still want it in this document (option 2 or 3). Hope we can get the input of several people in the group and try to figure out what the best option is. Stig > Thanks in advance, > > Best regards, > > Luis > > ________________________________ > > Luis M. Contreras > > Technology / Global CTO / Telefónica > > Efficiency Projects / Telefónica I+D > > Distrito Telefónica, Edificio Sur 3, Planta 3 > > 28050 Madrid > > España / Spain > > lmcm@tid.es > > > ------------------------------------------------------------------------ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra política de envío y recepción de correo electrónico en el enlace > situado más abajo. > This message is intended exclusively for its addressee. We only send and > receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From stig@venaas.com Fri Apr 19 11:36:26 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE58421F91BC for ; Fri, 19 Apr 2013 11:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.685 X-Spam-Level: X-Spam-Status: No, score=-99.685 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, GB_ABOUTYOU=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxG4PUj0Q7WR for ; Fri, 19 Apr 2013 11:36:26 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 00D7821F91BB for ; Fri, 19 Apr 2013 11:36:26 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id EA80A80C9 for ; Fri, 19 Apr 2013 20:36:23 +0200 (CEST) Message-ID: <51718E9F.7050708@venaas.com> Date: Fri, 19 Apr 2013 11:36:15 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: multimob@ietf.org References: <823234EF5C7C334998D973D822FF801B44F3B06C@EX10-MB2-MAD.hi.inet> <5165A5FF.1080805@venaas.com> In-Reply-To: <5165A5FF.1080805@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 18:36:26 -0000 It would be great to get input from more people in the WG on this issue. Stig On 4/10/2013 10:48 AM, Stig Venaas wrote: > Hi > > I'm responding here with my personal view, and hopefully also the same > as I was saying in the meeting. > > On 4/10/2013 12:49 AM, LUIS MIGUEL CONTRERAS MURILLO wrote: >> Dear all, >> >> After the Orlando meeting discussions on the flag A mechanism described >> in draft-ietf-multimob-handover-optimization-02 for mitigating the >> internal signaling within the network in case of reactive handover, we >> would like to consult WG members about your preference: >> >> Option 1.- To include the flag A mechanism as an integral (and >> mandatory) part of the solution, as described in the draft today. >> >> Option 2.- To consider the flag A mechanism as an option to reduce >> signaling in the core, then removing the reference to this mechanism >> from the draft. The final document would consider that the LMA always >> queries the pMAG by default, but mentioning that some mechanism >> (out-of-scope) could be used to reduce this signaling (by avoiding to >> query the pMAG). > > Wouldn't a 3rd option be to keep it in the draft, but not make the A > flag mandatory to implement/enable? I think that may require additional > work though, because you may need to know whether the A flag is being > used. Basically you need to know that A flag not set, doesn't mean that > there is no subscription when A-flag support isn't enabled. > > My concern is that the A-flag mechanism may not be worth the effort, or > even worse, if clients often switch between having multicast > subscriptions and not (basically that A is frequently often updated). > If the A flag is mostly stable, then I think it is useful. > > So at least my thinking is that unless we know with some certainty what > the usage pattern is, then it is better to make it optional. If we agree > on making it optional, then the question is whether we still want it in > this document (option 2 or 3). > > Hope we can get the input of several people in the group and try to > figure out what the best option is. > > Stig > >> Thanks in advance, >> >> Best regards, >> >> Luis >> >> ________________________________ >> >> Luis M. Contreras >> >> Technology / Global CTO / Telefónica >> >> Efficiency Projects / Telefónica I+D >> >> Distrito Telefónica, Edificio Sur 3, Planta 3 >> >> 28050 Madrid >> >> España / Spain >> >> lmcm@tid.es >> >> >> ------------------------------------------------------------------------ >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar >> nuestra política de envío y recepción de correo electrónico en el enlace >> situado más abajo. >> This message is intended exclusively for its addressee. We only send and >> receive email on the basis of the terms set out at: >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >> >> >> _______________________________________________ >> 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 Akbar.Rahman@InterDigital.com Fri Apr 19 12:35:58 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC76721F91CA for ; Fri, 19 Apr 2013 12:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_ABOUTYOU=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BocsUOqtpHMk for ; Fri, 19 Apr 2013 12:35:58 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3312A21F8614 for ; Fri, 19 Apr 2013 12:35:57 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Apr 2013 15:35:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Apr 2013 15:35:55 -0400 Message-ID: In-Reply-To: <51718E9F.7050708@venaas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization Thread-Index: Ac49LNDgLg2qkZvpQOe4oVy9HVI28wAB4pmA References: <823234EF5C7C334998D973D822FF801B44F3B06C@EX10-MB2-MAD.hi.inet><5165A5FF.1080805@venaas.com> <51718E9F.7050708@venaas.com> From: "Rahman, Akbar" To: "Stig Venaas" , X-OriginalArrivalTime: 19 Apr 2013 19:35:57.0217 (UTC) FILETIME=[1D29E910:01CE3D35] Subject: Re: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 19:35:59 -0000 Hi Stig/Carlos, I vote ofr Stig's proposal of making the flag A mechanism optional but = keeping it in the I-D (option 3). My only caveat would be if this = requires a lot of work on the part of the Authors to update the I-D as I = think we should wrap up this document sooner rather than later. If = Option 3 requires too much documentation effort then I vote for option = 2. Akbar -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On = Behalf Of Stig Venaas Sent: Friday, April 19, 2013 2:36 PM To: multimob@ietf.org Subject: Re: [multimob] WG Poll about the inclusion or not of flag A = mechanism in draft-ietf-multimob-handover-optimization It would be great to get input from more people in the WG on this issue. Stig On 4/10/2013 10:48 AM, Stig Venaas wrote: > Hi > > I'm responding here with my personal view, and hopefully also the same > as I was saying in the meeting. > > On 4/10/2013 12:49 AM, LUIS MIGUEL CONTRERAS MURILLO wrote: >> Dear all, >> >> After the Orlando meeting discussions on the flag A mechanism = described >> in draft-ietf-multimob-handover-optimization-02 for mitigating the >> internal signaling within the network in case of reactive handover, = we >> would like to consult WG members about your preference: >> >> Option 1.- To include the flag A mechanism as an integral (and >> mandatory) part of the solution, as described in the draft today. >> >> Option 2.- To consider the flag A mechanism as an option to reduce >> signaling in the core, then removing the reference to this mechanism >> from the draft. The final document would consider that the LMA always >> queries the pMAG by default, but mentioning that some mechanism >> (out-of-scope) could be used to reduce this signaling (by avoiding to >> query the pMAG). > > Wouldn't a 3rd option be to keep it in the draft, but not make the A > flag mandatory to implement/enable? I think that may require = additional > work though, because you may need to know whether the A flag is being > used. Basically you need to know that A flag not set, doesn't mean = that > there is no subscription when A-flag support isn't enabled. > > My concern is that the A-flag mechanism may not be worth the effort, = or > even worse, if clients often switch between having multicast > subscriptions and not (basically that A is frequently often updated). > If the A flag is mostly stable, then I think it is useful. > > So at least my thinking is that unless we know with some certainty = what > the usage pattern is, then it is better to make it optional. If we = agree > on making it optional, then the question is whether we still want it = in > this document (option 2 or 3). > > Hope we can get the input of several people in the group and try to > figure out what the best option is. > > Stig > >> Thanks in advance, >> >> Best regards, >> >> Luis >> >> ________________________________ >> >> Luis M. Contreras >> >> Technology / Global CTO / Telef=F3nica >> >> Efficiency Projects / Telef=F3nica I+D >> >> Distrito Telef=F3nica, Edificio Sur 3, Planta 3 >> >> 28050 Madrid >> >> Espa=F1a / Spain >> >> lmcm@tid.es >> >> >> = ------------------------------------------------------------------------ >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede = consultar >> nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico = en el enlace >> situado m=E1s abajo. >> This message is intended exclusively for its addressee. We only send = and >> receive email on the basis of the terms set out at: >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From sarikaya2012@gmail.com Fri Apr 19 13:44:34 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB7021F8EAA for ; Fri, 19 Apr 2013 13:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-0.893, BAYES_50=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrZRaeTDLKxH for ; Fri, 19 Apr 2013 13:44:33 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDFB21F8673 for ; Fri, 19 Apr 2013 13:44:32 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id t11so4099332lbi.39 for ; Fri, 19 Apr 2013 13:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bgWqtlkEH4vV0FUZXujxZs5/ekQIvRGXqILY8ELTyQM=; b=xpmuRYXPt/T1Fro1WVIr/TLCn+G/c6+68CJ4YsWyx7Vd7Oi56yKdJY/2vMUzpCekTR XYuGCCAj+ufP2kGQZ+tSNryslZEoS62qd720Yu0pIPbSzcWFg+mE/KvpGI0yBu9BCXCL noIwCrjmJeFz46+d0I4BBPnn1Z+oh3W2IxBimZAaX2z8dWJypir+GJ2cyV8kJUz/H/PV T0/4YD39DCyeoEIzSFGv7bcM1dQZuwVOsug8gTtFhGAaHGpperPxs3q4LhRdLpH8fBOl e/nSPffDFPAGZmYtD3h5q38JZlRxF7CR7t/uz9cqYb2ahIAIJCn7v/9+82aaMuA3y1sj RBkg== MIME-Version: 1.0 X-Received: by 10.112.146.98 with SMTP id tb2mr8758936lbb.77.1366404271426; Fri, 19 Apr 2013 13:44:31 -0700 (PDT) Received: by 10.114.175.140 with HTTP; Fri, 19 Apr 2013 13:44:31 -0700 (PDT) In-Reply-To: References: <823234EF5C7C334998D973D822FF801B44F3B06C@EX10-MB2-MAD.hi.inet> <5165A5FF.1080805@venaas.com> <51718E9F.7050708@venaas.com> Date: Fri, 19 Apr 2013 15:44:31 -0500 Message-ID: From: Behcet Sarikaya To: "Rahman, Akbar" Content-Type: multipart/alternative; boundary=047d7b3a85a837d1e604dabcc922 Cc: multimob@ietf.org Subject: Re: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 20:44:34 -0000 --047d7b3a85a837d1e604dabcc922 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Folks, This poll is not a WG poll. We have not decided on such a poll in Orlando, please check the minutes. We have 4 WG drafts and each draft has so many features/options. How would we cope with the situation if we had a poll on each? The author on his own has posted the mail with his own formulation of the questions. I repeat this is not a WG poll. My recommendation to WG is to review the WG drafts and help the authors improve the drafts. Regards, Behcet On Fri, Apr 19, 2013 at 2:35 PM, Rahman, Akbar < Akbar.Rahman@interdigital.com> wrote: > Hi Stig/Carlos, > > > I vote ofr Stig's proposal of making the flag A mechanism optional but > keeping it in the I-D (option 3). My only caveat would be if this requir= es > a lot of work on the part of the Authors to update the I-D as I think we > should wrap up this document sooner rather than later. If Option 3 > requires too much documentation effort then I vote for option 2. > > > > Akbar > > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Stig Venaas > Sent: Friday, April 19, 2013 2:36 PM > To: multimob@ietf.org > Subject: Re: [multimob] WG Poll about the inclusion or not of flag A > mechanism in draft-ietf-multimob-handover-optimization > > It would be great to get input from more people in the WG on this issue. > > Stig > > On 4/10/2013 10:48 AM, Stig Venaas wrote: > > Hi > > > > I'm responding here with my personal view, and hopefully also the same > > as I was saying in the meeting. > > > > On 4/10/2013 12:49 AM, LUIS MIGUEL CONTRERAS MURILLO wrote: > >> Dear all, > >> > >> After the Orlando meeting discussions on the flag A mechanism describe= d > >> in draft-ietf-multimob-handover-optimization-02 for mitigating the > >> internal signaling within the network in case of reactive handover, we > >> would like to consult WG members about your preference: > >> > >> Option 1.- To include the flag A mechanism as an integral (and > >> mandatory) part of the solution, as described in the draft today. > >> > >> Option 2.- To consider the flag A mechanism as an option to reduce > >> signaling in the core, then removing the reference to this mechanism > >> from the draft. The final document would consider that the LMA always > >> queries the pMAG by default, but mentioning that some mechanism > >> (out-of-scope) could be used to reduce this signaling (by avoiding to > >> query the pMAG). > > > > Wouldn't a 3rd option be to keep it in the draft, but not make the A > > flag mandatory to implement/enable? I think that may require additional > > work though, because you may need to know whether the A flag is being > > used. Basically you need to know that A flag not set, doesn't mean that > > there is no subscription when A-flag support isn't enabled. > > > > My concern is that the A-flag mechanism may not be worth the effort, or > > even worse, if clients often switch between having multicast > > subscriptions and not (basically that A is frequently often updated). > > If the A flag is mostly stable, then I think it is useful. > > > > So at least my thinking is that unless we know with some certainty what > > the usage pattern is, then it is better to make it optional. If we agre= e > > on making it optional, then the question is whether we still want it in > > this document (option 2 or 3). > > > > Hope we can get the input of several people in the group and try to > > figure out what the best option is. > > > > Stig > > > >> Thanks in advance, > >> > >> Best regards, > >> > >> Luis > >> > >> ________________________________ > >> > >> Luis M. Contreras > >> > >> Technology / Global CTO / Telef=F3nica > >> > >> Efficiency Projects / Telef=F3nica I+D > >> > >> Distrito Telef=F3nica, Edificio Sur 3, Planta 3 > >> > >> 28050 Madrid > >> > >> Espa=F1a / Spain > >> > >> lmcm@tid.es > >> > >> > >> ----------------------------------------------------------------------= -- > >> > >> Este mensaje se dirige exclusivamente a su destinatario. Puede consult= ar > >> nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en= el enlace > >> situado m=E1s abajo. > >> This message is intended exclusively for its addressee. We only send a= nd > >> receive email on the basis of the terms set out at: > >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx > >> > >> > >> _______________________________________________ > >> multimob mailing list > >> multimob@ietf.org > >> https://www.ietf.org/mailman/listinfo/multimob > >> > > > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > --047d7b3a85a837d1e604dabcc922 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Folks,

This poll is not a WG poll. We have not decided on such a pol= l in Orlando, please check the minutes.

We have 4 WG drafts and each= draft has so many features/options. How would we cope with the situation i= f we had a poll on each?

The author on his own has posted the mail with his own formulation of t= he questions. I repeat this is not a WG poll.

My recommendation to W= G is to review the WG drafts and help the authors improve the drafts.

Regards,

Behcet

On Fri, Apr 19= , 2013 at 2:35 PM, Rahman, Akbar <Akbar.Rahman@interdigital.co= m> wrote:
Hi Stig/Carlos,


I vote ofr Stig's proposal of making the flag A mechanism optional but = keeping it in the I-D (option 3). =A0My only caveat would be if this requir= es a lot of work on the part of the Authors to update the I-D as I think we= should wrap up this document sooner rather than later. =A0If Option 3 requ= ires too much documentation effort then I vote for option 2.



Akbar

-----Original Message-----
From: multimob-bounces@ietf.or= g [mailto:multimob-bounces= @ietf.org] On Behalf Of Stig Venaas
Sent: Friday, April 19, 2013 2:36 PM
To: multimob@ietf.org
Subject: Re: [multimob] WG Poll about the inclusion or not of flag A mechan= ism in draft-ietf-multimob-handover-optimization

It would be great to get input from more people in the WG on this issue.
Stig

On 4/10/2013 10:48 AM, Stig Venaas wrote:
> Hi
>
> I'm responding here with my personal view, and hopefully also the = same
> as I was saying in the meeting.
>
> On 4/10/2013 12:49 AM, LUIS MIGUEL CONTRERAS MURILLO wrote:
>> Dear all,
>>
>> After the Orlando meeting discussions on the flag A mechanism desc= ribed
>> in draft-ietf-multimob-handover-optimization-02 for mitigating the=
>> internal signaling within the network in case of reactive handover= , we
>> would like to consult WG members about your preference:
>>
>> Option 1.- To include the flag A mechanism as an integral (and
>> mandatory) part of the solution, as described in the draft today.<= br> >>
>> Option 2.- To consider the flag A mechanism as an option to reduce=
>> signaling in the core, then removing the reference to this mechani= sm
>> from the draft. The final document would consider that the LMA alw= ays
>> queries the pMAG by default, but mentioning that some mechanism >> (out-of-scope) could be used to reduce this signaling (by avoiding= to
>> query the pMAG).
>
> Wouldn't a 3rd option be to keep it in the draft, but not make the= A
> flag mandatory to implement/enable? I think that may require additiona= l
> work though, because you may need to know whether the A flag is being<= br> > used. Basically you need to know that A flag not set, doesn't mean= that
> there is no subscription when A-flag support isn't enabled.
>
> My concern is that the A-flag mechanism may not be worth the effort, o= r
> even worse, if clients often switch between having multicast
> subscriptions and not (basically that A is frequently often updated).<= br> > If the A flag is mostly stable, then I think it is useful.
>
> So at least my thinking is that unless we know with some certainty wha= t
> the usage pattern is, then it is better to make it optional. If we agr= ee
> on making it optional, then the question is whether we still want it i= n
> this document (option 2 or 3).
>
> Hope we can get the input of several people in the group and try to > figure out what the best option is.
>
> Stig
>
>> Thanks in advance,
>>
>> Best regards,
>>
>> Luis
>>
>> ________________________________
>>
>> Luis M. Contreras
>>
>> Technology / Global CTO / Telef=F3nica
>>
>> Efficiency Projects / Telef=F3nica I+D
>>
>> Distrito Telef=F3nica, Edificio Sur 3, Planta 3
>>
>> 28050 Madrid
>>
>> Espa=F1a / Spain
>>
>> lmcm@tid.es
>>
>>
>> ------------------------------------------------------------------= ------
>>
>> Este mensaje se dirige exclusivamente a su destinatario. Puede con= sultar
>> nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nic= o en el enlace
>> situado m=E1s abajo.
>> This message is intended exclusively for its addressee. We only se= nd and
>> receive email on the basis of the terms set out at:
>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>>
>>
>> _______________________________________________
>> multimob mailing list
>> multimob@ietf.org
>> https://www.ietf.org/mailman/listinfo/multimob
>>
>
> _______________________________________________
> multimob mailing list
> multimob@ietf.org
> https://www.ietf.org/mailman/listinfo/multimob

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

--047d7b3a85a837d1e604dabcc922-- From stig@venaas.com Fri Apr 19 15:33:46 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA30D21F8FED for ; Fri, 19 Apr 2013 15:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.892 X-Spam-Level: X-Spam-Status: No, score=-100.892 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, GB_ABOUTYOU=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uG68kcfjFhJG for ; Fri, 19 Apr 2013 15:33:46 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 9C99E21F8FE5 for ; Fri, 19 Apr 2013 15:33:45 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id D221781B3; Sat, 20 Apr 2013 00:33:43 +0200 (CEST) Message-ID: <5171C644.1050106@venaas.com> Date: Fri, 19 Apr 2013 15:33:40 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: sarikaya@ieee.org References: <823234EF5C7C334998D973D822FF801B44F3B06C@EX10-MB2-MAD.hi.inet> <5165A5FF.1080805@venaas.com> <51718E9F.7050708@venaas.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org, Behcet Sarikaya Subject: Re: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 22:33:47 -0000 On 4/19/2013 1:44 PM, Behcet Sarikaya wrote: > Folks, > > This poll is not a WG poll. We have not decided on such a poll in > Orlando, please check the minutes. I guess WG Poll is not the right title. It's not a formal poll. It's just the author trying to get input from the WG. > We have 4 WG drafts and each draft has so many features/options. How > would we cope with the situation if we had a poll on each? > > The author on his own has posted the mail with his own formulation of > the questions. I repeat this is not a WG poll. > > My recommendation to WG is to review the WG drafts and help the authors > improve the drafts. Right, and as part of this, we need to provide our views on this important issue, so that we have a draft reflecting the WGs opinions. I think this was the main outstanding issue from our discussion in Orlando. Stig > Regards, > > Behcet > > On Fri, Apr 19, 2013 at 2:35 PM, Rahman, Akbar > > > wrote: > > Hi Stig/Carlos, > > > I vote ofr Stig's proposal of making the flag A mechanism optional > but keeping it in the I-D (option 3). My only caveat would be if > this requires a lot of work on the part of the Authors to update the > I-D as I think we should wrap up this document sooner rather than > later. If Option 3 requires too much documentation effort then I > vote for option 2. > > > > Akbar > > -----Original Message----- > From: multimob-bounces@ietf.org > [mailto:multimob-bounces@ietf.org > ] On Behalf Of Stig Venaas > Sent: Friday, April 19, 2013 2:36 PM > To: multimob@ietf.org > Subject: Re: [multimob] WG Poll about the inclusion or not of flag A > mechanism in draft-ietf-multimob-handover-optimization > > It would be great to get input from more people in the WG on this issue. > > Stig > > On 4/10/2013 10:48 AM, Stig Venaas wrote: > > Hi > > > > I'm responding here with my personal view, and hopefully also the > same > > as I was saying in the meeting. > > > > On 4/10/2013 12:49 AM, LUIS MIGUEL CONTRERAS MURILLO wrote: > >> Dear all, > >> > >> After the Orlando meeting discussions on the flag A mechanism > described > >> in draft-ietf-multimob-handover-optimization-02 for mitigating the > >> internal signaling within the network in case of reactive > handover, we > >> would like to consult WG members about your preference: > >> > >> Option 1.- To include the flag A mechanism as an integral (and > >> mandatory) part of the solution, as described in the draft today. > >> > >> Option 2.- To consider the flag A mechanism as an option to reduce > >> signaling in the core, then removing the reference to this mechanism > >> from the draft. The final document would consider that the LMA > always > >> queries the pMAG by default, but mentioning that some mechanism > >> (out-of-scope) could be used to reduce this signaling (by > avoiding to > >> query the pMAG). > > > > Wouldn't a 3rd option be to keep it in the draft, but not make the A > > flag mandatory to implement/enable? I think that may require > additional > > work though, because you may need to know whether the A flag is being > > used. Basically you need to know that A flag not set, doesn't > mean that > > there is no subscription when A-flag support isn't enabled. > > > > My concern is that the A-flag mechanism may not be worth the > effort, or > > even worse, if clients often switch between having multicast > > subscriptions and not (basically that A is frequently often updated). > > If the A flag is mostly stable, then I think it is useful. > > > > So at least my thinking is that unless we know with some > certainty what > > the usage pattern is, then it is better to make it optional. If > we agree > > on making it optional, then the question is whether we still want > it in > > this document (option 2 or 3). > > > > Hope we can get the input of several people in the group and try to > > figure out what the best option is. > > > > Stig > > > >> Thanks in advance, > >> > >> Best regards, > >> > >> Luis > >> > >> ________________________________ > >> > >> Luis M. Contreras > >> > >> Technology / Global CTO / Telefónica > >> > >> Efficiency Projects / Telefónica I+D > >> > >> Distrito Telefónica, Edificio Sur 3, Planta 3 > >> > >> 28050 Madrid > >> > >> España / Spain > >> > >> lmcm@tid.es > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> Este mensaje se dirige exclusivamente a su destinatario. Puede > consultar > >> nuestra política de envío y recepción de correo electrónico en > el enlace > >> situado más abajo. > >> This message is intended exclusively for its addressee. We only > send and > >> receive email on the basis of the terms set out at: > >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx > >> > >> > >> _______________________________________________ > >> multimob mailing list > >> multimob@ietf.org > >> https://www.ietf.org/mailman/listinfo/multimob > >> > > > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ > 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 lmcm@tid.es Sat Apr 20 03:18:44 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241ED21F8EB5 for ; Sat, 20 Apr 2013 03:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WRZa1bIRaaK for ; Sat, 20 Apr 2013 03:18:43 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id A810B21F8E96 for ; Sat, 20 Apr 2013 03:18:40 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MLJ00JE4TZ0XE@tid.hi.inet> for multimob@ietf.org; Sat, 20 Apr 2013 12:18:36 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id E8.73.01293.E7B62715; Sat, 20 Apr 2013 12:18:38 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MLJ00JDWTZ0XE@tid.hi.inet> for multimob@ietf.org; Sat, 20 Apr 2013 12:18:36 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Sat, 20 Apr 2013 12:18:30 +0200 Date: Sat, 20 Apr 2013 10:18:38 +0000 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: <5171C644.1050106@venaas.com> X-Originating-IP: [10.95.64.115] To: Stig Venaas , "sarikaya@ieee.org" Message-id: <823234EF5C7C334998D973D822FF801B44F45253@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: es-ES Content-transfer-encoding: quoted-printable Accept-Language: es-ES, en-US Thread-topic: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization Thread-index: AQHOPT61hB/NVrxtxU2MxfZKpZStWJjd/9wAgADmNQA= X-AuditID: 0a5f4068-b7f006d00000050d-c4-51726b7e0cf7 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsXCFe/ApVuXXRRo8PSfjsWMj30sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKWDKrkalgmW3FmbY3LA2M23S7GNk5JARMJL6mdDFyAlliEhfu rWfrYuTiEBLYyCjRvO0FI0hCSOA3o8TEf2YQiWmMEr8eHmHpYuTgYBFQlbi3pQ6khk3AUGLW zkmsILawQK3EkbnH2EBsTgEtiT33v7FDLFCQ+HPuMQuILSLgJXHv8mqwemaBcInt3/rB6nkF vCXmvd3GCGELSvyYfI8FokZHovf7N2YIW1xizq+JUL3aEk/eXQCzGQVkJVaeP80IMb9OYu2B R1C2lcSZFQfZIG4QkFiy5zwzhC0q8fLxP1aIvzYxSaxY8Z9xAqP4LCS7ZyHZPQvJ7llIdi9g ZFnFKFacVJSZnlGSm5iZk25gqJeRqZeZl1qyiRESQxk7GJfvVDnEKMDBqMTDeyMiL1CINbGs uDL3EKMEB7OSCK9KVFGgEG9KYmVValF+fFFpTmrxIUYmDk6pBsbmlgjhYL1DHMsZnNlZxE9k zHe4KMKTLRuWuecv19uzXV3ydhtYE/2lRbVNHewDmnavOjR9YtbUt+IPjv2Qcrp94HhB+IHt gSuvvD5x93/0rDt2hvebb3NN/Hv7uojHxscX597zmn9RXovFaqO48PzSF5e+WOe9bKlf/szW S4+3cOnJM5Kyt5OUWIozEg21mIuKEwFt/zNqfwIAAA== References: <823234EF5C7C334998D973D822FF801B44F3B06C@EX10-MB2-MAD.hi.inet> <5165A5FF.1080805@venaas.com> <51718E9F.7050708@venaas.com> <5171C644.1050106@venaas.com> Cc: "multimob@ietf.org" , Behcet Sarikaya Subject: Re: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 10:18:44 -0000 Hi Behcet, Stig, Indeed the aim was just to collect feedback, as editors of the document, fr= om the WG in order to progress the draft. This is not a minor discussion be= cause the impact on the document is relevant. It was my fault to choose wrong wording for the mail subject. Sorry for tha= t. Best regards, Luis -----Mensaje original----- De: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] En nombre = de Stig Venaas Enviado el: s=E1bado, 20 de abril de 2013 0:34 Para: sarikaya@ieee.org CC: multimob@ietf.org; Behcet Sarikaya Asunto: Re: [multimob] WG Poll about the inclusion or not of flag A mechani= sm in draft-ietf-multimob-handover-optimization On 4/19/2013 1:44 PM, Behcet Sarikaya wrote: > Folks, > > This poll is not a WG poll. We have not decided on such a poll in > Orlando, please check the minutes. I guess WG Poll is not the right title. It's not a formal poll. It's just t= he author trying to get input from the WG. > We have 4 WG drafts and each draft has so many features/options. How > would we cope with the situation if we had a poll on each? > > The author on his own has posted the mail with his own formulation of > the questions. I repeat this is not a WG poll. > > My recommendation to WG is to review the WG drafts and help the > authors improve the drafts. Right, and as part of this, we need to provide our views on this important = issue, so that we have a draft reflecting the WGs opinions. I think this was the main outstanding issue from our discussion in Orlando. Stig > Regards, > > Behcet > > On Fri, Apr 19, 2013 at 2:35 PM, Rahman, Akbar > > > wrote: > > Hi Stig/Carlos, > > > I vote ofr Stig's proposal of making the flag A mechanism optional > but keeping it in the I-D (option 3). My only caveat would be if > this requires a lot of work on the part of the Authors to update the > I-D as I think we should wrap up this document sooner rather than > later. If Option 3 requires too much documentation effort then I > vote for option 2. > > > > Akbar > > -----Original Message----- > From: multimob-bounces@ietf.org > [mailto:multimob-bounces@ietf.org > ] On Behalf Of Stig Venaas > Sent: Friday, April 19, 2013 2:36 PM > To: multimob@ietf.org > Subject: Re: [multimob] WG Poll about the inclusion or not of flag A > mechanism in draft-ietf-multimob-handover-optimization > > It would be great to get input from more people in the WG on this iss= ue. > > Stig > > On 4/10/2013 10:48 AM, Stig Venaas wrote: > > Hi > > > > I'm responding here with my personal view, and hopefully also the > same > > as I was saying in the meeting. > > > > On 4/10/2013 12:49 AM, LUIS MIGUEL CONTRERAS MURILLO wrote: > >> Dear all, > >> > >> After the Orlando meeting discussions on the flag A mechanism > described > >> in draft-ietf-multimob-handover-optimization-02 for mitigating th= e > >> internal signaling within the network in case of reactive > handover, we > >> would like to consult WG members about your preference: > >> > >> Option 1.- To include the flag A mechanism as an integral (and > >> mandatory) part of the solution, as described in the draft today. > >> > >> Option 2.- To consider the flag A mechanism as an option to reduc= e > >> signaling in the core, then removing the reference to this mechan= ism > >> from the draft. The final document would consider that the LMA > always > >> queries the pMAG by default, but mentioning that some mechanism > >> (out-of-scope) could be used to reduce this signaling (by > avoiding to > >> query the pMAG). > > > > Wouldn't a 3rd option be to keep it in the draft, but not make the= A > > flag mandatory to implement/enable? I think that may require > additional > > work though, because you may need to know whether the A flag is be= ing > > used. Basically you need to know that A flag not set, doesn't > mean that > > there is no subscription when A-flag support isn't enabled. > > > > My concern is that the A-flag mechanism may not be worth the > effort, or > > even worse, if clients often switch between having multicast > > subscriptions and not (basically that A is frequently often update= d). > > If the A flag is mostly stable, then I think it is useful. > > > > So at least my thinking is that unless we know with some > certainty what > > the usage pattern is, then it is better to make it optional. If > we agree > > on making it optional, then the question is whether we still want > it in > > this document (option 2 or 3). > > > > Hope we can get the input of several people in the group and try t= o > > figure out what the best option is. > > > > Stig > > > >> Thanks in advance, > >> > >> Best regards, > >> > >> Luis > >> > >> ________________________________ > >> > >> Luis M. Contreras > >> > >> Technology / Global CTO / Telef=F3nica > >> > >> Efficiency Projects / Telef=F3nica I+D > >> > >> Distrito Telef=F3nica, Edificio Sur 3, Planta 3 > >> > >> 28050 Madrid > >> > >> Espa=F1a / Spain > >> > >> lmcm@tid.es > >> > >> > >> > ---------------------------------------------------------------------= --- > >> > >> Este mensaje se dirige exclusivamente a su destinatario. Puede > consultar > >> nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3ni= co en > el enlace > >> situado m=E1s abajo. > >> This message is intended exclusively for its addressee. We only > send and > >> receive email on the basis of the terms set out at: > >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx > >> > >> > >> _______________________________________________ > >> multimob mailing list > >> multimob@ietf.org > >> https://www.ietf.org/mailman/listinfo/multimob > >> > > > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From lmcm@tid.es Sat Apr 20 03:20:38 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A0321F8D2C for ; Sat, 20 Apr 2013 03:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLZAV9R6ymB7 for ; Sat, 20 Apr 2013 03:20:37 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92A9B21F8E96 for ; Sat, 20 Apr 2013 03:20:36 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MLJ00JWMU23XE@tid.hi.inet> for multimob@ietf.org; Sat, 20 Apr 2013 12:20:27 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id CB.73.01293.DEB62715; Sat, 20 Apr 2013 12:20:29 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MLJ00JWIU23XE@tid.hi.inet> for multimob@ietf.org; Sat, 20 Apr 2013 12:20:27 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Sat, 20 Apr 2013 12:20:21 +0200 Date: Sat, 20 Apr 2013 10:20:28 +0000 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: <5165A5FF.1080805@venaas.com> X-Originating-IP: [10.95.64.115] To: Stig Venaas , "multimob@ietf.org" Message-id: <823234EF5C7C334998D973D822FF801B44F45263@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: es-ES Content-transfer-encoding: quoted-printable Accept-Language: es-ES, en-US Thread-topic: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization Thread-index: Ac41v9OZ+4IIQcIETzu6AFg3ZJE8RgAQw+aAAetl6hA= X-AuditID: 0a5f4068-b7f006d00000050d-db-51726bed60c4 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsXCFe/Apfs2uyjQoOkVh8WMj30sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKaF3cwlSwTaNiwfenzA2MzxW6GDk5JARMJC68+8oEYYtJXLi3 nq2LkYtDSGAjo8TD2+vYIZzfjBLXL11lhnCmMUr8PNLOAtLCIqAqcXPidWYQm03AUGLWzkms ILawQK3EkbnH2EBsTgEtiS2LfkKtUJD4c+4xWK+IgJfEohcnwWp4BbwlVk+4xAphC0r8mHwP rIZZQEei9/s3ZghbXGLOr4msELa2xJN3F8BsRgFZiZXnTzNCzKyTWHvgEZRtJfHp+VY2iL0C Ekv2nGeGsEUlXj7+B9YrJJAtcXbJMZYJjGKzkKyehWT1LCSrZyFZvYCRZRWjWHFSUWZ6Rklu YmZOuoGhXkamXmZeaskmRkjEZOxgXL5T5RCjAAejEg/vjYi8QCHWxLLiytxDjBIczEoivCpR RYFCvCmJlVWpRfnxRaU5qcWHGJk4OKUaGEWUfkYYffit2l0jLNYWvzj4+fo0NXaBok3zSt2s 1dTSU8Xsj/7bHa9c/vZAp4fDyld9K/devvONy/2tRLj7Ffsr8h/Vd3D5x93P4T2y7f/cZ/dO WV8WXSLwn9+q/1XIirkaGhJzNTa82S4hVrp9n8xVYaepf2dG7VuzqKJK9Ngjx/yAW+JrHJRY ijMSDbWYi4oTAYyuIcF2AgAA References: <823234EF5C7C334998D973D822FF801B44F3B06C@EX10-MB2-MAD.hi.inet> <5165A5FF.1080805@venaas.com> Subject: Re: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 10:20:38 -0000 Hi Stig, Thanks for raising this third possibility for discussion. With the two opti= ons that I described on my mail we were trying to reflect the feedback we r= eceived in some of the comments on the mail list and during the meeting. Th= e objective of the second one is to simplify the draft, reducing the comple= xity of the proposal while, at the same time, opening the door to potential= optimizations that could be later specified (at the cost of more complexit= y). In this way, removing the flag A mechanism procedures from the draft does n= ot prevent the possibility of further improvements that could be documented= separately, decoupling the main handover optimization solution documented = in the draft from future improvements (a text can be included to highlight = that specific mechanisms could be developed in the future for improving the= efficiency of the solution). We as editors are ok in considering your proposed option 3 and working on t= hat if finally it is the option preferred by the WG. However, our feeling i= s that including the optional mechanism in the document will increase the c= omplexity of the solution. If the decision is to make optional the flag A m= echanism, our personal opinion is that it would be better to remove it from= the main text. Thanks for your positive contribution, Best regards, Luis -----Mensaje original----- De: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] En nombre = de Stig Venaas Enviado el: mi=E9rcoles, 10 de abril de 2013 19:49 Para: multimob@ietf.org Asunto: Re: [multimob] WG Poll about the inclusion or not of flag A mechani= sm in draft-ietf-multimob-handover-optimization Hi I'm responding here with my personal view, and hopefully also the same as I= was saying in the meeting. On 4/10/2013 12:49 AM, LUIS MIGUEL CONTRERAS MURILLO wrote: > Dear all, > > After the Orlando meeting discussions on the flag A mechanism > described in draft-ietf-multimob-handover-optimization-02 for > mitigating the internal signaling within the network in case of > reactive handover, we would like to consult WG members about your prefere= nce: > > Option 1.- To include the flag A mechanism as an integral (and > mandatory) part of the solution, as described in the draft today. > > Option 2.- To consider the flag A mechanism as an option to reduce > signaling in the core, then removing the reference to this mechanism > from the draft. The final document would consider that the LMA always > queries the pMAG by default, but mentioning that some mechanism > (out-of-scope) could be used to reduce this signaling (by avoiding to > query the pMAG). Wouldn't a 3rd option be to keep it in the draft, but not make the A flag m= andatory to implement/enable? I think that may require additional work thou= gh, because you may need to know whether the A flag is being used. Basicall= y you need to know that A flag not set, doesn't mean that there is no subsc= ription when A-flag support isn't enabled. My concern is that the A-flag mechanism may not be worth the effort, or eve= n worse, if clients often switch between having multicast subscriptions and= not (basically that A is frequently often updated). If the A flag is mostly stable, then I think it is useful. So at least my thinking is that unless we know with some certainty what the= usage pattern is, then it is better to make it optional. If we agree on ma= king it optional, then the question is whether we still want it in this doc= ument (option 2 or 3). Hope we can get the input of several people in the group and try to figure = out what the best option is. Stig > Thanks in advance, > > Best regards, > > Luis > > ________________________________ > > Luis M. Contreras > > Technology / Global CTO / Telef=F3nica > > Efficiency Projects / Telef=F3nica I+D > > Distrito Telef=F3nica, Edificio Sur 3, Planta 3 > > 28050 Madrid > > Espa=F1a / Spain > > lmcm@tid.es > > > ---------------------------------------------------------------------- > -- > > Este mensaje se dirige exclusivamente a su destinatario. Puede > consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3= nico > en el enlace situado m=E1s abajo. > This message is intended exclusively for its addressee. We only send > and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > > _______________________________________________ > 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 ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From lmcm@tid.es Sat Apr 20 03:26:42 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DFD21F8EFC for ; Sat, 20 Apr 2013 03:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJoOw8coH7uA for ; Sat, 20 Apr 2013 03:26:41 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5257721F8DD4 for ; Sat, 20 Apr 2013 03:26:40 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MLJ006J7UCCCS@tid.hi.inet> for multimob@ietf.org; Sat, 20 Apr 2013 12:26:36 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id E8.35.02845.A5D62715; Sat, 20 Apr 2013 12:26:34 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MLJ006IVUCBCS@tid.hi.inet> for multimob@ietf.org; Sat, 20 Apr 2013 12:26:35 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Sat, 20 Apr 2013 12:26:25 +0200 Date: Sat, 20 Apr 2013 10:26:32 +0000 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: X-Originating-IP: [10.95.64.115] To: "Rahman, Akbar" Message-id: <823234EF5C7C334998D973D822FF801B44F45281@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: es-ES Content-transfer-encoding: quoted-printable Accept-Language: es-ES, en-US Thread-topic: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization Thread-index: AQHOPTUgOmde2k9KKU6He1sgWAJzYZje51HA X-AuditID: 0a5f4e69-b7fb26d000000b1d-43-51726d5a2281 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsXCFe9nqBuVWxRoMKORz2LGxz4WB0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlzNpzlbXgnFbFivmfWBsY7yh1MXJySAiYSHQf380EYYtJXLi3 nq2LkYtDSGA7o8TOqQuZIJw/jBIPfp1jh3CmMUp8eH6HHaSFRUBVYsYRiHY2AUOJWTsnsXYx cnAIC9RKtG/0AAlzCvhIvFu2kxFig4LEn3OPWUBsEQFjiT8dC9hAbGYBbYlp/xYxg9i8At4S b/umM0LYghI/Jt9jgajRkej9/o0ZwhaXmPNrIitM75N3F8BsRgFZiZXnTzNCzK+T+Ld7ChPI OSICRhIX5xVAnCAgsWTPeWYIW1Ti5eN/rBBvnWaUWPhrGdsERvFZSFbPQrJ6FpLVs5CsXsDI sopRrDipKDM9oyQ3MTMn3cBILyNTLzMvtWQTIySOMncwLt+pcohRgINRiYf3RkReoBBrYllx Ze4hRgkOZiURXpWookAh3pTEyqrUovz4otKc1OJDjEwcnFINjFv+cmSlCyYf+TFhw8eXfzZN juzg7vgZ4VY3b1qL/VRfu6kbexOKNz0tP/NxZmeNivSh/EMXfa1WdEvMOnSF53zDhMfad5XO Z2txVf3uN/n9d3Lqd50b2y+yXvrz7fjs+umzd73p+td9PPhM8tVtFZlPz6c2auX7/LRYnzL9 cEzLjZnv3nxe8pNNiaU4I9FQi7moOBEA7m6Nv4ECAAA= References: <823234EF5C7C334998D973D822FF801B44F3B06C@EX10-MB2-MAD.hi.inet> <5165A5FF.1080805@venaas.com> <51718E9F.7050708@venaas.com> Cc: "multimob@ietf.org" Subject: Re: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 10:26:42 -0000 Thanks Akbar for your feedback. As I mentioned in a recent mail, our opinion is that option 3 would make th= e draft more complex. Probably would be better to simplify the draft to the= basic handover optimization solution opening the door to further optional = improvements (like the flag A mechanism) that could be analyzed and documen= ted separately. Let's see what others think about it. Best regards, Luis -----Mensaje original----- De: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] En nombre = de Rahman, Akbar Enviado el: viernes, 19 de abril de 2013 21:36 Para: Stig Venaas; multimob@ietf.org Asunto: Re: [multimob] WG Poll about the inclusion or not of flag A mechani= sm in draft-ietf-multimob-handover-optimization Hi Stig/Carlos, I vote ofr Stig's proposal of making the flag A mechanism optional but keep= ing it in the I-D (option 3). My only caveat would be if this requires a l= ot of work on the part of the Authors to update the I-D as I think we shoul= d wrap up this document sooner rather than later. If Option 3 requires too= much documentation effort then I vote for option 2. Akbar -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behal= f Of Stig Venaas Sent: Friday, April 19, 2013 2:36 PM To: multimob@ietf.org Subject: Re: [multimob] WG Poll about the inclusion or not of flag A mechan= ism in draft-ietf-multimob-handover-optimization It would be great to get input from more people in the WG on this issue. Stig On 4/10/2013 10:48 AM, Stig Venaas wrote: > Hi > > I'm responding here with my personal view, and hopefully also the same > as I was saying in the meeting. > > On 4/10/2013 12:49 AM, LUIS MIGUEL CONTRERAS MURILLO wrote: >> Dear all, >> >> After the Orlando meeting discussions on the flag A mechanism >> described in draft-ietf-multimob-handover-optimization-02 for >> mitigating the internal signaling within the network in case of >> reactive handover, we would like to consult WG members about your prefer= ence: >> >> Option 1.- To include the flag A mechanism as an integral (and >> mandatory) part of the solution, as described in the draft today. >> >> Option 2.- To consider the flag A mechanism as an option to reduce >> signaling in the core, then removing the reference to this mechanism >> from the draft. The final document would consider that the LMA always >> queries the pMAG by default, but mentioning that some mechanism >> (out-of-scope) could be used to reduce this signaling (by avoiding to >> query the pMAG). > > Wouldn't a 3rd option be to keep it in the draft, but not make the A > flag mandatory to implement/enable? I think that may require > additional work though, because you may need to know whether the A > flag is being used. Basically you need to know that A flag not set, > doesn't mean that there is no subscription when A-flag support isn't enab= led. > > My concern is that the A-flag mechanism may not be worth the effort, > or even worse, if clients often switch between having multicast > subscriptions and not (basically that A is frequently often updated). > If the A flag is mostly stable, then I think it is useful. > > So at least my thinking is that unless we know with some certainty > what the usage pattern is, then it is better to make it optional. If > we agree on making it optional, then the question is whether we still > want it in this document (option 2 or 3). > > Hope we can get the input of several people in the group and try to > figure out what the best option is. > > Stig > >> Thanks in advance, >> >> Best regards, >> >> Luis >> >> ________________________________ >> >> Luis M. Contreras >> >> Technology / Global CTO / Telef=F3nica >> >> Efficiency Projects / Telef=F3nica I+D >> >> Distrito Telef=F3nica, Edificio Sur 3, Planta 3 >> >> 28050 Madrid >> >> Espa=F1a / Spain >> >> lmcm@tid.es >> >> >> --------------------------------------------------------------------- >> --- >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede >> consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr= =F3nico >> en el enlace situado m=E1s abajo. >> This message is intended exclusively for its addressee. We only send >> and receive email on the basis of the terms set out at: >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From stig@venaas.com Mon Apr 22 11:17:18 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8967821F90FC for ; Mon, 22 Apr 2013 11:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.496 X-Spam-Level: X-Spam-Status: No, score=-101.496 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, GB_ABOUTYOU=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AciZOf-dRYHj for ; Mon, 22 Apr 2013 11:17:16 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 46B9921F8F6E for ; Mon, 22 Apr 2013 11:17:15 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id BE4D38038; Mon, 22 Apr 2013 20:17:09 +0200 (CEST) Message-ID: <51757E94.3020506@venaas.com> Date: Mon, 22 Apr 2013 11:16:52 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: LUIS MIGUEL CONTRERAS MURILLO References: <823234EF5C7C334998D973D822FF801B44F3B06C@EX10-MB2-MAD.hi.inet> <5165A5FF.1080805@venaas.com> <823234EF5C7C334998D973D822FF801B44F45263@EX10-MB2-MAD.hi.inet> In-Reply-To: <823234EF5C7C334998D973D822FF801B44F45263@EX10-MB2-MAD.hi.inet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "multimob@ietf.org" Subject: Re: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 18:17:18 -0000 Hi On 4/20/2013 3:20 AM, LUIS MIGUEL CONTRERAS MURILLO wrote: > Hi Stig, > Thanks for raising this third possibility for discussion. With the two options that I described on my mail we were trying to reflect the feedback we received in some of the comments on the mail list and during the meeting. The objective of the second one is to simplify the draft, reducing the complexity of the proposal while, at the same time, opening the door to potential optimizations that could be later specified (at the cost of more complexity). > > In this way, removing the flag A mechanism procedures from the draft does not prevent the possibility of further improvements that could be documented separately, decoupling the main handover optimization solution documented in the draft from future improvements (a text can be included to highlight that specific mechanisms could be developed in the future for improving the efficiency of the solution). > > We as editors are ok in considering your proposed option 3 and working on that if finally it is the option preferred by the WG. However, our feeling is that including the optional mechanism in the document will increase the complexity of the solution. If the decision is to make optional the flag A mechanism, our personal opinion is that it would be better to remove it from the main text. Yes, I think it would add complexity too. So I think I favor option 2 myself. But not opposed to 3 either. Basically option 2 would simplify the draft while still offering a good solution, while option 3 would make it more complex. Stig > Thanks for your positive contribution, > Best regards, > Luis > > -----Mensaje original----- > De: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] En nombre de Stig Venaas > Enviado el: miércoles, 10 de abril de 2013 19:49 > Para: multimob@ietf.org > Asunto: Re: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization > > Hi > > I'm responding here with my personal view, and hopefully also the same as I was saying in the meeting. > > On 4/10/2013 12:49 AM, LUIS MIGUEL CONTRERAS MURILLO wrote: >> Dear all, >> >> After the Orlando meeting discussions on the flag A mechanism >> described in draft-ietf-multimob-handover-optimization-02 for >> mitigating the internal signaling within the network in case of >> reactive handover, we would like to consult WG members about your preference: >> >> Option 1.- To include the flag A mechanism as an integral (and >> mandatory) part of the solution, as described in the draft today. >> >> Option 2.- To consider the flag A mechanism as an option to reduce >> signaling in the core, then removing the reference to this mechanism >> from the draft. The final document would consider that the LMA always >> queries the pMAG by default, but mentioning that some mechanism >> (out-of-scope) could be used to reduce this signaling (by avoiding to >> query the pMAG). > > Wouldn't a 3rd option be to keep it in the draft, but not make the A flag mandatory to implement/enable? I think that may require additional work though, because you may need to know whether the A flag is being used. Basically you need to know that A flag not set, doesn't mean that there is no subscription when A-flag support isn't enabled. > > My concern is that the A-flag mechanism may not be worth the effort, or even worse, if clients often switch between having multicast subscriptions and not (basically that A is frequently often updated). > If the A flag is mostly stable, then I think it is useful. > > So at least my thinking is that unless we know with some certainty what the usage pattern is, then it is better to make it optional. If we agree on making it optional, then the question is whether we still want it in this document (option 2 or 3). > > Hope we can get the input of several people in the group and try to figure out what the best option is. > > Stig > >> Thanks in advance, >> >> Best regards, >> >> Luis >> >> ________________________________ >> >> Luis M. Contreras >> >> Technology / Global CTO / Telefónica >> >> Efficiency Projects / Telefónica I+D >> >> Distrito Telefónica, Edificio Sur 3, Planta 3 >> >> 28050 Madrid >> >> España / Spain >> >> lmcm@tid.es >> >> >> ---------------------------------------------------------------------- >> -- >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede >> consultar nuestra política de envío y recepción de correo electrónico >> en el enlace situado más abajo. >> This message is intended exclusively for its addressee. We only send >> and receive email on the basis of the terms set out at: >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >> >> >> _______________________________________________ >> 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 > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. > This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > From johnsonhammond1@hushmail.com Sat Apr 27 18:18:09 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4132B21F97BE for ; Sat, 27 Apr 2013 18:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8l06Hl3rtWT for ; Sat, 27 Apr 2013 18:18:08 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2F521F97B8 for ; Sat, 27 Apr 2013 18:18:08 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id C437A30916 for ; Sat, 27 Apr 2013 17:36:07 +0000 (UTC) X-hush-relay-time: 213 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:36:07 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 433FEE6739; Sat, 27 Apr 2013 17:36:07 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:36:07 -0400 To: multimob@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427173607.433FEE6739@smtp.hushmail.com> Subject: [multimob] Biggest Fake Conference in Computer Science X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 01:18:09 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.