Re: [netext] Update on flow mobility following discussion with ADs
<Basavaraj.Patil@nokia.com> Wed, 02 March 2011 20:31 UTC
Return-Path: <Basavaraj.Patil@nokia.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 598983A6869 for <netext@core3.amsl.com>; Wed, 2 Mar 2011 12:31:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.391
X-Spam-Level:
X-Spam-Status: No, score=-101.391 tagged_above=-999 required=5 tests=[AWL=-1.093, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_LOW=-1, 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 yzdGnJXzspSx for <netext@core3.amsl.com>; Wed, 2 Mar 2011 12:31:16 -0800 (PST)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id E4C433A6823 for <netext@ietf.org>; Wed, 2 Mar 2011 12:31:12 -0800 (PST)
Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p22KVO4U025303; Wed, 2 Mar 2011 22:32:16 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 22:32:04 +0200
Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 2 Mar 2011 21:32:03 +0100
Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Wed, 2 Mar 2011 21:32:03 +0100
From: Basavaraj.Patil@nokia.com
To: sfaccin@rim.com, netext@ietf.org
Thread-Topic: [netext] Update on flow mobility following discussion with ADs
Thread-Index: AcvYfuevlCz6SlKTRRGiPCBHi+KqagAjGQMQ//+lzYA=
Date: Wed, 02 Mar 2011 20:32:02 +0000
Message-ID: <C9940198.116F1%basavaraj.patil@nokia.com>
In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC06325163@XCH02DFW.rim.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.0.101115
x-originating-ip: [172.19.59.44]
Content-Type: multipart/related; boundary="_005_C9940198116F1basavarajpatilnokiacom_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginalArrivalTime: 02 Mar 2011 20:32:04.0394 (UTC) FILETIME=[E45D18A0:01CBD918]
X-Nokia-AV: Clean
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: Wed, 02 Mar 2011 20:31:20 -0000
Hi Stefano, Inline below: From: ext Stefano Faccin <sfaccin@rim.com<mailto:sfaccin@rim.com>> Date: Wed, 2 Mar 2011 13:51:25 -0600 To: Patil Basavaraj <basavaraj.patil@nokia.com<mailto:basavaraj.patil@nokia.com>>, Netext <netext@ietf.org<mailto:netext@ietf.org>> Subject: RE: [netext] Update on flow mobility following discussion with ADs Raj, Thanks for the notes. There is one aspect that concerns me, and is related to : “2. There is no plan or expectation that there would be a way for the MN/host to do signaling related to flow mobility with a MAG at layer 3. Layer 2 is an option but obviously this requires such enhancements to be done in other SDOs. The preference is to develop a flow mobility solution that works with policies and signaling that is network centric (i.e MAG/LMA entities). ” Personally I am concerned about this. What is the usefulness in netext providing an “alternative” IP flow mobility solution that provides only a subset of the functionality of a host-based solution. Deployments of such so called alternative would provide a limited services with respect to deployments of the host-based solution. Why would anybody want to step back in time? Raj> I would not consider PMIP6 based flow mobility as an alternative to the host based solution that is specified in RFCs 6088/9. The type of mobility capability in a deployment can vary. The PMIP6 based flow mobility would be applicable in deployments which leverage network based mobility. Whether the functionality provided by this capability is sufficient, is a conscientious decision that will be made by the operator. It is a matter of choice and what I am saying is that the scope of this work is NOT intended to provide the same set of capabilities that exist in the host based flow mobility solution. As for: “The preference is to develop a flow mobility solution that works with policies and signaling that is network centric (i.e MAG/LMA entities). ” I can understand the point, but I have a question. As an example, 3GPP (that can be one of the potential customers and that we can surely not disregard) has been very keen in indicating that the user (whether it be the actual human being using the MN or e.g. the enterprise owning the MN) has priority wrt the policies defined by the operator. This is because in several scenarios the user may have preference for certain accesses (e.g. the enterprise WiFi) that are not provided by the operator for certain services (e.g. access to the enterprise resources). In such case, 3GPP has recognized the need to allow the user to have precedence. If the solution designed by netext is based solely on network policies and decisions, I am afraid we would have a solution that does not allow valid scenarios that have been identified by one of the potential customers for the solution. Raj> A network centric flow-mobility solution may not be able to address all the scenarios that 3GPP is considering. But a subset of those may be dealt with via this feature. As long as the document is clear about what is in scope and possibly documenting some of the limitations as well, it would be useful to specify it. There could be other types of networks that could use such a solution as well. -Raj Cheers, Stefano Faccin Standards Manager Research In Motion Corporation 5000 Riverside Drive Building 6, Brazos East, Ste. 100 Irving, Texas 75039 USA Office: (972) 910 3451 Internal: 820.63451 [Untitled-1]: (510) 230 8422 www.rim.com<outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.rim.com>; www.blackberry.com<outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.com> [cid:image004.png@01CB49EA.87D92140]<http://www.blackberry.com/> P Consider the environment before printing. From: netext-bounces@ietf.org<mailto:netext-bounces@ietf.org> [mailto:netext-bounces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com<mailto:Basavaraj.Patil@nokia.com> Sent: Wednesday, March 02, 2011 9:04 AM To: netext@ietf.org<mailto:netext@ietf.org> Subject: [netext] Update on flow mobility following discussion with ADs Just wanted to provide an update regarding the ongoing work on flow mobility for PMIP6 and my discussion with our ADs (Jari and Ralph) on March 1st: I have apprised our ADs about the state of the ongoing discussion on flow mobility. One of the concerns about the ongoing work on flow mobility was related to the logical interface feature. Flow mobility depends on the existence of a logical interface on the host. The WG has not addressed the concerns related to the logical interface I-D, that were raised at the previous WG meetings. Emphasised that we should get the logical interface spec done soon since it is a fundamental dependency for flow mobility. Regarding the current scope of the flow mobility work and the I-D which is now in consensus call, there are a few issues that need to be resolved. A few points below: 1. Flow mobility in the context of Proxy MIP6 is not analogous to the solution that has been developed for host based MIP6. The featureset and capabilities developed in Netext does not have to mirror, parallel or be equivalent to that of RFCs 6088/9. 2. There is no plan or expectation that there would be a way for the MN/host to do signaling related to flow mobility with a MAG at layer 3. Layer 2 is an option but obviously this requires such enhancements to be done in other SDOs. The preference is to develop a flow mobility solution that works with policies and signaling that is network centric (i.e MAG/LMA entities). 3. One of the major concerns raised on the mailing list is related to how flow mobility would work when an MN attaches to a wifi access and the LMA switches a flow(s) to the MAG serving the MN via that wifi. The MN has no way of indicating to the LMA if the wifi access is congested or for the MAG to indicate to the LMA about the state of the MNs attachment to the AP. Packets forwarded by the LMA to the MN via the wifi-MAG could be sent into a void. Without a solution for the above scenario, flow mobility would not be robust. Some clear answers are needed here. One option is that flow mobility for PMIP6 is applicable only in those access networks wherein the access network elements are aware of the state of the MNs connection and congestion state. The MAG can use this information to signal to an LMA attachment state and potentially cause flows to be switched to an alternative MAG. It may be okay to have specific statements about the limitations of flow mobility for PMIP6 documented as a sort of disclaimer. Other options? 4. The WG is free to extend the PMIP6 signaling between MAG/LMA to accomplish flow mobility. 5. And lastly the question about who is the customer for this work at this time is irrelevant. We have had this discussion during the chartering phase and there is no reason to revisit it. If I have missed any other significant (show-stopper) concern regarding the flow mobility feature, please do raise them. -Raj --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
- [netext] Update on flow mobility following discus… Basavaraj.Patil
- Re: [netext] Update on flow mobility following di… Sri Gundavelli
- Re: [netext] Update on flow mobility following di… Basavaraj.Patil
- Re: [netext] Update on flow mobility following di… Jari Arkko
- Re: [netext] Update on flow mobility following di… Stefano Faccin
- Re: [netext] Update on flow mobility following di… Sri Gundavelli
- Re: [netext] Update on flow mobility following di… Basavaraj.Patil
- Re: [netext] Update on flow mobility following di… Rajeev Koodli
- Re: [netext] Update on flow mobility following di… Julien Laganier
- Re: [netext] Update on flow mobility following di… Rajeev Koodli
- Re: [netext] Update on flow mobility following di… Julien Laganier
- Re: [netext] Update on flow mobility following di… Zuniga, Juan Carlos
- Re: [netext] Update on flow mobility following di… Julien Laganier