From sarikaya2012@gmail.com Sun Feb 2 15:39:29 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707791A0009 for ; Sun, 2 Feb 2014 15:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wC-wb4Ufk6-M for ; Sun, 2 Feb 2014 15:39:28 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 265381A0014 for ; Sun, 2 Feb 2014 15:39:27 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id c11so4929546lbj.3 for ; Sun, 02 Feb 2014 15:39:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=Qn1JbjfLTuELhVOuJbUZCr68GTy0vzW2AYuaBssdxzU=; b=yBkpE/rilOgjweDunpP7QPFXZxEdY4YcyZ59t39klMy7ZuqsJDZkT/4b01CKIgglW7 QHJvyIzhNhbI+L4De1lKUSleIVQJB14sLB8iOSaHx1QfsNRDFHbEEoQlX8y2IpFjFmtC Od9U0Rzlrv0h0zbj/Tv6t6fPRQysED3BUlPjO/EPmMET+0FegN5WP16P/Okmlg63NvX6 pJUor+EoUkW17lMAcZU9ZOzxF4CpfbQuIi9FRu1+xTyCzyLBx20qV/40FxC16ktHzpFQ 2e7DysMLOWKAw3XZD3p/pAXuiwSLLTaeyJixlZ1Vryn/c7bcBGBHzrgH79CfZ7ijlv8f m+rw== MIME-Version: 1.0 X-Received: by 10.152.42.129 with SMTP id o1mr11343324lal.19.1391384362975; Sun, 02 Feb 2014 15:39:22 -0800 (PST) Received: by 10.114.170.193 with HTTP; Sun, 2 Feb 2014 15:39:22 -0800 (PST) Date: Sun, 2 Feb 2014 17:39:22 -0600 Message-ID: From: Behcet Sarikaya To: "multimob@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3505cb3839d04f174eafc Subject: [multimob] Review of draft-ietf-multimob-fmipv6-pfmipv6-multicast-02 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 02 Feb 2014 23:39:29 -0000 --001a11c3505cb3839d04f174eafc Content-Type: text/plain; charset=ISO-8859-1 Dear all, I finished my review while watching Superball 2014 :-), here it is: - remove MIPv6 from the title Sec. 2 In addition, the following terms are introduced: where are the terms? Sec. 3.1 subnet link use on of them when the group is natively received. What does this mean, please explain As group membership information are s/are/is Sec. 3.2 FMIPv6 coverage is out of scope as it applies to MIPv6, so remove this section Other sections may need adjustment based on this Sec. 4.1.1 As FMIPv6 is out of scope, this section needs to be rewritten to cover PFMIPv6 (if any) Section 5 Here you may add one sentence saying that these structures can apply to MIPv6? Sec. 5.3 The size of this option in 8 octets s/in/is Last but not least, I think the draft finishes without a discussion of why this solution is needed. We need some text on this. I don't know if the reference "FMIPv6-Analysis" could be useful. Regards, Behcet --001a11c3505cb3839d04f174eafc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,

I finished my review while watc= hing Superball 2014 :-), here it is:

- remove MIPv6 from the title
Sec. 2
In addition, the following terms are
=A0=A0 introduced:<= br> =A0=A0 where are the terms?
=A0=A0
Sec. 3.1
subnet link
=A0=A0= use on of them
=A0=A0
when the group is
=A0=A0 natively received= .
=A0=A0 What does this mean, please explain
=A0=A0
As group memb= ership information are
=A0=A0 s/are/is
=A0=A0
Sec. 3.2
=A0 FMIPv6 coverage is out of sc= ope as it applies to MIPv6, so remove this section
=A0 Other sections ma= y need adjustment based on this
Sec. 4.1.1
=A0 As FMIPv6 is out of s= cope, this section needs to be rewritten to cover PFMIPv6 (if any)
Section 5
=A0 Here you may add one sentence saying that these structures= can apply to MIPv6?=A0
Sec. 5.3
=A0 The size of this option in 8 oc= tets
=A0 s/in/is
=A0
Last but not least, I think the draft finish= es without a discussion of why this solution is needed. We need some text o= n this. I don't know if the reference "FMIPv6-Analysis" could= be useful.

Regards,

Behcet
--001a11c3505cb3839d04f174eafc-- From prvs=106df4206=schmidt@informatik.haw-hamburg.de Wed Feb 5 10:00:39 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6751A0124 for ; Wed, 5 Feb 2014 10:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2i4LDn4oGRQ for ; Wed, 5 Feb 2014 10:00:36 -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 373451A001A for ; Wed, 5 Feb 2014 10:00:36 -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; 05 Feb 2014 19:00:35 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 9699810679D7; Wed, 5 Feb 2014 19:00:34 +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 08425-01; Wed, 5 Feb 2014 19:00:30 +0100 (CET) Received: from [192.168.1.96] (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 7465910679CF; Wed, 5 Feb 2014 19:00:30 +0100 (CET) Message-ID: <52F27C39.5070308@informatik.haw-hamburg.de> Date: Wed, 05 Feb 2014 19:00:25 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: sarikaya@ieee.org, "multimob@ietf.org" References: In-Reply-To: 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 Subject: Re: [multimob] Review of draft-ietf-multimob-fmipv6-pfmipv6-multicast-02 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 18:00:39 -0000 Thanks Behcet, for enjoying the Superball. Who won? Regarding the draft, we will provide an update soon that will include previous feedback from the WG, as well. What we already can say right now: We won't rip the draft into pieces and turn it into a fragment, as you please to suggest. Content, coverage and scope of this draft has been under intense discussion since 2010 with two ADs (Jari and Brian) involved. The last clear roadmap on the subject was given by Brian in the Berlin meeting. Behcet, every document we have worked out, you tried to destroy at the very last minute. * For RFC 6224 you requested changes to make it technically completely wrong. * You requested to garble the source draft a couple weeks ago. * Now you ask for ripping apart the *fmipv6 protocol systematic. I don't know why you're doing this ... but it's always against the quality of the documents, against the IETF consensus policy ... and it's always completely useless. So let's just forget this part of your Superball-Review. Cheers, Thomas On 03.02.2014 00:39, Behcet Sarikaya wrote: > Dear all, > > I finished my review while watching Superball 2014 :-), here it is: > > - remove MIPv6 from the title > > Sec. 2 > In addition, the following terms are > introduced: > where are the terms? > > Sec. 3.1 > subnet link > use on of them > > when the group is > natively received. > What does this mean, please explain > > As group membership information are > s/are/is > > Sec. 3.2 > FMIPv6 coverage is out of scope as it applies to MIPv6, so remove > this section > Other sections may need adjustment based on this > Sec. 4.1.1 > As FMIPv6 is out of scope, this section needs to be rewritten to > cover PFMIPv6 (if any) > Section 5 > Here you may add one sentence saying that these structures can apply > to MIPv6? > Sec. 5.3 > The size of this option in 8 octets > s/in/is > > Last but not least, I think the draft finishes without a discussion of > why this solution is needed. We need some text on this. I don't know if > the reference "FMIPv6-Analysis" could be useful. > > Regards, > > Behcet > > > _______________________________________________ > 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 iesg-secretary@ietf.org Mon Feb 10 07:53:50 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE9B1A087F; Mon, 10 Feb 2014 07:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElnakrUAr_BL; Mon, 10 Feb 2014 07:53:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E42E91A086D; Mon, 10 Feb 2014 07:53:48 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140210155348.10286.75549.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 07:53:48 -0800 Cc: multimob@ietf.org Subject: [multimob] Last Call: (Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains) to Experimental RFC X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:53:50 -0000 The IESG has received a request from the Multicast Mobility WG (multimob) to consider the following document: - 'Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-02-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 a base solution and an experimental protocol to support of mobile multicast senders in Proxy Mobile IPv6 domains for all three scenarios. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD Proxies are defined. Mobile sources always remain agnostic of multicast mobility operations. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source/ballot/ No IPR declarations have been submitted directly on this I-D. From sarikaya2012@gmail.com Wed Feb 12 09:21:48 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AD61A05FD for ; Wed, 12 Feb 2014 09:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntdZp6-CHMP9 for ; Wed, 12 Feb 2014 09:21:45 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B73671A0902 for ; Wed, 12 Feb 2014 09:21:44 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id u14so7432230lbd.1 for ; Wed, 12 Feb 2014 09:21:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1cqo99OXEzFEDbV+HYxElq53mOzaJNAzOmZSocVIJ80=; b=L5LGqnT6b+D9dxQkpddR5mAbcDT/rUQzyTzXOus15e5LqFyt22JM+Z2llk9jcfA6F1 AUvshHeHd1Y1Pnr5t7+bh7Zw9e25IiSCFHNTYtTe/Du/I5/G9a6f5yEgOmFu+zp97BQj 1HVXRCwecRQk1FPIu+kqjfXcWmxT3ZCA+mBNQ10QqUBjsBRaiengV4gQNyIi5eZn8Flx tmNAjZ9SE7V62l9jP4iW+raBSxeoXJ9UrI+KGp3n7KSFOUs9KqCoeqBYfBc5y1glSDto FhgRGk81x7/QuWaVdRLJbGRaJy3sP89CfwE7bcPhb6cZMHAqP6lXGIwNXYCq7a+AaTjF WXlA== MIME-Version: 1.0 X-Received: by 10.112.41.100 with SMTP id e4mr40009lbl.84.1392225703089; Wed, 12 Feb 2014 09:21:43 -0800 (PST) Received: by 10.114.170.193 with HTTP; Wed, 12 Feb 2014 09:21:43 -0800 (PST) In-Reply-To: <52F27C39.5070308@informatik.haw-hamburg.de> References: <52F27C39.5070308@informatik.haw-hamburg.de> Date: Wed, 12 Feb 2014 11:21:43 -0600 Message-ID: From: Behcet Sarikaya To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=001a1135e87a7adba204f238ceb3 Cc: "multimob@ietf.org" Subject: Re: [multimob] Review of draft-ietf-multimob-fmipv6-pfmipv6-multicast-02 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 17:21:49 -0000 --001a1135e87a7adba204f238ceb3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas, Please see inline. Regards, Behcet On Wed, Feb 5, 2014 at 12:00 PM, Thomas C. Schmidt < schmidt@informatik.haw-hamburg.de> wrote: > Thanks Behcet, > > for enjoying the Superball. Who won? > > Seattle Seahawks won, you should have watched the game it was fun :-) (not like reading your mail, though) > Regarding the draft, we will provide an update soon that will include > previous feedback from the WG, as well. > > What we already can say right now: > > We won't rip the draft into pieces and turn it into a fragment, as you > please to suggest. Content, coverage and scope of this draft has been und= er > intense discussion since 2010 with two ADs (Jari and Brian) involved. The > last clear roadmap on the subject was given by Brian in the Berlin meetin= g. > > I don't think Brian made any technical comments on your draft. > Behcet, every document we have worked out, you tried to destroy at the > very last minute. > > Wow, this is big claim. Please see below. > * For RFC 6224 you requested changes to make it technically completely > wrong. > > This is an old story. The comments I made were completely technical, I had even put them in issue tracker, this was the first and last time the issue tracker was used in Multimob and they were not wrong. Please go to the list, get my comments and let Multimob know which ones were wrong, I challenge you on this, because you always refused to comment on them. * You requested to garble the source draft a couple weeks ago. > > Again, I made technical comments. You personally claimed that PIM at MAG won't work for receiver mobility. But now you are including in the source mobility draft PIM at MAG case. Can I ask you what type of deployment policy we are advocating to the operators? For receiver mobility you should have Proxy at MAG. You can not have PIM at MAG. For source mobility which is much less frequently used case, you should deploy PIM at MAG? * Now you ask for ripping apart the *fmipv6 protocol systematic. > > I just noticed that you included fmipv6 even into the draft name. This is the same story. Multimob was chartered to work on PMIPv6 multicast extensions not MIPv6 because MIPv6 already had multicast support. We called it multicast mobility WG because we wanted to include IGMP/MLD for mobility cases which we did to some extent. You seem to feel free to add anything you like to your drafts and if asked to remove you claim that we are trying to garble your draft. I don't know why you're doing this ... but it's always against the quality > of the documents, against the IETF consensus policy ... and it's always > completely useless. > > I did similar requests to ropt draft, we asked PIM text to be removed and the authors did remove, they did not claim that their document is being garbled. I did similar request to Luis' handover draft, we asked a chunk of the draft (about 10 pages) to be removed, again, the authors did it and they did not claim their document is being garbled. Again let me state it clearly, PIM at MAG sections in source mobility draft and FMIPv6 and MIPv6 sections in your handover draft are out of scope in Multimob. > So let's just forget this part of your Superball-Review. > > Thanks for your nice words. Regards, Behcet > Cheers, > > Thomas > > > > On 03.02.2014 00:39, Behcet Sarikaya wrote: > >> Dear all, >> >> I finished my review while watching Superball 2014 :-), here it is: >> >> - remove MIPv6 from the title >> >> Sec. 2 >> In addition, the following terms are >> introduced: >> where are the terms? >> >> Sec. 3.1 >> subnet link >> use on of them >> >> when the group is >> natively received. >> What does this mean, please explain >> >> As group membership information are >> s/are/is >> >> Sec. 3.2 >> FMIPv6 coverage is out of scope as it applies to MIPv6, so remove >> this section >> Other sections may need adjustment based on this >> Sec. 4.1.1 >> As FMIPv6 is out of scope, this section needs to be rewritten to >> cover PFMIPv6 (if any) >> Section 5 >> Here you may add one sentence saying that these structures can apply >> to MIPv6? >> Sec. 5.3 >> The size of this option in 8 octets >> s/in/is >> >> Last but not least, I think the draft finishes without a discussion of >> why this solution is needed. We need some text on this. I don't know if >> the reference "FMIPv6-Analysis" could be useful. >> >> Regards, >> >> Behcet >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> >> > -- > > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner Tor= 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germa= ny =B0 > =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-84= 52=B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-84= 09=B0 > --001a1135e87a7adba204f238ceb3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,

Please see inline.<= br>
Regards,

Behcet


On Wed, Feb 5, 2014 at = 12:00 PM, Thomas C. Schmidt <schmidt@informatik.haw-hambur= g.de> wrote:
Thanks Behcet,

for enjoying the Superball. Who won?

Seattle Seahawks won, you should have watched the gam= e it was fun :-)
(not like reading your mail, though)
=A0<= br>
Regarding the draft, we will provide an update soon that will include previ= ous feedback from the WG, as well.

What we already can say right now:

=A0We won't rip the draft into pieces and turn it into a fragment, as y= ou please to suggest. Content, coverage and scope of this draft has been un= der intense discussion since 2010 with two ADs (Jari and Brian) involved. T= he last clear roadmap on the subject was given by Brian in the Berlin meeti= ng.

I don't think Brian made any technical comments o= n your draft.
=A0
Behcet, every document we have worked out, you tried to destroy at the very= last minute.


Wow, this is big claim. Please see bel= ow.
=A0
=A0* For RFC 6224 you requested changes to make it technically completely w= rong.


This is an old story.
T= he comments I made were completely technical, I had even put them in issue = tracker, this was the first and last time the issue tracker was used in Mul= timob
=A0and they were not wrong.
Please go to the list, get my com= ments and let Multimob know which ones were wrong, I challenge=A0 you on th= is, because you always refused to comment on them.

=A0* You requested to garble the source draft a couple weeks ago.

Again, I made technical comments. You personally clai= med that PIM at MAG won't work for receiver mobility.
But= now you are including in the source mobility draft PIM at MAG case.

Can I ask you what type of deployment policy we are advocati= ng to the operators?

For receiver mobility you should hav= e Proxy at MAG. You can not have PIM at MAG.
For source mobil= ity which is much less frequently used case, you should deploy PIM at MAG?<= br>

=A0* Now you ask for ripping apart the *fmipv6 protocol systematic.


I just noticed that you included fmipv= 6 even into the draft name.
This is the same story.
Multi= mob was chartered to work on PMIPv6 multicast extensions not MIPv6 because = MIPv6 already had multicast support.
We called it multicast mobility WG because we wanted to include = IGMP/MLD for mobility cases which we did to some extent.

= You seem to feel free to add anything you like to your drafts and if asked = to remove you claim that we are trying to garble your draft.

I don't know why you're doing this ... but it's always against = the quality of the documents, against the IETF consensus policy ... and it&= #39;s always completely useless.


I did similar requests to ropt draft, = we asked PIM text to be removed and the authors did remove, they did not cl= aim that their document is being garbled.

I did similar r= equest to Luis' handover draft, we asked a chunk of the draft (about 10= pages) to be removed, again, the authors did it and they did not claim the= ir document is being garbled.

Again let me state it clearly, PIM at MAG sections in source= mobility draft and FMIPv6 and MIPv6 sections in your handover draft are ou= t of scope in Multimob.

=A0
So let's just forget this part of your Superball-Review.


Thanks for your nice words.

Regards,

Behcet
Cheers,

Thomas



On 03.02.2014 00:39, Behcet Sarikaya wrote:
Dear all,

I finished my review while watching Superball 2014 :-), here it is:

- remove MIPv6 from the title

Sec. 2
In addition, the following terms are
=A0 =A0 introduced:
=A0 =A0 where are the terms?

Sec. 3.1
subnet link
=A0 =A0 use on of them

when the group is
=A0 =A0 natively received.
=A0 =A0 What does this mean, please explain

As group membership information are
=A0 =A0 s/are/is

Sec. 3.2
=A0 =A0FMIPv6 coverage is out of scope as it applies to MIPv6, so remove this section
=A0 =A0Other sections may need adjustment based on this
Sec. 4.1.1
=A0 =A0As FMIPv6 is out of scope, this section needs to be rewritten to
cover PFMIPv6 (if any)
Section 5
=A0 =A0Here you may add one sentence saying that these structures can apply=
to MIPv6?
Sec. 5.3
=A0 =A0The size of this option in 8 octets
=A0 =A0s/in/is

Last but not least, I think the draft finishes without a discussion of
why this solution is needed. We need some text on this. I don't know if=
the reference "FMIPv6-Analysis" could be useful.

Regards,

Behcet


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


--

Prof. Dr. Thomas C. Schmidt
=B0 Hamburg University of Applied Sciences =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 Berliner Tor 7 =B0
=B0 Dept. Informatik, Internet Technologies Group =A0 =A020099 Hamburg, Ger= many =B0
=B0 http://www= .haw-hamburg.de/inet =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fon: +49= -40-42875-8452 =B0
=B0 http://www.informatik.haw-hamburg.de/~schmidt =A0 =A0Fax: <= a href=3D"tel:%2B49-40-42875-8409" value=3D"+4940428758409" target=3D"_blan= k">+49-40-42875-8409 =B0

