From sarikaya2012@gmail.com Thu Feb 7 08:59:15 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 C82D621F87D7 for ; Thu, 7 Feb 2013 08:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vb9MfwIM0Q1A for ; Thu, 7 Feb 2013 08:59:15 -0800 (PST) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id D707D21F84C0 for ; Thu, 7 Feb 2013 08:59:14 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id gf7so2256195lbb.4 for ; Thu, 07 Feb 2013 08:59:05 -0800 (PST) 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=GasKWSU70pJEr+u/eB7lWiSHHOhkEJv9+ggpCXJmIFk=; b=CSaYkUw+5c+EI96DD9BHBnBuQBpaYDvTrZQrqgMJfNXGpyy/kxJPhZhHbS3+vYDEuC j98dbCww7XNdlqWiID514QRQOIZPNSiOXK080i2lvcI9JgUiyynpXPgsiXXnhBz+MLh8 +nTs0kmUhkBZBNKne+54tViCtFaeaOULCpavMG2Xxo8LVsOFA7FHWnvDHbqXQUACUWvF MnCmJe/KlI+VgVy+KwhMrTW24asDiAPoj/ogad5qTWeqoLdEyLBe3iEwvSruNPp0t5sg Nw9G/ZNU+graelGOJ6Y4ys5j/qzxiBKbjX/7MKkLaV0rLnA728NBdSHPZgmSyylwE/9N Nwjg== MIME-Version: 1.0 X-Received: by 10.112.28.102 with SMTP id a6mr1014210lbh.109.1360256345541; Thu, 07 Feb 2013 08:59:05 -0800 (PST) Received: by 10.114.28.168 with HTTP; Thu, 7 Feb 2013 08:59:05 -0800 (PST) Date: Thu, 7 Feb 2013 10:59:05 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: multipart/alternative; boundary=f46d040168b3478b6204d5255cf4 Subject: [multimob] IETF 86 Draft Cut-off Dates 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, 07 Feb 2013 16:59:16 -0000 --f46d040168b3478b6204d5255cf4 Content-Type: text/plain; charset=ISO-8859-1 Folks who plan to submit new drafts, the cutoff date is Monday Feb. 18 and for revised drafts, the cutoff date is Monday Feb. 25. Please take note of these deadlines! --f46d040168b3478b6204d5255cf4 Content-Type: text/html; charset=ISO-8859-1 Folks who plan to submit new drafts, the cutoff date is Monday Feb. 18 and
for revised drafts, the cutoff date is Monday Feb. 25.

Please take note of these deadlines!

--f46d040168b3478b6204d5255cf4-- From sarikaya2012@gmail.com Thu Feb 7 13:48: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 31EFE21F8917 for ; Thu, 7 Feb 2013 13:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IszwDjkii+7k for ; Thu, 7 Feb 2013 13:48:33 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB2A21F884C for ; Thu, 7 Feb 2013 13:48:33 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id fo13so3154749lab.10 for ; Thu, 07 Feb 2013 13:48:32 -0800 (PST) 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=OBh+ZfgIXYKZXz+jOxrNfiTJ1blMWbJMBQ3KbCks+2Q=; b=Wa6ZnkiH6yS225/aSa3GQRSRa3ELVQBb+Gg90codD/4N/Ii+yOsVDcwokb5TDcAaPx j5otN0U1stbwfn5wU+kBcXMOXI5YTbPoUrlxkIFB4IQGMJ6LssJqFHdJXoYNGSx9Q94S oJDNN1z5qotnJdERsvClbbRlrbu6VTiNGbPHQM1uwhmYU35SEJoPUU9KP6OXKrmRI8gd Y5g5UiRCReQNeczrNjCcqoORURHO2SzzOZEj4ZcPYJelhRmENgUn5LpeJLpryXq/OPgY UYLHJQ0fc8dcjQeqa4itMd3iB6zuP8mQMDKTyGBxa5A2BEiU8Cj2vA5BJ81yidb6sFFw 7baw== MIME-Version: 1.0 X-Received: by 10.112.16.102 with SMTP id f6mr1414453lbd.3.1360273712401; Thu, 07 Feb 2013 13:48:32 -0800 (PST) Received: by 10.114.28.168 with HTTP; Thu, 7 Feb 2013 13:48:32 -0800 (PST) Date: Thu, 7 Feb 2013 15:48:32 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: multipart/alternative; boundary=f46d0401fd0f6ccebf04d5296733 Subject: [multimob] IETF 86 Session 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, 07 Feb 2013 21:48:34 -0000 --f46d0401fd0f6ccebf04d5296733 Content-Type: text/plain; charset=ISO-8859-1 Our Orlando session has tentatively been scheduled as follows: multimob Session 1 (2:30:00) Wednesday, Morning Session I 0900-1130 Room Name: Caribbean 6 We will now start entertaining slot requests for presentations. Regards, Behcet --f46d0401fd0f6ccebf04d5296733 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Our Orlando session has tentatively been scheduled as follows:

multi= mob Session 1 (2:30:00)
=A0 =A0 Wednesday, Morning Session I 0900-1130
=A0 =A0 Room Name: Caribbean 6

We will now start entertaining slot r= equests for presentations.

Regards,

Behcet
--f46d0401fd0f6ccebf04d5296733-- From stig@venaas.com Thu Feb 7 15:44: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 31EF021F89B2 for ; Thu, 7 Feb 2013 15:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZj5gGGR0qL1 for ; Thu, 7 Feb 2013 15:44:38 -0800 (PST) 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 8118121F89AE for ; Thu, 7 Feb 2013 15:44:38 -0800 (PST) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id F3E157FB7 for ; Fri, 8 Feb 2013 00:44:36 +0100 (CET) Message-ID: <51143C60.7020401@venaas.com> Date: Thu, 07 Feb 2013 15:44:32 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 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: [multimob] Review of draft-ietf-multimob-handover-optimization-01 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, 07 Feb 2013 23:44:39 -0000 Hi, please find below my comments on this draft. Stig In the draft it says receiving the corresponding MLD Report message. This delay is caused by the time needed for the detection of the attachment in the new link and the re-establishment of the data plane after the handover, the radio transfer delays associated with the signaling to the mobile node, and the MLD query response interval time required by this procedure (whose default value is 10 seconds as defined in [RFC2710], or between 5 and 10 seconds as considered in the best case wireless link scenario in [RFC6636]). Assuming there is a point-to-point link MAG-MN, can't this be set to a minimal value, maybe even 0? What happens if the subscription state doesn't fit in a single PBU/PBA? Can multiple messages be sent? In 4.3.1.2.2. Message format Do you need the I flag? Can't the receiver just check all the options to see if there are any Active Multicast Subscription options? Is it really worth having the optimization with the A flag if new message types are required? May it be possible to make use of the PBU message instead? Note that there may be less signaling by needlessly querying the pMAG on handover, instead of signaling the LMA each time a MN starts joining or leaving multicast groups. Do you need to allow Home Network Prefix in various messages? Don't you just need the MNI option? E.g. in the MAI/MAIA messages. In 5.1.2 figure 3. You need to write something other than MLD Done to take care of MLDv2 that only has reports. I know what you are trying to say though. There should be some limit for how long the LMA keeps the information in the proactive case, or rather, if there is not a new nMAG within a reasonable time. It should be made clear that the nMAG should still ASAP send MLD a query to check the hosts subscription state. Maybe it is already stated somewhere? In section 7 about co-existence. I think the MAG should only tell the LMA about the subscription information for the (S,G)s or Gs where it decided to send IGMP reports/joins on the LMA tunnel. A few Minor issues below. Comments for section 1. Introduction The base solution describing how continuous multicast service delivery can be provided in Proxy Mobile IPv6 domains is described in RFC 6224 [RFC6224]. This solution specifies the basic functionality ^^^^^^ It's a bit unclear whether "This" refers to 6224 or this document. Suggest writing "the base solution specifies", or maybe just "it specifies". mobile node), there is no a generic standard solution for the ^^^ remove "a". IGMP/MLD protocols. Both protocols send multicast membership interrogation messages when a new link is up. The response to such a ^^^^^^^^^^^^^ "query". Consider using "query" instead of "interrogation" other places too. o The solution should not impact on existing multicast protocols. ^^^^^^^^^^^ just "impact" or "have impact on". Present specification addresses all these requirements, as described in the following sections. Start with "The present" I think. From stig@venaas.com Fri Feb 8 14:54:47 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 7451821F8C10 for ; Fri, 8 Feb 2013 14:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-qvuqsKbbAa for ; Fri, 8 Feb 2013 14:54:47 -0800 (PST) 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 D156021F86C9 for ; Fri, 8 Feb 2013 14:54:46 -0800 (PST) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id 728FC7FCB for ; Fri, 8 Feb 2013 23:54:45 +0100 (CET) Message-ID: <51158232.4050500@venaas.com> Date: Fri, 08 Feb 2013 14:54:42 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "multimob@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [multimob] A couple of comments on draft-ietf-multimob-pmipv6-source-02 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, 08 Feb 2013 22:54:47 -0000 Hi The document is in a pretty good shape. I found one issue though. In 4.3.3 it says: On handover, the mobile source reattaches to a new MAG (DR), and PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new point of attachment. However, in the absence of a corresponding multicast forwarding state, the new DR will treat S as a new source and initiate a source registering of PIM phase one. In consequence, the PIM transition from phase one to two will be iterated per handover, leading to an enhanced signaling load and repeated delay variations. This is not really the case. The new MAG should be sending registers to the same RP as the previous MAG did. If registration had completed so that no more data registers were sent by the previous MAG (only periodic null-registers to maintain the (S,G) state on the RP), the RP would immediately respond with a register stop when it receives a register from the new MAG. Basically, the RP behavior does not depend on who is sending the registers. Independent of the registers, if the RP had joined the SPT to receive from the source, the SPT would be updated and joins would go towards the new MAG. The same for 4.3.4. Two minor editorial things I spotted: such as IPTV or sever-centric gaming on mobiles. However, current ^^^^^ bindings) has been performed . Still multicast packets arriving at ^^^ Stig From prvs=745403b04=schmidt@informatik.haw-hamburg.de Sat Feb 9 01:17:05 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 6759621F8BBA for ; Sat, 9 Feb 2013 01:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOwCPvidih-7 for ; Sat, 9 Feb 2013 01:17:04 -0800 (PST) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id DA3F821F8A5F for ; Sat, 9 Feb 2013 01:16:54 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 09 Feb 2013 10:16:47 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 681431066AE3; Sat, 9 Feb 2013 10:16:47 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18863-03; Sat, 9 Feb 2013 10:16:47 +0100 (CET) Received: from [192.168.1.30] (unknown [91.112.103.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id CB73E1066AE2; Sat, 9 Feb 2013 10:16:46 +0100 (CET) Message-ID: <511613FE.2070701@informatik.haw-hamburg.de> Date: Sat, 09 Feb 2013 10:16:46 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Stig Venaas References: <51158232.4050500@venaas.com> In-Reply-To: <51158232.4050500@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: "multimob@ietf.org" Subject: Re: [multimob] A couple of comments on draft-ietf-multimob-pmipv6-source-02 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, 09 Feb 2013 09:17:05 -0000 Hi Stig, thanks ... we'll be back on this shortly ... currently on travel ;) Cheers, Thomas On 08.02.2013 23:54, Stig Venaas wrote: > Hi > > The document is in a pretty good shape. I found one issue though. > > In 4.3.3 it says: > > On handover, the mobile source reattaches to a new MAG (DR), and > PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new > point of attachment. However, in the absence of a corresponding > multicast forwarding state, the new DR will treat S as a new source > and initiate a source registering of PIM phase one. In consequence, > the PIM transition from phase one to two will be iterated per > handover, leading to an enhanced signaling load and repeated delay > variations. > > This is not really the case. The new MAG should be sending registers to > the same RP as the previous MAG did. If registration had completed so > that no more data registers were sent by the previous MAG (only periodic > null-registers to maintain the (S,G) state on the RP), the RP would > immediately respond with a register stop when it receives a register > from the new MAG. Basically, the RP behavior does not depend on who is > sending the registers. > > Independent of the registers, if the RP had joined the SPT to receive > from the source, the SPT would be updated and joins would go towards > the new MAG. > > The same for 4.3.4. > > Two minor editorial things I spotted: > > > such as IPTV or sever-centric gaming on mobiles. However, current > ^^^^^ > > bindings) has been performed . Still multicast packets arriving at > ^^^ > > Stig > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From guanjian8632@163.com Sat Feb 9 01:27:29 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 32DC321F8BBD for ; Sat, 9 Feb 2013 01:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFrm-uvsGKsY for ; Sat, 9 Feb 2013 01:27:28 -0800 (PST) Received: from m50-138.163.com (m50-138.163.com [123.125.50.138]) by ietfa.amsl.com (Postfix) with ESMTP id 3A17D21F8BB9 for ; Sat, 9 Feb 2013 01:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Received:Date:From:To:Subject:References: Mime-Version:Message-ID:Content-Type; bh=juh/vsLu5/oVKxlkLIcethl 1tn3azVtWpSVUwyJT1sM=; b=geAtNoMQwEhSBp9guilwTE2oHygYeF7MaP3t2vN NjB+c4MHIdLI1YlioW0A8Wp6LzGjZXYS7VQoKb8++E67plhRwI4kyFpflD42B3Cl SvGfL90xPzdv0YLhMZTMO3G0TAQAFpQW3+5bZS0g0/IDf6FupD1nOSsmccM+R7aI 57m4= Received: from lgjf (unknown [114.255.40.49]) by smtp1 (Coremail) with SMTP id C9GowABnMIx7FhZRicmlAQ--.1486S2; Sat, 09 Feb 2013 17:27:23 +0800 (CST) Date: Sat, 9 Feb 2013 17:27:33 +0800 From: guanjian8632 To: multimob References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[en] Mime-Version: 1.0 Message-ID: <201302091727332637990@163.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart308768073384_=----" X-CM-TRANSID: C9GowABnMIx7FhZRicmlAQ--.1486S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxCw1DCrWkKw13ArW8trW3GFg_yoWrXw15pr 4S93W3Gr1kXr1xXws7Aw1q93Wqy3yDtF4UArs8Gr18AFWUA34vyr4jyw1rZayDJry5JrW5 tF4j9r45Xw1YqFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07j6RRiUUUUU= X-CM-SenderInfo: hjxd0yhldqmlits6il2tof0z/xtbB0Ru+S1EAA5xEhgAAsz Subject: Re: [multimob] multimob Digest, Vol 69, Issue 5 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, 09 Feb 2013 09:27:29 -0000 This is a multi-part message in MIME format. ------=_001_NextPart308768073384_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SW4gZmFjdCwgdG9kYXkgaXMgdGhlIE5ldyBZZWFyJ3MgRXZlIG9mIENoaW5hLg0KSGFwcHkgbHVu YXIgbmV3IHllYXJ+fg0KDQoNCg0KDQpKaWFuZmVuZyBHdWFuDQoNCkZyb206IG11bHRpbW9iLXJl cXVlc3QNCkRhdGU6IDIwMTMtMDItMDkgMTc6MTcNClRvOiBtdWx0aW1vYg0KU3ViamVjdDogbXVs dGltb2IgRGlnZXN0LCBWb2wgNjksIElzc3VlIDUNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZGlnZXN0IHdpdGhvdXQgYWxsIHRoZSBpbmRpdmlkdWFsIG1lc3NhZ2UNCmF0dGFjaG1lbnRzIHlv dSB3aWxsIG5lZWQgdG8gdXBkYXRlIHlvdXIgZGlnZXN0IG9wdGlvbnMgaW4geW91ciBsaXN0DQpz dWJzY3JpcHRpb24uICBUbyBkbyBzbywgZ28gdG8gDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXVsdGltb2INCg0KQ2xpY2sgdGhlICdVbnN1YnNjcmliZSBvciBlZGl0 IG9wdGlvbnMnIGJ1dHRvbiwgbG9nIGluLCBhbmQgc2V0ICJHZXQNCk1JTUUgb3IgUGxhaW4gVGV4 dCBEaWdlc3RzPyIgdG8gTUlNRS4gIFlvdSBjYW4gc2V0IHRoaXMgb3B0aW9uDQpnbG9iYWxseSBm b3IgYWxsIHRoZSBsaXN0IGRpZ2VzdHMgeW91IHJlY2VpdmUgYXQgdGhpcyBwb2ludC4NCg0KDQoN ClNlbmQgbXVsdGltb2IgbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvDQptdWx0aW1vYkBpZXRm Lm9yZw0KDQpUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdl YiwgdmlzaXQNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXVsdGltb2IN Cm9yLCB2aWEgZW1haWwsIHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdoZWxw JyB0bw0KbXVsdGltb2ItcmVxdWVzdEBpZXRmLm9yZw0KDQpZb3UgY2FuIHJlYWNoIHRoZSBwZXJz b24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCm11bHRpbW9iLW93bmVyQGlldGYub3JnDQoNCldoZW4g cmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3Bl Y2lmaWMNCnRoYW4gIlJlOiBDb250ZW50cyBvZiBtdWx0aW1vYiBkaWdlc3QuLi4iDQoNCg0KVG9k YXkncyBUb3BpY3M6DQoNCiAgIDEuIFJlOiAgQSBjb3VwbGUgb2YgY29tbWVudHMgb24NCiAgICAg IGRyYWZ0LWlldGYtbXVsdGltb2ItcG1pcHY2LXNvdXJjZS0wMiAoVGhvbWFzIEMuIFNjaG1pZHQp DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpNZXNzYWdlOiAxDQpEYXRlOiBTYXQsIDA5IEZlYiAyMDEz IDEwOjE2OjQ2ICswMTAwDQpGcm9tOiAiVGhvbWFzIEMuIFNjaG1pZHQiIDxzY2htaWR0QGluZm9y bWF0aWsuaGF3LWhhbWJ1cmcuZGU+DQpUbzogU3RpZyBWZW5hYXMgPHN0aWdAdmVuYWFzLmNvbT4N CkNjOiAibXVsdGltb2JAaWV0Zi5vcmciIDxtdWx0aW1vYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbbXVsdGltb2JdIEEgY291cGxlIG9mIGNvbW1lbnRzIG9uDQpkcmFmdC1pZXRmLW11bHRpbW9i LXBtaXB2Ni1zb3VyY2UtMDINCk1lc3NhZ2UtSUQ6IDw1MTE2MTNGRS4yMDcwNzAxQGluZm9ybWF0 aWsuaGF3LWhhbWJ1cmcuZGU+DQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9SVNP LTg4NTktMTsgZm9ybWF0PWZsb3dlZA0KDQpIaSBTdGlnLA0KDQp0aGFua3MgLi4uIHdlJ2xsIGJl IGJhY2sgb24gdGhpcyBzaG9ydGx5IC4uLiBjdXJyZW50bHkgb24gdHJhdmVsIDspDQoNCkNoZWVy cywNCg0KVGhvbWFzDQoNCk9uIDA4LjAyLjIwMTMgMjM6NTQsIFN0aWcgVmVuYWFzIHdyb3RlOg0K PiBIaQ0KPg0KPiBUaGUgZG9jdW1lbnQgaXMgaW4gYSBwcmV0dHkgZ29vZCBzaGFwZS4gSSBmb3Vu ZCBvbmUgaXNzdWUgdGhvdWdoLg0KPg0KPiBJbiA0LjMuMyBpdCBzYXlzOg0KPg0KPiAgICAgT24g aGFuZG92ZXIsIHRoZSBtb2JpbGUgc291cmNlIHJlYXR0YWNoZXMgdG8gYSBuZXcgTUFHIChEUiks IGFuZA0KPiAgICAgUE1JUHY2IHVuaWNhc3QgbWFuYWdlbWVudCB3aWxsIHRyYW5zZmVyIHRoZSBM TUEtTUFHIHR1bm5lbCB0byB0aGUgbmV3DQo+ICAgICBwb2ludCBvZiBhdHRhY2htZW50LiAgSG93 ZXZlciwgaW4gdGhlIGFic2VuY2Ugb2YgYSBjb3JyZXNwb25kaW5nDQo+ICAgICBtdWx0aWNhc3Qg Zm9yd2FyZGluZyBzdGF0ZSwgdGhlIG5ldyBEUiB3aWxsIHRyZWF0IFMgYXMgYSBuZXcgc291cmNl DQo+ICAgICBhbmQgaW5pdGlhdGUgYSBzb3VyY2UgcmVnaXN0ZXJpbmcgb2YgUElNIHBoYXNlIG9u ZS4gIEluIGNvbnNlcXVlbmNlLA0KPiAgICAgdGhlIFBJTSB0cmFuc2l0aW9uIGZyb20gcGhhc2Ug b25lIHRvIHR3byB3aWxsIGJlIGl0ZXJhdGVkIHBlcg0KPiAgICAgaGFuZG92ZXIsIGxlYWRpbmcg dG8gYW4gZW5oYW5jZWQgc2lnbmFsaW5nIGxvYWQgYW5kIHJlcGVhdGVkIGRlbGF5DQo+ICAgICB2 YXJpYXRpb25zLg0KPg0KPiBUaGlzIGlzIG5vdCByZWFsbHkgdGhlIGNhc2UuIFRoZSBuZXcgTUFH IHNob3VsZCBiZSBzZW5kaW5nIHJlZ2lzdGVycyB0bw0KPiB0aGUgc2FtZSBSUCBhcyB0aGUgcHJl dmlvdXMgTUFHIGRpZC4gSWYgcmVnaXN0cmF0aW9uIGhhZCBjb21wbGV0ZWQgc28NCj4gdGhhdCBu byBtb3JlIGRhdGEgcmVnaXN0ZXJzIHdlcmUgc2VudCBieSB0aGUgcHJldmlvdXMgTUFHIChvbmx5 IHBlcmlvZGljDQo+IG51bGwtcmVnaXN0ZXJzIHRvIG1haW50YWluIHRoZSAoUyxHKSBzdGF0ZSBv biB0aGUgUlApLCB0aGUgUlAgd291bGQNCj4gaW1tZWRpYXRlbHkgcmVzcG9uZCB3aXRoIGEgcmVn aXN0ZXIgc3RvcCB3aGVuIGl0IHJlY2VpdmVzIGEgcmVnaXN0ZXINCj4gZnJvbSB0aGUgbmV3IE1B Ry4gQmFzaWNhbGx5LCB0aGUgUlAgYmVoYXZpb3IgZG9lcyBub3QgZGVwZW5kIG9uIHdobyBpcw0K PiBzZW5kaW5nIHRoZSByZWdpc3RlcnMuDQo+DQo+IEluZGVwZW5kZW50IG9mIHRoZSByZWdpc3Rl cnMsIGlmIHRoZSBSUCBoYWQgam9pbmVkIHRoZSBTUFQgdG8gcmVjZWl2ZQ0KPiBmcm9tIHRoZSBz b3VyY2UsIHRoZSBTUFQgd291bGQgYmUgdXBkYXRlZCBhbmQgam9pbnMgd291bGQgZ28gdG93YXJk cw0KPiB0aGUgbmV3IE1BRy4NCj4NCj4gVGhlIHNhbWUgZm9yIDQuMy40Lg0KPg0KPiBUd28gbWlu b3IgZWRpdG9yaWFsIHRoaW5ncyBJIHNwb3R0ZWQ6DQo+DQo+DQo+IHN1Y2ggYXMgSVBUViBvciBz ZXZlci1jZW50cmljIGdhbWluZyBvbiBtb2JpbGVzLiAgSG93ZXZlciwgY3VycmVudA0KPiAgICAg ICAgICAgICAgICAgIF5eXl5eDQo+DQo+ICAgICBiaW5kaW5ncykgaGFzIGJlZW4gcGVyZm9ybWVk IC4gIFN0aWxsIG11bHRpY2FzdCBwYWNrZXRzIGFycml2aW5nIGF0DQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBeXl4NCj4NCj4gU3RpZw0KPg0KPg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtdWx0aW1vYiBtYWlsaW5nIGxpc3QN Cj4gbXVsdGltb2JAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tdWx0aW1vYg0KDQotLSANCg0KUHJvZi4gRHIuIFRob21hcyBDLiBTY2htaWR0DQo/IEhh bWJ1cmcgVW5pdmVyc2l0eSBvZiBBcHBsaWVkIFNjaWVuY2VzICAgICAgICAgICAgICAgICAgIEJl cmxpbmVyIFRvciA3ID8NCj8gRGVwdC4gSW5mb3JtYXRpaywgSW50ZXJuZXQgVGVjaG5vbG9naWVz IEdyb3VwICAgIDIwMDk5IEhhbWJ1cmcsIEdlcm1hbnkgPw0KPyBodHRwOi8vd3d3Lmhhdy1oYW1i dXJnLmRlL2luZXQgICAgICAgICAgICAgICAgICAgRm9uOiArNDktNDAtNDI4NzUtODQ1MiA/DQo/ IGh0dHA6Ly93d3cuaW5mb3JtYXRpay5oYXctaGFtYnVyZy5kZS9+c2NobWlkdCAgICBGYXg6ICs0 OS00MC00Mjg3NS04NDA5ID8NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm11bHRpbW9i IG1haWxpbmcgbGlzdA0KbXVsdGltb2JAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXVsdGltb2INCg0KDQpFbmQgb2YgbXVsdGltb2IgRGlnZXN0LCBWb2wg NjksIElzc3VlIDUNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg== ------=_001_NextPart308768073384_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
In fact, today is the New Year's Eve of China.
Happy lunar new year~~
 
Jianfeng Guan
 
From: multimob-request
Date: 2013-02-09 17:17
To: multimob
Subject: multimob Digest, Vol 69, Issue 5
If you have received this digest withou= t all the individual message
attachments you will need to update you= r digest options in your list
subscription.  To do so, go to 
 
https://www.ietf.org/mailman/listinfo/multimob
 
Click the 'Unsubscribe or edit options' = ;button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.&n= bsp; You can set this option
globally for all the list digests you&n= bsp;receive at this point.
 
 
 
Send multimob mailing list submissions to
multimob@ietf.org
 
To subscribe or unsubscribe via the Wor= ld Wide Web, visit
https://www.ietf.org/mailman/listinfo/multimob
or, via email, send a message with = ;subject or body 'help' to
multimob-request@ietf.org
 
You can reach the person managing the&n= bsp;list at
multimob-owner@ietf.org
 
When replying, please edit your Subject = ;line so it is more specific
than "Re: Contents of multimob digest..."
 
 
Today's Topics:
 
   1. Re:  A couple of c= omments on
      draft-ietf-multimob-pmipv6-source= -02 (Thomas C. Schmidt)
 
 
---------------------------------------------------------------------= -
 
Message: 1
Date: Sat, 09 Feb 2013 10:16:46 +0100
From: "Thomas C. Schmidt" <schmidt@informatik.= haw-hamburg.de>
To: Stig Venaas <stig@venaas.com>
Cc: "multimob@ietf.org" <multimob@ietf.org>
Subject: Re: [multimob] A couple of com= ments on
draft-ietf-multimob-pmipv6-source-02
Message-ID: <511613FE.2070701@informatik.haw-hamburg.de>
Content-Type: text/plain; charset=3DISO-8859-1; format= =3Dflowed
 
Hi Stig,
 
thanks ... we'll be back on this s= hortly ... currently on travel ;)
 
Cheers,
 
Thomas
 
On 08.02.2013 23:54, Stig Venaas wrote:
> Hi
>
> The document is in a pretty g= ood shape. I found one issue though.
>
> In 4.3.3 it says:
>
>     On handover, the mob= ile source reattaches to a new MAG (DR)= , and
>     PMIPv6 unicast management=  will transfer the LMA-MAG tunnel to th= e new
>     point of attachment. = ; However, in the absence of a correspo= nding
>     multicast forwarding stat= e, the new DR will treat S as a&nb= sp;new source
>     and initiate a sourc= e registering of PIM phase one.  In&nbs= p;consequence,
>     the PIM transition f= rom phase one to two will be iterated&n= bsp;per
>     handover, leading to = ;an enhanced signaling load and repeated del= ay
>     variations.
>
> This is not really the case. = The new MAG should be sending registers = ;to
> the same RP as the previous M= AG did. If registration had completed so
> that no more data registers were&n= bsp;sent by the previous MAG (only periodic<= /DIV>
> null-registers to maintain the (S,G)&nb= sp;state on the RP), the RP would
> immediately respond with a register&nbs= p;stop when it receives a register
> from the new MAG. Basically, the&n= bsp;RP behavior does not depend on who = is
> sending the registers.
>
> Independent of the registers, if t= he RP had joined the SPT to receive
> from the source, the SPT would&nbs= p;be updated and joins would go towards
> the new MAG.
>
> The same for 4.3.4.
>
> Two minor editorial things I spott= ed:
>
>
> such as IPTV or sever-centric gami= ng on mobiles.  However, current
>           = ;       ^^^^^
>
>     bindings) has been p= erformed .  Still multicast packets arriving=  at
>           = ;            &= nbsp;        ^^^
>
> Stig
>
>
> _______________________________________________
> multimob mailing list
> multimob@ietf.org
> https://www.ietf.org/mailman/listinfo/multimob
 
-- 
 
Prof. Dr. Thomas C. Schmidt
? Hamburg University of Applied Sciences&nbs= p;            =       Berliner Tor 7 ?
? Dept. Informatik, Internet Technologies Gr= oup    20099 Hamburg, Germany ?
? http://www.haw-hamburg.de/inet     &n= bsp;           &nbs= p; Fon: +49-40-42875-8452 ?
? http://www.informatik.haw-hamburg.de/~schmidt   = ; Fax: +49-40-42875-8409 ?
 
 
------------------------------
 
_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob
 
 
End of multimob Digest, Vol 69, Issue&n= bsp;5
***************************************
------=_001_NextPart308768073384_=------ From sarikaya2012@gmail.com Mon Feb 11 08:43: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 9A27221F8939 for ; Mon, 11 Feb 2013 08:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WI5a1n-Zbbge for ; Mon, 11 Feb 2013 08:43:16 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E24A521F8849 for ; Mon, 11 Feb 2013 08:43:15 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id fq12so5882714lab.5 for ; Mon, 11 Feb 2013 08:43:14 -0800 (PST) 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=V72aEQ9QgkDQvTfjNErV+CeYAqZrybm1mpzbNdDWwiU=; b=KM5l8YLSG+v2N+a90OfpWr4l69XpG6PvL1cEHP6ydoaZJahFE2To8qmBbGAZvkxLO7 bXrKk7lroUQk4LVlOUbR21h76g8oBVlnUTRu+XohSdqFZXpVW84Z6J2cetW07frLT8ZW tvslhfYaP2EJa0qQVXBP8tf0pZzwp/ow/T61gJtJMJfmrcCDragpiJyUgo6YNdAWbViQ cCGBvT7H/ASSdq1eZMoh7jEAitaePW50DKy1NSLomDZgvcU6a3vxxdt/2ijQ0jZmY1I4 LQFv3JFYNPQ1onqvp8Xz4ZJNA/TqNIHdEUhiDyfckyQAih75STyEvhgRuxbuRhunbqlp 8yIA== MIME-Version: 1.0 X-Received: by 10.112.87.66 with SMTP id v2mr6119018lbz.130.1360600994618; Mon, 11 Feb 2013 08:43:14 -0800 (PST) Received: by 10.114.28.168 with HTTP; Mon, 11 Feb 2013 08:43:14 -0800 (PST) In-Reply-To: <201302091727332637990@163.com> References: <201302091727332637990@163.com> Date: Mon, 11 Feb 2013 10:43:14 -0600 Message-ID: From: Behcet Sarikaya To: guanjian8632 Content-Type: multipart/alternative; boundary=f46d040169fff71cc404d5759a0d Cc: multimob Subject: Re: [multimob] multimob Digest, Vol 69, Issue 5 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: Mon, 11 Feb 2013 16:43:17 -0000 --f46d040169fff71cc404d5759a0d Content-Type: text/plain; charset=ISO-8859-1 Happy lunar new year to our friends in China and all over the world. Behcet On Sat, Feb 9, 2013 at 3:27 AM, guanjian8632 wrote: > ** > In fact, today is the New Year's Eve of China. > Happy lunar new year~~ > > ------------------------------ > Jianfeng Guan > > *From:* multimob-request > *Date:* 2013-02-09 17:17 > *To:* multimob > *Subject:* multimob Digest, Vol 69, Issue 5 > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/multimob > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send multimob mailing list submissions to > multimob@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/multimob > or, via email, send a message with subject or body 'help' to > multimob-request@ietf.org > > You can reach the person managing the list at > multimob-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of multimob digest..." > > > Today's Topics: > > 1. Re: A couple of comments on > draft-ietf-multimob-pmipv6-source-02 (Thomas C. Schmidt) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 09 Feb 2013 10:16:46 +0100 > From: "Thomas C. Schmidt" > To: Stig Venaas > Cc: "multimob@ietf.org" > Subject: Re: [multimob] A couple of comments on > draft-ietf-multimob-pmipv6-source-02 > Message-ID: <511613FE.2070701@informatik.haw-hamburg.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Stig, > > thanks ... we'll be back on this shortly ... currently on travel ;) > > Cheers, > > Thomas > > On 08.02.2013 23:54, Stig Venaas wrote: > > Hi > > > > The document is in a pretty good shape. I found one issue though. > > > > In 4.3.3 it says: > > > > On handover, the mobile source reattaches to a new MAG (DR), and > > PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new > > point of attachment. However, in the absence of a corresponding > > multicast forwarding state, the new DR will treat S as a new source > > and initiate a source registering of PIM phase one. In consequence, > > the PIM transition from phase one to two will be iterated per > > handover, leading to an enhanced signaling load and repeated delay > > variations. > > > > This is not really the case. The new MAG should be sending registers to > > the same RP as the previous MAG did. If registration had completed so > > that no more data registers were sent by the previous MAG (only periodic > > null-registers to maintain the (S,G) state on the RP), the RP would > > immediately respond with a register stop when it receives a register > > from the new MAG. Basically, the RP behavior does not depend on who is > > sending the registers. > > > > Independent of the registers, if the RP had joined the SPT to receive > > from the source, the SPT would be updated and joins would go towards > > the new MAG. > > > > The same for 4.3.4. > > > > Two minor editorial things I spotted: > > > > > > such as IPTV or sever-centric gaming on mobiles. However, current > > ^^^^^ > > > > bindings) has been performed . Still multicast packets arriving at > > ^^^ > > > > Stig > > > > > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > > -- > > Prof. Dr. Thomas C. Schmidt > ? Hamburg University of Applied Sciences Berliner Tor 7 ? > ? Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ? > ? http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 > ? > ? http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 > ? > > > ------------------------------ > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > > End of multimob Digest, Vol 69, Issue 5 > *************************************** > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > --f46d040169fff71cc404d5759a0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Happy lunar new year to our friends in China and all over the world.
Behcet

On Sat, Feb 9, 2013 at 3:27 AM, g= uanjian8632 <guanjian8632@163.com> wrote:
In fact, today is the New=A0Year's=A0Eve of China.
Happy lunar new year~~
=A0
Jianfeng Guan
=A0
Date:=A02013-02-09=A017:17
Subject:=A0multimob Digest, Vol 69, Issue 5
If=A0you=A0have=A0received=A0this=A0digest=A0without=A0all=A0the=A0ind= ividual=A0message
attachments=A0you=A0will=A0need=A0to=A0update=A0your=A0digest=A0option= s=A0in=A0your=A0list
subscription.=A0=A0To=A0do=A0so,=A0go=A0to=A0
=A0
=A0
Click=A0the=A0'Unsubscribe=A0or=A0edit=A0options'=A0button,=A0= log=A0in,=A0and=A0set=A0"Get
MIME=A0or=A0Plain=A0Text=A0Digests?"=A0to=A0MIME.=A0=A0You=A0can= =A0set=A0this=A0option
globally=A0for=A0all=A0the=A0list=A0digests=A0you=A0receive=A0at=A0thi= s=A0point.
=A0
=A0
=A0
Send=A0multimob=A0mailing=A0list=A0submissions=A0to
=A0
To=A0subscribe=A0or=A0unsubscribe=A0via=A0the=A0World=A0Wide=A0Web,=A0= visit
or,=A0via=A0email,=A0send=A0a=A0message=A0with=A0subject=A0or=A0body= =A0'help'=A0to
=A0
You=A0can=A0reach=A0the=A0person=A0managing=A0the=A0list=A0at
=A0
When=A0replying,=A0please=A0edit=A0your=A0Subject=A0line=A0so=A0it=A0i= s=A0more=A0specific
than=A0"Re:=A0Contents=A0of=A0multimob=A0digest..."
=A0
=A0
Today's=A0Topics:
=A0
=A0=A0=A01.=A0Re:=A0=A0A=A0couple=A0of=A0comments=A0on
=A0=A0=A0=A0=A0=A0draft-ietf-multimob-pmipv6-source-02=A0(Thomas=A0C.= =A0Schmidt)
=A0
=A0
----------------------------------------------------------------------=
=A0
Message:=A01
Date:=A0Sat,=A009=A0Feb=A02013=A010:16:46=A0+0100
From:=A0"Thomas=A0C.=A0Schmidt"=A0<schmidt@informatik.haw-ham= burg.de>
To:=A0Stig=A0Venaas=A0<stig@venaas.com>
Subject:=A0Re:=A0[multimob]=A0A=A0couple=A0of=A0comments=A0on
draft-ietf-multimob-pmipv6-source-02
Content-Type:=A0text/plain;=A0charset=3DISO-8859-1;=A0format=3Dflowed<= /div>
=A0
Hi=A0Stig,
=A0
thanks=A0...=A0we'll=A0be=A0back=A0on=A0this=A0shortly=A0...=A0cur= rently=A0on=A0travel=A0;)
=A0
Cheers,
=A0
Thomas
=A0
On=A008.02.2013=A023:54,=A0Stig=A0Venaas=A0wrote:
>=A0Hi
>
>=A0The=A0document=A0is=A0in=A0a=A0pretty=A0good=A0shape.=A0I=A0fou= nd=A0one=A0issue=A0though.
>
>=A0In=A04.3.3=A0it=A0says:
>
>=A0=A0=A0=A0=A0On=A0handover,=A0the=A0mobile=A0source=A0reattaches= =A0to=A0a=A0new=A0MAG=A0(DR),=A0and
>=A0=A0=A0=A0=A0PMIPv6=A0unicast=A0management=A0will=A0transfer=A0t= he=A0LMA-MAG=A0tunnel=A0to=A0the=A0new
>=A0=A0=A0=A0=A0point=A0of=A0attachment.=A0=A0However,=A0in=A0the= =A0absence=A0of=A0a=A0corresponding
>=A0=A0=A0=A0=A0multicast=A0forwarding=A0state,=A0the=A0new=A0DR=A0= will=A0treat=A0S=A0as=A0a=A0new=A0source
>=A0=A0=A0=A0=A0and=A0initiate=A0a=A0source=A0registering=A0of=A0PI= M=A0phase=A0one.=A0=A0In=A0consequence,
>=A0=A0=A0=A0=A0the=A0PIM=A0transition=A0from=A0phase=A0one=A0to=A0= two=A0will=A0be=A0iterated=A0per
>=A0=A0=A0=A0=A0handover,=A0leading=A0to=A0an=A0enhanced=A0signalin= g=A0load=A0and=A0repeated=A0delay
>=A0=A0=A0=A0=A0variations.
>
>=A0This=A0is=A0not=A0really=A0the=A0case.=A0The=A0new=A0MAG=A0shou= ld=A0be=A0sending=A0registers=A0to
>=A0the=A0same=A0RP=A0as=A0the=A0previous=A0MAG=A0did.=A0If=A0regis= tration=A0had=A0completed=A0so
>=A0that=A0no=A0more=A0data=A0registers=A0were=A0sent=A0by=A0the=A0= previous=A0MAG=A0(only=A0periodic
>=A0null-registers=A0to=A0maintain=A0the=A0(S,G)=A0state=A0on=A0the= =A0RP),=A0the=A0RP=A0would
>=A0immediately=A0respond=A0with=A0a=A0register=A0stop=A0when=A0it= =A0receives=A0a=A0register
>=A0from=A0the=A0new=A0MAG.=A0Basically,=A0the=A0RP=A0behavior=A0do= es=A0not=A0depend=A0on=A0who=A0is
>=A0sending=A0the=A0registers.
>
>=A0Independent=A0of=A0the=A0registers,=A0if=A0the=A0RP=A0had=A0joi= ned=A0the=A0SPT=A0to=A0receive
>=A0from=A0the=A0source,=A0the=A0SPT=A0would=A0be=A0updated=A0and= =A0joins=A0would=A0go=A0towards
>=A0the=A0new=A0MAG.
>
>=A0The=A0same=A0for=A04.3.4.
>
>=A0Two=A0minor=A0editorial=A0things=A0I=A0spotted:
>
>
>=A0such=A0as=A0IPTV=A0or=A0sever-centric=A0gaming=A0on=A0mobiles.= =A0=A0However,=A0current
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0^^^^^
>
>=A0=A0=A0=A0=A0bindings)=A0has=A0been=A0performed=A0.=A0=A0Still= =A0multicast=A0packets=A0arriving=A0at
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0^^^
>
>=A0Stig
>
>
>=A0_______________________________________________
>=A0multimob=A0mailing=A0list
=A0
--=A0
=A0
Prof.=A0Dr.=A0Thomas=A0C.=A0Schmidt
?=A0Hamburg=A0University=A0of=A0Applied=A0Sciences=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Berliner=A0Tor=A07=A0?
?=A0Dept.=A0Informatik,=A0Internet=A0Technologies=A0Group=A0=A0=A0=A02= 0099=A0Hamburg,=A0Germany=A0?
?=A0http:= //www.haw-hamburg.de/inet=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0Fon:=A0+49-40-42875-8452=A0?
=A0
=A0
------------------------------
=A0
_______________________________________________
multimob=A0mailing=A0list
=A0
=A0
End=A0of=A0multimob=A0Digest,=A0Vol=A069,=A0Issue=A05
***************************************

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


--f46d040169fff71cc404d5759a0d-- From sarikaya2012@gmail.com Mon Feb 11 14:51:21 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 CD51621F8939 for ; Mon, 11 Feb 2013 14:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=2.02, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOv45+uEAExO for ; Mon, 11 Feb 2013 14:51:21 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0498721F892F for ; Mon, 11 Feb 2013 14:51:20 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id fo12so6350061lab.14 for ; Mon, 11 Feb 2013 14:51:20 -0800 (PST) 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=o2YK1XIV1lwlJXyPy5xBx8PQEKMOQp39nHti7O1MKWw=; b=Tl0zvRnqJjlNaqhUqVzY4e+8ZAy8/cPehoVxKUkOogwGUR75fYLew+L3tKXlNYZmQX vQ8BaZl0ADqVxL3W90YlLWcRP9XDhvCVk/N4CwjIA8pG17/FlRqTrtGVbf/UYwLk5RJA /wyvfn3THro8N0/wgaBS+o0HbrFp9KRa4aED+zrZj4m90ukDwbjU8/gQQwp85stpGYL4 YrXZocw/E/5vDq9xJgjQbC6OPWc3sm+/sQJ50vrDEGGr3rtO6TFmyIdeYDRpR+OblXuo kRuaFzzsuCCwdil4Jqqlz8YrN1PILvyIn30Oejtm98oduksHR6rMyKgoh6alEu2bouaA Ke5A== MIME-Version: 1.0 X-Received: by 10.112.16.102 with SMTP id f6mr6438369lbd.3.1360623079956; Mon, 11 Feb 2013 14:51:19 -0800 (PST) Received: by 10.114.28.168 with HTTP; Mon, 11 Feb 2013 14:51:19 -0800 (PST) Date: Mon, 11 Feb 2013 16:51:19 -0600 Message-ID: From: Behcet Sarikaya To: draft-ietf-multimob-pmipv6-ropt@tools.ietf.org, multimob@ietf.org Content-Type: multipart/alternative; boundary=f46d0401fd0f5a9f9b04d57abfe9 Subject: [multimob] 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: Mon, 11 Feb 2013 22:51:21 -0000 --f46d0401fd0f5a9f9b04d57abfe9 Content-Type: text/plain; charset=ISO-8859-1 Hi JC, Authors, This draft is a candidate for WG LC soon, so please consider my comments below and revise accordingly: Section 3.1. Similarly, more than one MTMA could be deployed by the operator (not shown in Figure 1). 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 Section 3.2. each MAG has a direct connection (i.e., not using the tunnel interface) with a multicast router. Does MR need to be next hop? If not what happens? Again this is later on explained on Page 15, but why not here? 3.3. Dynamic Selection Support This section is about MAG as a multicast router. WG has not yet decided if MAG should be a multicast router. So this section is out of scope. Please remove. Section 4.2.1 Is Figure 4 really needed? Maybe remove. 4.2.2. multicast establishment. vvv service 4.3. MAG as multicast router This section is also about MAG as a multicast router. WG has not yet decided if MAG should be a multicast router. So this section is out of scope. Please remove. 5.1. Dynamic IP Multicast Selector Option This option brings a lot of questions. But more importantly, it seems to apply to the case of MAG as multicast router which is out of scope, so please remove. I also read the Appendix, I think it is OK. Thanks for your hard work. Behcet --f46d0401fd0f5a9f9b04d57abfe9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi JC, Authors,
This draft is a candidate for WG LC soon, so please cons= ider my comments below and revise accordingly:

Section 3.1. Similarl= y, more than one MTMA could be
=A0=A0 deployed by the operator (not show= n in Figure 1).

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 stil= l not clear. Please explain it here in 3.1

Section 3.2. each MAG has= a direct connection (i.e., not
=A0=A0 using the tunnel interface) with a multicast router.

Does MR = need to be next hop? If not what happens?
Again this is later on explain= ed on Page 15, but why not here?

3.3.=A0 Dynamic Selection Support
This section is about MAG as a multicast router.
WG has not yet dec= ided if MAG should be a multicast router. So this section is out of scope. = Please remove.

Section 4.2.1
Is Figure 4 really needed? Maybe rem= ove.

4.2.2.
multicast =A0 =A0 =A0 =A0=A0 establishment.
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vvv=A0 service

4.3.=A0 MAG as multica= st router

This section is also about MAG as a multicast router.
= WG has not yet decided if MAG should be a multicast router. So this section= is out of scope. Please remove.

5.1.=A0 Dynamic IP Multicast Selector Option
This option brings a lo= t of questions.
But more importantly, it seems to apply to the case of M= AG as multicast router which is out of scope, so please remove.
I also r= ead the Appendix, I think it is OK.

Thanks for your hard work.

Behcet


--f46d0401fd0f5a9f9b04d57abfe9-- From asaeda@sfc.wide.ad.jp Mon Feb 11 19:28:29 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 634A921F8A94 for ; Mon, 11 Feb 2013 19:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jba5n9-w+koe for ; Mon, 11 Feb 2013 19:28:29 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id D5C1321F8A85 for ; Mon, 11 Feb 2013 19:28:28 -0800 (PST) Received: from localhost (unknown [202.249.37.10]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 384AE2780A7; Tue, 12 Feb 2013 12:28:27 +0900 (JST) Date: Tue, 12 Feb 2013 12:28:31 +0900 (JST) Message-Id: <20130212.122831.64581486.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: References: X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: sarikaya2012@gmail.com Subject: Re: [multimob] draft-ietf-multimob-pmipv6-ropt 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: Tue, 12 Feb 2013 03:28:29 -0000 Hi, I've reviewed this draft. I think this draft provides useful ideas and closes up to the LC, but the following points should taken into account. 1. multicast router support I almost agree with Behcet at this point. This draft should focus only on the case MAG acts as MLD proxy. All descriptions related to the case MAG acts as multicast routers (i.e. PIM routers) should be completely removed. (I would say WG does not need to decide only one solution. It sounds reasonable for this WG to provide both scenarios, "MAG=MLD proxy" and "MAG=PIM router". Both are beneficial for some condition or situation. The decision which scenario should be selected is an operator's or provider's choice, accouring to their conditions or situations. Well, it does not relate to the direction of this draft. I'd like to stop discussing about it here.) 2. local subscription This draft uses both "remote subscription" and "local subscription". But I don't think it is a bit confusing to use these words without clarifying the terminologies. The point of this confusion comes from several misuse of "direct routing" and "localized routing". Localized routing is formally defined in RFC6705. In my sense, local subscription includes both direct routing and localized routing, while this draft only focuses on direct routing. So, my recommendation is to remove these words, "remote subscription" and "local subscription", from the draft, and just use "subscription via MTMA" and "subscription via direct routing". 3. direct routing Similar to above. It'd be better to clarify that direct routing this draft focuses on does not include localized routing. Lastly, I have one question. Does this draft consider the case in which MAG enables *both* a tunnel to MTMA and direct routing? I could not find such consideration... Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Mon Feb 11 20:36: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 2DCBF21F8B4C for ; Mon, 11 Feb 2013 20:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npRH8jKy68OS for ; Mon, 11 Feb 2013 20:36:37 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 31FB221F8B4A for ; Mon, 11 Feb 2013 20:36:36 -0800 (PST) Received: from localhost (unknown [202.249.37.10]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id DC31F2780A7 for ; Tue, 12 Feb 2013 13:36:35 +0900 (JST) Date: Tue, 12 Feb 2013 13:36:40 +0900 (JST) Message-Id: <20130212.133640.253650244.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <20130212.122831.64581486.asaeda@sfc.wide.ad.jp> References: <20130212.122831.64581486.asaeda@sfc.wide.ad.jp> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] draft-ietf-multimob-pmipv6-ropt 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: Tue, 12 Feb 2013 04:36:38 -0000 One correction. > 1. multicast router support > I almost agree with Behcet at this point. This draft should focus > only on the case MAG acts as MLD proxy. All descriptions related to > the case MAG acts as multicast routers (i.e. PIM routers) should be > completely removed. > (I would say WG does not need to decide only one solution. It I would say WG can provide different solutions for different scenarios. > sounds reasonable for this WG to provide both scenarios, "MAG=MLD > proxy" and "MAG=PIM router". Both are beneficial for some condition > or situation. The decision which scenario should be selected is an > operator's or provider's choice, accouring to their conditions or > situations. Well, it does not relate to the direction of this > draft. I'd like to stop discussing about it here.) Regards, -- Hitoshi Asaeda From lmcm@tid.es Mon Feb 18 13:14:19 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 1000421F8CC8 for ; Mon, 18 Feb 2013 13:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHM82vKKCA9g for ; Mon, 18 Feb 2013 13:14:16 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id CD3F221F88AE for ; Mon, 18 Feb 2013 13:14:14 -0800 (PST) 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 <0MIF004FDPNN07@tid.hi.inet> for multimob@ietf.org; Mon, 18 Feb 2013 22:14:11 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id D6.65.05051.3A992215; Mon, 18 Feb 2013 22:14:11 +0100 (CET) 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 <0MIF004F7PNI07@tid.hi.inet> for multimob@ietf.org; Mon, 18 Feb 2013 22:14:11 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Mon, 18 Feb 2013 22:14:07 +0100 Date: Mon, 18 Feb 2013 21:14:05 +0000 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: X-Originating-IP: [10.95.64.115] To: "sarikaya@ieee.org" Message-id: <823234EF5C7C334998D973D822FF801B315A31D3@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_zpEQ0iCvDbBJJimnNZavxw)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: [multimob] draft-ietf-multimob-handover-optimization-01 Thread-index: AQHN/0F7Qi5Ph8IGG0+lcNSYgewrrJiAKiTQ X-AuditID: 0a5f4e69-b7fbe6d0000013bb-3d-512299a31d0a X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42Lhivcz1F08UynQYPpJbYsZH/tYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcb7lCUtBW0rFiiPdrA2MB0O7GDk5JARMJB69OMcOYYtJXLi3 nq2LkYtDSGAbo8TC8+sZIZzfjBK7W/ZAOTOBnOlXwFpYBFQlupdMYASx2QQMJWbtnMQKYgsL uEh8vzmbCcTmFAiW+LDvByPECgWJP+ces4DYIgLaEjsO7QAbyiwwkVFiQctEsAZeAW+JB//u sEPYghI/Jt8Da2AWyJX4+G8BO4QtLjHn10SwZYwCshIrz58GGsQBNNRV4touXoj5RhIbl3+D ek1AYsme88wQtqjEy8f/wFqFBAIk7r05zjyBUWwWkm2zkGybhWQbhK0jsWD3JzYIW1ti2cLX zDD2mQOPmZDFFzCyr2IUK04qykzPKMlNzMxJNzDSy8jUy8xLLdnECIm8zB2My3eqHGIU4GBU 4uE1VJcOFGJNLCuuzD3EKMHBrCTC29GuFCjEm5JYWZValB9fVJqTWnyIkYmDU6qBUaD4VElb 9MdHV/f2cWX73ty7Q/Bjo0dR2BXtt4ECQV90shfreE4O1Tv2fH1q41TbZG3vc/4rj8z7fs06 9XXSpZzmtFnclzitH/U9n8hwvcX5pcqSU9nd4TOW7r2RdWjpH6WF0RcS3j/f7XXuWuAuqRcf BAs4H+/8PG++1TX28u8JxXbOtRlM25RYijMSDbWYi4oTAQCSgR6aAgAA References: Cc: "multimob@ietf.org" Subject: Re: [multimob] draft-ietf-multimob-handover-optimization-01 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, 18 Feb 2013 21:14:19 -0000 --Boundary_(ID_zpEQ0iCvDbBJJimnNZavxw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Behcet, Thanks for your comments, and sorry for the late response. Please, find our answers in line Best regards, Luis De: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] En nombre de Behcet Sarikaya Enviado el: jueves, 31 de enero de 2013 0:28 Para: multimob@ietf.org Asunto: [multimob] draft-ietf-multimob-handover-optimization-01 Hi Carlos, authors, Some initial comments on your draft: Section 4.2 states that two new flags are defined but Flag A is not used in the line. [Luis>>] Actually section 4.2 covers the description of both flags, A and S. There is an specific section inside for any of them, being 4.2.1 devoted to flag S, and section 4.2.2 to flag A. We can improve the text explicitly mention this to help the reader. Subscription Query/Response messages: why not use the Update Notification message in draft-ietf-netext-update-notifications-00? [Luis>>] The mechanism described in draft-ietf-netext-update-notifications-00 focus on notifications triggered by the LMA. Despite the query from LMA to pMAG in the proactive handover case could be seen as one potential use case, the scope of the Subscription Query/Response messages is wider. These messages are also used by the nMAG for retrieving the multicast subscription information from the LMA in situations where the unicast binding is allowed to progress till the multicast information is ready, preventing large delays of the binding acknowledgement for unicast traffic (see section 5.2.4). In our opinion, a common mechanism should be used in both cases. Why is it necessary to define messages other than PBU/PBA from MAG to LMA, i.e. Act Ind? [Luis>>] The idea behind the new messages described in the WG draft is the use of specific and lightweight signaling methods for handling some flags in support of multicast handover optimization. For instance, the multicast activity indication represents the change in the multicast status state ( subscribed / not subscribed to any group) of one interface in the MAG. Strictly speaking, this event is not related to the purpose of PBU/PBA signaling. Regarding Figs 1 & 2, and also the Flag A, MLD Done is only in MLDv1 and has been removed from MLDv2, check Appendix B in RFC 3810. [Luis>>] That's correct, although the parts of the text where the reference to the MLD Done message appear are actually on Figure 3 and the first bullet below that figure. Our proposal is to change the text of the figure from "MLD Done" to "MLD Report" for brevity, and to change the text in the bullet from "MLD Done" to "MLD Report message (with a filter mode change record indicating EXCLUDE mode for the last subscribed multicast group)". MLD Done was mimicking IGMPv2 Leave message which is not mentioned in IPv4 support. The fact that MLD Done (or IGMP Leave) no longer available in SSM makes me question the A Flag. How could LMA sustain a valid value of the A Flag? OTOH, A Flag is only used for optimization, as shown in Figure 6. Would it be possible to not define A Flag and use S Flag? [Luis>>] Flag A helps to optimize the number of messages between PMIP entities by limiting the interrogation of the pMAG by the LMA in the case of reactive handover just to the case where the MN in the handover is maintaining an active multicast session. The proposed solution could work without using the flag A, but at the cost of delivering much more signaling messages than the strictly needed (all the messages for the MNs without multicast session does not need any supporting message for multicast handover optimization). Regards, Behcet ________________________________ 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 --Boundary_(ID_zpEQ0iCvDbBJJimnNZavxw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Behcet,

 

Thanks for your comments, and sorry for the late response.

 

Please, find our answers in line

 

Best regards,

 

Luis

 

De: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] En nombre de Behcet Sarikaya
Enviado el: jueves, 31 de enero de 2013 0:28
Para: multimob@ietf.org
Asunto: [multimob] draft-ietf-multimob-handover-optimization-01

 

Hi Carlos, authors,

Some initial comments on your draft:
Section 4.2 states that two new flags are defined but Flag A is not used in the line.

[Luis>>] Actually section 4.2 covers the description of both flags, A and S. There is an specific section inside for any of them, being 4.2.1 devoted to flag S, and section 4.2.2 to flag A. We can improve the text explicitly mention this to help the reader.

Subscription Query/Response messages: why not use the Update Notification message in draft-ietf-netext-update-notifications-00?

[Luis>>] The mechanism described in draft-ietf-netext-update-notifications-00 focus on notifications triggered by the LMA. Despite the query from LMA to pMAG in the proactive handover case could be seen as one potential use case, the scope of the Subscription Query/Response messages is wider. These messages are also used by the nMAG for retrieving the multicast subscription information from the LMA in situations where the unicast binding is allowed to progress till the multicast information is ready, preventing large delays of the binding acknowledgement for unicast traffic (see section 5.2.4). In our opinion, a common mechanism should be used in both cases.

Why is it necessary to define messages other than PBU/PBA from MAG to LMA, i.e. Act Ind?

[Luis>>] The idea behind the new messages described in the WG draft is the use of specific and lightweight signaling methods for handling some flags in support of multicast handover optimization. For instance, the multicast activity indication represents the change in the multicast status state ( subscribed / not subscribed to any group) of one interface in the MAG. Strictly speaking, this event is not related to the purpose of PBU/PBA signaling.

Regarding Figs 1 & 2, and also the Flag A, MLD Done is only in MLDv1 and has been removed from MLDv2, check Appendix B in RFC 3810.

[Luis>>] That’s correct, although the parts of the text where the reference to the MLD Done message appear are actually on Figure 3 and the first bullet below that figure. Our proposal is to change the text of the figure from “MLD Done” to “MLD Report” for brevity, and to change the text in the bullet from “MLD Done” to “MLD Report message (with a filter mode change record indicating EXCLUDE mode for the last subscribed multicast group)”.


MLD Done was mimicking IGMPv2 Leave message which is not mentioned in IPv4 support.

The fact that MLD Done (or IGMP Leave) no longer available in SSM makes me question the A Flag. How could LMA sustain a valid value of the A Flag?
OTOH, A Flag is only used for optimization, as shown in Figure 6.
Would it be possible to not define A Flag and use S Flag?

[Luis>>] Flag A helps to optimize the number of messages between PMIP entities by limiting the interrogation of the pMAG by the LMA in the case of reactive handover just to the case where the MN in the handover is maintaining an active multicast session. The proposed solution could work without using the flag A, but at the cost of delivering much more signaling messages than the strictly needed (all the messages for the MNs without multicast session does not need any supporting message for multicast handover optimization).



Regards,

Behcet



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
 --Boundary_(ID_zpEQ0iCvDbBJJimnNZavxw)-- From lmcm@tid.es Mon Feb 18 13:30:45 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 1621B21F8CD4 for ; Mon, 18 Feb 2013 13:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.469 X-Spam-Level: X-Spam-Status: No, score=-4.469 tagged_above=-999 required=5 tests=[AWL=2.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Y6uEgR5AGsw for ; Mon, 18 Feb 2013 13:30:42 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 24F9121F8CD1 for ; Mon, 18 Feb 2013 13:30:40 -0800 (PST) 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 <0MIF00F1PQF34N@tid.hi.inet> for multimob@ietf.org; Mon, 18 Feb 2013 22:30:39 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 14.1B.01293.F7D92215; Mon, 18 Feb 2013 22:30:39 +0100 (CET) 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 <0MIF00F1KQF34N@tid.hi.inet> for multimob@ietf.org; Mon, 18 Feb 2013 22:30:39 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Mon, 18 Feb 2013 22:30:39 +0100 Date: Mon, 18 Feb 2013 21:30:38 +0000 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: <51143C60.7020401@venaas.com> X-Originating-IP: [10.95.64.115] To: "Stig Venaas (stig@venaas.com)" Message-id: <823234EF5C7C334998D973D822FF801B315A3218@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: es-ES Content-transfer-encoding: base64 Accept-Language: es-ES, en-US Thread-topic: [multimob] Review of draft-ietf-multimob-handover-optimization-01 Thread-index: AQHOBY0bgKpMlHXkpUKUqly+8FmduJiAIIZQ X-AuditID: 0a5f4068-b7f006d00000050d-76-51229d7f4101 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsXCFe/ApVs/VynQ4M1zE4sZH/tYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcadfq6AlvWLz7SlMDYwbUroYOTkkBEwkrr/6wgRhi0lcuLee rYuRi0NIYAOjRNvRo+wQzm9Gidbb+1khnJmMEk+ePgLKcHCwCKhKdG1RA+lmEzCUmLVzEiuI LSzgJ9H88jvYVE4BLYmnXX9ZIDYoSPw59xjMFhEwlZg94wDYNmaBiYwSU1dOBWvmFfCW+HS4 lR3CFpT4MfkeC8guZgF1iSlTckHCzALiEnN+TWSFsBUlpi1qYASxGQVkJVaeP80IMd9f4nLT FSYI20iiqfs41A0CEkv2nGeGsEUlXj7+BzZHSKBI4n/TRLYJjOKzkGyehbB5FpLNs5BsXsDI sopRrDipKDM9oyQ3MTMn3cBQLyNTLzMvtWQTIySGMnYwLt+pcohRgINRiYfXQF06UIg1say4 MvcQowQHs5IIb0e7UqAQb0piZVVqUX58UWlOavEhRiYOTqkGRv6apOlrgxZuOvLkblf8U7Ul 2wP/S3bExNfvesM27Y1v3J0jzr85b3/TsWG+6fh0h6LSBpaXWbb/apwD621yleZG3lu44OXy Aou7QVJBRw7Y5Jwv/pxeELY9qCVLteWpQeLFXyvku2Lsfi92K/zn9FDqoefSmvvrmKZzPIpy W/5+otCl13L7y5VYijMSDbWYi4oTAd4r8IV/AgAA References: <51143C60.7020401@venaas.com> Cc: "multimob@ietf.org" Subject: Re: [multimob] Review of draft-ietf-multimob-handover-optimization-01 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, 18 Feb 2013 21:30:45 -0000 SGkgU3RpZywNCg0KVGhhbmtzIGZvciB5b3VyIGRlZXAgcmV2aWV3LCBhbmQgZXhjdXNlIHVzIGZv ciB0aGUgZGVsYXkgaW4gYW5zd2VyaW5nIGl0Lg0KDQpQbGVhc2UsIHNlZSBvdXIgY29tbWVudHMg aW4tbGluZS4NCg0KQmVzdCByZWdhcmRzLA0KDQpMdWlzDQoNCi0tLS0tTWVuc2FqZSBvcmlnaW5h bC0tLS0tDQpEZTogbXVsdGltb2ItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm11bHRpbW9iLWJv dW5jZXNAaWV0Zi5vcmddIEVuIG5vbWJyZSBkZSBTdGlnIFZlbmFhcw0KRW52aWFkbyBlbDogdmll cm5lcywgMDggZGUgZmVicmVybyBkZSAyMDEzIDA6NDUNClBhcmE6IG11bHRpbW9iQGlldGYub3Jn DQpBc3VudG86IFttdWx0aW1vYl0gUmV2aWV3IG9mIGRyYWZ0LWlldGYtbXVsdGltb2ItaGFuZG92 ZXItb3B0aW1pemF0aW9uLTAxDQoNCkhpLCBwbGVhc2UgZmluZCBiZWxvdyBteSBjb21tZW50cyBv biB0aGlzIGRyYWZ0Lg0KDQpTdGlnDQoNCkluIHRoZSBkcmFmdCBpdCBzYXlzDQoNCiAgICByZWNl aXZpbmcgdGhlIGNvcnJlc3BvbmRpbmcgTUxEIFJlcG9ydCBtZXNzYWdlLiAgVGhpcyBkZWxheSBp cyBjYXVzZWQNCiAgICBieSB0aGUgdGltZSBuZWVkZWQgZm9yIHRoZSBkZXRlY3Rpb24gb2YgdGhl IGF0dGFjaG1lbnQgaW4gdGhlIG5ldw0KICAgIGxpbmsgYW5kIHRoZSByZS1lc3RhYmxpc2htZW50 IG9mIHRoZSBkYXRhIHBsYW5lIGFmdGVyIHRoZSBoYW5kb3ZlciwNCiAgICB0aGUgcmFkaW8gdHJh bnNmZXIgZGVsYXlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2lnbmFsaW5nIHRvIHRoZSBtb2JpbGUN CiAgICBub2RlLCBhbmQgdGhlIE1MRCBxdWVyeSByZXNwb25zZSBpbnRlcnZhbCB0aW1lIHJlcXVp cmVkIGJ5IHRoaXMNCiAgICBwcm9jZWR1cmUgKHdob3NlIGRlZmF1bHQgdmFsdWUgaXMgMTAgc2Vj b25kcyBhcyBkZWZpbmVkIGluIFtSRkMyNzEwXSwNCiAgICBvciBiZXR3ZWVuIDUgYW5kIDEwIHNl Y29uZHMgYXMgY29uc2lkZXJlZCBpbiB0aGUgYmVzdCBjYXNlIHdpcmVsZXNzDQogICAgbGluayBz Y2VuYXJpbyBpbiBbUkZDNjYzNl0pLg0KDQpBc3N1bWluZyB0aGVyZSBpcyBhIHBvaW50LXRvLXBv aW50IGxpbmsgTUFHLU1OLCBjYW4ndCB0aGlzIGJlIHNldCB0byBhIG1pbmltYWwgdmFsdWUsIG1h eWJlIGV2ZW4gMD8NCg0KW0x1aXM+Pl0gUG90ZW50aWFsbHkgeWVzLiBFdmVuIGluIHRoYXQgY2Fz ZSwgdGhlIGV4cGVjdGVkIHBlcmZvcm1hbmNlIG9idGFpbmVkIGJ5IHVzaW5nIHRoaXMgb3B0aW1p emF0aW9uIGlzIGJldHRlciB0aGFuIHRoZSBvbmUgZXhwZXJpZW5jZWQgd2l0aCB0aGUgYmFzZSBz b2x1dGlvbiwgYXMgZGVzY3JpYmVkIGluIEFwcGVuZGl4IEEuIEhvd2V2ZXIsIGl0IGNvdWxkIGJl IGFuIG9wdGlvbiBqdXN0IGluIGNhc2UgdGhlIHJvdXRlciB3aGVyZSB0aGUgTUFHIHJlc2lkZXMg aXMgdXNlZCBvbmx5IGZvciBQTUlQdjYgbW9iaWxlIGN1c3RvbWVycyAoaS5lLiwgaXQgaXMgbm90 IG11dHVhbGl6ZWQgZm9yIGJvdGggbW9iaWxlIGFuZCBmaXhlZCB1c2VycyBpbiBmaXhlZC9tb2Jp bGUgY29udmVyZ2VudCBzY2VuYXJpb3MsIG9yIHRoZSByb3V0ZXIgYWxzbyBzaW11bHRhbmVvdXNs eSBwcm92aWRlcyBvdGhlciBtb2JpbGUgc2VydmljZXMgZGlmZmVyZW50IGZyb20gUE1JUHY2LCBp biB3aGljaCB0aGUgcG9pbnQtdG8tcG9pbnQgbGluayBtb2RlbCBpcyBub3QgZm9sbG93ZWQvcmVx dWlyZWQpLCBvciBpbiBjYXNlIHRoZSBNTEQgY29uZmlndXJhdGlvbiBjYW4gYmUgaW5kaXZpZHVh bGx5IGFwcGxpZWQgcGVyIGludGVyZmFjZSAodGh1cywgcGVyIFBNSVB2NiBNQUctdG8tTU4gcG9p bnQtdG8tcG9pbnQgaW50ZXJmYWNlKS4gTG9va2luZyBhdCBleGlzdGluZyBzdGF0ZS1vZi10aGUt YXJ0IE1BR3MsIHRoaXMgaXMgbm90IHBvc3NpYmxlLiBGb3IgaW5zdGFuY2UsIHRoZSBDaXNjbyA4 NTAwIFdpcmVsZXNzIExBTiBDb250cm9sbGVyIGRvcyBub3QgYWxsb3cgYSBjb25maWd1cmF0aW9u IG9mIHRoZSBxdWVyeSBpbnRlcnZhbCBiZWxvdyAxNSBzZWNvbmRzLCBhbmQgdGhlIE1MRCBjb25m aWd1cmF0aW9uIGFmZmVjdHMgdG8gdGhlIHdob2xlIGRldmljZS4gU28sIGluIHByYWN0aWNlLCB0 aGUgcG90ZW50aWFsIGNvbmZpZ3VyYXRpb24gb2YgdGhlIHF1ZXJ5IGludGVydmFsIHRvIDAgc2Vj LiBzZWVtcyB0byBiZSBmYXIgZnJvbSBjb21tb24uDQoNCldoYXQgaGFwcGVucyBpZiB0aGUgc3Vi c2NyaXB0aW9uIHN0YXRlIGRvZXNuJ3QgZml0IGluIGEgc2luZ2xlIFBCVS9QQkE/DQpDYW4gbXVs dGlwbGUgbWVzc2FnZXMgYmUgc2VudD8NCg0KW0x1aXM+Pl0gVGhlIHNvbHV0aW9uIGVuY2Fwc3Vs YXRlcyBlYWNoIGluZGl2aWR1YWwgbXVsdGljYXN0IG1lbWJlcnNoaXAgY29udGV4dCBpbiBhbiBp bmRlcGVuZGVudCBUTFYgYWN0aXZlIG11bHRpY2FzdCBzdWJzY3JpcHRpb24gbW9iaWxpdHkgb3B0 aW9uLCBhbGxvd2luZyB0byB0cmFuc21pdCBhIGxhcmdlIHN1YnNjcmlwdGlvbiBzdGF0ZSBpbiBt dWx0aXBsZSBtZXNzYWdlcyBpZiBuZWVkZWQuIFRoZSBtZWNoYW5pc20gZm9yIGRvaW5nIHRoYXQg d291bGQgbm90IGJlIGRpZmZlcmVudCB0byB3aGF0ZXZlciBtZWNoYW5pc20gZGVmaW5lZCBpbiBQ TUlQdjYgZm9yIGFueSBvdGhlciBvcHRpb24gb3Igc2V0IG9mIG9wdGlvbnMgaW4gY2FzZSBhIHNp bmdsZSBQQlUvUEJBIG1lc3NhZ2UgY291bGQgbm90IHRyYW5zZmVyIGFsbCB0aGUgcmVxdWlyZWQg Y29udGVudCBpbiBhIHNpbmdsZSBtZXNzYWdlLg0KDQpJbiA0LjMuMS4yLjIuICBNZXNzYWdlIGZv cm1hdA0KRG8geW91IG5lZWQgdGhlIEkgZmxhZz8gQ2FuJ3QgdGhlIHJlY2VpdmVyIGp1c3QgY2hl Y2sgYWxsIHRoZSBvcHRpb25zIHRvIHNlZSBpZiB0aGVyZSBhcmUgYW55IEFjdGl2ZSBNdWx0aWNh c3QgU3Vic2NyaXB0aW9uIG9wdGlvbnM/DQoNCltMdWlzPj5dIFRoZSBwb2ludCBpcyB0aGF0IGlu IGNhc2UgdGhlIHJlY2VpdmVyIGp1c3QgY2hlY2sgdGhlIG9wdGlvbnMgYW5kIHRoZSBTdWJzY3Jp cHRpb24gUmVzcG9uc2UgbWVzc2FnZSBkb2VzIG5vdCBpbmNsdWRlIGFueSBtdWx0aWNhc3Qgc3Vi c2NyaXB0aW9uIGluZm9ybWF0aW9uLCB0aGUgcmVjZWl2ZXIgY2Fubm90IGNsZWFybHkgZGV0ZXJt aW5lIGlmIHRoZXJlIGlzIG5vdCBhY3R1YWxseSBhbnkgb24tZ29pbmcgbXVsdGljYXN0IHN1YnNj cmlwdGlvbiBvciBpZiB0aGVyZSBpcyBhbiBlcnJvciBpbiB0aGUgbWVzc2FnZS4gVGhlIGZsYWcg SSBhc3Npc3RzIHRoZSByZWNlaXZlciBpbiBjb3JyZWN0bHkgcHJvY2Vzc2luZyB0aGUgbWVzc2Fn ZS4gSW4gY2FzZSB0aGVyZSBpcyBubyBhbnkgb24tZ29pbmcgbXVsdGljYXN0IHN1YnNjcmlwdGlv biAod2l0aCBJPTApIHRoZSByZWNlaXZlciBjYW4gYXZvaWQgdGhlIHByb2Nlc3Npbmcgb2YgdGhl IHJlc3Qgb2YgdGhlIG1lc3NhZ2U7IG90aGVyd2lzZSAod2l0aCBJPTEpIHRoZSByZWNlaXZlciBy ZWFsaXplcyB0aGVyZSB3YXMgYW4gZXJyb3IgYW5kIGNhbiB0cmlnZ2VyIHNvbWUgZnVydGhlciBh Y3Rpb24gdG8gc29sdmUgaXQgKGUuZy4sIHJhaXNlIGFuIGFsYXJtKS4NCg0KSXMgaXQgcmVhbGx5 IHdvcnRoIGhhdmluZyB0aGUgb3B0aW1pemF0aW9uIHdpdGggdGhlIEEgZmxhZyBpZiBuZXcgbWVz c2FnZSB0eXBlcyBhcmUgcmVxdWlyZWQ/IE1heSBpdCBiZSBwb3NzaWJsZSB0byBtYWtlIHVzZSBv ZiB0aGUgUEJVIG1lc3NhZ2UgaW5zdGVhZD8NCg0KW0x1aXM+Pl0gIERlc3BpdGUgdGhlIGV4dGVu c2lvbiBvZiBQQlUgbWVzc2FnZXMgY291bGQgaGF2ZSBiZWVuIGEgZGVzaWduIG9wdGlvbiwgaW4g b3VyIG9waW5pb24gdGhlIHVzZSBvZiBzcGVjaWZpYyBwdXJwb3NlIG1lc3NhZ2VzIHJlcHJlc2Vu dHMgYSBtb3JlIGxpZ2h0d2VpZ2h0IG1ldGhvZCBmb3Igc2lnbmFsaW5nIHRoaXMgaXNzdWUuIFRo ZQ0KUEJVL1BCQSBzZXF1ZW5jZSBpcyB0aWdodGx5IHJlbGF0ZWQgdG8gbG9jYXRpb24gcmVnaXN0 cmF0aW9uIGV2ZW50cyB3aGlsZSB0aGUgbXVsdGljYXN0IGFjdGl2aXR5IGluZGljYXRpb24gcmVm bGVjdHMgYSBjaGFuZ2UgaW4gdGhlIChtdWx0aWNhc3Qgc3RhdHVzKSBzdGF0ZSBvZiB0aGUgcG9p bnQtdG8tcG9pbnQgbGluayBhdCB0aGUgTUFHLiBUaGUgdXNlIG9mIFBCVS9QQkEgc2VxdWVuY2Ug dG8gc2lnbmFsIHRoYXQgc2VlbXMgYXJ0aWZpY2lhbC4NCg0KTm90ZSB0aGF0IHRoZXJlIG1heSBi ZSBsZXNzIHNpZ25hbGluZyBieSBuZWVkbGVzc2x5IHF1ZXJ5aW5nIHRoZSBwTUFHIG9uIGhhbmRv dmVyLCBpbnN0ZWFkIG9mIHNpZ25hbGluZyB0aGUgTE1BIGVhY2ggdGltZSBhIE1OIHN0YXJ0cyBq b2luaW5nIG9yIGxlYXZpbmcgbXVsdGljYXN0IGdyb3Vwcy4NCg0KW0x1aXM+Pl0gVGhlIHNpZ25h bGluZyBvZiB0aGUgbXVsdGljYXN0IGFjdGl2aXR5IGJldHdlZW4gTUFHIGFuZCBMTUEgaXMgcHJv cG9zZWQgbm90IHBlciBtdWx0aWNhc3QgZ3JvdXAgcmVxdWVzdCBmcm9tIHRoZSBNTiwgYnV0IGZv ciB0aGUgZHVyYXRpb24gb2YgdGhlIG11bHRpY2FzdCBhY3Rpdml0eSBieSB0aGUgTU4sIGluIG90 aGVyIHdvcmRzLCB0aGUgdGltZSB3aGlsZSB0aGUgTUFHIG1haW50YWlucyBhIG11bHRpY2FzdCBz dGF0dXMgZm9yIHRoZSBNTiBvbiB0aGUgcG9pbnQtdG8tcG9pbnQgbGlua3MuIFRoZSBhY3Rpdml0 eSBpcyBzaWduYWxlZCBPTiBvbmNlIHRoZSBNTiByZXF1ZXN0IGEgc3Vic2NyaXB0aW9uIHRvIGEg bXVsdGljYXN0IGdyb3VwLCBhbmQgaXQgaXMgc2lnbmFsZWQgT0ZGIHdoZW4gbm8gbW9yZSBjaGFu bmVscyBhcmUgcmVxdWVzdGVkIChpLmUuLCB0aGUgbGFzdCBzdWJzY3JpYmVkIGNoYW5uZWwgaXMg bGVmdCkuIEluIHRoZSBtZWFudGltZSB0aGUgTU4gY2FuIGxlYXZlIG9yIGpvaW4gZGlmZmVyZW50 IG11bHRpY2FzdCBncm91cHMsIGJ1dCBubyBzaWduYWxpbmcgaXMgdHJpZ2dlcmVkIGJlY2F1c2Ug dGhlIGFjdGl2aXR5IGlzIG1haW50YWluZWQuIFNvLCBpdCBjYW4gYmUgc2VlbiBhcyBhIGNvdXBs ZSBvZiBtZXNzYWdlcyBmb3IgdGhlIGR1cmF0aW9uIG9mIHRoZSBtdWx0aWNhc3Qgc2Vzc2lvbi4g V2UgY2FuIGFzc3VtZSB0aGF0IHRoZSBNTiBjdXN0b21lciBiYXNlIHNpbXVsdGFuZW91c2x5IGlu IGFjdGl2ZSBtdWx0aWNhc3QgbW9kZSBpcyBsb3dlciB0aGFuIHRoZSBnZW5lcmFsIE1OIGN1c3Rv bWVyIGJhc2UuDQoNCkRvIHlvdSBuZWVkIHRvIGFsbG93IEhvbWUgTmV0d29yayBQcmVmaXggaW4g dmFyaW91cyBtZXNzYWdlcz8gRG9uJ3QgeW91IGp1c3QgbmVlZCB0aGUgTU5JIG9wdGlvbj8gRS5n LiBpbiB0aGUgTUFJL01BSUEgbWVzc2FnZXMuDQoNCltMdWlzPj5dIFRoZSByYXRpb25hbGUgZm9y IGluY2x1ZGluZyB0aGUgSE5QcyBpcyBmb3IgZmFjaWxpdGF0aW5nIHRoZSBtYW5hZ2VtZW50IG9m IHRoZSBtdWx0aWNhc3Qgc3Vic2NyaXB0aW9uIHdoZW4gdGhlIE1OIGhhcyBkaWZmZXJlbnQgSE5Q cyB3aGlsZSBhdHRhY2hlZCB0byBkaWZmZXJlbnQgbmV0d29ya3MgKGUuZy4sIEludGVybmV0IGFu ZCBJbnRyYW5ldCkuIFRoZXJlIGNvdWxkIGJlIGRpZmZlcmVudCBjcml0ZXJpYSBwZXIgbmV0d29y ayBpbiB0ZXJtcyBvZiB3aGljaCBjb250ZW50IGNhbiBiZSBzdWJzY3JpYmVkIHRvIG9yIG5vdCAo ZS5nLiwgY2VydGFpbiBtdWx0aWNhc3QgZ3JvdXBzIGNvdWxkIG5vdCBiZSBhbGxvd2VkIHRvIGJl IHJlY2VpdmVkIGJ5IHRoZSBJbnRyYW5ldCkuIFVuZGVyIHRoZXNlIGNpcmN1bXN0YW5jZXMsIHRo ZXJlIGNvdWxkIGJlIGEgaGFuZG92ZXIgcHJvY2VzcyBmb3Igb25lIG9mIHRoYXQgbmV0d29ya3Ms IGJ1dCBub3QgZm9yIHRoZSBvdGhlci4gSW4gdGhhdCBjYXNlIGl0IGlzIG5lZWRlZCB0byB0cmFj ayBleGFjdGx5IHdoYXQgcG9pbnQgb2YgYXR0YWNobWVudCBpcyBjaGFuZ2luZywgdG8gdHJpZ2dl ciBvciBub3QgdGhlIG11bHRpY2FzdCBoYW5kb3ZlciBvcHRpbWl6YXRpb24gcHJvY2VzcyAoaWYg dGhlcmUgaXMgbm8gYWN0aXZlIHN1YnNjcmlwdGlvbiBvbiB0aGF0IGludGVyZmFjZSwgdGhlbiB0 aGVyZSBpcyBubyBuZWVkIHRvIGFwcGx5IGFueSBvcHRpbWl6YXRpb24pLg0KDQpJbiA1LjEuMiBm aWd1cmUgMy4gWW91IG5lZWQgdG8gd3JpdGUgc29tZXRoaW5nIG90aGVyIHRoYW4gTUxEIERvbmUg dG8gdGFrZSBjYXJlIG9mIE1MRHYyIHRoYXQgb25seSBoYXMgcmVwb3J0cy4gSSBrbm93IHdoYXQg eW91IGFyZSB0cnlpbmcgdG8gc2F5IHRob3VnaC4NCg0KW0x1aXM+Pl0gUmlnaHQuIFdlIHByb3Bv c2UgdG8gY2hhbmdlIGl0IGluIEZpZ3VyZSAzIGJ5IE1MRCBSZXBvcnQsIGFuZCBpbiB0aGUgdGV4 dCBqdXN0IGJlbG93IGJ5ICJNTEQgUmVwb3J0IG1lc3NhZ2UgKHdpdGggYSBmaWx0ZXIgbW9kZSBj aGFuZ2UgcmVjb3JkIGluZGljYXRpbmcgRVhDTFVERSBtb2RlIGZvciB0aGUgbGFzdCBzdWJzY3Jp YmVkIG11bHRpY2FzdCBncm91cCkiLg0KDQpUaGVyZSBzaG91bGQgYmUgc29tZSBsaW1pdCBmb3Ig aG93IGxvbmcgdGhlIExNQSBrZWVwcyB0aGUgaW5mb3JtYXRpb24gaW4gdGhlIHByb2FjdGl2ZSBj YXNlLCBvciByYXRoZXIsIGlmIHRoZXJlIGlzIG5vdCBhIG5ldyBuTUFHIHdpdGhpbiBhIHJlYXNv bmFibGUgdGltZS4NCg0KW0x1aXM+Pl0gU2luY2UgdGhlIGluZm9ybWF0aW9uIGlzIGtlcHQgaW4g dGhlIGJpbmRpbmcgY2FjaGUsIHdoYXQgd2UgYXJlIHByb3Bvc2luZyBpbiA1LjIuMS4xIGlzIHRo YXQgdGhlIG11bHRpY2FzdCBpbmZvcm1hdGlvbiBpcyByZW1vdmVkIHRvZ2V0aGVyIHdpdGggdGhl IHJlc3Qgb2YgdGhlIGJpbmRpbmcgZGF0YWJhc2UgZm9yIHRoZSBNTiBhY2NvcmRpbmcgdG8gc3Rh bmRhcmQgUE1JUHY2IHByb2NlZHVyZXMuDQoNCkl0IHNob3VsZCBiZSBtYWRlIGNsZWFyIHRoYXQg dGhlIG5NQUcgc2hvdWxkIHN0aWxsIEFTQVAgc2VuZCBNTEQgYSBxdWVyeSB0byBjaGVjayB0aGUg aG9zdHMgc3Vic2NyaXB0aW9uIHN0YXRlLiBNYXliZSBpdCBpcyBhbHJlYWR5IHN0YXRlZCBzb21l d2hlcmU/DQoNCltMdWlzPj5dIFRoaXMgcHJvcG9zYWwgaXMgYW4gb3B0aW1pemF0aW9uIG9mIHRo ZSBiYXNlIHNvbHV0aW9uIGJ1dCBkb2VzIG5vdCBzdWJzdGl0dXRlIHRoZSBwcm9jZXNzZXMgc3Rh bmRhcmRpemVkIGluIFJGQzYyMjQuIFRoZW4gdGhlIHByb3Bvc2FsIGRvZXMgbm90IHByZXZlbnQg dGhlIGRlbGl2ZXJ5IG9mIHRoZSBNTEQgcXVlcnkgb25jZSB0aGUgTU4gYXR0YWNoZXMgYSBuTUFH LCB3aGljaCBpcyBpbnRyaW5zaWNhbGx5IHBhcnQgb2YgdGhlIGFib3ZlIFJGQy4gV2UgY2FuIGlu Y2x1ZGUgc29tZSB0ZXh0IHJlZmVycmluZyB0aGlzLg0KDQpJbiBzZWN0aW9uIDcgYWJvdXQgY28t ZXhpc3RlbmNlLiBJIHRoaW5rIHRoZSBNQUcgc2hvdWxkIG9ubHkgdGVsbCB0aGUgTE1BIGFib3V0 IHRoZSBzdWJzY3JpcHRpb24gaW5mb3JtYXRpb24gZm9yIHRoZSAoUyxHKXMgb3IgR3Mgd2hlcmUg aXQgZGVjaWRlZCB0byBzZW5kIElHTVAgcmVwb3J0cy9qb2lucyBvbiB0aGUgTE1BIHR1bm5lbC4N Cg0KW0x1aXM+Pl0gRnJvbSBvdXIgcG9pbnQgb2YgdmlldywgaXQgaXMgcmVxdWlyZWQgaW4gYW55 IGNhc2UgaW4gdGhlIHByb2FjdGl2ZSBjYXNlLCBzaW5jZSB0aGUgaGFuZG92ZXIgb3B0aW1pemF0 aW9uIGFwcGxpZXMgZWl0aGVyIGlmIHRoZSBNQUcgZ2V0cyB0aGUgbXVsdGljYXN0IGdyb3VwIGZy b20gdGhlIExNQSAocmVtb3RlIHN1YnNjcmlwdGlvbikgb2YgZnJvbSB0aGUgbG9jYWwgbXVsdGlj YXN0IHJvdXRlciAobG9jYWwgc3Vic2NyaXB0aW9uKS4gVGhlIG11bHRpY2FzdCBjb250ZXh0LCBr ZXB0IGluIHRoZSBiaW5kaW5nIGNhY2hlLCBpcyBhIHBhcmFtZXRlciBvZiB0aGUgY29tbXVuaWNh dGlvbiBzZXJ2aWNlIG5vdCBib3VuZCB0byB0aGUgd2F5IHRoZSBtdWx0aWNhc3QgaXMgc2VydmVk Lg0KDQoNCkEgZmV3IE1pbm9yIGlzc3VlcyBiZWxvdy4NCg0KW0x1aXM+Pl0gTm90ZWQuIFdlIHdp bGwgdXBncmFkZSBuZXh0IGRyYWZ0IHZlcnNpb24gYWNjb3JkaW5nbHkuDQoNCkNvbW1lbnRzIGZv ciBzZWN0aW9uIDEuICBJbnRyb2R1Y3Rpb24NCg0KICAgIFRoZSBiYXNlIHNvbHV0aW9uIGRlc2Ny aWJpbmcgaG93IGNvbnRpbnVvdXMgbXVsdGljYXN0IHNlcnZpY2UNCiAgICBkZWxpdmVyeSBjYW4g YmUgcHJvdmlkZWQgaW4gUHJveHkgTW9iaWxlIElQdjYgZG9tYWlucyBpcyBkZXNjcmliZWQgaW4N CiAgICBSRkMgNjIyNCBbUkZDNjIyNF0uICBUaGlzIHNvbHV0aW9uIHNwZWNpZmllcyB0aGUgYmFz aWMgZnVuY3Rpb25hbGl0eQ0KICAgICAgICAgICAgICAgICAgICAgICAgXl5eXl5eDQoNCkl0J3Mg YSBiaXQgdW5jbGVhciB3aGV0aGVyICJUaGlzIiByZWZlcnMgdG8gNjIyNCBvciB0aGlzIGRvY3Vt ZW50Lg0KU3VnZ2VzdCB3cml0aW5nICJ0aGUgYmFzZSBzb2x1dGlvbiBzcGVjaWZpZXMiLCBvciBt YXliZSBqdXN0ICJpdCBzcGVjaWZpZXMiLg0KDQogICAgbW9iaWxlIG5vZGUpLCB0aGVyZSBpcyBu byBhIGdlbmVyaWMgc3RhbmRhcmQgc29sdXRpb24gZm9yIHRoZQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBeXl4NCnJlbW92ZSAiYSIuDQoNCiAgICBJR01QL01MRCBwcm90b2NvbHMuICBC b3RoIHByb3RvY29scyBzZW5kIG11bHRpY2FzdCBtZW1iZXJzaGlwDQogICAgaW50ZXJyb2dhdGlv biBtZXNzYWdlcyB3aGVuIGEgbmV3IGxpbmsgaXMgdXAuICBUaGUgcmVzcG9uc2UgdG8gc3VjaCBh DQogICAgXl5eXl5eXl5eXl5eXg0KDQoicXVlcnkiLiBDb25zaWRlciB1c2luZyAicXVlcnkiIGlu c3RlYWQgb2YgImludGVycm9nYXRpb24iIG90aGVyIHBsYWNlcyB0b28uDQoNCiAgIG8gIFRoZSBz b2x1dGlvbiBzaG91bGQgbm90IGltcGFjdCBvbiBleGlzdGluZyBtdWx0aWNhc3QgcHJvdG9jb2xz Lg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXiBqdXN0ICJpbXBhY3Qi IG9yICJoYXZlIGltcGFjdCBvbiIuDQoNCiAgIFByZXNlbnQgc3BlY2lmaWNhdGlvbiBhZGRyZXNz ZXMgYWxsIHRoZXNlIHJlcXVpcmVtZW50cywgYXMgZGVzY3JpYmVkDQogICAgaW4gdGhlIGZvbGxv d2luZyBzZWN0aW9ucy4NCg0KU3RhcnQgd2l0aCAiVGhlIHByZXNlbnQiIEkgdGhpbmsuDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXVsdGltb2IgbWFp bGluZyBsaXN0DQptdWx0aW1vYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tdWx0aW1vYg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlv LiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOz biBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8u DQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUu IFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1z IHNldCBvdXQgYXQ6DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNw eA0K From sarikaya2012@gmail.com Mon Feb 18 14:19:19 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 67ACB21F8CBC for ; Mon, 18 Feb 2013 14:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibfxr49t-+aw for ; Mon, 18 Feb 2013 14:19:18 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 75C3C21F8C5C for ; Mon, 18 Feb 2013 14:19:17 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id fs12so5871141lab.39 for ; Mon, 18 Feb 2013 14:19:16 -0800 (PST) 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=GH6ndmoruk66CxHAyzdIKzLYBI10eCYedkxmgUpoBnA=; b=HNFwzH9T0Fi9da2aTqBSR7PaJoLkpetsXS77ibEeIt7QqTegopi/rIhpqbeFvFTo5m z9CZlDn8NhS1DVDlnx3BRcKlHKz1Yb2E/km8cwWy2NlsVJ/MiPwZuwRmOMUIxgrFrdOp R9VQzyyVQRma0+3uAjIcqyn7357ioNJX95o+P6Fr6pHzK2bxnIfcB6I+qChUzPXSve7G jZ0gFCKwJVa6qv/KMDVggyDZxzIfyIivtmpdAF34B2MkRulrgdp+LG8ntlht9HzODGtK f5k4Q+RrlmioumDAng4j7LMSNXUhrnC/84O6lD57VURMZOG87f0YC0jy4EolAgGFVTr1 XYJw== MIME-Version: 1.0 X-Received: by 10.112.28.102 with SMTP id a6mr6213900lbh.109.1361225956246; Mon, 18 Feb 2013 14:19:16 -0800 (PST) Received: by 10.114.28.168 with HTTP; Mon, 18 Feb 2013 14:19:16 -0800 (PST) In-Reply-To: <823234EF5C7C334998D973D822FF801B315A31D3@EX10-MB2-MAD.hi.inet> References: <823234EF5C7C334998D973D822FF801B315A31D3@EX10-MB2-MAD.hi.inet> Date: Mon, 18 Feb 2013 16:19:16 -0600 Message-ID: From: Behcet Sarikaya To: LUIS MIGUEL CONTRERAS MURILLO Content-Type: multipart/alternative; boundary=f46d040168b394c4f204d6071dd6 Cc: "multimob@ietf.org" Subject: Re: [multimob] draft-ietf-multimob-handover-optimization-01 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: Mon, 18 Feb 2013 22:19:19 -0000 --f46d040168b394c4f204d6071dd6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Luis, Please see my replies inline. Let's resolve these issues quickly. Regards, Behcet On Mon, Feb 18, 2013 at 3:14 PM, LUIS MIGUEL CONTRERAS MURILLO wrote: > Hi Behcet, > > > > Thanks for your comments, and sorry for the late response. > > > > Please, find our answers in line > > > > Best regards, > > > > Luis > > > > *De:* multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] *En > nombre de *Behcet Sarikaya > *Enviado el:* jueves, 31 de enero de 2013 0:28 > *Para:* multimob@ietf.org > *Asunto:* [multimob] draft-ietf-multimob-handover-optimization-01 > > > > Hi Carlos, authors, > > Some initial comments on your draft: > Section 4.2 states that two new flags are defined but Flag A is not used > in the line. > > *[Luis>>] Actually section 4.2 covers the description of both flags, A > and S. There is an specific section inside for any of them, being 4.2.1 > devoted to flag S, and section 4.2.2 to flag A. We can improve the text > explicitly mention this to help the reader.* > > Here I meant to say that A flag is not sent/received in PBU/PBA or other messages you defined. > Subscription Query/Response messages: why not use the Update Notification > message in draft-ietf-netext-update-notifications-00? > > *[Luis>>] The mechanism described in > draft-ietf-netext-update-notifications-00 focus on notifications triggere= d > by the LMA. Despite the query from LMA to pMAG in the proactive handover > case could be seen as one potential use case, the scope of the Subscripti= on > Query/Response messages is wider. These messages are also used by the nMA= G > for retrieving the multicast subscription information from the LMA in > situations where the unicast binding is allowed to progress till the > multicast information is ready, preventing large delays of the binding > acknowledgement for unicast traffic (see section 5.2.4). In our opinion, = a > common mechanism should be used in both cases.* > > Why is it necessary to define messages other than PBU/PBA from MAG to LMA= , > i.e. Act Ind? > > *[Luis>>] The idea behind the new messages described in the WG draft is > the use of specific and lightweight signaling methods for handling some > flags in support of multicast handover optimization. For instance, the > multicast activity indication represents the change in the multicast stat= us > state ( subscribed / not subscribed to any group) of one interface in the > MAG. Strictly speaking, this event is not related to the purpose of PBU/P= BA > signaling.* > > If you remove the A flag and do the activity checking only right after th= e handover, you are simplifying the protocol and not losing much. Remember that LMA can check the aggregated multicast state and find out that some multicast sessions are active. Please see more on this below. If we agree on this then only Subscription Request/Reply remains to be resolved. Since these are not generic notification messages we can not use draft-ietf-netext-update-notifications, which is OK. So you can keep Subscription Request/Reply. > Regarding Figs 1 & 2, and also the Flag A, MLD Done is only in MLDv1 and > has been removed from MLDv2, check Appendix B in RFC 3810. > > *[Luis>>] That=92s correct, although the parts of the text where the > reference to the MLD Done message appear are actually on Figure 3 and the > first bullet below that figure. Our proposal is to change the text of the > figure from =93MLD Done=94 to =93MLD Report=94 for brevity,* > MLD Report is too generic. > * and to change the text in the bullet from =93MLD Done=94 to =93MLD Repo= rt > message (with a filter mode change record indicating EXCLUDE mode for the > last subscribed multicast group)=94.* > > > Exclude mode is only for SSM. But if you remove the A flag, you don't really need any of these things, see below. > MLD Done was mimicking IGMPv2 Leave message which is not mentioned in IPv= 4 > support. > > The fact that MLD Done (or IGMP Leave) no longer available in SSM makes m= e > question the A Flag. How could LMA sustain a valid value of the A Flag? > OTOH, A Flag is only used for optimization, as shown in Figure 6. > Would it be possible to not define A Flag and use S Flag? > > *[Luis>>] Flag A helps to optimize the number of messages between PMIP > entities by limiting the interrogation of the pMAG by the LMA in the case > of reactive handover just to the case where the MN in the handover is > maintaining an active multicast session.* > Well this information is already there in LMA as the aggregated multicast state. What you want to do is to make it MN specific. You seem to assume that LMA is unicast only. The resulting protocol is too heavy. > * The proposed solution could work without using the flag A, but at the > cost of delivering much more signaling messages than the strictly needed = * > Why? I think that using Fig. 5, steps 1-3 in case S=3D1 in all cases would be go= od enough. By removing the A flag, your protocol will be so much simplified, my guess is you can save 10 pages from the document. So I encourage you to remove the A flag. What you are losing is so little. > *(all the messages for the MNs without multicast session does not need > any supporting message for multicast handover optimization).* > > > Yes but this is already indicated with S=3D0. > > Regards, > > Behcet > > ------------------------------ > > 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 > --f46d040168b394c4f204d6071dd6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Luis,

Please see my replies inline. Let's resolve these issue= s quickly.

Regards,

Behcet

= On Mon, Feb 18, 2013 at 3:14 PM, LUIS MIGUEL CONTRERAS MURILLO <lmcm@tid.es&= gt; wrote:

Hi Behcet,

=A0

Thanks for your comments,= and sorry for the late response.

=A0

Please, find our answers = in line

=A0

Best regards,

=A0

Luis

=A0

De: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] En nombre de Behcet Sarikaya
Enviado el: jueves, 31 de enero de 2013 0:28
Para: multimo= b@ietf.org
Asunto: [multimob] draft-ietf-multimob-handover-optimization-01

=A0

Hi Carlos, authors,
Some initial comments on your draft:
Section 4.2 states that two new flags are defined but Flag A is not used in= the line.

[Luis>>] Actually section 4.2 covers the description of b= oth flags, A and S. There is an specific section inside for any of them, being 4.2.1 devoted to flag S, and section 4.2.2 to flag A. We ca= n improve the text explicitly mention this to help the reader.

Here I meant to say that A flag is no= t sent/received in PBU/PBA or other messages you defined.
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Subscription Query/Response messages: why not use the Update Notification m= essage in draft-ietf-netext-update-notifications-00?

[Luis>>] The mechanism described in draft-ietf-netext-upd= ate-notifications-00 focus on notifications triggered by the LMA. Despite the query from LMA to pMAG in the proactive handover case could be= seen as one potential use case, the scope of the Subscription Query/Respon= se messages is wider. These messages are also used by the nMAG for retrievi= ng the multicast subscription information from the LMA in situations where the unicast binding is allowed to progres= s till the multicast information is ready, preventing large delays of the b= inding acknowledgement for unicast traffic (see section 5.2.4). In our opin= ion, a common mechanism should be used in both cases.

Why is it necessary to define messages other than PBU/PBA from MAG to LMA, = i.e. Act Ind?

[Luis>>] The idea behind the new messages described in th= e WG draft is the use of specific and lightweight signaling methods for handling some flags in support of multicast handover optimization. For= instance, the multicast activity indication represents the change in the m= ulticast status state ( subscribed / not subscribed to any group) of one in= terface in the MAG. Strictly speaking, this event is not related to the purpose of PBU/PBA signaling.<= /b>

If you remove the A flag and do the a= ctivity checking only right after the handover, you are simplifying the pro= tocol and not losing much. Remember that LMA can check the aggregated multi= cast state and find out that some multicast sessions are active.
Please see more on this below.

If we agree on this then only Subscri= ption Request/Reply remains to be resolved.
Since these are not generic = notification messages we can not use draft-ietf-netext-update-notifications= , which is OK.
So you can keep Subscription Request/Reply.
=A0

Regarding Figs 1 & 2, and also the Flag A, MLD Done is only in MLDv1 an= d has been removed from MLDv2, check Appendix B in RFC 3810.

[Luis>>] That=92s correct, although the parts of the text= where the reference to the MLD Done message appear are actually on Figure 3 and the first bullet below that figure. Our proposal is to cha= nge the text of the figure from =93MLD Done=94 to =93MLD Report=94 for brev= ity,

MLD Report is too gene= ric.
=A0

and to change the text in the bullet = from =93MLD Done=94 to =93MLD Report message (with a filter mode change rec= ord indicating EXCLUDE mode for the last subscribed multicast group)=94.


<= /blockquote>
Exclude mode is only for SSM.
But if you remove the A f= lag, you don't really need any of these things, see below.
=A0

MLD Done was mimicking IGMPv2 Leave message which is not mentioned in IPv4 = support.

The fact that MLD Done (or IGMP Leave) no longer available in SSM makes me = question the A Flag. How could LMA sustain a valid value of the A Flag?
OTOH, A Flag is only used for optimization, as shown in Figure 6.
Would it be possible to not define A Flag and use S Flag?

[Luis>>] Flag A helps to optimize the number of messages = between PMIP entities by limiting the interrogation of the pMAG by the LMA in the case of reactive handover just to the case where the MN = in the handover is maintaining an active multicast session.<= /p>

Well this information is already there in = LMA as the aggregated multicast state. What you want to do is to make it MN= specific. You seem to assume that LMA is unicast only. The resulting proto= col is too heavy.
=A0

The proposed solution could work with= out using the flag A, but at the cost of delivering much more signaling mes= sages than the strictly needed

=A0Wh= y?
I think that using Fig. 5, steps 1-3 in case S=3D1 in all cases woul= d be good enough.
By removing the A flag, your protocol will be so much = simplified, my guess is you can save 10 pages from the document.
So I encourage you to remove the A flag. What you are losing is so little.<= br>

(all the messages for the MNs without multicast session do= es not need any supporting message for multicast handover optimization).


<= /blockquote>
Yes but this is already indicated with S=3D0.
=A0


Regards,

Behcet



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

--f46d040168b394c4f204d6071dd6-- From sarikaya2012@gmail.com Mon Feb 18 15:00:53 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 B1D6D21E803A for ; Mon, 18 Feb 2013 15:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N40Ny+ZIqNdR for ; Mon, 18 Feb 2013 15:00:53 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id CFD9D21F8C02 for ; Mon, 18 Feb 2013 15:00:52 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id gg6so4559941lbb.41 for ; Mon, 18 Feb 2013 15:00:51 -0800 (PST) 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=tm72B36Mpdntvka6ZWpsnZm5eqNhKO2240PSrY7WzJw=; b=I66cOilQ/wMKgLfxaLQ1RBooBHkSwYkysU/uUxIztberIPbjUP12C7rh4TsOvXGwYi lP/wMxVSELxLiG95AtlNRxmriQcUeaqBzU+s42TKn3dtOdaLbTePu7FcU7V/f1rIs58s obu4SkT7qEEeghkaAgjnsh4GufU6U+GwprKMm298WCWvbhJ7TAb+D816PKniidr31bOS O3ILOOGDNGYjMpeVO47tS0SahH3aPv0NqvnNe537wY4VCnYHyvM5aPODqCJVzMvrB6Th Pdy6k1eW5hT7VQhfB+RuUKpX5Tc/BZnZOga6CCytvh/QLc7qdaKnY+MSnVomL7e1FSZb 4Ajw== MIME-Version: 1.0 X-Received: by 10.112.101.230 with SMTP id fj6mr6246943lbb.115.1361228451709; Mon, 18 Feb 2013 15:00:51 -0800 (PST) Received: by 10.114.28.168 with HTTP; Mon, 18 Feb 2013 15:00:51 -0800 (PST) Date: Mon, 18 Feb 2013 17:00:51 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: multipart/alternative; boundary=f46d0401f99b52846d04d607b28a Subject: [multimob] draft-asaeda-multimob-pmip6-ropt-with-pim-00.txt 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: Mon, 18 Feb 2013 23:00:53 -0000 --f46d0401f99b52846d04d607b28a Content-Type: text/plain; charset=ISO-8859-1 A new draft has been submitted to Multimob. Please read and comment: http://tools.ietf.org/id/draft-asaeda-multimob-pmip6-ropt-with-pim-00.txt --f46d0401f99b52846d04d607b28a Content-Type: text/html; charset=ISO-8859-1

A new draft has been submitted to Multimob.

Please read and comment:
http://tools.ietf.org/id/draft-asaeda-multimob-pmip6-ropt-with-pim-00.txt

--f46d0401f99b52846d04d607b28a-- From asaeda@sfc.wide.ad.jp Mon Feb 18 18:15:47 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 DB9D521F8CEE for ; Mon, 18 Feb 2013 18:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4sl3QXj+XiT for ; Mon, 18 Feb 2013 18:15:47 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEB621F8CDA for ; Mon, 18 Feb 2013 18:15:46 -0800 (PST) Received: from localhost (unknown [202.249.37.10]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 939AD2780A0; Tue, 19 Feb 2013 11:15:44 +0900 (JST) Date: Tue, 19 Feb 2013 11:15:47 +0900 (JST) Message-Id: <20130219.111547.255992127.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, sarikaya2012@gmail.com From: Hitoshi Asaeda In-Reply-To: References: X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] draft-asaeda-multimob-pmip6-ropt-with-pim-00.txt 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: Tue, 19 Feb 2013 02:15:48 -0000 Thank you, Behcet, for announcing this draft. > A new draft has been submitted to Multimob. > > Please read and comment: > http://tools.ietf.org/id/draft-asaeda-multimob-pmip6-ropt-with-pim-00.txt Although this draft is a new draft (-00), it is a revised version of draft-asaeda-multimob-pmip6-extension-11. The new submission is aimed to provide the appropriate draft name, which wouldn't make people confuse. Thanks for your review. Regards, -- Hitoshi Asaeda From sarikaya2012@gmail.com Wed Feb 20 08:48:07 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 EE8A521F8803 for ; Wed, 20 Feb 2013 08:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77o9wQYJlT5i for ; Wed, 20 Feb 2013 08:48:06 -0800 (PST) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 08DB721F87D7 for ; Wed, 20 Feb 2013 08:48:05 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id gf7so6151478lbb.18 for ; Wed, 20 Feb 2013 08:48:04 -0800 (PST) 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=AoT+vPnP/U8fHw5WT4iQ/YeVLe3/wZPxrEKKuV/bSSQ=; b=WMJLzUcdLNTOcmPtt5MKNvCDPMmTlmnVoMbmbiujY+o2NhcJZjNYelhkD3DzUQpDWa 3y2U86PqUnxrLhqojtX46Cb3himbyOiatUXohMlYC3vGP0QnVVasFxnPmRIQH723MuD+ XhfXqIrH/vCdH1u1k7wdKIWO2ZKFCkDDTHFKKus4cOghC48GTZy3nlHF/Jw8ShchvuBH pJAoigAhByQbwuxujNEMr09sYirQ4H1MMcMbD4EpU3H2WV2FnST9DROWtWNUbri+bFzq 2WAE97kWfvFt+ZzaaMllK0hbHlbQ/oq1jczwgzllDDweE8gpfCXhlMf91wwoD74tI73D rY8A== MIME-Version: 1.0 X-Received: by 10.152.109.112 with SMTP id hr16mr18448394lab.38.1361378884452; Wed, 20 Feb 2013 08:48:04 -0800 (PST) Received: by 10.114.28.168 with HTTP; Wed, 20 Feb 2013 08:48:04 -0800 (PST) Date: Wed, 20 Feb 2013 10:48:04 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: multipart/alternative; boundary=bcaec54eea70d0013c04d62ab8ae Subject: [multimob] IETF 86 Draft Agenda 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, 20 Feb 2013 16:48:07 -0000 --bcaec54eea70d0013c04d62ab8ae Content-Type: text/plain; charset=ISO-8859-1 Has been posted at http://www.ietf.org/proceedings/86/agenda/agenda-86-multimob --bcaec54eea70d0013c04d62ab8ae Content-Type: text/html; charset=ISO-8859-1 Has been posted at

http://www.ietf.org/proceedings/86/agenda/agenda-86-multimob


--bcaec54eea70d0013c04d62ab8ae-- From lmcm@tid.es Fri Feb 22 01:32:23 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 6385421F8E04 for ; Fri, 22 Feb 2013 01:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.234 X-Spam-Level: X-Spam-Status: No, score=-4.234 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbAcmtH8ibMz for ; Fri, 22 Feb 2013 01:32:18 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2601421F8DFF for ; Fri, 22 Feb 2013 01:32:16 -0800 (PST) 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 <0MIM00KXI7TQ9Q@tid.hi.inet> for multimob@ietf.org; Fri, 22 Feb 2013 10:32:14 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 3D.D1.05051.E1B37215; Fri, 22 Feb 2013 10:32:14 +0100 (CET) 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 <0MIM00KXD7TP9Q@tid.hi.inet> for multimob@ietf.org; Fri, 22 Feb 2013 10:32:14 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Fri, 22 Feb 2013 10:32:13 +0100 Date: Fri, 22 Feb 2013 09:32:12 +0000 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: X-Originating-IP: [10.95.64.115] To: "sarikaya@ieee.org" Message-id: <823234EF5C7C334998D973D822FF801B315A6815@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_+7w+iEfbInKUFNiu50AsEQ)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: [multimob] draft-ietf-multimob-handover-optimization-01 Thread-index: AQHN/0F7Qi5Ph8IGG0+lcNSYgewrrJiAKiTQgAASjwCABYMLgA== X-AuditID: 0a5f4e69-b7fbe6d0000013bb-37-51273b1e381f X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42Lhivcz1JWzVg806DknZDHjYx+LA6PHkiU/ mQIYo7hsUlJzMstSi/TtErgyOvedZC+Yd4ixou9PN1sD46RljF2MnBwSAiYSv1u/skHYYhIX 7q0Hsrk4hAS2MUrs3bcFyvnNKHHr+i1GCGcmo8TG2z0sIC0sAqoSp46/ZAax2QQMJWbtnMQK YgsLuEh8vzmbCcTmFAiW2PK3kR1ihYLEn3OPwXpFBLQldhzaATaUWWAio8SClolgDbwC3hLd MycyQ9iCEj8m3wNrYBbIlVh06Rg7hC0uMefXRLBljAKyEivPnwYaxAE01FXi2i5eiPlOElN/ tkG9KSCxZM95ZghbVOLl43+sEM/cZpToWDKNZQKj2Cwk62YhWTcLyToIW0/ixtQpbBC2tsSy ha+ZIWxdiRn/DrEgiy9gZF/FKFacVJSZnlGSm5iZk25gpJeRqZeZl1qyiRESf5k7GJfvVDnE KMDBqMTDa6guHSjEmlhWXJl7iFGCg1lJhNfAQj1QiDclsbIqtSg/vqg0J7X4ECMTB6dUA6OO BGuhLZ/B3b8XOqx21HV/tvJYHZHOKenJs+2f+fNyH633n674Cxw8KaT0R7nRReLz0zmdczf1 hP+c4pJ8sERXvTb1luE6jlWrO79JrVrcdYhd9VPfcteUSNZDlTXtllOzV5ZcqBF8N+H+yqiD vM7XF/OfEy3S/2IdebXXSE0+58rhk9yPTiuxFGckGmoxFxUnAgBcdfi/nQIAAA== References: <823234EF5C7C334998D973D822FF801B315A31D3@EX10-MB2-MAD.hi.inet> Cc: "multimob@ietf.org" Subject: Re: [multimob] draft-ietf-multimob-handover-optimization-01 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, 22 Feb 2013 09:32:23 -0000 --Boundary_(ID_+7w+iEfbInKUFNiu50AsEQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi Behcet, The central argument of your comments orbits around the no necessity of imp= lementing the multicast activity indication process, as a way of simplifyin= g the protocol. Actually, the multicast activity indication does not impact= on the performance of the handover optimization, neither for the proactive= nor the reactive cases. The timing for getting the multicast subscription = information ready at the nMAG is the same. However, the presence of the mul= ticast activity indication makes the protocol more efficient in terms of si= gnaling messages in the network for the reactive case when the MN is not ma= intaining an active subscription. We believe it is worth using the multicas= t activity indication as compared to querying the pMAG every time an MN mov= es. This could become relevant in scenarios of high mobility or in scenario= s where the percentage of multicast active MNs is significantly low. Howeve= r, if the WG believes this should not be mandatory, a possibility could be = to implement the multicast activity indication as an option of the protocol= to improve the efficiency in certain scenarios. We would like to know your= opinion and the opinion of the working group about such possibility. Regards Luis De: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Enviado el: lunes, 18 de febrero de 2013 23:19 Para: LUIS MIGUEL CONTRERAS MURILLO CC: multimob@ietf.org; cjbc@it.uc3m.es; Ignacio Soto Campos (isoto@it.uc3m.= es) Asunto: Re: [multimob] draft-ietf-multimob-handover-optimization-01 Hi Luis, Please see my replies inline. Let's resolve these issues quickly. Regards, Behcet On Mon, Feb 18, 2013 at 3:14 PM, LUIS MIGUEL CONTRERAS MURILLO > wrote: Hi Behcet, Thanks for your comments, and sorry for the late response. Please, find our answers in line Best regards, Luis De: multimob-bounces@ietf.org [mailto:mul= timob-bounces@ietf.org] En nombre de Behc= et Sarikaya Enviado el: jueves, 31 de enero de 2013 0:28 Para: multimob@ietf.org Asunto: [multimob] draft-ietf-multimob-handover-optimization-01 Hi Carlos, authors, Some initial comments on your draft: Section 4.2 states that two new flags are defined but Flag A is not used in= the line. [Luis>>] Actually section 4.2 covers the description of both flags, A and S= . There is an specific section inside for any of them, being 4.2.1 devoted = to flag S, and section 4.2.2 to flag A. We can improve the text explicitly = mention this to help the reader. Here I meant to say that A flag is not sent/received in PBU/PBA or other me= ssages you defined. Subscription Query/Response messages: why not use the Update Notification m= essage in draft-ietf-netext-update-notifications-00? [Luis>>] The mechanism described in draft-ietf-netext-update-notifications-= 00 focus on notifications triggered by the LMA. Despite the query from LMA = to pMAG in the proactive handover case could be seen as one potential use c= ase, the scope of the Subscription Query/Response messages is wider. These = messages are also used by the nMAG for retrieving the multicast subscriptio= n information from the LMA in situations where the unicast binding is allow= ed to progress till the multicast information is ready, preventing large de= lays of the binding acknowledgement for unicast traffic (see section 5.2.4)= . In our opinion, a common mechanism should be used in both cases. Why is it necessary to define messages other than PBU/PBA from MAG to LMA, = i.e. Act Ind? [Luis>>] The idea behind the new messages described in the WG draft is the = use of specific and lightweight signaling methods for handling some flags i= n support of multicast handover optimization. For instance, the multicast a= ctivity indication represents the change in the multicast status state ( su= bscribed / not subscribed to any group) of one interface in the MAG. Strict= ly speaking, this event is not related to the purpose of PBU/PBA signaling. If you remove the A flag and do the activity checking only right after the = handover, you are simplifying the protocol and not losing much. Remember th= at LMA can check the aggregated multicast state and find out that some mult= icast sessions are active. Please see more on this below. If we agree on this then only Subscription Request/Reply remains to be reso= lved. Since these are not generic notification messages we can not use draft-ietf= -netext-update-notifications, which is OK. So you can keep Subscription Request/Reply. Regarding Figs 1 & 2, and also the Flag A, MLD Done is only in MLDv1 and ha= s been removed from MLDv2, check Appendix B in RFC 3810. [Luis>>] That's correct, although the parts of the text where the reference= to the MLD Done message appear are actually on Figure 3 and the first bull= et below that figure. Our proposal is to change the text of the figure from= "MLD Done" to "MLD Report" for brevity, MLD Report is too generic. and to change the text in the bullet from "MLD Done" to "MLD Report message= (with a filter mode change record indicating EXCLUDE mode for the last sub= scribed multicast group)". Exclude mode is only for SSM. But if you remove the A flag, you don't really need any of these things, se= e below. MLD Done was mimicking IGMPv2 Leave message which is not mentioned in IPv4 = support. The fact that MLD Done (or IGMP Leave) no longer available in SSM makes me = question the A Flag. How could LMA sustain a valid value of the A Flag? OTOH, A Flag is only used for optimization, as shown in Figure 6. Would it be possible to not define A Flag and use S Flag? [Luis>>] Flag A helps to optimize the number of messages between PMIP entit= ies by limiting the interrogation of the pMAG by the LMA in the case of rea= ctive handover just to the case where the MN in the handover is maintaining= an active multicast session. Well this information is already there in LMA as the aggregated multicast s= tate. What you want to do is to make it MN specific. You seem to assume tha= t LMA is unicast only. The resulting protocol is too heavy. The proposed solution could work without using the flag A, but at the cost = of delivering much more signaling messages than the strictly needed Why? I think that using Fig. 5, steps 1-3 in case S=3D1 in all cases would be go= od enough. By removing the A flag, your protocol will be so much simplified, my guess = is you can save 10 pages from the document. So I encourage you to remove the A flag. What you are losing is so little. (all the messages for the MNs without multicast session does not need any s= upporting message for multicast handover optimization). Yes but this is already indicated with S=3D0. Regards, Behcet ________________________________ 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 ________________________________ 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_+7w+iEfbInKUFNiu50AsEQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi Behcet,

The central argument of= your comments orbits around the no necessity of implementing the multicast= activity indication process, as a way of simplifying the protocol. Actually, the multicast activity indication does not impact on t= he performance of the handover optimization, neither for the proactive nor = the reactive cases. The timing for getting the multicast subscription infor= mation ready at the nMAG is the same. However, the presence of the multicast activity indication makes the= protocol more efficient in terms of signaling messages in the network for = the reactive case when the MN is not maintaining an active subscription. We= believe it is worth using the multicast activity indication as compared to querying the pMAG every time an MN move= s. This could become relevant in scenarios of high mobility or in scenarios= where the percentage of multicast active MNs is significantly low. However= , if the WG believes this should not be mandatory, a possibility could be to implement the multicast activi= ty indication as an option of the protocol to improve the efficiency in cer= tain scenarios. We would like to know your opinion and the opinion of the w= orking group about such possibility.

 

Regards

 

Luis

 

De: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
Enviado el: lunes, 18 de febrero de 2013 23:19
Para: LUIS MIGUEL CONTRERAS MURILLO
CC: multimob@ietf.org; cjbc@it.uc3m.es; Ignacio Soto Campos (isoto@i= t.uc3m.es)
Asunto: Re: [multimob] draft-ietf-multimob-handover-optimization-01<= /span>

 

Hi Luis,

Please see my replies inline. Let's resolve these issues quickly.

Regards,

Behcet

On Mon, Feb 18, 2013 at 3:14 PM, LUIS MIGUEL CONTRER= AS MURILLO <lmcm@tid.es= > wrote:

Hi Behcet,

 

Thanks for y= our comments, and sorry for the late response.

 

Please, find= our answers in line

 

Best regards= ,

 

= Luis

=  

De: multimob-bou= nces@ietf.org [mailto:multimob-bounces@ietf.org] En nombre de Behcet Sarikaya
Enviado el: jueves, 31 de enero de 2013 0:28
Para: multimo= b@ietf.org
Asunto: [multimob] draft-ietf-multimob-handover-optimization-01

 

Hi Carlos, authors,
Some initial comments on your draft:
Section 4.2 states that two new flags are defined but Flag A is not used in= the line.

[Luis>>] Actually section 4.2 covers the description of= both flags, A and S. There is an specific section inside for any of them, being 4.2.1 devoted to flag S, and section 4.2.2 to flag A. We ca= n improve the text explicitly mention this to help the reader.

Here I meant to say that A flag is not sent/received= in PBU/PBA or other messages you defined.
 

Subscription Query/Re= sponse messages: why not use the Update Notification message in draft-ietf-= netext-update-notifications-00?

[Luis>>] The mechanism described in draft-ietf-netext-u= pdate-notifications-00 focus on notifications triggered by the LMA. Despite the query from LMA to pMAG in the proactive handover case could be= seen as one potential use case, the scope of the Subscription Query/Respon= se messages is wider. These messages are also used by the nMAG for retrievi= ng the multicast subscription information from the LMA in situations where the unicast binding is allowed to progres= s till the multicast information is ready, preventing large delays of the b= inding acknowledgement for unicast traffic (see section 5.2.4). In our opin= ion, a common mechanism should be used in both cases.

Why is it necessary to define messages other than PBU/PBA from MAG to LMA, = i.e. Act Ind?

[Luis>>] The idea behind the new messages described in = the WG draft is the use of specific and lightweight signaling methods for handling some flags in support of multicast handover optimization. For= instance, the multicast activity indication represents the change in the m= ulticast status state ( subscribed / not subscribed to any group) of one in= terface in the MAG. Strictly speaking, this event is not related to the purpose of PBU/PBA signaling.<= /b>

If you remove the A flag and do the activity checkin= g only right after the handover, you are simplifying the protocol and not l= osing much. Remember that LMA can check the aggregated multicast state and = find out that some multicast sessions are active.
Please see more on this below.

If we agree on this then only Subscription Request/Reply remains to be reso= lved.
Since these are not generic notification messages we can not use draft-ietf= -netext-update-notifications, which is OK.
So you can keep Subscription Request/Reply.
 

Regarding Figs 1 &= ; 2, and also the Flag A, MLD Done is only in MLDv1 and has been removed fr= om MLDv2, check Appendix B in RFC 3810.

[Luis>>] That’s correct, although the parts of th= e text where the reference to the MLD Done message appear are actually on Figure 3 and the first bullet below that figure. Our proposal is to cha= nge the text of the figure from “MLD Done” to “MLD Report= ” for brevity,

MLD Report is too generic.
 

and to change the text in the bullet from “MLD DoneR= 21; to “MLD Report message (with a filter mode change record indicati= ng EXCLUDE mode for the last subscribed multicast group)”.

 

Exclude mode is only for SSM.
But if you remove the A flag, you don't really need any of these things, se= e below.
 

MLD Done was mimickin= g IGMPv2 Leave message which is not mentioned in IPv4 support.

The fact that MLD Done (or IGMP Leave) no longer available in SSM makes me = question the A Flag. How could LMA sustain a valid value of the A Flag?
OTOH, A Flag is only used for optimization, as shown in Figure 6.
Would it be possible to not define A Flag and use S Flag?

[Luis>>] Flag A helps to optimize the number of message= s between PMIP entities by limiting the interrogation of the pMAG by the LMA in the case of reactive handover just to the case where the MN = in the handover is maintaining an active multicast session.<= /p>

Well this information is already there in LMA as the= aggregated multicast state. What you want to do is to make it MN specific.= You seem to assume that LMA is unicast only. The resulting protocol is too= heavy.
 

The proposed solution could work without using the flag A, bu= t at the cost of delivering much more signaling messages than the strictly needed

 Why?
I think that using Fig. 5, steps 1-3 in case S=3D1 in all cases would be go= od enough.
By removing the A flag, your protocol will be so much simplified, my guess = is you can save 10 pages from the document.
So I encourage you to remove the A flag. What you are losing is so little.<= /p>

(all the messages for the MNs without multicast session does = not need any supporting message for multicast handover optimization).

 

Yes but this is already indicated with S=3D0.
 


Regards,

Behcet

 


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

 



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_+7w+iEfbInKUFNiu50AsEQ)-- From internet-drafts@ietf.org Mon Feb 25 07:32:01 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 2F77621F94C2; Mon, 25 Feb 2013 07:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yf3omgIuD972; Mon, 25 Feb 2013 07:32:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A560421F94C4; Mon, 25 Feb 2013 07:31:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225153159.15233.88432.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 07:31:59 -0800 Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-ropt-03.txt 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, 25 Feb 2013 15:32:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multicast Mobility Working Group of the I= ETF. Title : Multicast Mobility Routing Optimizations for Proxy Mobil= e 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 Abstract: The MULTIMOB group has specified a base solution to support IP multicasting in a PMIPv6 domain [RFC6224]. In this document, some enhancements to the base solution are described. These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the MAG can provide access to multicast content in the local network. These enhancements provide benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployment scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-ropt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-ropt-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-pmipv6-ropt-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From JuanCarlos.Zuniga@InterDigital.com Mon Feb 25 07:45:12 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 78D2021F935F for ; Mon, 25 Feb 2013 07:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NOVYz4mmdWq for ; Mon, 25 Feb 2013 07:45:12 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id DB79F21F9491 for ; Mon, 25 Feb 2013 07:45:11 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Feb 2013 10:45:10 -0500 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: Mon, 25 Feb 2013 10:45:10 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] I-D Action: draft-ietf-multimob-pmipv6-ropt-03.txt Thread-Index: Ac4TbWvl+uTkPLziRhKmpSTUDMvCDQAALyjw From: "Zuniga, Juan Carlos" To: X-OriginalArrivalTime: 25 Feb 2013 15:45:10.0592 (UTC) FILETIME=[1809DC00:01CE136F] Subject: [multimob] FW: I-D Action: draft-ietf-multimob-pmipv6-ropt-03.txt 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, 25 Feb 2013 15:45:12 -0000 Hi all, We have uploaded a new version of draft-ietf-multimob-pmipv6-ropt.=20 We have aimed at addressing the comments received at the meeting, as well as the reviews we got on the list from Akbar, Behcet and Hitoshi. Please take a look and let us know if you have any further comments. Best regards, Juan Carlos et al.=20 > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Monday, February 25, 2013 10:32 AM > To: i-d-announce@ietf.org > Cc: multimob@ietf.org > Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-ropt-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multicast Mobility Working Group of > the IETF. >=20 > 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 >=20 > Abstract: > The MULTIMOB group has specified a base solution to support IP > multicasting in a PMIPv6 domain [RFC6224]. In this document, some > enhancements to the base solution are described. These enhancements > include the use of a multicast tree mobility anchor as the > topological anchor point for multicast traffic, as well as a direct > routing option where the MAG can provide access to multicast content > in the local network. These enhancements provide benefits such as > reducing multicast traffic replication and supporting different > PMIPv6 deployment scenarios. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-ropt=20 >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-ropt-03=20 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-pmipv6-ropt-03=20 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ =20 >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From stig@venaas.com Mon Feb 25 10:08:15 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 D460521E804C for ; Mon, 25 Feb 2013 10:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVCBhZUGQWwD for ; Mon, 25 Feb 2013 10:08:14 -0800 (PST) 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 10B2821E8048 for ; Mon, 25 Feb 2013 10:08:14 -0800 (PST) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 09DC38009; Mon, 25 Feb 2013 19:08:11 +0100 (CET) Message-ID: <512BA88A.6090007@venaas.com> Date: Mon, 25 Feb 2013 10:08:10 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: LUIS MIGUEL CONTRERAS MURILLO References: <823234EF5C7C334998D973D822FF801B315A31D3@EX10-MB2-MAD.hi.inet> <823234EF5C7C334998D973D822FF801B315A6815@EX10-MB2-MAD.hi.inet> In-Reply-To: <823234EF5C7C334998D973D822FF801B315A6815@EX10-MB2-MAD.hi.inet> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "multimob@ietf.org" Subject: Re: [multimob] draft-ietf-multimob-handover-optimization-01 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, 25 Feb 2013 18:08:15 -0000 On 2/22/2013 1:32 AM, LUIS MIGUEL CONTRERAS MURILLO wrote: > Hi Behcet, > > The central argument of your comments orbits around the no necessity of > implementing the multicast activity indication process, as a way of > simplifying the protocol. Actually, the multicast activity indication > does not impact on the performance of the handover optimization, neither > for the proactive nor the reactive cases. The timing for getting the > multicast subscription information ready at the nMAG is the same. > However, the presence of the multicast activity indication makes the > protocol more efficient in terms of signaling messages in the network > for the reactive case when the MN is not maintaining an active > subscription. We believe it is worth using the multicast activity > indication as compared to querying the pMAG every time an MN moves. This > could become relevant in scenarios of high mobility or in scenarios > where the percentage of multicast active MNs is significantly low. > However, if the WG believes this should not be mandatory, a possibility > could be to implement the multicast activity indication as an option of > the protocol to improve the efficiency in certain scenarios. We would > like to know your opinion and the opinion of the working group about > such possibility. Hi. This sounds like a great topic to discuss in the meeting. It would be good if you spend some time on this in your presentation and we can try to get people's opinion. I think it might be worth making it optional, but I have no strong opinions on this. Stig > > Regards > > Luis > > *De:*Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > *Enviado el:* lunes, 18 de febrero de 2013 23:19 > *Para:* LUIS MIGUEL CONTRERAS MURILLO > *CC:* multimob@ietf.org; cjbc@it.uc3m.es; Ignacio Soto Campos > (isoto@it.uc3m.es) > *Asunto:* Re: [multimob] draft-ietf-multimob-handover-optimization-01 > > Hi Luis, > > Please see my replies inline. Let's resolve these issues quickly. > > Regards, > > Behcet > > On Mon, Feb 18, 2013 at 3:14 PM, LUIS MIGUEL CONTRERAS MURILLO > > wrote: > > Hi Behcet, > > Thanks for your comments, and sorry for the late response. > > Please, find our answers in line > > Best regards, > > Luis > > *De:*multimob-bounces@ietf.org > [mailto:multimob-bounces@ietf.org ] > *En nombre de *Behcet Sarikaya > *Enviado el:* jueves, 31 de enero de 2013 0:28 > *Para:* multimob@ietf.org > *Asunto:* [multimob] draft-ietf-multimob-handover-optimization-01 > > Hi Carlos, authors, > > Some initial comments on your draft: > Section 4.2 states that two new flags are defined but Flag A is not used > in the line. > > */[Luis>>] Actually section 4.2 covers the description of both flags, A > and S. There is an specific section inside for any of them, being 4.2.1 > devoted to flag S, and section 4.2.2 to flag A. We can improve the text > explicitly mention this to help the reader./* > > Here I meant to say that A flag is not sent/received in PBU/PBA or other > messages you defined. > > Subscription Query/Response messages: why not use the Update > Notification message in draft-ietf-netext-update-notifications-00? > > */[Luis>>] The mechanism described in > draft-ietf-netext-update-notifications-00 focus on notifications > triggered by the LMA. Despite the query from LMA to pMAG in the > proactive handover case could be seen as one potential use case, the > scope of the Subscription Query/Response messages is wider. These > messages are also used by the nMAG for retrieving the multicast > subscription information from the LMA in situations where the > unicast binding is allowed to progress till the multicast > information is ready, preventing large delays of the binding > acknowledgement for unicast traffic (see section 5.2.4). In our > opinion, a common mechanism should be used in both cases./* > > Why is it necessary to define messages other than PBU/PBA from MAG > to LMA, i.e. Act Ind? > > */[Luis>>] The idea behind the new messages described in the WG > draft is the use of specific and lightweight signaling methods for > handling some flags in support of multicast handover optimization. > For instance, the multicast activity indication represents the > change in the multicast status state ( subscribed / not subscribed > to any group) of one interface in the MAG. Strictly speaking, this > event is not related to the purpose of PBU/PBA signaling./* > > If you remove the A flag and do the activity checking only right after > the handover, you are simplifying the protocol and not losing much. > Remember that LMA can check the aggregated multicast state and find out > that some multicast sessions are active. > Please see more on this below. > > If we agree on this then only Subscription Request/Reply remains to be > resolved. > Since these are not generic notification messages we can not use > draft-ietf-netext-update-notifications, which is OK. > So you can keep Subscription Request/Reply. > > Regarding Figs 1 & 2, and also the Flag A, MLD Done is only in MLDv1 > and has been removed from MLDv2, check Appendix B in RFC 3810. > > */[Luis>>] That’s correct, although the parts of the text where the > reference to the MLD Done message appear are actually on Figure 3 > and the first bullet below that figure. Our proposal is to change > the text of the figure from “MLD Done” to “MLD Report” for brevity,/* > > MLD Report is too generic. > > */and to change the text in the bullet from “MLD Done” to “MLD > Report message (with a filter mode change record indicating EXCLUDE > mode for the last subscribed multicast group)”./* > > Exclude mode is only for SSM. > But if you remove the A flag, you don't really need any of these things, > see below. > > MLD Done was mimicking IGMPv2 Leave message which is not mentioned > in IPv4 support. > > The fact that MLD Done (or IGMP Leave) no longer available in SSM > makes me question the A Flag. How could LMA sustain a valid value of > the A Flag? > OTOH, A Flag is only used for optimization, as shown in Figure 6. > Would it be possible to not define A Flag and use S Flag? > > */[Luis>>] Flag A helps to optimize the number of messages between > PMIP entities by limiting the interrogation of the pMAG by the LMA > in the case of reactive handover just to the case where the MN in > the handover is maintaining an active multicast session./* > > Well this information is already there in LMA as the aggregated > multicast state. What you want to do is to make it MN specific. You seem > to assume that LMA is unicast only. The resulting protocol is too heavy. > > */The proposed solution could work without using the flag A, but at > the cost of delivering much more signaling messages than the > strictly needed /* > > Why? > I think that using Fig. 5, steps 1-3 in case S=1 in all cases would be > good enough. > By removing the A flag, your protocol will be so much simplified, my > guess is you can save 10 pages from the document. > So I encourage you to remove the A flag. What you are losing is so little. > > */(all the messages for the MNs without multicast session does not > need any supporting message for multicast handover optimization)./* > > Yes but this is already indicated with S=0. > > > Regards, > > Behcet > > ------------------------------------------------------------------------ > > > 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 > > > ------------------------------------------------------------------------ > > 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 sarikaya2012@gmail.com Mon Feb 25 11:03:14 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 EE1A321F938C for ; Mon, 25 Feb 2013 11:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.753 X-Spam-Level: X-Spam-Status: No, score=-2.753 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pT4eN+yO2pQ for ; Mon, 25 Feb 2013 11:02:55 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 08CEB21F92D6 for ; Mon, 25 Feb 2013 11:02:51 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id l12so2454054lbo.5 for ; Mon, 25 Feb 2013 11:02:49 -0800 (PST) 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=G1qy71IjbyKmG1mBdQw58k0bLNo6NiY2WWBFEgQ12v0=; b=v9YdN/3YDlPr5XBE9sa+mYy9GuFxPhsc92MhbQE5+XTMoXMt9daoIl80kXvs7GcDbh QnBxC6c0WOo81yER/A21NVExveJq+EKvRgEsS+EStffWCT/H69gLRe/Djf85iThu0NAh eE7HTG1BQgg8ZVQrlsgJmq+onjVO7cwYJybCfd1q8q/XQ8BVQPS1mWWD0OL+wxbUGovJ fTwx+zXQuWE658mbbG9HDJHN2OFoI3P6zMWeQh69nmEums9qfxBCIjqaziUhpdt8eYv7 1hxXZDecRyhk90C63nR1Gi7sgALA+b0i6O44bUFIUJLLdM6NEmUlKEAhDLil1Qx7OlR3 e1lg== MIME-Version: 1.0 X-Received: by 10.112.29.1 with SMTP id f1mr4887712lbh.30.1361818968749; Mon, 25 Feb 2013 11:02:48 -0800 (PST) Received: by 10.114.28.168 with HTTP; Mon, 25 Feb 2013 11:02:48 -0800 (PST) In-Reply-To: <512BA88A.6090007@venaas.com> References: <823234EF5C7C334998D973D822FF801B315A31D3@EX10-MB2-MAD.hi.inet> <823234EF5C7C334998D973D822FF801B315A6815@EX10-MB2-MAD.hi.inet> <512BA88A.6090007@venaas.com> Date: Mon, 25 Feb 2013 13:02:48 -0600 Message-ID: From: Behcet Sarikaya To: Stig Venaas Content-Type: multipart/alternative; boundary=bcaec554e14ce1798804d6912fe6 Cc: "multimob@ietf.org" Subject: Re: [multimob] draft-ietf-multimob-handover-optimization-01 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: Mon, 25 Feb 2013 19:03:14 -0000 X-List-Received-Date: Mon, 25 Feb 2013 19:03:14 -0000 --bcaec554e14ce1798804d6912fe6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Feb 25, 2013 at 12:08 PM, Stig Venaas wrote: > On 2/22/2013 1:32 AM, LUIS MIGUEL CONTRERAS MURILLO wrote: > >> Hi Behcet, >> >> The central argument of your comments orbits around the no necessity of >> implementing the multicast activity indication process, as a way of >> simplifying the protocol. Actually, the multicast activity indication >> does not impact on the performance of the handover optimization, neither >> for the proactive nor the reactive cases. The timing for getting the >> multicast subscription information ready at the nMAG is the same. >> However, the presence of the multicast activity indication makes the >> protocol more efficient in terms of signaling messages in the network >> for the reactive case when the MN is not maintaining an active >> subscription. We believe it is worth using the multicast activity >> indication as compared to querying the pMAG every time an MN moves. This >> could become relevant in scenarios of high mobility or in scenarios >> where the percentage of multicast active MNs is significantly low. >> However, if the WG believes this should not be mandatory, a possibility >> could be to implement the multicast activity indication as an option of >> the protocol to improve the efficiency in certain scenarios. We would >> like to know your opinion and the opinion of the working group about >> such possibility. >> > > Hi. This sounds like a great topic to discuss in the meeting. It would > be good if you spend some time on this in your presentation and we can > try to get people's opinion. > > I think it might be worth making it optional, but I have no strong > opinions on this. > > multicast activity indication signaling for individual MN's between MAG and LMA is the issue here. As I suggested, this should be taken out of this draft first. We can discuss if it there is a feasible solution? MLD Done is for ASM and it is a SHOULD in RFC 2710. What to do for SSM? Why do we need this additional signaling? Is there a strong justification? If a feasible solution emerges and WG believes that there is a need then a separate draft can be written and individual Handover drafts can use it. Behcet > Stig > > >> Regards >> >> Luis >> >> *De:*Behcet Sarikaya [mailto:sarikaya2012@gmail.com**] >> *Enviado el:* lunes, 18 de febrero de 2013 23:19 >> *Para:* LUIS MIGUEL CONTRERAS MURILLO >> *CC:* multimob@ietf.org; cjbc@it.uc3m.es; Ignacio Soto Campos >> (isoto@it.uc3m.es) >> *Asunto:* Re: [multimob] draft-ietf-multimob-handover-**optimization-01 >> >> >> Hi Luis, >> >> Please see my replies inline. Let's resolve these issues quickly. >> >> Regards, >> >> Behcet >> >> On Mon, Feb 18, 2013 at 3:14 PM, LUIS MIGUEL CONTRERAS MURILLO >> > wrote: >> >> Hi Behcet, >> >> Thanks for your comments, and sorry for the late response. >> >> Please, find our answers in line >> >> Best regards, >> >> Luis >> >> *De:*multimob-bounces@ietf.org >> > >> [mailto:multimob-bounces@ietf.**org > multimob-bounces@ietf.**org >] >> *En nombre de *Behcet Sarikaya >> *Enviado el:* jueves, 31 de enero de 2013 0:28 >> *Para:* multimob@ietf.org >> *Asunto:* [multimob] draft-ietf-multimob-handover-**optimization-01 >> >> >> Hi Carlos, authors, >> >> Some initial comments on your draft: >> Section 4.2 states that two new flags are defined but Flag A is not used >> in the line. >> >> */[Luis>>] Actually section 4.2 covers the description of both flags, A >> >> and S. There is an specific section inside for any of them, being 4.2.1 >> devoted to flag S, and section 4.2.2 to flag A. We can improve the text >> explicitly mention this to help the reader./* >> >> >> Here I meant to say that A flag is not sent/received in PBU/PBA or other >> messages you defined. >> >> Subscription Query/Response messages: why not use the Update >> Notification message in draft-ietf-netext-update-**notifications-00? >> >> */[Luis>>] The mechanism described in >> >> draft-ietf-netext-update-**notifications-00 focus on notifications >> triggered by the LMA. Despite the query from LMA to pMAG in the >> proactive handover case could be seen as one potential use case, the >> scope of the Subscription Query/Response messages is wider. These >> messages are also used by the nMAG for retrieving the multicast >> subscription information from the LMA in situations where the >> unicast binding is allowed to progress till the multicast >> information is ready, preventing large delays of the binding >> acknowledgement for unicast traffic (see section 5.2.4). In our >> opinion, a common mechanism should be used in both cases./* >> >> >> Why is it necessary to define messages other than PBU/PBA from MAG >> to LMA, i.e. Act Ind? >> >> */[Luis>>] The idea behind the new messages described in the WG >> >> draft is the use of specific and lightweight signaling methods for >> handling some flags in support of multicast handover optimization. >> For instance, the multicast activity indication represents the >> change in the multicast status state ( subscribed / not subscribed >> to any group) of one interface in the MAG. Strictly speaking, this >> event is not related to the purpose of PBU/PBA signaling./* >> >> >> If you remove the A flag and do the activity checking only right after >> the handover, you are simplifying the protocol and not losing much. >> Remember that LMA can check the aggregated multicast state and find out >> that some multicast sessions are active. >> Please see more on this below. >> >> If we agree on this then only Subscription Request/Reply remains to be >> resolved. >> Since these are not generic notification messages we can not use >> draft-ietf-netext-update-**notifications, which is OK. >> So you can keep Subscription Request/Reply. >> >> Regarding Figs 1 & 2, and also the Flag A, MLD Done is only in MLDv1 >> and has been removed from MLDv2, check Appendix B in RFC 3810. >> >> */[Luis>>] That=92s correct, although the parts of the text where th= e >> >> reference to the MLD Done message appear are actually on Figure 3 >> and the first bullet below that figure. Our proposal is to change >> the text of the figure from =93MLD Done=94 to =93MLD Report=94 for b= revity,/* >> >> >> MLD Report is too generic. >> >> */and to change the text in the bullet from =93MLD Done=94 to =93MLD >> >> Report message (with a filter mode change record indicating EXCLUDE >> mode for the last subscribed multicast group)=94./* >> >> >> Exclude mode is only for SSM. >> But if you remove the A flag, you don't really need any of these things, >> see below. >> >> MLD Done was mimicking IGMPv2 Leave message which is not mentioned >> in IPv4 support. >> >> The fact that MLD Done (or IGMP Leave) no longer available in SSM >> makes me question the A Flag. How could LMA sustain a valid value of >> the A Flag? >> OTOH, A Flag is only used for optimization, as shown in Figure 6. >> Would it be possible to not define A Flag and use S Flag? >> >> */[Luis>>] Flag A helps to optimize the number of messages between >> >> PMIP entities by limiting the interrogation of the pMAG by the LMA >> in the case of reactive handover just to the case where the MN in >> the handover is maintaining an active multicast session./* >> >> >> Well this information is already there in LMA as the aggregated >> multicast state. What you want to do is to make it MN specific. You seem >> to assume that LMA is unicast only. The resulting protocol is too heavy. >> >> */The proposed solution could work without using the flag A, but at >> >> the cost of delivering much more signaling messages than the >> strictly needed /* >> >> >> Why? >> I think that using Fig. 5, steps 1-3 in case S=3D1 in all cases would be >> good enough. >> By removing the A flag, your protocol will be so much simplified, my >> guess is you can save 10 pages from the document. >> So I encourage you to remove the A flag. What you are losing is so littl= e. >> >> */(all the messages for the MNs without multicast session does not >> need any supporting message for multicast handover optimization)./* >> >> >> Yes but this is already indicated with S=3D0. >> >> >> Regards, >> >> Behcet >> >> ------------------------------**------------------------------** >> ------------ >> >> >> >> 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 >> >> >> ------------------------------**------------------------------** >> ------------ >> >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar >> nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en e= l 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 >> >> > --bcaec554e14ce1798804d6912fe6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 25, 2013 at 12:08 PM, Stig V= enaas <stig@venaas.com> wrote:
On 2/22/2013 1:32 AM, LUIS MIGUEL CONTRERAS MURILLO wrote= :
Hi Behcet,

The central argument of your comments orbits around the no necessity of
implementing the multicast activity indication process, as a way of
simplifying the protocol. Actually, the multicast activity indication
does not impact on the performance of the handover optimization, neither for the proactive nor the reactive cases. The timing for getting the
multicast subscription information ready at the nMAG is the same.
However, the presence of the multicast activity indication makes the
protocol more efficient in terms of signaling messages in the network
for the reactive case when the MN is not maintaining an active
subscription. We believe it is worth using the multicast activity
indication as compared to querying the pMAG every time an MN moves. This could become relevant in scenarios of high mobility or in scenarios
where the percentage of multicast active MNs is significantly low.
However, if the WG believes this should not be mandatory, a possibility
could be to implement the multicast activity indication as an option of
the protocol to improve the efficiency in certain scenarios. We would
like to know your opinion and the opinion of the working group about
such possibility.

Hi. This sounds like a great topic to discuss in the meeting. It would
be good if you spend some time on this in your presentation and we can
try to get people's opinion.

I think it might be worth making it optional, but I have no strong
opinions on this.


=A0multicast activity indication signaling for in= dividual MN's between MAG and LMA is the issue here.

As I sugges= ted, this should be taken out of this draft first.
We can discuss
if it there is a feasible solution? MLD Done is for ASM and it is a SHOULD = in RFC 2710.
What to do for SSM?

Why do we need this additional s= ignaling? Is there a strong justification?

If a feasible solution em= erges and WG believes that there is a need then a separate draft can be wri= tten and individual Handover drafts can use it.

Behcet
=A0
Stig


Regards

Luis

*De:*Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
*Enviado el:* lunes, 18 de febrero de 2013 23:19
*Para:* LUIS MIGUEL CONTRERAS MURILLO
*CC:* multimob@ietf.= org; cjbc@it.uc3m.= es; Ignacio Soto Campos
(isoto@it.uc3m.es= )
*Asunto:* Re: [multimob] draft-ietf-multimob-handover-optimization-0= 1


Hi Luis,

Please see my replies inline. Let's resolve these issues quickly.

Regards,

Behcet

On Mon, Feb 18, 2013 at 3:14 PM, LUIS MIGUEL CONTRERAS MURILLO
<lmcm@tid.es <ma= ilto:lmcm@tid.es>&g= t; wrote:

Hi Behcet,

Thanks for your comments, and sorry for the late response.

Please, find our answers in line

Best regards,

Luis

*De:*multimo= b-bounces@ietf.org <mailto:multimob-bounces@ietf.org>
[mailto:mult= imob-bounces@ietf.org <mailto:multimob-bounces@ietf.org>] *En nombre de *Behcet Sarikaya
*Enviado el:* jueves, 31 de enero de 2013 0:28
*Para:* multimob@iet= f.org <mailto:multimob@ietf.org>
*Asunto:* [multimob] draft-ietf-multimob-handover-optimization-01

Hi Carlos, authors,

Some initial comments on your draft:
Section 4.2 states that two new flags are defined but Flag A is not used in the line.

*/[Luis>>] Actually section 4.2 covers the description of both flags,= A

and S. There is an specific section inside for any of them, being 4.2.1
devoted to flag S, and section 4.2.2 to flag A. We can improve the text
=
explicitly mention this to help the reader./*


Here I meant to say that A flag is not sent/received in PBU/PBA or other messages you defined.

=A0 =A0 Subscription Query/Response messages: why not use the Update
=A0 =A0 Notification message in draft-ietf-netext-update-notificatio= ns-00?

=A0 =A0 */[Luis>>] The mechanism described in

=A0 =A0 draft-ietf-netext-update-notifications-00 focus on notificat= ions
=A0 =A0 triggered by the LMA. Despite the query from LMA to pMAG in the
=A0 =A0 proactive handover case could be seen as one potential use case, th= e
=A0 =A0 scope of the Subscription Query/Response messages is wider. These =A0 =A0 messages are also used by the nMAG for retrieving the multicast
=A0 =A0 subscription information from the LMA in situations where the
=A0 =A0 unicast binding is allowed to progress till the multicast
=A0 =A0 information is ready, preventing large delays of the binding
=A0 =A0 acknowledgement for unicast traffic (see section 5.2.4). In our
=
=A0 =A0 opinion, a common mechanism should be used in both cases./*


=A0 =A0 Why is it necessary to define messages other than PBU/PBA from MAG<= br> =A0 =A0 to LMA, i.e. Act Ind?

=A0 =A0 */[Luis>>] The idea behind the new messages described in the = WG

