Re: [Banana] Charter

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Tue, 19 September 2017 00:21 UTC

Return-Path: <sgundave@cisco.com>
X-Original-To: banana@ietfa.amsl.com
Delivered-To: banana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA011332DA for <banana@ietfa.amsl.com>; Mon, 18 Sep 2017 17:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 e5cShDo0gPfB for <banana@ietfa.amsl.com>; Mon, 18 Sep 2017 17:20:59 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46FC41332CA for <banana@ietf.org>; Mon, 18 Sep 2017 17:20:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36642; q=dns/txt; s=iport; t=1505780459; x=1506990059; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ti2EycFEybz/yeaEI2+VdBv95LW5tfoRehzCppa2fSo=; b=ZKTiGrwybjZ0QpMrj1oEo2FJptW73MGqKevQIgMgEKZVkCGkE6DEPOIu u7y2/jHZ06NcFjgsN2GtK1rgjxLOy1kP588NWILqLyhYwMa0gqUymQk8f eaf+Ay8bd3tzpiuQKYD4A6lmghkRGanE4lmTUcQPiIKA54iASrTw4sj/f w=;
X-Files: 74A4446F-CFF1-4CCD-973D-BF402E138FD2.png : 19172
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DYAAAPYsBZ/5BdJa1cGQEBAQEBAQEBAQEBBwEBAQEBgm9rgVInB44Oj3eBdIg7iCyCGIMnghIHAQKFOwKESj8YAQIBAQEBAQEBayiFGAEBAQECAQV0BQsCAQgOAwMBAgYBAQEfBwIFEAEJBQwUCQgCBA4EAQYIDYoAAw0Iq02HOw2DXwEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4PgyuCAoFQgWODKIJYgkCFUwEEkXyOUDwChlmJA4R3kniMWoguAhEZAYE4AR84gQ13FYViHIFndocIgQ8BAQE
X-IronPort-AV: E=Sophos;i="5.42,415,1500940800"; d="png'150?scan'150,208,217,150";a="286651730"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 00:20:57 +0000
Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v8J0KvsG026401 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Sep 2017 00:20:57 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 18 Sep 2017 19:20:57 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1263.000; Mon, 18 Sep 2017 19:20:57 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Margaret Cullen <mrcullen42@gmail.com>
CC: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, "Zhangmingui (Martin)" <zhangmingui@huawei.com>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, "banana@ietf.org" <banana@ietf.org>
Thread-Topic: [Banana] Charter
Thread-Index: AQHS/w5lhWOFLy/yHEWQ/Po5rcE+YqJYdBGAgFsJ04CAADjYAIAArB+AgAGr8wCAALSfAIAEmiqAgABd/AD//5ILgIAAh5yA//+msICAAIHlAP//nMUA
Date: Tue, 19 Sep 2017 00:20:56 +0000
Message-ID: <D5E5AA42.22D7AB%sgundave@cisco.com>
References: <96A7BC33-FB64-487A-A60D-7AB8504C9DDF@gmail.com> <a1df884a51f246a7969c0057ff78d807@BTWP000357.corp.ads> <C3A4BFB9-EAD7-4B32-90C1-248D6D74ECD1@gmail.com> <9A767D1D-C6CA-4C7D-A281-7150E259881D@gmail.com> <DB5PR07MB13998EE07C5B5D5DBACED79C9B1A0@DB5PR07MB1399.eurprd07.prod.outlook.com> <7ED94797-5E72-4191-B861-4CD2F410BBD5@gmail.com> <7i60gox0c8.wl-jch@irif.fr> <DB5PR07MB1399FEDB262E0205457EA8AB9BFC0@DB5PR07MB1399.eurprd07.prod.outlook.com> <87bmqgov69.wl-jch@irif.fr> <DB5PR07MB1399977AFFE9FA7D19A2D34D9BFC0@DB5PR07MB1399.eurprd07.prod.outlook.com> <0d8ce583860345b89020113f1239be5d@BTWP000357.corp.ads> <21BD0F20-9CE5-466B-992E-93F6D84DB7D4@gmail.com> <95788B92-E8C1-4FE6-9B0C-7F29361D9297@trammell.ch> <d3759d89-9f6e-bcf4-8c44-32f3f435d784@gmail.com> <01e83ac6-0bd0-e7c7-01e4-0ffb7af73034@gmail.com> <4B6D7CF5-E6BC-4ECA-9299-7458A624320B@nokia.com> <B31BA5EB-7369-4B49-B240-AA6C3E653231@gmail.com> <2F216DBC-43EE-45AC-AAB8-68C81A14AD73@nokia.com> <4552F0907735844E9204A62BBDD325E7A65EC703@NKGEML515-MBX.china.huawei.com> <260086DD-D245-46EF-89E2-308D5A58AAFB@nokia.com> <5FECB6A6-41B7-41D1-A8B8-B7BCE8474F90@gmail.com> <2CD45C9D-41FB-425F-946E-D3AE47C9B000@nokia.com> <6A618A1C-92FB-467F-8F7D-6A9B40FC191E@gmail.com> <D5E56BEA.28AE8D%sgundave@cisco.com> <9CD725AF-B9FE-4E81-BFD6-21A812DF48CF@gmail.com> <D5E58ECD.22D723%sgundave@cisco.com> <355C07D1-032F-4E07-AEEB-6E1FD5024A68@gmail.com>
In-Reply-To: <355C07D1-032F-4E07-AEEB-6E1FD5024A68@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.188.54]
Content-Type: multipart/related; boundary="_004_D5E5AA4222D7ABsgundaveciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/ARVGguZ8kqL6JQa_Pc6A8WtGgCI>
Subject: Re: [Banana] Charter
X-BeenThere: banana@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Bandwidth Aggregation for interNet Access: Discussion of bandwidth aggregation solutions based on IETF technologies." <banana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/banana>, <mailto:banana-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/banana/>
List-Post: <mailto:banana@ietf.org>
List-Help: <mailto:banana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/banana>, <mailto:banana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Sep 2017 00:21:02 -0000

