Re: [netext] Additional comments for mMAG presentation
Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 07 November 2012 19:57 UTC
Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEC421F8C9B for <netext@ietfa.amsl.com>; Wed, 7 Nov 2012 11:57:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.213
X-Spam-Level:
X-Spam-Status: No, score=-10.213 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
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 LEJIbhEDMoOP for <netext@ietfa.amsl.com>; Wed, 7 Nov 2012 11:57:15 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0669921F8BD3 for <netext@ietf.org>; Wed, 7 Nov 2012 11:57:14 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA7JvDjl015345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <netext@ietf.org>; Wed, 7 Nov 2012 20:57:14 +0100
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA7JvD2K026164 for <netext@ietf.org>; Wed, 7 Nov 2012 20:57:13 +0100 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (arletty1-201-49.intra.cea.fr [132.166.201.49]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA7Jv7bJ006325 for <netext@ietf.org>; Wed, 7 Nov 2012 20:57:12 +0100
Message-ID: <509ABD12.5010400@gmail.com>
Date: Wed, 07 Nov 2012 20:57:06 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: netext@ietf.org
References: <00c801cdbc22$aacc2d30$00648790$@av.it.pt>
In-Reply-To: <00c801cdbc22$aacc2d30$00648790$@av.it.pt>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [netext] Additional comments for mMAG presentation
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2012 19:57:15 -0000
Le 06/11/2012 14:28, Seil Jeon a écrit : > Hi folks, > > On the mMAG presentation in the meeting, I think allocated slot might > not be enough to have full discussion. > > Let me give explanation about the substance of mMAG proposed in our > slide again. > > As I presented, the mMAG is ‘SEEN’ as one of MNs in MAG perspective > but this is not a ‘_MN_’ like mobile device you simply have. That is > a ‘ROUTER’ managed by the operators. So you can imagine same level > of security association between mMAG and LMA as the MAG and LMA has. Except that, when LMA sends a HNP (Home Network Prefix) to MAG to mMAG such as this HNP to be used by a Host in the moving network - there is no security between this Host and the LMA. There is a sort of delegation of authority between LMA and MAG and mMAG to trust about this Host, but obviously this is not 'end-to-end' security as one considers typically between a fixed Host and Correspondent in the Internet. > And this use case and the need are usually reasonable when > considering real deployment. Of course, we will update this use case > of NEMO in next version. But I think the need or the use case has > implicitly been assumed in prefix delegation WG draft, right? Well, one reads that as one wishes. In a ideal world, the problem statement and requirements about network mobility support with PMIP would be written first, separately, and allow time for competing solutions to root and grow. And later make some selection or join solutions. In a real world what happens is that some solutions grow much faster than others and they practically influence a problem statement, which is somehow more or less assummed to fit what that solution needs. Implementation is a key aspect as well. If one knows that some particular solution is safely planned to be implemented in a widely availabble router platform, then only thing one has to do is to agree to that solution, since deployment is guaranteed. Alex > > Regards, > > Seil > > > > _______________________________________________ netext mailing list > netext@ietf.org https://www.ietf.org/mailman/listinfo/netext >
- [netext] Additional comments for mMAG presentation Seil Jeon
- Re: [netext] Additional comments for mMAG present… Alexandru Petrescu