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

Vijay Devarapalli <vijay@wichorus.com> Tue, 14 April 2009 18:53 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 82A683A68A8 for <netlmm@core3.amsl.com>; Tue, 14 Apr 2009 11:53:36 -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 wWqfJjR+BMUf for <netlmm@core3.amsl.com>; Tue, 14 Apr 2009 11:53:35 -0700 (PDT)
Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id A7CBC3A6827 for <netlmm@ietf.org>; Tue, 14 Apr 2009 11:53:35 -0700 (PDT)
Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id fPd91b00316AWCUABWuoMp; Tue, 14 Apr 2009 18:54:48 +0000
Received: from [10.166.254.159] ([99.27.41.113]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id fWuY1b00H2SVSVv8SWud08; Tue, 14 Apr 2009 18:54:46 +0000
Message-ID: <49E4DBE6.5030609@wichorus.com>
Date: Tue, 14 Apr 2009 11:54:30 -0700
From: Vijay Devarapalli <vijay@wichorus.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Sri Gundavelli <sgundave@cisco.com>
References: <BE82361A0E26874DBC2ED1BA244866B9382A1F89@NALASEXMB08.na.qualcomm.com> <4D35478224365146822AE9E3AD4A2666035AAAA2@exchtewks3.starentnetworks.com> <BE82361A0E26874DBC2ED1BA244866B9382A1F91@NALASEXMB08.na.qualcomm.com> <4D35478224365146822AE9E3AD4A2666035AAAA5@exchtewks3.starentnetworks.com> <A13924FC-1FFB-4BC3-9E48-640BDE10C17B@gmail.com> <4D35478224365146822AE9E3AD4A2666035AAAB1@exchtewks3.starentnetworks.com> <03ADE51E-90B1-4FE0-809D-444D48D31849@gmail.com> <4D35478224365146822AE9E3AD4A2666035AAAB2@exchtewks3.starentnetworks.com> <Pine.GSO.4.63.0904140949460.2732@irp-view13.cisco.com> <49E4CF1F.601@wichorus.com> <Pine.GSO.4.63.0904141146390.2863@sgundave-sb100.cisco.com>
In-Reply-To: <Pine.GSO.4.63.0904141146390.2863@sgundave-sb100.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 18:53:36 -0000

Sri,

Sri Gundavelli wrote:
>>>  3. MAG will certainly synchroized the state from LMA through PMIP
>>>  signaling, only after each handoff. The MAG will not be in path for
>>>  subsequent DHCP events after handoff. This option will enable the MAG
>>>  to register itself to be in path for all messages. If a MN releases
>>>  an address, if the LMA recycles the address and allocates to some
>>>  other node. 
>>
>> This will not happen. If the LMA has a valid binding cache entry for 
>> the mobile node's IPv4 address, it is not going to allocate the IPv4 
>> address to another mobile node.
>>
> 
> We can argue, even if the MN releases the address, the LMA should
> keep a floating BCE, or it can cleanup the state. 

The MAG has not removed the binding yet. So the LMA cannot cleanup the 
state or remove the binding. It has to at least send a binding 
revocation message to the MAG and get a response to the that. It won't 
allocate the IPv4 address to another mobile node until that. It is a 
really bad idea for the LMA to remove the binding that the MAG created 
based on the DHCP release message from the mobile node.

Vijay

> The point is the
> need for the PMIP and DHCP entities aware of all transactions,
> ensuring the address that the MN requests is the same as what it
> obtained PMIP or being aware of MN releasing its address, or about
> extending lifetimes for the MAG to ensure the PMIP tunnel life is
> valid for the DHCP state.