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

Marco Liebsch <marco.liebsch@neclab.eu> Mon, 13 September 2010 13:47 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 5D5A53A69E4 for <mipshop@core3.amsl.com>; Mon, 13 Sep 2010 06:47:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.07
X-Spam-Level:
X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HELO_EQ_DE=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 MG8eEV2YDxWF for <mipshop@core3.amsl.com>; Mon, 13 Sep 2010 06:47:51 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 4ABE33A69E3 for <mipshop@ietf.org>; Mon, 13 Sep 2010 06:47:51 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 05AD52800017F; Mon, 13 Sep 2010 15:48:17 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZ-aien3qX0Q; Mon, 13 Sep 2010 15:48:16 +0200 (CEST)
Received: from ENCELADUS.office.hd (Enceladus.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id D7C5F2800017D; Mon, 13 Sep 2010 15:47:51 +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 15:46:45 +0200
Message-ID: <4C8E2B36.7050308@neclab.eu>
Date: Mon, 13 Sep 2010 15:46:30 +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 13:47:56 -0000

Hi Vijay,

please find some text for a revived section 4.7 MN Operation below.
Text in section 4.3.1 could then refer to this new section 4.7 to
link context.

4.7.  MN operation

  For single-radio handover, this specification does not require any
  extended mode of operation on the MN when compared to [RFC5213].

  During dual-radio handover, the MN benefits most from the transient
  BCE extension to PMIPv6 when it is able to keep communication on the
  previous interface while it is setting up its handover target
  interface with the configuration context which has been received as a
  result of the new interface's attachment to the nMAG.  Various
  techniques enable support for such operation, e.g. the use of a
  virtual interface on top of physical radio interfaces or
  implementation specific extensions to the MN's protocol stack.
  Details about how to enable such make-before-break support on the MN
  are out of scope of this document.


marco


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