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

Vijay Devarapalli <dvijay@gmail.com> Fri, 10 September 2010 22:06 UTC

Return-Path: <dvijay@gmail.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 189B13A6B4F for <mipshop@core3.amsl.com>; Fri, 10 Sep 2010 15:06:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 IRmfbGQ-9XFp for <mipshop@core3.amsl.com>; Fri, 10 Sep 2010 15:06:45 -0700 (PDT)
Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 349A13A6B4D for <mipshop@ietf.org>; Fri, 10 Sep 2010 15:06:45 -0700 (PDT)
Received: by pxi6 with SMTP id 6so1474543pxi.31 for <mipshop@ietf.org>; Fri, 10 Sep 2010 15:07:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=qtp1Yq1D9irUySffXacY+vmxB5KNevDQa4mqSXZChhk=; b=IwG6lfQ5MxG8kGfcNsmCn4zCuYp9T8AuE/ipMK49va4b89LBqi3Vz7CEDkk0XpEJfd BZIhxj/HQ+Nm99JK+IVIHLz2YR5baW5XNx80o1L0dru4KkydHj62FHlvi9OQ09a3IgXM gF2R36+t4x2LFbNlOBohMOBXJBvproJ7bUEB8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=LyDWylpLmjGGWg62KbFkqq+FkQyBZGMd7X9MDuFzn+QLuVUd+rKAnLUj/6ZW+an4na o4+wxT5pWYv0tt4PJ5HAl5Ap+hjrMIN+ZXG2LC73tdlbUrHzc+KNSs+NqiEq5uHnVXJR VZclUg4c8+zo7++BeHp7JN9DFvSO6YFJv6SnI=
Received: by 10.114.15.5 with SMTP id 5mr1534822wao.200.1284156432295; Fri, 10 Sep 2010 15:07:12 -0700 (PDT)
Received: from vijay-mac-2.local (adsl-99-96-187-86.dsl.pltn13.sbcglobal.net [99.96.187.86]) by mx.google.com with ESMTPS id s5sm5315895wak.12.2010.09.10.15.07.10 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Sep 2010 15:07:10 -0700 (PDT)
Message-ID: <4C8AAC0C.5020204@gmail.com>
Date: Fri, 10 Sep 2010 15:07:08 -0700
From: Vijay Devarapalli <dvijay@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
References: <4C8927B2.1030000@gmail.com> <4C89EE49.4050004@neclab.eu> <4C8A0FA7.7060308@piuha.net>
In-Reply-To: <4C8A0FA7.7060308@piuha.net>
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>, 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:06:46 -0000

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