From karagian@cs.utwente.nl Sun Nov 4 12:20:39 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B296421F8780 for ; Sun, 4 Nov 2012 12:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.429 X-Spam-Level: X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT+SJ-FJ552Q for ; Sun, 4 Nov 2012 12:20:38 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id E19F021F883C for ; Sun, 4 Nov 2012 12:20:37 -0800 (PST) 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.318.4; Sun, 4 Nov 2012 21:20:38 +0100 Received: from EXMBX01.ad.utwente.nl ([169.254.1.130]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0318.004; Sun, 4 Nov 2012 21:20:36 +0100 From: To: , Thread-Topic: [multimob] RV: I-D Action: draft-ietf-multimob-fast-handover-03.txt Thread-Index: AQHNsVIB0aXDTSUmT0GTMlGxf4zK65faMMcT Date: Sun, 4 Nov 2012 20:20:35 +0000 Message-ID: References: <20121022180703.7551.40147.idtracker@ietfa.amsl.com>, <823234EF5C7C334998D973D822FF801B1B8570D4@EX10-MB1-MAD.hi.inet> In-Reply-To: <823234EF5C7C334998D973D822FF801B1B8570D4@EX10-MB1-MAD.hi.inet> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.67.215] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multimob] RV: I-D Action: draft-ietf-multimob-fast-handover-03.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:20:39 -0000 Hi all, I think that the draft is in a good shape, but I have some comments. It is = not clear to me which requirements need to be fulfilled by the provided sol= ution in order to support the so called PMIPv6 multicast handover optimizat= ion.=20 It might be useful to first describe the PMIPv6 multicast handover optimiza= tion requirements that need to be fulfilled before describing the solution= . The draft could then also describe how the provided solution supports a g= iven requirement. Best regards, Georgios Karagiannis ________________________________________ Van: multimob-bounces@ietf.org [multimob-bounces@ietf.org] namens LUIS MIGU= EL CONTRERAS MURILLO [lmcm@tid.es] Verzonden: dinsdag 23 oktober 2012 21:09 To: multimob@ietf.org Onderwerp: [multimob] RV: I-D Action: draft-ietf-multimob-fast-handover-03.= txt Hi all, Yesterday we submitted a new version of the WG document "draft-ietf-multimo= b-fast-handover", addressing received comments and pending sections. Additional comments are welcome. Best regards, Luis -----Mensaje original----- De: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] En nombre = de internet-drafts@ietf.org Enviado el: lunes, 22 de octubre de 2012 20:07 Para: i-d-announce@ietf.org CC: multimob@ietf.org Asunto: [multimob] I-D Action: draft-ietf-multimob-fast-handover-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multicast Mobility Working Group of the I= ETF. Title : PMIPv6 multicast handover optimization by the Sub= scription Information Acquisition through the LMA (SIAL) Author(s) : Luis M. Contreras Carlos J. Bernardos Ignacio Soto Filename : draft-ietf-multimob-fast-handover-03.txt Pages : 42 Date : 2012-10-22 Abstract: This document specifies a multicast handover optimization mechanism for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic to mobile nodes after handovers. The mechanism is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current Proxy Mobile IPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions being developed to avoid the tunnel convergence problem. Furthermore, they are also independent of the role played by the mobile access gateway within the multicast network (either acting as multicast listener discovery proxy or multicast router). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-fast-handover There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-fast-handover-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-fast-handover-03 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 ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob= From sarikaya2012@gmail.com Mon Nov 5 10:53:54 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5D621F8581 for ; Mon, 5 Nov 2012 10:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P27crEiC6Cya for ; Mon, 5 Nov 2012 10:53:54 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E96321F842A for ; Mon, 5 Nov 2012 10:53:53 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so5107173iak.31 for ; Mon, 05 Nov 2012 10:53:53 -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:content-type; bh=GxjjkFdXpRfBSZBkK0jxPnA1AsOORv51M5LTg5/L3dQ=; b=FfS07f27q8G85Wzryu9BJKZAupT6lJRINH8yfyk0SJQI+uICXw9dlUnjddytY9FBN2 PyBI2JchEIKMpkwQKxJMDGuTy1CnYmgbPMoNd253/vIEoOS00S3xo6r3vWeuhDtPrnmz TPcv8d2LW5ab7hqzstt1gNSNDmFlSt/3xUIK5dbLQNn/SCY+yaHYzHQfChLcDm5O8qJo 34fVv3kGfX+bUv8HmvD/Lp3llN5OF30V8SpO3vQ23Vdp96+j8xsYaXzHTTox/7VpFGd5 jSBv3HFg9Hf9hSTmp1fEzQTP19dEKsjJyv8BNRgkj1Z8aDiRcFF5bzcD1Fzj8xFoKWxc 8z7Q== MIME-Version: 1.0 Received: by 10.42.147.74 with SMTP id m10mr9197109icv.0.1352141633726; Mon, 05 Nov 2012 10:53:53 -0800 (PST) Received: by 10.231.85.26 with HTTP; Mon, 5 Nov 2012 10:53:53 -0800 (PST) In-Reply-To: References: Date: Mon, 5 Nov 2012 12:53:53 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [multimob] Presentations for IETF 85 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 18:53:54 -0000 Please make sure to send your presentations to sarikaya2012@gmail.com I am having trouble receiving mails to sarikaya@ieee.org because of Sandy hurricane caused power disruptions in NY and NJ area in IEEE servers. Behcet On Fri, Oct 26, 2012 at 4:07 PM, Behcet Sarikaya wrote: > Hi all, > > It seems like the agenda at > http://www.ietf.org/proceedings/85/agenda/agenda-85-multimob > is now stable. > > It is time to submit the presentations. Please submit your presentation to > multimob-chairs@tools.ietf.org > > Regards, > > Behcet From prvs=649e6573b=schmidt@informatik.haw-hamburg.de Mon Nov 5 14:28:45 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21E221F8447 for ; Mon, 5 Nov 2012 14:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcwsjxtlA4EV for ; Mon, 5 Nov 2012 14:28:45 -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 7274C21F8438 for ; Mon, 5 Nov 2012 14:28:44 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAEg9mFCNFh5K/2dsb2JhbABEFoYBvR2BCIIeAQEBBAEBASAPAQU2CgEMBAkCEQMBAgECAgUEEggDAgIJAwIBAgEVHwkIBgoDAQUCAQEFEodvBAeoJ5JngSCKYRqFD4ETA4hajj2ET4VLhQ6DDYFGFw Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 05 Nov 2012 23:28:42 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id C944410CF285; Mon, 5 Nov 2012 23:28:42 +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 24130-01; Mon, 5 Nov 2012 23:28:42 +0100 (CET) Received: from [130.129.84.79] (dhcp-544f.meeting.ietf.org [130.129.84.79]) (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 780F610CF282; Mon, 5 Nov 2012 23:28:41 +0100 (CET) Message-ID: <50983D98.3040905@informatik.haw-hamburg.de> Date: Mon, 05 Nov 2012 17:28:40 -0500 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: LUIS MIGUEL CONTRERAS MURILLO References: <20121022180703.7551.40147.idtracker@ietfa.amsl.com> <823234EF5C7C334998D973D822FF801B1B8570D4@EX10-MB1-MAD.hi.inet> In-Reply-To: <823234EF5C7C334998D973D822FF801B1B8570D4@EX10-MB1-MAD.hi.inet> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: "multimob@ietf.org" Subject: Re: [multimob] RV: I-D Action: draft-ietf-multimob-fast-handover-03.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 22:28:45 -0000 Hi Luis, I was just flying over the rams/sial draft and saw my previous comments untreated. This was the transient binding below ... and IPv4 treatment ... and some more details I had commented about 10 - 15 months ago, but cannot quickly find my mail. Please have a look. So I guess you wanted to say "*partially* addressing received comments" Cheers, Thomas -------- Original Message -------- Subject: [multimob] draft-ietf-multimob-fast-handover + transient binding Date: Mon, 30 Jul 2012 14:36:25 -0700 From: Thomas C. Schmidt To: multimob@ietf.org Hi, as discussed today in the meeting, the following question was raised: draft-ietf-multimob-fast-handover transfers context from pMAG via LMA to nMAG - which in concept corresponds to the *Transient*Binding* in unicast RFC 6058 http://tools.ietf.org/html/rfc6058. draft-ietf-multimob-fast-handover does not even reference RFC 6058 ... but probably should closely stick to the unicast solution. So the question is about protocol systematics: Do we want unicast and multicast protocol operations remain incompatible? Cheers, Thomas On 23.10.2012 15:09, LUIS MIGUEL CONTRERAS MURILLO wrote: > Hi all, > > Yesterday we submitted a new version of the WG document "draft-ietf-multimob-fast-handover", addressing received comments and pending sections. > > Additional comments are welcome. > > Best regards, > > Luis > > -----Mensaje original----- > De: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] En nombre de internet-drafts@ietf.org > Enviado el: lunes, 22 de octubre de 2012 20:07 > Para: i-d-announce@ietf.org > CC: multimob@ietf.org > Asunto: [multimob] I-D Action: draft-ietf-multimob-fast-handover-03.txt > > > 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 : PMIPv6 multicast handover optimization by the Subscription Information Acquisition through the LMA (SIAL) > Author(s) : Luis M. Contreras > Carlos J. Bernardos > Ignacio Soto > Filename : draft-ietf-multimob-fast-handover-03.txt > Pages : 42 > Date : 2012-10-22 > > Abstract: > This document specifies a multicast handover optimization mechanism > for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic > to mobile nodes after handovers. The mechanism is based on speeding > up the acquisition of mobile nodes' multicast context by the mobile > access gateways. To do that, extensions to the current Proxy Mobile > IPv6 protocol are proposed. These extensions are not only applicable > to the base solution for multicast support in Proxy Mobile IPv6, but > they can also be applied to other solutions being developed to avoid > the tunnel convergence problem. Furthermore, they are also > independent of the role played by the mobile access gateway within > the multicast network (either acting as multicast listener discovery > proxy or multicast router). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-multimob-fast-handover > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-multimob-fast-handover-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-fast-handover-03 > > > 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 > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. > This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > -- 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 cjbc@it.uc3m.es Mon Nov 5 15:13:33 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED43A1F0C4A for ; Mon, 5 Nov 2012 15:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EH2JaZ7wQIhw for ; Mon, 5 Nov 2012 15:13:33 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id C6BBB21F849F for ; Mon, 5 Nov 2012 15:13:32 -0800 (PST) X-uc3m-safe: yes Received: from [130.129.83.185] (dhcp-53b9.meeting.ietf.org [130.129.83.185]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 7A46DC35A0E; Tue, 6 Nov 2012 00:13:30 +0100 (CET) Message-ID: <1352157208.7643.82.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Thomas C. Schmidt" Date: Tue, 06 Nov 2012 00:13:28 +0100 In-Reply-To: <50983D98.3040905@informatik.haw-hamburg.de> References: <20121022180703.7551.40147.idtracker@ietfa.amsl.com> <823234EF5C7C334998D973D822FF801B1B8570D4@EX10-MB1-MAD.hi.inet> <50983D98.3040905@informatik.haw-hamburg.de> Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-lztG1agYN6h2duB24pNC" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19344.000 X-TM-AS-Result: No--40.929-7.0-31-1 X-imss-scan-details: No--40.929-7.0-31-1 Cc: "multimob@ietf.org" Subject: Re: [multimob] RV: I-D Action: draft-ietf-multimob-fast-handover-03.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 23:13:34 -0000 --=-lztG1agYN6h2duB24pNC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thomas, On Mon, 2012-11-05 at 17:28 -0500, Thomas C. Schmidt wrote: > Hi Luis, >=20 > I was just flying over the rams/sial draft and saw my previous comments= =20 > untreated. >=20 > This was the transient binding below ... and IPv4 treatment ... and some= =20 > more details I had commented about 10 - 15 months ago, but cannot=20 > quickly find my mail. Please have a look. Regarding the transient binding, I thought Marco already commented on that. I'm just pasting below what he said: "Just a side note: As there was already some confusion during Vancouver meeting and the reference to the transient binding extensions (RFC6058) still shows up repeatedly, let me clarify one thing: PFMIP6 and Transient Binding address different use cases, they have been specified to address different problem spaces. It's=20 not appropriate to refer to these two unicast protocol extensions in the multicast space [...]" Probably Luis can add on top of that. >=20 > So I guess you wanted to say "*partially* addressing received comments" Regarding the other comments you mentioned, please tell us which specific issues you have on current version. When we said that current version addresses all received comments, we truly believed that, though it is possible we missed some by mistake (not intentionally). We are actually looking forward for your review. Thanks, Carlos >=20 > Cheers, >=20 > Thomas >=20 > -------- Original Message -------- > Subject: [multimob] draft-ietf-multimob-fast-handover + transient binding > Date: Mon, 30 Jul 2012 14:36:25 -0700 > From: Thomas C. Schmidt > To: multimob@ietf.org >=20 > Hi, >=20 > as discussed today in the meeting, the following question was raised: >=20 > draft-ietf-multimob-fast-handover transfers context from pMAG via LMA to > nMAG - which in concept corresponds to the *Transient*Binding* in > unicast RFC 6058 http://tools.ietf.org/html/rfc6058. >=20 > draft-ietf-multimob-fast-handover does not even reference RFC 6058 ... > but probably should closely stick to the unicast solution. >=20 > So the question is about protocol systematics: Do we want unicast and > multicast protocol operations remain incompatible? >=20 > Cheers, >=20 > Thomas >=20 > On 23.10.2012 15:09, LUIS MIGUEL CONTRERAS MURILLO wrote: > > Hi all, > > > > Yesterday we submitted a new version of the WG document "draft-ietf-mul= timob-fast-handover", addressing received comments and pending sections. > > > > Additional comments are welcome. > > > > Best regards, > > > > Luis > > > > -----Mensaje original----- > > De: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] En nom= bre de internet-drafts@ietf.org > > Enviado el: lunes, 22 de octubre de 2012 20:07 > > Para: i-d-announce@ietf.org > > CC: multimob@ietf.org > > Asunto: [multimob] I-D Action: draft-ietf-multimob-fast-handover-03.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the Multicast Mobility Working Group of = the IETF. > > > > Title : PMIPv6 multicast handover optimization by th= e Subscription Information Acquisition through the LMA (SIAL) > > Author(s) : Luis M. Contreras > > Carlos J. Bernardos > > Ignacio Soto > > Filename : draft-ietf-multimob-fast-handover-03.txt > > Pages : 42 > > Date : 2012-10-22 > > > > Abstract: > > This document specifies a multicast handover optimization mechanism > > for Proxy Mobile IPv6 to accelerate the delivery of multicast traff= ic > > to mobile nodes after handovers. The mechanism is based on speedin= g > > up the acquisition of mobile nodes' multicast context by the mobile > > access gateways. To do that, extensions to the current Proxy Mobil= e > > IPv6 protocol are proposed. These extensions are not only applicab= le > > to the base solution for multicast support in Proxy Mobile IPv6, bu= t > > they can also be applied to other solutions being developed to avoi= d > > the tunnel convergence problem. Furthermore, they are also > > independent of the role played by the mobile access gateway within > > the multicast network (either acting as multicast listener discover= y > > proxy or multicast router). > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-multimob-fast-handover > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-multimob-fast-handover-03 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-fast-handover-03 > > > > > > 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 > > > > ________________________________ > > > > Este mensaje se dirige exclusivamente a su destinatario. Puede consulta= r nuestra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n de correo electr=C3= =B3nico en el enlace situado m=C3=A1s abajo. > > This message is intended exclusively for its addressee. We only send an= d receive email on the basis of the terms set out at: > > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > > >=20 --=20 Carlos Jes=C3=BAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-lztG1agYN6h2duB24pNC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlCYSBgACgkQNdy6TdFwT2d+XACgjkHXuug/nxqvgyOnbpq9sgTQ vvwAn3pYayX0COiEXCGMuJI3aOp0pZgJ =pUWs -----END PGP SIGNATURE----- --=-lztG1agYN6h2duB24pNC-- From prvs=650f20da4=schmidt@informatik.haw-hamburg.de Mon Nov 5 16:09:41 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4577111E80AE for ; Mon, 5 Nov 2012 16:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAxp4a7uySgG for ; Mon, 5 Nov 2012 16:09:40 -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 C18F711E80A5 for ; Mon, 5 Nov 2012 16:09:39 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALpUmFCNFh5K/2dsb2JhbABEFsMdgQiCHgEBAQMBAQEBLwEFNgoBBQcECxEDAQIBCQQSCAcJAwIBAgEVHwkIEAMBBQIBAQUSh2kGBAe7FYt8GoY7A4hajj2ET4VLhQ6DDYFGFw Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 06 Nov 2012 01:09:37 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id DB8EB10CF285; Tue, 6 Nov 2012 01:09:37 +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 26317-06; Tue, 6 Nov 2012 01:09:37 +0100 (CET) Received: from [130.129.84.79] (dhcp-544f.meeting.ietf.org [130.129.84.79]) (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 5396010CF284; Tue, 6 Nov 2012 01:09:36 +0100 (CET) Message-ID: <5098553E.2090101@informatik.haw-hamburg.de> Date: Mon, 05 Nov 2012 19:09:34 -0500 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <20121022180703.7551.40147.idtracker@ietfa.amsl.com> <823234EF5C7C334998D973D822FF801B1B8570D4@EX10-MB1-MAD.hi.inet> <50983D98.3040905@informatik.haw-hamburg.de> <1352157208.7643.82.camel@acorde.it.uc3m.es> In-Reply-To: <1352157208.7643.82.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: "multimob@ietf.org" Subject: Re: [multimob] RV: I-D Action: draft-ietf-multimob-fast-handover-03.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 00:09:41 -0000 Hi Carlos, On 05.11.2012 18:13, Carlos Jesús Bernardos Cano wrote: >> I was just flying over the rams/sial draft and saw my previous comments >> untreated. >> >> This was the transient binding below ... and IPv4 treatment ... and some >> more details I had commented about 10 - 15 months ago, but cannot >> quickly find my mail. Please have a look. > > Regarding the transient binding, I thought Marco already commented on > that. I'm just pasting below what he said: > > "Just a side note: As there was already some confusion during Vancouver > meeting and the reference to the transient binding extensions (RFC6058) > still shows up repeatedly, let me clarify one thing: > > PFMIP6 and Transient Binding address different use cases, they > have been specified to address different problem spaces. It's > not appropriate to refer to these two unicast protocol extensions > in the multicast space [...]" > This was a different discussion. Marco said *PFMIP* and *Transient*Binding* are different (which is obviously true) ... but your draft is unrelated to *PFMIP* - it does transfer context via the LMA ... just as *Transient*Binding* does. As mentioned earlier: It does not appear smart to me if we define Multicast solutions that mirror unicast approaches, but remain incompatible on the wire. (For a way how to do unicast-integrated fast handover support see http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast-07). The second issue was *IPv4*support* - I suppose, PMIP acceleration protocols MUST provide IPv4 support. I don't see this in the current version. Regarding further issues I raised longer ago, I searched, but cannot find my old email ... if time permits, I should review the draft in more detail. Cheers, Thomas > Probably Luis can add on top of that. > >> >> So I guess you wanted to say "*partially* addressing received comments" > > Regarding the other comments you mentioned, please tell us which > specific issues you have on current version. When we said that current > version addresses all received comments, we truly believed that, though > it is possible we missed some by mistake (not intentionally). We are > actually looking forward for your review. > > Thanks, > > Carlos > >> >> Cheers, >> >> Thomas >> >> -------- Original Message -------- >> Subject: [multimob] draft-ietf-multimob-fast-handover + transient binding >> Date: Mon, 30 Jul 2012 14:36:25 -0700 >> From: Thomas C. Schmidt >> To: multimob@ietf.org >> >> Hi, >> >> as discussed today in the meeting, the following question was raised: >> >> draft-ietf-multimob-fast-handover transfers context from pMAG via LMA to >> nMAG - which in concept corresponds to the *Transient*Binding* in >> unicast RFC 6058 http://tools.ietf.org/html/rfc6058. >> >> draft-ietf-multimob-fast-handover does not even reference RFC 6058 ... >> but probably should closely stick to the unicast solution. >> >> So the question is about protocol systematics: Do we want unicast and >> multicast protocol operations remain incompatible? >> >> Cheers, >> >> Thomas >> >> On 23.10.2012 15:09, LUIS MIGUEL CONTRERAS MURILLO wrote: >>> Hi all, >>> >>> Yesterday we submitted a new version of the WG document "draft-ietf-multimob-fast-handover", addressing received comments and pending sections. >>> >>> Additional comments are welcome. >>> >>> Best regards, >>> >>> Luis >>> >>> -----Mensaje original----- >>> De: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] En nombre de internet-drafts@ietf.org >>> Enviado el: lunes, 22 de octubre de 2012 20:07 >>> Para: i-d-announce@ietf.org >>> CC: multimob@ietf.org >>> Asunto: [multimob] I-D Action: draft-ietf-multimob-fast-handover-03.txt >>> >>> >>> 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 : PMIPv6 multicast handover optimization by the Subscription Information Acquisition through the LMA (SIAL) >>> Author(s) : Luis M. Contreras >>> Carlos J. Bernardos >>> Ignacio Soto >>> Filename : draft-ietf-multimob-fast-handover-03.txt >>> Pages : 42 >>> Date : 2012-10-22 >>> >>> Abstract: >>> This document specifies a multicast handover optimization mechanism >>> for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic >>> to mobile nodes after handovers. The mechanism is based on speeding >>> up the acquisition of mobile nodes' multicast context by the mobile >>> access gateways. To do that, extensions to the current Proxy Mobile >>> IPv6 protocol are proposed. These extensions are not only applicable >>> to the base solution for multicast support in Proxy Mobile IPv6, but >>> they can also be applied to other solutions being developed to avoid >>> the tunnel convergence problem. Furthermore, they are also >>> independent of the role played by the mobile access gateway within >>> the multicast network (either acting as multicast listener discovery >>> proxy or multicast router). >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-multimob-fast-handover >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-multimob-fast-handover-03 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-fast-handover-03 >>> >>> >>> 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 >>> >>> ________________________________ >>> >>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. >>> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: >>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >>> _______________________________________________ >>> multimob mailing list >>> multimob@ietf.org >>> https://www.ietf.org/mailman/listinfo/multimob >>> >> > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > -- 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 lmcm@tid.es Tue Nov 6 02:58:40 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3CD921F85A8 for ; Tue, 6 Nov 2012 02:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qa8vLPYs9Fqz for ; Tue, 6 Nov 2012 02:58:39 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 512A321F84EC for ; Tue, 6 Nov 2012 02:58:36 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MD2009A4BTNT8@tid.hi.inet> for multimob@ietf.org; Tue, 06 Nov 2012 11:58:35 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 2C.CA.05494.B5DE8905; Tue, 06 Nov 2012 11:58:35 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MD20099ZBTNT8@tid.hi.inet> for multimob@ietf.org; Tue, 06 Nov 2012 11:58:35 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.64]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0318.004; Tue, 06 Nov 2012 11:58:34 +0100 Date: Tue, 06 Nov 2012 10:58:34 +0000 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: <50983D98.3040905@informatik.haw-hamburg.de> X-Originating-IP: [10.95.64.115] To: "Thomas C. Schmidt" Message-id: <823234EF5C7C334998D973D822FF801B1EDADC6B@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: es-ES Content-transfer-encoding: base64 Accept-Language: es-ES, en-US Thread-topic: [multimob] RV: I-D Action: draft-ietf-multimob-fast-handover-03.txt Thread-index: AQHNu6T0RK97IBJ3oEyIMXM/GB/Eh5fcopQQ X-AuditID: 0a5f4e69-b7fc06d000001576-79-5098ed5b123f X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsXCFe9nqBv9dkaAQX+nuMWMj30sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmL2ggbXgSkrFkWNPGRsYO5K6GDk5JARMJLZ09rJA2GISF+6t ZwOxhQS2MUrcP1nXxcgFZP9mlFi+ZgYLhDONUWLZli9gVSwCqhIffxxgArHZBAwlZu2cxApi CwsESJw8sxvM5hSwlFiw4ywTxAYFiT/nHoNtExGwljhz5g8TyFBmgYmMEgtaJoIV8Qp4S2yb c4UZwhaU+DH5HlADB1CRusSUKbkgYWYBcYk5vyayQtiKEtMWNTCC2IwCshIrz59mhJgfLLH6 8W5GkFYRASOJm28UIE4QkFiy5zwzhC0q8fLxP1aIvzYySkxtv8o2gVF8FpLNsxA2z0KyeRaS zQsYWVYxihUnFWWmZ5TkJmbmpBsY6WVk6mXmpZZsYoREUeYOxuU7VQ4xCnAwKvHwJsTMCBBi TSwrrsw9xCjJwaQkynvnBVCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO+ObUA53pTEyqrUonyY lAwHh5IEb+kboJRgUWp6akVaZg4wVcCkmTg4Qdp5gNrTQWp4iwsSc4sz0yHypxhVOXbuXPiQ UYglLz8vVUqctxCkSACkKKM0D27OK0ZxoIOFeb1AsjzAZAc34RXQcCag4cXXwIaXJCKkpBoY dT9qFvmoePhvtJTzM386/8u5H2wqT27dYte4bBiauMMj+bNLntLT9iV39CwOfLsXJlZ2pVXm T/Dls49elvKwVjdfTMoTVTTnTPrwV+Nkeukq6YM/69L+z6251/MwcnLdmba09XceyAqwbMh7 d8jXOe7VhBciLzskp4Qq2x551xrXx168LDNZiaU4I9FQi7moOBEAKtq2EzMDAAA= References: <20121022180703.7551.40147.idtracker@ietfa.amsl.com> <823234EF5C7C334998D973D822FF801B1B8570D4@EX10-MB1-MAD.hi.inet> <50983D98.3040905@informatik.haw-hamburg.de> Cc: "multimob@ietf.org" Subject: Re: [multimob] RV: I-D Action: draft-ietf-multimob-fast-handover-03.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 10:58:41 -0000 SGkgVGhvbWFzLA0KDQpUaGFua3MgZm9yIHJlZnJlc2hpbmcgdGhlc2UgY29tbWVudHMuIFJlZ2Fy ZGluZyB0aGUgVHJhbnNpZW50IEJpbmRpbmcgdG9waWMgd2UgaG9uZXN0bHkgdGhvdWdodCB0aGlz IHdhcyBhbHJlYWR5IGNsYXJpZmllZCB3aXRoIHRoZSBNYXJjb+KAmXMgbWFpbCBpbiB0aGUgaGFu ZG92ZXItcmVsYXRlZCBkaXNjdXNzaW9uIGdlbmVyYXRlZCBkdXJpbmcgbGFzdCBJRVRGIG1lZXRp bmcgKGEgdGhyZWFkIHdoaWNoIGludm9sdmVkIGRyYWZ0LWlldGYtbXVsdGltb2ItZmFzdC1oYW5k b3ZlciwgZHJhZnQtc2NobWlkdC1tdWx0aW1vYi1mbWlwdjYtcGZtaXB2Ni1tdWx0aWNhc3QsIGFu ZCB0cmFuc2llbnQgYmluZGluZykuIFNpbmNlIGl0IHNlZW1zIHRoYXQgd2UgcHJvYmFibHkgd2Vy ZSB3cm9uZywgbGV0IG1lIGdvIHRocm91Z2ggdGhpcyBhbmQgdGhlIHJlc3Qgb2YgdGhlIGNvbW1l bnRzIHlvdSBwcm92aWRlLg0KDQo9PSBUcmFuc2llbnQgYmluZGluZyA9PQ0KDQpZb3UgcG9pbnRl ZCBvdXQgYSBwb3RlbnRpYWwgcmVsYXRpb25zaGlwIGJldHdlZW4gZHJhZnQtaWV0Zi1tdWx0aW1v Yi1mYXN0LWhhbmRvdmVyIGFuZCBSRkM2MDU4LiBJIGFzc3VtZSB0aGF0LCBmcm9tIHRoZSB3aG9s ZSBkcmFmdC1pZXRmLW11bHRpbW9iLWZhc3QtaGFuZG92ZXIsIHlvdSBzcGVjaWZpY2FsbHkgc2Vl IGFwcGFyZW50IHNpbWlsYXJpdGllcyBmb3IgdGhlIHByb2FjdGl2ZSBoYW5kb3ZlciBjYXNlIChk dWUgdGhhdCBpbiB0aGUgcmVhY3RpdmUgY2FzZSB0aGVyZSBpcyBubyBvdGhlciBpbnRlcmFjdGlv biB3aXRoIHRoZSBCQ0UgLWFkZGl0aW9uYWwgdG8gd2hhdCBpcyBtZW50aW9uZWQgaW4gUkZDNTIx My0gdGhhbiBjaGVja2luZyBhIGZsYWcpLg0KDQpIb3dldmVyIHRoaXMgcG90ZW50aWFsIHJlbGF0 aW9uc2hpcCBpcyBub3QgYWN0dWFsbHkgdGhlIGNhc2UgZm9yIGEgbnVtYmVyIG9mIHJlYXNvbnMg SSB3aWxsIHRyeSB0byBleHBsYWluIGluIHRoaXMgbWFpbC4NCg0KQmFzaWNhbGx5LCBSRkM2MDU4 IGFsbG93cyB0aGUgbWFpbnRlbmFuY2Ugb2YgZGVkaWNhdGVkIGFuZCBzZXBhcmF0ZWQgZm9yd2Fy ZGluZyBydWxlcyBmb3IgdXBsaW5rIGFuZCBkb3dubGluaywgYW5kIHRoZSBtYWludGVuYW5jZSBv ZiB0d28gZm9yd2FyZGluZyBlbnRyaWVzIGF0IHRoZSBMTUEgcmVzcGVjdCB0byB0aGUgTU4sIHdo aWNoIGFsbG93cyB0aGUgc2ltdWx0YW5lb3VzIGRlbGl2ZXJ5IG9mIGRhdGEgdGhyb3VnaCBwTUFH IGFuZCBuTUFHIHRvd2FyZHMgdGhlIE1OLiBJbiBkcmFmdC1pZXRmLW11bHRpbW9iLWZhc3QtaGFu ZG92ZXIsIGhvd2V2ZXIsIGl0IGlzIGFzc3VtZWQgYSBkaXJlY3QgdHJhbnNpdGlvbiBiZXR3ZWVu IHRoZSB0d28gYWN0aXZlIEJDRSBzdGF0ZXMsIGFzIHN0YXRlZCBpbiBSRkM1MjEzICh0aGF0IGlz LCB0aGUgZm9yd2FyZGluZyBlbnRyeSBhdCBMTUEgcG9pbnRzIHRvIHRoZSBuTUFHIGFzIHNvb24g YXMgdGhlIFBCVSBpcyByZWNlaXZlZCBmcm9tIHRoZSBuTUFHLCBkZWxldGluZyB0aGUgcHJldmlv dXMgb25lIHBvaW50aW5nIHRvIHRoZSBwTUFHOyBpdCBkb2VzIG5vdCBzcGVjaWZ5IGEgQkNFIGNh cGFibGUgdG8gcmVmZXIgdG8gdHdvIHByb3h5IENvQXMgYXQgdGhlIHNhbWUgdGltZSkuDQoNClNJ QUwgKGRyYWZ0LWlldGYtbXVsdGltb2ItZmFzdC1oYW5kb3ZlcikgYXBwcm9hY2ggZG9lcyBub3Qg aW1wbHkgc3RhdHVzIGNoYW5nZSwgbm9yIGFueSBvdGhlciB0ZW1wb3JhbCBzdGF0dXMsIGluIHRo ZSBCQ0UsIGl0IGp1c3QgZmFjaWxpdGF0ZXMgdGhlIHN0b3JhZ2UgYW5kIGZvcndhcmRpbmcgb2Yg Y29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiwgc3BlY2lmaWNhbGx5IHRoZSBtdWx0aWNhc3QgYWRk cmVzcyByZWNvcmRzIHByb3ZpZGluZyB0aGUgbXVsdGljYXN0IHN1YnNjcmlwdGlvbiBpbmZvcm1h dGlvbiB0aGF0IHRoZSBNTiBpcyBzdWJzY3JpYmVkIHRvLiBJbiB0aGUgcHJvYWN0aXZlIGhhbmRv dmVyIGNhc2UsIHRoZXNlIG11bHRpY2FzdCBhZGRyZXNzIHJlY29yZHMgYXJlIHN0b3JlZCBpbiB0 aGUgQkNFIG9uY2UgdGhlIE1OIGRlLXJlZ2lzdGVycyBmcm9tIHRoZSBwTUFHLiBUaGlzIGluZm8g aXMgc3RvcmVkIGFzIGFueSBvdGhlciBpbmZvcm1hdGlvbiwgaXQgZG9lcyBub3QgdHJpZ2dlciBh bnkgYWN0aW9uLg0KTGF0ZXIgb24gaW4gU0lBTCwgb25jZSB0aGUgTU4gYXR0YWNoZXMgdG8gYSBu TUFHLCB0aGUgbk1BRyByZXRyaWV2ZXMgaW4gdGhlIFBCQSBjb25maWd1cmF0aW9uIGRhdGEgZnJv bSB0aGUgTE1BIGZvciBzZXJ2aW5nIHRoZSBNTiwgYXMgaXQgZG9lcyBmb3IgaW5zdGFuY2UgZm9y IHRoZSBsaW5rLWxvY2FsIGFkZHJlc3MgdG8gYmUgdXNlZCBhdCB0aGUgTUFHLiBUaGlzIGNvbmZp Z3VyYXRpb24gZGF0YSBpbiB0aGUgU0lBTCBhcHByb2FjaCBkb2VzIG5vdCBpbXBvc2UgYW55IGNo YW5nZSBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZSwgaXQgb25seSBoZWxwcyB0byBhY2NlbGVyYXRl IHRoZSBzdWJzY3JpcHRpb24gYnkgdGhlIG5NQUcgb2YgdGhlIGNvbnRlbnQgd2hpY2ggdGhlIE1O IHdhcyByZWNlaXZpbmcgYXQgdGhlIHBNQUcsIGluc3RlYWQgb2Ygd2FpdGluZyBmb3IgcmVzb2x2 aW5nIHRoZSBzdWJzY3JpcHRpb24gaW5mb3JtYXRpb24gYXMgc3BlY2lmaWVkIGluIFJGQzYyMjQu DQoNCkZ1cnRoZXJtb3JlLCBpbiBSRkM2MDU4IHRoZSB0cmFuc2llbnQgYmluZGluZyBpcyB0cmln Z2VyZWQgYnkgdGhlIG5NQUcsIHNvIHRoaXMgd291bGQgY29ycmVzcG9uZCB0byBhIHJlYWN0aXZl IGhhbmRvdmVyIGNhc2UuIEluIFNJQUwsIGFzIHJlc3VsdCBvZiByZWFjdGl2ZSBjYXNlLCB0aGUg bXVsdGljYXN0IGFkZHJlc3MgcmVjb3JkcyBoYXZlIG5vdCBiZWVuIHByZXZpb3VzbHkgc3RvcmVk IGluIHRoZSBCQ0UsIHNvIGFuIGludGVycm9nYXRpb24gcHJvY2VzcyBpcyB0cmlnZ2VyZWQgdG93 YXJkcyB0aGUgcE1BRy4gU28sIHRoZSByZWFjdGl2ZSBoYW5kb3ZlciBjYXNlIHJlc3VsdHMgb24g b3J0aG9nb25hbCBwcm9jZWR1cmVzIGluIGJvdGggYXBwcm9hY2hlcy4NCg0KPT0gSVB2NCA9PQ0K DQpTSUFMIGRlZmluZXMgYW4gc2lnbmFsaW5nIHByb2NlZHVyZSBpbnRlcm5hbCB0byB0aGUgbmV0 d29yaywgc3BlY2lmaWNhbGx5IGJldHdlZW4gTUFHcyBhbmQgTE1Bcy4gVGhlcmUgaXMgbm8gc3Bl Y2lmaWMgbXVsdGljYXN0IHNpZ25hbGluZyBpbiBTSUFMLCBidXQganVzdCBhIG11bHRpY2FzdCBt ZW1iZXJzaGlwIGNvbnRleHQgdHJhbnNmZXIgYmV0d2VlbiBQTUlQdjYgZW50aXRpZXMgd2hpY2gg Y2FuIGJlIHRyYW5zcG9ydGVkIGVpdGhlciBieSB1c2luZyBJUHY0IG9yIElQdjYsIGRlcGVuZGlu ZyBvbiB0aGUgc3BlY2lmaWMgZGVwbG95bWVudCBpbiB0aGUgZG9tYWluLiBGcm9tIHRoaXMgcG9p bnQgb2YgdmlldywgdGhlcmUgYXJlIG5vdCBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBvciBuZWVk cyB0byB0aGF0IGFscmVhZHkgc3BlY2lmaWVkIGluIFJGQzUyMTMsIFJGQzU4NDQgb3IgUkZDNjIy NC4NCg0KPT0gUHJldmlvdXMgY29tbWVudHMgPT0NCg0KSSB3b3VsZCBuZWVkIGEgbW9yZSBwcmVj aXNlIHJlZmVyZW5jZSB0byB0aGF0IG9sZCBjb21tZW50cyBub3QgYWxyZWFkeSBhZGRyZXNzZWQg aW4gdGhlIGN1cnJlbnQgdmVyc2lvbi4gRXZlbiBpZiBJIHRha2UgYSBsb29rIHRocm91Z2ggdGhl IG1haWwgbGlzdCwgSSB3b3VsZCBiZSBncmF0ZWZ1bCBpZiB5b3UgY291bGQgaWRlbnRpZnkgeWV0 IG9wZW4gcG9pbnRzLiBNYXliZSBhZnRlciByZWFkaW5nIGFnYWluIHRoYXQgbWFpbHMgYW5kIGNv bW1lbnRzIHdlIGJvdGggcmVhbGl6ZWQgdGhhdCBoYXZlIGJlZW4gYWxyZWFkeSBjb3ZlcmVkIGlu IHRoZSB0ZXh0Lg0KDQpIb3BlIHRoaXMgY2xhcmlmaWVzDQoNCkJlc3QgcmVnYXJkcywNCg0KTHVp cw0KDQoNCi0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQpEZTogVGhvbWFzIEMuIFNjaG1pZHQg W21haWx0bzpzY2htaWR0QGluZm9ybWF0aWsuaGF3LWhhbWJ1cmcuZGVdDQpFbnZpYWRvIGVsOiBs dW5lcywgMDUgZGUgbm92aWVtYnJlIGRlIDIwMTIgMjM6MjkNClBhcmE6IExVSVMgTUlHVUVMIENP TlRSRVJBUyBNVVJJTExPDQpDQzogbXVsdGltb2JAaWV0Zi5vcmcNCkFzdW50bzogUmU6IFttdWx0 aW1vYl0gUlY6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbXVsdGltb2ItZmFzdC1oYW5kb3Zlci0w My50eHQNCg0KSGkgTHVpcywNCg0KSSB3YXMganVzdCBmbHlpbmcgb3ZlciB0aGUgcmFtcy9zaWFs IGRyYWZ0IGFuZCBzYXcgbXkgcHJldmlvdXMgY29tbWVudHMgdW50cmVhdGVkLg0KDQpUaGlzIHdh cyB0aGUgdHJhbnNpZW50IGJpbmRpbmcgYmVsb3cgLi4uIGFuZCBJUHY0IHRyZWF0bWVudCAuLi4g YW5kIHNvbWUgbW9yZSBkZXRhaWxzIEkgaGFkIGNvbW1lbnRlZCBhYm91dCAxMCAtIDE1IG1vbnRo cyBhZ28sIGJ1dCBjYW5ub3QgcXVpY2tseSBmaW5kIG15IG1haWwuIFBsZWFzZSBoYXZlIGEgbG9v ay4NCg0KU28gSSBndWVzcyB5b3Ugd2FudGVkIHRvIHNheSAiKnBhcnRpYWxseSogYWRkcmVzc2lu ZyByZWNlaXZlZCBjb21tZW50cyINCg0KQ2hlZXJzLA0KDQpUaG9tYXMNCg0KLS0tLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDogW211bHRpbW9iXSBkcmFmdC1pZXRmLW11 bHRpbW9iLWZhc3QtaGFuZG92ZXIgKyB0cmFuc2llbnQgYmluZGluZw0KRGF0ZTogTW9uLCAzMCBK dWwgMjAxMiAxNDozNjoyNSAtMDcwMA0KRnJvbTogVGhvbWFzIEMuIFNjaG1pZHQgPHNjaG1pZHRA aW5mb3JtYXRpay5oYXctaGFtYnVyZy5kZT4NClRvOiBtdWx0aW1vYkBpZXRmLm9yZyA8bXVsdGlt b2JAaWV0Zi5vcmc+DQoNCkhpLA0KDQphcyBkaXNjdXNzZWQgdG9kYXkgaW4gdGhlIG1lZXRpbmcs IHRoZSBmb2xsb3dpbmcgcXVlc3Rpb24gd2FzIHJhaXNlZDoNCg0KZHJhZnQtaWV0Zi1tdWx0aW1v Yi1mYXN0LWhhbmRvdmVyIHRyYW5zZmVycyBjb250ZXh0IGZyb20gcE1BRyB2aWEgTE1BIHRvIG5N QUcgLSB3aGljaCBpbiBjb25jZXB0IGNvcnJlc3BvbmRzIHRvIHRoZSAqVHJhbnNpZW50KkJpbmRp bmcqIGluIHVuaWNhc3QgUkZDIDYwNTggaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjA1 OC4NCg0KZHJhZnQtaWV0Zi1tdWx0aW1vYi1mYXN0LWhhbmRvdmVyIGRvZXMgbm90IGV2ZW4gcmVm ZXJlbmNlIFJGQyA2MDU4IC4uLg0KYnV0IHByb2JhYmx5IHNob3VsZCBjbG9zZWx5IHN0aWNrIHRv IHRoZSB1bmljYXN0IHNvbHV0aW9uLg0KDQpTbyB0aGUgcXVlc3Rpb24gaXMgYWJvdXQgcHJvdG9j b2wgc3lzdGVtYXRpY3M6IERvIHdlIHdhbnQgdW5pY2FzdCBhbmQgbXVsdGljYXN0IHByb3RvY29s IG9wZXJhdGlvbnMgcmVtYWluIGluY29tcGF0aWJsZT8NCg0KQ2hlZXJzLA0KDQpUaG9tYXMNCg0K T24gMjMuMTAuMjAxMiAxNTowOSwgTFVJUyBNSUdVRUwgQ09OVFJFUkFTIE1VUklMTE8gd3JvdGU6 DQo+IEhpIGFsbCwNCj4NCj4gWWVzdGVyZGF5IHdlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9m IHRoZSBXRyBkb2N1bWVudCAiZHJhZnQtaWV0Zi1tdWx0aW1vYi1mYXN0LWhhbmRvdmVyIiwgYWRk cmVzc2luZyByZWNlaXZlZCBjb21tZW50cyBhbmQgcGVuZGluZyBzZWN0aW9ucy4NCj4NCj4gQWRk aXRpb25hbCBjb21tZW50cyBhcmUgd2VsY29tZS4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPg0KPiBM dWlzDQo+DQo+IC0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQo+IERlOiBtdWx0aW1vYi1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bXVsdGltb2ItYm91bmNlc0BpZXRmLm9yZ10gRW4NCj4gbm9t YnJlIGRlIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBFbnZpYWRvIGVsOiBsdW5lcywgMjIgZGUg b2N0dWJyZSBkZQ0KPiAyMDEyIDIwOjA3DQo+IFBhcmE6IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0K PiBDQzogbXVsdGltb2JAaWV0Zi5vcmcNCj4gQXN1bnRvOiBbbXVsdGltb2JdIEktRCBBY3Rpb246 DQo+IGRyYWZ0LWlldGYtbXVsdGltb2ItZmFzdC1oYW5kb3Zlci0wMy50eHQNCj4NCj4NCj4gQSBO ZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQt RHJhZnRzIGRpcmVjdG9yaWVzLg0KPiAgIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhl IE11bHRpY2FzdCBNb2JpbGl0eSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPg0KPiAgICAg ICAgICBUaXRsZSAgICAgICAgICAgOiBQTUlQdjYgbXVsdGljYXN0IGhhbmRvdmVyIG9wdGltaXph dGlvbiBieSB0aGUgU3Vic2NyaXB0aW9uIEluZm9ybWF0aW9uIEFjcXVpc2l0aW9uIHRocm91Z2gg dGhlIExNQSAoU0lBTCkNCj4gICAgICAgICAgQXV0aG9yKHMpICAgICAgIDogTHVpcyBNLiBDb250 cmVyYXMNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2FybG9zIEouIEJlcm5hcmRvcw0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJZ25hY2lvIFNvdG8NCj4gICAgICAgICAgRmls ZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1tdWx0aW1vYi1mYXN0LWhhbmRvdmVyLTAzLnR4dA0K PiAgICAgICAgICBQYWdlcyAgICAgICAgICAgOiA0Mg0KPiAgICAgICAgICBEYXRlICAgICAgICAg ICAgOiAyMDEyLTEwLTIyDQo+DQo+IEFic3RyYWN0Og0KPiAgICAgVGhpcyBkb2N1bWVudCBzcGVj aWZpZXMgYSBtdWx0aWNhc3QgaGFuZG92ZXIgb3B0aW1pemF0aW9uIG1lY2hhbmlzbQ0KPiAgICAg Zm9yIFByb3h5IE1vYmlsZSBJUHY2IHRvIGFjY2VsZXJhdGUgdGhlIGRlbGl2ZXJ5IG9mIG11bHRp Y2FzdCB0cmFmZmljDQo+ICAgICB0byBtb2JpbGUgbm9kZXMgYWZ0ZXIgaGFuZG92ZXJzLiAgVGhl IG1lY2hhbmlzbSBpcyBiYXNlZCBvbiBzcGVlZGluZw0KPiAgICAgdXAgdGhlIGFjcXVpc2l0aW9u IG9mIG1vYmlsZSBub2RlcycgbXVsdGljYXN0IGNvbnRleHQgYnkgdGhlIG1vYmlsZQ0KPiAgICAg YWNjZXNzIGdhdGV3YXlzLiAgVG8gZG8gdGhhdCwgZXh0ZW5zaW9ucyB0byB0aGUgY3VycmVudCBQ cm94eSBNb2JpbGUNCj4gICAgIElQdjYgcHJvdG9jb2wgYXJlIHByb3Bvc2VkLiAgVGhlc2UgZXh0 ZW5zaW9ucyBhcmUgbm90IG9ubHkgYXBwbGljYWJsZQ0KPiAgICAgdG8gdGhlIGJhc2Ugc29sdXRp b24gZm9yIG11bHRpY2FzdCBzdXBwb3J0IGluIFByb3h5IE1vYmlsZSBJUHY2LCBidXQNCj4gICAg IHRoZXkgY2FuIGFsc28gYmUgYXBwbGllZCB0byBvdGhlciBzb2x1dGlvbnMgYmVpbmcgZGV2ZWxv cGVkIHRvIGF2b2lkDQo+ICAgICB0aGUgdHVubmVsIGNvbnZlcmdlbmNlIHByb2JsZW0uICBGdXJ0 aGVybW9yZSwgdGhleSBhcmUgYWxzbw0KPiAgICAgaW5kZXBlbmRlbnQgb2YgdGhlIHJvbGUgcGxh eWVkIGJ5IHRoZSBtb2JpbGUgYWNjZXNzIGdhdGV3YXkgd2l0aGluDQo+ICAgICB0aGUgbXVsdGlj YXN0IG5ldHdvcmsgKGVpdGhlciBhY3RpbmcgYXMgbXVsdGljYXN0IGxpc3RlbmVyIGRpc2NvdmVy eQ0KPiAgICAgcHJveHkgb3IgbXVsdGljYXN0IHJvdXRlcikuDQo+DQo+DQo+IFRoZSBJRVRGIGRh dGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW11bHRpbW9iLWZhc3QtaGFuZG92ZXINCj4N Cj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+IGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXVsdGltb2ItZmFzdC1oYW5kb3Zlci0w Mw0KPg0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbXVsdGltb2It ZmFzdC1oYW5kb3Zlci0wMw0KPg0KPg0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxh YmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IG11bHRpbW9iIG1haWxpbmcgbGlzdA0KPiBtdWx0aW1vYkBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211bHRpbW9iDQo+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+DQo+IEVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhj bHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBv bMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4g ZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NCj4gVGhpcyBtZXNzYWdlIGlzIGludGVuZGVk IGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUg ZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0KPiBodHRwOi8vd3d3 LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtdWx0aW1vYiBtYWlsaW5nIGxpc3QNCj4g bXVsdGltb2JAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tdWx0aW1vYg0KPg0KDQotLQ0KDQpQcm9mLiBEci4gVGhvbWFzIEMuIFNjaG1pZHQNCsKwIEhh bWJ1cmcgVW5pdmVyc2l0eSBvZiBBcHBsaWVkIFNjaWVuY2VzICAgICAgICAgICAgICAgICAgIEJl cmxpbmVyIFRvciA3IMKwDQrCsCBEZXB0LiBJbmZvcm1hdGlrLCBJbnRlcm5ldCBUZWNobm9sb2dp ZXMgR3JvdXAgICAgMjAwOTkgSGFtYnVyZywgR2VybWFueSDCsA0KwrAgaHR0cDovL3d3dy5oYXct aGFtYnVyZy5kZS9pbmV0ICAgICAgICAgICAgICAgICAgIEZvbjogKzQ5LTQwLTQyODc1LTg0NTIg wrANCsKwIGh0dHA6Ly93d3cuaW5mb3JtYXRpay5oYXctaGFtYnVyZy5kZS9+c2NobWlkdCAgICBG YXg6ICs0OS00MC00Mjg3NS04NDA5IMKwDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5h dGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNl cGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBh YmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJl c3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUg dGVybXMgc2V0IG91dCBhdDoNCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1l ci5hc3B4DQo= From prvs=650f20da4=schmidt@informatik.haw-hamburg.de Tue Nov 6 09:51:21 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A7321F8879 for ; Tue, 6 Nov 2012 09:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQIrx6Y+7d4h for ; Tue, 6 Nov 2012 09:51:20 -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 8BDA621F867D for ; Tue, 6 Nov 2012 09:51:18 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALlMmVCNFh5K/2dsb2JhbAA6ChaGAb0YgQiCHgEBAQQBAQEgBAsBBTYEBgEMBAkCEQMBAgECAgUEEggDAgIJAwIBAgEVHwkIBgoDAQUCAQEFEodvBAepOoI8kEyBIIpjEAoGhSKBEwOIWo49hE+FS4UOgw2BPggX Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 06 Nov 2012 18:51:16 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id C1CB410DC39C; Tue, 6 Nov 2012 18:51:16 +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 00548-09; Tue, 6 Nov 2012 18:51:16 +0100 (CET) Received: from [130.129.84.79] (dhcp-544f.meeting.ietf.org [130.129.84.79]) (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 070E310DC39A; Tue, 6 Nov 2012 18:51:14 +0100 (CET) Message-ID: <50994E12.1010408@informatik.haw-hamburg.de> Date: Tue, 06 Nov 2012 12:51:14 -0500 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: LUIS MIGUEL CONTRERAS MURILLO References: <20121022180703.7551.40147.idtracker@ietfa.amsl.com> <823234EF5C7C334998D973D822FF801B1B8570D4@EX10-MB1-MAD.hi.inet> <50983D98.3040905@informatik.haw-hamburg.de> <823234EF5C7C334998D973D822FF801B1EDADC6B@EX10-MB2-MAD.hi.inet> In-Reply-To: <823234EF5C7C334998D973D822FF801B1EDADC6B@EX10-MB2-MAD.hi.inet> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: "multimob@ietf.org" Subject: Re: [multimob] RV: I-D Action: draft-ietf-multimob-fast-handover-03.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 17:51:21 -0000 Hi Luis, thanks for your reply ... still I don't believe one can just talk away the issues that were raised. [IPv4:] You define new messages, states and behavior in your protocol without mentioning IPv4. Your definitions are exclusively for MLDv2 (why only version 2???). This cannot work with IPv4, and you need not only to specify IPv4-capable signaling + state, but also the coexistence-semantic and - most importantly - methods to treat IPv4 address collisions (see RFC 6224 on that). [RFC 6058:] This RFC defines additional 'transient' binding states and corresponding behavior to 'seamlessly guide the transition' of context from pMAG to nMAG via the LMA by a proactive push. Even though I haven't worked it out, the approach should be able to carry your extensions and facilitate the protocol behavior you aim at. As mentioned earlier, it does not seem a systematic, IETF-style approach to have unicast and mutlicast protocols diverge to incompatibility. There is of course the other aspect of proper credit: Two solutions of context transition in PMIP are (sensibly) possible: 1. pMAG/AR -> nMAG/AR - that's (P)FMIP and was introduced by Rajeev et al. 2. pMAG -> LMA -> nMAG - that's PMIP (reactive pull) and RFC6058 (proactive push), the latter introduced by Marco et al. I don't think it is legible to adopt the latter without even referencing. In summary I strongly believe (i) you inevitably need to fix the IP version issue (ii) you should migrate your protocol operations to be compliant to RFC6058 ... otherwise you need at least to mention up front (abstract), why you build a solution that produces incompatibility with corresponding unicast protocols. Cheers, Thomas On 06.11.2012 05:58, LUIS MIGUEL CONTRERAS MURILLO wrote: > Hi Thomas, > > Thanks for refreshing these comments. Regarding the Transient Binding topic we honestly thought this was already clarified with the Marco’s mail in the handover-related discussion generated during last IETF meeting (a thread which involved draft-ietf-multimob-fast-handover, draft-schmidt-multimob-fmipv6-pfmipv6-multicast, and transient binding). Since it seems that we probably were wrong, let me go through this and the rest of the comments you provide. > > == Transient binding == > > You pointed out a potential relationship between draft-ietf-multimob-fast-handover and RFC6058. I assume that, from the whole draft-ietf-multimob-fast-handover, you specifically see apparent similarities for the proactive handover case (due that in the reactive case there is no other interaction with the BCE -additional to what is mentioned in RFC5213- than checking a flag). > > However this potential relationship is not actually the case for a number of reasons I will try to explain in this mail. > > Basically, RFC6058 allows the maintenance of dedicated and separated forwarding rules for uplink and downlink, and the maintenance of two forwarding entries at the LMA respect to the MN, which allows the simultaneous delivery of data through pMAG and nMAG towards the MN. In draft-ietf-multimob-fast-handover, however, it is assumed a direct transition between the two active BCE states, as stated in RFC5213 (that is, the forwarding entry at LMA points to the nMAG as soon as the PBU is received from the nMAG, deleting the previous one pointing to the pMAG; it does not specify a BCE capable to refer to two proxy CoAs at the same time). > > SIAL (draft-ietf-multimob-fast-handover) approach does not imply status change, nor any other temporal status, in the BCE, it just facilitates the storage and forwarding of configuration information, specifically the multicast address records providing the multicast subscription information that the MN is subscribed to. In the proactive handover case, these multicast address records are stored in the BCE once the MN de-registers from the pMAG. This info is stored as any other information, it does not trigger any action. > Later on in SIAL, once the MN attaches to a nMAG, the nMAG retrieves in the PBA configuration data from the LMA for serving the MN, as it does for instance for the link-local address to be used at the MAG. This configuration data in the SIAL approach does not impose any change in the forwarding plane, it only helps to accelerate the subscription by the nMAG of the content which the MN was receiving at the pMAG, instead of waiting for resolving the subscription information as specified in RFC6224. > > Furthermore, in RFC6058 the transient binding is triggered by the nMAG, so this would correspond to a reactive handover case. In SIAL, as result of reactive case, the multicast address records have not been previously stored in the BCE, so an interrogation process is triggered towards the pMAG. So, the reactive handover case results on orthogonal procedures in both approaches. > > == IPv4 == > > SIAL defines an signaling procedure internal to the network, specifically between MAGs and LMAs. There is no specific multicast signaling in SIAL, but just a multicast membership context transfer between PMIPv6 entities which can be transported either by using IPv4 or IPv6, depending on the specific deployment in the domain. From this point of view, there are not additional requirements or needs to that already specified in RFC5213, RFC5844 or RFC6224. > > == Previous comments == > > I would need a more precise reference to that old comments not already addressed in the current version. Even if I take a look through the mail list, I would be grateful if you could identify yet open points. Maybe after reading again that mails and comments we both realized that have been already covered in the text. > > Hope this clarifies > > Best regards, > > Luis > > > -----Mensaje original----- > De: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de] > Enviado el: lunes, 05 de noviembre de 2012 23:29 > Para: LUIS MIGUEL CONTRERAS MURILLO > CC: multimob@ietf.org > Asunto: Re: [multimob] RV: I-D Action: draft-ietf-multimob-fast-handover-03.txt > > Hi Luis, > > I was just flying over the rams/sial draft and saw my previous comments untreated. > > This was the transient binding below ... and IPv4 treatment ... and some more details I had commented about 10 - 15 months ago, but cannot quickly find my mail. Please have a look. > > So I guess you wanted to say "*partially* addressing received comments" > > Cheers, > > Thomas > > -------- Original Message -------- > Subject: [multimob] draft-ietf-multimob-fast-handover + transient binding > Date: Mon, 30 Jul 2012 14:36:25 -0700 > From: Thomas C. Schmidt > To: multimob@ietf.org > > Hi, > > as discussed today in the meeting, the following question was raised: > > draft-ietf-multimob-fast-handover transfers context from pMAG via LMA to nMAG - which in concept corresponds to the *Transient*Binding* in unicast RFC 6058 http://tools.ietf.org/html/rfc6058. > > draft-ietf-multimob-fast-handover does not even reference RFC 6058 ... > but probably should closely stick to the unicast solution. > > So the question is about protocol systematics: Do we want unicast and multicast protocol operations remain incompatible? > > Cheers, > > Thomas > > On 23.10.2012 15:09, LUIS MIGUEL CONTRERAS MURILLO wrote: >> Hi all, >> >> Yesterday we submitted a new version of the WG document "draft-ietf-multimob-fast-handover", addressing received comments and pending sections. >> >> Additional comments are welcome. >> >> Best regards, >> >> Luis >> >> -----Mensaje original----- >> De: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] En >> nombre de internet-drafts@ietf.org Enviado el: lunes, 22 de octubre de >> 2012 20:07 >> Para: i-d-announce@ietf.org >> CC: multimob@ietf.org >> Asunto: [multimob] I-D Action: >> draft-ietf-multimob-fast-handover-03.txt >> >> >> 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 : PMIPv6 multicast handover optimization by the Subscription Information Acquisition through the LMA (SIAL) >> Author(s) : Luis M. Contreras >> Carlos J. Bernardos >> Ignacio Soto >> Filename : draft-ietf-multimob-fast-handover-03.txt >> Pages : 42 >> Date : 2012-10-22 >> >> Abstract: >> This document specifies a multicast handover optimization mechanism >> for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic >> to mobile nodes after handovers. The mechanism is based on speeding >> up the acquisition of mobile nodes' multicast context by the mobile >> access gateways. To do that, extensions to the current Proxy Mobile >> IPv6 protocol are proposed. These extensions are not only applicable >> to the base solution for multicast support in Proxy Mobile IPv6, but >> they can also be applied to other solutions being developed to avoid >> the tunnel convergence problem. Furthermore, they are also >> independent of the role played by the mobile access gateway within >> the multicast network (either acting as multicast listener discovery >> proxy or multicast router). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-multimob-fast-handover >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-multimob-fast-handover-03 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-fast-handover-03 >> >> >> 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 >> >> ________________________________ >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. >> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> > > -- > > 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 ° > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. > This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > -- 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 prvs=650f20da4=schmidt@informatik.haw-hamburg.de Tue Nov 6 15:33:32 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A43D21F8590 for ; Tue, 6 Nov 2012 15:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTnbrt3tr2Zh for ; Tue, 6 Nov 2012 15:33:32 -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 AF81B21F851B for ; Tue, 6 Nov 2012 15:33:31 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACidmVCNFh5K/2dsb2JhbABEFsNIgQiCHgEBAQQBAQEkCwEFNgoBEAsYCRYPCQMCAQIBFTAGDQEFAgEBF4dvBAerEpArjB2GOwOIWo49hE+FS4UOgw2BRg Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 07 Nov 2012 00:33:30 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 6F37510DC3A6; Wed, 7 Nov 2012 00:33:30 +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 13423-02; Wed, 7 Nov 2012 00:33:29 +0100 (CET) Received: from [130.129.84.79] (dhcp-544f.meeting.ietf.org [130.129.84.79]) (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 2F50510DC39F; Wed, 7 Nov 2012 00:33:28 +0100 (CET) Message-ID: <50999E48.6090708@informatik.haw-hamburg.de> Date: Tue, 06 Nov 2012 18:33:28 -0500 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Zuniga, Juan Carlos" References: <4EE2A0D0.50303@informatik.haw-hamburg.de> In-Reply-To: <4EE2A0D0.50303@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 23:33:32 -0000 Hi Juan Carlos, I was just browsing over the ropt draft and would like to add some comments that relate to my previous comments given a year ago (see below). The status of the current document: * Section 3.5 "PMIPv6 enhancements" is now out, so the section 3 has returned to informational content. * IPv4 compatibility: You have added a section that simply points to RFC 6224 - however, I don't think situations are exactly comparable. RFC 6224 relies on the GRE-tunnel infrastructure MN <-> MAG <-> LMA. This is not true for the MTMA, which does not have MN-specific state. I don't think it's a big issue, but currently the draft is not sound. * Section 4.1. "Extensions to Binding Update List Data Structure" is completely unclear ... seems not informational. * Section 4.3 - Direct routing remains nebulous and severely lacks content. I should pointer to the discussion of direct routing for sources http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-02 - using the different PIM protocols in a mobility regime is by no means so trivial. * Section 5. defines new "Dynamic IP Multicast Selector Option" ... this is out of scope for informational documents. Best regards, Thomas On 09.12.2011 18:59, Thomas C. Schmidt wrote: > Hi all, > > some feedback: > > In general, I support adopting this document as a WG item - it > presents two valid deployment scenarios. But I guess, the intended > status should be informational, as this is just presenting deployment > advice (I know, currently the document does more ...). > > We've been discussing the two solutions (Multicast-Tunnelendpoint, > direct routing) for quite a while and we should come to conclusions ... > on the current document I only had a very brief look (apologies!). > > Here are three comments: > > 1.) On the quick run, I cannot see what Section 3.5 "PMIPv6 > enhancements" really is needed for. I know, I should re-read this (no > time now), still the MTM approach should work without protocol > modifications, I guess. > > 2.) There should be a section / solution on IPv4 compatibility > (including address collisions ...) as needed for PMIPv6. > > 3.) The direct routing section (4) is still rather superficial. It > should explain in detail how to deploy protocols, e.g., PIM-SM in the > presence of these PMIP tunnels ... just to avoid the confusion that has > been evident on this list since Quebec ;) . > > That's only for a quick feedback, > > Thomas > > > > On 08.12.2011 14:53, Behcet Sarikaya wrote: >> Hello all, >> There was consensus on the tunnel convergence solution draft in >> Taipei. >> This mail is to confirm the consensus. >> >> >> This document can be found at: >> http://tools.ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt >> >> This mail starts a WG adoption call on this draft. >> >> The intended status for this document is proposed standard. >> If adopted, the draft will be named: >> >> draft-ietf-multimob-pmipv6-tunnel-convergence. >> >> Please your comments by December 15, 2011. >> >> >> Chairs >> _______________________________________________ >> 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 zunigajc@gmail.com Tue Nov 6 23:31:56 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656E021F8AED for ; Tue, 6 Nov 2012 23:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eXgI7M0iDxH for ; Tue, 6 Nov 2012 23:31:55 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A8ACE21F8AEB for ; Tue, 6 Nov 2012 23:31:54 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so820157eek.31 for ; Tue, 06 Nov 2012 23:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5xumcGS+Om7ZfyEuxj5wTISnCF3cTSnKo3Rdf1paQZc=; b=SyP/Fo+VtbZfxC0hEO9oo3SFcwvMXl5LooHoOXIRng2Jl7lIPFYaGovfw+KZc29f2s wB553s3itu/zVUiHFXTBvc1uXNDCx5IViUg32u7z6qWakKKbn0nWc7k3fJtHhAqjyJbC sb2MNGzxqAmHo+dA4NRgjQrc6R3V/9IrvLA0JkvJhXUVxEV97iqOA0Up4FCyDDTPSXIy GfX/35LpDY/ACIivA5dmMR7No0f7rrSc6TsSSOTQk6dd859LyGoCH047fMwQcIHhLvrm hnX9HY8iCbLRN3FF+HPlPRiWr0j5zDZ6fdt2S0VbM47PK0uX+KTlLxAp3bjb0f5XLh3Y I2SA== MIME-Version: 1.0 Received: by 10.14.225.71 with SMTP id y47mr12860242eep.0.1352273513810; Tue, 06 Nov 2012 23:31:53 -0800 (PST) Received: by 10.223.148.17 with HTTP; Tue, 6 Nov 2012 23:31:53 -0800 (PST) Date: Wed, 7 Nov 2012 02:31:53 -0500 Message-ID: From: Juan Carlos Zuniga To: "Zuniga, Juan Carlos" , multimob@ietf.org Content-Type: multipart/alternative; boundary=047d7b66fa516e099c04cde2b68f Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 07:36:38 -0000 --047d7b66fa516e099c04cde2b68f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas, Thanks for your comments. Please see in-line: On Wed, Nov 7, 2012 at 1:57 AM, Zuniga, Juan Carlos < JuanCarlos.Zuniga@interdigital.com> wrote: > > > > -----Original Message----- > > From: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de] > > Sent: Tuesday, November 06, 2012 6:33 PM > > To: Zuniga, Juan Carlos > > Cc: multimob@ietf.org > > Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob- > > pmipv6-ropt > > > > Hi Juan Carlos, > > > > I was just browsing over the ropt draft and would like to add some > > comments that relate to my previous comments given a year ago (see > > below). > > > > The status of the current document: > > > > * Section 3.5 "PMIPv6 enhancements" is now out, so the section 3 has > > returned to informational content. > The document has been restructured as per the last presentation at IETF84. There is no section 3.5 in the last two versions, so if you refer to the current document please refer to version 02. > > > > * IPv4 compatibility: You have added a section that simply points to > > RFC 6224 - however, I don't think situations are exactly comparable. > > RFC > > 6224 relies on the GRE-tunnel infrastructure MN <-> MAG <-> LMA. This > > is > > not true for the MTMA, which does not have MN-specific state. I don't > > think it's a big issue, but currently the draft is not sound. > Indeed the MTMA does not have an MN-soecific state, so we will add text to clarify the differences. > > > > * Section 4.1. "Extensions to Binding Update List Data Structure" is > > completely unclear ... seems not informational. > This was discussed at the last meeting and it was clarified that we are not restricted by the charter, and that the status of the document could be changed down the process. Please take a look at the minutes from IETF84 and let's not have this discussion again. > > > > * Section 4.3 - Direct routing remains nebulous and severely lacks > > content. I should pointer to the discussion of direct routing for > > sources http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-02 > > - using the different PIM protocols in a mobility regime is by no means > > so trivial. > This is one of the options described, so we can discuss if there is a better option to achieve the same functionality in a better way. > > > > * Section 5. defines new "Dynamic IP Multicast Selector Option" ... > > this is out of scope for informational documents. > Please see comment from section 4.1 above > > > > Best regards, > > > > Thomas > > > > On 09.12.2011 18:59, Thomas C. Schmidt wrote: > > > Hi all, > > > > > > some feedback: > > > > > > In general, I support adopting this document as a WG item - it > > > presents two valid deployment scenarios. But I guess, the intended > > > status should be informational, as this is just presenting deployment > > > advice (I know, currently the document does more ...). > > > > > > We've been discussing the two solutions (Multicast-Tunnelendpoint, > > > direct routing) for quite a while and we should come to conclusions > > ... > > > on the current document I only had a very brief look (apologies!). > > > > > > Here are three comments: > > > > > > 1.) On the quick run, I cannot see what Section 3.5 "PMIPv6 > > > enhancements" really is needed for. I know, I should re-read this (no > > > time now), still the MTM approach should work without protocol > > > modifications, I guess. > > > > > > 2.) There should be a section / solution on IPv4 compatibility > > > (including address collisions ...) as needed for PMIPv6. > > > > > > 3.) The direct routing section (4) is still rather superficial. It > > > should explain in detail how to deploy protocols, e.g., PIM-SM in the > > > presence of these PMIP tunnels ... just to avoid the confusion that > > has > > > been evident on this list since Quebec ;) . > > > > > > That's only for a quick feedback, > > > > > > Thomas > > > > > > > > > > > > On 08.12.2011 14:53, Behcet Sarikaya wrote: > > >> Hello all, > > >> There was consensus on the tunnel convergence solution draft in > > >> Taipei. > > >> This mail is to confirm the consensus. > > >> > > >> > > >> This document can be found at: > > >> http://tools.ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt > > >> > > >> This mail starts a WG adoption call on this draft. > > >> > > >> The intended status for this document is proposed standard. > > >> If adopted, the draft will be named: > > >> > > >> draft-ietf-multimob-pmipv6-tunnel-convergence. > > >> > > >> Please your comments by December 15, 2011. > > >> > > >> > > >> Chairs > > >> _______________________________________________ > > >> 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 T= or > > 7 =B0 > > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, > > Germany =B0 > > =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875- > > 8452 =B0 > > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875- > > 8409 =B0 > --047d7b66fa516e099c04cde2b68f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas,

