Re: [mif] Follow up with BBF proposal

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Tue, 11 November 2014 09:18 UTC

Return-Path: <sgundave@cisco.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 29DBC1A6F96 for <mif@ietfa.amsl.com>; Tue, 11 Nov 2014 01:18:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.095
X-Spam-Level:
X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 uLvNN5RBWTxT for <mif@ietfa.amsl.com>; Tue, 11 Nov 2014 01:18:46 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120BF1A1B75 for <mif@ietf.org>; Tue, 11 Nov 2014 01:18:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3229; q=dns/txt; s=iport; t=1415697526; x=1416907126; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7gOBn4hFMJn3hqY1kitezc1T3RjchG5qqMlLlzvhvNI=; b=Juxcwd4cmneq96+om3RvCEaaaKUCtcS4KYump1X9oL+SzP82wkivhkGR wbiBaQ88Jse3ejU3PWkhPOR0Se+1KSss/dZV2pByFOHD+XyJiG4+/1IAm FHRCZZVvSxt1ZPiLSgVInPFUqwMNsjo5l+DY2dsAInWw0+cXzDLwoQ56P Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAE7UYVStJV2Z/2dsb2JhbABSCoMOgS0E01ECgR0WAQEBAQF9hAIBAQEDAToxBwcFBwQCAQgRBAEBHwkHMhQJCAIEAQ0FG4gdCcxlAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5A4XAcGhEUBBJIxi3SWYIN6bIFIgQMBAQE
X-IronPort-AV: E=Sophos;i="5.07,359,1413244800"; d="scan'208";a="371134178"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 11 Nov 2014 09:18:39 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sAB9IcLS014230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 09:18:38 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.32]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 03:18:38 -0600
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Hui Deng <denghui@chinamobile.com>, 'Ted Lemon' <Ted.Lemon@nominum.com>
Thread-Topic: Follow up with BBF proposal
Thread-Index: AQHP/ZB6Wa/8PQlUKkaI0q2EH9MMrA==
Date: Tue, 11 Nov 2014 09:18:38 +0000
Message-ID: <D086FAFB.178092%sgundave@cisco.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> <002c01cffd58$18276ca0$487645e0$@com>
In-Reply-To: <002c01cffd58$18276ca0$487645e0$@com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [10.21.114.240]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DA569DC58471CE4B9BC41103A7ECBE28@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mif/VgjsCJ_gQIFoiFxMP2keY5HWFo4
Cc: 'Brian Haberman' <brian@innovationslab.net>, "mif@ietf.org" <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 09:18:50 -0000

(We have started the technical discussion, but I do want to respond to
this)


Hi Hui,

> 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.


You are saying the charter disallows splitting of flows across two access
networks, but it allows splitting of a single flow ? What is the logic
here ?  So, this requirement does not match the prior work because the
flow policy is different ? That's the only reason why we should look at
this as a different problem from the work that was done in the past ?

Per-packet load balancing is probably not explicitly stated as transport
group was never in favor of splitting a single flow across two access
links with different transmission properties (latency, packet loss and
jitter) as that will result in peers requiring to deal with
re-odering/buffering issues.  General recommendation was not to split a
single flow, and so the MIP WG always kept the flow definition at the
granularity of a flow-level and not at a packet level. But, in any case
that's just a policy that is exchanged between two peers.


Regards
Sri



On 11/10/14 6:34 PM, "Hui Deng" <denghui@chinamobile.com> wrote:

>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