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

[Xiangsong Cui <[e-mail]>]

Dear Jouni,
Please see my comments inline.


> -----Original Message-----
> From: jouni korhonen [mailto:[e-mail]]
> Sent: Thursday, September 16, 2010 2:58 PM
> To: Xiangsong Cui
> Cc: [e-mail]
> 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: [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
> >