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

Jari Arkko <jari.arkko@piuha.net> Tue, 14 September 2010 10:25 UTC

Return-Path: <jari.arkko@piuha.net>
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 94AA63A6947 for <mipshop@core3.amsl.com>; Tue, 14 Sep 2010 03:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.421
X-Spam-Level:
X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 EqLZS0ctaF2g for <mipshop@core3.amsl.com>; Tue, 14 Sep 2010 03:25:56 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 0BE5E3A68D9 for <mipshop@ietf.org>; Tue, 14 Sep 2010 03:25:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 610A72CC4E; Tue, 14 Sep 2010 13:26:21 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crB1IMbzDYbH; Tue, 14 Sep 2010 13:26:20 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A47032CC30; Tue, 14 Sep 2010 13:26:20 +0300 (EEST)
Message-ID: <4C8F4DCC.6090809@piuha.net>
Date: Tue, 14 Sep 2010 13:26:20 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Marco Liebsch <marco.liebsch@neclab.eu>
References: <4C8927B2.1030000@gmail.com> <4C89EE49.4050004@neclab.eu> <4C8A0FA7.7060308@piuha.net> <4C8AAC0C.5020204@gmail.com> <4C8E2B36.7050308@neclab.eu> <4C8E9C38.2030408@gmail.com> <4C8F167C.9030806@piuha.net> <4C8F23F7.6020301@neclab.eu>
In-Reply-To: <4C8F23F7.6020301@neclab.eu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Tue, 14 Sep 2010 10:25:57 -0000

OK

Marco Liebsch kirjoitti:
>  Hi Jari,
>
> Am 14.09.2010 08:30, schrieb Jari Arkko:
>> Will the text that we added about the network only doing this if it 
>> knows that the mobile node is BCE-PMIP capable still stay?
>
> I guess you refer to the new text in 4.3.1, which came in since 
> version 7. Yes. I think it
> will stay and Vijay requested an addition section where to describe 
> *what* the
> MN actually needs to support to be tBCE capable.
>
> So, we keep the current text in 4.3.1 and refer to section 4.7 in this 
> context.
>
> Is that ok?
>
> marco
>
>
>>
>> Jari
>>
>> Vijay Devarapalli kirjoitti:
>>> On 9/13/10 6:46 AM, Marco Liebsch wrote:
>>>> 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].
>>>
>>> Replace the above with
>>>
>>>   For a single-radio handover, this specification does not require
>>>   any additional functionality on the mobile node, when compared to
>>>   [RFC 5213].
>>>
>>>> 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.
>>>
>>> Looks ok. BTW, I think its ok to include the reference to the NETEXT 
>>> draft for the virtual interface (see Julien's email).
>>>
>>> Vijay
>>>
>>>>
>>>>
>>>> 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
>>>>
>>>
>>>
>>
>
>