IETF Logo Mail Archive

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

Sri Gundavelli <sgundave@cisco.com> Tue, 14 April 2009 18:47 UTC

Return-Path: <sgundave@cisco.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 CD7903A6EB5 for <netlmm@core3.amsl.com>; Tue, 14 Apr 2009 11:47:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Dl+m-oAmrMCU for <netlmm@core3.amsl.com>; Tue, 14 Apr 2009 11:47:59 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1D75B3A6981 for <netlmm@ietf.org>; Tue, 14 Apr 2009 11:47:59 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.40,186,1238976000"; d="scan'208";a="154590897"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2009 18:49:11 +0000
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3EInAgN003491; Tue, 14 Apr 2009 11:49:10 -0700
Received: from sgundave-sb100.cisco.com (sgundave-sb100.cisco.com [128.107.163.1]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n3EInAWL011110; Tue, 14 Apr 2009 18:49:10 GMT
Date: Tue, 14 Apr 2009 11:49:10 -0700
From: Sri Gundavelli <sgundave@cisco.com>
To: Vijay Devarapalli <vijay@wichorus.com>
In-Reply-To: <49E4CF1F.601@wichorus.com>
Message-ID: <Pine.GSO.4.63.0904141146390.2863@sgundave-sb100.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>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1085; t=1239734950; x=1240598950; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20<sgundave@cisco.com> |Subject:=20Re=3A=20[netlmm]=20Consensus=20call=3A=20RFC510 7=20based=20DHCP=20message=20interceptat=0A=20MAG |Sender:=20; bh=BPL6ESwt4YTCm5XySKu84NU2uAiplM0uWQVepnXA5MU=; b=P6uFxozUbqOaQBVnA0+CRWSn3tR4G67QMQpLMicD+wGQ48UGlBTx/OBkhr ut0K23de247EShb+o+4w1kdObNdIYThMD8zym4JmuZ4WIBfhoOq5K4K16edz VwLRFioSJE;
Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
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:47:59 -0000

On Tue, 14 Apr 2009, Vijay Devarapalli wrote:

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

Sri

v2.23.0 | Report a Bug | By Email