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

"Laganier, Julien" <julienl@qualcomm.com> Mon, 13 September 2010 16:46 UTC

Return-Path: <julienl@qualcomm.com>
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 3559C3A69F3 for <mipshop@core3.amsl.com>; Mon, 13 Sep 2010 09:46:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.555
X-Spam-Level:
X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 AbIwwJVMCjCH for <mipshop@core3.amsl.com>; Mon, 13 Sep 2010 09:46:03 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id ACDD53A69A0 for <mipshop@ietf.org>; Mon, 13 Sep 2010 09:46:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1284396390; x=1315932390; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20Marco=20Liebsch=20<marco.liebsch@neclab.eu>,=20Vij ay=20Devarapalli=0D=0A=09<dvijay@gmail.com>|CC:=20"mipsho p@ietf.org"=20<mipshop@ietf.org>,=20"BLUME,=09Oliver"=0D =0A=09<Oliver.Blume@alcatel-lucent.de>|Date:=20Mon,=2013 =20Sep=202010=2009:46:26=20-0700|Subject:=20RE:=20[Mipsho p]=20Section=204.3.1=20of=0D=0A=09draft-ietf-mipshop-tran sient-bce-pmipv6|Thread-Topic:=20[Mipshop]=20Section=204. 3.1=20of=0D=0A=09draft-ietf-mipshop-transient-bce-pmipv6 |Thread-Index:=20ActTSlcBUOhdRdrITk2A7EsmDt6NMwAGHwtg |Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1F6826E3E 6@NALASEXMB04.na.qualcomm.com>|References:=20<4C8927B2.10 30000@gmail.com>=20<4C89EE49.4050004@neclab.eu>=0D=0A=09< 4C8A0FA7.7060308@piuha.net>=20<4C8AAC0C.5020204@gmail.com >=0D=0A=20<4C8E2B36.7050308@neclab.eu>|In-Reply-To:=20<4C 8E2B36.7050308@neclab.eu>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=AM+rPDpWi0uSOHnOYJZwG9bsEt/2amiMy4tLMZcNPAs=; b=sHmj8usawUH1vZJkaqvKv8vU5HxCt2UiGNeFQ5Oj0J9F1FDHR068q0eK B+lvvGq19DlNkXQtQ9OJB7vw2gPWDlvEhb5DeAUtQLN5iKOHvdg4pi/9p NnO+UzHb87VAPYh+77QYrT9puX3SK2qQ1kqMXrKJIMXRHqDX+AGqXsDDt 8=;
X-IronPort-AV: E=McAfee;i="5400,1158,6105"; a="54305351"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 13 Sep 2010 09:46:29 -0700
X-IronPort-AV: E=Sophos;i="4.56,357,1280732400"; d="scan'208";a="13315826"
Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 13 Sep 2010 09:46:29 -0700
Received: from nasanexhc06.na.qualcomm.com (172.30.48.3) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 13 Sep 2010 09:46:29 -0700
Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhc06.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.0.694.0; Mon, 13 Sep 2010 09:46:28 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Mon, 13 Sep 2010 09:46:28 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Marco Liebsch <marco.liebsch@neclab.eu>, Vijay Devarapalli <dvijay@gmail.com>
Date: Mon, 13 Sep 2010 09:46:26 -0700
Thread-Topic: [Mipshop] Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6
Thread-Index: ActTSlcBUOhdRdrITk2A7EsmDt6NMwAGHwtg
Message-ID: <BF345F63074F8040B58C00A186FCA57F1F6826E3E6@NALASEXMB04.na.qualcomm.com>
References: <4C8927B2.1030000@gmail.com> <4C89EE49.4050004@neclab.eu> <4C8A0FA7.7060308@piuha.net> <4C8AAC0C.5020204@gmail.com> <4C8E2B36.7050308@neclab.eu>
In-Reply-To: <4C8E2B36.7050308@neclab.eu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mipshop@ietf.org" <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 16:46:05 -0000

Hi Marco,

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

I suggest: 

"logical interface on top of physical radio interfaces [I-D. ietf-netext-logical-interface-support] 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.

--julien

> 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
> 
> _______________________________________________
> Mipshop mailing list
> Mipshop@ietf.org
> https://www.ietf.org/mailman/listinfo/mipshop