Re: [netlmm] Some comments // RE: Fwd: New Version Notification for draft-ietf-netlmm-lma-discovery-05

Xiangsong Cui <Xiangsong.Cui@huawei.com> Thu, 16 September 2010 09:58 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 958F83A6926 for <netlmm@core3.amsl.com>; Thu, 16 Sep 2010 02:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.062
X-Spam-Level:
X-Spam-Status: No, score=-0.062 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 s6xHADjrqSSJ for <netlmm@core3.amsl.com>; Thu, 16 Sep 2010 02:58:58 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 187383A6924 for <netlmm@ietf.org>; Thu, 16 Sep 2010 02:58:58 -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 <0L8U00J193LD34@szxga04-in.huawei.com> for netlmm@ietf.org; Thu, 16 Sep 2010 17:56:01 +0800 (CST)
Received: from c00111037 ([10.111.16.128]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L8U00JO83LCRD@szxga04-in.huawei.com> for netlmm@ietf.org; Thu, 16 Sep 2010 17:56:01 +0800 (CST)
Date: Thu, 16 Sep 2010 17:56:00 +0800
From: Xiangsong Cui <Xiangsong.Cui@huawei.com>
In-reply-to: <6D56C9EB-84BE-4CF6-8CD1-8C153AF23450@gmail.com>
To: 'jouni korhonen' <jouni.nospam@gmail.com>
Message-id: <006a01cb5585$5e3f01f0$1abd05d0$%cui@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-cn
Content-transfer-encoding: 7BIT
Thread-index: ActVg82tP9I6HftdRG2ZE2qdWZSOywAAKbcA
References: <20100913093616.B6F433A6954@core3.amsl.com> <E6A9CB0C-41C3-48F7-A5A2-3CD1FA51DFD5@gmail.com> <003f01cb553d$acd29900$0677cb00$%cui@huawei.com> <6EB3A011-D90A-41E0-847B-EE4EC35A37EC@gmail.com> <006901cb557f$4e5482c0$eafd8840$%cui@huawei.com> <6D56C9EB-84BE-4CF6-8CD1-8C153AF23450@gmail.com>
Cc: netlmm@ietf.org
Subject: Re: [netlmm] Some comments // RE: Fwd: New Version Notification for draft-ietf-netlmm-lma-discovery-05
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: Thu, 16 Sep 2010 09:58:59 -0000

Thanks for your quick response.

Removing the "(es)" is very useful, otherwise we would be confused by
"receiving multiple LMA addresses, but sending PBU to one LMA".

As to the updating procedure, since this document would be a "informational"
RFC, so I can also accept the overall description.
But I would worry about the popularization of this documents, because it is
a bit too general.

Best regards,
Xiangsong


> -----Original Message-----
> From: jouni korhonen [mailto:jouni.nospam@gmail.com]
> Sent: Thursday, September 16, 2010 5:45 PM
> To: Xiangsong Cui
> Cc: netlmm@ietf.org
> Subject: Re: Some comments // RE: [netlmm] Fwd: New Version Notification
for
> draft-ietf-netlmm-lma-discovery-05
> 
> Hi,
> 
> Inline..
> 
> On Sep 16, 2010, at 12:12 PM, Xiangsong Cui wrote:
> 
> [snip]
> 
> >>
> >> Anyway, I have no problem of removing RFC5149 reference if that is
> > offending.
> >> It only appeared in -04 version of this draft.
> >
> > I prefer "selecting a LMA based on desired services." Thanks!
> 
> Ok. Good.
> 
> [snap]
> 
> >
> > Do you mean, when the MAG download MN's policy profile from AAA server,
> the
> > identifier of the selected LMA is contained in the policy profile?
> > And as RFC5779, MAG can get LMA information by MIP6-Agent-Info AVP, and
> the
> > AVP may be hostname or IP address.
> > So it seems MAG can get two set of LMA information, separately from
> Diameter
> > AVP and policy profile.
> 
> It can based on the ABNF in RFC5779. But in Section 2.1 approach MAG would
> only be receiving the IP address. Why would AAA server purposely try to
> confuse the MAG?
> 
> Anyway, RFC5779 is an example here. So going into RFC5779 details here is
not
> in the scope.
> 
> > And, what you said here seems that, if AAA server has already assigned a
> LMA
> > to the given MN (i.e. handover case), the AAA server would only provide
the
> > unified LMA address to MAG, LMA host name would not be provided to MAG
> in
> > this case.
> >
> > If this is true, then I can understand.
> 
> Yep. Good.
> 
> 
> [clip]
> 
> >>
> >> If you have something in mind that would make the text clearer how the
> > goal is
> >> achieved, please propose text.
> >
> > I suggest we add some text about "if MAG receives multiple LMA address
> from
> > AAA server or DNS server, then ..."
> >
> > Example, from:
> >   Once the MAG receives the LMA IP address(es), it sends Proxy Binding
> >   Update (PBU) message for the newly authenticated and authorized MN.
> >   The MAG expects that the LMA returned by the AAA server is able to
> >   provide mobility session continuity for the MN, i.e. after a handover
> >   the LMA would be the same one the MN already has a mobility session
> >   set up with.
> >
> > To:
> >   The MAG expects that the LMA returned by the AAA server is able to
> >   provide mobility session continuity for the MN, i.e. after a handover
> >   the LMA would be the same one the MN already has a mobility session
> >   set up with.
> >   Once the MAG receives the unified LMA IP address, it sends Proxy
Binding
> >   Update (PBU) message for the newly authenticated and authorized MN to
> >   this LMA. If the MAG receives multiple LMA addresses from AAA server
or
> >   DNS server, then .......
> >
> > In my mind, there may be two ways in this case, the simple one is "the
MAG
> > may lost session continuity", and the robust one is "the MAG interacts
> > separately with these addresses, finds out the right LMA which the MN
has
> > already been registered to, and sends PBU to that LMA". The robust one
is
> > very complex and may affect handover performance, but would keep session
> > continuity. These two cases are in different requirement levels, and
either
> > is OK for me.
> 
> Actually I would just rephrase my original text like:
> 
>    Once the MAG receives the LMA IP address, it sends Proxy Binding
>    Update (PBU) message for the newly authenticated and authorized MN.
> 
> That basically states the MAG receives *one* address thus no issue with
> multiple choices.
> 
> 
> [clipetisnip]
> 
> >>
> >> Obviously the whole section is about AAA-based solution. Anyway would
the
> >> following be clearer?
> >>
> >>   ..
> >>   Store.  For example, the LMA could perform the Policy Store update
> > using
> >>   the AAA infrastructure once it receives the initial PBU from the MAG
> > for
> >>   the new mobility session.
> >
> > Hmm, I hope this would be more detailed.
> >
> > From my perspective, as a PMIPer, I care what should I do on my MAG and
> LMA.
> > If you say the MAG and LMA can utilize the feature of LMA discovery, but
all
> > I can do is expecting AAA Server's behavior/response and some general
> > update, that is not enough. I, at least, need to know, how I can update
the
> > related state, this means which protocol (Diameter or xxx) and which AVP
> > (defined in xxx) should I use, and what operation rule I should follow
(if
> > there is rule). Because in most cases, LMA and AAA server are from
different
> > vendors, we need an explicit reference.
> 
> We are not going to redefine RFC5779 in this document. I rather stick with
my
> new proposed "overall description" text. Section 4 also discusses this
particular
> update procedure from handover context.
> 
> - Jouni
> 
> 
> 
> >
> > Thanks and best regards,
> > Xiangsong
> >
> >>
> >>
> >> - Jouni
> >>
> >>
> >>
> >>
> >>>
> >>> Thanks and regards,
> >>> Xiangsong
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On
> >> Behalf
> >>>> Of jouni korhonen
> >>>> Sent: Monday, September 13, 2010 5:40 PM
> >>>> To: netlmm@ietf.org List
> >>>> Subject: [netlmm] Fwd: New Version Notification for
> >>>> draft-ietf-netlmm-lma-discovery-05
> >>>>
> >>>> FYI. We reduced the text a bit and added recommendations as asked by
> > Jari.
> >>>>
> >>>> - Jouni
> >>>>
> >>>> Begin forwarded message:
> >>>>
> >>>>> From: IETF I-D Submission Tool <idsubmission@ietf.org>;
> >>>>> Date: September 13, 2010 12:36:16 PM GMT+03:00
> >>>>> To: jouni.nospam@gmail.com
> >>>>> Cc: dvijay@gmail.com
> >>>>> Subject: New Version Notification for
> > draft-ietf-netlmm-lma-discovery-05
> >>>>>
> >>>>>
> >>>>> A new version of I-D, draft-ietf-netlmm-lma-discovery-05.txt has
been
> >>>> successfully submitted by Jouni Korhonen and posted to the IETF
> >>> repository.
> >>>>>
> >>>>> Filename:	 draft-ietf-netlmm-lma-discovery
> >>>>> Revision:	 05
> >>>>> Title:		 LMA Discovery for Proxy Mobile IPv6
> >>>>> Creation_date:	 2010-09-13
> >>>>> WG ID:		 netlmm
> >>>>> Number_of_pages: 9
> >>>>>
> >>>>> Abstract:
> >>>>> 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.
> >>>>>
> >>>>>
> >>>>>
> >>>>> The IETF Secretariat.
> >>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> netlmm mailing list
> >>>> netlmm@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/netlmm
> >>>
> >