Re: [mif] Follow up with BBF proposal

"Hui Deng" <denghui@chinamobile.com> Tue, 11 November 2014 02:35 UTC

Return-Path: <denghui@chinamobile.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB751AD47B for <mif@ietfa.amsl.com>; Mon, 10 Nov 2014 18:35:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.273
X-Spam-Level:
X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyCgvAmk068P for <mif@ietfa.amsl.com>; Mon, 10 Nov 2014 18:35:03 -0800 (PST)
Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with SMTP id 8F6291AD478 for <mif@ietf.org>; Mon, 10 Nov 2014 18:35:02 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.19]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee2546175d534d-13615; Tue, 11 Nov 2014 10:35:01 +0800 (CST)
X-RM-TRANSID: 2ee2546175d534d-13615
X-RM-SPAM-FLAG: 00000000
Received: from cmccPC (unknown[31.133.163.238]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea546175ce1d8-6b8ca; Tue, 11 Nov 2014 10:35:01 +0800 (CST)
X-RM-TRANSID: 2eea546175ce1d8-6b8ca
From: Hui Deng <denghui@chinamobile.com>
To: "'Sri Gundavelli (sgundave)'" <sgundave@cisco.com>, 'Ted Lemon' <Ted.Lemon@nominum.com>
References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <D0765101.175805%sgundave@cisco.com> <005401cff509$3719eb30$a54dc190$@com> <D0869CBD.177FDF%sgundave@cisco.com> <642BADAF-0E49-4B1E-A2C2-374B1A8FA174@nominum.com> <D086AE73.178045%sgundave@cisco.com>
In-Reply-To: <D086AE73.178045%sgundave@cisco.com>
Date: Mon, 10 Nov 2014 16:34:57 -1000
Message-ID: <002c01cffd58$18276ca0$487645e0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHP/VZdDGqgD4+1QES0VCAdxLmWw5xatOjw
Content-Language: zh-cn
Archived-At: http://mailarchive.ietf.org/arch/msg/mif/OqmX1Om7dYGu260Fso_8dVGLY_w
Cc: 'Brian Haberman' <brian@innovationslab.net>, mif@ietf.org
Subject: Re: [mif] Follow up with BBF proposal
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 02:35:05 -0000

Hi Sri,

Current MIF charter prevent MIF from working on flow switch which is mostly mobile ip/dmm based solution, 
but it doesn't disallow MIF to work on flow split and per packet delivery. This is the key point that PS should explain the clearly.

-Hui

-----Original Message-----
From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] 
Sent: Monday, November 10, 2014 4:23 PM
To: Ted Lemon
Cc: STARK, BARBARA H; Hui Deng; mif@ietf.org; Brian Haberman; Jouni Korhonen; pierrick.seite@orange.com; Dapeng Liu
Subject: Re: Follow up with BBF proposal

Hi Ted,

Having a discussion in MIF WG sounds reasonable to me.

Regarding homenet relation, I'm not sure it belongs to that WG either. The focus of the homenet is on ingress networks and for realizing simplified configurations and that has no relation to access selection on egress paths. FWIW, this work is very much related to what the MIP working group have been doing for many years. Sure, the device in case of BBF is a fixed device, but the fundamental requirements are about access selection, flow mobility and policy exchange. The flow mobility / MCOA work in MIP working groups have done significant amount of work in this area and the expertise is in that group.

If the reason for steering this work away from DMM is due the belief that we will apply only MIP-based solution, I'd say the group will certainly do that, but the WG may also agree to additional solution/protocol mechanisms. Also, IETF is in no position to pick one protocol/solution for this requirement. It is probably reasonable for IETF to identify a set of solutions and present analysis on each of the solutions and that can be the basis for the BBF to review and pick one or more solutions. But, either way I believe the expertise around this topic is in DMM WG and not in homenet or in MIF WG's.

Regards
Sri
 



On 11/10/14 5:59 PM, "Ted Lemon" <Ted.Lemon@nominum.com> wrote:

>On Nov 10, 2014, at 3:08 PM, Sri Gundavelli (sgundave) 
><sgundave@cisco.com> wrote:
>> The BBF requirement as presented in the BBF documents and as 
>>interpreted in draft-seite and draft-lhwxz is about enabling a CPE 
>>device to attach to multiple access network and perform flow management.
>>However, I look at it, I see this this is a mobility requirement and 
>>is really not in the scope of MIF WG. The BBF requirement in question 
>>is all about flow switching or flow splitting across access systems. 
>>I'm not sure why this work belongs MIF and not DMM which is chartered 
>>to handle all mobility use-cases. We have discussed this specific 
>>use-case of flow splitting during MIF formation and explicitly 
>>disallowed MIF WG from taking up such work. The following is the quote 
>>from the MIF chartered text. Also, the MIF WG was primarily looking at 
>>issues for a host attached to multiple access networks, but the hybrid 
>>access is about a CPE attached to multiple networks. I really think 
>>this work should be done in DMM and we did present the requirements in 
>>the last IETF meeting.
>
>It's not at all clear that the way the problem is currently framed is
>even correct.   I am skeptical that this is a flow splitting/flow
>switching problem.   I agree that if it is, it doesn't belong in MIF.
>But I think it's worthwhile to discuss in MIF, and I think it's also
>germane to what homenet is doing.   If this does actually require flow
>splitting and/or switching, that's going to have some pretty nasty 
>implications on the home network, so it would be nice to see if there's 
>a better way to approach the problem.
>