=A0 =A0 draft is the use of specific and lightweight signaling methods for<= br> =A0 =A0 handling some flags in support of multicast handover optimization.<= br> =A0 =A0 For instance, the multicast activity indication represents the
=A0 =A0 change in the multicast status state ( subscribed / not subscribed<= br> =A0 =A0 to any group) of one interface in the MAG. Strictly speaking, this<= br>
=A0 =A0 event is not related to the purpose of PBU/PBA signaling./*


If you remove the A flag and do the activity checking only right after
the handover, you are simplifying the protocol and not losing much.
Remember that LMA can check the aggregated multicast state and find out
that some multicast sessions are active.
Please see more on this below.

If we agree on this then only Subscription Request/Reply remains to be
resolved.
Since these are not generic notification messages we can not use
draft-ietf-netext-update-notifications, which is OK.
So you can keep Subscription Request/Reply.

=A0 =A0 Regarding Figs 1 & 2, and also the Flag A, MLD Done is only in = MLDv1
=A0 =A0 and has been removed from MLDv2, check Appendix B in RFC 3810.

=A0 =A0 */[Luis>>] That=92s correct, although the parts of the text w= here the

=A0 =A0 reference to the MLD Done message appear are actually on Figure 3 =A0 =A0 and the first bullet below that figure. Our proposal is to change
=A0 =A0 the text of the figure from =93MLD Done=94 to =93MLD Report=94 for = brevity,/*


MLD Report is too generic.

=A0 =A0 */and to change the text in the bullet from =93MLD Done=94 to =93ML= D

