DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
 h=subject:mime-version:content-type:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to:x-mailer;
 b=iYHenGQO4Dn+IjwQDRncjx4zqxFWQepFcUTdS+Qqkbn0+cF2cu0nHs9Fy+rXUe4JIV
 rVhjZCtEm3plJMduWPpe9TtkuwDjJBK89OTFgdZFNM8RozdTzyTRb83xqhn4yMeNpuXa
 popkLugcMDBlw1NTpK0U0q5NttTelNxznkgIs=
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <003f01cb553d$acd29900$0677cb00$%cui@huawei.com>
Date: Thu, 16 Sep 2010 09:57:43 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <6EB3A011-D90A-41E0-847B-EE4EC35A37EC@gmail.com>
References: <20100913093616.B6F433A6954@core3.amsl.com>
 <E6A9CB0C-41C3-48F7-A5A2-3CD1FA51DFD5@gmail.com>
 <003f01cb553d$acd29900$0677cb00$%cui@huawei.com>
To: Xiangsong Cui <Xiangsong.Cui@huawei.com>
Cc: netlmm@ietf.org
Subject: Re: [netlmm] Some comments // RE: Fwd: New Version Notification for
 draft-ietf-netlmm-lma-discovery-05
Precedence: list

Hello Xiangsong,


On Sep 16, 2010, at 4:22 AM, Xiangsong Cui wrote:

> Dear Jouni,
>=20
> 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.
>=20
> RFC5149 issue.
> The abstract of RFC5149 reads,=20
> "  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..

Anyway, I have no problem of removing RFC5149 reference if that is =
offending. It only appeared in -04 version of this draft.

>=20
> 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.
>=20
> 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]).

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.


>=20
> "  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.
>=20
> 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.


- Jouni




>=20
> Thanks and regards,
> Xiangsong
>=20
>=20
>> -----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
>>=20
>> FYI. We reduced the text a bit and added recommendations as asked by =
Jari.
>>=20
>> - Jouni
>>=20
>> Begin forwarded message:
>>=20
>>> 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
>>>=20
>>>=20
>>> 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.
>>>=20
>>> 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
>>>=20
>>> 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.
>>>=20
>>>=20
>>>=20
>>> The IETF Secretariat.
>>>=20
>>>=20
>>=20
>> _______________________________________________
>> netlmm mailing list
>> netlmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/netlmm
>=20