Re: [Mipshop] Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Marco Liebsch <marco.liebsch@neclab.eu> Mon, 13 September 2010 10:10 UTC

Return-Path: <Marco.Liebsch@neclab.eu>
X-Original-To: mipshop@core3.amsl.com
Delivered-To: mipshop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19963A696A for <mipshop@core3.amsl.com>; Mon, 13 Sep 2010 03:10:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.544
X-Spam-Level:
X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_05=-1.11]
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 fEHpJOUy233W for <mipshop@core3.amsl.com>; Mon, 13 Sep 2010 03:10:25 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 4BA083A696B for <mipshop@ietf.org>; Mon, 13 Sep 2010 03:10:23 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 6A98B2C0001B6; Mon, 13 Sep 2010 12:10:38 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vmf2VyE7KCkv; Mon, 13 Sep 2010 12:10:38 +0200 (CEST)
Received: from ENCELADUS.office.hd (Enceladus.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 4EFCF2C0001B0; Mon, 13 Sep 2010 12:10:13 +0200 (CEST)
Received: from [10.1.6.34] (10.1.6.34) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 13 Sep 2010 12:09:07 +0200
Message-ID: <4C8DF834.1050402@neclab.eu>
Date: Mon, 13 Sep 2010 12:08:52 +0200
From: Marco Liebsch <marco.liebsch@neclab.eu>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: Vijay Devarapalli <dvijay@gmail.com>
References: <4C8927B2.1030000@gmail.com> <4C89EE49.4050004@neclab.eu> <4C8A0FA7.7060308@piuha.net> <4C8AAC0C.5020204@gmail.com>
In-Reply-To: <4C8AAC0C.5020204@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.6.34]
Cc: "Laganier, Julien" <julienl@qualcomm.com>, mipshop@ietf.org, "BLUME, Oliver" <Oliver.Blume@alcatel-lucent.de>
Subject: Re: [Mipshop] Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6
X-BeenThere: mipshop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <mipshop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mipshop>
List-Post: <mailto:mipshop@ietf.org>
List-Help: <mailto:mipshop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2010 10:10:26 -0000

Hi Vijay,

Vijay Devarapalli wrote:
> On 9/10/10 3:59 AM, Jari Arkko wrote:
>> Is some document change needed?
>
> Yes, IMO. Section 4.3.1 talks about the nMAG creating a transient BCE 
> only if it knows the MN supports transient BCE. Two issues with this.
>
> 1. If its a single radio handover, nothing needs to be supported on 
> the MN. Just whatever is needed according to RFC 5213.
>
> 2. For a dual radio handover, to get the true benefit from transient 
> BCE, the MN needs to be able to receive packets on two interfaces at 
> the same time for a short while. If it does not do this, transient BCE 
> would still work, and the MN does benefit, but there will be some 
> packet loss.
>
> This is not really captured in the draft.
>
> For the actual text changes, it is going to be hard for me to suggest 
> text changes since its been a year since I read the draft. I have to 
> go through it again. Marco would probably be able to come up with text 
> changes much more quickly.
We had a section on MN operation in until version 03, but removed it 
according to a proposal.
I am ok with including such section again and will propose text.

Thanks,
marco

>
> Perhaps we should add a section on the mobile node support for 
> transient BCE and explain clearly what needs to be supported on the 
> mobile node.
>
> Vijay