Re: [DMM] Review of draft-zuniga-dmm-gap-analysis-02

<karagian@cs.utwente.nl> Sun, 04 November 2012 19:27 UTC

Return-Path: <karagian@cs.utwente.nl>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9BC21F86DD for <dmm@ietfa.amsl.com>; Sun, 4 Nov 2012 11:27:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.204
X-Spam-Level:
X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_21=0.6]
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 gbehFsG4ur0P for <dmm@ietfa.amsl.com>; Sun, 4 Nov 2012 11:27:19 -0800 (PST)
Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 75AA521F86D5 for <dmm@ietf.org>; Sun, 4 Nov 2012 11:27:18 -0800 (PST)
Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 4 Nov 2012 20:27:19 +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 20:27:17 +0100
From: karagian@cs.utwente.nl
To: cjbc@it.uc3m.es, elena.demaria@telecomitalia.it
Thread-Topic: [DMM] Review of draft-zuniga-dmm-gap-analysis-02
Thread-Index: Ac22hgLN2+klwA8wTNyhbETk9W34bADDZtyAAErzD7M=
Date: Sun, 04 Nov 2012 19:27:17 +0000
Message-ID: <FF1A9612A94D5C4A81ED7DE1039AB80F2CC125AB@EXMBX01.ad.utwente.nl>
References: <36A93B31228D3B49B691AD31652BCAE9A5A6D86A7D@GRFMBX702BA020.griffon.local>, <1351930793.28330.4.camel@acorde.it.uc3m.es>
In-Reply-To: <1351930793.28330.4.camel@acorde.it.uc3m.es>
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
Cc: dmm@ietf.org
Subject: Re: [DMM] Review of draft-zuniga-dmm-gap-analysis-02
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Nov 2012 19:27:20 -0000

Hi all,

I have also reviewd draft-zuniga-dmm-gap-analysis-02. I think that this draft is usefull, but I have some comments:

1) the gap analysis should somehow use as context a generic framework, like the one introduced in http://www.ietf.org/id/draft-chan-dmm-framework-gap-analysis-05.txt and/or 
http://www.ietf.org/id/draft-liebsch-dmm-framework-analysis-00.txt.

2) Section 3, describes the limitations in current practices, by using the requirements specified in http://www.ietf.org/id/draft-ietf-dmm-requirements-02.txt.

However, by reviewing the descibed limitations of each existing solution, I have seen that these limitations are too briefly explained without focussing in detail on how each of these limitations relates to the given requirement.

3) As I already mentioned previously in emails sent to the list, more solutions could be included in this analysis, such as:

=> Shim6: Level 3 Multihoming Shim Protocol for IPv6 
http://www.rfc-editor.org/rfc/rfc5533.txt

=> LISP Mobile Node
http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt
Locator/ID Separation Protocol (LISP) 
http://www.ietf.org/id/draft-ietf-lisp-23.txt

=> Mobile IPv6 Fast Handovers
http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt
This is the draft that became then RFC5568, so no need to mention it.
http://www.rfc-editor.org/rfc/rfc5568.txt

=> Fast Handovers for Proxy Mobile IPv6 
http://www.rfc-editor.org/rfc/rfc5949.txt
=> Host Identity Protocol
http://www.rfc-editor.org/rfc/rfc4423.txt
http://www.rfc-editor.org/rfc/rfc5201.txt
http://www.rfc-editor.org/rfc/rfc6253.txt
http://www.rfc-editor.org/rfc/rfc5206.txt

=> IKEv2 Mobility and Multihoming Protocol (MOBIKE) 
http://www.rfc-editor.org/rfc/rfc4555.txt

=> GTPv2-C: 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 3GPP Evolved Packet System (EPS);  
Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3 (Release 11)
http://www.3gpp.org/ftp/Specs/archive/29_series/29.274/29274-b30.zip

=> Mobility solutions used for Cloud computing support

Best regards,
Georgios
________________________________________
Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Carlos Jesús Bernardos Cano [cjbc@it.uc3m.es]
Verzonden: zaterdag 3 november 2012 9:19
To: Demaria Elena
Cc: dmm@ietf.org
Onderwerp: Re: [DMM] Review of draft-zuniga-dmm-gap-analysis-02

Dear Elena,

Thanks a lot for your comments on our draft. Please, see some answers
below inline...

On Fri, 2012-11-02 at 09:40 +0100, Demaria Elena wrote:
> Hi all,
> here are some comments on draft-zuniga-dmm-gap-analysis-02.
>
> I have some doubts on current scope of section 2. In my opinion "how to deploy a mobility solution in a DMM fashion" is the gap analysis.

Well, our approach was to analyze to what extent main IP mobility
protocols could meet DMM requirements. In order to do so, we first
describe how these main IP solutions can operate/be deployed to work in
a DMM fashion. This is what we try to do in Section 2.

> Probably a section on existing mobility solutions (that rapidly covers main features) is needed but I would avoid to anticipate some considerations on the gap analysis itself. Just briefly describe what are the main features of the analyzed protocols.

We believe that it is important to understand what are the capabilities
in terms of distributed operation of main mobility solutions. This paves
the way for the actual gap analysis performed in Section 3.

> In the gap analysis itself (paragraph 3), for example, I found difficult to understand what is missing in term of functionalities. For example in 3.1.1 you say that REQ1 is not satisfied by MIP6, but you are not saying what  is missing. You said that in 2.1.1: "current Mobile IPv6 / NEMO specifications do not allow the use of multiple home agents by a mobile node simultaneously".

We sure can improve the text, and suggestions are highly welcome and
appreciated. Our rationale there is that current MIPv6/NEMO do not allow
to deploy distributed home agents and then enable the mobile node to
dynamically switch and benefit from using them. You can deploy multiple
home agents, but the mobile node will always be associated to a single
one at each moment. This is what it is missing.

>
> I would also have considered, for example, MIPv6 and its extensions as a whole instead of separating each component. What we are trying to understand here is if we can use some existing protocols and its currently defined extensions for DMM. I think it is useful to see which extension adds which feature but at the end of the document you should say something on a complete solution. Perhaps you can add some text in chapter 4 saying that a solution that considers protocol x plus extension y is well suited for DMM or that none of the available solutions meets all requirements.

That is indeed a possible option that we also did consider. But here we
thought there is a tradeoff between complexity of the text and clarity.
We wanted to keep the text as simple as possible and we also fear that
going into analyzing combinations of solutions might go into solution
space, which is not the goal of the gap analysis. We should just find
out if a DMM solution is actually required or if the DMM requirements
can be met with existing solutions.

>
> For REQ2 (for both MIPv6 and PMIPv6) you say that the solution is transparent to upper layers but in the table in paragraph 4 there is LIM (limited support). I think this is wrong. Non optimal routing is already considered in REQ1 and should not be part of REQ2.

It is true that this is not clear in this version. In the table we
wanted to highlight that even though MIPv6 and PMIPv6 are transparent to
upper layers, its use deploying multiple home agents/local mobility
anchors and trying to benefit from that "distributed" mode is not, as it
requires to change the home address. Maybe we can clarify this in
regards of the requirements and then update the table accordingly.

Thanks again for the comments.

Carlos

>
> Regards,
> Elena
>
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
>

--
Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

--
Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
Universidad Carlos III de Madrid