[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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