Re: [netlmm] Consensus call: RFC5107 based DHCP message interceptat MAG

Hidetoshi Yokota <yokota@kddilabs.jp> Tue, 14 April 2009 01:01 UTC

Return-Path: <yokota@kddilabs.jp>
X-Original-To: netlmm@core3.amsl.com
Delivered-To: netlmm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E903A6853 for <netlmm@core3.amsl.com>; Mon, 13 Apr 2009 18:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.151
X-Spam-Level:
X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVBD5mEBt4jV for <netlmm@core3.amsl.com>; Mon, 13 Apr 2009 18:01:18 -0700 (PDT)
Received: from mandala.kddilabs.jp (unknown [IPv6:2001:200:601:12:230:48ff:fe22:3a84]) by core3.amsl.com (Postfix) with ESMTP id 465E43A677C for <netlmm@ietf.org>; Mon, 13 Apr 2009 18:01:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 4AD7EEC870; Tue, 14 Apr 2009 10:02:28 +0900 (JST)
Received: from ultra.mip.kddilabs.jp (unknown [2001:200:601:402:203:baff:fe2c:bc3]) by mandala.kddilabs.jp (Postfix) with ESMTP id D2C1DEC868; Tue, 14 Apr 2009 10:02:27 +0900 (JST)
Received: from [127.0.0.1] (dhcp128.east-3f.cn.kddilabs.jp [172.19.126.128]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 7B0F41C0BC; Tue, 14 Apr 2009 10:00:44 +0900 (JST)
Message-ID: <49E3E08B.40202@kddilabs.jp>
Date: Tue, 14 Apr 2009 10:02:03 +0900
From: Hidetoshi Yokota <yokota@kddilabs.jp>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Vijay Devarapalli <vijay@wichorus.com>
References: <C608B346.62A1%vijay@wichorus.com>
In-Reply-To: <C608B346.62A1%vijay@wichorus.com>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new
Cc: netlmm@ietf.org
Subject: Re: [netlmm] Consensus call: RFC5107 based DHCP message interceptat MAG
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2009 01:01:19 -0000

Hi Vijay,

Vijay Devarapalli wrote:
> Hello,
> 
> 
> On 4/13/09 1:57 AM, "Hidetoshi Yokota" wrote:
> 
>> Hi Rajeev and all,
>>
>> I have a bit of concern about the restriction that the DHCP server has
>> to be collocated with the LMA. Some deployment scenario may have
>> multiple LMAs and one DHCP server in a PMIPv6 domain and there is a
>> situation where the LMA for some mobile node gets changed to another for
>> failure recovery reason. If RFC5107 can allow this configuration and
>> handle this situation well, then it's worth keeping it in the document.
>> A further clarification will be helpful as you pointed out, though.
> 
> LMA relocation while preserving the IP address for the mobile node is
> something that is not supported even in RFC 5213. So can you describe the
> above scenario in more detail?

Here, I'm thinking of a real PMIPv6 deployment not limited to RFC5213.
5213 is the base spec and we all know that we need further extensions
including binding revocations, redirections, etc. The concern I raised
here is that it would be a bit restrictive if the collocation of the LMA
and DHCP server is mandated.

> If this is a failover case where another LMA takes over for a failed LMA,
> and the state is synced between the two, this change should not even be
> visible to the MAG or the MN. All the mobility sessions continue as is.

If the state is synced between the two, yes. But in the collocated case,
a change of LMA means a change of DHCP server. DHCP and PMIP are
basically separate things in protocol and operations although their
states should be in sync. Here, I raised a question that this
collocation is a must or a choice.

Regards,
-- 
Hidetoshi


> Vijay
> 
> 
> 
>