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

"Laganier, Julien" <julienl@qualcomm.com> Fri, 10 September 2010 22:20 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 0364C3A692B for <mipshop@core3.amsl.com>; Fri, 10 Sep 2010 15:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.552
X-Spam-Level:
X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 jOSmRFZV8Ja7 for <mipshop@core3.amsl.com>; Fri, 10 Sep 2010 15:20:30 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 628383A6834 for <mipshop@ietf.org>; Fri, 10 Sep 2010 15:20:30 -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=1284157257; x=1315693257; 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:=20Vijay=20Devarapalli=20<dvijay@gmail.com>,=20Jari =20Arkko=20<jari.arkko@piuha.net>|CC:=20Marco=20Liebsch =20<marco.liebsch@neclab.eu>,=20"BLUME,=20Oliver"=0D=0A =09<Oliver.Blume@alcatel-lucent.de>,=20"mipshop@ietf.org" =20<mipshop@ietf.org>|Date:=20Fri,=2010=20Sep=202010=2015 :20:55=20-0700|Subject:=20RE:=20Section=204.3.1=20of=20dr aft-ietf-mipshop-transient-bce-pmipv6|Thread-Topic:=20Sec tion=204.3.1=20of=20draft-ietf-mipshop-transient-bce-pmip v6|Thread-Index:=20ActRNIaZQzE7cJQMTiWFBytMO8o05gAAMnTg |Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1F6826E39 8@NALASEXMB04.na.qualcomm.com>|References:=20<4C8927B2.10 30000@gmail.com>=20<4C89EE49.4050004@neclab.eu>=0D=0A=20< 4C8A0FA7.7060308@piuha.net>=20<4C8AAC0C.5020204@gmail.com >|In-Reply-To:=20<4C8AAC0C.5020204@gmail.com> |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-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=4t6gUg6AAk1wjRpU05eifti7/YPEsQLl8VnL5ZckAfc=; b=ISR7NTA6me/eqRMRVyGEpxRzxm6uqDhc+hpI+kadHipsweMj2+ffMErr PGLRv0m2tCte4PWCC7vg9U9hRe4OHFIzf/9QnD+EkKoeZIB2T272pwpWb Pjwc95eOLSilZq3fCDKPqi/b1TAxht6mH5Lehr3M3o+cT1wJf6C7LJA2z s=;
X-IronPort-AV: E=McAfee;i="5400,1158,6102"; a="53956594"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 10 Sep 2010 15:20:57 -0700
X-IronPort-AV: E=Sophos;i="4.56,347,1280732400"; d="scan'208";a="2523094"
Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 10 Sep 2010 15:20:57 -0700
Received: from nasanexhc06.na.qualcomm.com (172.30.48.3) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 10 Sep 2010 15:20:57 -0700
Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhc06.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.0.694.0; Fri, 10 Sep 2010 15:20:56 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Fri, 10 Sep 2010 15:20:56 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Vijay Devarapalli <dvijay@gmail.com>, Jari Arkko <jari.arkko@piuha.net>
Date: Fri, 10 Sep 2010 15:20:55 -0700
Thread-Topic: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6
Thread-Index: ActRNIaZQzE7cJQMTiWFBytMO8o05gAAMnTg
Message-ID: <BF345F63074F8040B58C00A186FCA57F1F6826E398@NALASEXMB04.na.qualcomm.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>
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>, Marco Liebsch <marco.liebsch@neclab.eu>
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: Fri, 10 Sep 2010 22:20:32 -0000

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.

All of the NETLMM work has happened under the premise that the host is unmodified, and NETEXT has pushed this a bit further with only mandating that the IP stack is unmodified, e.g., quoting current NETEXT charter: 

  The work in this charter is entirely internal to the network and does
  not affect host IP stack operation in any way (except perhaps through
  impacting packet forwarding capacity visible to the hosts). The working
  group is not allowed to specify new IP layer protocol mechanisms to
  signal mobility related events between the host and the network.

We should adhere to the same guidelines in this situation. Thus the only way for the BCE to work in the dual radio case is to have a logical interface that hides to the IP layer the two physical interfaces, as described in this draft from the NETEXT WG:

http://tools.ietf.org/html/draft-ietf-netext-logical-interface-support

Thus we should add to the BCE draft a sentence that explains that for BCE to be beneficial in dual radio case it requires support for the logical interface, and reference the NETEXT draft.

--julien