Re: [netlmm] FW: I-D Action:draft-ietf-netlmm-lma-discovery-04.txt

Xiangsong Cui <Xiangsong.Cui@huawei.com> Tue, 08 June 2010 03:39 UTC

Return-Path: <Xiangsong.Cui@huawei.com>
X-Original-To: netlmm@core3.amsl.com
Delivered-To: netlmm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618543A6905 for <netlmm@core3.amsl.com>; Mon, 7 Jun 2010 20:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.92
X-Spam-Level: *
X-Spam-Status: No, score=1.92 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIx4sp563g4o for <netlmm@core3.amsl.com>; Mon, 7 Jun 2010 20:39:43 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5E2813A691E for <netlmm@ietf.org>; Mon, 7 Jun 2010 20:39:43 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3O00MAPFHX7H@szxga04-in.huawei.com> for netlmm@ietf.org; Tue, 08 Jun 2010 11:39:34 +0800 (CST)
Received: from c00111037 ([10.111.16.150]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3O008QPFHV1Q@szxga04-in.huawei.com> for netlmm@ietf.org; Tue, 08 Jun 2010 11:39:33 +0800 (CST)
Date: Tue, 08 Jun 2010 11:39:30 +0800
From: Xiangsong Cui <Xiangsong.Cui@huawei.com>
To: "Soininen, Jonne (NSN-FI/Espoo)" <Jonne.Soininen@nsn.com>, netlmm@ietf.org
Message-id: <014a01cb06bc$34fd87c0$96106f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3598
Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <C82411E0.B0511%Jonne.Soininen@nsn.com>
Subject: Re: [netlmm] FW: I-D Action:draft-ietf-netlmm-lma-discovery-04.txt
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jun 2010 03:39:44 -0000

Hello,
I have read the draft and have following comments.

Technological comments:

1, I am also against any L2 based or MN based solution in this draft,
    I remember I had a long discussion with the authors and expressed 
    the reason last year.

2, I think section 4 DNS considerations needs more clarification.
    I don't understand "Low TTL values increase the number of DNS
    queries considerably", and "the PMIPv6 domain LMA availability 
    or load information is dynamically updated into the DNS", and 
    "Typically AAA infrastructure is used for exchanging information 
     between the LMA and the Policy Store" and some others. 
    What is the relation between TTL and LMA discovery consistency? 
    How LMA load information is updated into the DNS/Policy Store? 
    these problems are not described in this draft.

3, The reference of RFC5149. I agree on selecting a LMA based on 
    desired service, but RFC5149 is used between MN and HA, or even
    between MAG and LMA. The time is after the LMA has been selected, 
    I mean LMA discovery happens before RFC5149 is involved.
    I guess maybe some Radius or Diameter extension is better reference?
    So the AAA server can select a LMA by the desired service.

4, "Once the MAG receives the LMA IP address(es), it sends Proxy Binding"
    I am not sure does this make sense. As to the handover, if the old MAG 
    can not transfer context to the new MAG, and the AAA responds multiple
    LMA addresses to the new MAG, how can the new MAG select the right
    LMA address (i.e. the one which is selected by the old MAG) from the list?
    If the context can be transferred to the new MAG, the new MAG does not
    need LMA discovery at that time.

Editorial comment:

section 2.1
After the MN has successfully authenticated for the network access
/After the MN has been successfully authenticated for the network access


Regards,
Xiangsong

----- Original Message ----- 
From: "Soininen, Jonne (NSN-FI/Espoo)" <Jonne.Soininen@nsn.com>
To: <netlmm@ietf.org>
Sent: Thursday, May 27, 2010 5:11 PM
Subject: [netlmm] FW: I-D Action:draft-ietf-netlmm-lma-discovery-04.txt


> Hello,
> 
> Jouni has published a new version of the LMA discovery document. Please,
> take a look to see if this version is acceptable for publishing as an RFC.
> 
> Cheers,
> 
> Jonne.
> ------ Forwarded Message
>> From: "ext Internet-Drafts@ietf.org" <Internet-Drafts@ietf.org>
>> Reply-To: <internet-drafts@ietf.org>
>> Date: Mon, 24 May 2010 08:00:01 -0700 (PDT)
>> To: <i-d-announce@ietf.org>
>> Cc: "netlmm@ietf.org" <netlmm@ietf.org>
>> Subject: I-D Action:draft-ietf-netlmm-lma-discovery-04.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-04.txt
>> Pages           : 10
>> Date            : 2010-05-24
>> 
>> 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 document describes several 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-04.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.
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> ------ End of Forwarded Message
> 
>


--------------------------------------------------------------------------------


> _______________________________________________
> netlmm mailing list
> netlmm@ietf.org
> https://www.ietf.org/mailman/listinfo/netlmm
>