[netlmm] Some comments // RE: Fwd: New Version Notification for draft-ietf-netlmm-lma-discovery-05

Xiangsong Cui <Xiangsong.Cui@huawei.com> Thu, 16 September 2010 01:22 UTC

Return-Path: <Xiangsong.Cui@huawei.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 880733A6AA5 for <netlmm@core3.amsl.com>; Wed, 15 Sep 2010 18:22:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.034
X-Spam-Level:
X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 q8OvEYGd0maz for <netlmm@core3.amsl.com>; Wed, 15 Sep 2010 18:22:23 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 79E353A67FA for <netlmm@ietf.org>; Wed, 15 Sep 2010 18:22:23 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8T00GKRFTQID@szxga04-in.huawei.com> for netlmm@ietf.org; Thu, 16 Sep 2010 09:22:38 +0800 (CST)
Received: from c00111037 ([10.111.16.128]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L8T00GDPFTP09@szxga04-in.huawei.com> for netlmm@ietf.org; Thu, 16 Sep 2010 09:22:38 +0800 (CST)
Date: Thu, 16 Sep 2010 09:22:48 +0800
From: Xiangsong Cui <Xiangsong.Cui@huawei.com>
In-reply-to: <E6A9CB0C-41C3-48F7-A5A2-3CD1FA51DFD5@gmail.com>
To: 'jouni korhonen' <jouni.nospam@gmail.com>, netlmm@ietf.org
Message-id: <003f01cb553d$acd29900$0677cb00$%cui@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-cn
Content-transfer-encoding: 7BIT
Thread-index: ActTJ+t/nfGEru7IR7C85UoX3NULDACEkfKQ
References: <20100913093616.B6F433A6954@core3.amsl.com> <E6A9CB0C-41C3-48F7-A5A2-3CD1FA51DFD5@gmail.com>
Subject: [netlmm] Some comments // RE: Fwd: New Version Notification for draft-ietf-netlmm-lma-discovery-05
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: Thu, 16 Sep 2010 01:22:26 -0000

Dear Jouni,

I ever responded some comments, at
http://www.ietf.org/mail-archive/web/netlmm/current/msg06537.html,
But I think some are not clearly addressed in this version.

RFC5149 issue.
The abstract of RFC5149 reads, 
"  This
   document describes a Service Selection Mobility Option for both
   conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to
   assist home agents to make a specific service selection for the..."
So in my understanding, RFC5149 is about mobility option, is used between MN
and HA (or MAG/LMA), is involved after HA/LMA is chosen.
But in this LMA-discovery draft, RFC5149 is referred as
"  Other drivers for the dynamic discovery of a LMA include LMA
   load balancing solutions and selecting a LMA based on desired
   services [RFC5149]."
This seems that RFC5149 is the basis or input of LMA selecting, is it a
circulatory logic?


Multiple LMA addresses issue.
The draft reads
"  The MAG expects that the LMA returned by the AAA server is able to
   provide mobility session continuity for the MN, i.e. after a handover
   the LMA would be the same one the MN already has a mobility session
   set up with."  -- section 2.1.

It is not clear how the goal is achieved (I'm not sure is it achieved by MAG
or by LMA, or by both together?), we need a more obvious operation
description than "expect", imho.

"  In order for this to work, the resolved
   and selected LMA IP address must be updated to the remote Policy
   Store.  For example, the LMA could perform the update once it
   receives the initial PBU from the MAG for the new mobility session." --
section 2.2.

Similarly, I don't understand how this procedure happens. It seems that the
LMA must update the state maintained by AAA server/Policy Store/DNS server.
What protocols are used in this procedure? Mobility protocol or others (e.g.
Diameter, DNS)? Or the protocol is out of scope of this document?

Thanks and regards,
Xiangsong


> -----Original Message-----
> From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On Behalf
> Of jouni korhonen
> Sent: Monday, September 13, 2010 5:40 PM
> To: netlmm@ietf.org List
> Subject: [netlmm] Fwd: New Version Notification for
> draft-ietf-netlmm-lma-discovery-05
> 
> FYI. We reduced the text a bit and added recommendations as asked by Jari.
> 
> - Jouni
> 
> Begin forwarded message:
> 
> > From: IETF I-D Submission Tool <idsubmission@ietf.org>;
> > Date: September 13, 2010 12:36:16 PM GMT+03:00
> > To: jouni.nospam@gmail.com
> > Cc: dvijay@gmail.com
> > Subject: New Version Notification for draft-ietf-netlmm-lma-discovery-05
> >
> >
> > A new version of I-D, draft-ietf-netlmm-lma-discovery-05.txt has been
> successfully submitted by Jouni Korhonen and posted to the IETF
repository.
> >
> > Filename:	 draft-ietf-netlmm-lma-discovery
> > Revision:	 05
> > Title:		 LMA Discovery for Proxy Mobile IPv6
> > Creation_date:	 2010-09-13
> > WG ID:		 netlmm
> > Number_of_pages: 9
> >
> > Abstract:
> > Large Proxy Mobile IPv6 deployments would benefit from a
> > functionality, where a Mobile Access Gateway could dynamically
> > discover a Local Mobility Anchor for a Mobile Node attaching to a
> > Proxy Mobile IPv6 domain.  The purpose of the dynamic discovery
> > functionality is to reduce the amount of static configuration in the
> > Mobile Access Gateway.  This document describes several possible
> > dynamic Local Mobility Anchor discovery solutions.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
> 
> _______________________________________________
> netlmm mailing list
> netlmm@ietf.org
> https://www.ietf.org/mailman/listinfo/netlmm