Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt

[Xiangsong Cui <[e-mail]>]

Hi Vijay,

I am sorry I can't agree on this.
I think this is a dangerous overflow.

For example, let's take a look on MIP4 protocol, which is
host-based. I am sure you know it better than me.

When the MIP4 node sends Registration Request to the network,
it encapsulates the mobility signal in UDP payload.
This mechanism, which offers the binding information, is in scope
of mobility management, is in CMIP scope.

While in this case, the MN sends the LMA information to the network.
In my understanding, binding information and LMA information
are both mobility related information.

If you say the solution of passing LMA information to the network
is in scope of PMIP, could you kindly tell me, where is the boundary
between CMIP and PMIP?

Regards
Xiangsong


----- Original Message ----- 
From: "Vijay Devarapalli" <[e-mail]>
To: "Xiangsong Cui" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, September 01, 2009 1:12 PM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt


> Hi Xiansong,
>
> On 8/31/09 10:05 PM, "Xiangsong Cui" wrote:
>
>> Hi Vijay,
>>
>> I'm not saying the MN does mobility management,
>> I'm saying the MN, which does the action related to mobility
>> management, is involved in the mobility management.
>
> No. Again, passing some information at L2 is not the same being "involved"
> in mobility management. This is a slippery slope, trying to define when 
> you
> can say the MN is "involved" in mobility management.
>
> I think the existing text is fine for an Informational document.
>
> So can we please move on?
>
> Vijay
>
>> I think the mobility management, in this solution, is achieved by
>> multiple elements, including the MN and the MAG and others.
>>
>> In my understanding, passing the LMA information at L2 is a
>> manner of offering the LMA information.
>> Passing is subset of offering, while offering is a subset of
>> involvement, which conflicts with the charter.
>>
>> Regards
>> Xiangsong
>>
>> ----- Original Message -----
>> From: "Vijay Devarapalli" <[e-mail]>
>> To: "Xiangsong Cui" <[e-mail]>; "jouni korhonen"
>> <[e-mail]>
>> Cc: <[e-mail]>
>> Sent: Tuesday, September 01, 2009 12:34 PM
>> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
>>
>>
>>> Hi Xiangsong,
>>>
>>> On 8/31/09 6:31 PM, "Xiangsong Cui" wrote:
>>>
>>>> Hi Jouni,
>>>>
>>>> It is not only about modification, but also involvement.
>>>>
>>>> In NETLMM WG charter, there is clear statement:
>>>>
>>>> Description of Working Group:
>>>>
>>>> "This working
>>>> group is tasked with defining a network-based local mobility
>>>> management protocol, where local IP mobility is handled without
>>>>                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> involvement from the mobile node."
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>
>>>> And as I said before, in this solution, MN is involved in the
>>>> mobility management.
>>>>
>>>> So my comment is to remove this solution from the WG draft.
>>>
>>> I disagree. Passing the LMA information at L2 is not the same the MN 
>>> doing
>>> mobility management. So this shouldn't be removed from the draft.
>>>
>>> Vijay
>>>
>>>>
>>>> Thank you for your discussion.
>>>>
>>>> Regards
>>>> Xiangsong
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "jouni korhonen" <[e-mail]>
>>>> To: "Xiangsong Cui" <[e-mail]>
>>>> Cc: "Vijay Devarapalli" <[e-mail]>; <[e-mail]>
>>>> Sent: Monday, August 31, 2009 5:25 PM
>>>> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
>>>>
>>>>
>>>>> Hi Xiangsong,
>>>>>
>>>>>
>>>>> On Aug 29, 2009, at 4:16 AM, Xiangsong Cui wrote:
>>>>>
>>>>>> Hi Jouni,
>>>>>>
>>>>>> Please see inline.
>>>>>>
>>>>>> Regards
>>>>>> Xiangsong
>>>>>>
>>>>>>
>>>>>> ----- Original Message ----- From: "jouni korhonen"
>>>>>> <[e-mail]
>>>>>>>
>>>>>> To: "Xiangsong Cui" <[e-mail]>
>>>>>> Cc: "Vijay Devarapalli" <[e-mail]>; <[e-mail]>
>>>>>> Sent: Friday, August 28, 2009 6:56 PM
>>>>>> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-
>>>>>> discovery-01.txt
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Aug 28, 2009, at 12:19 PM, Xiangsong Cui wrote:
>>>>>>>
>>>>>>>> Hi Jouni,
>>>>>>>>
>>>>>>>>> And what's the problem with that if it is part of the normal 
>>>>>>>>> lower
>>>>>>>>> layer attach procedure? The MN has a blob of information  that it
>>>>>>>>> knows what to do with to get an access, but does not  know/care
>>>>>>>>> about
>>>>>>>>> its content. Yet, we have not changed anything  in the MN  that it
>>>>>>>>> would do normally in any case.
>>>>>>>>
>>>>>>>> I don't know what kind of MN or OS can achieve this operation,
>>>>>>>> maybe you can give me some example.
>>>>>>>
>>>>>>> As I said in an earlier mail, this procedure is analogous to 3G/EPS
>>>>>>> attach procedure under certain conditions. There's a bunch of such
>>>>>>> MNs
>>>>>>> out there.. but that is not relevant from the I-D point of view.
>>>>>>>
>>>>>>>>
>>>>>>>> Even the MN exists, you are now designing a new container, and
>>>>>>>> putting
>>>>>>>
>>>>>>> Hmm.. If such MN & lower layer exists then I could not possibly be
>>>>>>> designing any new container as it is already there.
>>>>>>
>>>>>> We need some existing examples for this. The solution can not depend
>>>>>> on
>>>>>> any nonexistent assumption.
>>>>>
>>>>>  If it makes folks happy, we can add a reference to one example of 
>>>>> such
>>>>> functionality.
>>>>>
>>>>>    The solution described in this section is similar to the solution
>>>>>    discussed in Section 3.1.  Instead of deriving the LMA FQDN from 
>>>>> the
>>>>>    MN identity, the MAG receives a LMA FQDN or an IP address
>>>>> information
>>>>>    from lower layers, for example, as a part of the normal lower layer
>>>>>    signaling when the MN attaches to the network.  One existing 
>>>>> example
>>>>>    of such lower layer functionality is the Access Point Name
>>>>>    Information Element (APN IE) in 3GPP radio's network access
>>>>> signaling
>>>>>    capable of carrying a FQDN [3GPP.24.008].  However, in general this
>>>>>    means the MN is also the originator of the LMA information.  The 
>>>>> LMA
>>>>>    information content as such can be transparent to the MN, meaning
>>>>> the
>>>>>    MN has no knowledge it being anything LMA related.
>>>>>
>>>>>
>>>>>>>
>>>>>>>> special new information block in it, the MN must read and include
>>>>>>>> the
>>>>>>>
>>>>>>> If the information blob were transparent to the MN, the MN would 
>>>>>>> not
>>>>>>> see anything special in it.
>>>>>>
>>>>>> The precondition is a problem, another problem is that the MN does do
>>>>>> the action related to mobility management.
>>>>>>
>>>>>> Even the action (i.e. offering LMA information ) is not in the
>>>>>> consciousness of the MN, the fact does still exist,
>>>>>> the action is done by the MN and the MN is involved in the mobility
>>>>>> management.
>>>>>>
>>>>>> The principle of NETLMM WG is "MN not *involved* in the mobility
>>>>>> management", but not "MN not *active* in the mobility management",
>>>>>> right?
>>>>>
>>>>> Well.. the charter talks about "specifying any changes to mobile hosts
>>>>> is
>>>>> out of scope", which in most cases realizes to no host involvement  or
>>>>> similar that would require code changes etc. However, in this
>>>>> particular
>>>>> case, when we talk about MNs that have desired capabilities  at lower
>>>>> layers (e.g. in network access signaling), we are not  changing the
>>>>> mobile
>>>>> host but just taking advantage of the existing  functionality on the
>>>>> _network_ side.
>>>>>
>>>>> From my side, I am done now ;)
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Jouni
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>> newly-added additional information block in the signal message.
>>>>>>>
>>>>>>> And the MN would do the same even if PMIP was not deployed.
>>>>>>>
>>>>>>>> Does it not need extension or enhancement?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jouni
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Regards
>>>>>>>> Xiangsong
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message ----- From: "jouni korhonen"
>>>>>>>> <[e-mail]
>>>>>>>>>
>>>>>>>> To: "Xiangsong Cui" <[e-mail]>
>>>>>>>> Cc: "Vijay Devarapalli" <[e-mail]>; <[e-mail]>
>>>>>>>> Sent: Friday, August 28, 2009 4:44 PM
>>>>>>>> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-
>>>>>>>> discovery-01.txt
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On Aug 28, 2009, at 11:25 AM, Xiangsong Cui wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> please see inline.
>>>>>>>>>>
>>>>>>>>>> Regards/Xiangsong
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----- Original Message ----- From: "jouni korhonen"
>>>>>>>>>> <[e-mail]
>>>>>>>>>>>
>>>>>>>>>> To: "Xiangsong Cui" <[e-mail]>
>>>>>>>>>> Cc: "Vijay Devarapalli" <[e-mail]>; <[e-mail]>
>>>>>>>>>> Sent: Friday, August 28, 2009 4:05 PM
>>>>>>>>>> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-
>>>>>>>>>> discovery-01.txt
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On Aug 28, 2009, at 5:11 AM, Xiangsong Cui wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Jouni,
>>>>>>>>>>>>
>>>>>>>>>>>>> However, the LMA information content as such can be 
>>>>>>>>>>>>> transparent
>>>>>>>>>>>>> to
>>>>>>>>>>>>> the MN, meaning the MN has no knowledge it being anything LMA
>>>>>>>>>>>>> related.
>>>>>>>>>>>>
>>>>>>>>>>>> If the MN don't know what the information is, why does it
>>>>>>>>>>>> include
>>>>>>>>>>>> the
>>>>>>>>>>>> content in the transmitted message?
>>>>>>>>>>>
>>>>>>>>>>> It can be part of a lower layer attach procedure and the MN 
>>>>>>>>>>> does
>>>>>>>>>>> what it is specified to do.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I can't understand this situation: some information content is
>>>>>>>>>>>> included
>>>>>>>>>>>> in the signal message, but the origin and the destination do
>>>>>>>>>>>> take
>>>>>>>>>>>> different
>>>>>>>>>>>> comprehension on this content.
>>>>>>>>>>>
>>>>>>>>>>> For example, the MN has some operator provisioned information
>>>>>>>>>>> that
>>>>>>>>>>> the MN knows it needs to signal to the network during the 
>>>>>>>>>>> attach
>>>>>>>>>>> procedure
>>>>>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>>>>>> In these cases, MN knows what the information is, and knows the
>>>>>>>>>> information should be transimitted to the network, and then it
>>>>>>>>>> does
>>>>>>>>>> signal
>>>>>>>>>> the information to the network.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> And what's the problem with that if it is part of the normal 
>>>>>>>>> lower
>>>>>>>>> layer attach procedure? The MN has a blob of information  that it
>>>>>>>>> knows what to do with to get an access, but does not  know/care
>>>>>>>>> about
>>>>>>>>> its content. Yet, we have not changed anything  in the MN  that it
>>>>>>>>> would do normally in any case.
>>>>>>>>>
>>>>>>>>> Jouni
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> in order to get access & reach certain desired service. The
>>>>>>>>>>> information happens to be in a FQDN format that maps to a
>>>>>>>>>>> specific
>>>>>>>>>>> LMA. The MAG knows this fact but the MN does not care/  know 
>>>>>>>>>>> about
>>>>>>>>>>> it. This is analogous to 3G/EPC attach procedure   under certain
>>>>>>>>>>> conditions.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Jouni
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Xiangsong
>>>>>>>>>>>>
>>>>>>>>>>>> ----- Original Message ----- From: "jouni korhonen"
>>>>>>>>>>>> <[e-mail]
>>>>>>>>>>>>>
>>>>>>>>>>>> To: "Xiangsong Cui" <[e-mail]>
>>>>>>>>>>>> Cc: "Vijay Devarapalli" <[e-mail]>; <[e-mail]>
>>>>>>>>>>>> Sent: Thursday, August 27, 2009 9:12 PM
>>>>>>>>>>>> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-
>>>>>>>>>>>> discovery-01.txt
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Aug 27, 2009, at 11:57 AM, Xiangsong Cui wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Jouni,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Let's take a precise analyse on this issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You said such information may come from lower layers,
>>>>>>>>>>>>> but who generate this information?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Does lower layer generate the LMA information or the
>>>>>>>>>>>>> LMA information does depend on the link type?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think it is not.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe it is the user who configures the LMA information
>>>>>>>>>>>>> in the mobile node (i.e. the device), but in the MAG
>>>>>>>>>>>>> perspective,
>>>>>>>>>>>>> the initiator of the message which contains the LMA
>>>>>>>>>>>>> information,
>>>>>>>>>>>>> the initiator is the MN, the MAG gets the LMA information from
>>>>>>>>>>>>> the mobile node.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For example, the MAG gets LMA information from AAA server,
>>>>>>>>>>>>> and the LMA information in AAA server is configured by the
>>>>>>>>>>>>> administrator.
>>>>>>>>>>>>> We can say MAG gets LMA information from AAA server but nobody
>>>>>>>>>>>>> says MAG gets LMA information from the administrator.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So I think it is a MN-assist solution.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The MN is only doing what it would do independent of PMIP 
>>>>>>>>>>>>> being
>>>>>>>>>>>>> deployed or not and the MAG just makes advantage of it.  Some
>>>>>>>>>>>>> existing systems & MNs already do this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Based on the discussion we have had I think it is now worth
>>>>>>>>>>>>> keeping this solution in the I-D. I would, however, reword  it
>>>>>>>>>>>>> like:
>>>>>>>>>>>>>
>>>>>>>>>>>>> The solution described in this section is similar to the
>>>>>>>>>>>>> solution
>>>>>>>>>>>>> discussed in Section 3.1.  Instead of deriving the LMA FQDN
>>>>>>>>>>>>> from the
>>>>>>>>>>>>> MN identity, the MAG receives explicit LMA FQDN or IP address
>>>>>>>>>>>>> information from lower layers, for example, as a part of the
>>>>>>>>>>>>> normal
>>>>>>>>>>>>> lower layer signaling when the MN attaches to the network.
>>>>>>>>>>>>> This
>>>>>>>>>>>>> usually means the MN is also the originator of the LMA
>>>>>>>>>>>>> information.
>>>>>>>>>>>>> However, the LMA information content as such can be 
>>>>>>>>>>>>> transparent
>>>>>>>>>>>>> to
>>>>>>>>>>>>> the MN, meaning the MN has no knowledge it being anything LMA
>>>>>>>>>>>>> related.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Jouni
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards/Xiangsong
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ----- Original Message ----- From: "jouni korhonen"
>>>>>>>>>>>>> <[e-mail]
>>>>>>>>>>>>>
>>>>>>>>>>>>> To: "Xiangsong Cui" <[e-mail]>
>>>>>>>>>>>>> Cc: "Vijay Devarapalli" <[e-mail]>;
>>>>>>>>>>>>> <[e-mail]>
>>>>>>>>>>>>> Sent: Thursday, August 27, 2009 4:15 PM
>>>>>>>>>>>>> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-
>>>>>>>>>>>>> discovery-01.txt
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Aug 27, 2009, at 5:11 AM, Xiangsong Cui wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Vijay,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think I got your point, but I still have some questions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1, NETLMM WG is about mobility management, so the item
>>>>>>>>>>>>> of LMA discovery is of course in scope of mobility
>>>>>>>>>>>>> management,
>>>>>>>>>>>>> is it right?
>>>>>>>>>>>>>
>>>>>>>>>>>>> ok.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2, MN provides LMA information to MAG, is a *MN-assistant*
>>>>>>>>>>>>> LMA discovery, is it right?
>>>>>>>>>>>>>
>>>>>>>>>>>>> We are a bit on a grey area here. Like the text says such
>>>>>>>>>>>>> information may come from lower layers. If such information
>>>>>>>>>>>>> delivery is e.g. part of the normal L2 attach procedure
>>>>>>>>>>>>> independent whether there is PMIP or not, I would not call
>>>>>>>>>>>>> it
>>>>>>>>>>>>> in that case MN assisted LMA discovery.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3, MN-assistant LMA discovery means MN involves in the
>>>>>>>>>>>>> mobility
>>>>>>>>>>>>> management, is it right?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Continuing from the above. If the information that MN
>>>>>>>>>>>>> provides
>>>>>>>>>>>>> is configured into MNs and this configuration is   independent
>>>>>>>>>>>>> whether there is PMIP or not, I would not say   that MN is
>>>>>>>>>>>>> involved in the mobility management. The  content  of the
>>>>>>>>>>>>> configuration data might then be different  depending  whether
>>>>>>>>>>>>> PMIP is used but that is transparent to  MNs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Jouni
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>
>>>>>>>>>>>>> Xiangsong
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ----- Original Message ----- From: "Vijay Devarapalli"
>>>>>>>>>>>>> <[e-mail]
>>>>>>>>>>>>>
>>>>>>>>>>>>> To: "Xiangsong Cui" <[e-mail]>; "jouni
>>>>>>>>>>>>> korhonen" <[e-mail]
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cc: <[e-mail]>
>>>>>>>>>>>>> Sent: Thursday, August 27, 2009 8:32 AM
>>>>>>>>>>>>> Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-lma-
>>>>>>>>>>>>> discovery-01.txt
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are right. I am not disagreeing that the mobile node
>>>>>>>>>>>>> knows that
>>>>>>>>>>>>> PMIPv6 is being used in the network when it sends the LMA
>>>>>>>>>>>>> information to
>>>>>>>>>>>>> the MAG. But we have a sort of working assumption that  the
>>>>>>>>>>>>> MN
>>>>>>>>>>>>> is able to
>>>>>>>>>>>>> supply certain information to the MAG at L2, for example,
>>>>>>>>>>>>> attach versus
>>>>>>>>>>>>> handover indication. This would be similar to that.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Vijay
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Xiangsong Cui [mailto:[e-mail]]
>>>>>>>>>>>>> Sent: Monday, August 24, 2009 7:13 PM
>>>>>>>>>>>>> To: Vijay Devarapalli; jouni korhonen
>>>>>>>>>>>>> Cc: [e-mail]
>>>>>>>>>>>>> Subject: Re: [netlmm] I-D
>>>>>>>>>>>>> Action:draft-ietf-netlmm-lma-discovery-01.txt
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Vijay,
>>>>>>>>>>>>>
>>>>>>>>>>>>> In my understanding, LMA is a functional element of  mobility
>>>>>>>>>>>>> management, the mobile node with only simple IP stack can't
>>>>>>>>>>>>> recognize the information of LMA and can't transmit it  to
>>>>>>>>>>>>> MAG.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If the mobile node can't send this information to MAG,
>>>>>>>>>>>>> MAG can't receive this information from mobile node.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards/Xiangsong
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ----- Original Message ----- From: "Vijay Devarapalli"
>>>>>>>>>>>>> <[e-mail]
>>>>>>>>>>>>>
>>>>>>>>>>>>> To: "jouni korhonen" <[e-mail]>;  "Xiangsong
>>>>>>>>>>>>> Cui"
>>>>>>>>>>>>> <[e-mail]>
>>>>>>>>>>>>> Cc: <[e-mail]>
>>>>>>>>>>>>> Sent: Tuesday, August 25, 2009 1:47 AM
>>>>>>>>>>>>> Subject: Re: [netlmm] I-D
>>>>>>>>>>>>> Action:draft-ietf-netlmm-lma-discovery-01.txt
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 8/24/09 1:56 AM, "jouni korhonen" wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Section 3.2,
>>>>>>>>>>>>> "  This usually means the MN is the
>>>>>>>>>>>>>  originator of the LMA information and explicitly
>>>>>>>>>>>>> participates to the
>>>>>>>>>>>>>  mobility management signaling "
>>>>>>>>>>>>>
>>>>>>>>>>>>> In NETLMM, the principle is that the MN should not be
>>>>>>>>>>>>> involved
>>>>>>>>>>>>> in
>>>>>>>>>>>>> mobility management, right?
>>>>>>>>>>>>> So the solution "Receiving LMA FQDN or IP Address"
>>>>>>>>>>>>> should be
>>>>>>>>>>>>> deleted in the netlmm WG draft.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would be fine deleting this section. Others?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I disagree. The section explicitly says the MAG receives  the
>>>>>>>>>>>>> LMA FQDN or IP
>>>>>>>>>>>>> address from the MN in the lower layers. This is not the  same
>>>>>>>>>>>>> as the MN
>>>>>>>>>>>>> doing mobility management.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Vijay
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>