[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
Ok, lets agree to disagree then.
Vijay
> -----Original Message-----
> From: Xiangsong Cui [mailto:Xiangsong.Cui at huawei.com]
> Sent: Monday, August 31, 2009 11:10 PM
> To: Vijay Devarapalli
> Cc: netlmm at ietf.org
> 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" <vijay at wichorus.com>
> To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
> Cc: <netlmm at ietf.org>
> 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" <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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>