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