Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments

Benjamin Lim <benjamin.limck@sg.panasonic.com> Fri, 12 December 2008 03:01 UTC

Return-Path: <mext-bounces@ietf.org>
X-Original-To: monami6-archive@megatron.ietf.org
Delivered-To: ietfarch-monami6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5C73A67B5; Thu, 11 Dec 2008 19:01:12 -0800 (PST)
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 4D6003A67B5 for <mext@core3.amsl.com>; Thu, 11 Dec 2008 19:01:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.757
X-Spam-Level:
X-Spam-Status: No, score=-0.757 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
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 8zNn3waK9lNA for <mext@core3.amsl.com>; Thu, 11 Dec 2008 19:01:10 -0800 (PST)
Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 5F8CE3A6774 for <mext@ietf.org>; Thu, 11 Dec 2008 19:01:10 -0800 (PST)
Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id mBC312qj029963; Fri, 12 Dec 2008 12:01:02 +0900 (JST)
Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id mBC312003361; Fri, 12 Dec 2008 12:01:02 +0900 (JST)
Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili06) with ESMTP id mBC312p19126; Fri, 12 Dec 2008 12:01:02 +0900 (JST)
Received: from [127.0.0.1] ([10.81.113.115]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 11:00:40 +0800
Message-ID: <4941D3D1.10307@sg.panasonic.com>
Date: Fri, 12 Dec 2008 11:00:33 +0800
From: Benjamin Lim <benjamin.limck@sg.panasonic.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Christian.Kaas-Petersen@tieto.com
References: <D3CFEF84287B46408A7F0405EE7C545701969E24@corvette.eu.tieto.com>
In-Reply-To: <D3CFEF84287B46408A7F0405EE7C545701969E24@corvette.eu.tieto.com>
X-Enigmail-Version: 0.95.7
X-OriginalArrivalTime: 12 Dec 2008 03:00:40.0165 (UTC) FILETIME=[D0A22950:01C95C05]
Cc: mext@ietf.org
Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments
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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

Hi Christian,

Comment to one of your question.

Christian.Kaas-Petersen@tieto.com wrote:
> Draft 10, section 4.2 (and other places) defines the H flag, which when
> set means the mobile node wants to use both its home link and one or
> more of its foreign links.  The H flag is really an instruction to the
> home agent, that in addition to all the bidings currently defined
> is shall have an extra binding where packets shall not be tunneled.  
> 
> Proposal:  The mobile node should be able to define a binding saying
> 
>     HoA BID=0 HoA
> 
> This is a kind of default binding to be used when any of the other HoA-
> bindings cannot be used.  I think the H flag is an indirect way of
> saying there is an extra binding, whereas the binding above is direct.
> It also avoids continuously setting the H flag when both home link
> and foreign links are active.
[Ben] I cannot understand the reasoning for this.  Does not the use of
the H flag can achieve the same purpose as the 'default' binding as you
mention?  Is there some issue for the H flag to require this change you
are proposing?  Also, note that this draft underwent one IESG review and
changing a working mechanism now does not seem to garden any logic.

Regards,
Benjamin Lim


_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext