[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
Folks,
Service name based LMA discovery is covered in:
http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt
I think everybody wants this (see mails from Julien, Christian, etc.)
I am hoping that the chairs will hear it and make this draft a WG draft somehow.
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: Monday, August 24, 2009 1:12:46 PM
> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
>
> Hi,
>
> On Aug 24, 2009, at 2:11 PM, Xiangsong Cui wrote:
>
> > Hi Jouni,
> >
> >> As the text already states:
> >>
> >> ... If the MN
> >> originated service name also embeds the information of the entity
> >> hosting the service or the external network, then the MAG can
> >> construct a generic LMA FQDN (e.g., based on some pre-configured
> >> formatting rules) providing an access to the service or the external
> >> network.
> >>
> >> The service name must have enough information in it. And later we give an
> example of such existing service name.
> >
> > I think the key point is not the "example of such existing service name",
> > but the "pre-configured formatting rules".
> >
> > Does the MAG cache a formula, take the service name as the input value,
> > and calculate the LMA FQDN?
>
> Deployment, inter-operator agreements etc typically define the formatting rules.
> Rest is up to the implementation.
>
> > Could you give us an example of such "formatting rules"?
>
> The text gives a reference of "example of such existing service name" to 23.003.
>
> >
> > Additionally, I'm interested in "enough information", is there any criterion?
>
> The same text says:
>
> "..If the MN
> originated service name also embeds the information of the entity
> hosting the service or the external network, then the MAG can"
>
> So the service name just have to data/information that can be used to identify
> the entity (e.g. the operator) hosting the LMA. That is the criterion.
>
> >
> > IMHO, this is a strange and difficult solution.
>
> I don't think so. It might not be the most fabulous solution but already
> selected some by SDOs.
>
> Cheers,
> Jouni
>
> >
> >
> > Regards
> >
> > Xiangsong
> >
> > ----- Original Message ----- From: "jouni korhonen"
> > To: "Xiangsong Cui"
> > Cc:
> > Sent: Monday, August 24, 2009 4:56 PM
> > Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
> >
> >
> >> Hi,
> >>
> >> Thanks for the review. See my comments inline.
> >>
> >> On Aug 24, 2009, at 7:11 AM, Xiangsong Cui wrote:
> >>
> >>> Hi,
> >>>
> >>> I read the document just now, and I have some comments on
> >>> section 3.
> >>>
> >>> Section 3.1,
> >>> " The solution discussed in this section has issues if MN's identity
> >>> does not embed enough information. In a case the MN identity does
> >>> not embed any LMA hosting entity information, the MAG might use a
> >>> local database to map MN identities to corresponding LMAs. However,
> >>> this solution is unlikely to scale outside a limited PMIPv6 domain."
> >>>
> >>> I agree the solution "map MN id to corresponding LMA", and I
> >>> dislike the solution "construct a generic LMA FQDN" (it depends on
> >>> special assumption and precondition).
> >>> But the solution "map MN id to corresponding LMA" also need a
> >>> precondition, the MAG should know all addresses of the LMAs in the
> >>> domain. So in this case, it is not "LMA discovery" but "LMA selection".
> >>> I think the WG may rename the working item to "LMA discovery and
> >>> selection" (favorable), or remove the solution from "LMA discovery".
> >>
> >> Well.. I don't have big feelings related to the I-D name. It is changeable.
> >>
> >> Related to the "selection" versus discovery we could write that:
> >>
> >> ...
> >> does not embed enough information. In a case the MN identity does
> >> not embed any LMA hosting entity information, the MAG might use a
> >> local database to map MN identities to corresponding LMAs FQDN.
> >> ...
> >>
> >>
> >>>
> >>>
> >>> 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?
> >>
> >>
> >>>
> >>> Section 3.3,
> >>> For the MAG, is the service name enough to get out the LMA FQDN
> >>> or LMA IP address?
> >>> I don't understand how the MAG can construct the LMA FQDN only
> >>> by the service name.
> >>
> >> As the text already states:
> >>
> >> ... If the MN
> >> originated service name also embeds the information of the entity
> >> hosting the service or the external network, then the MAG can
> >> construct a generic LMA FQDN (e.g., based on some pre-configured
> >> formatting rules) providing an access to the service or the external
> >> network.
> >>
> >> The service name must have enough information in it. And later we give an
> example of such existing service name.
> >>
> >> Cheers,
> >> Jouni
> >>
> >>
> >>>
> >>> Regards
> >>>
> >>> Xiangsong
> >>>
> >>>
> >>> ----- Original Message ----- From:
> >>> To:
> >>> Cc:
> >>> Sent: Monday, August 24, 2009 5:00 AM
> >>> Subject: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
> >>>
> >>>
> >>>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >>>> This draft is a work item of the Network-based Localized Mobility
> Management Working Group of the IETF.
> >>>>
> >>>>
> >>>> Title : LMA Discovery for Proxy Mobile IPv6
> >>>> Author(s) : J. Korhonen, V. Devarapalli
> >>>> Filename : draft-ietf-netlmm-lma-discovery-01.txt
> >>>> Pages : 10
> >>>> Date : 2009-08-23
> >>>>
> >>>> Large Proxy Mobile IPv6 deployments would benefit from a
> >>>> functionality, where a Mobile Access Gateway could dynamically
> >>>> discover a Local Mobility Anchor for a Mobile Node attaching to a
> >>>> Proxy Mobile IPv6 domain. The purpose of the dynamic discovery
> >>>> functionality is to reduce the amount of static configuration in the
> >>>> Mobile Access Gateway. This specification describes a number of
> >>>> possible dynamic Local Mobility Anchor discovery solutions.
> >>>>
> >>>> A URL for this Internet-Draft is:
> >>>> http://www.ietf.org/internet-drafts/draft-ietf-netlmm-lma-discovery-01.txt
> >>>>
> >>>> Internet-Drafts are also available by anonymous FTP at:
> >>>> ftp://ftp.ietf.org/internet-drafts/
> >>>>
> >>>> Below is the data which will enable a MIME compliant mail reader
> >>>> implementation to automatically retrieve the ASCII version of the
> >>>> Internet-Draft.
> >>>>
> >>>
> >>>
> >>>
> --------------------------------------------------------------------------------
> >>>
> >>>
> >>>> _______________________________________________
> >>>> netlmm mailing list
> >>>> netlmm at ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/netlmm
> >>>
> >>> _______________________________________________
> >>> netlmm mailing list
> >>> netlmm at ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netlmm
> >
>
> _______________________________________________
> netlmm mailing list
> netlmm at ietf.org
> https://www.ietf.org/mailman/listinfo/netlmm