Re: [netext] Update on flow mobility following discussion with ADs

Rajeev Koodli <rkoodli@cisco.com> Fri, 04 March 2011 05:38 UTC

Return-Path: <rkoodli@cisco.com>
X-Original-To: netext@core3.amsl.com
Delivered-To: netext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39B823A692B for <netext@core3.amsl.com>; Thu, 3 Mar 2011 21:38:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.077
X-Spam-Level:
X-Spam-Status: No, score=-110.077 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 qalzHb+1vfIO for <netext@core3.amsl.com>; Thu, 3 Mar 2011 21:38:19 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id AC58C3A693C for <netext@ietf.org>; Thu, 3 Mar 2011 21:38:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rkoodli@cisco.com; l=3074; q=dns/txt; s=iport; t=1299217168; x=1300426768; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=3EXSDVH2vrpqaeJZ0wyFS2K9vouY/mKaErMKfHs9gXY=; b=SYPsAVo15BSCTkos0mCER5PXaJ7OOuQttEK1Lir7VNXDG1bqtjqNROER 6RC2t6ojtyWXNhNv9YuFluXfEccFa+8G5CMD7YgazaIdXa5/5qHXRtcqg 00erIYssEwdz2/KDy4LEnvvBPhtmT7iJNQgHJNfR4vdJsFO6tHGYb0AXC c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAP4JcE2tJXHA/2dsb2JhbACmb3SiYpwMhWEEhRyHE4NJgxQ
X-IronPort-AV: E=Sophos;i="4.62,262,1297036800"; d="scan'208";a="222493322"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-2.cisco.com with ESMTP; 04 Mar 2011 05:39:27 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p245dR47024116; Fri, 4 Mar 2011 05:39:27 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 23:39:27 -0600
Received: from 10.21.144.204 ([10.21.144.204]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Mar 2011 05:39:27 +0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Thu, 03 Mar 2011 21:40:19 -0800
From: Rajeev Koodli <rkoodli@cisco.com>
To: Julien Laganier <julien.ietf@gmail.com>
Message-ID: <C995BB43.E160%rkoodli@cisco.com>
Thread-Topic: [netext] Update on flow mobility following discussion with ADs
Thread-Index: AcvaLqV910UT+qCsj0eeBVZTVPFoDQ==
In-Reply-To: <AANLkTim25tLfusBFkY35AFi_7fXucQ4etjKxj4y-KLEf@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 04 Mar 2011 05:39:27.0533 (UTC) FILETIME=[86D025D0:01CBDA2E]
Cc: netext@ietf.org, Basavaraj.Patil@nokia.com
Subject: Re: [netext] Update on flow mobility following discussion with ADs
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2011 05:38:21 -0000

Hi Julien,

I don't believe I suggested sacrificing correctness and robustness; in fact,
I suggested robustness of protocol operation to cover all cases.

More to the point, I think relying _only_ on extended L2 signaling is one of
the cases the protocol needs to cover. We need to include the case when
either new L2 signaling is unavailable or is not considered reliable.

I am proposing an inclusive approach for providing flow mobility when the
desired aspects of L2 signaling are available (HI=Flow Mobility) _and_
consider the case when we they are not available (HI=Unknown). I should be
able to move flows across interfaces regardless of whether the LMA maintains
a single session or multiple sessions (all created according to the baseline
PMIP6 model).

Making use of 3GPP as a customer is great, but I do not want to be limited
only to it.

Thanks,

-Rajeev



On 3/3/11 11:44 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote:

> Hi Rajeev,
> 
> On Wed, Mar 2, 2011 at 12:39 PM, Rajeev Koodli <rkoodli@cisco.com> wrote:
>> 
>> 
>> On 3/2/11 11:49 AM, "Jari Arkko" <jari.arkko@piuha.net> wrote:
>> 
>>> Sri:
>>> 
>>> What Basavaraj said. I don't think the number of specifications is a big
>>> concern either now or later. Split the documents the way you like. Lets
>>> discuss functionality, robustness, assumptions instead -- those are
>>> important.
>> 
>> 
>> I agree that the spec should be robust, and should work under conditions
>> assuming existing & new L2 signaling, as well as under conditions when new
>> L2 signaling is unavailable.
> 
> I have expressed doubts about the feasibility of a robust flow
> mobility / inter-access handover solution that relies on existing,
> unmodified L2 signaling (this is discussed in a different thread.) We
> should not sacrifice correctness and robustness for the sake of
> working around unmodified L2 signaling. As I've said earlier, one of
> the potential customer for this (3GPP) owns two L2 that are used to
> access their system (PMIP based S5 for 3GPP accesses, and PMIP based
> S2b for no-3GPP accesses.)
> 
>> It's a question of whether we agree that LMA-MAG signaling could also be
>> used in addition to relying only on L2 signaling for flow mobility.
> 
> At this stage the question is rather, is it possible to provide a
> correct and robust system without modified L2 signaling. If it is,
> then we can go ahead with the question you laid above. Would you
> agree?
> 
>>> (And of course, splitting to different specifications should not be
>>> misused to hide a technical omission or a problem.)
>> 
>> I would focus on getting a protocol that works under different cases and not
>> just under continued reliance on (existing and new) L2 signaling. (I am not
>> referring to new IP signaling between MN and MAG).
> 
> See above. The focus you propose is only appropriate insofar we've
> come up with a positive answer to the question I asked above, and that
> we' re discussing with Carlos, Hesham, et al.
> 
> --julien