Re: [DMM] regarding DMM framework and draft-chan-dmm-framework-gap-analysis
h chan <h.anthony.chan@huawei.com> Mon, 05 November 2012 14:06 UTC
Return-Path: <h.anthony.chan@huawei.com>
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 D217521F86F6 for <dmm@ietfa.amsl.com>; Mon, 5 Nov 2012 06:06:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 8PV4eMgZtxWf for <dmm@ietfa.amsl.com>; Mon, 5 Nov 2012 06:06:28 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 92BC221F84D1 for <dmm@ietf.org>; Mon, 5 Nov 2012 06:06:23 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALF85017; Mon, 05 Nov 2012 14:06:22 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 5 Nov 2012 14:06:13 +0000
Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 5 Nov 2012 14:06:17 +0000
Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.141]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 5 Nov 2012 22:06:14 +0800
From: h chan <h.anthony.chan@huawei.com>
To: "karagian@cs.utwente.nl" <karagian@cs.utwente.nl>
Thread-Topic: [DMM] regarding DMM framework and draft-chan-dmm-framework-gap-analysis
Thread-Index: AQHNcYKokxa/5YVnAE2oihPhzNSmY5fb1nGQ
Date: Mon, 05 Nov 2012 14:06:13 +0000
Message-ID: <6E31144C030982429702B11D6746B98C284130CD@SZXEML510-MBX.china.huawei.com>
References: <FF1A9612A94D5C4A81ED7DE1039AB80F2CBE684D@EXMBX04.ad.utwente.nl>
In-Reply-To: <FF1A9612A94D5C4A81ED7DE1039AB80F2CBE684D@EXMBX04.ad.utwente.nl>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.142.194]
Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C284130CDSZXEML510MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] regarding DMM framework and draft-chan-dmm-framework-gap-analysis
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: Mon, 05 Nov 2012 14:06:33 -0000
Georgios, The framework is only at a high level. As we go deeper, granularity will arise. I thought these mobility management signaling are mainly in the control plane. When you say separation into control path and data path, do you mean the signaling and the data traffic can take different paths? H Anthony Chan From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of karagian@cs.utwente.nl Sent: Friday, August 03, 2012 10:17 AM To: h chan Cc: dmm@ietf.org Subject: [DMM] regarding DMM framework and draft-chan-dmm-framework-gap-analysis Hi Anthony, I have read the draft-chan-dmm-framework-gap-analysis-02.txt. The DMM framework part description is useful. However, I have a comment! The current provided DMM framework is not making any distinction between control path and data path related functions/entities. I think that the DMM framework should provide this distinction, since functions/entities that are supporting the control path may not be collocated with functions/entities that are supporting the data path. This comment is in my opinion valid for both: (1) mobility routing (MR) function/entity and (2) internetwork location management (LM) function/entity. This could mean that: The MR function/entity can be divided in: MRC (Mobility Routing Control path) function/entity MRD (Mobility Routing Data path) function/entity The LM function can be divided in: LMC (internetwork Location Management Control path) function/entity LMD (internetwork Location Management Data path) function/entity Best regards, Georgios