[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,

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" <jouni.nospam at gmail.com > 
To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
Cc: <netlmm at ietf.org>
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: <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