[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,
MAG making a DNS query for a service name and randomly selecting one LMA from among the returned replies is a good way of discovering LMA for each MN:
- it does not require MN providing input so it works with unmodified hosts,
- LMA load balancing is achieved.
Regards,
Behcet
----- Original Message ----
> From: jouni korhonen <jouni.nospam at gmail.com>
> To: Xiangsong Cui <Xiangsong.Cui at huawei.com>
> Cc: netlmm at ietf.org
> Sent: Thursday, August 27, 2009 8:12:38 AM
> 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"
> > To: "Xiangsong Cui"
> > Cc: "Vijay Devarapalli" ;
> > 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" > >>> >
> >>> To: "Xiangsong Cui" ; "jouni korhonen"
> > >>> >
> >>> Cc:
> >>> 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" > >>>> >
> >>>> To: "jouni korhonen" ; "Xiangsong Cui"
> >>>>
> >>>> Cc:
> >>>> 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
> >>>>
> >>>>
> >>>
> >
>
> _______________________________________________
> netlmm mailing list
> netlmm at ietf.org
> https://www.ietf.org/mailman/listinfo/netlmm