Re: [Banana] Charter

<philip.eardley@bt.com> Wed, 20 September 2017 09:03 UTC

Return-Path: <philip.eardley@bt.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 A7493133245 for <banana@ietfa.amsl.com>; Wed, 20 Sep 2017 02:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jHjWMXaMKtoI for <banana@ietfa.amsl.com>; Wed, 20 Sep 2017 02:03:13 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41AF6133087 for <banana@ietf.org>; Wed, 20 Sep 2017 02:03:13 -0700 (PDT)
Received: from E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 20 Sep 2017 10:03:08 +0100
Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 20 Sep 2017 10:03:05 +0100
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 20 Sep 2017 10:02:57 +0100
Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1293.004; Wed, 20 Sep 2017 10:02:57 +0100
From: philip.eardley@bt.com
To: sgundave@cisco.com, mrcullen42@gmail.com
CC: zhangmingui@huawei.com, alexandre.petrescu@gmail.com, wim.henderickx@nokia.com, banana@ietf.org
Thread-Topic: [Banana] Charter
Thread-Index: AQHS/w5ltg//ruHrikWaK9JnJ9Le2KJYD3uAgFsJ1ICAADjYAIAArB+AgAGr8wCAALSeAIAEmiuAgABd/ACAAAcIAIAAEp+AgAAb3ACAAlNrEA==
Date: Wed, 20 Sep 2017 09:02:56 +0000
Message-ID: <c24c36808777493198304d37daa9fe69@rew09926dag03b.domain1.systemhost.net>
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>
In-Reply-To: <D5E58ECD.22D723%sgundave@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.202.243]
Content-Type: multipart/alternative; boundary="_000_c24c36808777493198304d37daa9fe69rew09926dag03bdomain1sy_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/mjOw0CF51LTS2kOoCwda8SyFE_E>
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: Wed, 20 Sep 2017 09:03:16 -0000

Sri,



<< The problem with the proposed charter text is the following. Our starting point was about a load-balancing problem. Given two overlay tunnel paths, how do I split the traffic between these two tunnel paths; is it flow-based routing, packet based routing, or weighted packet distribution, what should be the algorithm and considerations. If you had kept at this at this level, a study item on this might be a reasonable proposal, as we could have learnt if there are any gaps in this area. This is strictly a user-plane discussion and no need for signaling plane.  Instead, the charter talks about "Banana Boxes", "Banana Encapsulation", "Banana Signaling"; This is solution description. IETF does not do system architecture, that is in SDO scope; we work on protocols.>>



I think it's better for the IETF to define the protocol for the signalling between the Banana 'boxes'. The algorithm for splitting traffic between the paths can be left for vendors, I think.



There's an open question in my mind whether the split would be done per packet or per flow, and if that choice has implications on the signalling protocol between the Banana boxes.  I presume that if, as the charter says, it allows per packet split, then it also supports per flow support?



Best wishes,

phil

From: Banana [mailto:banana-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: 18 September 2017 23:30
To: Margaret Cullen <mrcullen42@gmail.com>
Cc: Zhangmingui (Martin) <zhangmingui@huawei.com>; Alexandre Petrescu <alexandre.petrescu@gmail.com>; Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com>; banana@ietf.org
Subject: Re: [Banana] Charter

> The IETF WG formation process focuses on making sure that there is an actual community of people who want to do a well-understood set of work, that those people have the skills and knowledge to do the work successfully, and that they represent enough segments of the industry to have a wide-enough perspective to do the work in a way that will be widely applicable.  The IETF is set up to attract competent groups of people who want to do interesting work within the IETF's scope, and offer them an environment and support that will allow them to do a good job.

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.

The problem with the proposed charter text is the following. Our starting point was about a load-balancing problem. Given two overlay tunnel paths, how do I split the traffic between these two tunnel paths; is it flow-based routing, packet based routing, or weighted packet distribution, what should be the algorithm and considerations. If you had kept at this at this level, a study item on this might be a reasonable proposal, as we could have learnt if there are any gaps in this area. This is strictly a user-plane discussion and no need for signaling plane.  Instead, the charter talks about "Banana Boxes", "Banana Encapsulation", "Banana Signaling"; This is solution description. IETF does not do system architecture, that is in SDO scope; we work on protocols.

We can define a new signaling protocol, just to solve this distribution problem, which can authenticate/authorize the peers, allows path registrations, or prefix allocations, but it will be exactly the same as some existing protocols, but with a new signaling semantics. So, what would be achieve from this effort? It will be another signaling protocol  called "Banana",  which does exactly the same. I wonder, what is the point of this effort?

I suggest we go back to the drawing board and discuss the Problem Statement. I am saying this very objectively, not with the goal to block this work.


Sri



From: Margaret Cullen <mrcullen42@gmail.com<mailto:mrcullen42@gmail.com>>
Date: Monday, September 18, 2017 at 1:50 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