IETF Logo Mail Archive

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

Vijay Devarapalli <vijay@wichorus.com> Mon, 13 April 2009 16:14 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 076943A6EA5 for <netlmm@core3.amsl.com>; Mon, 13 Apr 2009 09:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.049
X-Spam-Level:
X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067]
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 7gYIn3qKF2PT for <netlmm@core3.amsl.com>; Mon, 13 Apr 2009 09:14:41 -0700 (PDT)
Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 3736C3A6E9E for <netlmm@ietf.org>; Mon, 13 Apr 2009 09:14:41 -0700 (PDT)
Received: from 67.161.28.136 ([67.161.28.136]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Apr 2009 16:15:51 +0000
User-Agent: Microsoft-Entourage/12.10.0.080409
Date: Mon, 13 Apr 2009 09:15:50 -0700
From: Vijay Devarapalli <vijay@wichorus.com>
To: Hidetoshi Yokota <yokota@kddilabs.jp>, "Koodli, Rajeev" <rkoodli@starentnetworks.com>
Message-ID: <C608B346.62A1%vijay@wichorus.com>
Thread-Topic: [netlmm] Consensus call: RFC5107 based DHCP message interceptat MAG
Thread-Index: Acm8UxxOu7nxKGfswUyxc93HCNT4SA==
In-Reply-To: <49E2FE6C.2010100@kddilabs.jp>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
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: Mon, 13 Apr 2009 16:14:42 -0000

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?

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.

Vijay

v2.23.0 | Report a Bug | By Email