=A0 =A0 Report message (with a filter mode change record indicating EXCLUDE=
=A0 =A0 mode for the last subscribed multicast group)=94./*


Exclude mode is only for SSM.
But if you remove the A flag, you don't really need any of these things= ,
see below.

=A0 =A0 MLD Done was mimicking IGMPv2 Leave message which is not mentioned<= br> =A0 =A0 in IPv4 support.

=A0 =A0 The fact that MLD Done (or IGMP Leave) no longer available in SSM =A0 =A0 makes me question the A Flag. How could LMA sustain a valid value o= f
=A0 =A0 the A Flag?
=A0 =A0 OTOH, A Flag is only used for optimization, as shown in Figure 6. =A0 =A0 Would it be possible to not define A Flag and use S Flag?

=A0 =A0 */[Luis>>] Flag A helps to optimize the number of messages be= tween

=A0 =A0 PMIP entities by limiting the interrogation of the pMAG by the LMA<= br> =A0 =A0 in the case of reactive handover just to the case where the MN in
=A0 =A0 the handover is maintaining an active multicast session./*


Well this information is already there in LMA as the aggregated
multicast state. What you want to do is to make it MN specific. You seem to assume that LMA is unicast only. The resulting protocol is too heavy.
=A0 =A0 */The proposed solution could work without using the flag A, but at=

