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

[Xiangsong Cui <[e-mail]>]

Thanks for your quick response.

Removing the "(es)" is very useful, otherwise we would be confused by
"receiving multiple LMA addresses, but sending PBU to one LMA".

As to the updating procedure, since this document would be a "informational"
RFC, so I can also accept the overall description.
But I would worry about the popularization of this documents, because it is
a bit too general.

Best regards,
Xiangsong


> -----Original Message-----
> From: jouni korhonen [mailto:[e-mail]]
> Sent: Thursday, September 16, 2010 5:45 PM
> To: Xiangsong Cui
> Cc: [e-mail]
> Subject: Re: Some comments // RE: [netlmm] Fwd: New Version Notification
for
> draft-ietf-netlmm-lma-discovery-05
> 
> Hi,
> 
> Inline..
> 
> On Sep 16, 2010, at 12:12 PM, Xiangsong Cui wrote:
> 
> [snip]
> 
> >>
> >> 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!
> 
> Ok. Good.
> 
> [snap]
> 
> >
> > 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.
> 
> It can based on the ABNF in RFC5779. But in Section 2.1 approach MAG would
> only be receiving the IP address. Why would AAA server purposely try to
> confuse the MAG?
> 
> Anyway, RFC5779 is an example here. So going into RFC5779 details here is
not
> in the scope.
> 
> > 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.
> 
> Yep. Good.
> 
> 
> [clip]
> 
> >>
> >> 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.
> 
> Actually I would just rephrase my original text like:
> 
>    Once the MAG receives the LMA IP address, it sends Proxy Binding
>    Update (PBU) message for the newly authenticated and authorized MN.
> 
> That basically states the MAG receives *one* address thus no issue with
> multiple choices.
> 
> 
> [clipetisnip]
> 
> >>
> >> 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.
> 
> We are not going to redefine RFC5779 in this document. I rather stick with
my
> new proposed "overall description" text. Section 4 also discusses this
particular
> update procedure from handover context.
> 
> - Jouni
> 
> 
> 
> >
> > 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
> >>>
> >