Re: [DMM] review on draft-ietf-dmm-best-practices-gap-analysis-02

Hi Jouni,

Thanks for your review and comments. Please see some comments from us
inline below.

On Sat, 2013-10-26 at 21:43 +0300, Jouni wrote:
> Folks,
> 
> I did some brief reading on the -02 version (mainly to trigger even
> some discussion!). Here are my initial comments.
> 
> I am quite pleased with the sections up to 5. Good stuff.
> 
> In Section 5.2. 
> 
>    whether the allocated IP addresses are anchored).  However, there are
>    ongoing IETF works that are proposing that the network could indicate
>    the different IP addresses properties during assignment procedures
>    [I-D.bhandari-dhc-class-based-prefix],
>    [I-D.korhonen-6man-prefix-properties].
> 
> * Here I would also reference to latest MPVD activities in Mif, since in my
>   mind PVDs could.. could'ish.. also be used to carry properties & information
>   about prefixes.

OK. We'll address this in the next revision.

> 
> * Anyway, I would like to stress in this section that even if we have individual
>   attempts to fix the gap, there is no solution in IETF.. not even close that 
>   would be accepted & endorsed by IETF.

OK. We'll add that in the next revision.

> 
> Section 5.8.
> 
>   "o  Existing solutions do only provide an optimal initial anchor
>       assignment, a gap being the lack of dynamic anchor change/new
>       anchor assignment.  Neither the HA switch nor the LMA runtime
>       assignment allow changing the anchor during an ongoing session."
> 
> * In theory MOBIKE could be used to switch from a gateway to another  
>   mid-session.. from the MN point of view. There is no protocol for the
>   network side (there _was_ an attempt to do a gw-to-gw thing years ago).
>   Agree that there is nothing for (P)MIPv6.

OK, we'll add a note mentioning that MOBIKE is capable of doing that.

> 
>   "o  Currently, there is no efficient mechanism specified by the IETF
>       that allows to dynamically discover the presence of nodes that can
>       play the role of anchor, discover their capabilities and allow the
>       selection of the most suitable one."
> 
> * Hmm, DHAAD? H-flag in RA? The MAP option in RAs? We do have multiple
>   mechanisms it seems. In some cases we can even distinguish between a
>   "local" vs. "normal" anchor. Using DHAAD one could use anycast to
>   locate topologically close HAs.

Agree. We'll add some text on the next revision.

> 
> * For RFC5685 allows us to do IKEv2 to anycast address. That combined to
>   RFC5026 would allow discover topologically close HA. Same for with
>   RFC4555 to enhance MOBIKE gateway selection. Routing infra  would be
>   used to select the "most suitable" from locality point of view.
> 
> * What is meant by the "capability" of an anchor? Local vs. non-local?
>   I do agree we only can distinguish between on-link HA vs. MAP vs.
>   something beyond on-link. And that is not much.
> 

See above.

> I would say the above existing mechanisms need to be reflected in the 
> document.

Agree. We'll try to explain the need for enhanced mechanisms in the next
revision of the draft.

> 
>   "o  The mobile node needs to simultaneously use multiple IP addresses,
>       which requires additional support which might not be available on
>       the mobile node's stack, especially for the case of network-based
>       solutions."
> 
> * This gap means what? Is the additional support what REQ2 is about?
>   Like giving a meaning to prefixes which are anchored and which not?

Yes, this gap refers to 5.2.

> 
>   "o  While existing network-based DMM practices may allow to deploy
>       multiple LMAs and dynamically select the best one, this requires
>       to still keep some centralization in the control plane, to access
>       on the policy store (as defined in RFC5213)."
> 
> * Ok.. so you are saying a subscriber database or AAA server, which is
>   central makes a mobility protocol centralized?

No, we just meant that a part of the control plane will remain
centralized. Thinking about control and data plane separation, we could 
have a distributed data plane and a centralized (or partially)
centralized data plane. Meaning that we do not have a 100% distributed
solution.

> 
> Since I got the feeling folks want to work more on the control and data
> plane separation, the summary should state the lack of solutions in
> that space more clearly (ok.. there is now stuff coming from Netext
> for PMIP but still).

OK, we'll do it in the next revision.

> 
> And about the table. An 'X' means a gap? It is not really said anywhere
> how to interpret the table.

Yes, X means "there is a gap"; we will clarify this in the update.

> 
> By the way, I would add a disclaimer that this document does not consider
> transport layer solutions like mptcp since they are not mobility protocols
> per se. I think we need this disclaimer, since e.g. mptcp is now deployed
> to allow mobility with specific services.

It does make sense but, if we add such disclaimer, we should also add a
disclaimer for SIP and any kind of application layer solutions....
Introduction highlights that the focus of the document is on IP mobility
protocols, and therefore excludes all others solutions. Isn't
sufficient?

Thanks!

> 
> - Jouni
> 
> 
> 
> 
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm