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

jouni korhonen <jouni.nospam@gmail.com> Thu, 16 September 2010 10:02 UTC

Return-Path: <jouni.nospam@gmail.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 F2ED13A6AF6 for <netlmm@core3.amsl.com>; Thu, 16 Sep 2010 03:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level:
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96]
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 jautm+Mt+AzP for <netlmm@core3.amsl.com>; Thu, 16 Sep 2010 03:02:19 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 62D503A6940 for <netlmm@ietf.org>; Thu, 16 Sep 2010 03:02:19 -0700 (PDT)
Received: by wyi11 with SMTP id 11so1395490wyi.31 for <netlmm@ietf.org>; Thu, 16 Sep 2010 03:02:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=lGoX1V5QMH8vRhE8fTFfTwOoD5lv4zu+O1FsgMvYmh8=; b=hhcGxsKKrsz0HwjD6SWr1E916OSgwHG9C4ich0uAowjkmNd8S1ELBkFc6m+YbTSutC QU23jYKwrn5h31tU3Ghrr+59UyCSijrvW01uCTIB5lCxy3y30dQryMbBIXt/wtE50gUG M/DbPVpEVR/2QxmBSGTgWjgCLdMMFk56q7XFM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=kX9vK1ylr5q+XQgXF0g1Vzq6TZV6eTImbVv44mOdkPBTPrGXc4IkmMvu08/R7OYt9Q tw3LxmbaW0cCmFSP+uyyntkXdUe9K3WOQBJGTwZCsya9+JU5LeDTxq38TQQJ74oRcKDI Qp1ww7ouqSPj1lAkVwM1yoXB8S7LUmjLNXsRg=
Received: by 10.227.133.7 with SMTP id d7mr2606331wbt.54.1284631362624; Thu, 16 Sep 2010 03:02:42 -0700 (PDT)
Received: from [10.254.0.64] ([192.100.123.77]) by mx.google.com with ESMTPS id w31sm2152069wbd.15.2010.09.16.03.02.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Sep 2010 03:02:37 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <006a01cb5585$5e3f01f0$1abd05d0$%cui@huawei.com>
Date: Thu, 16 Sep 2010 13:02:43 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <728D15C8-21D4-40FD-A532-288AAC98C02E@gmail.com>
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> <006a01cb5585$5e3f01f0$1abd05d0$%cui@huawei.com>
To: Xiangsong Cui <Xiangsong.Cui@huawei.com>
X-Mailer: Apple Mail (2.1078)
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 10:02:21 -0000

Hi,

On Sep 16, 2010, at 12:56 PM, Xiangsong Cui wrote:

> 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".

Ok. Good.

> 
> 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.

I see your point. But for more detailed stuff we do actually point the reader to other documents.. to quite many actually.

- Jouni


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