> There are people solving this problem today, in the field, though, and they don't seem to be using the protocols you have mentioned.  Can you point to someone who is?

OK! I can provide that information. We have large scale deployments of the below based on Proxy Mobile IPv6 (100's of thousands), with the ability to perform per-flow load balancing and per-packet and link-weighted packet distribution.  Many DSL operators have deployed this (DSL RG with LTE dongle)  and we have also deployed for many overlay applications.  You can check cisco CCO pages for the product details. For measuring path characteristics, we use IP SLA. Its a solution based on PMIP mobility and SLA for path performance measurement.

Your problem statement is exactly this. The difference is that its Banana Signaling, Banana encapsulation and with Banana anchor/CPE. Its 100% re-invention of existing art, IMO, but built on the argument that we need improved packet distribution scheme. In the process you are building a solution, IMO.

The aspect of CPE registering with the anchor, discovery of the anchor, path specific registrations, prefix negotiation for the ingress network from the overlay anchor, tunnel parameter negotiation, flow policy negotiation have to be part of your protocol. So, this is the big overlap and so this is not about few willing hands to do the work.




[cid:74A4446F-CFF1-4CCD-973D-BF402E138FD2]


*** I know some others realizing the above with MobIKE extensions, and some others realizing the same based on MPTCP Anchor.


Sri



From: Margaret Cullen <mrcullen42@gmail.com<mailto:mrcullen42@gmail.com>>
Date: Monday, September 18, 2017 at 4:15 PM
To: Sri Gundavelli <sgundave@cisco.com<mailto:sgundave@cisco.com>>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>, "Zhangmingui (Martin)" <zhangmingui@huawei.com<mailto:zhangmingui@huawei.com>>, Alexandre Petrescu <alexandre.petrescu@gmail.com<mailto:alexandre.petrescu@gmail.com>>, "banana@ietf.org<mailto:banana@ietf.org>" <banana@ietf.org<mailto:banana@ietf.org>>
Subject: Re: [Banana] Charter


On Sep 18, 2017, at 6:30 PM, Sri Gundavelli (sgundave) <sgundave@cisco.com<mailto:sgundave@cisco.com>> wrote:
Generally, I agree with your above statement. If there is enough interest to do some new work and people ready to write some drafts and people ready to chair the meetings, creation of a WG should be the most logical thing. But, that goes with the assumption that the work is not overlapping with some other work that is happening some where else. That needs to be ensured and hence the need to agree upon the problem statement from both interested and non-interested parties. We need to review this overlap with QUIC, MPTCP, MobIKE and Mobile IPv6 protocols.

This is one of the reasons we have BOFs.  If you believe that there is some overlap with one of those protocols, or that one of those protocols already solves the problem, say that and explain how.  Also, perhaps include some explanation of what that protocol is not already being used to solve this problem, or what sort of changes or extensions would be needed to make it solve the problem more completely.  I am pretty sure that the IESG doesn't want to charter a group to solve an already-solved problem.

There are people solving this problem today, in the field, though, and they don't seem to be using the protocols you have mentioned.  Can you point to someone who is?

Margaret