Thanks for your comments. Please see in-line:


On Wed, Nov 7, 2012 a= t 1:57 AM, Zuniga, Juan Carlos <JuanCarlos.Zuniga@interdi= gital.com> wrote:


> -----Original Message-----
> From: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de]
> Sent: Tuesday, November 06, 2012 6:33 PM
> To: Zuniga, Juan Carlos
> Cc: multimob@ietf.org
> Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-
> pmipv6-ropt
>
> Hi Juan Carlos,
>
> I was just browsing over the ropt draft and would like to add some
> comments that relate to my previous comments given a year ago (see
> below).
>
> The status of the current document:
>
> =A0 * Section 3.5 =A0"PMIPv6 enhancements" is now out, so th= e section 3 has
> returned to informational content.
The document h= as been restructured as per the last presentation at IETF84. There is no se= ction 3.5 in the last two versions, so if you refer to the current document= please refer to version 02.
>
> =A0 * IPv4 compatibility: You have added a section that simply points = to
> RFC 6224 - however, I don't think situations are exactly comparabl= e.
> RFC
> 6224 relies on the GRE-tunnel infrastructure MN <-> MAG <->= ; LMA. This
> is
> not true for the MTMA, which does not have MN-specific state. I don= 9;t
> think it's a big issue, but currently the draft is not sound.
<= /blockquote>
Indeed the MTMA does not have an MN-soecific state, so we = will add text to clarify the differences.
>
> =A0 * Section 4.1. "Extensions to Binding Update List Data Struct= ure" is
> completely unclear ... seems not informational.
T= his was discussed at the last meeting and it was clarified that we are not = restricted by the charter, and that the status of the document could be cha= nged down the process. Please take a look at the minutes from IETF84 and le= t's not have this discussion again.
>
> =A0 * Section 4.3 - Direct routing remains nebulous and severely lacks=
> content. I should pointer to the discussion of direct routing for
> sources http://tools.ietf.org/html/draft-ietf-multi= mob-pmipv6-source-02
> - using the different PIM protocols in a mobility regime is by no mean= s
> so trivial.
This is one of the options described,= so we can discuss if there is a better option to achieve the same function= ality in a better way.
>
> =A0 * Section 5. defines new "Dynamic IP Multicast Selector Optio= n" ...
> this is out of scope for informational documents.
Please see comment from section 4.1 above
>
> Best regards,
>
> Thomas
>
> On 09.12.2011 18:59, Thomas C. Schmidt wrote:
> > Hi all,
> >
> > some feedback:
> >
> > =A0 In general, I support adopting this document as a WG item - i= t
> > presents two valid deployment scenarios. But I guess, the intende= d
> > status should be informational, as this is just presenting deploy= ment
> > advice (I know, currently the document does more ...).
> >
> > =A0 We've been discussing the two solutions (Multicast-Tunnel= endpoint,
> > direct routing) for quite a while and we should come to conclusio= ns
> ...
> > on the current document I only had a very brief look (apologies!)= .
> >
> > =A0 Here are three comments:
> >
> > =A0 1.) On the quick run, I cannot see what Section 3.5 =A0"= PMIPv6
> > enhancements" really is needed for. I know, I should re-read= this (no
> > time now), still the MTM approach should work without protocol > > modifications, I guess.
> >
> > =A0 2.) There should be a section / solution on IPv4 compatibilit= y
> > (including address collisions ...) as needed for PMIPv6.
> >
> > =A0 3.) The direct routing section (4) is still rather superficia= l. It
> > should explain in detail how to deploy protocols, e.g., PIM-SM in= the
> > presence of these PMIP tunnels ... just to avoid the confusion th= at
> has
> > been evident on this list since Quebec ;) .
> >
> > That's only for a quick feedback,
> >
> > Thomas
> >
> >
> >
> > On 08.12.2011 14:53, Behcet Sarikaya wrote:
> >> Hello all,
> >> =A0 =A0There was consensus on the tunnel convergence solution= draft in
> >> Taipei.
> >> =A0 This mail is to confirm the consensus.
> >>
> >>
> >> This document can be found at:
> >> http://tools.ietf.org/id/draft-zuniga-mu= ltimob-pmipv6-ropt-01.txt
> >>
> >> This mail starts a WG adoption call on this draft.
> >>
> >> The intended status for this document is proposed standard. > >> If adopted, the draft will be named:
> >>
> >> draft-ietf-multimob-pmipv6-tunnel-convergence.
> >>
> >> Please your comments by December 15, 2011.
> >>
> >>
> >> Chairs
> >> _______________________________________________
> >> 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= ,
> Germany =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" value=3D"+494042875">+49-40-42875-
> 8409 =B0