--001a1135e87a7adba204f238ceb3-- From brian@innovationslab.net Thu Feb 13 05:16:12 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402D41A0234 for ; Thu, 13 Feb 2014 05:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gxwl6EFqAGp for ; Thu, 13 Feb 2014 05:16:09 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7D01A0225 for ; Thu, 13 Feb 2014 05:16:09 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 3EE1B880A7 for ; Thu, 13 Feb 2014 05:16:08 -0800 (PST) Received: from Littlejohn.local (c-76-21-129-88.hsd1.md.comcast.net [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7C9B01368159 for ; Thu, 13 Feb 2014 05:16:07 -0800 (PST) Message-ID: <52FCC590.2000602@innovationslab.net> Date: Thu, 13 Feb 2014 08:16:00 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: multimob@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3kMiJVwUBccqTauDi1B6amU3xLXHuBmIa" Subject: Re: [multimob] draft-ietf-multimob-fmipv6-pfmipv6-multicast-02 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 13:16:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3kMiJVwUBccqTauDi1B6amU3xLXHuBmIa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, It appears that there has been exactly one review done on this draft during the current Last Call period. Even though it is an Experimental document, the IESG is generally not happy with seeing no comments during a document's WGLC. I can assume that the authors want to see the document advance, but I would like to see some semblance of support from the rest of the WG. Otherwise, I consider it an unpublishable document. Regards, Brian (as shepherding AD) On 1/17/14 1:15 PM, Behcet Sarikaya wrote: > Folks, >=20 > This message starts a four week (as usual in Multimob) > Multimob Working Group last call > on advancing: >=20 >=20 > 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-02.txt > Pages : 27 > Date : 2013-12-13 >=20 > as Experimental. Substantive comments and statements of support > for advancing this document should be directed to the mailing list. > Editorial suggestions can be sent to the authors. This last call will > end on February 14, 2014. >=20 > Regards, > Behcet >=20 >=20 >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob >=20 --3kMiJVwUBccqTauDi1B6amU3xLXHuBmIa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS/MWWAAoJEBOZRqCi7goqWgkH/1bdXOgSTI4R0PJeeh4VI2I+ YEeg1p0TQWeGMLeK4oiLCMtvThZngCKs0u0rSKmWCRe28Abma+4CJCConbxau8UM VQ7Hj4EG5XjvSkVSuD5+Ghjx6dJP5IzKGHtguDU85DPkGmknoJ8VFdGwDIIUYRCt XW9daB8tbYEQeOR50tTXl2QgGXs2RmS7T43RZ2FJAzPut1iJXnCgScLf1vSh7fgo J92wyyMKYwQhq3oAWz7MGICiA2Sj4LN/rwSNhNZqMEASrFEII69UeKYcNxtfsPfI ot/702wZS7iSv5a3YIIyyHuIr9LLDjldEIcH7ls3IBekd9kWSZnbUkiSsAKfZmI= =r3Va -----END PGP SIGNATURE----- --3kMiJVwUBccqTauDi1B6amU3xLXHuBmIa-- From nobody Thu Feb 13 14:11:04 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FE71A040C for ; Thu, 13 Feb 2014 14:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_84=0.6, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyiOjM6p4MHV for ; Thu, 13 Feb 2014 14:10:50 -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 DA6131A041B for ; Thu, 13 Feb 2014 14:10:49 -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; 13 Feb 2014 23:10:47 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 79B6E10679D7; Thu, 13 Feb 2014 23:10: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 17409-05; Thu, 13 Feb 2014 23:10:45 +0100 (CET) Received: from [192.168.178.49] (g231108249.adsl.alicedsl.de [92.231.108.249]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 1B69810679CF; Thu, 13 Feb 2014 23:10:45 +0100 (CET) Message-ID: <52FD42E4.3000502@informatik.haw-hamburg.de> Date: Thu, 13 Feb 2014 23:10:44 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: karagian@cs.utwente.nl References: <201309251549114085692@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/eFYnyz5dNJR8js3FYaGCWEQ7lWg Cc: multimob@ietf.org Subject: Re: [multimob] I-D Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 22:10:54 -0000 Hi Georgios, thanks again for your thorough review and sorry for our delayed work on this. We're currently collecting all the previous comments/reviews and combine them in an updated version of the document ... which then is hopefully in good rough consensus of the WG. Please see answers inline: On 01.10.2013 08:06, karagian@cs.utwente.nl wrote: > During the last multimob WG meeting in Berlin I had volunteerd to > provide comments on the last version of this draft. > > Here are these comments: > > Comment_1:The draft is useful since it is providing a solution for > seamless and fast handover for multicast applications by extending > existing seamless and fast handover solutions used for unicast > applications, which are the Mobile IPv6 Fast Handovers (FMIPv6) > specified in RFC5568 and the Fast Handovers for Proxy Mobile IPv6 > (PFMIPv6) specified in RFC5949. > Thanks - we agree :-) > Comment_2: A motivation section is missing from the draft. In my opinion > it is very useful to include such section in this draft. Okay: a similar comment was made by Behcet. We will add a subsection (see below). >In particular, > this draft mentions that a seamless and fast handover solutions is > needed for multicast applications like IPTV. Other scenarios and > applications that will make use of such a solutions are Public > Protection and Disaster Relief (PPDR) scenarios, where mobile multicast > communications need to be supported between members of rescue teams, > police officers, fire brigade teams, paramedic teams, command control > offices in order to support the protection and health of citizens. > > In particular three main PPDR scenarios & application types could be > distinguished: > > 1)City security scenario:that can be used to support the day to day > safety and security of citizens. > > 2)Disaster recovery scenario that deals with the protection of people > and rescue teams during large scale natural or man-made disasters, like > flooding, earth quakes and nuclear disasters. > > 3)Temporary Protection PPDR scenario that deals with safety and security > of citizens visiting large planned events like football matches, pop > concerts and protest demonstrations. > A very good point - actually we are currently working with an airport on such crisis prevention and disaster recovery solutions, it is of emerging importance. We have added the following text: -------------------------- snip ---------------------------------- 1.1. Use Cases and Deployment Scenarios Multicast Extensions for Fast Handovers enable multicast services in those domains that operate any of the unicast fast handover protocols [RFC5568] or [RFC5949]. Typically, fast handover protocols are activated within an operator network or within a dedicated service installation. Multicast group communication has a variety of dominant use cases. One traditional application area is infotainment with voluminous multimedia streams delivered to a large number of receivers (e.g., IPTV). Other time-critical news items like stock-exchange prices are commonly transmitted via multicast to support fair and fast updates. Both may be mobile and both largely benefit from fast handover operations. Operators may enhance their operational quality or offer premium services by enabling fast handovers. Another traditional application area for multicast is conversational group communication in scenarios like conferencing or gaming, but also in dedicated collaborative environments or teams. Machine-to- machine communication in the emerging Internet of Things is expected to generate various additional mobile use cases (e.g., among cars). High demands on transmission quality and rapidly moving parties may require fast handovers. Most of the deployment scenarios above are bound to a fixed infrastructure with consumer equipment at the edge. Today, they are thus likely to follow an operator-centric approach like PFMIPv6. However, Internet technologies evolve for adoption in infrastructureless scenarios at desaster recovery, rescue, crisis prevention and civil safety. Mobile end-to-end communication in groups is needed in Public Protection and Disaster Relief (PPDR) scenarios, where mobile multicast communication needs to be supported between members of rescue teams, police officers, fire brigade teams, paramedic teams, command control offices in order to support the protection and health of citizens. These use cases require fast and reliable mobile services which cannot rely on operator infrastructure. They are thus predestined to running multicast with FMIPv6. -------------------------- snap ---------------------------------- > Comment_3: List the requirements that need to be satisfied by this > solution. You may use as example Section 1.1 of > http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-04.txt > I'm not sure here: Different from the rather 'individual' solution presented in draft-ietf-multimob-handover-optimization, the fast handover document works out multicast extensions for the existing fast handover protocol standards. So the requirement basically reads * multicast shall be transparently included in *fmipv6 handover operations without harming anything else. But this is very explicitly stated in the abstract and introduction, so an additional requirements section would be either completely trivial, or a repetition of what has been already said. Do you think of any particular aspect we forgot to mention? > Comment_4: Provide a more detailed message flow description, similar to > the one that is given in Section 5.1.2 in± > > http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-04.txt > > This comment holds for Figures 2, 3, 4, 5 > This again is a bit unclear to me. The difference between the figures in draft-ietf-multimob-handover-optimization and our Figs 2 - 5 are (a) other entities are involved (b) there are some comments on states in the figures from draft-ietf-multimob-handover-optimization In fact, the fast handover operations are much simpler than operations in draft-ietf-multimob-handover-optimization, and directly plug into the unicast protocol elements. It is more 'natural' to compare with the call flows in [RFC5568] and [RFC5949]. If you do so, what would you propose to add? > Comment_5: There is no description on how this draft, which specifies a > mobile multicast listener support solution, can be used in combination a > the mobile multicast senders, solution e.g., > http://www.ietf.org/id/draft-ietf-multimob-pmipv6-source-05.txt. > > There are scenarios and applications that require the use of these two > solutions simultaneously. > You are right. draft-ietf-multimob-pmipv6-source does not touch the fast handover solution. The current document is bound to listener operation which was a result of the charter. The best way is probably to add the sender aspects to an appendix, as a free gift let's say. Do you agree? Thanks again & best regards Thomas >> >>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. >> >> 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-multicast >> >>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=draft-ietf-multimob-fmipv6-pfmipv6-multicast-01 >> >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>multimob mailing list >>multimob@ietf.org >>https://www.ietf.org/mailman/listinfo/multimob > > = = = = = = = = = = = = = = = = = = = = > > > 　　　　　　　　致 > 礼！ > > > Shuai Gao > Associate Professor > National Engineering Lab for Next Generation Internet Interconnection > Devices > Beijing Jiaotong University > Beijing, China, 100044 > gaoxlh@gmail.com > 2013-09-25 > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Thu Feb 13 15:25:43 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEB01A0023 for ; Thu, 13 Feb 2014 15:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.052 X-Spam-Level: *** X-Spam-Status: No, score=3.052 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVEncP3a-Wy3 for ; Thu, 13 Feb 2014 15:25:38 -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 C93A61A001D for ; Thu, 13 Feb 2014 15:25:37 -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; 14 Feb 2014 00:25:35 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 7100910679D7; Fri, 14 Feb 2014 00:25:35 +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 19171-08; Fri, 14 Feb 2014 00:25:34 +0100 (CET) Received: from [192.168.178.49] (g231108249.adsl.alicedsl.de [92.231.108.249]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 868D410679CF; Fri, 14 Feb 2014 00:25:34 +0100 (CET) Message-ID: <52FD546E.8050900@informatik.haw-hamburg.de> Date: Fri, 14 Feb 2014 00:25:34 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Shuai Gao References: <201309251549114085692@gmail.com> In-Reply-To: <201309251549114085692@gmail.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/uSUUmTmoSYJ4dXEfpBTrax3xhLI Cc: multimob Subject: Re: [multimob] I-D Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 23:25:41 -0000 Hi Shuai, many thanks for your earlier review and sorry that we picked up work on this late. We're now catching up and try to finalize the document (as it had been struck by an unexpected last call ;) ). Please see answers inline: On 25.09.2013 09:49, Shuai Gao wrote: > As promised at IETF-87, I have reviewed the Fast Handover draft. Overall the I-D is in very good shape. I have a few comments for your consideration. > > 1) P3: improve these handover delays for unicast communication to the order of the maximum delay needed for link switching and signaling between Access Routers (ARs) or Mobile Access Gateways (MAGs) [FMIPv6-Analysis]. ==> improve the performance of handover delays Also, what does to the order mean in this sentence? You're right, this sentence is a bit imprecise. We changed to Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568], and Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) [RFC5949] improve the performance of these handover delays for unicast communication to the order of the maximum of the delays needed for link switching and signaling between Access Routers (ARs) or Mobile Access Gateways (MAGs) [FMIPv6-Analysis]. "to the order" means that the delay is approximately as stated (plus noise). In this reference, the indicated delays were identified as the leading terms in a series of delays. > > 2) P5: The specified mechanisms apply when a mobile node has joined and maintains ==> The specified mechanisms apply when a mobile node has joined and maintained I don't think so: The sentence basically says that handover mechanisms apply to active group membership ... this is "has joined and maintains" or "continues to maintain". On the contrary, if group membership is not maintained anymore, i.e., lost, no multicast handover is required. > > 3) P6: Depending on the specific network topology though, multicast traffic for some groups ==> delete the word though in this sentence. O.K. > > 4) P6: that make it undesirable to forward the multicast traffic.The PAR can ==> that make it undesirable to forward the multicast traffic. The PAR can Thanks, fixed. > > 5) P7: The NAR implements an MLD proxy [RFC4605] providing host-side behaviour on behalf of the upstream PAR. ==> Here, on behalf of the upstream PAR is little confusing. I suggest to modify to towards the upstream PAR. Yes, good suggestion - done. > > 6) P9: In figure 3, FBU has contained the Multicast Option, and thereby both PAR and NAR have known the related multicast information. So the question is whether its necessary to include Multicast Option in the HI message here? As inherited from unicast, FBU is tunneled to PAR and NAR is not intercepting messages. HI/HACk with MobOpts is performed to keep the access router in sync. It may be that native multicast traffic arrives quickly from the local join after handover, but then membership transfer is terminated from NAR (explicitly without timeout). If native routing is slow, the tunneling of multicast traffic will be appreciated. Does this address your comments exhaustively? If yes, it would be good to hear your opinion on the WG last call. Best regards, Thomas > ======= 2013-02-26 07:44:10 д======= > >> >> 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. >> >> 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-multicast >> >> 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=draft-ietf-multimob-fmipv6-pfmipv6-multicast-01 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > > = = = = = = = = = = = = = = = = = = = = > > > > > > > Shuai Gao > Associate Professor > National Engineering Lab for Next Generation Internet Interconnection Devices > Beijing Jiaotong University > Beijing, China, 100044 > gaoxlh@gmail.com > 2013-09-25 > > _______________________________________________ > 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 nobody Thu Feb 13 17:18:33 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F32D1A0045 for ; Thu, 13 Feb 2014 17:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.039 X-Spam-Level: X-Spam-Status: No, score=-0.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfP352J2o5O5 for ; Thu, 13 Feb 2014 17:18:27 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A7C481A000E for ; Thu, 13 Feb 2014 17:18:27 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id g10so11202183pdj.16 for ; Thu, 13 Feb 2014 17:18:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type; bh=ywI0ers9Tb39FTcyPMtsjiG78GtomohpFW3jiRVb7yg=; b=VwQANEXQ5GgKLA59FuWeeGfgWilb6nxfaO7MykhKbCIbLwqk1kHimEteGZQSwsalZV 1KSl099FXRdYiZcyY4uw5kwQXmU8q1zDNDtrCN9OM3Dpd+0GHO0kVr5VyJOFn3RFthcd KJnTM0+nmww5kYtQkYImVlAuPPfbuR94EZL2LOut61p0upjvaEWIM55rfcxU1gH30ozX zVR2frdWY2yWI2n6MllmHtL8zhubhkGtd2q+8RIefsY15dvmur6FM+uv1QQbn1tWhAVi Oka0IFwUmg7y6t1chUbaMCc8z/lMr/BVzWVM0m8UZFtJvHVwV9wOJ98UpL+VZl4/ElJC Q7Zg== X-Received: by 10.66.129.133 with SMTP id nw5mr5418770pab.98.1392340706396; Thu, 13 Feb 2014 17:18:26 -0800 (PST) Received: from admin-PC ([211.71.74.133]) by mx.google.com with ESMTPSA id om6sm10983085pbc.43.2014.02.13.17.18.21 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 13 Feb 2014 17:18:25 -0800 (PST) Date: Fri, 14 Feb 2014 09:18:23 +0800 From: "=?utf-8?B?U2h1YWkgR2Fv?=" To: "=?utf-8?B?c2FyaWtheWE=?=" , "=?utf-8?B?bXVsdGltb2JAaWV0Zi5vcmc=?=" Message-ID: <201402140918206810562@gmail.com> X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon044371450466_=====" Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/XBQV-sDi3MAhylHKF0KZQw0Mzxs Subject: Re: [multimob] =?utf-8?q?draft-ietf-multimob-fmipv6-pfmipv6-multicast?= =?utf-8?q?-02?= X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 01:18:29 -0000 This is a multi-part message in MIME format. --=====003_Dragon044371450466_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUaGlzIGRyYWZ0IGhhcyBiZWVuIGRpc2N1c3NlZCBmb3IgYSBsb25nIHRpbWUg YW5kIGl0J3MgaW4gYSBnb29kIHNoYXBlIG5vdy4NCkkgc3VwcG9ydCBhIHN1Y2Vzc2Z1bCBXR0xD LiANCg0KQWxzbywgSSdtIGxvb2sgZm9yd2FyZCB0byBuZXh0IHZlcnNpb24gd2hpY2ggd2lsbCBp bmNsdWRlIGFsbCB0aGUgZmVlZGJhY2tzIGZyb20gcmV2aWV3ZXJzIGFzIHRoZSBhdXRob3IgcHJv bWlzZWQuIA0KDQpSZWdhcmRzLA0KU2h1YWkNCuOAgOOAgA0KDQo9PT09PT09PSAyMDE0LTAxLTE4 IDAyOjE1OjIwIOaCqOWcqOadpeS/oeS4reWGmemBk++8miA9PT09PT09PQ0KDQpGb2xrcywNCg0K DQpUaGlzIG1lc3NhZ2Ugc3RhcnRzIGEgZm91ciB3ZWVrIChhcyB1c3VhbCBpbiBNdWx0aW1vYikg TXVsdGltb2IgV29ya2luZyBHcm91cCBsYXN0IGNhbGwNCm9uIGFkdmFuY2luZzoJVGl0bGUgICAg ICAgICAgIDogTXVsdGljYXN0IExpc3RlbmVyIEV4dGVuc2lvbnMgZm9yIE1JUHY2IGFuZCBQTUlQ djYgRmFzdCBIYW5kb3ZlcnMNCglBdXRob3IocykgICAgICAgOiBUaG9tYXMgQy4gU2NobWlkdA0K ICAgICAgICAgICAgICAgICAgICAgICAgICBNYXR0aGlhcyBXYWVobGlzY2gNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgUmFqZWV2IEtvb2RsaQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBH b2RyZWQgRmFpcmh1cnN0DQogICAgICAgICAgICAgICAgICAgICAgICAgIERhcGVuZyBMaXUNCglG aWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW11bHRpbW9iLWZtaXB2Ni1wZm1pcHY2LW11bHRp Y2FzdC0wMi50eHQNCglQYWdlcyAgICAgICAgICAgOiAyNw0KCURhdGUgICAgICAgICAgICA6IDIw MTMtMTItMTNhcyBFeHBlcmltZW50YWwuICBTdWJzdGFudGl2ZSBjb21tZW50cyBhbmQgc3RhdGVt ZW50cyBvZiBzdXBwb3J0DQpmb3IgYWR2YW5jaW5nIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIGRp cmVjdGVkIHRvIHRoZSBtYWlsaW5nIGxpc3QuDQpFZGl0b3JpYWwgc3VnZ2VzdGlvbnMgY2FuIGJl IHNlbnQgdG8gdGhlIGF1dGhvcnMuICBUaGlzIGxhc3QgY2FsbCB3aWxsDQplbmQgb24gRmVicnVh cnkgMTQsIDIwMTQuUmVnYXJkcywNCkJlaGNldA0KDQoNCj0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9 ID0gPSA9ID0gPSA9ID0gPSA9ID0gDQrjgIDjgIDjgIDjgIDjgIDjgIDjgIDjgIDoh7QNCuekvO+8 gQ0KDQrjgIDjgIDjgIDjgIDjgIDjgIDjgIDjgIDjgIDjgIDjgIDjgIDjgIDjgIBTaHVhaSBHYW8N CuOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgGdhb3hsaEBnbWFpbC5j b20NCuOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgDIw MTQtMDItMTQNCg== --=====003_Dragon044371450466_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCA4LjAwLjc2MDAuMTcwNTEiPjxMSU5LIHJlbD1zdHlsZXNoZWV0IA0KaHJl Zj0iQkxPQ0tRVU9URXttYXJnaW4tVG9wOiAwcHg7IG1hcmdpbi1Cb3R0b206IDBweDsgbWFyZ2lu LUxlZnQ6IDJlbX0iPjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2VhZWFlYT4NCjxESVY+PEZPTlQg c2l6ZT0yIGZhY2U95a6L5L2TPkhpIGFsbCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 MiBmYWNlPeWui+S9kz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNl PeWui+S9kz5UaGlzIGRyYWZ0IGhhcyBiZWVuIGRpc2N1c3NlZCBmb3IgYSBsb25nIHRpbWUgYW5k IGl0J3MgDQppbiBhIGdvb2Qgc2hhcGUgbm93LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yIGZhY2U95a6L5L2TPkkgc3VwcG9ydCBhIHN1Y2Vzc2Z1bCBXR0xDLiA8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPeWui+S9kz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIHNpemU9MiBmYWNlPeWui+S9kz5BbHNvLCBJJ20gbG9vayBmb3J3YXJkIHRvIG5leHQg dmVyc2lvbiB3aGljaCB3aWxsIA0KaW5jbHVkZSBhbGwgdGhlIGZlZWRiYWNrcyBmcm9tIHJldmll d2VycyBhcyB0aGUgYXV0aG9yIHByb21pc2VkLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNp emU9MiBmYWNlPeWui+S9kz48L0ZPTlQ+PEZPTlQgc2l6ZT0yIGZhY2U95a6L5L2TPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+UmVnYXJkcyw8L0RJVj4NCjxESVY+U2h1YWk8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yIGZhY2U95a6L5L2TPuOAgOOAgDwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPeWui+S9kz49PT09PT09PSAyMDE0LTAxLTE4 Jm5ic3A7MDI6MTU6MjAmbmJzcDvmgqjlnKjmnaXkv6HkuK3lhpnpgZPvvJogDQo9PT09PT09PTwv Rk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4NCjxUQUJM RSB3aWR0aD0iMTAwJSI+DQogIDxUQk9EWT4NCiAgPFRSPg0KICAgIDxURCB3aWR0aD0iMTAwJSI+ DQogICAgICA8QkxPQ0tRVU9URSANCiAgICAgIHN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAwMCAy cHggc29saWQ7IFBBRERJTkctTEVGVDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1M RUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICAgICAgPERJViBkaXI9bHRyPkZvbGtz LDxCUj48QlI+PFBSRT5UaGlzIG1lc3NhZ2Ugc3RhcnRzIGEgZm91ciB3ZWVrIChhcyB1c3VhbCBp biBNdWx0aW1vYikgPEJSPk11bHRpbW9iIFdvcmtpbmcgR3JvdXAgbGFzdCBjYWxsDQpvbiBhZHZh bmNpbmc6PEJSPjxCUj48QlI+CVRpdGxlICAgICAgICAgICA6IE11bHRpY2FzdCBMaXN0ZW5lciBF eHRlbnNpb25zIGZvciBNSVB2NiBhbmQgUE1JUHY2IEZhc3QgSGFuZG92ZXJzDQoJQXV0aG9yKHMp ICAgICAgIDogVGhvbWFzIEMuIFNjaG1pZHQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgTWF0 dGhpYXMgV2FlaGxpc2NoDQogICAgICAgICAgICAgICAgICAgICAgICAgIFJhamVldiBLb29kbGkN CiAgICAgICAgICAgICAgICAgICAgICAgICAgR29kcmVkIEZhaXJodXJzdA0KICAgICAgICAgICAg ICAgICAgICAgICAgICBEYXBlbmcgTGl1DQoJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1t dWx0aW1vYi1mbWlwdjYtcGZtaXB2Ni1tdWx0aWNhc3QtMDIudHh0DQoJUGFnZXMgICAgICAgICAg IDogMjcNCglEYXRlICAgICAgICAgICAgOiAyMDEzLTEyLTEzPEJSPjxCUj5hcyBFeHBlcmltZW50 YWwuICBTdWJzdGFudGl2ZSBjb21tZW50cyBhbmQgc3RhdGVtZW50cyBvZiBzdXBwb3J0DQpmb3Ig YWR2YW5jaW5nIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIGRpcmVjdGVkIHRvIHRoZSBtYWlsaW5n IGxpc3QuDQpFZGl0b3JpYWwgc3VnZ2VzdGlvbnMgY2FuIGJlIHNlbnQgdG8gdGhlIGF1dGhvcnMu ICBUaGlzIGxhc3QgY2FsbCB3aWxsDQplbmQgb24gRmVicnVhcnkgMTQsIDIwMTQuPEJSPjxCUj5S ZWdhcmRzLA0KQmVoY2V0PEJSPjwvUFJFPjwvRElWPjwvQkxPQ0tRVU9URT48L1REPjwvVFI+PC9U Qk9EWT48L1RBQkxFPjwvRk9OVD48L0RJVj4NCjxESVY+DQo8UD48Rk9OVCBzaXplPTIgZmFjZT3l rovkvZM+PSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA8L0ZPTlQ+ PC9QPg0KPFA+PEZPTlQgc2l6ZT0yIGZhY2U95a6L5L2TPuOAgOOAgOOAgOOAgOOAgOOAgOOAgOOA gOiHtDxCUj7npLzvvIE8L0ZPTlQ+PC9QPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yIGZhY2U95a6L5L2TPuOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOA gOOAgDxTUEFOPlNodWFpIEdhbzwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 MiBmYWNlPeWui+S9kz48Rk9OVCBzaXplPTIgZmFjZT3lrovkvZM+44CA44CA44CA44CA44CA44CA 44CA44CA44CA44CA44CA44CA44CA44CAPC9GT05UPjxBIA0KaHJlZj0ibWFpbHRvOmdhb3hsaEBn bWFpbC5jb20iPmdhb3hsaEBnbWFpbC5jb208L0E+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBz aXplPTIgZmFjZT3lrovkvZM+44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA 44CA44CA44CA44CAMjAxNC0wMi0xNDwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PC9E SVY+PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon044371450466_=====-- From nobody Thu Feb 13 22:05:50 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF141A010A for ; Thu, 13 Feb 2014 22:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3_kfDH-5wy6 for ; Thu, 13 Feb 2014 22:05:44 -0800 (PST) Received: from out48-ams.mf.surf.net (out48-ams.mf.surf.net [145.0.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id DECA21A0107 for ; Thu, 13 Feb 2014 22:05:43 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s1E65dJo012180; Fri, 14 Feb 2014 07:05:39 +0100 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 14 Feb 2014 07:05:39 +0100 Received: from EXMBX23.ad.utwente.nl ([169.254.3.41]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0328.009; Fri, 14 Feb 2014 07:05:39 +0100 From: To: Thread-Topic: [multimob] I-D Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast Thread-Index: AQHPKQh0/chgzFO8nEqcxN73z3RGx5q0PhUXgAAFatw= Date: Fri, 14 Feb 2014 06:05:38 +0000 Message-ID: References: <201309251549114085692@gmail.com> , <52FD42E4.3000502@informatik.haw-hamburg.de> In-Reply-To: <52FD42E4.3000502@informatik.haw-hamburg.de> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4204B3EXMBX23adutwent_" MIME-Version: 1.0 X-Bayes-Prob: 0.9999 (Score 4.7, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.48; country=NL; region=15; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0vLq65D3V - c06a225252b9 - 20140214 X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/cZYF0LerdmZ2AC7sdUfEpSyFvAk Cc: multimob@ietf.org Subject: Re: [multimob] I-D Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 06:05:49 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4204B3EXMBX23adutwent_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Thomas, Thanks for willing to work out my comments that can be IMHO considered also= as WGLC related comments. Regarding your proposed answers and questions, please see in line! > ________________________________ > Van: Thomas C. Schmidt [schmidt@informatik.haw-hamburg.de] > Verzonden: donderdag 13 februari 2014 23:10 > To: Karagiannis, G. (EWI) > Cc: multimob@ietf.org > Onderwerp: Re: [multimob] I-D Action:draft-ietf-multimob-fmipv6-pfmipv6-m= ulticast > Hi Georgios, > thanks again for your thorough review and sorry for our delayed work on > this. > We're currently collecting all the previous comments/reviews and combine > them in an updated version of the document ... which then is hopefully > in good rough consensus of the WG. > Please see answers inline: > On 01.10.2013 08:06, karagian@cs.utwente.nl wrote: > > During the last multimob WG meeting in Berlin I had volunteerd to > > provide comments on the last version of this draft. > > > > Here are these comments: > > > > Comment_1:The draft is useful since it is providing a solution for > > seamless and fast handover for multicast applications by extending > > existing seamless and fast handover solutions used for unicast > > applications, which are the Mobile IPv6 Fast Handovers (FMIPv6) > > specified in RFC5568 and the Fast Handovers for Proxy Mobile IPv6 > > (PFMIPv6) specified in RFC5949. > > > Thanks - we agree :-) > > Comment_2: A motivation section is missing from the draft. In my opinio= n > > it is very useful to include such section in this draft. > Okay: a similar comment was made by Behcet. We will add a subsection > (see below). Georgios: Okay, great! > >In particular, > > this draft mentions that a seamless and fast handover solutions is > > needed for multicast applications like IPTV. Other scenarios and > > applications that will make use of such a solutions are Public > > Protection and Disaster Relief (PPDR) scenarios, where mobile multicast > > communications need to be supported between members of rescue teams, > > police officers, fire brigade teams, paramedic teams, command control > > offices in order to support the protection and health of citizens. > > > > In particular three main PPDR scenarios & application types could be > > distinguished: > > > > 1)City security scenario:that can be used to support the day to day > > safety and security of citizens. > > > > 2)Disaster recovery scenario that deals with the protection of people > > and rescue teams during large scale natural or man-made disasters, like > > flooding, earth quakes and nuclear disasters. > > > > 3)Temporary Protection PPDR scenario that deals with safety and securit= y > > of citizens visiting large planned events like football matches, pop > > concerts and protest demonstrations. > > > A very good point - actually we are currently working with an airport on > such crisis prevention and disaster recovery solutions, it is of > emerging importance. > We have added the following text: > > -------------------------- snip ---------------------------------- > 1.1. Use Cases and Deployment Scenarios > > Multicast Extensions for Fast Handovers enable multicast services in > those domains that operate any of the unicast fast handover protocols > [RFC5568] or [RFC5949]. Typically, fast handover protocols are > activated within an operator network or within a dedicated service > installation. > > Multicast group communication has a variety of dominant use cases. > One traditional application area is infotainment with voluminous > multimedia streams delivered to a large number of receivers (e.g., > IPTV). Other time-critical news items like stock-exchange prices are > commonly transmitted via multicast to support fair and fast updates. > Both may be mobile and both largely benefit from fast handover > operations. Operators may enhance their operational quality or offer > premium services by enabling fast handovers. > Another traditional application area for multicast is conversational > group communication in scenarios like conferencing or gaming, but > also in dedicated collaborative environments or teams. Machine-to- > machine communication in the emerging Internet of Things is expected > to generate various additional mobile use cases (e.g., among cars). > High demands on transmission quality and rapidly moving parties may > require fast handovers. > Most of the deployment scenarios above are bound to a fixed > infrastructure with consumer equipment at the edge. Today, they > are thus likely to follow an operator-centric approach like PFMIPv6. > However, Internet technologies evolve for adoption in > infrastructureless scenarios at desaster recovery, rescue, crisis > prevention and civil safety. Mobile end-to-end communication in > groups is needed in Public Protection and Disaster Relief (PPDR) > scenarios, where mobile multicast communication needs to be supported > between members of rescue teams, police officers, fire brigade teams, > paramedic teams, command control offices in order to support the > protection and health of citizens. These use cases require fast and > reliable mobile services which cannot rely on operator > infrastructure. They are thus predestined to running multicast with > FMIPv6. Georgios: Okay, great! > -------------------------- snap ---------------------------------- > > Comment_3: List the requirements that need to be satisfied by this > > solution. You may use as example Section 1.1 of > > http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-04.txt > > > I'm not sure here: Different from the rather 'individual' solution > presented in draft-ietf-multimob-handover-optimization, the fast > handover document works out multicast extensions for the existing fast > handover protocol standards. So the requirement basically reads > > * multicast shall be transparently included in *fmipv6 handover > operations without harming anything else. > But this is very explicitly stated in the abstract and introduction, so > an additional requirements section would be either completely trivial, > or a repetition of what has been already said. > Do you think of any particular aspect we forgot to mention? Georgios: Yes, see below. Actually, I have reused some of the requirements = listed in: http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-07.txt Possible requirements to include: o The solution MUST be applicable to any kind of MN, in such a way that = any type of mobile node in a PMIPv6 domain being served with multicast traffic can benefit from the fast handover solution. o The solution MUST NOT impact existing multicast protocols. o) The multicast MIPv6 and PMIPv6 Fast Handover solutions MUST optimize = the handover performance, in terms of delay, for multicast communication to the order of the maximum delay needed = for link switching and signaling between Access Routers (ARs) or Mobile Access Gateways (MAGs). o The solution SHOULD minimize the number and extent of additional support (i.e., capabilities) required in the network, aiming at an easier deployment. o The solution MUST NOT impact deployments of legacy implementations of [RFC5213] and [RFC6224]. > > Comment_4: Provide a more detailed message flow description, similar to > > the one that is given in Section 5.1.2 in=1B$B!^=1B(B > > > > http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-04.txt > > > > This comment holds for Figures 2, 3, 4, 5 > > This again is a bit unclear to me. > The difference between the figures in > draft-ietf-multimob-handover-optimization and our Figs 2 - 5 are > (a) other entities are involved > (b) there are some comments on states in the figures from > draft-ietf-multimob-handover-optimization > In fact, the fast handover operations are much simpler than operations > in draft-ietf-multimob-handover-optimization, and directly plug into the > unicast protocol elements. > It is more 'natural' to compare with the call flows in [RFC5568] and > [RFC5949]. > If you do so, what would you propose to add? Georgios: Okay, I will not insist to add more information in the figures, b= ut IMHO, the operation of the protocol can be made very clear when each message sequence chart ste= p (i.e., each message exchange) is described in detail. > > Comment_5: There is no description on how this draft, which specifies a > > mobile multicast listener support solution, can be used in combination = a > > the mobile multicast senders, solution e.g., > > http://www.ietf.org/id/draft-ietf-multimob-pmipv6-source-05.txt. > > > > There are scenarios and applications that require the use of these two > > solutions simultaneously. > > > You are right. draft-ietf-multimob-pmipv6-source does not touch the fast > handover solution. The current document is bound to listener operation > which was a result of the charter. > The best way is probably to add the sender aspects to an appendix, as a > free gift let's say. > > Do you agree? Georgios: Yes, I agree, this will be great! Best regards, Georgios > Thanks again & best regards > > Thomas >> >>A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >> This draft is a work item of the Multicast Mobility Working Group of the= IETF. >> >> Title : Multicast Listener Extensions for MIPv6 and PMIP= v6 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-multi= cast >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv6-multicast-0= 1 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-fmipv6-pfmipv6-mul= ticast-01 >> >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>multimob mailing list >>multimob@ietf.org >>https://www.ietf.org/mailman/listinfo/multimob > > =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D = =3D =3D > > > =1B$B!!!!!!!!!!!!!!!!CW=1B(B > =1B$BNi!*=1B(B > > > Shuai Gao > Associate Professor > National Engineering Lab for Next Generation Internet Interconnection > Devices > Beijing Jiaotong University > Beijing, China, 100044 > gaoxlh@gmail.com > 2013-09-25 > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > -- Prof. Dr. Thomas C. Schmidt =1B$B!k=1B(B Hamburg University of Applied Sciences Berli= ner Tor 7 =1B$B!k=1B(B =1B$B!k=1B(B Dept. Informatik, Internet Technologies Group 20099 Hamburg= , Germany =1B$B!k=1B(B =1B$B!k=1B(B http://www.haw-hamburg.de/inet Fon: +49-40-4= 2875-8452 =1B$B!k=1B(B =1B$B!k=1B(B http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-4= 2875-8409 =1B$B!k=1B(B --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4204B3EXMBX23adutwent_ Content-Type: text/html; charset="iso-2022-jp" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Thomas,

 

Thanks for willing to work out my comments that can be IMHO considered a= lso as WGLC related comments.

 

Regarding your proposed answers and questions, please see in line!

 

>
> Van: Thomas C. Schmidt [schmidt@informatik.haw-hamburg.de]<= br> > Verzonden: donderdag 13 februari 2014 23:10
> To: Karagiannis, G. (EWI)
> Cc: multimob@ietf.org
> Onderwerp: Re: [multimob] I-D Action:draft-ietf-multimob-fmipv6= -pfmipv6-multicast

> Hi Georgios,

> thanks again for your thorough review and sorry for our delayed work o= n
> this.

> We're currently collecting all the previous comments/reviews and combi= ne
> them in an updated version of the document ... which then is hopefully=
> in good rough consensus of the WG.

> Please see answers inline:

> On 01.10.2013 08:06, karagian@cs.utwente.nl wrote:

> > During the last multimob WG meeting in Berlin I had volunteerd to=
> > provide comments on the last version of this draft.
> >
> > Here are these comments:
> >
> > Comment_1:The draft is useful since it is providing a solution fo= r
> > seamless and fast handover for multicast applications by extendin= g
> > existing seamless and fast handover solutions used for unicast > > applications, which are the Mobile IPv6 Fast Handovers (FMIPv6) > > specified in RFC5568 and the Fast Handovers for Proxy Mobile IPv6=
> > (PFMIPv6) specified in RFC5949.
> >

> Thanks - we agree :-)

> > Comment_2: A motivation section is missing from the draft. In my = opinion
> > it is very useful to include such section in this draft.

> Okay: a similar comment was made by Behcet. We will add a subsection <= br> > (see below).
 
Georgios: Okay, great!

> >In particular,
> > this draft mentions that a seamless and fast handover solutions i= s
> > needed for multicast applications like IPTV. Other scenarios and<= br> > > applications that will make use of such a solutions are Public > > Protection and Disaster Relief (PPDR) scenarios, where mobile mul= ticast
> > communications need to be supported between members of rescue tea= ms,
> > police officers, fire brigade teams, paramedic teams, command con= trol
> > offices in order to support the protection and health of citizens= .
> >
> > In particular three main PPDR scenarios & application types c= ould be
> > distinguished:
> >
> > 1)City security scenario:that can be used to support the day to d= ay
> > safety and security of citizens.
> >
> > 2)Disaster recovery scenario that deals with the protection of pe= ople
> > and rescue teams during large scale natural or man-made disasters= , like
> > flooding, earth quakes and nuclear disasters.
> >
> > 3)Temporary Protection PPDR scenario that deals with safety and s= ecurity
> > of citizens visiting large planned events like football matches, = pop
> > concerts and protest demonstrations.
> >

> A very good point - actually we are currently working with an airport = on
> such crisis prevention and disaster recovery solutions, it is of
> emerging importance.

> We have added the following text:
> 
>   -------------------------- snip --------------------------= --------
> 1.1.  Use Cases and Deployment Scenarios
> 
>     Multicast Extensions for Fast Handovers enable= multicast services in
>     those domains that operate any of the unicast = fast handover protocols
>     [RFC5568] or [RFC5949].  Typically, fast = handover protocols are
 >    activated within an operator network or within= a dedicated service
>     installation.
> 
>     Multicast group communication has a variety of= dominant use cases.
 >    One traditional application area is infotainme= nt with voluminous
>     multimedia streams delivered to a large number= of receivers (e.g.,
 >    IPTV).  Other time-critical news items li= ke stock-exchange prices are
 >    commonly transmitted via multicast to support = fair and fast updates.
 >   Both may be mobile and both largely benefit from fas= t handover
 >    operations.  Operators may enhance their = operational quality or offer
 >    premium services by enabling fast handovers.
>     Another traditional application area for multi= cast is conversational
>     group communication in scenarios like conferen= cing or gaming, but
>     also in dedicated collaborative environments o= r teams.  Machine-to-
>     machine communication in the emerging Internet= of Things is expected
>     to generate various additional mobile use case= s (e.g., among cars).
>     High demands on transmission quality and rapid= ly moving parties may
>     require fast handovers.

>     Most of the deployment scenarios above are bou= nd to a fixed
>     infrastructure with consumer equipment at the = edge.  Today, they
>     are thus likely to follow an operator-centric = approach like PFMIPv6.
>     However, Internet technologies evolve for adop= tion in
>     infrastructureless scenarios at desaster recov= ery, rescue, crisis
>     prevention and civil safety.  Mobile end-= to-end communication in
 >    groups is needed in Public Protection and Disa= ster Relief (PPDR)
>     scenarios, where mobile multicast communicatio= n needs to be supported
>    between members of rescue teams, police officers, fi= re brigade teams,
>     paramedic teams, command control offices in or= der to support the
>     protection and health of citizens.  These= use cases require fast and
>     reliable mobile services which cannot rely on = operator
>     infrastructure.  They are thus predestine= d to running multicast with
>     FMIPv6.
 
Georgios: Okay, great!


>   -------------------------- snap --------------------------= --------

> > Comment_3: List the requirements that need to be satisfied by thi= s
> > solution. You may use as example Section 1.1 of
> > http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-04.txt=
> >

> I'm not sure here: Different from the rather 'individual' solution > presented in draft-ietf-multimob-handover-optimization, the fast
> handover document works out multicast extensions for the existing fast=
> handover protocol standards. So the requirement basically reads
> 
>    * multicast shall be transparently included in *fmip= v6 handover
> operations without harming anything else.

> But this is very explicitly stated in the abstract and introduction, s= o
> an additional requirements section would be either completely trivial,=
> or a repetition of what has been already said.

> Do you think of any particular aspect we forgot to mention?
 
Georgios: Yes, see below. Actually, I have reused = some of the requirements listed in:
http://www.ietf.org/id/= draft-ietf-multimob-handover-optimization-07.txt
 
Possible requirements to include:
 
  o  The solution MUST be applicable to = any kind of MN, in such a way that any type of mobile node
      in a PMIPv6 domain being served with multica= st traffic can benefit
      from the fast handover solution.
 
   o  The solution MUST NOT impact = existing multicast protocols.

   o) The multicast MIPv6 and PMIPv6 Fast Handover solutions MUST= optimize the handover performance, in terms of delay,
      for multicast communication to the order of = the maximum delay needed for link switching and signaling between Access Ro= uters (ARs) or Mobile
      Access Gateways (MAGs).

   o  The solution SHOULD minimize the number and extent of = additional
      support (i.e., capabilities) required in the= network, aiming at an
      easier deployment.
 
   o  The solution MUST NOT impact = deployments of legacy implementations
      of [RFC5213] and [RFC6224].


