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
>