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.
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: <Internet-Drafts at ietf.org>
To: <i-d-announce at ietf.org>
Cc: <netlmm at ietf.org>
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