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 >>>>> >>> >
- [netlmm] Fwd: New Version Notification for draft-… jouni korhonen
- [netlmm] Some comments // RE: Fwd: New Version No… Xiangsong Cui
- Re: [netlmm] Some comments // RE: Fwd: New Versio… jouni korhonen
- Re: [netlmm] Some comments // RE: Fwd: New Versio… Xiangsong Cui
- Re: [netlmm] Some comments // RE: Fwd: New Versio… jouni korhonen
- Re: [netlmm] Some comments // RE: Fwd: New Versio… Xiangsong Cui
- Re: [netlmm] Some comments // RE: Fwd: New Versio… jouni korhonen
- Re: [netlmm] Some comments // RE: Fwd: New Versio… Vijay Devarapalli
- Re: [netlmm] Some comments // RE: Fwd: New Versio… Xiangsong Cui
- Re: [netlmm] Some comments // RE: Fwd: New Versio… Vijay Devarapalli
- Re: [netlmm] Some comments // RE: Fwd: New Versio… Narayanan, Vidya
- Re: [netlmm] Some comments // RE: Fwd: New Versio… Jari Arkko
- Re: [netlmm] Some comments // RE: Fwd: New Versio… Narayanan, Vidya