[Netext] LMA redirection (was RE: WG Review: Network-Based MobilityExtensions (netext))

Hi Yungui,

Some answer inline.

On Apr 22, 2009, at 11:58 AM, Yungui Wang wrote:

>
> Hi Jouni
>
> Please see inline...
>
>> -----Original Message-----
>> From: jouni korhonen [mailto:jouni.nospam at gmail.com]
>> Sent: Wednesday, April 22, 2009 2:56 PM
>> To: w52006 at huawei.com
>> Cc: 'Sri Gundavelli'; 'Vijay Devarapalli';
>> jouni.korhonen at nsn.com; netext at mail.mobileip.jp
>> Subject: Re: [Netext] LMA redirection (was RE: WG Review:
>> Network-Based MobilityExtensions (netext))
>>
>> Hi Yungui,
>>
>>
>> On Apr 22, 2009, at 5:47 AM, Yungui Wang wrote:
>>
>>> Hello Sri
>>>
>>>> Jouni's document is trying to provide a solution with the following
>>>> goals in mind:
>>>>
>>>> - Expose a single address for the entire LMA infrastructure
>>>
>>> What is the actual meaning here?
>>> In my understanding, MAG always knows the r2LMA address after
>>> PBA is received. Do you mean exposing a single address to AAA
>>> server or other? In practice, e.g. as 3GPP TS23.402 described,
>>> after PBU/PBA (reg or de-reg) processing is completed, r2LMA
>>> address et. information should be informed to HSS/AAA.
>>
>> Say, you have a number of LMA clusters (each cluster has e.g. 10
>> LMAs). Still, each individual LMA has one or more IP address. For a
>> generic LMA discovery you would only expose one rfLMA addresses per
>> cluster e.g. through DNS.  After the redirection the MAG would
>> communicate directly with the assigned r2LMA in some cluster.
>>
>
> Please see my previous mail to Sri.
> In my mind, the point 'Expose a single address for the entire LMA
> infrastructure' is not highlighted.

Righty. Currently this is somewhat vaguely said there. That is  
highlighted more to some extent in the next revision of the solution I- 
D. Once I get it submitted ;)

Anyway, how many addresses shall or will be exposed is always  
dependent on the deployment and operator configuration.

>
>>> Again, I think, MAG re-selecting LMA (e.g. based on rfLMA's
>>> redirection or overload indirection, or LMA address list from FQDN)
>>> is a good choice, at least for scenario of each LMA is separate box.
>>> This is because,
>>> on the one hand, each LMA neither needs explicit mobility
>>> management signaling to other, nor needs to know other's load info
>>> due to load info is a integrative and complex value (e.g. CPU 75%
>>> is overloading for one LMA, but not for another).
>>> on the other hand, it is consistent with basis LMA discovery
>>> mechanism.
>>
>> I don't think there needs to be any mobility signaling between LMAs.
>
> In this draft, when rfLMA redirect the MAG to a r2LMA, doesn't
> the rfLMA forward the request(PBU) to the r2LMA?

The current text in section 5.2. surface this topic and state it is  
out of scope of this specification. I guess we need to have some more  
text there but I really don't see a reason to define how rfLMA and  
r2LMA exactly exchange information/data between each other.

>>
>> Of course LMAs need to share information between each other but
>> obviously vendors have existing proprietary and standardized
>> solutions
>> for that.
>>
>>>>
>>>> - Allow the primary LMA to dynamically assign the LMA for a
>>>>  given session along the lines of RFC-4433, Dynamic Home
>>>>  Agent Assignment.
>>>
>>>> - Not require the primary LMA to be in path, once the assignment
>>>>  is done
>>>
>>> Always is it for each LMA is on the same level.
>>
>> I did not understand what you meant here.
>>
>
> Sorry. My point is, there is no primary LMA. Each LMA can do
> redirection if it is overloaded. After redirection completed, other
> LMA has taken over the corresponding session. So 'Not require
> the primary LMA to be in path' is a natural result.

It depends on the deployment and load balancer approach some decides  
to implement. So there are deployment models that would have a  
"primary LMA"/load balancer in path.. and some model where not.

Jouni

>
>
> B.R.
> Yungui
>
>>>>
>>>> - Not require multiple MIP signaling round trips after each
>>>>  assignment.
>>>
>>> It is little meaningful when LMA redirection less frequently
>>> happened.
>>
>> Cheers,
>> 	Jouni
>>
>>
>>>
>>>
>>> B.R.
>>> Yungui
>>>
>>>>
>>>> The document can certainly recognise that there are other solutions
>>>> possible, if exposed LMA stickiness is not of concern.
>>>>
>>>>
>>>> Regards
>>>> Sri
>>>>
>>>
>>> _______________________________________________
>>> NetExt mailing list
>>> NetExt at mail.mobileip.jp
>>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>