Re: [netext] New draft draft-petrescu-netext-pmip-nemo-00

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 09 March 2012 18:32 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 9F5AD21F8712 for <netext@ietfa.amsl.com>; Fri, 9 Mar 2012 10:32:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.886
X-Spam-Level:
X-Spam-Status: No, score=-7.886 tagged_above=-999 required=5 tests=[AWL=2.363, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtLx9AdZDX9s for <netext@ietfa.amsl.com>; Fri, 9 Mar 2012 10:32:27 -0800 (PST)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id A438B21F86F6 for <netext@ietf.org>; Fri, 9 Mar 2012 10:32:26 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q29IWNer024704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Mar 2012 19:32:23 +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 q29IWMlW013362; Fri, 9 Mar 2012 19:32:22 +0100 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q29IWJFY024640; Fri, 9 Mar 2012 19:32:22 +0100
Message-ID: <4F5A4CB3.7050309@gmail.com>
Date: Fri, 09 Mar 2012 19:32:19 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Sri Gundavelli <sgundave@cisco.com>
References: <CB7BF763.3D5B3%sgundave@cisco.com>
In-Reply-To: <CB7BF763.3D5B3%sgundave@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: netext@ietf.org
Subject: Re: [netext] New draft draft-petrescu-netext-pmip-nemo-00
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: Fri, 09 Mar 2012 18:32:27 -0000

Sri,

Le 07/03/2012 02:18, Sri Gundavelli a écrit :
> Alex:
>
> - DHCP PD is the protocol interface that we have with the mobile
> router.

It is good that DHCP PD is the protocol used to allocate prefixes.

> - The allocate prefix, if done by DHCP server, or LMA,

I believe draft-ietf-netext-pd-pmip makes PMIP allocate the prefix (and
not DHCP), because draft says:
> If the MAG does not know the delegated prefix, then mobile network
> prefix in the MNP option MUST be set to unspecified address "::" and
> prefix length to 0.  The LMA either assigns the MR a new delegated
> prefix or returns an existing one.

Remark it does not say what happens whether the MAG _does_ know the
delegated prefix, or whether it learned it somehow.

> needs to be managed in the BCE, as there is routing state and
> mobility associated with that. So, PMIP does allocate the prefix in
> some sense.

In some sense.

Allocating a prefix is a different operation than setting up routing
state and BCE associated with it.  Allocating involves managing a pool
of available prefixes such that same MNP is allocated uniquely to a
unique MR.  Setting up routing state is about inserting data in a table.

Basically, (1) the DHCP Server can allocate the prefix and inform the
LMA to update routing, or (2) LMA can allocate prefix, set up routing,
and inform DHCP Server about that prefix (I don't know why would it do it).

> - If we look at MNP's as a set of prefixes, and HNP's as a set of
> prefixes, if they are aggregatable to a single larger prefix, or if
> they belong to a non-contiguous space is more about assignment
> policy.

It's not assignment policy.

It is possible to derive an MNP by dividing the HNP that is allocated by
PMIP and thus not demand the use of DHCPv6 - just do 5213 PMIP and
modify a little the MR.  This is what a part of
draft-petrescu-netext-pmip-nemmo proposes, and draft-ietf-netext-pmip-pd
doesn't.

It is also possible to have completely different prefixes HNP and MNP
(leftmost bit flipped) and this is what allocation with DHCP PD allows
(also proposed by draft-petrescu-pmip-nemo and not allowed by
draft-ietf-netext-pmip-pd).

> So, may be its the same.

In a sense, yes, like when looking at from a distance.

And let us look more in detail.

Alex

>
>
> Regards Sri
>
>
>
> On 3/6/12 12:43 PM, "Alexandru
> Petrescu"<alexandru.petrescu@gmail.com> wrote:
>
>> Sri,
>>
>> Thank you for the question.  There are two basic differences:
>>
>> The WG document on PD assumes that PMIP allocates the prefix,
>> whereas this draft assumes DHCP allocates  it.
>>
>> The WG document does not describe a method of dividing the HNP in
>> order to obtain an MNP, whereas this draft does.
>>
>> What do you think?
>>
>> Alex
>>
>> Le 06/03/2012 01:35, Sri Gundavelli a écrit :
>>> Hi Alex:
>>>
>>> Question. How is this draft different from the WG document on PD
>>>  ?
>>>
>>> Regards Sri
>>>
>>>
>>>
>>>
>>> On 3/5/12 1:24 PM, "Alexandru
>>> Petrescu"<alexandru.petrescu@gmail.com>  wrote:
>>>
>>>> Hello netext participants,
>>>>
>>>> We have submitted a short Internet Draft:
>>>>
>>>> http://tools.ietf.org/html/draft-petrescu-netext-pmip-nemo-00
>>>>
>>>> It treats of moving networks within a PMIPv6 domain.  It
>>>> offers two alternative mechanisms:
>>>>
>>>> - HNP Division - PMIPv6 is not modified, HNP is divided into
>>>> two or more MNPs. - Enhancements to PMIPv6 and DHCPv6-PD - Q
>>>> bit, DHCP allocates MNP whereas PMIP is just informed
>>>> (DUID=MNID).
>>>>
>>>> We are interested in discussion about this draft.  The text is
>>>> relatively brief now but we can offer clarification depending
>>>> on interest.
>>>>
>>>> Yours,
>>>>
>>>> Alex _______________________________________________ netext
>>>> mailing list netext@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netext
>>>
>>>
>>
>
>