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

<Basavaraj.Patil@nokia.com> Tue, 16 August 2011 15:16 UTC

Return-Path: <Basavaraj.Patil@nokia.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7BBC721F8BB7 for <netext@ietfa.amsl.com>; Tue, 16 Aug 2011 08:16:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.525
X-Spam-Status: No, score=-101.525 tagged_above=-999 required=5 tests=[AWL=-1.226, BAYES_00=-2.599, MANGLED_AVOID=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3NrcgYDrVVRR for <netext@ietfa.amsl.com>; Tue, 16 Aug 2011 08:16:42 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3BFCD11E8085 for <netext@ietf.org>; Tue, 16 Aug 2011 08:16:40 -0700 (PDT)
Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com []) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7GFH9ml003347 for <netext@ietf.org>; Tue, 16 Aug 2011 18:17:28 +0300
Received: from smtp.mgd.nokia.com ([]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Aug 2011 18:16:56 +0300
Received: from 008-AM1MMR1-003.mgdnok.nokia.com ( by NOK-AM1MHUB-03.mgdnok.nokia.com ( with Microsoft SMTP Server (TLS) id; Tue, 16 Aug 2011 17:16:56 +0200
Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([]) by 008-AM1MMR1-003.mgdnok.nokia.com ([]) with mapi id 14.01.0323.002; Tue, 16 Aug 2011 17:16:56 +0200
From: <Basavaraj.Patil@nokia.com>
To: <netext@ietf.org>
Thread-Topic: LMA initiated flow mobility scenario in I-D draft-bernardos-netext-pmipv6-flowmob
Thread-Index: AQHMXCeI4KodSZYTPEqA8A8VWvP+JA==
Date: Tue, 16 Aug 2011 15:16:55 +0000
Message-ID: <CA6FF415.1D381%basavaraj.patil@nokia.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C839288ECE88C44EA139B8AA3EED1A45@nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Aug 2011 15:16:56.0695 (UTC) FILETIME=[897B7070:01CC5C27]
X-Nokia-AV: Clean
Subject: [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:16:42 -0000


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.