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: [email protected] [[email protected]] namens Carlos Jesús Bernardos Cano [[email protected]] Verzonden: zaterdag 3 november 2012 9:19 To: Demaria Elena Cc: [email protected] 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 <[email protected]> Universidad Carlos III de Madrid _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
