Re: [DMM] DMM solution space categorization
Alper Yegin <alper.yegin@yegin.org> Mon, 21 July 2014 14:32 UTC
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00861A000F for <dmm@ietfa.amsl.com>; Mon, 21 Jul 2014 07:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5lpeqI2H6rP for <dmm@ietfa.amsl.com>; Mon, 21 Jul 2014 07:32:00 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62851A000D for <dmm@ietf.org>; Mon, 21 Jul 2014 07:32:00 -0700 (PDT)
Received: from [10.119.8.8] ([67.230.161.180]) by mrelay.perfora.net (node=mreueus001) with ESMTP (Nemesis) id 0LsS1m-1WPDcx2ww4-011yMX; Mon, 21 Jul 2014 16:31:51 +0200
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="windows-1252"
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <E8980645-BD47-4DD4-916F-4FE1C5CDA0FB@office.hd>
Date: Mon, 21 Jul 2014 17:31:47 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D4AECFE-2B88-46FC-8F5F-652B08B40A3D@yegin.org>
References: <61D0EE5C-EAE2-4724-BE98-0F5A99441B2B@yegin.org> <53CC134D.4000908@gmail.com>, <53CC1450.5020606@gmail.com> <E8980645-BD47-4DD4-916F-4FE1C5CDA0FB@office.hd>
To: Marco Liebsch <marco.liebsch@neclab.eu>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:xBM5kc+mUtDPu1uzJSHMKnV1mw8kzNT5llooesmDFry 5RiqHv5sorgMwL0LOejz99hqqvV9eDOg5mYeCUTymsG8KuFbGQ 7ccCYXDHSE0q/cq1vwXjSRgPpThOmyCB0AfES7Lno4BN9WioSK Usyh3Ea0EAJ60bk2qeJwVAai66ZREyvmtbFRDutIdUVshrd2zg pdjR0t78I32ndBiW4fyq3pXj+b12/Q/hu8DCtz9pzWE2s/4Ai6 AdVLfMyFJJLuEUI330Flnskxpw2l/wO0QhH+Y/ZRRHcbR42beR k9VR4mcqWBZuwoNRIltMHUSo46i92P2eaPAd4fX4RLBZOwtXxe /VTVwPF/QAAzPhYJyTliz8gQEj93AY2vErQ89Z5TmayGcm2IGC Fe61sM/IILNSA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/TpPY1qDY4sjxifHbK0vaU3GoXO8
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] DMM solution space categorization
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 21 Jul 2014 14:32:07 -0000
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" <jouni.nospam@gmail.com> 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 >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>>> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm
- [DMM] DMM solution space categorization Alper Yegin
- Re: [DMM] DMM solution space categorization Jouni Korhonen
- Re: [DMM] DMM solution space categorization Jouni Korhonen
- Re: [DMM] DMM solution space categorization Marco Liebsch
- Re: [DMM] DMM solution space categorization Alper Yegin
- Re: [DMM] DMM solution space categorization Alper Yegin
- Re: [DMM] DMM solution space categorization Jouni Korhonen
- Re: [DMM] DMM solution space categorization Behcet Sarikaya