--047d7b66fa516e099c04cde2b68f-- From sfigueiredo@av.it.pt Wed Nov 7 07:37:45 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BDF21F8C03 for ; Wed, 7 Nov 2012 07:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRbxeZxXC7ua for ; Wed, 7 Nov 2012 07:37:40 -0800 (PST) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id E942C21F8C10 for ; Wed, 7 Nov 2012 07:37:37 -0800 (PST) Received: from [193.136.93.29] (account sfigueiredo@av.it.pt [193.136.93.29] verified) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 66946549 for multimob@ietf.org; Wed, 07 Nov 2012 15:37:30 +0000 Message-ID: <509A803A.1040007@av.it.pt> Date: Wed, 07 Nov 2012 15:37:30 +0000 From: =?ISO-8859-1?Q?S=E9rgio_Figueiredo?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [multimob] Multicast router operation in MAGs in draft-asaeda-multimob-pmip6-extension-11 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:37:45 -0000 Hi Hitoshi, Pierrick, I have 2 questions: 1) how is the operation of MAGs using a M-Tunnel different from a MR deployed in a MAG using MTMA mode? I didn't go through both drafts in detail, so I may be missing something.. 2) The second issue is more specific and is related to the correct operation of your proposal (which I would sayz also applies to section 4.3 of "Multicast Mobility Routing Optimizations for Proxy Mobile IPv6"). It is said in the draft that "The MAG selects only one upstream interface (either M-Tunnel interface or physical interface) for a multicast channel by the Reverse Path Forwarding (RPF) algorithm." It is correct that RPF will lead to the selection of a single interface for any multicast channel. Although, the M-Tunnel will not be selected following RPF unless one of two options is followed: 1) a specific route entry to the RP (RPT) or to the source (SPT) exists in the RIB, and it "points to" the tunnel interface; - I assume such a tunnel won't be running a routing protocol like OSPFv3, so I find this case very improbable / impossible (?) 2) MRIB is (manually) configured with an entry stating that the RP's (or source's) prefix is accessed via the M-tunnel; - in RFC4601 it is stated regarding MRIB that "The routes in this table may be taken directly from the unicast routing table, or they may be different and provided by a separate routing protocol such as MBGP". In my opinion, this gives space to feeding MRIBs from MAGs in a "novel" way for PMIPv6 environments.. Please correct me if any of my conclusions / observations are wrong, but my main point is, the exact way how the MRIB is filled should be described, as it is crucial to the correct operation of the proposal. Best regards, Sérgio From waehlisch@ieee.org Wed Nov 7 09:22:19 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B17421F8C23 for ; Wed, 7 Nov 2012 09:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+UaM2ilmlJh for ; Wed, 7 Nov 2012 09:22:18 -0800 (PST) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) by ietfa.amsl.com (Postfix) with ESMTP id 3956421F8C20 for ; Wed, 7 Nov 2012 09:22:18 -0800 (PST) Envelope-to: multimob@ietf.org Received: from dhcp-9335.meeting.ietf.org ([130.129.11.53] helo=mw-PC.meeting.ietf.org) by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TW9KS-000DiS-ID for multimob@ietf.org; Wed, 07 Nov 2012 18:22:16 +0100 Date: Wed, 7 Nov 2012 12:22:04 -0500 (Eastern Normalzeit) From: Matthias Waehlisch To: multimob@ietf.org Message-ID: X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Subject: [multimob] Reference to Magma WG X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:22:19 -0000 Hi Hitoshi, regarding your comment about the Magma WG: Please, could you send a pointer the corresponding IETF proceedings/minutes. Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From JuanCarlos.Zuniga@InterDigital.com Wed Nov 7 09:26:41 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB84021F8C33 for ; Wed, 7 Nov 2012 09:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5GTOjxkVi5A for ; Wed, 7 Nov 2012 09:26:41 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDE721F8C27 for ; Wed, 7 Nov 2012 09:26:41 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Nov 2012 09:46:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDBCF6.A519D850" Date: Wed, 7 Nov 2012 09:46:17 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: test (pls ignore) Thread-Index: Ac289qSc81bGVhsWQ2qkzpuPFESl8w== From: "Zuniga, Juan Carlos" To: X-OriginalArrivalTime: 07 Nov 2012 14:46:18.0033 (UTC) FILETIME=[A507A210:01CDBCF6] Subject: [multimob] test (pls ignore) X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:26:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDBCF6.A519D850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just testing if reverse DNS is now working for my postings. Please ignore. =20 Regards, =20 Juan Carlos=20 ------_=_NextPart_001_01CDBCF6.A519D850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just = testing if reverse DNS is now working for my postings. Please = ignore.

 

Regards,

 

Juan Carlos =

------_=_NextPart_001_01CDBCF6.A519D850-- From sarikaya2012@gmail.com Wed Nov 7 10:43:45 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A095F21F8B54 for ; Wed, 7 Nov 2012 10:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbPoqD7+wX1W for ; Wed, 7 Nov 2012 10:43:44 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A894F21F8C8A for ; Wed, 7 Nov 2012 10:43:44 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so3230786iec.31 for ; Wed, 07 Nov 2012 10:43:44 -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:cc :content-type; bh=WwKe+iMHzX8bCdkbtZ3SFdyCHmIU4F4VZUBLYLsswc4=; b=pe5DXhmr+PJX6n6kqhqlTnkEqpI9tOYUpYHvfpBqhqMHRYc1nS45S4cXGDN0U4CVeu tBDoViWHmgXnUlUo1DJJ9VlnMu6/CiiiQfALDFTKh9uzbGQ3rsjyRQMHhmbTXdMZpp5i Tp+OwdDBG1oK1xFUHz3OIAh4P56C6iIRc7XQveIC6AM+GACqRpqLDR69HbiTl4Gzr6Qy dNJAPJEUdvN4tdlTrF1us/RpvlJv7nKPfI9FDMnZGN+qJQ7JuGSa5P8aIUOFbcLEg47O Ny1Gch6/iNPocG7CT/rjDHSz/NSJhJNZV1MNZ4yS6VREB+/pwQmSb5dV9NMyDleUPOPi Xcfg== MIME-Version: 1.0 Received: by 10.50.57.225 with SMTP id l1mr3014265igq.37.1352313824395; Wed, 07 Nov 2012 10:43:44 -0800 (PST) Received: by 10.231.85.26 with HTTP; Wed, 7 Nov 2012 10:43:44 -0800 (PST) Date: Wed, 7 Nov 2012 12:43:44 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [multimob] Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:43:45 -0000 Hi all, I posted the minutes at: http://www.ietf.org/proceedings/85/minutes/minutes-85-multimob Many thanks to Akbar for taking the minutes. Regards, Behcet From sarikaya2012@gmail.com Thu Nov 8 06:55:41 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4439B21F855E for ; Thu, 8 Nov 2012 06:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L69o7XZnoXdL for ; Thu, 8 Nov 2012 06:55:40 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE0EB21F8419 for ; Thu, 8 Nov 2012 06:55:40 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so2228083iak.31 for ; Thu, 08 Nov 2012 06:55:40 -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:cc :content-type; bh=QqMBqDAYjM6KGSfGiTshm4eaYgjV+PLswnI7nu7zD5I=; b=Shut6KC62mU0Q5V+7dIuOCGWmdo4BdvtKNW1zR7yclcEaj1qlwjqrKUI1PQl2IB9Pg 7yvsO3LNfR9d8K12EFbNnQCS6JM1bxMETM7AZIFD9TdaRC9IxAwS3aEXaZ/o4tBPFntN sIdwhYGYdm+fmivd5e9RbhuqJkvkssHz+zsoC4fLJXfmkMClVjxaW/2pPVM1QyPh80g/ Pvu5HnT3WKHgTdcLQNNUDlEJ03H98hGPGZ4T7G+lrm51W1hHomjmsAeGKsVx7vyi8KhE bNA0DEDePU4lKCBY/6LyqM9jOHoZQKk50gGiAfP2tlgYUr93ZaQNRu3FYWNrtNeTHSA4 Tw6w== MIME-Version: 1.0 Received: by 10.42.147.74 with SMTP id m10mr7299062icv.0.1352386540402; Thu, 08 Nov 2012 06:55:40 -0800 (PST) Received: by 10.231.85.26 with HTTP; Thu, 8 Nov 2012 06:55:40 -0800 (PST) Date: Thu, 8 Nov 2012 08:55:40 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [multimob] Minutes revised X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:55:41 -0000 Posted revised minutes. Thanks Matthias. > Hi all, > > I posted the minutes at: > > http://www.ietf.org/proceedings/85/minutes/minutes-85-multimob > > Many thanks to Akbar for taking the minutes. > > Regards, > > Behcet From sarikaya2012@gmail.com Thu Nov 8 07:21:12 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8F621F887F for ; Thu, 8 Nov 2012 07:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XP66e1tN1kHL for ; Thu, 8 Nov 2012 07:21:11 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4436B21F878E for ; Thu, 8 Nov 2012 07:21:11 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so2249825iak.31 for ; Thu, 08 Nov 2012 07:21:10 -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:content-type; bh=NgEcimr2MlH7AC3CrfpZbuFfmvy5Y0c9pvX4yxXDLpQ=; b=AMG6KyNUjWDFZDuDXD7erwu2VSuI2aco6TYcGcmKw1yC3fOqQelp3CmLkvseKy1K/e o1tk6H3sVbuYks0Met9Ro2QXJIs/CZm8wfverdt7qJ21KoIjgAZ+IslAuwb5IxDgg6Zr 74WftRy9EOipGTc74tW/hOn8VacwH+DGI3RCc0ZHplDuxuvd1VapNgahTCs135NhjPf/ YVOsPe2N8/JKC3aR3ZeWk32CF+12wpnSSthDQmcZm6v2FnbEd80uax0dudnPt63Xy2jj 7U0WycFST4+IBGCjV6pIgIo725faa529xJj5q1I2Ix5KPKAv9GKe/OGJej8uXdg6k52W DL8w== MIME-Version: 1.0 Received: by 10.50.173.37 with SMTP id bh5mr8470449igc.45.1352388070645; Thu, 08 Nov 2012 07:21:10 -0800 (PST) Received: by 10.231.85.26 with HTTP; Thu, 8 Nov 2012 07:21:10 -0800 (PST) In-Reply-To: <20121108.101140.115367609.asaeda@sfc.wide.ad.jp> References: <20121108.101140.115367609.asaeda@sfc.wide.ad.jp> Date: Thu, 8 Nov 2012 09:21:10 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org, Hitoshi Asaeda Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [multimob] Minutes revised X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:21:12 -0000 Rev 02 of the minutes has been posted. Thanks Hitoshi. From prvs=6565d6a3d=schmidt@informatik.haw-hamburg.de Mon Nov 12 14:29:05 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3146D21F8773 for ; Mon, 12 Nov 2012 14:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuvdgLm+pwI7 for ; Mon, 12 Nov 2012 14:29:04 -0800 (PST) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD1121F874D for ; Mon, 12 Nov 2012 14:28:56 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoIAHl3oVCNFh5K/2dsb2JhbABEFsNMgQEHglcBBUA9FhgDAgECAUsKAwgBAReHcweYQqEzkAOCXAOXGIRPhUqFDoJiDg Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 12 Nov 2012 23:28:56 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id F0504104DABC for ; Mon, 12 Nov 2012 23:28:55 +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 31014-06 for ; Mon, 12 Nov 2012 23:28:55 +0100 (CET) Received: from [192.168.178.36] (g231108188.adsl.alicedsl.de [92.231.108.188]) (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 7AA22107B96A for ; Mon, 12 Nov 2012 23:28:55 +0100 (CET) Message-ID: <50A17826.5070109@informatik.haw-hamburg.de> Date: Mon, 12 Nov 2012 23:28:54 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "multimob@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Subject: [multimob] Fast Handover Solutions X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:29:05 -0000 Hi all, after the - somewhat uninformed discussion at IETF85 - chairs asked me to restate requirements of a "fast handover solution" for Multicast Mobility. Here they are: (i) Handover should be fast (this is only true for a direct pMAG/AR to nMAG/AR solution such as http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast). (ii) Multicast handover should be fully synchronized with unicast handover (otherwise unicast and multicast states diverge as is a well-known issue for the RAMS-approach, i.e., https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). (iii) Multicast handover solutions should tightly integrate with unicast handover (only http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast integrates with PFMIPv6 and FMIPv6). (iv) Handover management should reuse standard mobility and multicast protocol operations for easy implementation and deployment (http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast introduced the use of standard IGMP/MLD records for context description in transfer, which has been copied several times). (v) Multicast handover management should integrate ASM and SSM, as well as IPv4 (IGMP) and IPv6 (MLD), which is only provided by http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast. Based on these facts, chairs and AD proclaimed to re-decide on future paths for Multimob fast handover solutions. Cheers, 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 cjbc@it.uc3m.es Thu Nov 15 09:56:17 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0BF21F88A9 for ; Thu, 15 Nov 2012 09:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1SCHXq9YtIk for ; Thu, 15 Nov 2012 09:56:14 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6C521F8896 for ; Thu, 15 Nov 2012 09:56:13 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id C397476B2B2; Thu, 15 Nov 2012 18:56:11 +0100 (CET) Message-ID: <1353002171.5573.53.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Thomas C. Schmidt" Date: Thu, 15 Nov 2012 18:56:11 +0100 In-Reply-To: <50A17826.5070109@informatik.haw-hamburg.de> References: <50A17826.5070109@informatik.haw-hamburg.de> Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-fj4hO8NttcoLHqP8llPf" X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19370.001 X-TM-AS-Result: No--31.400-7.0-31-1 X-imss-scan-details: No--31.400-7.0-31-1 Cc: "multimob@ietf.org" Subject: Re: [multimob] Fast Handover Solutions X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:56:17 -0000 --=-fj4hO8NttcoLHqP8llPf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thomas, all, Please see some comments inline below. On Mon, 2012-11-12 at 23:28 +0100, Thomas C. Schmidt wrote: > Hi all, >=20 > after the - somewhat uninformed discussion at IETF85 - chairs asked me= =20 > to restate requirements of a "fast handover solution" for Multicast=20 > Mobility. I don't recall the chairs asking you to restate the requirements of a "fast handover solution", and the minutes do not reflect that either. Our AD asked the WG to document the requirements of the different solutions the WG is working on, as well as the feedback obtained from operators interested in multimob work. Actually, the WG already has a WG document for the fast handover solution milestone, and during initial discussions and the adoption process, we did have discussions on different aspects of how a fast handover solution should operate and the different requirements it should meet. There have been several reviews of the WG document and it captures feedback from the WG. >=20 > Here they are: This list, IMHO, is not complete. For example, one critical aspect that has been discussed several times is how generic the solution is and what requirements it imposes on the different involved entities, as for example the need of layer-2 triggers on the mobile node. >=20 > (i) Handover should be fast (this is only true for a direct pMAG/AR to= =20 > nMAG/AR solution such as=20 > http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicas= t). The handover speed will highly depend on the network topology in place. It cannot be generally stated that direct communication will always be faster than MAG to LMA communication. In fact, taking into account typical operative networks, an strict hierarchical topology is commonly deployed where the communication among different elements located in different access networks pass through central elements, using an star topology. Considering that a MAG could be able to serve a huge number of radio accesses, the more logical trend could be to deploy separated MAGs, without direct connectivity capabilities. Additionally, as previously discussed on this mailing list, you should note that the reactive case for FPMIPv6 is extremely harmful from the multicast handover delay perspective, as it needs to firstly register the MN and resolve the MLD Query process of RFC6224 to trigger the reactive mechanism afterwards. There is for sure no improvement regarding RFC6224. Furthermore, the dependency on the radio part (for layer-2 trigger capabilities) definitely limits the potential benefits that your proposal could provide. >=20 > (ii) Multicast handover should be fully synchronized with unicast=20 > handover (otherwise unicast and multicast states diverge as is a=20 > well-known issue for the RAMS-approach, i.e.,=20 > https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). >=20 The adopted WG document draft-ietf-multimob-fast-handover (previously aka RAMS, now SIAL) is totally synchronized with the unicast handover, up to the point that it is triggered by the registration and/or de-registration messages of the unicast handover. It is difficult to achieve a better integration. In the proactive case, the de-registration message for unicast handover sent by the pMAG conveys the multicast membership subscription context for the moving MN. In the reactive case, the registration message for the MN attaching to the nMAG triggers the process, and the response to the registration PBU conveys the multicast membership subscription context. Do you really think these are not synchronized processes? BTW, what is the "well-known" issue you refer to? > (iii) Multicast handover solutions should tightly integrate with=20 > unicast handover (only=20 > http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicas= t=20 > integrates with PFMIPv6 and FMIPv6). >=20 The key point here is to be *integrated* with PMIPv6 in a *general* way. The integration of SIAL with PMIPv6 is ensured as described above. Furthermore, it is general because it does not impose the necessity of additional layer-2 capabilities in the MN to work. This does not happen with other solutions, including yours. Additionally, this has been discussed already in the WG. Several individuals, such as Marco, expressed that unicast and multicast handovers have different considerations. The WG consensus was to not to specify in the adopted document a solution bound to a unicast handover optimization solution. > (iv) Handover management should reuse standard mobility and multicast= =20 > protocol operations for easy implementation and deployment=20 > (http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multica= st=20 > introduced the use of standard IGMP/MLD records for context description= =20 > in transfer, which has been copied several times). draft-ietf-multimob-fast-handover incorporated the use of the standard multicast address record format as result of the WG feedback. >=20 > (v) Multicast handover management should integrate ASM and SSM, as=20 > well as IPv4 (IGMP) and IPv6 (MLD), which is only provided by=20 > http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicas= t. Since the SIAL solution deals with multicast membership subscription context transfer, no issues relate to ASM and SSM. Regarding the IPv4 treatment, we thank you for pointing this out and this is going to be addressed in the next revision of the document, as we discussed during the Atlanta meeting. We don't foresee any significant issue on adding that support, and we of course welcome any contribution from you or any other WG member on this aspect. >=20 > Based on these facts, chairs and AD proclaimed to re-decide on future=20 > paths for Multimob fast handover solutions. Again, based on what I recall, that seems to match what is captured in the minutes, what was discussed is that the AD would check with the chairs the process of the adoption call of draft-schmidt-multimob-fmipv6-pfmipv6-multicast. I don't quite see how a formal process revision (decision of the chairs on a WG adoption document) relates with your e-mail. Thanks, Carlos >=20 > Cheers, >=20 > Thomas --=20 Carlos Jes=C3=BAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-fj4hO8NttcoLHqP8llPf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlClLLsACgkQNdy6TdFwT2dGtwCg0LCpbGYvn1StqWGSyLuMbaUu LVAAoMYtklos3ql3RiHVNTCgQyNYa9Rg =GZ1s -----END PGP SIGNATURE----- --=-fj4hO8NttcoLHqP8llPf-- From lmcm@tid.es Thu Nov 15 10:18:31 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D491D21F8475 for ; Thu, 15 Nov 2012 10:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVlNXkzwLVvT for ; Thu, 15 Nov 2012 10:18:25 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 43E8621F8976 for ; Thu, 15 Nov 2012 10:18:23 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MDJ006C1K6KV9@tid.hi.inet> for multimob@ietf.org; Thu, 15 Nov 2012 19:18:21 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 33.2E.05494.DE135A05; Thu, 15 Nov 2012 19:18:21 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MDJ006C8K6KV9@tid.hi.inet> for multimob@ietf.org; Thu, 15 Nov 2012 19:18:21 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.64]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0318.004; Thu, 15 Nov 2012 19:17:56 +0100 Date: Thu, 15 Nov 2012 18:18:19 +0000 From: LUIS MIGUEL CONTRERAS MURILLO X-Originating-IP: [10.95.64.115] To: "multimob@ietf.org" Message-id: <823234EF5C7C334998D973D822FF801B1EDB6325@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_VjwVQfu9xawqThtiDwpPLQ)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: Re: [multimob] Fast Handover Solutions Thread-index: Ac3DW52oJ+u9aTMfTz+vbRAj7Lj2ug== X-AuditID: 0a5f4e69-b7fc06d000001576-b3-50a531ed0e77 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA2WTf0xTVxTHc15fy7PpI5dS5NjhNI0mZswKhkXmNvCPuWzRLf1j2ZJFo8/w aJ8rrfaBgosOnQspGmSTTnyDCq7VKC5a508G/lGXuQ0z2AjxFysoioE5BN2MbqTZe+8WJfG/ z7nne7/nnnPv5QzWRJqdk3zlYsAneB0mM2te817+wr/yo668yAFLYeNEHbsM3o5EnjAu+Mj8 eonolTaJgUVFa82e0MCHG/rboPLr0DVDNYyGoRZmcEgKsOVqmKU8E3sSx00aW8kZwO4aL+X/ AP9p+rgWzCp/Bbjn4CVdxJL52DzYZNTYRPJROf+lyhyXSRZhsm4F9ZyLk78O6f42kov3RiYZ jQ2kFCe6+/R1nqzAG492pzgDH+9NsFTjxv11TwyUs7Hp3y/0UkBm45HuLqCeBdg+Npzyd2Lw 4WMjrWvDm791mShn4chQ0lgPNmVaCWVaCWVaCcp+/DncltI48WqowUQ5Fw+1/pnSL8TGZJx9 fj0HvwsFQVHHZSCfA97a94NJmZrd7c5zLA0+Y/Dv++Npij7hk4CtzVk0MQE4vidopEEIsGH7 xdT+E4BXdh9JBX2AsZow0KAdsH7XwdSeNgabB07rjZjISkz2NemHtJHX8PLlSUZRr0g78HjH KuXZbVFFHrafvpdGeTFe/D6ht5RJivHKt2dBmbr00E9AR1mIoyP1LO2hEB8mehiNLWQp/th7 LE2zt5BKbKk20eVPcO+NXmiBlUdhprwuILk95WWC5HXnLXZ6JKfkE8tPAn3U0jk4fH5eHAgH DgtfXxRxWY3CJrmqLA6zOMaRxS9zRl3W9HX+kiqPIHvWBCq8ohyHeWpnt0609YCd9fl9osPG v/OiquNLhKotYsA/JcvhOAfyA3lqKiMgusXKUsmr/qmpNMPNiANyFnX7oKbh5Q1CmSy5af4X mM+deVB7G6x6DXs236OJiCbyVPie+oxCtnr4TH6blrWon/apw6hqzqjmp3Iimnm58CxlrwbD W6VSxfpvmN5HS6Iv7JA7ooWx/SP9cT7o32bHd+/0mscvNCyvfnNfUTI2y7rZeqm/M9ffaCze OtbdlZ2+/PfwB+8/eKX00zkdyUPRo4NDW4d8W1bfnTM2XLwrWLAxNrfqVOPLsWuhzvU1f2Rd P5C+s7Vr6eEFkzvuZNw/e2Hn8BuvurY7WNkj5L9kCMjC/7RS81lxBAAA Subject: Re: [multimob] Fast Handover Solutions X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:18:32 -0000 --Boundary_(ID_VjwVQfu9xawqThtiDwpPLQ) Content-type: multipart/alternative; boundary="Boundary_(ID_uC7LUFDYDqHpG++zlilUVQ)" --Boundary_(ID_uC7LUFDYDqHpG++zlilUVQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi all, One additional comment on this. It would be worthy to remark that a generic solution, non-dependent on laye= r-2 capabilities, has been adopted to avoid partial solutions not applicabl= e to all the MNs in a network. This solution provides a uniform performance= as it does not depend on the underlying radio particularities (framing, re= liability, contention, etc) nor the multicast protocols specificities (like= the IGMP/MLD timers, conceived for very distinct environment to the one ad= dressed by PMIPv6). From an operator point of view, this predictability eas= ies the planning of the access network and the expected performance guarant= ees to be delivered to the end user across all the access points in the net= work, especially for the upcoming heterogeneous access network scenarios. T= he unpredictability impacts on the usability of a protocol. Best regards, Luis ________________________________ Luis M. Contreras Technology / Global CTO / Telef=F3nica Efficiency Projects / Telef=F3nica I+D Distrito Telef=F3nica, Edificio Sur 3, Planta 3 28050 Madrid Espa=F1a / Spain lmcm@tid.es ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_uC7LUFDYDqHpG++zlilUVQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi all,

 

One additional comment on this.

 

It would be worthy to remark that a generic solution= , non-dependent on layer-2 capabilities, has been adopted to avoid partial = solutions not applicable to all the MNs in a network. This solution provide= s a uniform performance as it does not depend on the underlying radio particularities (framing, reliability, = contention, etc) nor the multicast protocols specificities (like the IGMP/M= LD timers, conceived for very distinct environment to the one addressed by = PMIPv6). From an operator point of view, this predictability easies the planning of the access network and= the expected performance guarantees to be delivered to the end user across= all the access points in the network, especially for the upcoming heteroge= neous access network scenarios. The unpredictability impacts on the usability of a protocol.

 

Best regards,

 

Luis

________________________________

Luis M. Contreras

 

Technology / Global CTO / Telef=F3= nica

Efficiency Projects / Telef=F3nica= I+D

 

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

28050 Madrid

Espa=F1a / Spain

 

lmcm@tid.es

 



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_uC7LUFDYDqHpG++zlilUVQ)-- --Boundary_(ID_VjwVQfu9xawqThtiDwpPLQ) Content-type: message/rfc822 Content-disposition: attachment; creation-date="Thu, 15 Nov 2012 18:18:19 GMT"; modification-date="Thu, 15 Nov 2012 18:18:19 GMT" Received: from tid (10.95.64.115) by ex10-htcas5-mad.hi.inet (10.95.73.86) with Microsoft SMTP Server id 14.2.318.4; Thu, 15 Nov 2012 18:56:26 +0100 Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MDJ004HEJ62ET@tid.hi.inet> for lmcm@tid.es; Thu, 15 Nov 2012 18:56:26 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id CB.78.03143.ACC25A05; Thu, 15 Nov 2012 18:56:26 +0100 (CET) Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MDJ004HAJ60ET@tid.hi.inet> for lmcm@tid.es; Thu, 15 Nov 2012 18:56:26 +0100 (MET) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0F121F8A01; Thu, 15 Nov 2012 09:56:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0BF21F88A9 for ; Thu, 15 Nov 2012 09:56:16 -0800 (PST) Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1SCHXq9YtIk for ; Thu, 15 Nov 2012 09:56:14 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6C521F8896 for ; Thu, 15 Nov 2012 09:56:13 -0800 (PST) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id C397476B2B2; Thu, 15 Nov 2012 18:56:11 +0100 (CET) Date: Thu, 15 Nov 2012 17:56:11 +0000 From: =?utf-8?B?Q2FybG9zIEplc8O6cyBCZXJuYXJkb3MgQ2Fubw==?= Subject: Re: [multimob] Fast Handover Solutions In-reply-to: <50A17826.5070109@informatik.haw-hamburg.de> Sender: "multimob-bounces@ietf.org" To: "Thomas C. Schmidt" Cc: "multimob@ietf.org" Errors-to: multimob-bounces@ietf.org Reply-to: "cjbc@it.uc3m.es" Message-id: <1353002171.5573.53.camel@acorde.it.uc3m.es> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Jz8fRJPni6ERdpr13jS2wQ)" Content-language: es-ES X-BeenThere: multimob@ietf.org Delivered-to: multimob@ietfa.amsl.com Thread-topic: [multimob] Fast Handover Solutions Thread-index: AQHNwSVJ5n1qB46tzkCKmnyRC+8k5JfrIfCA dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1353002183; bh=P/wrySUcHpqV9NgXbHDpWADB4qb0PoZ5rHPWv/qbMZU=; h=Message-ID:From:To:Date:In-Reply-To:References:Mime-Version:Cc: Subject:Reply-To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Content-Type:Sender; b=vututoxFgB4+ClMaW457C+CP4wqBx2qMMfD3nHAu7Mc4p6F+b00eL+zaaJIhDb6aC uNmFR2FgOs7ULVe59T26HipQ+MD96WgqmArlbPbnBy6HGzzx9lQpVm0nz5MW5K1IL8 Zpvq7cmt/d5XpwsnD8qxmTmbneObHPWI+RvNMkz4= received-spf: Fail (EX10-HTCAS5-MAD.hi.inet: domain of multimob-bounces@ietf.org does not designate 10.95.64.115 as permitted sender) receiver=EX10-HTCAS5-MAD.hi.inet; client-ip=10.95.64.115; helo=tid; X-MS-Exchange-Organization-AuthSource: EX10-HTCAS5-MAD.hi.inet X-MS-Has-Attach: yes X-Auto-Response-Suppress: All X-MS-Exchange-Organization-SenderIdResult: Fail X-MS-Exchange-Organization-PRD: ietf.org X-MS-TNEF-Correlator: x-auditid: 0a5f4068-b7f746d000000c47-78-50a52ccaf687 x-brightmail-tracker: H4sIAAAAAAAAA1VTbUhTYRT27N5t17Wrr5vpcZrhWllWlhH0HUYQRSCLfgQR1h1e3Y1tyraW RkX0aRa20LSWhflRWWlmlk2jaESRJUhQSR8WJVaGREUfZlr37k6rf885z/Oc8xx4X4bSlakN DJ/v5p0OzmZUaWjN+nTN9PZpteaZ744Y5n541q5Oh+U9Q82UGdZqFmbxNsHDO2cs3qCxlnZc hryB+fl7GwbpHXAqrQjCGSSz8Ui5F2Qcg53dF1VFoGF0pBGw9di3UPEJ8OTtYkpS6Ug54KHH GaOq2sN3lHLxBHBw54FQ0Qro7bsGclGvwKqbJ1SSnyYTsbfkqFLCKrIM26qG6SJgGD2ZgcPF K6V2OJmH7YVDCgnrSRLeu3ElaI0mC/DBg1/BPkWmYtlwVTCSkpjQ96pXLceLw6fvqylpJEvm YrcvW2pHklRsaqwI3smSKPxR0k3LN8djddNvkEdm4Je6n8FkhBA8WeNXyJpEfL3HO5q++Otz hXQWTQYo7O8vDIkm4e6Xh5QynoxH6zpByoAkEusDE+R2NBa13lLLmMX7pXdVXpju+yeS758Y Mt6KbWd7KRlPwT0tg2pf6PrTpz6E+ouwoeFjyLsQmx5VgozHY0t/RUgzDSvbPqtGdt071kP/ r2FEHI9nhplK0J6DGJfFKeRY3XZOsOXMTEu1CqmCg3c3gfzgrNfgjN8UAMKAUct6F9eYdUrO 4yqwByCOURjHsoVTas26CEtuVoGVc1nXOzfZeFcATOKO143nO8FAO3IdvDGaXZEo6tgsrmAL 78wdkSUwjBHZ6ykiFeXkc/j8bMEmvvcRWsGEBwAZrWj/OFWyu/I4u0vIkfl2SDLEspslM5EI 6ybHqFf6LunnLIkPYZxBz0JYWJhOm8c77YL7f74PYsXD9GyyNEUrONyj0/vExQpxcXNCjbTY zf2lDDvAcrU8dmJZ9rOu7ztTNw7s13viXkzqqquklvj8MY/og5nJ61ZfKExZ6lFdbm57rJuX ZPJ8t80qWT42KqJ6jnGoY9/h7NiuWbrBN5D89mruLos97FKkQOKOd8Tc9hv3R6wyJWzvWXr6 ePPe90C9y8xI7KLMpS1j/LiG2dZPSuM9+UbaZeXSUiini/sDdiAdVCkEAAA= x-original-to: multimob@ietfa.amsl.com x-spam-score: -5.849 x-virus-scanned: amavisd-new at amsl.com x-spam-status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] x-spam-level: x-spam-flag: NO x-tm-as-product-ver: IMSS-7.1.0.1224-6.8.0.1017-19370.001 x-tm-as-result: No--31.400-7.0-31-1 x-imss-scan-details: No--31.400-7.0-31-1 References: <50A17826.5070109@informatik.haw-hamburg.de> X-Mailman-Version: 2.1.12 List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: List-Id: Multicast Mobility --Boundary_(ID_Jz8fRJPni6ERdpr13jS2wQ) Content-id: <98959C1B6E39D543A7D5B7BCE3FB5A76@hi.inet> Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SGkgVGhvbWFzLCBhbGwsDQoNClBsZWFzZSBzZWUgc29tZSBjb21tZW50cyBpbmxpbmUgYmVsb3cu DQoNCk9uIE1vbiwgMjAxMi0xMS0xMiBhdCAyMzoyOCArMDEwMCwgVGhvbWFzIEMuIFNjaG1pZHQg d3JvdGU6DQo+IEhpIGFsbCwNCj4NCj4gYWZ0ZXIgdGhlIC0gc29tZXdoYXQgdW5pbmZvcm1lZCBk aXNjdXNzaW9uIGF0IElFVEY4NSAtIGNoYWlycyBhc2tlZCBtZQ0KPiB0byByZXN0YXRlIHJlcXVp cmVtZW50cyBvZiBhICJmYXN0IGhhbmRvdmVyIHNvbHV0aW9uIiBmb3IgTXVsdGljYXN0DQo+IE1v YmlsaXR5Lg0KDQpJIGRvbid0IHJlY2FsbCB0aGUgY2hhaXJzIGFza2luZyB5b3UgdG8gcmVzdGF0 ZSB0aGUgcmVxdWlyZW1lbnRzIG9mIGENCiJmYXN0IGhhbmRvdmVyIHNvbHV0aW9uIiwgYW5kIHRo ZSBtaW51dGVzIGRvIG5vdCByZWZsZWN0IHRoYXQgZWl0aGVyLg0KT3VyIEFEIGFza2VkIHRoZSBX RyB0byBkb2N1bWVudCB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZSBkaWZmZXJlbnQNCnNvbHV0aW9u cyB0aGUgV0cgaXMgd29ya2luZyBvbiwgYXMgd2VsbCBhcyB0aGUgZmVlZGJhY2sgb2J0YWluZWQg ZnJvbQ0Kb3BlcmF0b3JzIGludGVyZXN0ZWQgaW4gbXVsdGltb2Igd29yay4NCg0KQWN0dWFsbHks IHRoZSBXRyBhbHJlYWR5IGhhcyBhIFdHIGRvY3VtZW50IGZvciB0aGUgZmFzdCBoYW5kb3Zlcg0K c29sdXRpb24gbWlsZXN0b25lLCBhbmQgZHVyaW5nIGluaXRpYWwgZGlzY3Vzc2lvbnMgYW5kIHRo ZSBhZG9wdGlvbg0KcHJvY2Vzcywgd2UgZGlkIGhhdmUgZGlzY3Vzc2lvbnMgb24gZGlmZmVyZW50 IGFzcGVjdHMgb2YgaG93IGEgZmFzdA0KaGFuZG92ZXIgc29sdXRpb24gc2hvdWxkIG9wZXJhdGUg YW5kIHRoZSBkaWZmZXJlbnQgcmVxdWlyZW1lbnRzIGl0DQpzaG91bGQgbWVldC4gVGhlcmUgaGF2 ZSBiZWVuIHNldmVyYWwgcmV2aWV3cyBvZiB0aGUgV0cgZG9jdW1lbnQgYW5kIGl0DQpjYXB0dXJl cyBmZWVkYmFjayBmcm9tIHRoZSBXRy4NCg0KPg0KPiBIZXJlIHRoZXkgYXJlOg0KDQpUaGlzIGxp c3QsIElNSE8sIGlzIG5vdCBjb21wbGV0ZS4gRm9yIGV4YW1wbGUsIG9uZSBjcml0aWNhbCBhc3Bl Y3QgdGhhdA0KaGFzIGJlZW4gZGlzY3Vzc2VkIHNldmVyYWwgdGltZXMgaXMgaG93IGdlbmVyaWMg dGhlIHNvbHV0aW9uIGlzIGFuZCB3aGF0DQpyZXF1aXJlbWVudHMgaXQgaW1wb3NlcyBvbiB0aGUg ZGlmZmVyZW50IGludm9sdmVkIGVudGl0aWVzLCBhcyBmb3INCmV4YW1wbGUgdGhlIG5lZWQgb2Yg bGF5ZXItMiB0cmlnZ2VycyBvbiB0aGUgbW9iaWxlIG5vZGUuDQoNCj4NCj4gICAoaSkgSGFuZG92 ZXIgc2hvdWxkIGJlIGZhc3QgKHRoaXMgaXMgb25seSB0cnVlIGZvciBhIGRpcmVjdCBwTUFHL0FS IHRvDQo+IG5NQUcvQVIgc29sdXRpb24gc3VjaCBhcw0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1zY2htaWR0LW11bHRpbW9iLWZtaXB2Ni1wZm1pcHY2LW11bHRpY2FzdCkuDQoN ClRoZSBoYW5kb3ZlciBzcGVlZCB3aWxsIGhpZ2hseSBkZXBlbmQgb24gdGhlIG5ldHdvcmsgdG9w b2xvZ3kgaW4gcGxhY2UuDQpJdCBjYW5ub3QgYmUgZ2VuZXJhbGx5IHN0YXRlZCB0aGF0IGRpcmVj dCBjb21tdW5pY2F0aW9uIHdpbGwgYWx3YXlzIGJlDQpmYXN0ZXIgdGhhbiBNQUcgdG8gTE1BIGNv bW11bmljYXRpb24uIEluIGZhY3QsIHRha2luZyBpbnRvIGFjY291bnQNCnR5cGljYWwgb3BlcmF0 aXZlIG5ldHdvcmtzLCBhbiBzdHJpY3QgaGllcmFyY2hpY2FsIHRvcG9sb2d5IGlzIGNvbW1vbmx5 DQpkZXBsb3llZCB3aGVyZSB0aGUgY29tbXVuaWNhdGlvbiBhbW9uZyBkaWZmZXJlbnQgZWxlbWVu dHMgbG9jYXRlZCBpbg0KZGlmZmVyZW50IGFjY2VzcyBuZXR3b3JrcyBwYXNzIHRocm91Z2ggY2Vu dHJhbCBlbGVtZW50cywgdXNpbmcgYW4gc3Rhcg0KdG9wb2xvZ3kuIENvbnNpZGVyaW5nIHRoYXQg YSBNQUcgY291bGQgYmUgYWJsZSB0byBzZXJ2ZSBhIGh1Z2UgbnVtYmVyIG9mDQpyYWRpbyBhY2Nl c3NlcywgdGhlIG1vcmUgbG9naWNhbCB0cmVuZCBjb3VsZCBiZSB0byBkZXBsb3kgc2VwYXJhdGVk DQpNQUdzLCB3aXRob3V0IGRpcmVjdCBjb25uZWN0aXZpdHkgY2FwYWJpbGl0aWVzLiBBZGRpdGlv bmFsbHksIGFzDQpwcmV2aW91c2x5IGRpc2N1c3NlZCBvbiB0aGlzIG1haWxpbmcgbGlzdCwgeW91 IHNob3VsZCBub3RlIHRoYXQgdGhlDQpyZWFjdGl2ZSBjYXNlIGZvciBGUE1JUHY2IGlzIGV4dHJl bWVseSBoYXJtZnVsIGZyb20gdGhlIG11bHRpY2FzdA0KaGFuZG92ZXIgZGVsYXkgcGVyc3BlY3Rp dmUsIGFzIGl0IG5lZWRzIHRvIGZpcnN0bHkgcmVnaXN0ZXIgdGhlIE1OIGFuZA0KcmVzb2x2ZSB0 aGUgTUxEIFF1ZXJ5IHByb2Nlc3Mgb2YgUkZDNjIyNCB0byB0cmlnZ2VyIHRoZSByZWFjdGl2ZQ0K bWVjaGFuaXNtIGFmdGVyd2FyZHMuIFRoZXJlIGlzIGZvciBzdXJlIG5vIGltcHJvdmVtZW50IHJl Z2FyZGluZw0KUkZDNjIyNC4gRnVydGhlcm1vcmUsIHRoZSBkZXBlbmRlbmN5IG9uIHRoZSByYWRp byBwYXJ0IChmb3IgbGF5ZXItMg0KdHJpZ2dlciBjYXBhYmlsaXRpZXMpIGRlZmluaXRlbHkgbGlt aXRzIHRoZSBwb3RlbnRpYWwgYmVuZWZpdHMgdGhhdCB5b3VyDQpwcm9wb3NhbCBjb3VsZCBwcm92 aWRlLg0KDQo+DQo+ICAgKGlpKSBNdWx0aWNhc3QgaGFuZG92ZXIgc2hvdWxkIGJlIGZ1bGx5IHN5 bmNocm9uaXplZCB3aXRoIHVuaWNhc3QNCj4gaGFuZG92ZXIgKG90aGVyd2lzZSB1bmljYXN0IGFu ZCBtdWx0aWNhc3Qgc3RhdGVzIGRpdmVyZ2UgYXMgaXMgYQ0KPiB3ZWxsLWtub3duIGlzc3VlIGZv ciB0aGUgUkFNUy1hcHByb2FjaCwgaS5lLiwNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbXVsdGltb2ItZmFzdC1oYW5kb3ZlcikuDQo+DQoNClRoZSBhZG9wdGVkIFdH IGRvY3VtZW50IGRyYWZ0LWlldGYtbXVsdGltb2ItZmFzdC1oYW5kb3ZlciAocHJldmlvdXNseQ0K YWthIFJBTVMsIG5vdyBTSUFMKSBpcyB0b3RhbGx5IHN5bmNocm9uaXplZCB3aXRoIHRoZSB1bmlj YXN0IGhhbmRvdmVyLA0KdXAgdG8gdGhlIHBvaW50IHRoYXQgaXQgaXMgdHJpZ2dlcmVkIGJ5IHRo ZSByZWdpc3RyYXRpb24gYW5kL29yDQpkZS1yZWdpc3RyYXRpb24gbWVzc2FnZXMgb2YgdGhlIHVu aWNhc3QgaGFuZG92ZXIuIEl0IGlzIGRpZmZpY3VsdCB0bw0KYWNoaWV2ZSBhIGJldHRlciBpbnRl Z3JhdGlvbi4gSW4gdGhlIHByb2FjdGl2ZSBjYXNlLCB0aGUgZGUtcmVnaXN0cmF0aW9uDQptZXNz YWdlIGZvciB1bmljYXN0IGhhbmRvdmVyIHNlbnQgYnkgdGhlIHBNQUcgY29udmV5cyB0aGUgbXVs dGljYXN0DQptZW1iZXJzaGlwIHN1YnNjcmlwdGlvbiBjb250ZXh0IGZvciB0aGUgbW92aW5nIE1O LiBJbiB0aGUgcmVhY3RpdmUgY2FzZSwNCnRoZSByZWdpc3RyYXRpb24gbWVzc2FnZSBmb3IgdGhl IE1OIGF0dGFjaGluZyB0byB0aGUgbk1BRyB0cmlnZ2VycyB0aGUNCnByb2Nlc3MsIGFuZCB0aGUg cmVzcG9uc2UgdG8gdGhlIHJlZ2lzdHJhdGlvbiBQQlUgY29udmV5cyB0aGUgbXVsdGljYXN0DQpt ZW1iZXJzaGlwIHN1YnNjcmlwdGlvbiBjb250ZXh0LiBEbyB5b3UgcmVhbGx5IHRoaW5rIHRoZXNl IGFyZSBub3QNCnN5bmNocm9uaXplZCBwcm9jZXNzZXM/DQoNCkJUVywgd2hhdCBpcyB0aGUgIndl bGwta25vd24iIGlzc3VlIHlvdSByZWZlciB0bz8NCg0KPiAgIChpaWkpIE11bHRpY2FzdCBoYW5k b3ZlciBzb2x1dGlvbnMgc2hvdWxkIHRpZ2h0bHkgaW50ZWdyYXRlIHdpdGgNCj4gdW5pY2FzdCBo YW5kb3ZlciAob25seQ0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2htaWR0 LW11bHRpbW9iLWZtaXB2Ni1wZm1pcHY2LW11bHRpY2FzdA0KPiBpbnRlZ3JhdGVzIHdpdGggUEZN SVB2NiBhbmQgRk1JUHY2KS4NCj4NCg0KVGhlIGtleSBwb2ludCBoZXJlIGlzIHRvIGJlICppbnRl Z3JhdGVkKiB3aXRoIFBNSVB2NiBpbiBhICpnZW5lcmFsKiB3YXkuDQpUaGUgaW50ZWdyYXRpb24g b2YgU0lBTCB3aXRoIFBNSVB2NiBpcyBlbnN1cmVkIGFzIGRlc2NyaWJlZCBhYm92ZS4NCkZ1cnRo ZXJtb3JlLCBpdCBpcyBnZW5lcmFsIGJlY2F1c2UgaXQgZG9lcyBub3QgaW1wb3NlIHRoZSBuZWNl c3NpdHkgb2YNCmFkZGl0aW9uYWwgbGF5ZXItMiBjYXBhYmlsaXRpZXMgaW4gdGhlIE1OIHRvIHdv cmsuIFRoaXMgZG9lcyBub3QgaGFwcGVuDQp3aXRoIG90aGVyIHNvbHV0aW9ucywgaW5jbHVkaW5n IHlvdXJzLg0KDQpBZGRpdGlvbmFsbHksIHRoaXMgaGFzIGJlZW4gZGlzY3Vzc2VkIGFscmVhZHkg aW4gdGhlIFdHLiBTZXZlcmFsDQppbmRpdmlkdWFscywgc3VjaCBhcyBNYXJjbywgZXhwcmVzc2Vk IHRoYXQgdW5pY2FzdCBhbmQgbXVsdGljYXN0DQpoYW5kb3ZlcnMgaGF2ZSBkaWZmZXJlbnQgY29u c2lkZXJhdGlvbnMuIFRoZSBXRyBjb25zZW5zdXMgd2FzIHRvIG5vdCB0bw0Kc3BlY2lmeSBpbiB0 aGUgYWRvcHRlZCBkb2N1bWVudCBhIHNvbHV0aW9uIGJvdW5kIHRvIGEgdW5pY2FzdCBoYW5kb3Zl cg0Kb3B0aW1pemF0aW9uIHNvbHV0aW9uLg0KDQo+ICAgKGl2KSBIYW5kb3ZlciBtYW5hZ2VtZW50 IHNob3VsZCByZXVzZSBzdGFuZGFyZCBtb2JpbGl0eSBhbmQgbXVsdGljYXN0DQo+IHByb3RvY29s IG9wZXJhdGlvbnMgZm9yIGVhc3kgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQNCj4gKGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjaG1pZHQtbXVsdGltb2ItZm1pcHY2LXBm bWlwdjYtbXVsdGljYXN0DQo+IGludHJvZHVjZWQgdGhlIHVzZSBvZiBzdGFuZGFyZCBJR01QL01M RCByZWNvcmRzIGZvciBjb250ZXh0IGRlc2NyaXB0aW9uDQo+IGluIHRyYW5zZmVyLCB3aGljaCBo YXMgYmVlbiBjb3BpZWQgc2V2ZXJhbCB0aW1lcykuDQoNCmRyYWZ0LWlldGYtbXVsdGltb2ItZmFz dC1oYW5kb3ZlciBpbmNvcnBvcmF0ZWQgdGhlIHVzZSBvZiB0aGUgc3RhbmRhcmQNCm11bHRpY2Fz dCBhZGRyZXNzIHJlY29yZCBmb3JtYXQgYXMgcmVzdWx0IG9mIHRoZSBXRyBmZWVkYmFjay4NCg0K Pg0KPiAgICh2KSBNdWx0aWNhc3QgaGFuZG92ZXIgbWFuYWdlbWVudCBzaG91bGQgaW50ZWdyYXRl IEFTTSBhbmQgU1NNLCBhcw0KPiB3ZWxsIGFzIElQdjQgKElHTVApIGFuZCBJUHY2IChNTEQpLCB3 aGljaCBpcyBvbmx5IHByb3ZpZGVkIGJ5DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXNjaG1pZHQtbXVsdGltb2ItZm1pcHY2LXBmbWlwdjYtbXVsdGljYXN0Lg0KDQpTaW5jZSB0 aGUgU0lBTCBzb2x1dGlvbiBkZWFscyB3aXRoIG11bHRpY2FzdCBtZW1iZXJzaGlwIHN1YnNjcmlw dGlvbg0KY29udGV4dCB0cmFuc2Zlciwgbm8gaXNzdWVzIHJlbGF0ZSB0byBBU00gYW5kIFNTTS4g UmVnYXJkaW5nIHRoZSBJUHY0DQp0cmVhdG1lbnQsIHdlIHRoYW5rIHlvdSBmb3IgcG9pbnRpbmcg dGhpcyBvdXQgYW5kIHRoaXMgaXMgZ29pbmcgdG8gYmUNCmFkZHJlc3NlZCBpbiB0aGUgbmV4dCBy ZXZpc2lvbiBvZiB0aGUgZG9jdW1lbnQsIGFzIHdlIGRpc2N1c3NlZCBkdXJpbmcNCnRoZSBBdGxh bnRhIG1lZXRpbmcuIFdlIGRvbid0IGZvcmVzZWUgYW55IHNpZ25pZmljYW50IGlzc3VlIG9uIGFk ZGluZw0KdGhhdCBzdXBwb3J0LCBhbmQgd2Ugb2YgY291cnNlIHdlbGNvbWUgYW55IGNvbnRyaWJ1 dGlvbiBmcm9tIHlvdSBvciBhbnkNCm90aGVyIFdHIG1lbWJlciBvbiB0aGlzIGFzcGVjdC4NCg0K Pg0KPiBCYXNlZCBvbiB0aGVzZSBmYWN0cywgY2hhaXJzIGFuZCBBRCBwcm9jbGFpbWVkIHRvIHJl LWRlY2lkZSBvbiBmdXR1cmUNCj4gcGF0aHMgZm9yIE11bHRpbW9iIGZhc3QgaGFuZG92ZXIgc29s dXRpb25zLg0KDQpBZ2FpbiwgYmFzZWQgb24gd2hhdCBJIHJlY2FsbCwgdGhhdCBzZWVtcyB0byBt YXRjaCB3aGF0IGlzIGNhcHR1cmVkIGluDQp0aGUgbWludXRlcywgd2hhdCB3YXMgZGlzY3Vzc2Vk IGlzIHRoYXQgdGhlIEFEIHdvdWxkIGNoZWNrIHdpdGggdGhlDQpjaGFpcnMgdGhlIHByb2Nlc3Mg b2YgdGhlIGFkb3B0aW9uIGNhbGwgb2YNCmRyYWZ0LXNjaG1pZHQtbXVsdGltb2ItZm1pcHY2LXBm bWlwdjYtbXVsdGljYXN0LiBJIGRvbid0IHF1aXRlIHNlZSBob3cgYQ0KZm9ybWFsIHByb2Nlc3Mg cmV2aXNpb24gKGRlY2lzaW9uIG9mIHRoZSBjaGFpcnMgb24gYSBXRyBhZG9wdGlvbg0KZG9jdW1l bnQpIHJlbGF0ZXMgd2l0aCB5b3VyIGUtbWFpbC4NCg0KVGhhbmtzLA0KDQpDYXJsb3MNCg0KPg0K PiBDaGVlcnMsDQo+DQo+IFRob21hcw0KDQotLQ0KQ2FybG9zIEplc8O6cyBCZXJuYXJkb3MgQ2Fu byAgaHR0cDovL3d3dy5uZXRjb20uaXQudWMzbS5lcy8NCkdQRyBGUDogRDI5QiAwQTZBIDYzOUEg QTU2MSA5M0NBICA0RDU1IDM1REMgQkE0RCBEMTcwIDRGNjcNCg0K --Boundary_(ID_Jz8fRJPni6ERdpr13jS2wQ) Content-id: <24CB0839BB234549878CD32DDBD72154@hi.inet> Content-type: application/pgp-signature; name=signature.asc Content-transfer-encoding: base64 Content-disposition: attachment; filename=signature.asc; size=205; creation-date="Thu, 15 Nov 2012 17:56:27 GMT"; modification-date="Thu, 15 Nov 2012 17:56:27 GMT" Content-description: This is a digitally signed message part.asc LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuMTIgKEdO VS9MaW51eCkNCg0KaUVZRUFCRUNBQVlGQWxDbExMc0FDZ2tRTmR5NlRkRndUMmRHdHdDZzBMQ3Bi R1l2bjFTdHFXR1N5THVNYmFVdQ0KTFZBQW9NWXRrbG9zM3FsM1JpSFZOVENnUXlOWWE5UmcNCj1H WjFzDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --Boundary_(ID_Jz8fRJPni6ERdpr13jS2wQ) Content-id: <9592FFD4240DA64AAE113315D3943350@hi.inet> Content-type: text/plain; name=ATT00001.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ATT00001.txt; size=139; creation-date="Thu, 15 Nov 2012 17:56:27 GMT"; modification-date="Thu, 15 Nov 2012 17:56:27 GMT" Content-description: ATT00001.txt _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --Boundary_(ID_Jz8fRJPni6ERdpr13jS2wQ)-- --Boundary_(ID_VjwVQfu9xawqThtiDwpPLQ)-- From prvs=65964a046=schmidt@informatik.haw-hamburg.de Thu Nov 15 11:11:03 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007E121F8875 for ; Thu, 15 Nov 2012 11:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.63 X-Spam-Level: X-Spam-Status: No, score=-101.63 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jibR72r18yAV for ; Thu, 15 Nov 2012 11:11:02 -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 6446921F8874 for ; Thu, 15 Nov 2012 11:11:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAP09pVCNFh5K/2dsb2JhbABEFoYHvCSBCIIeAQEFIw8BBTYKARAJAhgCAgUECAoLAgIJAwIBAgFFEAMBBwEBF4d2B6o0kmGBIosPGoJfgiCBEwOXGIRPhUqFDoJwgWMX Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 15 Nov 2012 20:10:59 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 6B911105418F; Thu, 15 Nov 2012 20:10:59 +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 30555-06; Thu, 15 Nov 2012 20:10:57 +0100 (CET) Received: from [10.153.164.69] (unknown [89.204.153.69]) (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 BC667105418E; Thu, 15 Nov 2012 20:10:56 +0100 (CET) Message-ID: <50A53E41.5020602@informatik.haw-hamburg.de> Date: Thu, 15 Nov 2012 20:10:57 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <50A17826.5070109@informatik.haw-hamburg.de> <1353002171.5573.53.camel@acorde.it.uc3m.es> In-Reply-To: <1353002171.5573.53.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: "multimob@ietf.org" Subject: Re: [multimob] Fast Handover Solutions + Closing Multimob X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:11:03 -0000 Hi Carlos, just a short answer: Chairs asked me in personal communication to send these requirements. For the rest: We have had lengthy discussions over months on all the subjects, on-list and off-list, mentioning all types of pro's and con's. I don't want to repeat this. We finally agreed (with chairs) off-list to adopt both drafts as experimental ... but then some people behaved differently from what they had said earlier. My view on the general situation is that there are two kinds of reasonable work for Multimob (i) Basic enabling of PMIP multicast (ii) Convincing coverage of the solution space in relevant scenarios (i) will be done by Multimob with the Base + MLD RFCs and the source solution. Ad (ii), my impression is that Multimob is not really doing a decent job. In fact, I have severe doubts that any of the work on track will be of any value to anyone. So I believe we should start thinking about closing Multimob. Cheers, Thomas On 15.11.2012 18:56, Carlos Jesús Bernardos Cano wrote: > Hi Thomas, all, > > Please see some comments inline below. > > On Mon, 2012-11-12 at 23:28 +0100, Thomas C. Schmidt wrote: >> Hi all, >> >> after the - somewhat uninformed discussion at IETF85 - chairs asked me >> to restate requirements of a "fast handover solution" for Multicast >> Mobility. > > I don't recall the chairs asking you to restate the requirements of a > "fast handover solution", and the minutes do not reflect that either. > Our AD asked the WG to document the requirements of the different > solutions the WG is working on, as well as the feedback obtained from > operators interested in multimob work. > > Actually, the WG already has a WG document for the fast handover > solution milestone, and during initial discussions and the adoption > process, we did have discussions on different aspects of how a fast > handover solution should operate and the different requirements it > should meet. There have been several reviews of the WG document and it > captures feedback from the WG. > >> >> Here they are: > > This list, IMHO, is not complete. For example, one critical aspect that > has been discussed several times is how generic the solution is and what > requirements it imposes on the different involved entities, as for > example the need of layer-2 triggers on the mobile node. > >> >> (i) Handover should be fast (this is only true for a direct pMAG/AR to >> nMAG/AR solution such as >> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast). > > The handover speed will highly depend on the network topology in place. > It cannot be generally stated that direct communication will always be > faster than MAG to LMA communication. In fact, taking into account > typical operative networks, an strict hierarchical topology is commonly > deployed where the communication among different elements located in > different access networks pass through central elements, using an star > topology. Considering that a MAG could be able to serve a huge number of > radio accesses, the more logical trend could be to deploy separated > MAGs, without direct connectivity capabilities. Additionally, as > previously discussed on this mailing list, you should note that the > reactive case for FPMIPv6 is extremely harmful from the multicast > handover delay perspective, as it needs to firstly register the MN and > resolve the MLD Query process of RFC6224 to trigger the reactive > mechanism afterwards. There is for sure no improvement regarding > RFC6224. Furthermore, the dependency on the radio part (for layer-2 > trigger capabilities) definitely limits the potential benefits that your > proposal could provide. > >> >> (ii) Multicast handover should be fully synchronized with unicast >> handover (otherwise unicast and multicast states diverge as is a >> well-known issue for the RAMS-approach, i.e., >> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). >> > > The adopted WG document draft-ietf-multimob-fast-handover (previously > aka RAMS, now SIAL) is totally synchronized with the unicast handover, > up to the point that it is triggered by the registration and/or > de-registration messages of the unicast handover. It is difficult to > achieve a better integration. In the proactive case, the de-registration > message for unicast handover sent by the pMAG conveys the multicast > membership subscription context for the moving MN. In the reactive case, > the registration message for the MN attaching to the nMAG triggers the > process, and the response to the registration PBU conveys the multicast > membership subscription context. Do you really think these are not > synchronized processes? > > BTW, what is the "well-known" issue you refer to? > >> (iii) Multicast handover solutions should tightly integrate with >> unicast handover (only >> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast >> integrates with PFMIPv6 and FMIPv6). >> > > The key point here is to be *integrated* with PMIPv6 in a *general* way. > The integration of SIAL with PMIPv6 is ensured as described above. > Furthermore, it is general because it does not impose the necessity of > additional layer-2 capabilities in the MN to work. This does not happen > with other solutions, including yours. > > Additionally, this has been discussed already in the WG. Several > individuals, such as Marco, expressed that unicast and multicast > handovers have different considerations. The WG consensus was to not to > specify in the adopted document a solution bound to a unicast handover > optimization solution. > >> (iv) Handover management should reuse standard mobility and multicast >> protocol operations for easy implementation and deployment >> (http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast >> introduced the use of standard IGMP/MLD records for context description >> in transfer, which has been copied several times). > > draft-ietf-multimob-fast-handover incorporated the use of the standard > multicast address record format as result of the WG feedback. > >> >> (v) Multicast handover management should integrate ASM and SSM, as >> well as IPv4 (IGMP) and IPv6 (MLD), which is only provided by >> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast. > > Since the SIAL solution deals with multicast membership subscription > context transfer, no issues relate to ASM and SSM. Regarding the IPv4 > treatment, we thank you for pointing this out and this is going to be > addressed in the next revision of the document, as we discussed during > the Atlanta meeting. We don't foresee any significant issue on adding > that support, and we of course welcome any contribution from you or any > other WG member on this aspect. > >> >> Based on these facts, chairs and AD proclaimed to re-decide on future >> paths for Multimob fast handover solutions. > > Again, based on what I recall, that seems to match what is captured in > the minutes, what was discussed is that the AD would check with the > chairs the process of the adoption call of > draft-schmidt-multimob-fmipv6-pfmipv6-multicast. I don't quite see how a > formal process revision (decision of the chairs on a WG adoption > document) relates with your e-mail. > > Thanks, > > Carlos > >> >> Cheers, >> >> 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 stig@venaas.com Thu Nov 15 15:43:31 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82081F0C6E for ; Thu, 15 Nov 2012 15:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgmVuX00GiEJ for ; Thu, 15 Nov 2012 15:43:31 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id AD50E1F0C71 for ; Thu, 15 Nov 2012 15:43:30 -0800 (PST) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id 710677FC5; Fri, 16 Nov 2012 00:43:27 +0100 (CET) Message-ID: <50A57E1E.6030202@venaas.com> Date: Thu, 15 Nov 2012 15:43:26 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <50A17826.5070109@informatik.haw-hamburg.de> <1353002171.5573.53.camel@acorde.it.uc3m.es> <50A53E41.5020602@informatik.haw-hamburg.de> In-Reply-To: <50A53E41.5020602@informatik.haw-hamburg.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "multimob@ietf.org" Subject: Re: [multimob] Fast Handover Solutions + Closing Multimob X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:43:32 -0000 Hi On 11/15/2012 11:10 AM, Thomas C. Schmidt wrote: > Hi Carlos, > > just a short answer: Chairs asked me in personal communication to send > these requirements. I don't recall that, but happy to see them posted here. > For the rest: > > We have had lengthy discussions over months on all the subjects, on-list > and off-list, mentioning all types of pro's and con's. I don't want to > repeat this. > > We finally agreed (with chairs) off-list to adopt both drafts as > experimental ... but then some people behaved differently from what they > had said earlier. I don't recall that either. > My view on the general situation is that there are two kinds of > reasonable work for Multimob > > (i) Basic enabling of PMIP multicast > (ii) Convincing coverage of the solution space in relevant scenarios > > (i) will be done by Multimob with the Base + MLD RFCs and the source > solution. > > Ad (ii), my impression is that Multimob is not really doing a decent > job. In fact, I have severe doubts that any of the work on track will be > of any value to anyone. > > So I believe we should start thinking about closing Multimob. We should finish the existing charter items, but I also think we need to consider seriously whether it is worth adding new charter items. I feel when we've completed the current items we've pretty much solved the more obvious issues. Once PMIP with multicast gets more deployment it can be reconsidered whether more IETF work is needed. I think it's best to do the DMM multicast work in DMM. I'm not necessarily saying that multimob should be closed any time soon, but we do need to at least have this discussion. It is a natural part of the rechartering discussion. Stig > Cheers, > > Thomas > > > On 15.11.2012 18:56, Carlos Jesús Bernardos Cano wrote: >> Hi Thomas, all, >> >> Please see some comments inline below. >> >> On Mon, 2012-11-12 at 23:28 +0100, Thomas C. Schmidt wrote: >>> Hi all, >>> >>> after the - somewhat uninformed discussion at IETF85 - chairs asked me >>> to restate requirements of a "fast handover solution" for Multicast >>> Mobility. >> >> I don't recall the chairs asking you to restate the requirements of a >> "fast handover solution", and the minutes do not reflect that either. >> Our AD asked the WG to document the requirements of the different >> solutions the WG is working on, as well as the feedback obtained from >> operators interested in multimob work. >> >> Actually, the WG already has a WG document for the fast handover >> solution milestone, and during initial discussions and the adoption >> process, we did have discussions on different aspects of how a fast >> handover solution should operate and the different requirements it >> should meet. There have been several reviews of the WG document and it >> captures feedback from the WG. >> >>> >>> Here they are: >> >> This list, IMHO, is not complete. For example, one critical aspect that >> has been discussed several times is how generic the solution is and what >> requirements it imposes on the different involved entities, as for >> example the need of layer-2 triggers on the mobile node. >> >>> >>> (i) Handover should be fast (this is only true for a direct >>> pMAG/AR to >>> nMAG/AR solution such as >>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast). >>> >> >> The handover speed will highly depend on the network topology in place. >> It cannot be generally stated that direct communication will always be >> faster than MAG to LMA communication. In fact, taking into account >> typical operative networks, an strict hierarchical topology is commonly >> deployed where the communication among different elements located in >> different access networks pass through central elements, using an star >> topology. Considering that a MAG could be able to serve a huge number of >> radio accesses, the more logical trend could be to deploy separated >> MAGs, without direct connectivity capabilities. Additionally, as >> previously discussed on this mailing list, you should note that the >> reactive case for FPMIPv6 is extremely harmful from the multicast >> handover delay perspective, as it needs to firstly register the MN and >> resolve the MLD Query process of RFC6224 to trigger the reactive >> mechanism afterwards. There is for sure no improvement regarding >> RFC6224. Furthermore, the dependency on the radio part (for layer-2 >> trigger capabilities) definitely limits the potential benefits that your >> proposal could provide. >> >>> >>> (ii) Multicast handover should be fully synchronized with unicast >>> handover (otherwise unicast and multicast states diverge as is a >>> well-known issue for the RAMS-approach, i.e., >>> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). >>> >> >> The adopted WG document draft-ietf-multimob-fast-handover (previously >> aka RAMS, now SIAL) is totally synchronized with the unicast handover, >> up to the point that it is triggered by the registration and/or >> de-registration messages of the unicast handover. It is difficult to >> achieve a better integration. In the proactive case, the de-registration >> message for unicast handover sent by the pMAG conveys the multicast >> membership subscription context for the moving MN. In the reactive case, >> the registration message for the MN attaching to the nMAG triggers the >> process, and the response to the registration PBU conveys the multicast >> membership subscription context. Do you really think these are not >> synchronized processes? >> >> BTW, what is the "well-known" issue you refer to? >> >>> (iii) Multicast handover solutions should tightly integrate with >>> unicast handover (only >>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast >>> >>> integrates with PFMIPv6 and FMIPv6). >>> >> >> The key point here is to be *integrated* with PMIPv6 in a *general* way. >> The integration of SIAL with PMIPv6 is ensured as described above. >> Furthermore, it is general because it does not impose the necessity of >> additional layer-2 capabilities in the MN to work. This does not happen >> with other solutions, including yours. >> >> Additionally, this has been discussed already in the WG. Several >> individuals, such as Marco, expressed that unicast and multicast >> handovers have different considerations. The WG consensus was to not to >> specify in the adopted document a solution bound to a unicast handover >> optimization solution. >> >>> (iv) Handover management should reuse standard mobility and multicast >>> protocol operations for easy implementation and deployment >>> (http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast >>> >>> introduced the use of standard IGMP/MLD records for context description >>> in transfer, which has been copied several times). >> >> draft-ietf-multimob-fast-handover incorporated the use of the standard >> multicast address record format as result of the WG feedback. >> >>> >>> (v) Multicast handover management should integrate ASM and SSM, as >>> well as IPv4 (IGMP) and IPv6 (MLD), which is only provided by >>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast. >>> >> >> Since the SIAL solution deals with multicast membership subscription >> context transfer, no issues relate to ASM and SSM. Regarding the IPv4 >> treatment, we thank you for pointing this out and this is going to be >> addressed in the next revision of the document, as we discussed during >> the Atlanta meeting. We don't foresee any significant issue on adding >> that support, and we of course welcome any contribution from you or any >> other WG member on this aspect. >> >>> >>> Based on these facts, chairs and AD proclaimed to re-decide on future >>> paths for Multimob fast handover solutions. >> >> Again, based on what I recall, that seems to match what is captured in >> the minutes, what was discussed is that the AD would check with the >> chairs the process of the adoption call of >> draft-schmidt-multimob-fmipv6-pfmipv6-multicast. I don't quite see how a >> formal process revision (decision of the chairs on a WG adoption >> document) relates with your e-mail. >> >> Thanks, >> >> Carlos >> >>> >>> Cheers, >>> >>> Thomas >> > From prvs=65964a046=schmidt@informatik.haw-hamburg.de Thu Nov 15 15:52:38 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CAC21F850A for ; Thu, 15 Nov 2012 15:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwUTuq-WGH4L for ; Thu, 15 Nov 2012 15:52:37 -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 6831C21F8485 for ; Thu, 15 Nov 2012 15:52:35 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAMR/pVCNFh5K/2dsb2JhbABEFoYHvCWBCIIeAQEEASMPAQU2CgEFCwkCGAICBQQICgsCAgkDAgECAUUGCgMBBwEBF4dsCgeqNZJTgSKLDxqCX4IggRMDlxiET4VKhQ6CcIFjFw Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 16 Nov 2012 00:52:33 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 6A1261054194; Fri, 16 Nov 2012 00:52:33 +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 30254-05; Fri, 16 Nov 2012 00:52:32 +0100 (CET) Received: from [192.168.178.36] (e178061168.adsl.alicedsl.de [85.178.61.168]) (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 2F9C01054192; Fri, 16 Nov 2012 00:52:32 +0100 (CET) Message-ID: <50A58042.9050001@informatik.haw-hamburg.de> Date: Fri, 16 Nov 2012 00:52:34 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stig Venaas References: <50A17826.5070109@informatik.haw-hamburg.de> <1353002171.5573.53.camel@acorde.it.uc3m.es> <50A53E41.5020602@informatik.haw-hamburg.de> <50A57E1E.6030202@venaas.com> In-Reply-To: <50A57E1E.6030202@venaas.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: "multimob@ietf.org" Subject: Re: [multimob] Fast Handover Solutions + Closing Multimob X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:52:38 -0000 Hi Stig, On 16.11.2012 00:43, Stig Venaas wrote: > On 11/15/2012 11:10 AM, Thomas C. Schmidt wrote: >> Hi Carlos, >> >> just a short answer: Chairs asked me in personal communication to send >> these requirements. > > I don't recall that, but happy to see them posted here. > Well, this was you in Atlanta in an oral discussion with Gorry. >> For the rest: >> >> We have had lengthy discussions over months on all the subjects, on-list >> and off-list, mentioning all types of pro's and con's. I don't want to >> repeat this. >> >> We finally agreed (with chairs) off-list to adopt both drafts as >> experimental ... but then some people behaved differently from what they >> had said earlier. > > I don't recall that either. > This was Behcet in an Email discussion with Marco, Carlos & Carlos. Cheers, Thomas >> My view on the general situation is that there are two kinds of >> reasonable work for Multimob >> >> (i) Basic enabling of PMIP multicast >> (ii) Convincing coverage of the solution space in relevant scenarios >> >> (i) will be done by Multimob with the Base + MLD RFCs and the source >> solution. >> >> Ad (ii), my impression is that Multimob is not really doing a decent >> job. In fact, I have severe doubts that any of the work on track will be >> of any value to anyone. >> >> So I believe we should start thinking about closing Multimob. > > We should finish the existing charter items, but I also think we need to > consider seriously whether it is worth adding new charter items. I feel > when we've completed the current items we've pretty much solved the more > obvious issues. Once PMIP with multicast gets more deployment it can be > reconsidered whether more IETF work is needed. I think it's best to do > the DMM multicast work in DMM. I'm not necessarily saying that multimob > should be closed any time soon, but we do need to at least have this > discussion. It is a natural part of the rechartering discussion. > > Stig > >> Cheers, >> >> Thomas >> >> >> On 15.11.2012 18:56, Carlos Jesús Bernardos Cano wrote: >>> Hi Thomas, all, >>> >>> Please see some comments inline below. >>> >>> On Mon, 2012-11-12 at 23:28 +0100, Thomas C. Schmidt wrote: >>>> Hi all, >>>> >>>> after the - somewhat uninformed discussion at IETF85 - chairs asked me >>>> to restate requirements of a "fast handover solution" for Multicast >>>> Mobility. >>> >>> I don't recall the chairs asking you to restate the requirements of a >>> "fast handover solution", and the minutes do not reflect that either. >>> Our AD asked the WG to document the requirements of the different >>> solutions the WG is working on, as well as the feedback obtained from >>> operators interested in multimob work. >>> >>> Actually, the WG already has a WG document for the fast handover >>> solution milestone, and during initial discussions and the adoption >>> process, we did have discussions on different aspects of how a fast >>> handover solution should operate and the different requirements it >>> should meet. There have been several reviews of the WG document and it >>> captures feedback from the WG. >>> >>>> >>>> Here they are: >>> >>> This list, IMHO, is not complete. For example, one critical aspect that >>> has been discussed several times is how generic the solution is and what >>> requirements it imposes on the different involved entities, as for >>> example the need of layer-2 triggers on the mobile node. >>> >>>> >>>> (i) Handover should be fast (this is only true for a direct >>>> pMAG/AR to >>>> nMAG/AR solution such as >>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast). >>>> >>>> >>> >>> The handover speed will highly depend on the network topology in place. >>> It cannot be generally stated that direct communication will always be >>> faster than MAG to LMA communication. In fact, taking into account >>> typical operative networks, an strict hierarchical topology is commonly >>> deployed where the communication among different elements located in >>> different access networks pass through central elements, using an star >>> topology. Considering that a MAG could be able to serve a huge number of >>> radio accesses, the more logical trend could be to deploy separated >>> MAGs, without direct connectivity capabilities. Additionally, as >>> previously discussed on this mailing list, you should note that the >>> reactive case for FPMIPv6 is extremely harmful from the multicast >>> handover delay perspective, as it needs to firstly register the MN and >>> resolve the MLD Query process of RFC6224 to trigger the reactive >>> mechanism afterwards. There is for sure no improvement regarding >>> RFC6224. Furthermore, the dependency on the radio part (for layer-2 >>> trigger capabilities) definitely limits the potential benefits that your >>> proposal could provide. >>> >>>> >>>> (ii) Multicast handover should be fully synchronized with unicast >>>> handover (otherwise unicast and multicast states diverge as is a >>>> well-known issue for the RAMS-approach, i.e., >>>> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). >>>> >>> >>> The adopted WG document draft-ietf-multimob-fast-handover (previously >>> aka RAMS, now SIAL) is totally synchronized with the unicast handover, >>> up to the point that it is triggered by the registration and/or >>> de-registration messages of the unicast handover. It is difficult to >>> achieve a better integration. In the proactive case, the de-registration >>> message for unicast handover sent by the pMAG conveys the multicast >>> membership subscription context for the moving MN. In the reactive case, >>> the registration message for the MN attaching to the nMAG triggers the >>> process, and the response to the registration PBU conveys the multicast >>> membership subscription context. Do you really think these are not >>> synchronized processes? >>> >>> BTW, what is the "well-known" issue you refer to? >>> >>>> (iii) Multicast handover solutions should tightly integrate with >>>> unicast handover (only >>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast >>>> >>>> >>>> integrates with PFMIPv6 and FMIPv6). >>>> >>> >>> The key point here is to be *integrated* with PMIPv6 in a *general* way. >>> The integration of SIAL with PMIPv6 is ensured as described above. >>> Furthermore, it is general because it does not impose the necessity of >>> additional layer-2 capabilities in the MN to work. This does not happen >>> with other solutions, including yours. >>> >>> Additionally, this has been discussed already in the WG. Several >>> individuals, such as Marco, expressed that unicast and multicast >>> handovers have different considerations. The WG consensus was to not to >>> specify in the adopted document a solution bound to a unicast handover >>> optimization solution. >>> >>>> (iv) Handover management should reuse standard mobility and >>>> multicast >>>> protocol operations for easy implementation and deployment >>>> (http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast >>>> >>>> >>>> introduced the use of standard IGMP/MLD records for context description >>>> in transfer, which has been copied several times). >>> >>> draft-ietf-multimob-fast-handover incorporated the use of the standard >>> multicast address record format as result of the WG feedback. >>> >>>> >>>> (v) Multicast handover management should integrate ASM and SSM, as >>>> well as IPv4 (IGMP) and IPv6 (MLD), which is only provided by >>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast. >>>> >>>> >>> >>> Since the SIAL solution deals with multicast membership subscription >>> context transfer, no issues relate to ASM and SSM. Regarding the IPv4 >>> treatment, we thank you for pointing this out and this is going to be >>> addressed in the next revision of the document, as we discussed during >>> the Atlanta meeting. We don't foresee any significant issue on adding >>> that support, and we of course welcome any contribution from you or any >>> other WG member on this aspect. >>> >>>> >>>> Based on these facts, chairs and AD proclaimed to re-decide on future >>>> paths for Multimob fast handover solutions. >>> >>> Again, based on what I recall, that seems to match what is captured in >>> the minutes, what was discussed is that the AD would check with the >>> chairs the process of the adoption call of >>> draft-schmidt-multimob-fmipv6-pfmipv6-multicast. I don't quite see how a >>> formal process revision (decision of the chairs on a WG adoption >>> document) relates with your e-mail. >>> >>> Thanks, >>> >>> Carlos >>> >>>> >>>> Cheers, >>>> >>>> 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 prvs=660e046e7=schmidt@informatik.haw-hamburg.de Thu Nov 15 16:22:27 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B7F21E803F for ; Thu, 15 Nov 2012 16:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw81qVb2hhdL for ; Thu, 15 Nov 2012 16:22:26 -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 68A6C1F041A for ; Thu, 15 Nov 2012 16:22:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKKGpVCNFh5K/2dsb2JhbABEFoYHvCWBCIIeAQEEASMPAQU2CgEQCQIYAgIFBAgKCwICCQMCAQIBRQYKAwEHAQEXh2wKB6okklWBIosPGoJfgiCBEwOXGIRPhUqFDoJwgWMX Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 16 Nov 2012 01:22:23 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id A1DD11054194; Fri, 16 Nov 2012 01:22:23 +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 30501-10; Fri, 16 Nov 2012 01:22:22 +0100 (CET) Received: from [192.168.178.36] (e178061168.adsl.alicedsl.de [85.178.61.168]) (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 8E2901054192; Fri, 16 Nov 2012 01:22:22 +0100 (CET) Message-ID: <50A58741.9050008@informatik.haw-hamburg.de> Date: Fri, 16 Nov 2012 01:22:25 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stig Venaas References: <50A17826.5070109@informatik.haw-hamburg.de> <1353002171.5573.53.camel@acorde.it.uc3m.es> <50A53E41.5020602@informatik.haw-hamburg.de> <50A57E1E.6030202@venaas.com> In-Reply-To: <50A57E1E.6030202@venaas.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: "multimob@ietf.org" Subject: Re: [multimob] Fast Handover Solutions + Closing Multimob X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 00:22:27 -0000 Hi again Stig, on Multimob evaluation, please see inline: On 16.11.2012 00:43, Stig Venaas wrote: >> My view on the general situation is that there are two kinds of >> reasonable work for Multimob >> >> (i) Basic enabling of PMIP multicast >> (ii) Convincing coverage of the solution space in relevant scenarios >> >> (i) will be done by Multimob with the Base + MLD RFCs and the source >> solution. >> >> Ad (ii), my impression is that Multimob is not really doing a decent >> job. In fact, I have severe doubts that any of the work on track will be >> of any value to anyone. >> >> So I believe we should start thinking about closing Multimob. > > We should finish the existing charter items, but I also think we need to > consider seriously whether it is worth adding new charter items. I feel > when we've completed the current items we've pretty much solved the more > obvious issues. I would already question the last observation. Multimob has moved into the complex domain of optimization by protocol extensions. To be successful in this area requires (a) a systematic exploration of the solution space (b) identification of superior solutions that are convincing to those who deploy After the (inconsistent) rechartering, Multimob has neither acted systematically in any visible way, nor at superior quality. The 'fast handover disaster' is only one example were the group made random choices for solutions that are barely sound. My personal impression is that people see Multimob just as a place were it is worthwhile fishing for an RFC number (sure, we also want to get documents published, but not on the price of humiliation), without even caring whether their proposals are implementable by reasonable means. This has grown worth and worth. My impression from the Atlanta meeting was that we have reached a state where any technical argument is completely useless in Multimob and a waste of mental resources. Cheers, Thomas >Once PMIP with multicast gets more deployment it can be > reconsidered whether more IETF work is needed. I think it's best to do > the DMM multicast work in DMM. I'm not necessarily saying that multimob > should be closed any time soon, but we do need to at least have this > discussion. It is a natural part of the rechartering discussion. > > Stig > >> Cheers, >> >> Thomas >> >> >> On 15.11.2012 18:56, Carlos Jesús Bernardos Cano wrote: >>> Hi Thomas, all, >>> >>> Please see some comments inline below. >>> >>> On Mon, 2012-11-12 at 23:28 +0100, Thomas C. Schmidt wrote: >>>> Hi all, >>>> >>>> after the - somewhat uninformed discussion at IETF85 - chairs asked me >>>> to restate requirements of a "fast handover solution" for Multicast >>>> Mobility. >>> >>> I don't recall the chairs asking you to restate the requirements of a >>> "fast handover solution", and the minutes do not reflect that either. >>> Our AD asked the WG to document the requirements of the different >>> solutions the WG is working on, as well as the feedback obtained from >>> operators interested in multimob work. >>> >>> Actually, the WG already has a WG document for the fast handover >>> solution milestone, and during initial discussions and the adoption >>> process, we did have discussions on different aspects of how a fast >>> handover solution should operate and the different requirements it >>> should meet. There have been several reviews of the WG document and it >>> captures feedback from the WG. >>> >>>> >>>> Here they are: >>> >>> This list, IMHO, is not complete. For example, one critical aspect that >>> has been discussed several times is how generic the solution is and what >>> requirements it imposes on the different involved entities, as for >>> example the need of layer-2 triggers on the mobile node. >>> >>>> >>>> (i) Handover should be fast (this is only true for a direct >>>> pMAG/AR to >>>> nMAG/AR solution such as >>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast). >>>> >>>> >>> >>> The handover speed will highly depend on the network topology in place. >>> It cannot be generally stated that direct communication will always be >>> faster than MAG to LMA communication. In fact, taking into account >>> typical operative networks, an strict hierarchical topology is commonly >>> deployed where the communication among different elements located in >>> different access networks pass through central elements, using an star >>> topology. Considering that a MAG could be able to serve a huge number of >>> radio accesses, the more logical trend could be to deploy separated >>> MAGs, without direct connectivity capabilities. Additionally, as >>> previously discussed on this mailing list, you should note that the >>> reactive case for FPMIPv6 is extremely harmful from the multicast >>> handover delay perspective, as it needs to firstly register the MN and >>> resolve the MLD Query process of RFC6224 to trigger the reactive >>> mechanism afterwards. There is for sure no improvement regarding >>> RFC6224. Furthermore, the dependency on the radio part (for layer-2 >>> trigger capabilities) definitely limits the potential benefits that your >>> proposal could provide. >>> >>>> >>>> (ii) Multicast handover should be fully synchronized with unicast >>>> handover (otherwise unicast and multicast states diverge as is a >>>> well-known issue for the RAMS-approach, i.e., >>>> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). >>>> >>> >>> The adopted WG document draft-ietf-multimob-fast-handover (previously >>> aka RAMS, now SIAL) is totally synchronized with the unicast handover, >>> up to the point that it is triggered by the registration and/or >>> de-registration messages of the unicast handover. It is difficult to >>> achieve a better integration. In the proactive case, the de-registration >>> message for unicast handover sent by the pMAG conveys the multicast >>> membership subscription context for the moving MN. In the reactive case, >>> the registration message for the MN attaching to the nMAG triggers the >>> process, and the response to the registration PBU conveys the multicast >>> membership subscription context. Do you really think these are not >>> synchronized processes? >>> >>> BTW, what is the "well-known" issue you refer to? >>> >>>> (iii) Multicast handover solutions should tightly integrate with >>>> unicast handover (only >>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast >>>> >>>> >>>> integrates with PFMIPv6 and FMIPv6). >>>> >>> >>> The key point here is to be *integrated* with PMIPv6 in a *general* way. >>> The integration of SIAL with PMIPv6 is ensured as described above. >>> Furthermore, it is general because it does not impose the necessity of >>> additional layer-2 capabilities in the MN to work. This does not happen >>> with other solutions, including yours. >>> >>> Additionally, this has been discussed already in the WG. Several >>> individuals, such as Marco, expressed that unicast and multicast >>> handovers have different considerations. The WG consensus was to not to >>> specify in the adopted document a solution bound to a unicast handover >>> optimization solution. >>> >>>> (iv) Handover management should reuse standard mobility and >>>> multicast >>>> protocol operations for easy implementation and deployment >>>> (http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast >>>> >>>> >>>> introduced the use of standard IGMP/MLD records for context description >>>> in transfer, which has been copied several times). >>> >>> draft-ietf-multimob-fast-handover incorporated the use of the standard >>> multicast address record format as result of the WG feedback. >>> >>>> >>>> (v) Multicast handover management should integrate ASM and SSM, as >>>> well as IPv4 (IGMP) and IPv6 (MLD), which is only provided by >>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast. >>>> >>>> >>> >>> Since the SIAL solution deals with multicast membership subscription >>> context transfer, no issues relate to ASM and SSM. Regarding the IPv4 >>> treatment, we thank you for pointing this out and this is going to be >>> addressed in the next revision of the document, as we discussed during >>> the Atlanta meeting. We don't foresee any significant issue on adding >>> that support, and we of course welcome any contribution from you or any >>> other WG member on this aspect. >>> >>>> >>>> Based on these facts, chairs and AD proclaimed to re-decide on future >>>> paths for Multimob fast handover solutions. >>> >>> Again, based on what I recall, that seems to match what is captured in >>> the minutes, what was discussed is that the AD would check with the >>> chairs the process of the adoption call of >>> draft-schmidt-multimob-fmipv6-pfmipv6-multicast. I don't quite see how a >>> formal process revision (decision of the chairs on a WG adoption >>> document) relates with your e-mail. >>> >>> Thanks, >>> >>> Carlos >>> >>>> >>>> Cheers, >>>> >>>> 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 stig@venaas.com Thu Nov 15 23:55:23 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEC921F84B2 for ; Thu, 15 Nov 2012 23:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+Ty3oTv8RZy for ; Thu, 15 Nov 2012 23:55:22 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 39B7A21F8477 for ; Thu, 15 Nov 2012 23:55:22 -0800 (PST) Received: from [192.168.1.101] (c-67-170-194-177.hsd1.ca.comcast.net [67.170.194.177]) by ufisa.uninett.no (Postfix) with ESMTPSA id 1708F7FC7; Fri, 16 Nov 2012 08:55:14 +0100 (CET) Message-ID: <50A5F198.20504@venaas.com> Date: Thu, 15 Nov 2012 23:56:08 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <50A17826.5070109@informatik.haw-hamburg.de> <1353002171.5573.53.camel@acorde.it.uc3m.es> <50A53E41.5020602@informatik.haw-hamburg.de> <50A57E1E.6030202@venaas.com> <50A58042.9050001@informatik.haw-hamburg.de> In-Reply-To: <50A58042.9050001@informatik.haw-hamburg.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "multimob@ietf.org" Subject: Re: [multimob] Fast Handover Solutions + Closing Multimob X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 07:55:23 -0000 Hi On 15.11.2012 15:52, Thomas C. Schmidt wrote: > Hi Stig, > > On 16.11.2012 00:43, Stig Venaas wrote: > >> On 11/15/2012 11:10 AM, Thomas C. Schmidt wrote: >>> Hi Carlos, >>> >>> just a short answer: Chairs asked me in personal communication to send >>> these requirements. >> >> I don't recall that, but happy to see them posted here. >> > > Well, this was you in Atlanta in an oral discussion with Gorry. Right, I remember we discussed about requirements. I don't remember exactly about posting them, but it certainly is a good idea. >>> For the rest: >>> >>> We have had lengthy discussions over months on all the subjects, on-list >>> and off-list, mentioning all types of pro's and con's. I don't want to >>> repeat this. >>> >>> We finally agreed (with chairs) off-list to adopt both drafts as >>> experimental ... but then some people behaved differently from what they >>> had said earlier. >> >> I don't recall that either. >> > > This was Behcet in an Email discussion with Marco, Carlos & Carlos. OK. Ideally we should as a group evaluate the proposals and pick the one that we believe best fits the requirements, or maybe another solution. Coming up with 2 solutions is not that good, unless we believe there really is a need for 2 solutions. But it may be an option. Stig > Cheers, > > Thomas > >>> My view on the general situation is that there are two kinds of >>> reasonable work for Multimob >>> >>> (i) Basic enabling of PMIP multicast >>> (ii) Convincing coverage of the solution space in relevant scenarios >>> >>> (i) will be done by Multimob with the Base + MLD RFCs and the source >>> solution. >>> >>> Ad (ii), my impression is that Multimob is not really doing a decent >>> job. In fact, I have severe doubts that any of the work on track will be >>> of any value to anyone. >>> >>> So I believe we should start thinking about closing Multimob. >> >> We should finish the existing charter items, but I also think we need to >> consider seriously whether it is worth adding new charter items. I feel >> when we've completed the current items we've pretty much solved the more >> obvious issues. Once PMIP with multicast gets more deployment it can be >> reconsidered whether more IETF work is needed. I think it's best to do >> the DMM multicast work in DMM. I'm not necessarily saying that multimob >> should be closed any time soon, but we do need to at least have this >> discussion. It is a natural part of the rechartering discussion. >> >> Stig >> >>> Cheers, >>> >>> Thomas >>> >>> >>> On 15.11.2012 18:56, Carlos Jesús Bernardos Cano wrote: >>>> Hi Thomas, all, >>>> >>>> Please see some comments inline below. >>>> >>>> On Mon, 2012-11-12 at 23:28 +0100, Thomas C. Schmidt wrote: >>>>> Hi all, >>>>> >>>>> after the - somewhat uninformed discussion at IETF85 - chairs asked me >>>>> to restate requirements of a "fast handover solution" for Multicast >>>>> Mobility. >>>> >>>> I don't recall the chairs asking you to restate the requirements of a >>>> "fast handover solution", and the minutes do not reflect that either. >>>> Our AD asked the WG to document the requirements of the different >>>> solutions the WG is working on, as well as the feedback obtained from >>>> operators interested in multimob work. >>>> >>>> Actually, the WG already has a WG document for the fast handover >>>> solution milestone, and during initial discussions and the adoption >>>> process, we did have discussions on different aspects of how a fast >>>> handover solution should operate and the different requirements it >>>> should meet. There have been several reviews of the WG document and it >>>> captures feedback from the WG. >>>> >>>>> >>>>> Here they are: >>>> >>>> This list, IMHO, is not complete. For example, one critical aspect that >>>> has been discussed several times is how generic the solution is and >>>> what >>>> requirements it imposes on the different involved entities, as for >>>> example the need of layer-2 triggers on the mobile node. >>>> >>>>> >>>>> (i) Handover should be fast (this is only true for a direct >>>>> pMAG/AR to >>>>> nMAG/AR solution such as >>>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast). >>>>> >>>>> >>>>> >>>> >>>> The handover speed will highly depend on the network topology in place. >>>> It cannot be generally stated that direct communication will always be >>>> faster than MAG to LMA communication. In fact, taking into account >>>> typical operative networks, an strict hierarchical topology is commonly >>>> deployed where the communication among different elements located in >>>> different access networks pass through central elements, using an star >>>> topology. Considering that a MAG could be able to serve a huge >>>> number of >>>> radio accesses, the more logical trend could be to deploy separated >>>> MAGs, without direct connectivity capabilities. Additionally, as >>>> previously discussed on this mailing list, you should note that the >>>> reactive case for FPMIPv6 is extremely harmful from the multicast >>>> handover delay perspective, as it needs to firstly register the MN and >>>> resolve the MLD Query process of RFC6224 to trigger the reactive >>>> mechanism afterwards. There is for sure no improvement regarding >>>> RFC6224. Furthermore, the dependency on the radio part (for layer-2 >>>> trigger capabilities) definitely limits the potential benefits that >>>> your >>>> proposal could provide. >>>> >>>>> >>>>> (ii) Multicast handover should be fully synchronized with unicast >>>>> handover (otherwise unicast and multicast states diverge as is a >>>>> well-known issue for the RAMS-approach, i.e., >>>>> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). >>>>> >>>> >>>> The adopted WG document draft-ietf-multimob-fast-handover (previously >>>> aka RAMS, now SIAL) is totally synchronized with the unicast handover, >>>> up to the point that it is triggered by the registration and/or >>>> de-registration messages of the unicast handover. It is difficult to >>>> achieve a better integration. In the proactive case, the >>>> de-registration >>>> message for unicast handover sent by the pMAG conveys the multicast >>>> membership subscription context for the moving MN. In the reactive >>>> case, >>>> the registration message for the MN attaching to the nMAG triggers the >>>> process, and the response to the registration PBU conveys the multicast >>>> membership subscription context. Do you really think these are not >>>> synchronized processes? >>>> >>>> BTW, what is the "well-known" issue you refer to? >>>> >>>>> (iii) Multicast handover solutions should tightly integrate with >>>>> unicast handover (only >>>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast >>>>> >>>>> >>>>> >>>>> integrates with PFMIPv6 and FMIPv6). >>>>> >>>> >>>> The key point here is to be *integrated* with PMIPv6 in a *general* >>>> way. >>>> The integration of SIAL with PMIPv6 is ensured as described above. >>>> Furthermore, it is general because it does not impose the necessity of >>>> additional layer-2 capabilities in the MN to work. This does not happen >>>> with other solutions, including yours. >>>> >>>> Additionally, this has been discussed already in the WG. Several >>>> individuals, such as Marco, expressed that unicast and multicast >>>> handovers have different considerations. The WG consensus was to not to >>>> specify in the adopted document a solution bound to a unicast handover >>>> optimization solution. >>>> >>>>> (iv) Handover management should reuse standard mobility and >>>>> multicast >>>>> protocol operations for easy implementation and deployment >>>>> (http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast >>>>> >>>>> >>>>> >>>>> introduced the use of standard IGMP/MLD records for context >>>>> description >>>>> in transfer, which has been copied several times). >>>> >>>> draft-ietf-multimob-fast-handover incorporated the use of the standard >>>> multicast address record format as result of the WG feedback. >>>> >>>>> >>>>> (v) Multicast handover management should integrate ASM and SSM, as >>>>> well as IPv4 (IGMP) and IPv6 (MLD), which is only provided by >>>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast. >>>>> >>>>> >>>>> >>>> >>>> Since the SIAL solution deals with multicast membership subscription >>>> context transfer, no issues relate to ASM and SSM. Regarding the IPv4 >>>> treatment, we thank you for pointing this out and this is going to be >>>> addressed in the next revision of the document, as we discussed during >>>> the Atlanta meeting. We don't foresee any significant issue on adding >>>> that support, and we of course welcome any contribution from you or any >>>> other WG member on this aspect. >>>> >>>>> >>>>> Based on these facts, chairs and AD proclaimed to re-decide on future >>>>> paths for Multimob fast handover solutions. >>>> >>>> Again, based on what I recall, that seems to match what is captured in >>>> the minutes, what was discussed is that the AD would check with the >>>> chairs the process of the adoption call of >>>> draft-schmidt-multimob-fmipv6-pfmipv6-multicast. I don't quite see >>>> how a >>>> formal process revision (decision of the chairs on a WG adoption >>>> document) relates with your e-mail. >>>> >>>> Thanks, >>>> >>>> Carlos >>>> >>>>> >>>>> Cheers, >>>>> >>>>> Thomas >>>> >>> >> > From mounir.kellil@cea.fr Fri Nov 16 06:27:20 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2510721F8609 for ; Fri, 16 Nov 2012 06:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTPRsoCRUTyv for ; Fri, 16 Nov 2012 06:27:19 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 04B7F21F84E4 for ; Fri, 16 Nov 2012 06:27:18 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qAGERHf7002968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 16 Nov 2012 15:27:17 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qAGERHhV017783 for ; Fri, 16 Nov 2012 15:27:17 +0100 (envelope-from mounir.kellil@cea.fr) Received: from EXCAH-B2.intra.cea.fr (excah-b2.intra.cea.fr [132.166.88.87]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qAGERHEd002356 for ; Fri, 16 Nov 2012 15:27:17 +0100 Received: from EXDAG0-B2.intra.cea.fr ([fe80::d079:8496:6c6c:9b1f]) by EXCAH-B2.intra.cea.fr ([fe80::6d9a:7f48:7b8f:6abc%12]) with mapi id 14.01.0339.001; Fri, 16 Nov 2012 15:27:16 +0100 From: KELLIL Mounir To: "multimob@ietf.org" Thread-Topic: FYI: draft-kellil-multimob-partial-mcast-00.txt Thread-Index: Ac3EBdcf7K3fD+PtSYCgvsabR1i+aA== Date: Fri, 16 Nov 2012 14:27:15 +0000 Message-ID: <7708224CCA85B641A12F88B1F5A47A430367002D@EXDAG0-B2.intra.cea.fr> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.105] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-19370.003 x-tm-as-result: No--26.598000-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7708224CCA85B641A12F88B1F5A47A430367002DEXDAG0B2intrace_" MIME-Version: 1.0 Subject: [multimob] FYI: draft-kellil-multimob-partial-mcast-00.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 14:27:20 -0000 --_000_7708224CCA85B641A12F88B1F5A47A430367002DEXDAG0B2intrace_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I have just submitted a draft to IETF (within the scope of multimob WG). Please find below a few words on the general idea of the draft Best regards Mounir KELLIL Filename: draft-kellil-multimob-partial-mcast Revision: 00 Title: Group Communications in a PMIPv6 Domain with Part= ial Deployment of Multicast Creation date: 2012-11-16 WG ID: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-kellil-multimob-= partial-mcast-00.txt Status: http://datatracker.ietf.org/doc/draft-kellil-multimob-part= ial-mcast Htmlized: http://tools.ietf.org/html/draft-kellil-multimob-partial-m= cast-00 Abstract: Various approaches have been proposed to support multicast in PMIPv6 domains. However, the problem of partial deployment of multicast in the PMIPv6 domain has not been considered. In particular, the proposed approaches typically assume that all the MAGs of the PMIPv6 domain are multicast-capable. The present work aims at carrying out the case where some of the PMIPv6 domain's MAGs are not necessarily multicast-capable. --_000_7708224CCA85B641A12F88B1F5A47A430367002DEXDAG0B2intrace_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I have just submitted a draft t= o IETF (within the scope of multimob WG).

