[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 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.
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" <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: 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" <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