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

[jouni korhonen <[e-mail]>]

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

Anyway, I have no problem of removing RFC5149 reference if that is offending. It only appeared in -04 version of this draft.

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

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.


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


- Jouni




> 
> Thanks and regards,
> Xiangsong
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of jouni korhonen
>> Sent: Monday, September 13, 2010 5:40 PM
>> To: [e-mail] 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 <[e-mail]>
>>> Date: September 13, 2010 12:36:16 PM GMT+03:00
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netlmm
>