Please find below a few words o= n the general idea of the draft

 

Best regards<= /p>

 

Mounir KELLIL

Filename:   &= nbsp;        draft-kellil-multimob-parti= al-mcast

Revision:   &= nbsp;         00<= /p>

Title:   &nbs= p;            &= nbsp;   Group Communications in a PMIPv6 Domain with Partial Depl= oyment of Multicast

Creation date:   2= 012-11-16

WG ID:   &nbs= p;             = Individual Submission

Number of pages: 12

URL:    =          http://www.ietf.org/internet-drafts/draft-kellil-multimob= -partial-mcast-00.txt

Status:   &nb= sp;      http://d= atatracker.ietf.org/doc/draft-kellil-multimob-partial-mcast

Htmlized:   &= nbsp;    http://tools.ietf.or= g/html/draft-kellil-multimob-partial-mcast-00

 

 

Abstract:<= /p>

   Various approac= hes have been proposed to support multicast in PMIPv6

   domains. Howeve= r, the problem of partial deployment of multicast in

   the PMIPv6 doma= in has not been considered. In particular, the

   proposed approa= ches typically assume that all the MAGs of the PMIPv6

   domain are mult= icast-capable. The present work aims at carrying out

   the case where = some of the PMIPv6 domain's MAGs are not necessarily

   multicas= t-capable.

 

