Subject: [netlmm] Fwd: New Version Notification for draft-ietf-netlmm-lma-discovery-05

From: jouni korhonen <[email-masked]>
Date: Mon, 13 Sep 2010 12:39:39 +0300

FYI. We reduced the text a bit and added recommendations as asked by Jari.

- Jouni

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: September 13, 2010 12:36:16 PM GMT+03:00
> To: [email-masked]
> Cc: [email-masked]
> 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.
> 
>

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 16 Sep 2010 09:22:48 +0800

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?

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.

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

Thanks and regards,
Xiangsong

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of jouni korhonen
> Sent: Monday, September 13, 2010 5:40 PM
> To: [email-masked] List
> Subject: [netlmm] Fwd: 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.
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm

---

From: jouni korhonen <[email-masked]>
Date: Thu, 16 Sep 2010 09:57:43 +0300

Hello Xiangsong,

> This seems that RFC5149 is the basis or input of LMA selecting, is it a

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.

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

> 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

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 16 Sep 2010 17:12:36 +0800

Dear Jouni,
Please see my comments inline.

> From: jouni korhonen [mailto:[email-masked]]
> Sent: Thursday, September 16, 2010 2:58 PM
> To: Xiangsong Cui
> Cc: [email-masked]
> Subject: Re: Some comments // RE: [netlmm] Fwd: New Version Notification
for
> > So in my understanding, RFC5149 is about mobility option, is used
between
> MN
> 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!

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

>    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

---

From: jouni korhonen <[email-masked]>
Date: Thu, 16 Sep 2010 12:44:32 +0300

Hi,

Inline..

On Sep 16, 2010, at 12:12 PM, Xiangsong Cui wrote:

[snip]

> I prefer "selecting a LMA based on desired services." Thanks!

Ok. Good.

[snap]

> So it seems MAG can get two set of LMA information, separately from Diameter

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.

> If this is true, then I can understand.

Yep. Good.

[clip]

> continuity. These two cases are in different requirement levels, and either

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]

> 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

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 16 Sep 2010 17:56:00 +0800

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

> Sent: Thursday, September 16, 2010 5:45 PM
> To: Xiangsong Cui
> Cc: [email-masked]
for
> 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.
> >> Obviously the whole section is about AAA-based solution. Anyway would
the
> >> following be clearer?
> 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
> >>>
> >>>

---

From: jouni korhonen <[email-masked]>
Date: Thu, 16 Sep 2010 13:02:43 +0300

Hi,

Ok. Good.

> But I would worry about the popularization of this documents, because it is

I see your point. But for more detailed stuff we do actually point the reader to other documents.. to quite many actually.

- Jouni

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 20 Sep 2010 10:40:26 -0700

>> I prefer "selecting a LMA based on desired services." Thanks!

No, this is too vague. It is hard for someone not familiar with 3GPP to 
figure out what it means to select LMA based on the services desired. 
Service specific mobility anchor points are very 3GPP specific. So I 
think we should have the reference to RFC 5149. That RFC clearly 
explains what a "service" means in addition to defining a new mobility 
option. I think you should put back this reference.

Vijay

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 21 Sep 2010 11:03:45 +0800

I don't think so.
As I said in my earlier mail, I think there is some circulation on RFC5149
reference.

RFC5149 reads,
   This document describes a Service Selection Mobility Option for
   Mobile IPv6 that is intended to *assist home agents* to make specific
   service selections for the mobility service subscription **during the
   binding registration procedure.**

I think this is clear enough, RFC5149 is "assist HA ... during registration
procedure", right?
While in this draft, we are talking about "assist LMA-discoverer to select a
LMA, before registration procedure", right?

How can we mix them together?

Desired service may be used for purpose A, and may be used for purpose B,
but this not means A and B *MUST* be free to be cross-referenced, imho.
So I agree LMA-discovery refer on desired service, and I disagree
LMA-discovery refer on RFC5149.
And I am open for any clarification on desired service, if it is not clear.

Xiangsong

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Tuesday, September 21, 2010 1:40 AM
> To: jouni korhonen
> Cc: Xiangsong Cui; [email-masked]
> Subject: Re: [netlmm] Some comments // RE: Fwd: New Version Notification
for

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 21 Sep 2010 14:57:19 -0700

> LMA, before registration procedure", right?

No. Read through the rest of the Introduction in RFC 5149. It 
specifically talks about distinguishing between multiple services that 
can be provided to a mobile node and how to identify the service that 
the mobile node wants to use when it sends a Binding Update to the home 
agent. (in PMIPv6, it would be the PBU from the MAG to the LMA).

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 26 Sep 2010 12:49:54 -0700

It seems to me that a reference to RFC5149 and a description of how it applies is appropriate.  Vijay, can this be handled as RFC-Editor notes?  I'm wondering if there is any reason we can't move this document along to IESG review in its current state.  

Vidya

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Vijay Devarapalli
> Sent: Tuesday, September 21, 2010 2:57 PM
> To: Xiangsong Cui
> Cc: [email-masked]
> Subject: Re: [netlmm] Some comments // RE: Fwd: New Version
> Notification for draft-ietf-netlmm-lma-discovery-05
>