Re: [netext] LMA initiated flow mobility scenario in I-D draft-bernardos-netext-pmipv6-flowmob

Julien Laganier <julien.ietf@gmail.com> Tue, 16 August 2011 15:26 UTC

Return-Path: <julien.ietf@gmail.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F9211E809F for <netext@ietfa.amsl.com>; Tue, 16 Aug 2011 08:26:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTDWbA-OrtTw for <netext@ietfa.amsl.com>; Tue, 16 Aug 2011 08:26:28 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6014C11E809B for <netext@ietf.org>; Tue, 16 Aug 2011 08:26:28 -0700 (PDT)
Received: by wyg8 with SMTP id 8so14430wyg.31 for <netext@ietf.org>; Tue, 16 Aug 2011 08:27:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=o3LqF9MEP+px4JKPPfOdN3YSEfWI7hGht/bINrbl+c8=; b=fwF8FZprMPNBw4My2tYixSd/wHXazAYdq6Fk7l/E2hKjjamkcLvDnAV7ZfLhSXZRNd qWXytE7BpU/l/v/2nNo9Q5DCQbmko/Zmp6waCFMlIC/FRw3T8jLRN1i1iUZJjvc7rqg+ mDDYPnxMk3t7Y/NnuzfICIbZOvNT9F2Mr4mo0=
MIME-Version: 1.0
Received: by 10.227.11.141 with SMTP id t13mr4602129wbt.36.1313508433874; Tue, 16 Aug 2011 08:27:13 -0700 (PDT)
Received: by 10.227.5.133 with HTTP; Tue, 16 Aug 2011 08:27:13 -0700 (PDT)
In-Reply-To: <CA6FF415.1D381%basavaraj.patil@nokia.com>
References: <CA6FF415.1D381%basavaraj.patil@nokia.com>
Date: Tue, 16 Aug 2011 08:27:13 -0700
Message-ID: <CAE_dhjuS_paehLNFe03rynGdnzeYARXEqACxzUCi4EhX79pQdQ@mail.gmail.com>
From: Julien Laganier <julien.ietf@gmail.com>
To: Basavaraj.Patil@nokia.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: netext@ietf.org
Subject: Re: [netext] LMA initiated flow mobility scenario in I-D draft-bernardos-netext-pmipv6-flowmob
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Tue, 16 Aug 2011 15:26:29 -0000

Hi Raj,

On Tue, Aug 16, 2011 at 8:16 AM,  <Basavaraj.Patil@nokia.com> wrote:
>
> Hello,
>
> One of the issues that has been raised (by Julien) is about the capability
> that allows an LMA to initiate flow switching.
> The I-D states:
> "
>   A second possible scenario is the following.  A multi-interfaced
>   mobile node is attached to a PMIPv6-Domain and the LMA, at a given
>   moment, decides to move a flow.  The LMA can decide to move a flow as
>   a result of a policy change or upon receiving a trigger either based
>   on network status or based on an event detected at the mobile node
>   and transported via old or new MAG.  How this decision is taken is
>   out of scope of this specification.
>
> "
>
> One of the possible consequences of such an action would be packets being
> sent into a void because the MN may be no longer attached to that MAG
> through the specific interface. There has not been a good solution that
> has been presented to the WG. This issue has been considered as being a
> fundamental flaw.
>
> In view of the criticality of this flaw, I would recommend that the LMA
> initiated flow mobility capability be removed from the I-D prior to it
> being accepted as the WG doc. If WG members feel strongly about having
> this feature, it can be included at a later time when a reasonable
> solution to address the above concern has been presented and accepted.

I support this approach.

Thanks,

--julien