Re: DMM solution space categorization

Marco, Jouni,

The categorization I provided was for the "solution space".
Framework, and deployment models are not solution documents.

If I'm missing something, and also for any other docs I missed in the categorization, folks please also suggest where they should fit in when sending the I-D names.

Alper



On Jul 20, 2014, at 10:26 PM, Marco Liebsch wrote:

> You may add the framework draft to that category as well.
> draft-liebsch-dmm-framework 
> 
> Marco
> 
> 
> On 20.07.2014, at 15:11, "Jouni Korhonen" <[email protected]> wrote:
> 
>> And then there is the "Distributed mobility management deployment models and scenarios":
>> 
>> draft-liu-dmm-deployment-scenario
>> 
>> Forgot that.. sprry.
>> 
>> - Jouni
>> 
>> 
>> 
>> 7/20/2014 10:06 PM, Jouni Korhonen kirjoitti:
>>> 
>>> Alper,
>>> 
>>> Thanks for doing the categorization work. We should also try to look
>>> these how they fit under the proposed new milestones. See below:
>>> 
>>> 
>>> 7/19/2014 11:44 AM, Alper Yegin kirjoitti:
>>>> *
>>>> *
>>>> 
>>>> I've updated the list with the I-Ds suggested by Behcet/Fred/Jouni.
>>>> 
>>>> Please see below for my opinions about how each category relates to the
>>>> overall work.
>>>> Comments welcome.
>>>> *
>>>> *
>>>> *
>>>> *
>>>> *1. Per-flow IP address configuration according to mobility needs*
>>> 
>>> "Exposing mobility state to mobile nodes and network nodes"
>>> 
>>>> Apps indicating their mobility needs to the IP stack on the MN, and
>>>> associated IP configuration signaling between the MN and the network.
>>>> 
>>>> draft-bhandari-dhc-class-based-prefix-03
>>>> draft-korhonen-dmm-prefix-properties-00.txt
>>>> draft-yegin-dmm-ondemand-mobility-02
>>> 
>>> Then we have a number of I-Ds from MIF:
>>> 
>>> draft-kk-mpvd-ndp-support
>>> draft-kkb-mpvd-dhcp-support
>>> draft-kkbg-mpvd-id
>>> 
>>> These intend to build the overall method of conveying the signaling
>>> between the network and the mn. There are no spacific use cases
>>> described for mobility yet but those are then amendments for the above.
>>> 
>>> draft-liu-dmm-mobility-api
>>> 
>>> Above has extensions to RFC5014 for applications to check prefix
>>> properties.
>>> 
>>> 
>>>> This category is essential, given that we all agree mobility will be
>>>> treated on a per-flow basis.
>>>> (and once we dive into the category, I'd say the aforementioned I-Ds are
>>>> complementary).
>>>> 
>>>> 
>>>> 
>>>> *2. Mobility solution selection *
>>> 
>>> In my optinion this also fits under "Exposing mobility state to mobile
>>> nodes and network nodes".
>>> 
>>>> MN determining the type of mobility solution(s) it'd apply to a given
>>>> flow.
>>>> 
>>>> draft-yegin-ip-mobility-orchestrator-00
>>>> 
>>>> In recognition of L4+ mobility solutions (such as MPTCP, SIP, apps
>>>> having their own), this also becomes essential for a DMM solution. Some
>>>> people may argue, discussion is very welcome.
>>>> 
>>>> 
>>>> 
>>>> *3. IP anchor selection*
>>> 
>>> "Enhanced mobility anchoring"
>>> 
>>>> MN selecting the IP anchor node after it decides to use IP anchoring
>>>> (whether in the access network or the core network).
>>>> 
>>>> draft-aliahmad-dmm-anchor-selection-00.txt
>>>> 
>>>> This category is supporting the Category 4, 5 and 6. This is about more
>>>> intelligent way of picking the IP anchor once the type of anchor is
>>>> determined.
>>>> This may produce a standalone I-D, or may be folded into individual
>>>> solutions in those categories.
>>>> 
>>>> 
>>>> *4. Access network anchoring*
>>> 
>>> Still related to "Enhanced mobility anchoring". Many of these I-Ds
>>> handle the anchor change issues (like tunneling between the anchors).
>>> 
>>>> Anchoring IP address within the access network using IP-in-IP tunneling.
>>>> 
>>>> draft-bernardos-dmm-cmip-01
>>>> draft-bernardos-dmm-pmip-03
>>>> draft-bernardos-dmm-distributed-anchoring-04
>>>> draft-chan-dmm-enhanced-mobility-anchoring-00
>>>> draft-sarikaya-dmm-for-wifi-00.txt
>>>> draft-seite-dmm-dma-07.txt
>>>> draft-xuan-dmm-nemo-dmm-02.txt
>>>> draft-korhonen-dmm-local-prefix-01
>>>> 
>>>> The need for this category is well-understood. The challenge is having
>>>> plethora of solutions. Though the main concept is common…
>>>> 
>>>> 
>>>> *5. Corresponding node/network anchoring*
>>> 
>>> Still under "Enhanced mobility anchoring".
>>> 
>>>> Anchoring IP address on the Corresponding Node or Corresponding Network.
>>>> 
>>>> Mobile IPv6 route optimization
>>>> draft-yegin-dmm-cnet-homing-02
>>>> draft-xiong-dmm-ip-reachability-01
>>>> draft-templin-aerolink-29
>>>> 
>>>> This category of solutions are also needed (for their ability to produce
>>>> better paths and different applicability with respect to the Category 4)
>>>> 
>>>> 
>>>> *6. Host-route based intra-domain solutions*
>>> 
>>> "Forwarding path and signalling management"
>>> 
>>>> Non-tunneling solutions.
>>>> 
>>>> draft-chan-dmm-enhanced-mobility-anchoring-00
>>>> draft-matsushima-stateless-uplane-vepc-02
>>>> draft-mccann-dmm-flatarch-00
>>>> draft-sarikaya-dmm-for-wifi-00.txt
>>>> 
>>>> Solutions in this category are competing with the Category 4 type
>>>> solutions. There are various pros and cons. IMHO, we cannot resolve that
>>>> contest, hence we should produce solution for both categories and let
>>>> the industry pick and choose. Given that these solutions are isolated
>>>> from the other components (categories), standardizing both should not
>>>> have adverse impact on the overall DMM complexity.
>>>> 
>>>> Alper
>>> 
>>> - JOuni
>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> dmm mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>> 
>> 
>> _______________________________________________
>> dmm mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dmm