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

Vijay Devarapalli <vijay@wichorus.com> Tue, 14 April 2009 17:48 UTC

Return-Path: <vijay@wichorus.com>
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 3E5403A6E82 for <netlmm@core3.amsl.com>; Tue, 14 Apr 2009 10:48:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 7HC8iQ64bwF6 for <netlmm@core3.amsl.com>; Tue, 14 Apr 2009 10:48:29 -0700 (PDT)
Received: from QMTA15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id 61F723A6E47 for <netlmm@ietf.org>; Tue, 14 Apr 2009 10:48:29 -0700 (PDT)
Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA15.emeryville.ca.mail.comcast.net with comcast id fSv01b0080QkzPwAFVphl0; Tue, 14 Apr 2009 17:49:41 +0000
Received: from [10.166.254.159] ([99.27.41.113]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id fVpA1b0012SVSVv8NVpM2l; Tue, 14 Apr 2009 17:49:39 +0000
Message-ID: <49E4CC93.6000407@wichorus.com>
Date: Tue, 14 Apr 2009 10:49:07 -0700
From: Vijay Devarapalli <vijay@wichorus.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Hidetoshi Yokota <yokota@kddilabs.jp>
References: <C608B346.62A1%vijay@wichorus.com> <49E3E08B.40202@kddilabs.jp>
In-Reply-To: <49E3E08B.40202@kddilabs.jp>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Cc: netlmm@ietf.org, Ryuji Wakikawa <ryuji@jp.toyota-itc.com>
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 17:48:30 -0000

Hello,

Hidetoshi Yokota wrote:

>>> 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.

There are a lot more issues you need to handle with LMA relocation. In
case you want address LMA relocation, I think a separate document which
describes the scenario, how the LMA is changed, how the LMA and the DHCP
server interact, what happens to the mobility sessions that the mobile
node is required.

>> 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.

ahh.. This is one of my main concerns. We don't want to protocols both
managing the IPv4 address for the mobile node. It should be just the
PMIPv6 protocol. If there is a need for a separate DHCP server in the
PMIPv6 domain, it should be the LMA that interacts with it. Not the MAG.

Vijay