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

["Vijay Devarapalli" <[e-mail]>]

Ok, lets agree to disagree then.

Vijay 

> -----Original Message-----
> From: Xiangsong Cui [mailto:[e-mail]] 
> Sent: Monday, August 31, 2009 11:10 PM
> To: Vijay Devarapalli
> Cc: [e-mail]
> Subject: Re: [netlmm] I-D 
> Action:draft-ietf-netlmm-lma-discovery-01.txt
> 
> 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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> > 
> 
>