Re: [DMM] regarding DMM framework and draft-chan-dmm-framework-gap-analysis
<karagian@cs.utwente.nl> Mon, 05 November 2012 18:30 UTC
Return-Path: <karagian@cs.utwente.nl>
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 828D321F87E0 for <dmm@ietfa.amsl.com>; Mon, 5 Nov 2012 10:30:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.474
X-Spam-Level:
X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001]
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 1cJBIpN5E7gc for <dmm@ietfa.amsl.com>; Mon, 5 Nov 2012 10:30:15 -0800 (PST)
Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id DD2D121F87D0 for <dmm@ietf.org>; Mon, 5 Nov 2012 10:30:05 -0800 (PST)
Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 5 Nov 2012 19:30:09 +0100
Received: from EXMBX04.ad.utwente.nl ([169.254.4.76]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0318.004; Mon, 5 Nov 2012 19:30:05 +0100
From: karagian@cs.utwente.nl
To: h.anthony.chan@huawei.com
Thread-Topic: [DMM] regarding DMM framework and draft-chan-dmm-framework-gap-analysis
Thread-Index: AQHNu168vCnpQ4XQ4USyKuDSlnqJdJfbj6fq
Date: Mon, 05 Nov 2012 18:30:04 +0000
Message-ID: <FF1A9612A94D5C4A81ED7DE1039AB80F2CC17A63@EXMBX04.ad.utwente.nl>
References: <FF1A9612A94D5C4A81ED7DE1039AB80F2CBE684D@EXMBX04.ad.utwente.nl>, <6E31144C030982429702B11D6746B98C284130CD@SZXEML510-MBX.china.huawei.com>
In-Reply-To: <6E31144C030982429702B11D6746B98C284130CD@SZXEML510-MBX.china.huawei.com>
Accept-Language: nl-NL, en-US
Content-Language: nl-NL
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.129.67.215]
Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CC17A63EXMBX04adutwent_"
MIME-Version: 1.0
Cc: 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 18:30:15 -0000
Hi Anthony, Regarding your question, yes, the framework should allow the possibility that data traffic and signaling take different paths! Best regards, Georgios ________________________________ Van: h chan [h.anthony.chan@huawei.com] Verzonden: maandag 5 november 2012 15:06 To: Karagiannis, G. (EWI) Cc: dmm@ietf.org Onderwerp: RE: [DMM] regarding DMM framework and draft-chan-dmm-framework-gap-analysis 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