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

Romain KUNTZ <kuntz@lsiit.u-strasbg.fr> Tue, 12 May 2009 21:08 UTC

Return-Path: <kuntz@lsiit.u-strasbg.fr>
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 7A7C128C189 for <mext@core3.amsl.com>; Tue, 12 May 2009 14:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.063
X-Spam-Level:
X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 voRB6MFpzVT3 for <mext@core3.amsl.com>; Tue, 12 May 2009 14:08:21 -0700 (PDT)
Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.156]) by core3.amsl.com (Postfix) with ESMTP id 5B0B73A67A3 for <mext@ietf.org>; Tue, 12 May 2009 14:08:21 -0700 (PDT)
Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n4CL8ZcH044762 ; Tue, 12 May 2009 23:08:35 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id F01F1BEAFB6; Tue, 12 May 2009 23:08:35 +0200 (CEST)
Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq5uO9qubniG; Tue, 12 May 2009 23:08:35 +0200 (CEST)
Received: from [192.168.0.10] (bro67-5-88-177-196-175.fbx.proxad.net [88.177.196.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kuntz) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 4D4FDBEAFA7; Tue, 12 May 2009 23:08:35 +0200 (CEST)
Message-Id: <F97A75CE-228C-48BF-98F4-1F3E82978421@lsiit.u-strasbg.fr>
From: Romain KUNTZ <kuntz@lsiit.u-strasbg.fr>
To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
In-Reply-To: <20149D5A-EAFA-459B-A76E-5190856FD4B6@gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Tue, 12 May 2009 23:08:35 +0200
References: <14008519-2F77-45BC-B9F4-AA449A1627B5@lsiit.u-strasbg.fr> <20149D5A-EAFA-459B-A76E-5190856FD4B6@gmail.com>
X-Mailer: Apple Mail (2.930.3)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mailhost.u-strasbg.fr [130.79.200.156]); Tue, 12 May 2009 23:08:36 +0200 (CEST)
X-Virus-Scanned: ClamAV 0.94.2/9355/Tue May 12 19:42:46 2009 on mr6.u-strasbg.fr
X-Virus-Status: Clean
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: Tue, 12 May 2009 21:08:22 -0000

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?


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