Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13

Ryuji Wakikawa <ryuji.wakikawa@gmail.com> Mon, 18 May 2009 17:13 UTC

Return-Path: <ryuji.wakikawa@gmail.com>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D497E3A6E4A for <mext@core3.amsl.com>; Mon, 18 May 2009 10:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 1u7C8YMIdm9C for <mext@core3.amsl.com>; Mon, 18 May 2009 10:13:29 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id E69503A6DB6 for <mext@ietf.org>; Mon, 18 May 2009 10:13:28 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id g37so1434053rvb.49 for <mext@ietf.org>; Mon, 18 May 2009 10:15:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=Y0kJn0aFs+OTlN2cOOR0un63AOv7vWHiDVZ36Olqmzk=; b=N3DMtK7J+/2BDNiuh1TQZ3w4mnryHZulLZl4bZ4QU+tVTwgX2OjnyzMsPLp8vTSB/c J7aUg8BnuddqFqL/IJklSMIEAzcMqiDQT0GUQAhoRVo1b3UB9TFL087d8MTDnvgNLwES PirxfflT11w5m4JUNeDsC/B3TxaCG1LFL0XBU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=kG2Pt2YTVPPo7JCe3EDxc4IUv4rBbqCQ6pR1z8LZniV3xT3caLYtgXglw+1Y0fjjTk RBb0SD5WmS0p29592NLKVX7UUKe/7JUQq8k0t/IaG7NJsFeasNv/XEpSlkJowA6tlf7P JYThHU0L9NU0szxtEZf13nHPJt/F7jPKSWOwA=
Received: by 10.141.168.16 with SMTP id v16mr2396200rvo.233.1242666903270; Mon, 18 May 2009 10:15:03 -0700 (PDT)
Received: from ?192.168.110.115? ([206.132.173.18]) by mx.google.com with ESMTPS id f42sm13788739rvb.31.2009.05.18.10.15.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 10:15:01 -0700 (PDT)
From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
To: Romain KUNTZ <kuntz@lsiit.u-strasbg.fr>
In-Reply-To: <F97A75CE-228C-48BF-98F4-1F3E82978421@lsiit.u-strasbg.fr>
References: <14008519-2F77-45BC-B9F4-AA449A1627B5@lsiit.u-strasbg.fr> <20149D5A-EAFA-459B-A76E-5190856FD4B6@gmail.com> <F97A75CE-228C-48BF-98F4-1F3E82978421@lsiit.u-strasbg.fr>
Message-Id: <8E4F20F0-4D14-4B27-A615-1E067A2A0809@gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Mon, 18 May 2009 10:14:58 -0700
X-Mailer: Apple Mail (2.935.3)
Cc: mext <mext@ietf.org>
Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 May 2009 17:13:35 -0000

Hi Romain,

On 2009/05/12, at 14:08, Romain KUNTZ wrote:

> Hi Ryuji,
>
> On 2009/05/11, at 22:59, Ryuji Wakikawa wrote:
>>> First, I'd like to express that I support Arnaud's opinion about  
>>> section 5.6 (Simultaneous Home and Visited Link Operation). I also  
>>> don't see what is the motivation to re-route and tunnel traffic  
>>> from the HA to one of the MN's CoA, while the MN is only one hop  
>>> from the HA. Even if there is a specific use-case, at the time  
>>> this topology was suggested, a simple solution that came out was  
>>> to configure a CoA on the Home link and use a tunnel via the home  
>>> link. I don't think the little overhead of this solution justifies  
>>> the complexity of the one proposed in the draft.
>>
>> This was discussed at WG. We agreed to have this feature at the end.
>> I understand the complexity, but this is how WG agreed.
>>
>> It is not possible to change the consensus at this moment. We  
>> passed all last call.
>
> Ok, this has also been extensively discussed in another thread -  
> I'll follow the WG agreement then.
>
>>> Two other minor comments on the draft below:
>>>
>>> - Section 6.2 (Processing Binding Update)
>>>
>>>    *  If the 'O' flag is set in the Binding Update, the home agent
>>>       removes all the existing bindings and registers the received
>>>       binding(s).
>>>
>>> It is not explicitly said that the MN can use the O flag with a  
>>> CN. I think nothing prevents the MN to use it, so we should  
>>> replace "home agent" with "receiving node".
>
> You didn't ack the above comment, did you skip it by mistake?

I've already replaced it :-)

thanks!
ryuji


>
>
>
>>> If all the above operations are successfully completed, a Binding
>>> Acknowledgement containing the Binding Identifier mobility options
>>> MUST be sent to the mobile node.
>>>
>>> The BAck must be sent only if the 'A' flag was set in the BU,  
>>> right? or does the MCoA spec mandates sending BAck in all cases?
>>
>> BA is sent only A flag is set.
>> I will update this to
>>
>>> If all the above operations are successfully completed, a Binding
>>> Acknowledgement containing the Binding Identifier mobility options
>>> MUST be sent to the mobile node if  'A' flag is set in the  
>>> received Binding Update.
>>
>> Please let me know if you have further comments on this.
>
> Looks fine with me!
>
> Thanks,
> romain
>