=A0 =A0 the cost of delivering much more signaling messages than the
=A0 =A0 strictly needed /*


=A0 Why?
I think that using Fig. 5, steps 1-3 in case S=3D1 in all cases would be good enough.
By removing the A flag, your protocol will be so much simplified, my
guess is you can save 10 pages from the document.
So I encourage you to remove the A flag. What you are losing is so little.<= br>
=A0 =A0 */(all the messages for the MNs without multicast session does not<= br> =A0 =A0 need any supporting message for multicast handover optimization)./*=


Yes but this is already indicated with S=3D0.


=A0 =A0 Regards,

=A0 =A0 Behcet

=A0 =A0 ------------------------------------------------------------= ------------



=A0 =A0 Este mensaje se dirige exclusivamente a su destinatario. Puede
=A0 =A0 consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo
=A0 =A0 electr=F3nico en el enlace situado m=E1s abajo.
=A0 =A0 This message is intended exclusively for its addressee. We only sen= d
=A0 =A0 and receive email on the basis of the terms set out at:
=A0 =A0 http://www.tid.es/ES/PAGINAS/disclaimer.aspx


-------------------------------------------------------------= -----------


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 e= nlace
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



--bcaec554e14ce1798804d6912fe6-- From internet-drafts@ietf.org Mon Feb 25 11:35:41 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 54DB321F92E4; Mon, 25 Feb 2013 11:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id runQMFSv1pUv; Mon, 25 Feb 2013 11:35:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E7521F92E9; Mon, 25 Feb 2013 11:35:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225193540.20829.34780.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 11:35:40 -0800 Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-03.txt 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, 25 Feb 2013 19:35:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multicast Mobility Working Group of the I= ETF. Title : Mobile Multicast Sender Support in Proxy Mobile IPv6 (PM= IPv6) Domains Author(s) : Thomas C. Schmidt Shuai Gao Hong-Ke Zhang Matthias Waehlisch Filename : draft-ietf-multimob-pmipv6-source-03.txt Pages : 26 Date : 2013-02-25 Abstract: Multicast communication can be enabled in Proxy Mobile IPv6 domains via the Local Mobility Anchors by deploying MLD Proxy functions at Mobile Access Gateways, via a direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains for all three scenarios. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as extended MLD Proxy functions are presented. Mobile sources always remain agnostic of multicast mobility operations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-pmipv6-source-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=761bc2c9a=schmidt@informatik.haw-hamburg.de Mon Feb 25 11:45:15 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 0610321E8056 for ; Mon, 25 Feb 2013 11:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3iveL8svU-Z for ; Mon, 25 Feb 2013 11:45:12 -0800 (PST) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id 35CE421E804D for ; Mon, 25 Feb 2013 11:45:09 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 25 Feb 2013 20:45:08 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id C55ED106872B; Mon, 25 Feb 2013 20:45:08 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02463-03; Mon, 25 Feb 2013 20:45:06 +0100 (CET) Received: from [192.168.152.252] (rrcs-67-52-140-5.west.biz.rr.com [67.52.140.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 46EC9106872A; Mon, 25 Feb 2013 20:45:05 +0100 (CET) Message-ID: <512BBF3C.80901@informatik.haw-hamburg.de> Date: Mon, 25 Feb 2013 11:45:00 -0800 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Stig Venaas References: <51158232.4050500@venaas.com> In-Reply-To: <51158232.4050500@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: "multimob@ietf.org" Subject: Re: [multimob] A couple of comments on draft-ietf-multimob-pmipv6-source-02 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, 25 Feb 2013 19:45:15 -0000 Hi Stig, thanks again for your comments and sorry for coming back late on this. We adjusted the PIM phase transition details you pointed at in our recent post. However - without questioning the judgement of the PIM co-chair ;) - there are a couple more involvements. First, the moving source arrives at a different (tunnel) interface of the RP ... so PIM implementations need to being able to cope with this change ... ... second, the SPTs don't point directly to the MAGs, but to the LMA (-tunnel interface). In theory, this is a stability anchor which simplifies, but in practice an unmodified PIM-RP would not know and had to re-iterate phase transitions ... otherwise, if the stable LMA weren't in place, data streams would be lost. Our update is just a quick sketch ... I guess, some editorial polishing is needed. In addition, we moved the multiple upstream proxy to the appendix as desired in the Atlanta meeting. Cheers, Thomas On 08.02.2013 14:54, Stig Venaas wrote: > Hi > > The document is in a pretty good shape. I found one issue though. > > In 4.3.3 it says: > > On handover, the mobile source reattaches to a new MAG (DR), and > PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new > point of attachment. However, in the absence of a corresponding > multicast forwarding state, the new DR will treat S as a new source > and initiate a source registering of PIM phase one. In consequence, > the PIM transition from phase one to two will be iterated per > handover, leading to an enhanced signaling load and repeated delay > variations. > > This is not really the case. The new MAG should be sending registers to > the same RP as the previous MAG did. If registration had completed so > that no more data registers were sent by the previous MAG (only periodic > null-registers to maintain the (S,G) state on the RP), the RP would > immediately respond with a register stop when it receives a register > from the new MAG. Basically, the RP behavior does not depend on who is > sending the registers. > > Independent of the registers, if the RP had joined the SPT to receive > from the source, the SPT would be updated and joins would go towards > the new MAG. > > The same for 4.3.4. > > Two minor editorial things I spotted: > > > such as IPTV or sever-centric gaming on mobiles. However, current > ^^^^^ > > bindings) has been performed . Still multicast packets arriving at > ^^^ > > Stig > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From internet-drafts@ietf.org Mon Feb 25 14:10:51 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 5402121F9236; Mon, 25 Feb 2013 14:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2A5GQx7PXCj; Mon, 25 Feb 2013 14:10:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785DC21F9239; Mon, 25 Feb 2013 14:10:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225221050.23550.42196.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 14:10:50 -0800 Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-handover-optimization-02.txt 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, 25 Feb 2013 22:10:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multicast Mobility Working Group of the I= ETF. Title : PMIPv6 multicast handover optimization by the Subscripti= on Information Acquisition through the LMA (SIAL) Author(s) : Luis M. Contreras Carlos J. Bernardos Ignacio Soto Filename : draft-ietf-multimob-handover-optimization-02.txt Pages : 47 Date : 2013-02-25 Abstract: This document specifies a multicast handover optimization mechanism for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic to mobile nodes after handovers. The mechanism is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current Proxy Mobile IPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions being developed to avoid the tunnel convergence problem. Furthermore, they are also independent of the role played by the mobile access gateway within the multicast network (either acting as multicast listener discovery proxy or multicast router). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-handover-optimization There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-handover-optimization-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-handover-optimizatio= n-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lmcm@tid.es Mon Feb 25 14:16: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 6FCA121E80FA for ; Mon, 25 Feb 2013 14:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.456 X-Spam-Level: X-Spam-Status: No, score=-5.456 tagged_above=-999 required=5 tests=[AWL=1.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76YSwvZWk0dS for ; Mon, 25 Feb 2013 14:16:38 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4ED21E811F for ; Mon, 25 Feb 2013 14:16:35 -0800 (PST) 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 <0MIS00I4NR7DVS@tid.hi.inet> for multimob@ietf.org; Mon, 25 Feb 2013 23:16:25 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id BA.6F.05051.9B2EB215; Mon, 25 Feb 2013 23:16:25 +0100 (CET) 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 <0MIS00I4JR7DVS@tid.hi.inet> for multimob@ietf.org; Mon, 25 Feb 2013 23:16:25 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Mon, 25 Feb 2013 23:16:24 +0100 Date: Mon, 25 Feb 2013 22:16:24 +0000 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: <20130225221050.23550.49781.idtracker@ietfa.amsl.com> X-Originating-IP: [10.95.64.115] To: "multimob@ietf.org" Message-id: <823234EF5C7C334998D973D822FF801B315A8AA9@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: es-ES Content-transfer-encoding: base64 Accept-Language: es-ES, en-US Thread-topic: New Version Notification for draft-ietf-multimob-handover-optimization-02.txt Thread-index: AQHOE6T6y+1OMbDy5EWId9gq5vjJBpiLIr3Q X-AuditID: 0a5f4e69-b7fbe6d0000013bb-6b-512be2b93cee X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsXCFe9nqLvzkXagwb+14hYzPvaxODB6LFny kymAMYrLJiU1J7MstUjfLoEr48yyd+wFG+Qq3r9ZzNjAeEa2i5GTQ0LAROL6gRMsELaYxIV7 69m6GLk4hAS2MUr0HtjIBOH8ZpQ4snwmO4Qzk1Hi6MXnYC0sAqoSXTcPs4LYbAKGErN2TgKz hQViJI5+ewhUw8HBKeAkselYOsQGBYk/5x6DtYoIaEu8efmHCcRmFkiT+Hj+Klg5r4C3xKd9 vCBhXgFBiR+T74GFmQXUJaZMyYWoFpeY82siK4StKDFtUQMjiM0oICux8vxpRojpsRJnT/2G 2mQk8e/cRTaICwQkluw5zwxhi0q8fPyPFWS8kICjxIs3whMYxWchWTwLYfEsJItnIVm8gJFl FaNYcVJRZnpGSW5iZk66gZFeRqZeZl5qySZGSPxk7mBcvlPlEKMAB6MSD69Gh3agEGtiWXFl 7iFGCQ5mJRFezgygEG9KYmVValF+fFFpTmrxIUYmDk6pBsY0kQOtN6MuzJSVyk3InVVVdOtn +YNE+V/h+5bYLZ3J2skUGnD3+mTzT8YXVXr1vykfWXV/ysoJQp/28bO0Lzy50ygrsLukOHlX 5YZDN/59fyogGHd12fMK8eMpuiV/OF5lsv4wmLlDak113DPufJ7PxVe6+zW7n29WaRRbtEvl 6tRjF7Z9ntaixFKckWioxVxUnAgAKJCl6n0CAAA= References: <20130225221050.23550.49781.idtracker@ietfa.amsl.com> Subject: [multimob] RV: New Version Notification for draft-ietf-multimob-handover-optimization-02.txt 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, 25 Feb 2013 22:16:39 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUganVzdCB1cGxvYWRlZCBhbiB1cGRhdGVkIHZlcnNpb24gb2Yg ZHJhZnQtaWV0Zi1tdWx0aW1vYi1oYW5kb3Zlci1vcHRpbWl6YXRpb24uDQoNClRoaXMgbmV3IHZl cnNpb24gaW5jbHVkZXMgc29tZSBjbGFyaWZpY2F0aW9uIHRleHQgYWNjb3JkaW5nIHRvIHRoZSBs YXN0IGNvbW1lbnRzIHJlY2VpdmVkIGFuZCBtaW5vciBlZGl0b3JpYWwgaW1wcm92ZW1lbnRzLg0K DQpBbGwgdGhlIGNvbnRlbnQgcmVsYXRlZCB0byB0aGUgbXVsdGljYXN0IGFjdGl2aXR5IGluZGlj YXRpb24gcHJvY2VkdXJlIHJlbWFpbnMgYXMgaW4gdGhlIHByZXZpb3VzIHZlcnNpb24sIHdhaXRp bmcgZm9yIHRoZSBkaXNjdXNzaW9uIHJlc3VsdHMgYW5kIHRoZSBkZWNpc2lvbnMgb2YgdGhlIG5l eHQgbWVldGluZyBpbiBPcmxhbmRvLg0KDQpUaGFua3MsIGJlc3QgcmVnYXJkcywNCg0KTHVpcw0K DQotLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KRGU6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCkVudmlhZG8gZWw6IGx1bmVzLCAy NSBkZSBmZWJyZXJvIGRlIDIwMTMgMjM6MTENClBhcmE6IExVSVMgTUlHVUVMIENPTlRSRVJBUyBN VVJJTExPDQpDQzogaXNvdG9AaXQudWMzbS5lczsgY2piY0BpdC51YzNtLmVzDQpBc3VudG86IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1tdWx0aW1vYi1oYW5kb3Zlci1v cHRpbWl6YXRpb24tMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYt bXVsdGltb2ItaGFuZG92ZXItb3B0aW1pemF0aW9uLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBMdWlzIE0uIENvbnRyZXJhcyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG IHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiAgICAgICAgZHJhZnQtaWV0Zi1tdWx0aW1vYi1oYW5k b3Zlci1vcHRpbWl6YXRpb24NClJldmlzaW9uOiAgICAgICAgMDINClRpdGxlOiAgICAgICAgICAg UE1JUHY2IG11bHRpY2FzdCBoYW5kb3ZlciBvcHRpbWl6YXRpb24gYnkgdGhlIFN1YnNjcmlwdGlv biBJbmZvcm1hdGlvbiBBY3F1aXNpdGlvbiB0aHJvdWdoIHRoZSBMTUEgKFNJQUwpDQpDcmVhdGlv biBkYXRlOiAgIDIwMTMtMDItMjUNCkdyb3VwOiAgICAgICAgICAgbXVsdGltb2INCk51bWJlciBv ZiBwYWdlczogNDcNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi1tdWx0aW1vYi1oYW5kb3Zlci1vcHRpbWl6YXRpb24tMDIudHh0 DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1tdWx0aW1vYi1oYW5kb3Zlci1vcHRpbWl6YXRpb24NCkh0bWxpemVkOiAgICAgICAgaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tdWx0aW1vYi1oYW5kb3Zlci1vcHRp bWl6YXRpb24tMDINCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1tdWx0aW1vYi1oYW5kb3Zlci1vcHRpbWl6YXRpb24tMDINCg0KQWJz dHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIG11bHRpY2FzdCBoYW5kb3ZlciBv cHRpbWl6YXRpb24gbWVjaGFuaXNtDQogICBmb3IgUHJveHkgTW9iaWxlIElQdjYgdG8gYWNjZWxl cmF0ZSB0aGUgZGVsaXZlcnkgb2YgbXVsdGljYXN0IHRyYWZmaWMNCiAgIHRvIG1vYmlsZSBub2Rl cyBhZnRlciBoYW5kb3ZlcnMuICBUaGUgbWVjaGFuaXNtIGlzIGJhc2VkIG9uIHNwZWVkaW5nDQog ICB1cCB0aGUgYWNxdWlzaXRpb24gb2YgbW9iaWxlIG5vZGVzJyBtdWx0aWNhc3QgY29udGV4dCBi eSB0aGUgbW9iaWxlDQogICBhY2Nlc3MgZ2F0ZXdheXMuICBUbyBkbyB0aGF0LCBleHRlbnNpb25z IHRvIHRoZSBjdXJyZW50IFByb3h5IE1vYmlsZQ0KICAgSVB2NiBwcm90b2NvbCBhcmUgcHJvcG9z ZWQuICBUaGVzZSBleHRlbnNpb25zIGFyZSBub3Qgb25seSBhcHBsaWNhYmxlDQogICB0byB0aGUg YmFzZSBzb2x1dGlvbiBmb3IgbXVsdGljYXN0IHN1cHBvcnQgaW4gUHJveHkgTW9iaWxlIElQdjYs IGJ1dA0KICAgdGhleSBjYW4gYWxzbyBiZSBhcHBsaWVkIHRvIG90aGVyIHNvbHV0aW9ucyBiZWlu ZyBkZXZlbG9wZWQgdG8gYXZvaWQNCiAgIHRoZSB0dW5uZWwgY29udmVyZ2VuY2UgcHJvYmxlbS4g IEZ1cnRoZXJtb3JlLCB0aGV5IGFyZSBhbHNvDQogICBpbmRlcGVuZGVudCBvZiB0aGUgcm9sZSBw bGF5ZWQgYnkgdGhlIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheSB3aXRoaW4NCiAgIHRoZSBtdWx0aWNh c3QgbmV0d29yayAoZWl0aGVyIGFjdGluZyBhcyBtdWx0aWNhc3QgbGlzdGVuZXIgZGlzY292ZXJ5 DQogICBwcm94eSBvciBtdWx0aWNhc3Qgcm91dGVyKS4NCg0KDQoNCg0KVGhlIElFVEYgU2VjcmV0 YXJpYXQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNh amUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25z dWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8g ZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3Nh Z2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2Vu ZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6 DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From lmcm@tid.es Mon Feb 25 14:23: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 268FB21E80AE for ; Mon, 25 Feb 2013 14:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.741 X-Spam-Level: X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDeiXV9K8TxW for ; Mon, 25 Feb 2013 14:23:07 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id B87B521E8040 for ; Mon, 25 Feb 2013 14:23:06 -0800 (PST) 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 <0MIS005HKRIHTW@tid.hi.inet> for multimob@ietf.org; Mon, 25 Feb 2013 23:23:05 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id EC.B5.01293.944EB215; Mon, 25 Feb 2013 23:23:05 +0100 (CET) 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 <0MIS005HERIHTW@tid.hi.inet> for multimob@ietf.org; Mon, 25 Feb 2013 23:23:05 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Mon, 25 Feb 2013 23:23:05 +0100 Date: Mon, 25 Feb 2013 22:23:05 +0000 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: <20130225142639.13979.26353.idtracker@ietfa.amsl.com> X-Originating-IP: [10.95.64.115] To: "multimob@ietf.org" Message-id: <823234EF5C7C334998D973D822FF801B315A8ADB@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: es-ES Content-transfer-encoding: base64 Accept-Language: es-ES, en-US Thread-topic: New Version Notification for draft-contreras-multimob-multiple-upstreams-01.txt Thread-index: AQHOE2QgGvLbYqrm4Eu2t0i16e4FWpiLJajA X-AuditID: 0a5f4068-b7f006d00000050d-4b-512be449eea2 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsXCFe/Apev5RDvQ4N8PI4sZH/tYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMWHDcpaCPqmKn5uOszQw7pDsYuTkkBAwkfi+YSozhC0mceHe erYuRi4OIYENjBJr9k9ihXB+M0qc27KRHcKZyShx98QEsBYWAVWJydPXgNlsAoYSs3aCdHBy CAvESaybuJyli5GDg1PASWJxpxvEBgWJP+ces4DYIgLaEm9e/mECmcks0MMocfv7SWaQel4B b4nmHZEgNbwCghI/Jt8DG8MsoC4xZUouSJhZQFxizq+JrBC2osS0RQ2MIDajgKzEyvOnGSHG x0s8nv2SFcI2kji98BLUkwISS/ach7JFJV4+/gdWIyTgKHH+ww2mCYzis5BsnoWweRaSzbOQ bF7AyLKKUaw4qSgzPaMkNzEzJ93AUC8jUy8zL7VkEyMkhjJ2MC7fqXKIUYCDUYmHV6NDO1CI NbGsuDL3EKMEB7OSCC9nBlCINyWxsiq1KD++qDQntfgQIxMHp1QDI3/6Ld3VWe9NGG8XnP8o 8zz6eqiCwI9C3sL2rcVBQl+XvnLcLH7hm9F/i8XlogdFLwbPYLLZe32FH+s8Tdt/Hx7MCfAU ZjmfGCWr9anzyVrhVvnyrWX/goP3JpjdWqQj/FY4tvdIz3wdv7J3Oe/melbxBPhKcU1PT14k anZJ6L/DvznO1f5rlFiKMxINtZiLihMBdYOe9X8CAAA= References: <20130225142639.13979.26353.idtracker@ietfa.amsl.com> Subject: [multimob] RV: New Version Notification for draft-contreras-multimob-multiple-upstreams-01.txt 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, 25 Feb 2013 22:23:09 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUgc3VibWl0dGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiBkcmFm dC1jb250cmVyYXMtbXVsdGltb2ItbXVsdGlwbGUtdXBzdHJlYW1zLg0KDQpUaGUgZG9jdW1lbnQg aGFzIGJlZW4gYXVnbWVudGVkIGJ5IGluY2x1ZGluZyBzY2VuYXJpb3MgZm9yIGZpeGVkIG5ldHdv cmtzIGFuZCBhbiBpbnRyb2R1Y3RvcnkgYXBwZW5kaXggdG8gUE1JUHY2Lg0KDQpBbnkgY29tbWVu dCBpcyB3ZWxjb21lZCwNCg0KVGhhbmtzIGluIGFkdmFuY2UsDQoNCkJlc3QgcmVnYXJkcywNCg0K THVpcw0KDQotLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KRGU6IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCkVudmlhZG8gZWw6IGx1 bmVzLCAyNSBkZSBmZWJyZXJvIGRlIDIwMTMgMTU6MjcNClBhcmE6IExVSVMgTUlHVUVMIENPTlRS RVJBUyBNVVJJTExPDQpDQzoganVhbmNhcmxvcy56dW5pZ2FAaW50ZXJkaWdpdGFsLmNvbTsgY2pi Y0BpdC51YzNtLmVzDQpBc3VudG86IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt Y29udHJlcmFzLW11bHRpbW9iLW11bHRpcGxlLXVwc3RyZWFtcy0wMS50eHQNCg0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtY29udHJlcmFzLW11bHRpbW9iLW11bHRpcGxlLXVwc3RyZWFt cy0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTHVpcyBNLiBDb250 cmVyYXMgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogICAg ICAgIGRyYWZ0LWNvbnRyZXJhcy1tdWx0aW1vYi1tdWx0aXBsZS11cHN0cmVhbXMNClJldmlzaW9u OiAgICAgICAgMDENClRpdGxlOiAgICAgICAgICAgRXh0ZW5zaW9uIG9mIHRoZSBNTEQgcHJveHkg ZnVuY3Rpb25hbGl0eSB0byBzdXBwb3J0IG11bHRpcGxlIHVwc3RyZWFtIGludGVyZmFjZXMNCkNy ZWF0aW9uIGRhdGU6ICAgMjAxMy0wMi0yNQ0KR3JvdXA6ICAgICAgICAgICBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMjENClVSTDogICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtY29udHJlcmFzLW11bHRpbW9iLW11bHRp cGxlLXVwc3RyZWFtcy0wMS50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1jb250cmVyYXMtbXVsdGltb2ItbXVsdGlwbGUtdXBzdHJlYW1z DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNvbnRy ZXJhcy1tdWx0aW1vYi1tdWx0aXBsZS11cHN0cmVhbXMtMDENCkRpZmY6ICAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtY29udHJlcmFzLW11bHRpbW9iLW11 bHRpcGxlLXVwc3RyZWFtcy0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJlc2Vu dHMgZGlmZmVyZW50IHNjZW5hcmlvcyBvZiBhcHBsaWNhYmlsaXR5IGZvciBhbg0KICAgTUxEIHBy b3h5IHJ1bm5pbmcgbW9yZSB0aGFuIG9uZSB1cHN0cmVhbSBpbnRlcmZhY2UuIFNpbmNlIHRob3Nl DQogICBzY2VuYXJpb3MgaW1wb3NlIGRpZmZlcmVudCByZXF1aXJlbWVudHMgb24gdGhlIE1MRCBw cm94eSB3aXRoDQogICBtdWx0aXBsZSB1cHN0cmVhbSBpbnRlcmZhY2VzLCBpdCBpcyBpbXBvcnRh bnQgdG8gZW5zdXJlIHRoYXQgdGhlDQogICBwcm94eSBmdW5jdGlvbmFsaXR5IGFkZHJlc3NlcyBh bGwgb2YgdGhlbSBmb3IgY29tcGF0aWJpbGl0eS4NCg0KICAgVGhlIHB1cnBvc2Ugb2YgdGhpcyBk b2N1bWVudCBpcyB0byBkZWZpbmUgdGhlIHJlcXVpcmVtZW50cyBpbiBhbiBNTEQNCiAgIHByb3h5 IHdpdGggbXVsdGlwbGUgaW50ZXJmYWNlcyBjb3ZlcmluZyBhIHZhcmlldHkgb2YgYXBwbGljYWJp bGl0eQ0KICAgc2NlbmFyaW9zLCBhbmQgdG8gc3BlY2lmeSB0aGUgcHJveHkgZnVuY3Rpb25hbGl0 eSB0byBzYXRpc2Z5IGFsbCBvZg0KICAgdGhlbS4NCg0KDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2Fq ZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1 bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBl bGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2Fn ZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5k IGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdDoN Cmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From stig@venaas.com Mon Feb 25 14:37:24 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 BCC7B21E80D4 for ; Mon, 25 Feb 2013 14:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPiSwxglzU81 for ; Mon, 25 Feb 2013 14:37:24 -0800 (PST) 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 DB4E821E80CA for ; Mon, 25 Feb 2013 14:37:23 -0800 (PST) Received: from [IPv6:2001:420:301:1004:fd03:20e:59e5:4632] (unknown [IPv6:2001:420:301:1004:fd03:20e:59e5:4632]) by ufisa.uninett.no (Postfix) with ESMTPSA id 31FA68018; Mon, 25 Feb 2013 23:37:21 +0100 (CET) Message-ID: <512BE79A.4030400@venaas.com> Date: Mon, 25 Feb 2013 14:37:14 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <51158232.4050500@venaas.com> <512BBF3C.80901@informatik.haw-hamburg.de> In-Reply-To: <512BBF3C.80901@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "multimob@ietf.org" Subject: Re: [multimob] A couple of comments on draft-ietf-multimob-pmipv6-source-02 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, 25 Feb 2013 22:37:24 -0000 On 2/25/2013 11:45 AM, Thomas C. Schmidt wrote: > Hi Stig, > > thanks again for your comments and sorry for coming back late on this. > > We adjusted the PIM phase transition details you pointed at in our > recent post. > > However - without questioning the judgement of the PIM co-chair ;) - > there are a couple more involvements. > > First, the moving source arrives at a different (tunnel) interface of > the RP ... so PIM implementations need to being able to cope with this > change ... Even though the source address is different, the RP isn't treating them as arriving on different tunnel interfaces. But basically, as you can see from 4601, the RP doesn't care at all who sent the register (apart from where to send a register stop if needed). This means the behavior when receiving registers is not really affected by the source moving. > ... second, the SPTs don't point directly to the MAGs, but to the LMA > (-tunnel interface). In theory, this is a stability anchor which > simplifies, but in practice an unmodified PIM-RP would not know and had > to re-iterate phase transitions ... otherwise, if the stable LMA weren't > in place, data streams would be lost. Since the RP doesn't take the source address of the register into account, there are no transitions on the RP due to the source mobility. When it gets a data register from the new DR, it will behave the same as if it got a data register from the old DR. It may be easiest for me to explain this face to face... Stig > Our update is just a quick sketch ... I guess, some editorial polishing > is needed. > > In addition, we moved the multiple upstream proxy to the appendix as > desired in the Atlanta meeting. > > Cheers, > > Thomas > > On 08.02.2013 14:54, Stig Venaas wrote: >> Hi >> >> The document is in a pretty good shape. I found one issue though. >> >> In 4.3.3 it says: >> >> On handover, the mobile source reattaches to a new MAG (DR), and >> PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new >> point of attachment. However, in the absence of a corresponding >> multicast forwarding state, the new DR will treat S as a new source >> and initiate a source registering of PIM phase one. In consequence, >> the PIM transition from phase one to two will be iterated per >> handover, leading to an enhanced signaling load and repeated delay >> variations. >> >> This is not really the case. The new MAG should be sending registers to >> the same RP as the previous MAG did. If registration had completed so >> that no more data registers were sent by the previous MAG (only periodic >> null-registers to maintain the (S,G) state on the RP), the RP would >> immediately respond with a register stop when it receives a register >> from the new MAG. Basically, the RP behavior does not depend on who is >> sending the registers. >> >> Independent of the registers, if the RP had joined the SPT to receive >> from the source, the SPT would be updated and joins would go towards >> the new MAG. >> >> The same for 4.3.4. >> >> Two minor editorial things I spotted: >> >> >> such as IPTV or sever-centric gaming on mobiles. However, current >> ^^^^^ >> >> bindings) has been performed . Still multicast packets arriving at >> ^^^ >> >> Stig >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > From internet-drafts@ietf.org Mon Feb 25 15:42: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 CAEFE21F8E0B; Mon, 25 Feb 2013 15:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGffqiS5UHJD; Mon, 25 Feb 2013 15:42:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FF821E8179; Mon, 25 Feb 2013 15:42:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225234230.9064.63069.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 15:42:30 -0800 Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-fmipv6-pfmipv6-multicast-01.txt 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, 25 Feb 2013 23:42:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multicast Mobility Working Group of the I= ETF. Title : Multicast Listener Extensions for MIPv6 and PMIPv6 Fast = Handovers Author(s) : Thomas C. Schmidt Matthias Waehlisch Rajeev Koodli Godred Fairhurst Dapeng Liu Filename : draft-ietf-multimob-fmipv6-pfmipv6-multicast-01.txt Pages : 27 Date : 2013-02-25 Abstract: Fast handover protocols for MIPv6 and PMIPv6 define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication, and hence do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, are comprised of delay-sensitive real-time traffic and will benefit from fast handover execution. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by a management of rapid context transfer between access routers, second at the data plane by an optional fast traffic forwarding that may include buffering. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-fmipv6-pfmipv6-multica= st There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv6-multicast-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-fmipv6-pfmipv6-multi= cast-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/