[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt

To: Xiangsong Cui <Xiangsong.Cui at huawei.com>, jouni korhonen <jouni.nospam at gmail.com>
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
From: Vijay Devarapalli <vijay at wichorus.com>
Date: Mon, 31 Aug 2009 21:34:24 -0700
Cc: netlmm at ietf.org
Delivered-to: netlmm at core3.amsl.com
In-reply-to: <000e01ca2aa3$df9c03a0$40106f0a at china.huawei.com>
List-archive: <http://www.ietf.org/mail-archive/web/netlmm>
List-help: <mailto:netlmm-request@ietf.org?subject=help>
List-id: NETLMM working group discussion list <netlmm.ietf.org>
List-post: <mailto:netlmm@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
Thread-index: AcoqvXtXxoRYEjp9G0ae8C8Wxeloaw==
Thread-topic: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
User-agent: Microsoft-Entourage/12.10.0.080409
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" <jouni.nospam at gmail.com>
> To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
> Cc: "Vijay Devarapalli" <vijay at wichorus.com>; <netlmm at ietf.org>
> 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"
>>> <jouni.nospam at gmail.com
>>>> 
>>> To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
>>> Cc: "Vijay Devarapalli" <vijay at wichorus.com>; <netlmm at ietf.org>
>>> 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"
>>>>> <jouni.nospam at gmail.com
>>>>>> 
>>>>> To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
>>>>> Cc: "Vijay Devarapalli" <vijay at wichorus.com>; <netlmm at ietf.org>
>>>>> 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"
>>>>>>> <jouni.nospam at gmail.com
>>>>>>>> 
>>>>>>> To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
>>>>>>> Cc: "Vijay Devarapalli" <vijay at wichorus.com>; <netlmm at ietf.org>
>>>>>>> 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"
>>>>>>>>> <jouni.nospam at gmail.com
>>>>>>>>>> 
>>>>>>>>> To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
>>>>>>>>> Cc: "Vijay Devarapalli" <vijay at wichorus.com>; <netlmm at ietf.org>
>>>>>>>>> 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"
>>>>>>>>>>> <jouni.nospam at gmail.com
>>>>>>>>>>>> 
>>>>>>>>>>> To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
>>>>>>>>>>> Cc: "Vijay Devarapalli" <vijay at wichorus.com>;  <netlmm at ietf.org>
>>>>>>>>>>> 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"
>>>>>>>>>>>> <vijay at wichorus.com
>>>>>>>>>>>> 
>>>>>>>>>>>> To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>; "jouni
>>>>>>>>>>>> korhonen" <jouni.nospam at gmail.com
>>>>>>>>>>>> 
>>>>>>>>>>>> Cc: <netlmm at ietf.org>
>>>>>>>>>>>> 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:Xiangsong.Cui at huawei.com]
>>>>>>>>>>>> Sent: Monday, August 24, 2009 7:13 PM
>>>>>>>>>>>> To: Vijay Devarapalli; jouni korhonen
>>>>>>>>>>>> Cc: netlmm at ietf.org
>>>>>>>>>>>> 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"
>>>>>>>>>>>> <vijay at wichorus.com
>>>>>>>>>>>> 
>>>>>>>>>>>> To: "jouni korhonen" <jouni.nospam at gmail.com>;  "Xiangsong
>>>>>>>>>>>> Cui"
>>>>>>>>>>>> <Xiangsong.Cui at huawei.com>
>>>>>>>>>>>> Cc: <netlmm at ietf.org>
>>>>>>>>>>>> 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
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
>> 
>
Follow-Ups:
- Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
  - From: Xiangsong Cui
References:
- Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
  - From: Xiangsong Cui
Prev by Date: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
Next by Date: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
Previous by thread: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
Next by thread: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
Index(es):
- Date
- Thread