--_000_7708224CCA85B641A12F88B1F5A47A430367002DEXDAG0B2intrace_-- From soohongp@gmail.com Fri Nov 16 18:41:27 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E0A21F8B05; Fri, 16 Nov 2012 18:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.008 X-Spam-Level: * X-Spam-Status: No, score=1.008 tagged_above=-999 required=5 tests=[AWL=0.626, BAYES_00=-2.599, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_LOW=-1, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01s7rnIu2zN0; Fri, 16 Nov 2012 18:41:27 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A6DF221F8AE4; Fri, 16 Nov 2012 18:41:26 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so1566266bku.31 for ; Fri, 16 Nov 2012 18:41:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PVnblALcVJn00mAn81iCggOwy1v7gYwnt77BSC/j5DA=; b=Nn+ThegMmdS2sd7ZjeCyYr/0u/UD5RwQkUswhLW0ETYbGDxYmVQknYbQx3COAmiC3W KCC3LlDqgccNMlbPfB9+sqYQ/l76A0BfsDX5eREnTFirSnYOqkWpUSe3LyQog3BrKcCh B7Dap1146AUuZgo1li/MRymBy9Zux25sSFuS/CnrRziFa42cvBHSml8JhwKesYbePuiR 5ca7tXwl555ThP6krsdlImEVD7GLoSnfjStR45jsxD3Vd+bhD7Q9Tl6FaP5VfudBB8hZ ocgxxc28kEDPuS+CfC5pxeG7+twgUo2V1M9sNQiB1tUEdWfbunLTAi/d6rzcb9oFVydw xuyw== MIME-Version: 1.0 Received: by 10.204.6.87 with SMTP id 23mr2723673bky.78.1353120085816; Fri, 16 Nov 2012 18:41:25 -0800 (PST) Received: by 10.204.60.81 with HTTP; Fri, 16 Nov 2012 18:41:25 -0800 (PST) Date: Sat, 17 Nov 2012 11:41:25 +0900 Message-ID: From: Daniel Park To: mmusic@ietf.org, wg2193@eeca16.sogang.ac.kr, monica@ittimes.co.kr, mskang@kt.co.kr, multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [multimob] (no subject) X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 02:41:27 -0000 http://www.77wonder.com/wp-content/plugins/akismet/google235.html From soohongp@gmail.com Sat Nov 17 20:37:44 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA8D21F8593; Sat, 17 Nov 2012 20:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.519 X-Spam-Level: X-Spam-Status: No, score=0.519 tagged_above=-999 required=5 tests=[AWL=1.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shOBM3sWWcq4; Sat, 17 Nov 2012 20:37:43 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D738921F84BB; Sat, 17 Nov 2012 20:37:42 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so1776467bku.31 for ; Sat, 17 Nov 2012 20:37:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BfcEIoeBMwUm/AkmYdQS3lotD5Rv16mHCN7vdFF1OJo=; b=BjoPLKs05oMIuSuxgHHKrCtHwE6AhxMx8A6DvigEhF9OVwkRFknQq87XQprcwcZcv5 iOFlFKXfDC+MbAX8hfIJ2N0oR9ZwCuXVMyY7fFxH0kWqtfFNplncXvk7maBM+L7kbwX5 WFZlS5aW+gZFVKTz/5Yo+RWgmLFtqzmOqDGUtktWeaGO0YOw+NES/rF5yoS30yH9xCZk ylpc1H6IQgUIsAPXTQVS6Jdx7kCXbJBCV64Nv81UmW/+IYnJy6vcYc3YCnGW6zKBX8Qt Lm2uhU3XNCN9oo4g7zW0s0aUsrH+2W+tzDj6OBPQu9U5TuMaWCdmSw6kmx7ForuVvidR r8Xg== MIME-Version: 1.0 Received: by 10.204.4.133 with SMTP id 5mr3711449bkr.21.1353213461950; Sat, 17 Nov 2012 20:37:41 -0800 (PST) Received: by 10.204.60.81 with HTTP; Sat, 17 Nov 2012 20:37:41 -0800 (PST) Received: by 10.204.60.81 with HTTP; Sat, 17 Nov 2012 20:37:41 -0800 (PST) In-Reply-To: References: Date: Sun, 18 Nov 2012 13:37:41 +0900 Message-ID: From: Daniel Park To: mskang@kt.co.kr, mmusic@ietf.org, multimob@ietf.org, monica@ittimes.co.kr, wg2193@eeca16.sogang.ac.kr Content-Type: multipart/alternative; boundary=0015175884c4b4710004cebd8f4b Subject: Re: [multimob] (no subject) spam. Please ignore X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 04:37:44 -0000 --0015175884c4b4710004cebd8f4b Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable I do not know why this mail is forwarded...it is spam..please ignore it. sorry. Soohong Daniel Park from my Galaxy Note 2012. 11. 17. =BF=C0=C0=FC 11:41=BF=A1 "Daniel Park" = =B4=D4=C0=CC =C0=DB=BC=BA: --0015175884c4b4710004cebd8f4b Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable

I do not know why this mail is forwarded...it is spam..please ignore it.= sorry.

Soohong Daniel Park from my Galaxy Note

2012. 11. 17. =BF=C0=C0=FC 11:41=BF=A1 "Dan= iel Park" <soohongp@gmail.com= >=B4=D4=C0=CC =C0=DB=BC=BA:
--0015175884c4b4710004cebd8f4b-- From sarikaya2012@gmail.com Mon Nov 19 15:09:28 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F7A21F8559 for ; Mon, 19 Nov 2012 15:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jlwKNFhqXwZ for ; Mon, 19 Nov 2012 15:09:27 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A68C621F8824 for ; Mon, 19 Nov 2012 15:09:15 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so217493ieb.31 for ; Mon, 19 Nov 2012 15:09:15 -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:content-transfer-encoding; bh=ImsoFcDBpnt/aT8KGA0UsB8aUtZy+o/MGzRvwJe3Q2o=; b=ZyzK7bZS6GYAsncZWcC2SDM1/DZoFPb1f8aWV4ebl1Qm/BYtiiXhSMhEDv6S7APk5W 4LlzbszS1PnJFwVVqKunnpnwKQupcfR3gs8WJUvFHVWbbGAyZ4bvapS1fkBnxLEXAGBC hh1TskabGtSMVgf7hNOLQ/cbCzKkRuVeIWpFEVZJnnnprTUR2mwGVeVdB9yS2Ffn4M/v SDrcFc5Tl43vWwUx/5GLFBwC2xpLFlNW+Squ/RJy5CE+Nj4E8SdaWrIrJo8h4S8W/ReD loTdQZ2bJzxdtJMwGZOgDCLmYt1Jm7VbJDhH/Z8q4zyKtp/JwV+nWqUNaccBJAT9tJ7f aaKQ== MIME-Version: 1.0 Received: by 10.42.147.74 with SMTP id m10mr12415123icv.0.1353366555179; Mon, 19 Nov 2012 15:09:15 -0800 (PST) Received: by 10.231.85.26 with HTTP; Mon, 19 Nov 2012 15:09:14 -0800 (PST) In-Reply-To: <50A17826.5070109@informatik.haw-hamburg.de> References: <50A17826.5070109@informatik.haw-hamburg.de> Date: Mon, 19 Nov 2012 17:09:14 -0600 Message-ID: From: Behcet Sarikaya To: "Thomas C. Schmidt" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multimob@ietf.org" Subject: Re: [multimob] Fast Handover Solutions X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 23:09:28 -0000 Hi Thomas, It seems that these requirements are for draft-schmidt-multimob-fmipv6-pfmipv6-multicast and not for draft-ietf-multimob-fast-handover. What do you think? Regards, Behcet On Mon, Nov 12, 2012 at 4:28 PM, Thomas C. Schmidt wrote: > Hi all, > > after the - somewhat uninformed discussion at IETF85 - chairs asked me to > restate requirements of a "fast handover solution" for Multicast Mobility= . > > Here they are: > > (i) Handover should be fast (this is only true for a direct pMAG/AR to > nMAG/AR solution such as > http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicas= t). > > (ii) Multicast handover should be fully synchronized with unicast handov= er > (otherwise unicast and multicast states diverge as is a well-known issue = for > the RAMS-approach, i.e., > https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). > > (iii) Multicast handover solutions should tightly integrate with unicast > handover (only > http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicas= t > integrates with PFMIPv6 and FMIPv6). > > (iv) Handover management should reuse standard mobility and multicast > protocol operations for easy implementation and deployment > (http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multica= st > introduced the use of standard IGMP/MLD records for context description i= n > transfer, which has been copied several times). > > (v) Multicast handover management should integrate ASM and SSM, as well = as > IPv4 (IGMP) and IPv6 (MLD), which is only provided by > http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicas= t. > > Based on these facts, chairs and AD proclaimed to re-decide on future pat= hs > for Multimob fast handover solutions. > > Cheers, > > Thomas > -- > > 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 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From prvs=6642d1344=schmidt@informatik.haw-hamburg.de Mon Nov 19 16:27:47 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB54F21F87AB for ; Mon, 19 Nov 2012 16:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8Cg9soUfKDG for ; Mon, 19 Nov 2012 16:27:47 -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 CD33121F87A6 for ; Mon, 19 Nov 2012 16:27:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANXNqlCNFh5K/2dsb2JhbABFFsI8gQiCHgEBAQQBAQEvAQU2CgEQCxgJFg8JAwIBAgEVMBADAQUCAQEXh3YHr22QM4w0hQ0DlxiET4VKhQ6CcA Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 20 Nov 2012 01:27:44 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 5FDE911C95AB; Tue, 20 Nov 2012 01:27:44 +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 28865-06; Tue, 20 Nov 2012 01:27:43 +0100 (CET) Received: from [192.168.178.36] (g231105033.adsl.alicedsl.de [92.231.105.33]) (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 9B71E102A53D; Tue, 20 Nov 2012 01:27:43 +0100 (CET) Message-ID: <50AACE81.9050905@informatik.haw-hamburg.de> Date: Tue, 20 Nov 2012 01:27:45 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: sarikaya@ieee.org References: <50A17826.5070109@informatik.haw-hamburg.de> 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 Cc: "multimob@ietf.org" , Behcet Sarikaya Subject: Re: [multimob] Fast Handover Solutions X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 00:27:48 -0000 Hi Behcet, these requirements are for a fast handover solution, i.e., a protocol that operates a *handover* in a *fast* manner. I agree that draft-ietf-multimob-fast-handover does not meet the requirements, but had written earlier on the list that the name of this draft is misleading in two ways: (i) draft-ietf-multimob-fast-handover is not a fast handover solution, and (ii) the name "fast handover" is tied to RFC5568/RFC5949-like schemes for good reasons. Cheers, Thomas On 20.11.2012 00:09, Behcet Sarikaya wrote: > Hi Thomas, > > It seems that these requirements are for > > draft-schmidt-multimob-fmipv6-pfmipv6-multicast > > and not for > draft-ietf-multimob-fast-handover. > > What do you think? > > Regards, > > Behcet > > On Mon, Nov 12, 2012 at 4:28 PM, Thomas C. Schmidt > wrote: >> Hi all, >> >> after the - somewhat uninformed discussion at IETF85 - chairs asked me to >> restate requirements of a "fast handover solution" for Multicast Mobility. >> >> Here they are: >> >> (i) Handover should be fast (this is only true for a direct pMAG/AR to >> nMAG/AR solution such as >> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast). >> >> (ii) Multicast handover should be fully synchronized with unicast handover >> (otherwise unicast and multicast states diverge as is a well-known issue for >> the RAMS-approach, i.e., >> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). >> >> (iii) Multicast handover solutions should tightly integrate with unicast >> handover (only >> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast >> integrates with PFMIPv6 and FMIPv6). >> >> (iv) Handover management should reuse standard mobility and multicast >> protocol operations for easy implementation and deployment >> (http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast >> introduced the use of standard IGMP/MLD records for context description in >> transfer, which has been copied several times). >> >> (v) Multicast handover management should integrate ASM and SSM, as well as >> IPv4 (IGMP) and IPv6 (MLD), which is only provided by >> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast. >> >> Based on these facts, chairs and AD proclaimed to re-decide on future paths >> for Multimob fast handover solutions. >> >> Cheers, >> >> 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 ° >> _______________________________________________ >> 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 sarikaya2012@gmail.com Mon Nov 26 13:46:55 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB51721F8618 for ; Mon, 26 Nov 2012 13:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Cuw4svN5dwB for ; Mon, 26 Nov 2012 13:46:54 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A69C821F85F0 for ; Mon, 26 Nov 2012 13:46:54 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so10571293ieb.31 for ; Mon, 26 Nov 2012 13:46:54 -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:content-transfer-encoding; bh=rhPfa3t6LCr9xi1l7nZg49wJzF3Xm7chfA0oSaS/SpE=; b=iYnI1TNgVUIPeyWQ0rFUyTGXT8KT22ZVUYYwwRjsaPJPzQWhf4PZbZ493gKtmsQa0Z EqHMR5zG5GJFNMEu26Bm2uNrfXYp6bGaQNcvlSqBFqw52hrmLax9vzYiZ7l/HjpC+nLc Dg8cWReNojrzUnPCo+mVdy5f5Z6/uFE0jWSMiNZu6ZEfs/bgu7KYlS8e3VD9TPJP8DcW b4kYVf6gssSDB0OS9b9/X4E298xmWGvTgiBL+p2B+ktvaKG9R3dvBqmeSBoemJmGZAjG vluJRf+uFpAuhN8tUL8IwHfNPVsudxgwq7msIEHd0Bru4/oE/RYMStTooy6wxMT12t9u 1d1w== MIME-Version: 1.0 Received: by 10.50.152.240 with SMTP id vb16mr13610833igb.45.1353966414266; Mon, 26 Nov 2012 13:46:54 -0800 (PST) Received: by 10.231.10.204 with HTTP; Mon, 26 Nov 2012 13:46:54 -0800 (PST) In-Reply-To: <50AACE81.9050905@informatik.haw-hamburg.de> References: <50A17826.5070109@informatik.haw-hamburg.de> <50AACE81.9050905@informatik.haw-hamburg.de> Date: Mon, 26 Nov 2012 15:46:54 -0600 Message-ID: From: Behcet Sarikaya To: "Thomas C. Schmidt" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multimob@ietf.org" Subject: Re: [multimob] Fast Handover Solutions X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 21:46:55 -0000 On Mon, Nov 19, 2012 at 6:27 PM, Thomas C. Schmidt wrote: > Hi Behcet, > > these requirements are for a fast handover solution, i.e., a protocol tha= t > operates a *handover* in a *fast* manner. > > I agree that draft-ietf-multimob-fast-handover does not meet the > requirements, but had written earlier on the list that the name of this > draft is misleading in two ways: (i) draft-ietf-multimob-fast-handover is > not a fast handover solution, and (ii) the name "fast handover" is tied t= o > RFC5568/RFC5949-like schemes for good reasons. > The draft title contains ... handover optimization ... and it reflects its content. We asked for this WG draft name because of the charter item to which it corresponds. I think this clarifies your confusion. Regards, Behcet > Cheers, > > Thomas > > > On 20.11.2012 00:09, Behcet Sarikaya wrote: >> >> Hi Thomas, >> >> It seems that these requirements are for >> >> draft-schmidt-multimob-fmipv6-pfmipv6-multicast >> >> and not for >> draft-ietf-multimob-fast-handover. >> >> What do you think? >> >> Regards, >> >> Behcet >> >> On Mon, Nov 12, 2012 at 4:28 PM, Thomas C. Schmidt >> wrote: >>> >>> Hi all, >>> >>> after the - somewhat uninformed discussion at IETF85 - chairs asked me = to >>> restate requirements of a "fast handover solution" for Multicast >>> Mobility. >>> >>> Here they are: >>> >>> (i) Handover should be fast (this is only true for a direct pMAG/AR t= o >>> nMAG/AR solution such as >>> >>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multic= ast). >>> >>> (ii) Multicast handover should be fully synchronized with unicast >>> handover >>> (otherwise unicast and multicast states diverge as is a well-known issu= e >>> for >>> the RAMS-approach, i.e., >>> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). >>> >>> (iii) Multicast handover solutions should tightly integrate with >>> unicast >>> handover (only >>> >>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multic= ast >>> integrates with PFMIPv6 and FMIPv6). >>> >>> (iv) Handover management should reuse standard mobility and multicast >>> protocol operations for easy implementation and deployment >>> >>> (http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multi= cast >>> introduced the use of standard IGMP/MLD records for context description >>> in >>> transfer, which has been copied several times). >>> >>> (v) Multicast handover management should integrate ASM and SSM, as we= ll >>> as >>> IPv4 (IGMP) and IPv6 (MLD), which is only provided by >>> >>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multic= ast. >>> >>> Based on these facts, chairs and AD proclaimed to re-decide on future >>> paths >>> for Multimob fast handover solutions. >>> >>> Cheers, >>> >>> Thomas >>> -- >>> >>> Prof. Dr. Thomas C. Schmidt >>> =B0 Hamburg University of Applied Sciences Berliner T= or 7 >>> =B0 >>> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Ger= many >>> =B0 >>> =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-= 8452 >>> =B0 >>> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-= 8409 >>> =B0 >>> _______________________________________________ >>> 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 From rkoodli@cisco.com Mon Nov 26 16:07:32 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C23C21F84F1 for ; Mon, 26 Nov 2012 16:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GjwilG7Yemw for ; Mon, 26 Nov 2012 16:07:31 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 41AFE21F84F0 for ; Mon, 26 Nov 2012 16:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4486; q=dns/txt; s=iport; t=1353974851; x=1355184451; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7SVB4netwq16Uqf3SuAOSe9NCfECup7D4eSw8aVfo9M=; b=jlLala3IW7d5wHfCPrAEPJ4yIl4iBMhQWdWqYX9se/csyflg+UAUONWt cwy0oZhquVKCqhToBT3QOIpaWLiMOoZzivNULV26bPtbYy3OHuP5oMyH9 pNwL9ZRozlbOmxtuskbNJ2AyUwidGlR/Wvrry3D1DGn/2uaqLZUTPpF4U 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACYDtFCtJXG//2dsb2JhbABEFsAOgQmCHgEBAQQBAQFrCxIBCBgKRQYLJQIEAQkEBQgTh2ADDwywN4ZYDYlUi05pg2BhA4gpjAOCcYoYA4UNgm+CHQ X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146456930" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 27 Nov 2012 00:07:30 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAR07UWP010220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 00:07:30 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.168]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Mon, 26 Nov 2012 18:07:30 -0600 From: "Rajeev Koodli (rkoodli)" To: "sarikaya@ieee.org" , "Thomas C. Schmidt" Thread-Topic: [multimob] Fast Handover Solutions Thread-Index: AQHNwSUhIilrHwuomkScmGZZlY53rpfyOBMAgAAV8ICACtNhAP//pgYA Date: Tue, 27 Nov 2012 00:07:30 +0000 Message-ID: <7C52FDEBC843C44DBAF2CA6A30662C6D0D2927@xmb-aln-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.82.220] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5317DB3322346B48BEB6D2BE4E9D0D61@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multimob@ietf.org" Subject: Re: [multimob] Fast Handover Solutions X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 00:07:32 -0000 Hi Behcet, On 11/26/12 1:46 PM, "Behcet Sarikaya" wrote: >On Mon, Nov 19, 2012 at 6:27 PM, Thomas C. Schmidt > wrote: >> Hi Behcet, >> >> these requirements are for a fast handover solution, i.e., a protocol >>that >> operates a *handover* in a *fast* manner. >> >> I agree that draft-ietf-multimob-fast-handover does not meet the >> requirements, but had written earlier on the list that the name of this >> draft is misleading in two ways: (i) draft-ietf-multimob-fast-handover >>is >> not a fast handover solution, and (ii) the name "fast handover" is tied >>to >> RFC5568/RFC5949-like schemes for good reasons. >> > >The draft title contains ... handover optimization ... and it reflects >its content. >We asked for this WG draft name because of the charter item to which >it corresponds. Sorry, which charter item has "fast-handover"? Could you clarify? Thanks. -Rajeev =20 > >I think this clarifies your confusion. > >Regards, > >Behcet > >> Cheers, >> >> Thomas >> >> >> On 20.11.2012 00:09, Behcet Sarikaya wrote: >>> >>> Hi Thomas, >>> >>> It seems that these requirements are for >>> >>> draft-schmidt-multimob-fmipv6-pfmipv6-multicast >>> >>> and not for >>> draft-ietf-multimob-fast-handover. >>> >>> What do you think? >>> >>> Regards, >>> >>> Behcet >>> >>> On Mon, Nov 12, 2012 at 4:28 PM, Thomas C. Schmidt >>> wrote: >>>> >>>> Hi all, >>>> >>>> after the - somewhat uninformed discussion at IETF85 - chairs asked >>>>me to >>>> restate requirements of a "fast handover solution" for Multicast >>>> Mobility. >>>> >>>> Here they are: >>>> >>>> (i) Handover should be fast (this is only true for a direct pMAG/AR >>>>to >>>> nMAG/AR solution such as >>>> >>>>=20 >>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multic >>>>ast). >>>> >>>> (ii) Multicast handover should be fully synchronized with unicast >>>> handover >>>> (otherwise unicast and multicast states diverge as is a well-known >>>>issue >>>> for >>>> the RAMS-approach, i.e., >>>> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). >>>> >>>> (iii) Multicast handover solutions should tightly integrate with >>>> unicast >>>> handover (only >>>> >>>>=20 >>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multic >>>>ast >>>> integrates with PFMIPv6 and FMIPv6). >>>> >>>> (iv) Handover management should reuse standard mobility and >>>>multicast >>>> protocol operations for easy implementation and deployment >>>> >>>>=20 >>>>(http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multi >>>>cast >>>> introduced the use of standard IGMP/MLD records for context >>>>description >>>> in >>>> transfer, which has been copied several times). >>>> >>>> (v) Multicast handover management should integrate ASM and SSM, as >>>>well >>>> as >>>> IPv4 (IGMP) and IPv6 (MLD), which is only provided by >>>> >>>>=20 >>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multic >>>>ast. >>>> >>>> Based on these facts, chairs and AD proclaimed to re-decide on future >>>> paths >>>> for Multimob fast handover solutions. >>>> >>>> Cheers, >>>> >>>> Thomas >>>> -- >>>> >>>> Prof. Dr. Thomas C. Schmidt >>>> =B0 Hamburg University of Applied Sciences Berliner >>>>Tor 7 >>>> =B0 >>>> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, >>>>Germany >>>> =B0 >>>> =B0 http://www.haw-hamburg.de/inet Fon: >>>>+49-40-42875-8452 >>>> =B0 >>>> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: >>>>+49-40-42875-8409 >>>> =B0 >>>> _______________________________________________ >>>> 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 To= r >>7 =B0 >> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, >>Germany =B0 >> =B0 http://www.haw-hamburg.de/inet Fon: >>+49-40-42875-8452 =B0 >> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: >>+49-40-42875-8409 =B0 >_______________________________________________ >multimob mailing list >multimob@ietf.org >https://www.ietf.org/mailman/listinfo/multimob From sarikaya2012@gmail.com Tue Nov 27 09:24:35 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC5A21F87E0 for ; Tue, 27 Nov 2012 09:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4qoTPGmkYBN for ; Tue, 27 Nov 2012 09:24:34 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 606F921F8711 for ; Tue, 27 Nov 2012 09:24:34 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so9954433iaf.31 for ; Tue, 27 Nov 2012 09:24:34 -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:content-transfer-encoding; bh=vN03/vEcSY69uk3ibwKc+RPmn9oLSur24bUWuT5WacE=; b=01JaodSvQYzy9B1I8Fo7Evr2ook5DENbsPSpDzkTWD3pOfFy7yfsY5TH5EPw+XwCAZ WZ9YuKRSlQcBxNotCZGHvpNvsVqAfI8BXpjdwfqi7SytXhycJk/s9+xuMjd0S2+JkPjY rd5UG/vp/HIEaj4hbZsGHVAy8c3Yu+Cm7XWT8+QQ2DF+Kj9Tzx2MvQbXjmnCbZ9jm0nr 0ZpW2lOSVide13tBhiwo09uHb7/VLcgnsK05B46ZypCSrXhT+caT6Pnk7P+/Qm9Hl0DC cayS5bHHXtBVMpUAGNKAqqfR014kk4B/JTl3IJqDOFVB+hbOvPywpnVJ0ikrdIy92dLG 923Q== MIME-Version: 1.0 Received: by 10.50.5.205 with SMTP id u13mr16502362igu.37.1354037073990; Tue, 27 Nov 2012 09:24:33 -0800 (PST) Received: by 10.231.10.204 with HTTP; Tue, 27 Nov 2012 09:24:33 -0800 (PST) In-Reply-To: <7C52FDEBC843C44DBAF2CA6A30662C6D0D2927@xmb-aln-x04.cisco.com> References: <7C52FDEBC843C44DBAF2CA6A30662C6D0D2927@xmb-aln-x04.cisco.com> Date: Tue, 27 Nov 2012 11:24:33 -0600 Message-ID: From: Behcet Sarikaya To: "Rajeev Koodli (rkoodli)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multimob@ietf.org" , "Thomas C. Schmidt" Subject: Re: [multimob] Fast Handover Solutions X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 17:24:35 -0000 Hi Rajeev, I checked again. The charter item is about PMIPv6 handover optimizations, not on fast handov= er. The draft name should have been handover-optimizations not fast-handover. Sorry about that because I had suggested this draft name. Without realizing that it would cause so much trouble. I repeat here again, the draft title did not change and the draft content is reflected in the title. This is the most important thing. Regards, Behcet On Mon, Nov 26, 2012 at 6:07 PM, Rajeev Koodli (rkoodli) wrote: > > > Hi Behcet, > > On 11/26/12 1:46 PM, "Behcet Sarikaya" wrote: > >>On Mon, Nov 19, 2012 at 6:27 PM, Thomas C. Schmidt >> wrote: >>> Hi Behcet, >>> >>> these requirements are for a fast handover solution, i.e., a protocol >>>that >>> operates a *handover* in a *fast* manner. >>> >>> I agree that draft-ietf-multimob-fast-handover does not meet the >>> requirements, but had written earlier on the list that the name of this >>> draft is misleading in two ways: (i) draft-ietf-multimob-fast-handover >>>is >>> not a fast handover solution, and (ii) the name "fast handover" is tied >>>to >>> RFC5568/RFC5949-like schemes for good reasons. >>> >> >>The draft title contains ... handover optimization ... and it reflects >>its content. >>We asked for this WG draft name because of the charter item to which >>it corresponds. > > Sorry, which charter item has "fast-handover"? > Could you clarify? > > Thanks. > > -Rajeev > > > >> >>I think this clarifies your confusion. >> >>Regards, >> >>Behcet >> >>> Cheers, >>> >>> Thomas >>> >>> >>> On 20.11.2012 00:09, Behcet Sarikaya wrote: >>>> >>>> Hi Thomas, >>>> >>>> It seems that these requirements are for >>>> >>>> draft-schmidt-multimob-fmipv6-pfmipv6-multicast >>>> >>>> and not for >>>> draft-ietf-multimob-fast-handover. >>>> >>>> What do you think? >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>> On Mon, Nov 12, 2012 at 4:28 PM, Thomas C. Schmidt >>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> after the - somewhat uninformed discussion at IETF85 - chairs asked >>>>>me to >>>>> restate requirements of a "fast handover solution" for Multicast >>>>> Mobility. >>>>> >>>>> Here they are: >>>>> >>>>> (i) Handover should be fast (this is only true for a direct pMAG/AR >>>>>to >>>>> nMAG/AR solution such as >>>>> >>>>> >>>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multi= c >>>>>ast). >>>>> >>>>> (ii) Multicast handover should be fully synchronized with unicast >>>>> handover >>>>> (otherwise unicast and multicast states diverge as is a well-known >>>>>issue >>>>> for >>>>> the RAMS-approach, i.e., >>>>> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). >>>>> >>>>> (iii) Multicast handover solutions should tightly integrate with >>>>> unicast >>>>> handover (only >>>>> >>>>> >>>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multi= c >>>>>ast >>>>> integrates with PFMIPv6 and FMIPv6). >>>>> >>>>> (iv) Handover management should reuse standard mobility and >>>>>multicast >>>>> protocol operations for easy implementation and deployment >>>>> >>>>> >>>>>(http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mult= i >>>>>cast >>>>> introduced the use of standard IGMP/MLD records for context >>>>>description >>>>> in >>>>> transfer, which has been copied several times). >>>>> >>>>> (v) Multicast handover management should integrate ASM and SSM, as >>>>>well >>>>> as >>>>> IPv4 (IGMP) and IPv6 (MLD), which is only provided by >>>>> >>>>> >>>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multi= c >>>>>ast. >>>>> >>>>> Based on these facts, chairs and AD proclaimed to re-decide on future >>>>> paths >>>>> for Multimob fast handover solutions. >>>>> >>>>> Cheers, >>>>> >>>>> Thomas >>>>> -- >>>>> >>>>> Prof. Dr. Thomas C. Schmidt >>>>> =B0 Hamburg University of Applied Sciences Berliner >>>>>Tor 7 >>>>> =B0 >>>>> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, >>>>>Germany >>>>> =B0 >>>>> =B0 http://www.haw-hamburg.de/inet Fon: >>>>>+49-40-42875-8452 >>>>> =B0 >>>>> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: >>>>>+49-40-42875-8409 >>>>> =B0 >>>>> _______________________________________________ >>>>> 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 T= or >>>7 =B0 >>> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, >>>Germany =B0 >>> =B0 http://www.haw-hamburg.de/inet Fon: >>>+49-40-42875-8452 =B0 >>> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: >>>+49-40-42875-8409 =B0 >>_______________________________________________ >>multimob mailing list >>multimob@ietf.org >>https://www.ietf.org/mailman/listinfo/multimob > From rkoodli@cisco.com Tue Nov 27 10:19:36 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC5D21F86B0 for ; Tue, 27 Nov 2012 10:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlTkKha-d9id for ; Tue, 27 Nov 2012 10:19:35 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C0F7321F86B8 for ; Tue, 27 Nov 2012 10:19:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5729; q=dns/txt; s=iport; t=1354040368; x=1355249968; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=xwwNLBLDh6tTG9qKCqMjt2O0NiLfo7LvKk/D3cU9gGc=; b=N53bTrYYW4JGB73ppzYWOk2wIwJGbCmVFSe+gfgtt35bQGd8qeGnfqRz KcQr9id++I2HC5k2PwcopxNzQBKSGLzllYk2/j2oWv2BxbmxkzRLoG7qm IGvhnQBRLJdz9kftsmr49VCmypJSFx8DG+bgsUo6jG0CVX4sNbOQKZVQG I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8LAFoDtVCtJXHA/2dsb2JhbABFFsAIFmwHgh4BAQEEAQEBawsSAQgYCkUGCyUCBAoEBQgTh2ADDwywG4ZrDYlUi1Fpg2BhA4gpjAOCcYoYA4UNgnCCIA X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="146741493" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 27 Nov 2012 18:19:28 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qARIJSB0014641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 18:19:28 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.168]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 12:19:28 -0600 From: "Rajeev Koodli (rkoodli)" To: "sarikaya@ieee.org" Thread-Topic: [multimob] Fast Handover Solutions Thread-Index: AQHNwSUhIilrHwuomkScmGZZlY53rpfyOBMAgAAV8ICACtNhAP//pgYAgAGjAoD//44ZgA== Date: Tue, 27 Nov 2012 18:19:27 +0000 Message-ID: <7C52FDEBC843C44DBAF2CA6A30662C6D0D2BDD@xmb-aln-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.89.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multimob@ietf.org" , "Thomas C. Schmidt" Subject: Re: [multimob] Fast Handover Solutions X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 18:19:36 -0000 Thanks for checking. To avoid the confusion, kindly rename the draft appropriately. The draft title and the draft name should be consistent, and not mislead, as it does now. -Rajeev On 11/27/12 9:24 AM, "Behcet Sarikaya" wrote: >Hi Rajeev, > >I checked again. >The charter item is about PMIPv6 handover optimizations, not on fast >handover. > >The draft name should have been handover-optimizations not fast-handover. > >Sorry about that because I had suggested this draft name. > >Without realizing that it would cause so much trouble. > >I repeat here again, the draft title did not change and the draft >content is reflected in the title. This is the most important thing. > > >Regards, > >Behcet > >On Mon, Nov 26, 2012 at 6:07 PM, Rajeev Koodli (rkoodli) > wrote: >> >> >> Hi Behcet, >> >> On 11/26/12 1:46 PM, "Behcet Sarikaya" wrote: >> >>>On Mon, Nov 19, 2012 at 6:27 PM, Thomas C. Schmidt >>> wrote: >>>> Hi Behcet, >>>> >>>> these requirements are for a fast handover solution, i.e., a protocol >>>>that >>>> operates a *handover* in a *fast* manner. >>>> >>>> I agree that draft-ietf-multimob-fast-handover does not meet the >>>> requirements, but had written earlier on the list that the name of >>>>this >>>> draft is misleading in two ways: (i) draft-ietf-multimob-fast-handover >>>>is >>>> not a fast handover solution, and (ii) the name "fast handover" is >>>>tied >>>>to >>>> RFC5568/RFC5949-like schemes for good reasons. >>>> >>> >>>The draft title contains ... handover optimization ... and it reflects >>>its content. >>>We asked for this WG draft name because of the charter item to which >>>it corresponds. >> >> Sorry, which charter item has "fast-handover"? >> Could you clarify? >> >> Thanks. >> >> -Rajeev >> >> >> >>> >>>I think this clarifies your confusion. >>> >>>Regards, >>> >>>Behcet >>> >>>> Cheers, >>>> >>>> Thomas >>>> >>>> >>>> On 20.11.2012 00:09, Behcet Sarikaya wrote: >>>>> >>>>> Hi Thomas, >>>>> >>>>> It seems that these requirements are for >>>>> >>>>> draft-schmidt-multimob-fmipv6-pfmipv6-multicast >>>>> >>>>> and not for >>>>> draft-ietf-multimob-fast-handover. >>>>> >>>>> What do you think? >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>> >>>>> On Mon, Nov 12, 2012 at 4:28 PM, Thomas C. Schmidt >>>>> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> after the - somewhat uninformed discussion at IETF85 - chairs asked >>>>>>me to >>>>>> restate requirements of a "fast handover solution" for Multicast >>>>>> Mobility. >>>>>> >>>>>> Here they are: >>>>>> >>>>>> (i) Handover should be fast (this is only true for a direct >>>>>>pMAG/AR >>>>>>to >>>>>> nMAG/AR solution such as >>>>>> >>>>>> >>>>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mult >>>>>>ic >>>>>>ast). >>>>>> >>>>>> (ii) Multicast handover should be fully synchronized with unicast >>>>>> handover >>>>>> (otherwise unicast and multicast states diverge as is a well-known >>>>>>issue >>>>>> for >>>>>> the RAMS-approach, i.e., >>>>>> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). >>>>>> >>>>>> (iii) Multicast handover solutions should tightly integrate with >>>>>> unicast >>>>>> handover (only >>>>>> >>>>>> >>>>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mult >>>>>>ic >>>>>>ast >>>>>> integrates with PFMIPv6 and FMIPv6). >>>>>> >>>>>> (iv) Handover management should reuse standard mobility and >>>>>>multicast >>>>>> protocol operations for easy implementation and deployment >>>>>> >>>>>> >>>>>>(http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mul >>>>>>ti >>>>>>cast >>>>>> introduced the use of standard IGMP/MLD records for context >>>>>>description >>>>>> in >>>>>> transfer, which has been copied several times). >>>>>> >>>>>> (v) Multicast handover management should integrate ASM and SSM, as >>>>>>well >>>>>> as >>>>>> IPv4 (IGMP) and IPv6 (MLD), which is only provided by >>>>>> >>>>>> >>>>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mult >>>>>>ic >>>>>>ast. >>>>>> >>>>>> Based on these facts, chairs and AD proclaimed to re-decide on >>>>>>future >>>>>> paths >>>>>> for Multimob fast handover solutions. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Thomas >>>>>> -- >>>>>> >>>>>> Prof. Dr. Thomas C. Schmidt >>>>>> =B0 Hamburg University of Applied Sciences Berline= r >>>>>>Tor 7 >>>>>> =B0 >>>>>> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, >>>>>>Germany >>>>>> =B0 >>>>>> =B0 http://www.haw-hamburg.de/inet Fon: >>>>>>+49-40-42875-8452 >>>>>> =B0 >>>>>> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: >>>>>>+49-40-42875-8409 >>>>>> =B0 >>>>>> _______________________________________________ >>>>>> 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, >>>>Germany =B0 >>>> =B0 http://www.haw-hamburg.de/inet Fon: >>>>+49-40-42875-8452 =B0 >>>> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: >>>>+49-40-42875-8409 =B0 >>>_______________________________________________ >>>multimob mailing list >>>multimob@ietf.org >>>https://www.ietf.org/mailman/listinfo/multimob >> From stig@venaas.com Tue Nov 27 10:53:49 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C9421F85E8 for ; Tue, 27 Nov 2012 10:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mca2OudM0xuh for ; Tue, 27 Nov 2012 10:53:48 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id A2D9A21F81FF for ; Tue, 27 Nov 2012 10:53:34 -0800 (PST) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id 639C87FCF; Tue, 27 Nov 2012 19:53:30 +0100 (CET) Message-ID: <50B50C24.3010801@venaas.com> Date: Tue, 27 Nov 2012 10:53:24 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Rajeev Koodli (rkoodli)" References: <7C52FDEBC843C44DBAF2CA6A30662C6D0D2BDD@xmb-aln-x04.cisco.com> In-Reply-To: <7C52FDEBC843C44DBAF2CA6A30662C6D0D2BDD@xmb-aln-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "multimob@ietf.org" , "Thomas C. Schmidt" Subject: Re: [multimob] Fast Handover Solutions X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 18:53:50 -0000 On 11/27/2012 10:19 AM, Rajeev Koodli (rkoodli) wrote: > > Thanks for checking. > > To avoid the confusion, kindly rename the draft appropriately. > The draft title and the draft name should be consistent, and not mislead, > as it does now. It's a bit misleading, but the name does not matter much. The RFC won't have the draft name mentioned anywhere. Can't we rather discuss how the two real fast handover drafts meet the requirements? Stig > > -Rajeev > > > On 11/27/12 9:24 AM, "Behcet Sarikaya" wrote: > >> Hi Rajeev, >> >> I checked again. >> The charter item is about PMIPv6 handover optimizations, not on fast >> handover. >> >> The draft name should have been handover-optimizations not fast-handover. >> >> Sorry about that because I had suggested this draft name. >> >> Without realizing that it would cause so much trouble. >> >> I repeat here again, the draft title did not change and the draft >> content is reflected in the title. This is the most important thing. >> >> >> Regards, >> >> Behcet >> >> On Mon, Nov 26, 2012 at 6:07 PM, Rajeev Koodli (rkoodli) >> wrote: >>> >>> >>> Hi Behcet, >>> >>> On 11/26/12 1:46 PM, "Behcet Sarikaya" wrote: >>> >>>> On Mon, Nov 19, 2012 at 6:27 PM, Thomas C. Schmidt >>>> wrote: >>>>> Hi Behcet, >>>>> >>>>> these requirements are for a fast handover solution, i.e., a protocol >>>>> that >>>>> operates a *handover* in a *fast* manner. >>>>> >>>>> I agree that draft-ietf-multimob-fast-handover does not meet the >>>>> requirements, but had written earlier on the list that the name of >>>>> this >>>>> draft is misleading in two ways: (i) draft-ietf-multimob-fast-handover >>>>> is >>>>> not a fast handover solution, and (ii) the name "fast handover" is >>>>> tied >>>>> to >>>>> RFC5568/RFC5949-like schemes for good reasons. >>>>> >>>> >>>> The draft title contains ... handover optimization ... and it reflects >>>> its content. >>>> We asked for this WG draft name because of the charter item to which >>>> it corresponds. >>> >>> Sorry, which charter item has "fast-handover"? >>> Could you clarify? >>> >>> Thanks. >>> >>> -Rajeev >>> >>> >>> >>>> >>>> I think this clarifies your confusion. >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>>> Cheers, >>>>> >>>>> Thomas >>>>> >>>>> >>>>> On 20.11.2012 00:09, Behcet Sarikaya wrote: >>>>>> >>>>>> Hi Thomas, >>>>>> >>>>>> It seems that these requirements are for >>>>>> >>>>>> draft-schmidt-multimob-fmipv6-pfmipv6-multicast >>>>>> >>>>>> and not for >>>>>> draft-ietf-multimob-fast-handover. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Behcet >>>>>> >>>>>> On Mon, Nov 12, 2012 at 4:28 PM, Thomas C. Schmidt >>>>>> wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> after the - somewhat uninformed discussion at IETF85 - chairs asked >>>>>>> me to >>>>>>> restate requirements of a "fast handover solution" for Multicast >>>>>>> Mobility. >>>>>>> >>>>>>> Here they are: >>>>>>> >>>>>>> (i) Handover should be fast (this is only true for a direct >>>>>>> pMAG/AR >>>>>>> to >>>>>>> nMAG/AR solution such as >>>>>>> >>>>>>> >>>>>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mult >>>>>>> ic >>>>>>> ast). >>>>>>> >>>>>>> (ii) Multicast handover should be fully synchronized with unicast >>>>>>> handover >>>>>>> (otherwise unicast and multicast states diverge as is a well-known >>>>>>> issue >>>>>>> for >>>>>>> the RAMS-approach, i.e., >>>>>>> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). >>>>>>> >>>>>>> (iii) Multicast handover solutions should tightly integrate with >>>>>>> unicast >>>>>>> handover (only >>>>>>> >>>>>>> >>>>>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mult >>>>>>> ic >>>>>>> ast >>>>>>> integrates with PFMIPv6 and FMIPv6). >>>>>>> >>>>>>> (iv) Handover management should reuse standard mobility and >>>>>>> multicast >>>>>>> protocol operations for easy implementation and deployment >>>>>>> >>>>>>> >>>>>>> (http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mul >>>>>>> ti >>>>>>> cast >>>>>>> introduced the use of standard IGMP/MLD records for context >>>>>>> description >>>>>>> in >>>>>>> transfer, which has been copied several times). >>>>>>> >>>>>>> (v) Multicast handover management should integrate ASM and SSM, as >>>>>>> well >>>>>>> as >>>>>>> IPv4 (IGMP) and IPv6 (MLD), which is only provided by >>>>>>> >>>>>>> >>>>>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mult >>>>>>> ic >>>>>>> ast. >>>>>>> >>>>>>> Based on these facts, chairs and AD proclaimed to re-decide on >>>>>>> future >>>>>>> paths >>>>>>> for Multimob fast handover solutions. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> 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 >>>>>>> ° >>>>>>> _______________________________________________ >>>>>>> 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 >>> > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From rkoodli@cisco.com Tue Nov 27 11:23:07 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50ED21F85FE for ; Tue, 27 Nov 2012 11:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqPIbA2whBCH for ; Tue, 27 Nov 2012 11:23:07 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C6C2521F85CC for ; Tue, 27 Nov 2012 11:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7410; q=dns/txt; s=iport; t=1354044186; x=1355253786; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=nyviDYmSt55K7IR7gPfvfjvkhq8hePVzFfl3255/e9Y=; b=fgmnEH+IkjzWD3tfBDxduh5MKdFi+6FSAFkGYLHCeSkMjuX2BOppGX19 MUbdRwJau68JF0iMrDA0QWiggwU7ld3hDHQEQ5yHgggiwi6CxV1hiO+mX dNTpHnpi22cUc/OhvpvzVIXX+G48nnlqu0m/uk3jv7FyL/r/HDhlHdjnE U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJkStVCtJV2Y/2dsb2JhbABFFsAIFnOCHgEBAQQBAQFrCxIBCBgKRQYLJQIECgQFCBOHYAMPDLAYhmQNiVSLUWmDYGEDiCmMA4JxihgDhQ2CcIIg X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="146749225" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 27 Nov 2012 19:23:06 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qARJN6Yg011867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 19:23:06 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.168]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 13:23:05 -0600 From: "Rajeev Koodli (rkoodli)" To: Stig Venaas Thread-Topic: [multimob] Fast Handover Solutions Thread-Index: AQHNwSUhIilrHwuomkScmGZZlY53rpfyOBMAgAAV8ICACtNhAP//pgYAgAGjAoD//44ZgIAAiroA//+HC4A= Date: Tue, 27 Nov 2012 19:23:05 +0000 Message-ID: <7C52FDEBC843C44DBAF2CA6A30662C6D0D2C1F@xmb-aln-x04.cisco.com> In-Reply-To: <50B50C24.3010801@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.82.61] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multimob@ietf.org" , "Thomas C. Schmidt" Subject: Re: [multimob] Fast Handover Solutions X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 19:23:08 -0000 Hi Stig, On 11/27/12 10:53 AM, "Stig Venaas" wrote: >On 11/27/2012 10:19 AM, Rajeev Koodli (rkoodli) wrote: >> >> Thanks for checking. >> >> To avoid the confusion, kindly rename the draft appropriately. >> The draft title and the draft name should be consistent, and not >>mislead, >> as it does now. > >It's a bit misleading, but the name does not matter much. The RFC won't >have the draft name mentioned anywhere. IMHO, that's not a reason to be sloppy and misleading. You didn't say what's the issue with using the appropriate draft name? > >Can't we rather discuss how the two real fast handover drafts meet >the requirements? I admit I am not on this alias much. I don't understand what is considered "fast handover" here. Based on what I have read, it's supposed to be a closed issue, and the WG is moving on with the WG ID that is called "*-fast-handover-*". And, I have an issue with this misleading naming suggested/adopted by the chairs. Please fix the name. That's it! :-) -Rajeev > >Stig > >> >> -Rajeev >> >> >> On 11/27/12 9:24 AM, "Behcet Sarikaya" wrote: >> >>> Hi Rajeev, >>> >>> I checked again. >>> The charter item is about PMIPv6 handover optimizations, not on fast >>> handover. >>> >>> The draft name should have been handover-optimizations not >>>fast-handover. >>> >>> Sorry about that because I had suggested this draft name. >>> >>> Without realizing that it would cause so much trouble. >>> >>> I repeat here again, the draft title did not change and the draft >>> content is reflected in the title. This is the most important thing. >>> >>> >>> Regards, >>> >>> Behcet >>> >>> On Mon, Nov 26, 2012 at 6:07 PM, Rajeev Koodli (rkoodli) >>> wrote: >>>> >>>> >>>> Hi Behcet, >>>> >>>> On 11/26/12 1:46 PM, "Behcet Sarikaya" wrote: >>>> >>>>> On Mon, Nov 19, 2012 at 6:27 PM, Thomas C. Schmidt >>>>> wrote: >>>>>> Hi Behcet, >>>>>> >>>>>> these requirements are for a fast handover solution, i.e., a >>>>>>protocol >>>>>> that >>>>>> operates a *handover* in a *fast* manner. >>>>>> >>>>>> I agree that draft-ietf-multimob-fast-handover does not meet the >>>>>> requirements, but had written earlier on the list that the name of >>>>>> this >>>>>> draft is misleading in two ways: (i) >>>>>>draft-ietf-multimob-fast-handover >>>>>> is >>>>>> not a fast handover solution, and (ii) the name "fast handover" is >>>>>> tied >>>>>> to >>>>>> RFC5568/RFC5949-like schemes for good reasons. >>>>>> >>>>> >>>>> The draft title contains ... handover optimization ... and it >>>>>reflects >>>>> its content. >>>>> We asked for this WG draft name because of the charter item to which >>>>> it corresponds. >>>> >>>> Sorry, which charter item has "fast-handover"? >>>> Could you clarify? >>>> >>>> Thanks. >>>> >>>> -Rajeev >>>> >>>> >>>> >>>>> >>>>> I think this clarifies your confusion. >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>> >>>>>> Cheers, >>>>>> >>>>>> Thomas >>>>>> >>>>>> >>>>>> On 20.11.2012 00:09, Behcet Sarikaya wrote: >>>>>>> >>>>>>> Hi Thomas, >>>>>>> >>>>>>> It seems that these requirements are for >>>>>>> >>>>>>> draft-schmidt-multimob-fmipv6-pfmipv6-multicast >>>>>>> >>>>>>> and not for >>>>>>> draft-ietf-multimob-fast-handover. >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Behcet >>>>>>> >>>>>>> On Mon, Nov 12, 2012 at 4:28 PM, Thomas C. Schmidt >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> after the - somewhat uninformed discussion at IETF85 - chairs >>>>>>>>asked >>>>>>>> me to >>>>>>>> restate requirements of a "fast handover solution" for Multicast >>>>>>>> Mobility. >>>>>>>> >>>>>>>> Here they are: >>>>>>>> >>>>>>>> (i) Handover should be fast (this is only true for a direct >>>>>>>> pMAG/AR >>>>>>>> to >>>>>>>> nMAG/AR solution such as >>>>>>>> >>>>>>>> >>>>>>>>=20 >>>>>>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mu >>>>>>>>lt >>>>>>>> ic >>>>>>>> ast). >>>>>>>> >>>>>>>> (ii) Multicast handover should be fully synchronized with >>>>>>>>unicast >>>>>>>> handover >>>>>>>> (otherwise unicast and multicast states diverge as is a well-known >>>>>>>> issue >>>>>>>> for >>>>>>>> the RAMS-approach, i.e., >>>>>>>> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). >>>>>>>> >>>>>>>> (iii) Multicast handover solutions should tightly integrate >>>>>>>>with >>>>>>>> unicast >>>>>>>> handover (only >>>>>>>> >>>>>>>> >>>>>>>>=20 >>>>>>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mu >>>>>>>>lt >>>>>>>> ic >>>>>>>> ast >>>>>>>> integrates with PFMIPv6 and FMIPv6). >>>>>>>> >>>>>>>> (iv) Handover management should reuse standard mobility and >>>>>>>> multicast >>>>>>>> protocol operations for easy implementation and deployment >>>>>>>> >>>>>>>> >>>>>>>>=20 >>>>>>>>(http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-m >>>>>>>>ul >>>>>>>> ti >>>>>>>> cast >>>>>>>> introduced the use of standard IGMP/MLD records for context >>>>>>>> description >>>>>>>> in >>>>>>>> transfer, which has been copied several times). >>>>>>>> >>>>>>>> (v) Multicast handover management should integrate ASM and >>>>>>>>SSM, as >>>>>>>> well >>>>>>>> as >>>>>>>> IPv4 (IGMP) and IPv6 (MLD), which is only provided by >>>>>>>> >>>>>>>> >>>>>>>>=20 >>>>>>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mu >>>>>>>>lt >>>>>>>> ic >>>>>>>> ast. >>>>>>>> >>>>>>>> Based on these facts, chairs and AD proclaimed to re-decide on >>>>>>>> future >>>>>>>> paths >>>>>>>> for Multimob fast handover solutions. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Thomas >>>>>>>> -- >>>>>>>> >>>>>>>> Prof. Dr. Thomas C. Schmidt >>>>>>>> =B0 Hamburg University of Applied Sciences >>>>>>>>Berliner >>>>>>>> Tor 7 >>>>>>>> =B0 >>>>>>>> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg= , >>>>>>>> Germany >>>>>>>> =B0 >>>>>>>> =B0 http://www.haw-hamburg.de/inet Fon: >>>>>>>> +49-40-42875-8452 >>>>>>>> =B0 >>>>>>>> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: >>>>>>>> +49-40-42875-8409 >>>>>>>> =B0 >>>>>>>> _______________________________________________ >>>>>>>> multimob mailing list >>>>>>>> multimob@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/multimob >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Prof. Dr. Thomas C. Schmidt >>>>>> =B0 Hamburg University of Applied Sciences Berline= r >>>>>> Tor >>>>>> 7 =B0 >>>>>> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, >>>>>> Germany =B0 >>>>>> =B0 http://www.haw-hamburg.de/inet Fon: >>>>>> +49-40-42875-8452 =B0 >>>>>> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: >>>>>> +49-40-42875-8409 =B0 >>>>> _______________________________________________ >>>>> multimob mailing list >>>>> multimob@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/multimob >>>> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> > From william.atwood@concordia.ca Tue Nov 27 11:33:44 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE8721F8686 for ; Tue, 27 Nov 2012 11:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plovOvyBPBwV for ; Tue, 27 Nov 2012 11:33:43 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.94]) by ietfa.amsl.com (Postfix) with ESMTP id 32A3C21F86B5 for ; Tue, 27 Nov 2012 11:33:43 -0800 (PST) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id qARJXdV5022195 for ; Tue, 27 Nov 2012 14:33:40 -0500 Message-ID: <50B515A5.2020201@concordia.ca> Date: Tue, 27 Nov 2012 14:33:57 -0500 From: John William Atwood Organization: Concordia University, Montreal User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: multimob@ietf.org References: <7C52FDEBC843C44DBAF2CA6A30662C6D0D2C1F@xmb-aln-x04.cisco.com> In-Reply-To: <7C52FDEBC843C44DBAF2CA6A30662C6D0D2C1F@xmb-aln-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2012/11/27 14:33:40 EST Subject: Re: [multimob] Fast Handover Solutions X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 19:33:44 -0000 As an aside, while the draft name does not appear in the RFC, it _will_ appear in the datatracker entry for the RFC (once the RFC is published). I support Rajeev's suggestion to fix the name of the draft (even though the draft is already at the -03 level). Bill On 11/27/2012 2:23 PM, Rajeev Koodli (rkoodli) wrote: > > Hi Stig, > > > On 11/27/12 10:53 AM, "Stig Venaas" wrote: > >> On 11/27/2012 10:19 AM, Rajeev Koodli (rkoodli) wrote: >>> >>> Thanks for checking. >>> >>> To avoid the confusion, kindly rename the draft appropriately. >>> The draft title and the draft name should be consistent, and not >>> mislead, >>> as it does now. >> >> It's a bit misleading, but the name does not matter much. The RFC won't >> have the draft name mentioned anywhere. > > IMHO, that's not a reason to be sloppy and misleading. > You didn't say what's the issue with using the appropriate draft name? > > >> >> Can't we rather discuss how the two real fast handover drafts meet >> the requirements? > > I admit I am not on this alias much. > > I don't understand what is considered "fast handover" here. > Based on what I have read, it's supposed to be a closed issue, and the WG > is moving on with the WG ID that is called "*-fast-handover-*". > And, I have an issue with this misleading naming suggested/adopted by the > chairs. > Please fix the name. > > That's it! :-) > > -Rajeev > > > > >> >> Stig >> >>> >>> -Rajeev >>> >>> >>> On 11/27/12 9:24 AM, "Behcet Sarikaya" wrote: >>> >>>> Hi Rajeev, >>>> >>>> I checked again. >>>> The charter item is about PMIPv6 handover optimizations, not on fast >>>> handover. >>>> >>>> The draft name should have been handover-optimizations not >>>> fast-handover. >>>> >>>> Sorry about that because I had suggested this draft name. >>>> >>>> Without realizing that it would cause so much trouble. >>>> >>>> I repeat here again, the draft title did not change and the draft >>>> content is reflected in the title. This is the most important thing. >>>> >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>> On Mon, Nov 26, 2012 at 6:07 PM, Rajeev Koodli (rkoodli) >>>> wrote: >>>>> >>>>> >>>>> Hi Behcet, >>>>> >>>>> On 11/26/12 1:46 PM, "Behcet Sarikaya" wrote: >>>>> >>>>>> On Mon, Nov 19, 2012 at 6:27 PM, Thomas C. Schmidt >>>>>> wrote: >>>>>>> Hi Behcet, >>>>>>> >>>>>>> these requirements are for a fast handover solution, i.e., a >>>>>>> protocol >>>>>>> that >>>>>>> operates a *handover* in a *fast* manner. >>>>>>> >>>>>>> I agree that draft-ietf-multimob-fast-handover does not meet the >>>>>>> requirements, but had written earlier on the list that the name of >>>>>>> this >>>>>>> draft is misleading in two ways: (i) >>>>>>> draft-ietf-multimob-fast-handover >>>>>>> is >>>>>>> not a fast handover solution, and (ii) the name "fast handover" is >>>>>>> tied >>>>>>> to >>>>>>> RFC5568/RFC5949-like schemes for good reasons. >>>>>>> >>>>>> >>>>>> The draft title contains ... handover optimization ... and it >>>>>> reflects >>>>>> its content. >>>>>> We asked for this WG draft name because of the charter item to which >>>>>> it corresponds. >>>>> >>>>> Sorry, which charter item has "fast-handover"? >>>>> Could you clarify? >>>>> >>>>> Thanks. >>>>> >>>>> -Rajeev >>>>> >>>>> >>>>> >>>>>> >>>>>> I think this clarifies your confusion. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Behcet >>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Thomas >>>>>>> >>>>>>> >>>>>>> On 20.11.2012 00:09, Behcet Sarikaya wrote: >>>>>>>> >>>>>>>> Hi Thomas, >>>>>>>> >>>>>>>> It seems that these requirements are for >>>>>>>> >>>>>>>> draft-schmidt-multimob-fmipv6-pfmipv6-multicast >>>>>>>> >>>>>>>> and not for >>>>>>>> draft-ietf-multimob-fast-handover. >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Behcet >>>>>>>> >>>>>>>> On Mon, Nov 12, 2012 at 4:28 PM, Thomas C. Schmidt >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> after the - somewhat uninformed discussion at IETF85 - chairs >>>>>>>>> asked >>>>>>>>> me to >>>>>>>>> restate requirements of a "fast handover solution" for Multicast >>>>>>>>> Mobility. >>>>>>>>> >>>>>>>>> Here they are: >>>>>>>>> >>>>>>>>> (i) Handover should be fast (this is only true for a direct >>>>>>>>> pMAG/AR >>>>>>>>> to >>>>>>>>> nMAG/AR solution such as >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mu >>>>>>>>> lt >>>>>>>>> ic >>>>>>>>> ast). >>>>>>>>> >>>>>>>>> (ii) Multicast handover should be fully synchronized with >>>>>>>>> unicast >>>>>>>>> handover >>>>>>>>> (otherwise unicast and multicast states diverge as is a well-known >>>>>>>>> issue >>>>>>>>> for >>>>>>>>> the RAMS-approach, i.e., >>>>>>>>> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover). >>>>>>>>> >>>>>>>>> (iii) Multicast handover solutions should tightly integrate >>>>>>>>> with >>>>>>>>> unicast >>>>>>>>> handover (only >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mu >>>>>>>>> lt >>>>>>>>> ic >>>>>>>>> ast >>>>>>>>> integrates with PFMIPv6 and FMIPv6). >>>>>>>>> >>>>>>>>> (iv) Handover management should reuse standard mobility and >>>>>>>>> multicast >>>>>>>>> protocol operations for easy implementation and deployment >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> (http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-m >>>>>>>>> ul >>>>>>>>> ti >>>>>>>>> cast >>>>>>>>> introduced the use of standard IGMP/MLD records for context >>>>>>>>> description >>>>>>>>> in >>>>>>>>> transfer, which has been copied several times). >>>>>>>>> >>>>>>>>> (v) Multicast handover management should integrate ASM and >>>>>>>>> SSM, as >>>>>>>>> well >>>>>>>>> as >>>>>>>>> IPv4 (IGMP) and IPv6 (MLD), which is only provided by >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mu >>>>>>>>> lt >>>>>>>>> ic >>>>>>>>> ast. >>>>>>>>> >>>>>>>>> Based on these facts, chairs and AD proclaimed to re-decide on >>>>>>>>> future >>>>>>>>> paths >>>>>>>>> for Multimob fast handover solutions. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> ° >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>> >>> >>> _______________________________________________ >>> 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 > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From sarikaya2012@gmail.com Wed Nov 28 08:42:38 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E00221F88E0; Wed, 28 Nov 2012 08:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INN3nFcF5ji1; Wed, 28 Nov 2012 08:42:37 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E2F1321F88D0; Wed, 28 Nov 2012 08:42:36 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so14110665ieb.31 for ; Wed, 28 Nov 2012 08:42:36 -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:cc :content-type; bh=sqL25+UswCUbr1/2tx+n3iEekb1VcwAwrj9Kn4CObUM=; b=glcEa3pCpQHr3uLZc/1hgRLTrna4v1wHag7utAMmZjS8G+vGxzyhujFFXJk/yAKa3H GTYF/QSgeElng5j0B50DTUunM5rbVkugGfOoQrjRaTWcYoBHNtQ69dB3Xu4VcLRO99xy luPlEeK23iz9JwAM06Sd2r2MFpr5geLd8PUGpoTE7DOHNdQpeCr9QMPJSqLotn9zB0s2 tn4lIKK+R51SMz9DdpT8DcwHaF/Gn3avN5dok9rUtUhn/PsYeDD6u+6MaB+U60dIKgn3 rperqWK1OmcNrg+J63VS4wOS7PGRUIHIxVFrWRn7YKGpzKyWk9M4gCpH2lMgoIMeI5gW 8H5Q== MIME-Version: 1.0 Received: by 10.50.173.37 with SMTP id bh5mr20133696igc.45.1354120956490; Wed, 28 Nov 2012 08:42:36 -0800 (PST) Received: by 10.231.10.204 with HTTP; Wed, 28 Nov 2012 08:42:36 -0800 (PST) Date: Wed, 28 Nov 2012 10:42:36 -0600 Message-ID: From: Behcet Sarikaya To: iesg-secretary@ietf.org Content-Type: multipart/alternative; boundary=e89a8f6464eb98331204cf90da17 Cc: multimob@ietf.org Subject: [multimob] WG draft name change request X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 16:42:38 -0000 --e89a8f6464eb98331204cf90da17 Content-Type: text/plain; charset=ISO-8859-1 Dear IESG secretary, Multimob WG has decided to change the following WG draft name: http://tools.ietf.org/html/draft-ietf-multimob-fast-handover-03 from draft-ietf-multimob-fast-handover to draft-ietf-multimob-handover-optimization We hope that it is possible to do this change without asking the authors to resubmit their draft with the new draft name. Regards, Behcet --e89a8f6464eb98331204cf90da17 Content-Type: text/html; charset=ISO-8859-1 Dear IESG secretary,

Multimob WG has decided to change the following WG draft name:

http://tools.ietf.org/html/draft-ietf-multimob-fast-handover-03

from draft-ietf-multimob-fast-handover

to draft-ietf-multimob-handover-optimization

We hope that it is possible to do this change without asking the authors to resubmit their draft with the new draft name.

Regards,

Behcet --e89a8f6464eb98331204cf90da17-- From sarikaya2012@gmail.com Wed Nov 28 08:59:57 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2018B21F8931 for ; Wed, 28 Nov 2012 08:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thqhLztWWRMp for ; Wed, 28 Nov 2012 08:59:56 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9160F21F8930 for ; Wed, 28 Nov 2012 08:59:56 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so14148850ieb.31 for ; Wed, 28 Nov 2012 08:59:56 -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=KFG+6siF9Tnc44KJfXVzFcVm0hIVkMRndE2zVm7xFNQ=; b=f+FfKi15JQzOgNk/7LTaYydmB5ZhLdgJyHkWJPjjkFoNljwevfvHl7bQO4iNjFkqHb kLD7qgG+JfX3L0DC/n4ChdOB6FoT0jGAGdOOAIRfHF7THUtqAip08l0QVGHz3kYFs0H6 9rbjucaXyobJzMEKIuLkLsZhfGPSUDTMA4CeWpdBXYGIYZRnHWqgePdFxPe9jHO/oad1 OY7zLIEgpgTkAKqMtF1/maLErCyB+1YJyvPLMooB3aQA0aLilz9o4n8NzbUjK3i1WUp7 z0RTQ3jEyslXptzWRGW9THDayCq+Ubcz/TkGt6MbVc8jfoHdNQ6Gb/LOtbPWu2V5we7x s0ug== MIME-Version: 1.0 Received: by 10.50.40.138 with SMTP id x10mr22651078igk.41.1354121996117; Wed, 28 Nov 2012 08:59:56 -0800 (PST) Received: by 10.231.10.204 with HTTP; Wed, 28 Nov 2012 08:59:55 -0800 (PST) In-Reply-To: References: Date: Wed, 28 Nov 2012 10:59:55 -0600 Message-ID: From: Behcet Sarikaya To: =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= Content-Type: multipart/alternative; boundary=14dae93409018fa86c04cf9118c1 Cc: multimob@ietf.org, draft-ietf-multimob-fast-handover@tools.ietf.org Subject: [multimob] Fwd: WG draft name change request X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 16:59:57 -0000 --14dae93409018fa86c04cf9118c1 Content-Type: text/plain; charset=ISO-8859-1 Hi Carlos, Please submit http://tools.ietf.org/html/draft-ietf-multimob-fast-handover-03.txt with a new draft name: draft-ietf-multimob-handover-optimization.00.txt This new name will replace the existing http://tools.ietf.org/html/draft-ietf-multimob-fast-handover-03.txt. Regards, Behcet ---------- Forwarded message ---------- From: Behcet Sarikaya Date: Wed, Nov 28, 2012 at 10:42 AM Subject: WG draft name change request To: iesg-secretary@ietf.org Cc: multimob@ietf.org, Brian Haberman Dear IESG secretary, Multimob WG has decided to change the following WG draft name: http://tools.ietf.org/html/draft-ietf-multimob-fast-handover-03 from draft-ietf-multimob-fast-handover to draft-ietf-multimob-handover-optimization We hope that it is possible to do this change without asking the authors to resubmit their draft with the new draft name. Regards, Behcet --14dae93409018fa86c04cf9118c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlos,

Please submit
http://tools.ietf.org/html/draft-i= etf-multimob-fast-handover-03.txt

with a new draft name:

draft-ietf-multimob-handover-optimization.00.txt

This new name will = replace the existing http://tools.ietf.org/html/draft-ietf-multimob-fa= st-handover-03.txt.

Regards,

Behcet

---------- For= warded message ----------
From: Behcet Sar= ikaya <s= arikaya2012@gmail.com>
Date: Wed, Nov 28, 2012 at 10:42 AM
Subject: WG draft name change reques= t
To: iesg-secretary@ietf.org=
Cc: multimob@ietf.org, Bri= an Haberman <brian@innovatio= nslab.net>


Dear IESG secretary,

Multimob WG has decided to change the f= ollowing WG draft name:

http://tools.ietf.org/htm= l/draft-ietf-multimob-fast-handover-03

from draft-ietf-multimob-fast-handover

to draft-ietf-multimob-ha= ndover-optimization

We hope that it is possible to do this change wi= thout asking the authors to resubmit their draft with the new draft name.
Regards,

Behcet

--14dae93409018fa86c04cf9118c1-- From sarikaya2012@gmail.com Wed Nov 28 09:09:29 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FF021F8897 for ; Wed, 28 Nov 2012 09:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYFqlkppm3hK for ; Wed, 28 Nov 2012 09:09:29 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2FADB21F88B8 for ; Wed, 28 Nov 2012 09:09:26 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so10948442iaf.31 for ; Wed, 28 Nov 2012 09:09:26 -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=LIl3sgxDWulpF1lk3Stc+ROWte4xOz3AKb7ZQ5/FKdU=; b=TFRmvrXBU/THYs9zTR83VetXGyBvmbR+31b+XK5YPRh+jUjz44ueplv2mfiQQqbUeg WSS+ELoFue8UgJaUcfMQrP8oJUQ+mr5g5UcJhjhDUUJTL5d2J47csF4ilwp40UROV8Od c5bTspzT9lXTjE6MmfVKhyRgbY3ylWg4+S2p2NjkEbeLKOvONOm3q9gifUs+X1iUPykn /IZ80tt+RBgozWR6hMgwCFoo4ZpL5ssSpfZopsgIOQp+5f3d9Mbo38ZBg8Qav3gO05lF j7SNE8aa0bsVIl5rrLEdgumXbq+LwKFStvqAoU92PTtGQCuhdYl7ahD3hp8i4wcStS2F 4K+g== MIME-Version: 1.0 Received: by 10.50.40.138 with SMTP id x10mr22682238igk.41.1354122565949; Wed, 28 Nov 2012 09:09:25 -0800 (PST) Received: by 10.231.10.204 with HTTP; Wed, 28 Nov 2012 09:09:25 -0800 (PST) In-Reply-To: References: Date: Wed, 28 Nov 2012 11:09:25 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: multipart/alternative; boundary=14dae9340901869a2f04cf913aac Subject: Re: [multimob] Concluding WG adoption calls X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 17:09:30 -0000 --14dae9340901869a2f04cf913aac Content-Type: text/plain; charset=ISO-8859-1 Folks, After going through the results again, it has been decided that there was enough support on http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast-07 to become a WG draft. Authors of draft-schmidt-multimob-fmipv6-pfmipv6-multicast-07, please submit your draft as WG draft with experimental as the intended status. Regards, Behcet On Tue, Sep 11, 2012 at 10:19 AM, Behcet Sarikaya wrote: > Hi all, > > The chairs have gone through all the votes and in consultation with > Brian, our AD, we came to the conclusion that there is not really > enough people voting to say we have a rough > consensus right now on adopting any of these two drafts. > > Regards, > > Stig & Behcet > --14dae9340901869a2f04cf913aac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Folks,

After going through the results again, it has been decided th= at
there was enough support on
http://tools.ietf.org/= html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast-07
to become a WG draft.

Authors of draft-schmidt-multimob-fmipv6-pfmip= v6-multicast-07, please submit your draft as

WG draft with experimen= tal as the intended status.

Regards,

Behcet

On Tue, Sep 11, 2012 at 10:19 AM, Behcet Sarikaya <sarikaya2012@gmail= .com> wrote:
Hi all,

The chairs have gone through all the votes and in consultation with
Brian, our AD, we came to the conclusion that there is not really
enough people voting to say we have a rough
consensus right now on adopting any of these two drafts.

Regards,

Stig & Behcet

--14dae9340901869a2f04cf913aac-- From cjbc@it.uc3m.es Thu Nov 29 00:43:26 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE9721F8B5E for ; Thu, 29 Nov 2012 00:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L29X-H0DDBFY for ; Thu, 29 Nov 2012 00:43:25 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5E68021F8B18 for ; Thu, 29 Nov 2012 00:43:25 -0800 (PST) X-uc3m-safe: yes Received: from [172.24.10.154] (public.eurecom.fr [193.55.113.196]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 0DE537688FE; Thu, 29 Nov 2012 09:43:23 +0100 (CET) Message-ID: <1354178602.3741.47.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: sarikaya@ieee.org Date: Thu, 29 Nov 2012 09:43:22 +0100 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-jMHc1prpytyqDCztsfA1" X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19402.006 X-TM-AS-Result: No--16.394-7.0-31-1 X-imss-scan-details: No--16.394-7.0-31-1 Cc: multimob@ietf.org, draft-ietf-multimob-fast-handover@tools.ietf.org Subject: Re: [multimob] Fwd: WG draft name change request X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 08:43:26 -0000 --=-jMHc1prpytyqDCztsfA1 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Behcet, We have just done it. Thanks, Carlos On Wed, 2012-11-28 at 10:59 -0600, Behcet Sarikaya wrote: > Hi Carlos, >=20 > Please submit > http://tools.ietf.org/html/draft-ietf-multimob-fast-handover-03.txt >=20 > with a new draft name: >=20 > draft-ietf-multimob-handover-optimization.00.txt >=20 > This new name will replace the existing > http://tools.ietf.org/html/draft-ietf-multimob-fast-handover-03.txt. >=20 > Regards, >=20 > Behcet >=20 > ---------- Forwarded message ---------- > From: Behcet Sarikaya > Date: Wed, Nov 28, 2012 at 10:42 AM > Subject: WG draft name change request > To: iesg-secretary@ietf.org > Cc: multimob@ietf.org, Brian Haberman >=20 >=20 > Dear IESG secretary, >=20 > Multimob WG has decided to change the following WG draft name: >=20 > http://tools.ietf.org/html/draft-ietf-multimob-fast-handover-03 >=20 > from draft-ietf-multimob-fast-handover >=20 > to draft-ietf-multimob-handover-optimization >=20 > We hope that it is possible to do this change without asking the authors = to > resubmit their draft with the new draft name. >=20 > Regards, >=20 > Behcet --=20 Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-jMHc1prpytyqDCztsfA1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlC3ICoACgkQNdy6TdFwT2cqkwCggWeDabhlmGZXRUCKBDMdJ686 yikAoOGk0xyv6swU0Rk2AlX7j0A5lkwr =b+Xa -----END PGP SIGNATURE----- --=-jMHc1prpytyqDCztsfA1-- From internet-drafts@ietf.org Thu Nov 29 08:49:01 2012 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC8221F88DF; Thu, 29 Nov 2012 08:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnnDhVabbjby; Thu, 29 Nov 2012 08:49:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E99B21F8AB5; Thu, 29 Nov 2012 08:49:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121129164901.6068.45286.idtracker@ietfa.amsl.com> Date: Thu, 29 Nov 2012 08:49:01 -0800 Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-handover-optimization-00.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 16:49:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multicast Mobility Working Group of the I= ETF. Title : PMIPv6 multicast handover optimization by the Subscripti= on Information Acquisition through the LMA (SIAL) Author(s) : Luis M. Contreras Carlos J. Bernardos Ignacio Soto Filename : draft-ietf-multimob-handover-optimization-00.txt Pages : 42 Date : 2012-11-29 Abstract: This document specifies a multicast handover optimization mechanism for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic to mobile nodes after handovers. The mechanism is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current Proxy Mobile IPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions being developed to avoid the tunnel convergence problem. Furthermore, they are also independent of the role played by the mobile access gateway within the multicast network (either acting as multicast listener discovery proxy or multicast router). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-handover-optimization There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-handover-optimization-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/