Re: [mif] Follow up with BBF proposal

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Tue, 11 November 2014 02:22 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 677331AD44E for <mif@ietfa.amsl.com>; Mon, 10 Nov 2014 18:22:42 -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 j_p56FcSbYzN for <mif@ietfa.amsl.com>; Mon, 10 Nov 2014 18:22:40 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C141AD44A for <mif@ietf.org>; Mon, 10 Nov 2014 18:22:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3057; q=dns/txt; s=iport; t=1415672560; x=1416882160; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7/r3cWEjvAAVesDa2GAKoVlyu1lU33v2yXyjwhM8CbY=; b=B2l4ceJTNOEhEyp7ywlHbxpT994BmtQ6N1tiVHa3AZi/ZAOpvchQeDOi oeHzuhk/4WpaVYcoPqa2HeOzqWwOOBNPq+nDVvSnjGiUIyg/giOb2TCB5 hIXXiFXuP95qzymEXgc4yt7nu2SV6xegHWdSzMX1IQeM10S2VNTaUZxy+ Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAB1yYVStJV2Y/2dsb2JhbABSCoMOgS0E008CgRwWAQEBAQF9hAMBAQQ6MQcHEAIBCBgeEDIlAgQOBRuIJsx/AQEBAQEBAQEBAQEBAQEBAQEBARmQOVwHhEsFkjGLdJZgg3psgUiBAwEBAQ
X-IronPort-AV: E=Sophos;i="5.07,357,1413244800"; d="scan'208";a="95354001"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 11 Nov 2014 02:22:40 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sAB2MdvF021868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 02:22:39 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.32]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 20:22:39 -0600
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
Thread-Topic: Follow up with BBF proposal
Thread-Index: AQHP/VZdDGqgD4+1QES0VCAdxLmWww==
Date: Tue, 11 Nov 2014 02:22:39 +0000
Message-ID: <D086AE73.178045%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>
In-Reply-To: <642BADAF-0E49-4B1E-A2C2-374B1A8FA174@nominum.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.69.71]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4F2B8BB6013E1A4BA8182B937D078E55@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mif/_QSo6HwhELgGQVftP8gO6HjdP78
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 02:22:42 -0000

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