> > Comment_4: Provide a more detailed message flow description, simi= lar to
> > the one that is given in Section 5.1.2 in=1B$B!^=1B(B
> >
> > http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-04.txt=
> >
> > This comment holds for Figures 2, 3, 4, 5
>

> This again is a bit unclear to me.

> The difference between the figures in
> draft-ietf-multimob-handover-optimization and our Figs 2 - 5 are

>   (a) other entities are involved
>   (b) there are some comments on states in the figures from =
> draft-ietf-multimob-handover-optimization

> In fact, the fast handover operations are much simpler than operations=
> in draft-ietf-multimob-handover-optimization, and directly plug into t= he
> unicast protocol elements.

> It is more 'natural' to compare with the call flows in [RFC5568] and <= br> > [RFC5949].

> If you do so, what would you propose to add?
 
Georgios: Okay, I will not insist to add more info= rmation in the figures, but IMHO, the operation
of the protocol can be made very clear when each m= essage sequence chart step
(i.e., each message exchange) is described in deta= il.


> > Comment_5: There is no description on how this draft, which speci= fies a
> > mobile multicast listener support solution, can be used in combin= ation a
> > the mobile multicast senders, solution e.g.,
> > http://www.ietf.org/id/draft-ietf-multimob-pmipv6-source-05.txt.
> >
> > There are scenarios and applications that require the use of thes= e two
> > solutions simultaneously.
> >

> You are right. draft-ietf-multimob-pmipv6-source does not touch the fa= st
> handover solution. The current document is bound to listener operation=
> which was a result of the charter.

> The best way is probably to add the sender aspects to an appendix, as = a
> free gift let's say.
>
> Do you agree?
 
Georgios: Yes, I agree, this will be great!
 
Best regards,
Georgios


> Thanks again & best regards
>
> Thomas


>>
>>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.
>>
>>       Title    &= nbsp;      : Multicast Listener Extensions for MIP= v6 and PMIPv6 Fast Handovers
>>       Author(s)   &nb= sp;   : Thomas C. Schmidt
>>           &= nbsp;           &nbs= p;  Matthias Waehlisch
>>           &= nbsp;           &nbs= p;  Rajeev Koodli
>>           &= nbsp;           &nbs= p;  Godred Fairhurst
>>           &= nbsp;           &nbs= p;  Dapeng Liu
>>       Filename   &nbs= p;    : draft-ietf-multimob-fmipv6-pfmipv6-multicast-01.txt<= br> >>       Pages    &= nbsp;      : 27
>>       Date    &n= bsp;       : 2013-02-25
>>
>>Abstract:
>>   Fast handover protocols for MIPv6 and PMIPv6 define mo= bility
>>   management procedures that support unicast communicati= on at reduced
>>   handover latency.  Fast handover base operations = do not affect
>>   multicast communication, and hence do not accelerate h= andover
>>   management for native multicast listeners.  Many = multicast
>>   applications like IPTV or conferencing, though, are co= mprised of
>>   delay-sensitive real-time traffic and will benefit fro= m fast handover
>>   execution.  This document specifies extension of = the Mobile IPv6 Fast
>>   Handovers (FMIPv6) and the Fast Handovers for Proxy Mo= bile IPv6
>>   (PFMIPv6) protocols to include multicast traffic manag= ement in fast
>>   handover operations.  This multicast support is p= rovided first at the
>>   control plane by a management of rapid context transfe= r between
>>   access routers, second at the data plane by an optiona= l fast traffic
>>   forwarding that may include buffering.
>>
>>
>>The IETF datatracker status page for this draft is:
>>https://datatracker.ietf.org/doc/d= raft-ietf-multimob-fmipv6-pfmipv6-multicast
>>
>>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?u= rl2=3Ddraft-ietf-multimob-fmipv6-pfmipv6-multicast-01
>>
>>
>>Internet-Drafts are also available by anonymous FTP at:
>>f= tp://ftp.ietf.org/internet-drafts/
>>
>>_______________________________________________
>>multimob mailing list
>>multimob@ietf.org
>>https://www.ietf.org/mailman/listinfo/multimob
>
> =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D = =3D =3D =3D
>
>
> =1B$B!!!!!!!!!!!!!!!!CW=1B(B
> =1B$BNi!*=1B(B
>
>
> Shuai Gao
> Associate Professor
> National Engineering Lab for Next Generation Internet Interconnection<= br> > Devices
> Beijing Jiaotong University
> Beijing, China, 100044
> gaoxlh@gmail.com
> 2013-09-25
>
> _______________________________________________
> multimob mailing list
> multimob@ietf.org
> https://www.ietf.org/mailman/listinfo/multimob
>
>
>
> _______________________________________________
> multimob mailing list
> multimob@ietf.org
> https://www.ietf.org/mailman/listinfo/multimob
>

--

Prof. Dr. Thomas C. Schmidt
=1B$B!k=1B(B Hamburg University of Applied Sciences    =             &nb= sp;  Berliner Tor 7 =1B$B!k=1B(B
=1B$B!k=1B(B Dept. Informatik, Internet Technologies Group   = ; 20099 Hamburg, Germany =1B$B!k=1B(B
=1B$B!k=1B(B h= ttp://www.haw-hamburg.de/inet       =             Fon: = 3;49-40-42875-8452 =1B$B!k=1B(B
=1B$B!k=1B(B http://www.informatik.haw-hamburg.de/~schmidt  =   Fax: +49-40-42875-8409 =1B$B!k=1B(B
--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4204B3EXMBX23adutwent_-- From nobody Fri Feb 14 03:12:29 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6901A0205 for ; Fri, 14 Feb 2014 03:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_84=0.6, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5LHcSjDWMds for ; Fri, 14 Feb 2014 03:12:22 -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 4C0C01A01CE for ; Fri, 14 Feb 2014 03:12:20 -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; 14 Feb 2014 12:12:13 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 82E9810679D7; Fri, 14 Feb 2014 12:12:13 +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 13251-10; Fri, 14 Feb 2014 12:12:12 +0100 (CET) Received: from [192.168.178.49] (g231224147.adsl.alicedsl.de [92.231.224.147]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 7DEC710679CF; Fri, 14 Feb 2014 12:12:12 +0100 (CET) Message-ID: <52FDFA0C.5070302@informatik.haw-hamburg.de> Date: Fri, 14 Feb 2014 12:12:12 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: karagian@cs.utwente.nl References: <201309251549114085692@gmail.com> , <52FD42E4.3000502@informatik.haw-hamburg.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/GWIZgvZ43OsbE4xgVULhz1wPYd8 Cc: multimob@ietf.org Subject: Re: [multimob] I-D Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 11:12:26 -0000 Hi Georgios, thanks again for your comments: we are now working on polishing the draft for the new submission (deadline today) ... and see the details then. Best Thomas On 14.02.2014 07:05, karagian@cs.utwente.nl wrote: > Hi Thomas, > > Thanks for willing to work out my comments that can be IMHO considered > also as WGLC related comments. > > Regarding your proposed answers and questions, please see in line! > >> > ------------------------------------------------------------------------ > *> Van:* Thomas C. Schmidt [schmidt@informatik.haw-hamburg.de] > *> Verzonden:* donderdag 13 februari 2014 23:10 > *> To:* Karagiannis, G. (EWI) > *> Cc:* multimob@ietf.org > *> Onderwerp:* Re: [multimob] I-D > Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast > >> Hi Georgios, > >> thanks again for your thorough review and sorry for our delayed work on >> this. > >> We're currently collecting all the previous comments/reviews and combine >> them in an updated version of the document ... which then is hopefully >> in good rough consensus of the WG. > >> Please see answers inline: > >> On 01.10.2013 08:06, karagian@cs.utwente.nl wrote: > >> > During the last multimob WG meeting in Berlin I had volunteerd to >> > provide comments on the last version of this draft. >> > >> > Here are these comments: >> > >> > Comment_1:The draft is useful since it is providing a solution for >> > seamless and fast handover for multicast applications by extending >> > existing seamless and fast handover solutions used for unicast >> > applications, which are the Mobile IPv6 Fast Handovers (FMIPv6) >> > specified in RFC5568 and the Fast Handovers for Proxy Mobile IPv6 >> > (PFMIPv6) specified in RFC5949. >> > > >> Thanks - we agree :-) > >> > Comment_2: A motivation section is missing from the draft. In my opinion >> > it is very useful to include such section in this draft. > >> Okay: a similar comment was made by Behcet. We will add a subsection >> (see below). > Georgios: Okay, great! > >> >In particular, >> > this draft mentions that a seamless and fast handover solutions is >> > needed for multicast applications like IPTV. Other scenarios and >> > applications that will make use of such a solutions are Public >> > Protection and Disaster Relief (PPDR) scenarios, where mobile multicast >> > communications need to be supported between members of rescue teams, >> > police officers, fire brigade teams, paramedic teams, command control >> > offices in order to support the protection and health of citizens. >> > >> > In particular three main PPDR scenarios & application types could be >> > distinguished: >> > >> > 1)City security scenario:that can be used to support the day to day >> > safety and security of citizens. >> > >> > 2)Disaster recovery scenario that deals with the protection of people >> > and rescue teams during large scale natural or man-made disasters, like >> > flooding, earth quakes and nuclear disasters. >> > >> > 3)Temporary Protection PPDR scenario that deals with safety and security >> > of citizens visiting large planned events like football matches, pop >> > concerts and protest demonstrations. >> > > >> A very good point - actually we are currently working with an airport on >> such crisis prevention and disaster recovery solutions, it is of >> emerging importance. > >> We have added the following text: >> >> -------------------------- snip ---------------------------------- >> 1.1. Use Cases and Deployment Scenarios >> >> Multicast Extensions for Fast Handovers enable multicast services in >> those domains that operate any of the unicast fast handover protocols >> [RFC5568] or [RFC5949]. Typically, fast handover protocols are > > activated within an operator network or within a dedicated service >> installation. >> >> Multicast group communication has a variety of dominant use cases. > > One traditional application area is infotainment with voluminous >> multimedia streams delivered to a large number of receivers (e.g., > > IPTV). Other time-critical news items like stock-exchange prices are > > commonly transmitted via multicast to support fair and fast updates. > > Both may be mobile and both largely benefit from fast handover > > operations. Operators may enhance their operational quality or offer > > premium services by enabling fast handovers. > >> Another traditional application area for multicast is conversational >> group communication in scenarios like conferencing or gaming, but >> also in dedicated collaborative environments or teams. Machine-to- >> machine communication in the emerging Internet of Things is expected >> to generate various additional mobile use cases (e.g., among cars). >> High demands on transmission quality and rapidly moving parties may >> require fast handovers. > >> Most of the deployment scenarios above are bound to a fixed >> infrastructure with consumer equipment at the edge. Today, they >> are thus likely to follow an operator-centric approach like PFMIPv6. >> However, Internet technologies evolve for adoption in >> infrastructureless scenarios at desaster recovery, rescue, crisis >> prevention and civil safety. Mobile end-to-end communication in > > groups is needed in Public Protection and Disaster Relief (PPDR) >> scenarios, where mobile multicast communication needs to be supported >> between members of rescue teams, police officers, fire brigade teams, >> paramedic teams, command control offices in order to support the >> protection and health of citizens. These use cases require fast and >> reliable mobile services which cannot rely on operator >> infrastructure. They are thus predestined to running multicast with >> FMIPv6. > Georgios: Okay, great! > > >> -------------------------- snap ---------------------------------- > >> > Comment_3: List the requirements that need to be satisfied by this >> > solution. You may use as example Section 1.1 of >> >http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-04.txt >> > > >> I'm not sure here: Different from the rather 'individual' solution >> presented in draft-ietf-multimob-handover-optimization, the fast >> handover document works out multicast extensions for the existing fast >> handover protocol standards. So the requirement basically reads >> >> * multicast shall be transparently included in *fmipv6 handover >> operations without harming anything else. > >> But this is very explicitly stated in the abstract and introduction, so >> an additional requirements section would be either completely trivial, >> or a repetition of what has been already said. > >> Do you think of any particular aspect we forgot to mention? > Georgios: Yes, see below. Actually, I have reused some of the > requirements listed in: > http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-07.txt > Possible requirements to include: > o The solution MUST be applicable to any kind of MN, in such a way > that any type of mobile node > in a PMIPv6 domain being served with multicast traffic can benefit > from the fast handover solution. > o The solution MUST NOT impact existing multicast protocols. > > o) The multicast MIPv6 and PMIPv6 Fast Handover solutions MUST > optimize the handover performance, in terms of delay, > for multicast communication to the order of the maximum delay > needed for link switching and signaling between Access Routers (ARs) or > Mobile > Access Gateways (MAGs). > > o The solution SHOULD minimize the number and extent of additional > support (i.e., capabilities) required in the network, aiming at an > easier deployment. > o The solution MUST NOT impact deployments of legacy implementations > of [RFC5213] and [RFC6224]. > > >> > Comment_4: Provide a more detailed message flow description, similar to >> > the one that is given in Section 5.1.2 in± >> > >> >http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-04.txt >> > >> > This comment holds for Figures 2, 3, 4, 5 >> > >> This again is a bit unclear to me. > >> The difference between the figures in >> draft-ietf-multimob-handover-optimization and our Figs 2 - 5 are > >> (a) other entities are involved >> (b) there are some comments on states in the figures from >> draft-ietf-multimob-handover-optimization > >> In fact, the fast handover operations are much simpler than operations >> in draft-ietf-multimob-handover-optimization, and directly plug into the >> unicast protocol elements. > >> It is more 'natural' to compare with the call flows in [RFC5568] and >> [RFC5949]. > >> If you do so, what would you propose to add? > Georgios: Okay, I will not insist to add more information in the > figures, but IMHO, the operation > of the protocol can be made very clear when each message sequence chart > step > (i.e., each message exchange) is described in detail. > > >> > Comment_5: There is no description on how this draft, which specifies a >> > mobile multicast listener support solution, can be used in combination a >> > the mobile multicast senders, solution e.g., >> >http://www.ietf.org/id/draft-ietf-multimob-pmipv6-source-05.txt. >> > >> > There are scenarios and applications that require the use of these two >> > solutions simultaneously. >> > > >> You are right. draft-ietf-multimob-pmipv6-source does not touch the fast >> handover solution. The current document is bound to listener operation >> which was a result of the charter. > >> The best way is probably to add the sender aspects to an appendix, as a >> free gift let's say. >> >> Do you agree? > Georgios: Yes, I agree, this will be great! > Best regards, > Georgios > > >> Thanks again & best regards >> >> Thomas > > >>> >>>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. >>> >>> 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-multicast >>> >>>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=draft-ietf-multimob-fmipv6-pfmipv6-multicast-01 >>> >>> >>>Internet-Drafts are also available by anonymous FTP at: >>>ftp://ftp.ietf.org/internet-drafts/ >>> >>>_______________________________________________ >>>multimob mailing list >>>multimob@ietf.org >>>https://www.ietf.org/mailman/listinfo/multimob >> >> = = = = = = = = = = = = = = = = = = = = >> >> >> 　　　　　　　　致 >> 礼！ >> >> >> Shuai Gao >> Associate Professor >> National Engineering Lab for Next Generation Internet Interconnection >> Devices >> Beijing Jiaotong University >> Beijing, China, 100044 >> gaoxlh@gmail.com >> 2013-09-25 >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >>https://www.ietf.org/mailman/listinfo/multimob >> >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >>https://www.ietf.org/mailman/listinfo/multimob >> > > -- > > Prof. Dr. Thomas C. Schmidt > ° Hamburg University of Applied Sciences Berliner Tor 7 ° > ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° > ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° > ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° > > > _______________________________________________ > 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 nobody Fri Feb 14 03:18:39 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3BD1A01BB for ; Fri, 14 Feb 2014 03:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03DX6c9_NFpk for ; Fri, 14 Feb 2014 03:18:36 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id D32F41A00F1 for ; Fri, 14 Feb 2014 03:18:35 -0800 (PST) Envelope-to: multimob@ietf.org Received: from g231224147.adsl.alicedsl.de ([92.231.224.147] helo=[192.168.178.49]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1WEGmv-000HWq-Nw; Fri, 14 Feb 2014 12:18:33 +0100 Message-ID: <52FDFB89.60104@fhtw-berlin.de> Date: Fri, 14 Feb 2014 12:18:33 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Shuai Gao , "multimob@ietf.org" References: <201402140918206810562@gmail.com> In-Reply-To: <201402140918206810562@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/Uxve92XTZ-_6VZVDKfDOq8IBGRg Subject: Re: [multimob] draft-ietf-multimob-fmipv6-pfmipv6-multicast-02 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 11:18:39 -0000 Hi Shuai, On 14.02.2014 02:18, Shuai Gao wrote: > This draft has been discussed for a long time and it's in a good shape now. > I support a sucessful WGLC. > Also, I'm look forward to next version which will include all the > feedbacks from reviewers as the author promised. Thanks - we'll submit the updated version today. Best regards, Thomas 　　 > ======== 2014-01-18 02:15:20 您在来信中写道： ======== > > Folks, > > This message starts a four week (as usual in Multimob) > Multimob Working Group last call > on advancing: > > > 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-02.txt > Pages : 27 > Date : 2013-12-13 > > as Experimental. Substantive comments and statements of support > for advancing this document should be directed to the mailing list. > Editorial suggestions can be sent to the authors. This last call will > end on February 14, 2014. > > Regards, > Behcet > > = = = = = = = = = = = = = = = = = = = = = = > > 　　　　　　　　致 > 礼！ > > 　　　　　　　　　　　　　　Shuai Gao > 　　　　　　　　　　　　　　gaoxlh@gmail.com > 　　　　　　　　　　　　　　　　　2014-02-14 > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From nobody Fri Feb 14 15:22:15 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28431A0414; Fri, 14 Feb 2014 15:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-kb_SDpvXQz; Fri, 14 Feb 2014 15:22:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0C71A0482; Fri, 14 Feb 2014 15:22:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214232211.17812.29110.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:22:11 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/owwpvRZsHuG45whaeTGUtRwzAhI Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-fmipv6-pfmipv6-multicast-03.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:22:13 -0000 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. Title : Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers Authors : Thomas C. Schmidt Matthias Waehlisch Rajeev Koodli Godred Fairhurst Dapeng Liu Filename : draft-ietf-multimob-fmipv6-pfmipv6-multicast-03.txt Pages : 28 Date : 2014-02-14 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-multicast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv6-multicast-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-fmipv6-pfmipv6-multicast-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 15:48:06 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F401A04C0 for ; Fri, 14 Feb 2014 15:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Qv42jvKYfxU for ; Fri, 14 Feb 2014 15:47:59 -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 A129D1A0140 for ; Fri, 14 Feb 2014 15:47:59 -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; 15 Feb 2014 00:47:57 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 5FE0010679D7 for ; Sat, 15 Feb 2014 00:47:57 +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 09769-09 for ; Sat, 15 Feb 2014 00:47:56 +0100 (CET) Received: from [192.168.178.49] (g231224147.adsl.alicedsl.de [92.231.224.147]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id ABF2B10679CF for ; Sat, 15 Feb 2014 00:47:56 +0100 (CET) Message-ID: <52FEAB2B.8060607@informatik.haw-hamburg.de> Date: Sat, 15 Feb 2014 00:47:55 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: multimob@ietf.org References: <20140214232211.17812.29110.idtracker@ietfa.amsl.com> In-Reply-To: <20140214232211.17812.29110.idtracker@ietfa.amsl.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 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/tIvt03u1aDHDrsRyFVaNWDdm7P4 Subject: Re: [multimob] I-D Action: draft-ietf-multimob-fmipv6-pfmipv6-multicast-03.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:48:03 -0000 Hi all, this new version of the Fast Handover draft should include all the changes and polishing requested from the working group ... as of the content this should be complete and ready to move forward. There are two TODOs (unfinished due to the cutoff deadline): * IANA registration writeup * Appendix on Fast handover sender mobility as requested by Georgios We will add and update in the IETF week. Thomas On 15.02.2014 00:22, internet-drafts@ietf.org wrote: > > 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. > > Title : Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers > Authors : Thomas C. Schmidt > Matthias Waehlisch > Rajeev Koodli > Godred Fairhurst > Dapeng Liu > Filename : draft-ietf-multimob-fmipv6-pfmipv6-multicast-03.txt > Pages : 28 > Date : 2014-02-14 > > 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-multicast/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv6-multicast-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-fmipv6-pfmipv6-multicast-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 nobody Fri Feb 14 15:57:02 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5391A0479 for ; Fri, 14 Feb 2014 15:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_84=0.6, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm7WyKTbmK3q for ; Fri, 14 Feb 2014 15:56:55 -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 3BF801A00B0 for ; Fri, 14 Feb 2014 15:56:55 -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; 15 Feb 2014 00:56:52 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id D9A5310679D7; Sat, 15 Feb 2014 00:56:52 +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 10250-08; Sat, 15 Feb 2014 00:56:51 +0100 (CET) Received: from [192.168.178.49] (g231224147.adsl.alicedsl.de [92.231.224.147]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 2CE1D10679CF; Sat, 15 Feb 2014 00:56:51 +0100 (CET) Message-ID: <52FEAD42.5000006@informatik.haw-hamburg.de> Date: Sat, 15 Feb 2014 00:56:50 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: karagian@cs.utwente.nl References: <201309251549114085692@gmail.com> , <52FD42E4.3000502@informatik.haw-hamburg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/gY0iMKfxBWL91l6uZtXz5kc5PF4 Cc: multimob@ietf.org Subject: Re: [multimob] I-D Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:56:59 -0000 Hi Georgios, thanks and et voila - the update is out. On 14.02.2014 07:05, karagian@cs.utwente.nl wrote: Please see answers inline: > >> On 01.10.2013 08:06, karagian@cs.utwente.nl wrote: > >> > During the last multimob WG meeting in Berlin I had volunteerd to >> > provide comments on the last version of this draft. >> > >> > Here are these comments: >> > >> > Comment_1:The draft is useful since it is providing a solution for >> > seamless and fast handover for multicast applications by extending >> > existing seamless and fast handover solutions used for unicast >> > applications, which are the Mobile IPv6 Fast Handovers (FMIPv6) >> > specified in RFC5568 and the Fast Handovers for Proxy Mobile IPv6 >> > (PFMIPv6) specified in RFC5949. >> > > >> Thanks - we agree :-) > >> > Comment_2: A motivation section is missing from the draft. In my opinion >> > it is very useful to include such section in this draft. > >> Okay: a similar comment was made by Behcet. We will add a subsection >> (see below). > Georgios: Okay, great! > >> >In particular, >> > this draft mentions that a seamless and fast handover solutions is >> > needed for multicast applications like IPTV. Other scenarios and >> > applications that will make use of such a solutions are Public >> > Protection and Disaster Relief (PPDR) scenarios, where mobile multicast >> > communications need to be supported between members of rescue teams, >> > police officers, fire brigade teams, paramedic teams, command control >> > offices in order to support the protection and health of citizens. >> > >> > In particular three main PPDR scenarios & application types could be >> > distinguished: >> > >> > 1)City security scenario:that can be used to support the day to day >> > safety and security of citizens. >> > >> > 2)Disaster recovery scenario that deals with the protection of people >> > and rescue teams during large scale natural or man-made disasters, like >> > flooding, earth quakes and nuclear disasters. >> > >> > 3)Temporary Protection PPDR scenario that deals with safety and security >> > of citizens visiting large planned events like football matches, pop >> > concerts and protest demonstrations. >> > > >> A very good point - actually we are currently working with an airport on >> such crisis prevention and disaster recovery solutions, it is of >> emerging importance. > >> We have added the following text: >> >> -------------------------- snip ---------------------------------- >> 1.1. Use Cases and Deployment Scenarios >> >> Multicast Extensions for Fast Handovers enable multicast services in >> those domains that operate any of the unicast fast handover protocols >> [RFC5568] or [RFC5949]. Typically, fast handover protocols are > > activated within an operator network or within a dedicated service >> installation. >> >> Multicast group communication has a variety of dominant use cases. > > One traditional application area is infotainment with voluminous >> multimedia streams delivered to a large number of receivers (e.g., > > IPTV). Other time-critical news items like stock-exchange prices are > > commonly transmitted via multicast to support fair and fast updates. > > Both may be mobile and both largely benefit from fast handover > > operations. Operators may enhance their operational quality or offer > > premium services by enabling fast handovers. > >> Another traditional application area for multicast is conversational >> group communication in scenarios like conferencing or gaming, but >> also in dedicated collaborative environments or teams. Machine-to- >> machine communication in the emerging Internet of Things is expected >> to generate various additional mobile use cases (e.g., among cars). >> High demands on transmission quality and rapidly moving parties may >> require fast handovers. > >> Most of the deployment scenarios above are bound to a fixed >> infrastructure with consumer equipment at the edge. Today, they >> are thus likely to follow an operator-centric approach like PFMIPv6. >> However, Internet technologies evolve for adoption in >> infrastructureless scenarios at desaster recovery, rescue, crisis >> prevention and civil safety. Mobile end-to-end communication in > > groups is needed in Public Protection and Disaster Relief (PPDR) >> scenarios, where mobile multicast communication needs to be supported >> between members of rescue teams, police officers, fire brigade teams, >> paramedic teams, command control offices in order to support the >> protection and health of citizens. These use cases require fast and >> reliable mobile services which cannot rely on operator >> infrastructure. They are thus predestined to running multicast with >> FMIPv6. > Georgios: Okay, great! > > >> -------------------------- snap ---------------------------------- > >> > Comment_3: List the requirements that need to be satisfied by this >> > solution. You may use as example Section 1.1 of >> >http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-04.txt >> > > >> I'm not sure here: Different from the rather 'individual' solution >> presented in draft-ietf-multimob-handover-optimization, the fast >> handover document works out multicast extensions for the existing fast >> handover protocol standards. So the requirement basically reads >> >> * multicast shall be transparently included in *fmipv6 handover >> operations without harming anything else. > >> But this is very explicitly stated in the abstract and introduction, so >> an additional requirements section would be either completely trivial, >> or a repetition of what has been already said. > >> Do you think of any particular aspect we forgot to mention? > Georgios: Yes, see below. Actually, I have reused some of the > requirements listed in: > http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-07.txt > Possible requirements to include: > o The solution MUST be applicable to any kind of MN, in such a way > that any type of mobile node > in a PMIPv6 domain being served with multicast traffic can benefit > from the fast handover solution. > o The solution MUST NOT impact existing multicast protocols. > > o) The multicast MIPv6 and PMIPv6 Fast Handover solutions MUST > optimize the handover performance, in terms of delay, > for multicast communication to the order of the maximum delay > needed for link switching and signaling between Access Routers (ARs) or > Mobile > Access Gateways (MAGs). > > o The solution SHOULD minimize the number and extent of additional > support (i.e., capabilities) required in the network, aiming at an > easier deployment. > o The solution MUST NOT impact deployments of legacy implementations > of [RFC5213] and [RFC6224]. > We've added a paragraph of requirements to the introduction - this should cover all there is needed to clarify the rationale behind the design - Okay? > >> > Comment_4: Provide a more detailed message flow description, similar to >> > the one that is given in Section 5.1.2 in$B!^(B >> > >> >http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-04.txt >> > >> > This comment holds for Figures 2, 3, 4, 5 >> > >> This again is a bit unclear to me. > >> The difference between the figures in >> draft-ietf-multimob-handover-optimization and our Figs 2 - 5 are > >> (a) other entities are involved >> (b) there are some comments on states in the figures from >> draft-ietf-multimob-handover-optimization > >> In fact, the fast handover operations are much simpler than operations >> in draft-ietf-multimob-handover-optimization, and directly plug into the >> unicast protocol elements. > >> It is more 'natural' to compare with the call flows in [RFC5568] and >> [RFC5949]. > >> If you do so, what would you propose to add? > Georgios: Okay, I will not insist to add more information in the > figures, but IMHO, the operation > of the protocol can be made very clear when each message sequence chart > step > (i.e., each message exchange) is described in detail. > > >> > Comment_5: There is no description on how this draft, which specifies a >> > mobile multicast listener support solution, can be used in combination a >> > the mobile multicast senders, solution e.g., >> >http://www.ietf.org/id/draft-ietf-multimob-pmipv6-source-05.txt. >> > >> > There are scenarios and applications that require the use of these two >> > solutions simultaneously. >> > > >> You are right. draft-ietf-multimob-pmipv6-source does not touch the fast >> handover solution. The current document is bound to listener operation >> which was a result of the charter. > >> The best way is probably to add the sender aspects to an appendix, as a >> free gift let's say. >> >> Do you agree? > Georgios: Yes, I agree, this will be great! Unfortunately, time did not permit to add this appendix - we will contribute prior to IETF London and then submit a version once the submission tool is open again. As this is supplementary material, further discussion and progressing of the draft should not be affected. see you in London! Thomas >>> >>>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. >>> >>> 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-multicast >>> >>>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=draft-ietf-multimob-fmipv6-pfmipv6-multicast-01 >>> >>> >>>Internet-Drafts are also available by anonymous FTP at: >>>ftp://ftp.ietf.org/internet-drafts/ >>> >>>_______________________________________________ >>>multimob mailing list >>>multimob@ietf.org >>>https://www.ietf.org/mailman/listinfo/multimob >> >> = = = = = = = = = = = = = = = = = = = = >> >> >> $B!!!!!!!!!!!!!!!!CW(B >> $BNi!*(B >> >> >> Shuai Gao >> Associate Professor >> National Engineering Lab for Next Generation Internet Interconnection >> Devices >> Beijing Jiaotong University >> Beijing, China, 100044 >> gaoxlh@gmail.com >> 2013-09-25 >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >>https://www.ietf.org/mailman/listinfo/multimob >> >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >>https://www.ietf.org/mailman/listinfo/multimob >> > > -- > > Prof. Dr. Thomas C. Schmidt > $B!k(B Hamburg University of Applied Sciences Berliner Tor 7 $B!k(B > $B!k(B Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany $B!k(B > $B!k(B http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 $B!k(B > $B!k(B http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 $B!k(B -- Prof. Dr. Thomas C. Schmidt $B!k(B Hamburg University of Applied Sciences Berliner Tor 7 $B!k(B $B!k(B Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany $B!k(B $B!k(B http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 $B!k(B $B!k(B http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 $B!k(B From nobody Fri Feb 14 16:03:43 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8301A040C for ; Fri, 14 Feb 2014 16:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-Y5wXqYaTts for ; Fri, 14 Feb 2014 16:03:38 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 774F71A00A5 for ; Fri, 14 Feb 2014 16:03:38 -0800 (PST) Envelope-to: multimob@ietf.org Received: from g231224147.adsl.alicedsl.de ([92.231.224.147] helo=[192.168.178.49]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1WESjH-000KxM-Pp; Sat, 15 Feb 2014 01:03:36 +0100 Message-ID: <52FEAED6.6050307@fhtw-berlin.de> Date: Sat, 15 Feb 2014 01:03:34 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: sarikaya@ieee.org, "multimob@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/8_VXMw73XyG3Q8RPy6l8Y8OBDVI Subject: Re: [multimob] Review of draft-ietf-multimob-fmipv6-pfmipv6-multicast-02 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 00:03:42 -0000 Hi Behcet, thanks for your comments: we have updated and submitted the draft. Please see answers inline: On 03.02.2014 00:39, Behcet Sarikaya wrote: > Sec. 2 > In addition, the following terms are > introduced: > where are the terms? > Oopsi, no further terms. We have cleared this. > Sec. 3.1 > subnet link > use on of them > OK - it's subnet now. > when the group is > natively received. > What does this mean, please explain > This means native multicast packet forwarding (instead of tunneling). > As group membership information are > s/are/is > Thanks - corrected. > Sec. 5.3 > The size of this option in 8 octets > s/in/is > Thanks - corrected. > Last but not least, I think the draft finishes without a discussion of > why this solution is needed. We need some text on this. I don't know if > the reference "FMIPv6-Analysis" could be useful. > This corresponds to a comment made be Georgios. We have added the following subsection to the introduction: 1.1. Use Cases and Deployment Scenarios Multicast Extensions for Fast Handovers enable multicast services in those domains that operate any of the unicast fast handover protocols [RFC5568] or [RFC5949]. Typically, fast handover protocols are activated within an operator network or within a dedicated service installation. Multicast group communication has a variety of dominant use cases. One traditional application area is infotainment with voluminous multimedia streams delivered to a large number of receivers (e.g., IPTV). Other time-critical news items like stock-exchange prices are commonly transmitted via multicast to support fair and fast updates. Both may be mobile and both largely benefit from fast handover operations. Operators may enhance their operational quality or offer premium services by enabling fast handovers. Another traditional application area for multicast is conversational group communication in scenarios like conferencing or gaming, but also in dedicated collaborative environments or teams. Machine-to- machine communication in the emerging Internet of Things is expected Schmidt, et al. Expires August 19, 2014 [Page 4] Internet-Draft Multicast for FMIPv6/PFMIPv6 February 2014 to generate various additional mobile use cases (e.g., among cars). High demands on transmission quality and rapidly moving parties may require fast handovers. Most of the deployment scenarios above are bound to a fixed infrastructure with consumer equipment at the edge. Today, they are thus likely to follow an operator-centric approach like PFMIPv6. However, Internet technologies evolve for adoption in infrastructureless scenarios at disaster recovery, rescue, crisis prevention and civil safety. Mobile end-to-end communication in groups is needed in Public Protection and Disaster Relief (PPDR) scenarios, where mobile multicast communication needs to be supported between members of rescue teams, police officers, fire brigade teams, paramedic teams, command control offices in order to support the protection and health of citizens. These use cases require fast and reliable mobile services which cannot rely on operator infrastructure. They are thus predestined to running multicast with FMIPv6. Have a safe trip to Monty Python land! Thomas From nobody Mon Feb 17 02:41:23 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE2C1A047F; Mon, 17 Feb 2014 02:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuszvDscQ6bd; Mon, 17 Feb 2014 02:41:16 -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 8AD501A01CA; Mon, 17 Feb 2014 02:41:15 -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; 17 Feb 2014 11:41:12 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 423B210679D7; Mon, 17 Feb 2014 11:41:12 +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 13124-09; Mon, 17 Feb 2014 11:41:11 +0100 (CET) Received: from [172.27.31.57] (unknown [195.37.142.72]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 7014310679CF; Mon, 17 Feb 2014 11:41:11 +0100 (CET) Message-ID: <5301E745.6020109@informatik.haw-hamburg.de> Date: Mon, 17 Feb 2014 11:41:09 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Black, David" , "shgao@bjtu.edu.cn" , "hkzhang@bjtu.edu.cn" , "mw@link-lab.net" , "General Area Review Team (gen-art@ietf.org)" References: <8D3D17ACE214DC429325B2B98F3AE712027281E4CC@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712027281E4CC@MX15A.corp.emc.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 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/EEMXNm7J_uSvhyUHvEmF2Xkb4yM Cc: "multimob@ietf.org" , "ietf@ietf.org" Subject: Re: [multimob] Gen-ART review of draft-ietf-multimob-pmipv6-source-07 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 10:41:20 -0000 Hi David, many thanks for the review and the feedback. Please see responses inline. On 17.02.2014 04:22, Black, David wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-multimob-pmipv6-source-07 > Reviewer: David L. Black > Review Date: Feb 16, 2014 > IETF LC End Date: Feb 24, 2014 > > Summary: This draft is basically ready for publication, but has nits that > should be fixed before publication. > > This draft describes multicast support for proxy mobile IPv6. It assumes > significant understanding of multicast and specifically the PIM-SM protocol. > > Nits/editorial comments: > > -- Introduction, 3rd paragraph > > Remove the word business from the following text, please: > > Such approaches (partially) follow > the business model of providing multicast data services in parallel > to PMIPv6 unicast routing [I-D.ietf-multimob-handover-optimization]. > O.K., done. > -- 4.3.1 > > The fact that PIM-SM has three phases could be made somewhat clearer here. > Suggestion: > > OLD > The granularity of mobility-related routing > locators required in PIM depends on the complexity (phases) of its > deployment. > > The following information is needed for all three phases of PIM as > defined in [RFC4601]. > NEW > The granularity of mobility-related routing > locators required in PIM depends on the complexity (specific phase) > of its deployment. > > For all three phases of PIM deployment (see [RFC4601]), the following > information is needed. > O.K., done > Also, is "deployment" the right word to describe the phases? It implies > that not all of the phases need to be present in an implementation or > used, even if applicable. > You're right. We have reworded For all three phases in the operation of PIM (see [RFC4601]), the following information is needed. > -- 4.3.2 - 4.3.4 > > I would also suggest including the names of the phases from RFC 4601 in > these section titles, e.g.: > > 4.3.2. Operations of PIM in Phase One (RP Tree) > Thanks, done. > -- idnits > > idnits 2.13.01 found an unused reference and a couple of drafts that > have been updated: > > == Unused Reference: 'RFC2236' is defined on line 1047, but no explicit > reference was found in the text > Oh, a lapse - RFC2236 is listed mainly for historic/compatibility reasons. It is referenced now. > == Outdated reference: A later version (-02) exists of > draft-ietf-multimob-fmipv6-pfmipv6-multicast-01 > > == Outdated reference: A later version (-07) exists of > draft-ietf-multimob-handover-optimization-06 > This is due to an update problem of the online tool (ID database), which seems fixed now. Thanks again! We will update the document as soon as the submission re-opens. Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt Hamburg University of Applied Sciences Berliner Tor 7 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 From nobody Mon Feb 24 00:09:21 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24E21A00B0; Mon, 24 Feb 2014 00:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCGg_oGpywho; Mon, 24 Feb 2014 00:09:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F581A0370; Mon, 24 Feb 2014 00:09:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, multimob-chairs@tools.ietf.org, draft-ietf-multimob-pmipv6-source@tools.ietf.org, multimob@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140224080915.19825.460.idtracker@ietfa.amsl.com> Date: Mon, 24 Feb 2014 00:09:15 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/-LEfxTtMbUGmajd7bu6GpyIKxFI Cc: iesg-secretary@ietf.org Subject: [multimob] Last Call Expired: X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 08:09:18 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup.