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

Sri Gundavelli <sgundave@cisco.com> Tue, 14 April 2009 18:57 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 D7ABF3A6AC4 for <netlmm@core3.amsl.com>; Tue, 14 Apr 2009 11:57:01 -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=[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 jzzTtkdQB44w for <netlmm@core3.amsl.com>; Tue, 14 Apr 2009 11:57:01 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2745F3A6A65 for <netlmm@ietf.org>; Tue, 14 Apr 2009 11:57:01 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.40,186,1238976000"; d="scan'208";a="286174771"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2009 18:58:13 +0000
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3EIwCAw027854; Tue, 14 Apr 2009 11:58:12 -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 n3EIwC00013491; Tue, 14 Apr 2009 18:58:12 GMT
Date: Tue, 14 Apr 2009 11:58:12 -0700
From: Sri Gundavelli <sgundave@cisco.com>
To: Vijay Devarapalli <vijay@wichorus.com>
In-Reply-To: <49E4DBE6.5030609@wichorus.com>
Message-ID: <Pine.GSO.4.63.0904141155160.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> <Pine.GSO.4.63.0904141146390.2863@sgundave-sb100.cisco.com> <49E4DBE6.5030609@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=1691; t=1239735492; x=1240599492; c=relaxed/simple; s=sjdkim1004; 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=zxKoW3uVTpFaBOFgieij12titM6dND+YuPxBioM680M=; b=pXu1NZECIgDntm1R0OWhDuhmQN0Wf2/GCQzgIv9k8yFZuycixt35gyLnl/ KagSZoMT70P2KCi8Fy0jYved+jqr5r3rnrbkerNUQDnOs2VM71tJInsAyL3p i+u1A74Ljc+5pFjfA7toUdIuThhPIfbKs6hwAChsYzR+ud9Ydcw6E=;
Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 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:57:01 -0000

Vijay,



On Tue, 14 Apr 2009, Vijay Devarapalli wrote:

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

Dont bring revocation into picture. We are not talking about
a revoked session. There is a spec 5107, or if not the MAG can
certainly intercept all DHCP packets. Either way, revocation
has no business here.

Like I said, you can argue LMA need not remove the MN state
even if the address is released, it can hang on to it for
ever. The point is for the MAG to be aware of the MN-LMA
DHCP states.

Sri