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

Vijay Devarapalli <dvijay@gmail.com> Tue, 21 September 2010 21:57 UTC

Return-Path: <dvijay@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 91A0D3A69C5 for <netlmm@core3.amsl.com>; Tue, 21 Sep 2010 14:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.378
X-Spam-Level:
X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 TC0uRvRn8+o0 for <netlmm@core3.amsl.com>; Tue, 21 Sep 2010 14:56:57 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 4B1F93A68AE for <netlmm@ietf.org>; Tue, 21 Sep 2010 14:56:57 -0700 (PDT)
Received: by pvg7 with SMTP id 7so2342944pvg.31 for <netlmm@ietf.org>; Tue, 21 Sep 2010 14:57:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=mlFAnudq6oIHmB7bJd6VW5XWnKX89vIZUWZrYu6aQy0=; b=L1I2x4m9+SmZzrNi4qSQybFWC760dUe5WBhuqtLLAqlEZpV00MeMDtZpATIdLHLHwQ hiA32eOAGu42eKr3uiyuCtydbSH4FEWP98Pd8tEkfozndv6PVt1Lya8Gvu+qac1q8rif SsTDDIVKWw6Sfk9PcTTTxTQtXuwTos3JMq8Ag=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=KEq2t4JsJti1+q/wxG7xfl6fBMLc9DWcy272bBinRBN6p1B+c6q0YxC75Crd28otDu PxJwP5IgIFzkc7nO1ShT8Jj+b4mQRQjt+1D+wWdZbU/lQn6jjnAhpcfSmcQpdfM1SC0t LGJzLtzFq9R57Nv0Wz8FZe1afUNpumnSZfco8=
Received: by 10.114.25.5 with SMTP id 5mr12545876way.137.1285106242533; Tue, 21 Sep 2010 14:57:22 -0700 (PDT)
Received: from vijay-mac-2.local (adsl-99-96-187-86.dsl.pltn13.sbcglobal.net [99.96.187.86]) by mx.google.com with ESMTPS id d2sm16276360wam.14.2010.09.21.14.57.20 (version=SSLv3 cipher=RC4-MD5); Tue, 21 Sep 2010 14:57:21 -0700 (PDT)
Message-ID: <4C992A3F.2050509@gmail.com>
Date: Tue, 21 Sep 2010 14:57:19 -0700
From: Vijay Devarapalli <dvijay@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Xiangsong Cui <Xiangsong.Cui@huawei.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> <4C979C8A.7030000@gmail.com> <005d01cb5939$9ad13180$d0739480$%cui@huawei.com>
In-Reply-To: <005d01cb5939$9ad13180$d0739480$%cui@huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Tue, 21 Sep 2010 21:57:04 -0000

On 9/20/10 8:03 PM, Xiangsong Cui wrote:
> I don't think so.
> As I said in my earlier mail, I think there is some circulation on RFC5149
> reference.
>
> RFC5149 reads,
>     This document describes a Service Selection Mobility Option for
>     Mobile IPv6 that is intended to *assist home agents* to make specific
>     service selections for the mobility service subscription **during the
>     binding registration procedure.**
>
> I think this is clear enough, RFC5149 is "assist HA ... during registration
> procedure", right?
> While in this draft, we are talking about "assist LMA-discoverer to select a
> LMA, before registration procedure", right?

No. Read through the rest of the Introduction in RFC 5149. It 
specifically talks about distinguishing between multiple services that 
can be provided to a mobile node and how to identify the service that 
the mobile node wants to use when it sends a Binding Update to the home 
agent. (in PMIPv6, it would be the PBU from the MAG to the LMA).

Vijay

>
> How can we mix them together?
>
> Desired service may be used for purpose A, and may be used for purpose B,
> but this not means A and B *MUST* be free to be cross-referenced, imho.
> So I agree LMA-discovery refer on desired service, and I disagree
> LMA-discovery refer on RFC5149.
> And I am open for any clarification on desired service, if it is not clear.
>
> Xiangsong
>
>
>> -----Original Message-----
>> From: Vijay Devarapalli [mailto:dvijay@gmail.com]
>> Sent: Tuesday, September 21, 2010 1:40 AM
>> To: jouni korhonen
>> Cc: Xiangsong Cui; netlmm@ietf.org
>> Subject: Re: [netlmm] Some comments // RE: Fwd: New Version Notification
> for
>> draft-ietf-netlmm-lma-discovery-05
>>
>> On 9/16/10 2:44 AM, jouni korhonen wrote:
>>> 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.
>>
>> No, this is too vague. It is hard for someone not familiar with 3GPP to
>> figure out what it means to select LMA based on the services desired.
>> Service specific mobility anchor points are very 3GPP specific. So I
>> think we should have the reference to RFC 5149. That RFC clearly
>> explains what a "service" means in addition to defining a new mobility
>> option. I think you should put back this reference.
>>
>> Vijay
>