Re: [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 09:14 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 D87783A6AB2 for <netlmm@core3.amsl.com>; Thu, 16 Sep 2010 02:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.048
X-Spam-Level:
X-Spam-Status: No, score=-0.048 tagged_above=-999 required=5 tests=[AWL=0.447, 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 32fpnjBnv4C2 for <netlmm@core3.amsl.com>; Thu, 16 Sep 2010 02:14:34 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E1B323A6940 for <netlmm@ietf.org>; Thu, 16 Sep 2010 02:14:14 -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 <0L8U0012A1L1DL@szxga04-in.huawei.com> for netlmm@ietf.org; Thu, 16 Sep 2010 17:12:37 +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 <0L8U006E21L1FW@szxga04-in.huawei.com> for netlmm@ietf.org; Thu, 16 Sep 2010 17:12:37 +0800 (CST)
Date: Thu, 16 Sep 2010 17:12:36 +0800
From: Xiangsong Cui <Xiangsong.Cui@huawei.com>
In-reply-to: <6EB3A011-D90A-41E0-847B-EE4EC35A37EC@gmail.com>
To: 'jouni korhonen' <jouni.nospam@gmail.com>
Message-id: <006901cb557f$4e5482c0$eafd8840$%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: ActVbS3lee49z3I7QNKsvqwvAZWZSAAA+3nA
References: <20100913093616.B6F433A6954@core3.amsl.com> <E6A9CB0C-41C3-48F7-A5A2-3CD1FA51DFD5@gmail.com> <003f01cb553d$acd29900$0677cb00$%cui@huawei.com> <6EB3A011-D90A-41E0-847B-EE4EC35A37EC@gmail.com>
Cc: netlmm@ietf.org
Subject: Re: [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 09:14:38 -0000
Dear Jouni, Please see my comments inline. > -----Original Message----- > From: jouni korhonen [mailto:jouni.nospam@gmail.com] > Sent: Thursday, September 16, 2010 2:58 PM > To: Xiangsong Cui > Cc: netlmm@ietf.org > Subject: Re: Some comments // RE: [netlmm] Fwd: New Version Notification for > draft-ietf-netlmm-lma-discovery-05 > > Hello Xiangsong, > > > On Sep 16, 2010, at 4:22 AM, Xiangsong Cui wrote: > > > 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? > > I assume you know how RFC5149 is used with PMIPv6 (one example is in EPC as > a PMIPv6 equivalent of GTP's APN IE). Using Section 3.3 stuff, the MAG first > receives 'Service Name' somehow/somewhere (like from lower layers). MAG > does the discovery of the LMA, puts the same 'Service Name' into the RFC5149 > mobility option, sends a PBU to LMA, which upon receiving the PBU with > RFC5149 stuff does the final decision of e.g. HNP, PDN, etc.. So you are telling LMA some information, but not telling the information which is used to find a LMA, to the receiver. > > Anyway, I have no problem of removing RFC5149 reference if that is offending. > It only appeared in -04 version of this draft. I prefer "selecting a LMA based on desired services." Thanks! > > > > > 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. > > I am confused. In the previous paragraph is says: > ... > IP address information would be part of the AAA message that ends the > successful authentication and authorization AAA exchange. > > So obviously the AAA knows who the MN/subscriber is. If the AAA has LMA IP > address associated to a specific MN/subscriber it is rather obvious the AAA > returns that LMA IP address. Also, Section 2 intro gives a reference to RFC5779 > as a generic example how AAA could be implemented in PMIPv6 domain and a > reference to RFC5213 Annex A that explains what the Policy Profile contains: > ... > and authorization for the mobility services. The PMIPv6 parameters > bootstrapping involves the Policy Profile download over the AAA > infrastructure to the MAG (see Appendix A of [RFC5213]). Do you mean, when the MAG download MN's policy profile from AAA server, the identifier of the selected LMA is contained in the policy profile? And as RFC5779, MAG can get LMA information by MIP6-Agent-Info AVP, and the AVP may be hostname or IP address. So it seems MAG can get two set of LMA information, separately from Diameter AVP and policy profile. And, what you said here seems that, if AAA server has already assigned a LMA to the given MN (i.e. handover case), the AAA server would only provide the unified LMA address to MAG, LMA host name would not be provided to MAG in this case. If this is true, then I can understand. > > Regarding the "expects".. if the AAA chooses not to deliver the same LMA IP > address after a handover, it is free to do so. However, in that case ensuring > session continuity might not be trivial anymore. > > If you have something in mind that would make the text clearer how the goal is > achieved, please propose text. I suggest we add some text about "if MAG receives multiple LMA address from AAA server or DNS server, then ..." Example, from: Once the MAG receives the LMA IP address(es), it sends Proxy Binding Update (PBU) message for the newly authenticated and authorized MN. 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. To: 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. Once the MAG receives the unified LMA IP address, it sends Proxy Binding Update (PBU) message for the newly authenticated and authorized MN to this LMA. If the MAG receives multiple LMA addresses from AAA server or DNS server, then ....... In my mind, there may be two ways in this case, the simple one is "the MAG may lost session continuity", and the robust one is "the MAG interacts separately with these addresses, finds out the right LMA which the MN has already been registered to, and sends PBU to that LMA". The robust one is very complex and may affect handover performance, but would keep session continuity. These two cases are in different requirement levels, and either is OK for me. > > > > > > " 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? > > Obviously the whole section is about AAA-based solution. Anyway would the > following be clearer? > > .. > Store. For example, the LMA could perform the Policy Store update using > the AAA infrastructure once it receives the initial PBU from the MAG for > the new mobility session. Hmm, I hope this would be more detailed. >From my perspective, as a PMIPer, I care what should I do on my MAG and LMA. If you say the MAG and LMA can utilize the feature of LMA discovery, but all I can do is expecting AAA Server's behavior/response and some general update, that is not enough. I, at least, need to know, how I can update the related state, this means which protocol (Diameter or xxx) and which AVP (defined in xxx) should I use, and what operation rule I should follow (if there is rule). Because in most cases, LMA and AAA server are from different vendors, we need an explicit reference. Thanks and best regards, Xiangsong > > > - Jouni > > > > > > > > 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 > >
- [netlmm] Fwd: New Version Notification for draft-… jouni korhonen
- [netlmm] Some comments // RE: Fwd: New Version No… Xiangsong Cui
- Re: [netlmm] Some comments // RE: Fwd: New Versio… jouni korhonen
- Re: [netlmm] Some comments // RE: Fwd: New Versio… Xiangsong Cui
- Re: [netlmm] Some comments // RE: Fwd: New Versio… jouni korhonen
- Re: [netlmm] Some comments // RE: Fwd: New Versio… Xiangsong Cui
- Re: [netlmm] Some comments // RE: Fwd: New Versio… jouni korhonen
- Re: [netlmm] Some comments // RE: Fwd: New Versio… Vijay Devarapalli
- Re: [netlmm] Some comments // RE: Fwd: New Versio… Xiangsong Cui
- Re: [netlmm] Some comments // RE: Fwd: New Versio… Vijay Devarapalli
- Re: [netlmm] Some comments // RE: Fwd: New Versio… Narayanan, Vidya
- Re: [netlmm] Some comments // RE: Fwd: New Versio… Jari Arkko
- Re: [netlmm] Some comments // RE: Fwd: New Versio… Narayanan, Vidya