Re: [Banana] Updated Charter
<philip.eardley@bt.com> Thu, 28 September 2017 09:23 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 65FDA134595 for <banana@ietfa.amsl.com>; Thu, 28 Sep 2017 02:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 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, URIBL_BLOCKED=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 BlGe2yhI6s25 for <banana@ietfa.amsl.com>; Thu, 28 Sep 2017 02:22:56 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE57134571 for <banana@ietf.org>; Thu, 28 Sep 2017 02:22:55 -0700 (PDT)
Received: from EVMHT02-UKBR.domain1.systemhost.net (193.113.108.43) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 28 Sep 2017 10:22:49 +0100
Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVMHT02-UKBR.domain1.systemhost.net (193.113.108.43) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 28 Sep 2017 10:22:52 +0100
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 28 Sep 2017 10:22:51 +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; Thu, 28 Sep 2017 10:22:51 +0100
From: philip.eardley@bt.com
To: sgundave@cisco.com, margaretw42@gmail.com
CC: wim.henderickx@nokia.com, david.i.allan@ericsson.com, banana@ietf.org
Thread-Topic: [Banana] Updated Charter
Thread-Index: AQHTM9eewc8sJpJigkmyyLuhpw9xU6LF0UGwgAAgZQCAAAKngIAABBoAgAAEfQCAAJ2RgIAA9sOAgAAFBwCAATkeAIAAdssAgAC/z3A=
Date: Thu, 28 Sep 2017 09:22:50 +0000
Message-ID: <495513e936694f4da78b8ccf3091c618@rew09926dag03b.domain1.systemhost.net>
References: <2F845727-395A-4FDD-9E6D-41734E22F9BD@gmail.com> <a7717b292b2f4ece916410f98dc38cb4@rew09926dag03b.domain1.systemhost.net> <BEBED891-9A4B-421F-BD80-606D20FB803B@gmail.com> <E6C17D2345AC7A45B7D054D407AA205C68F6B38A@eusaamb105.ericsson.se> <E8628CC1-A63B-422C-AF18-3A16AF3F9223@gmail.com> <E6C17D2345AC7A45B7D054D407AA205C68F6B49C@eusaamb105.ericsson.se> <B420FF35-A139-45EB-AE64-A330B58A5E28@nokia.com> <0C6764E0-B414-4F0A-A04C-B9CC9E5DFABB@gmail.com> <D5F00874.28BB74%sgundave@cisco.com> <A0ED15BD-D3D2-461A-83A8-FC4015A73EE2@gmail.com> <D5F1703B.5643%sgundave@cisco.com>
In-Reply-To: <D5F1703B.5643%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.232]
Content-Type: multipart/alternative; boundary="_000_495513e936694f4da78b8ccf3091c618rew09926dag03bdomain1sy_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/PHTJTy43GUTVu60ZlWSoUQzi9J0>
Subject: Re: [Banana] Updated 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: Thu, 28 Sep 2017 09:23:01 -0000
Sri, My reading of the proposed work is a bit different. There are several “Bandwidth Aggregation mechanisms” proposed and in products (you have counted 7) - it doesn’t seem likely that we can converge to one solution and that the IETF could standardise “the chosen one”. The Charter suggests a common protocol to send control information between the Banana boxes, whatever bandwidth aggregation mechanism you choose. It may also be possible to recommend way or ways of finding the other Banana box, again whatever the Bandwidth aggregation mechanism. These seem to me reasonable things to try and do. Do you have an issue with these two items? (I’m not sure). I don’t interpret these work items as “like redefining Mobile Ipv6/NEMO” (I’m not sure if you’re suggesting this – and I’m out of date with Nemo, so may be getting it wrong). My understanding is that the final item, about a particular bandwidth aggregation solution, is a bit separate and isn’t going to determine what’s chosen for the first two items. I think you have an issue with this final work item, believing it would amount to the IETF rubber stamping a particular solution. I wouldn’t support work on a problem statement – at least the general reasons for doing bandwidth aggregation seem to be understood. From your last paragraph, I think you have ideas about what would be good alternative topics for a WG – would be interested in hearing about those. Best wishes, phil From: Banana [mailto:banana-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: 27 September 2017 23:24 To: Margaret Cullen <margaretw42@gmail.com> Cc: Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com>; David Allan I <david.i.allan@ericsson.com>; banana@ietf.org Subject: Re: [Banana] Updated Charter Hi Margaret, Sure, Several reasons why I disagree .. I will state them again and at the risk of repeating myself .. 1. Lack of a clear problem statement – You are attempting to charter this WG by providing a broad solution description and with no identified technical problems or solution approaches. Various vendors have products supporting this solution and I have identified at least 6 different approaches for realizing this solution and Praveen tells me they have the 7th approach. Now, you want a charter that allows you (or others chosen for chairing this group) to be in a position where they can standardize any protocol/approach and put an IETF stamp on it. This is not IETF’s business to pick one protocol and call it a “Banana” Solution. This stamping will hurt vendors who may choose not to support what you standardize. So, the idea of a “solution” branding is the issue here and the idea of giving such power to a WG chair is the issue here. The idea of allowing you to define a new signaling/user-plane protocol with no justification and that's based on your determination is the issue here. 2. The charter that you are trying to propose below is like redefining Mobile IPv6/NEMO functionality and many other things. The idea of peer discovery, prefix allocation, NAT traversal, Traffic Policies ..and all the other extensions that come with it in the form of security, protocol semantics is not a small efforts, or a charter that 10 people in Banana WG can deliver. Your only argument for not using existing protocols is about lack of a specification on Per-packet LB. So, you want to reinvent the whole wheel, signaling and user plane… and put a solution stamp. Also, the “banana” solution overlaps with what 3GPP and BBF plans to do with their work item. So, we do not know yet who wants this work. 3. There is also simply no support for this work, IMO. I do understand there were few extra voices in the room in IETF99 that gave few people an impression that people are jumping to do this work, but if you look at the complete picture, last 3 years of history, SDO interest, email activity, current opposition and the fact that this is being discussed for 3+ years is a good hint on where this should go. So, I suggest we let this cool down a bit. We need to have conducive environment to discuss and agree on a problem statement. That time is not now and not over emails. Lets meet in IETF 100 and start those discussions and also include BBF/3GPP folks so they can provide feedback. You can certainly tweak few lines of charter text and call it a success, but I am certain it will go no where as I don’t see support for this. Charter text discussion at this stage is premature IMO. Sri ------------ * * Determine how Local and Remote BANANA Boxes find each other (i.e. describe how BANANA boxes will be provisioned/configured). * Select or specify protocol(s) that can be used to send control information between BANANA Boxes, including: * IP Prefixes of access links * Information about link status and properties (including congestion) * Information needed by the Bandwidth Aggregation mechanism(s) in use * Determining which flows are/are not eligible for Bandwidth Aggregation * Select (and extend, if necessary) a tunnel-based method for sending traffic between BANANA Boxes (i.e. specify a tunnel-based Bandwidth Aggregation mechanism). ----------- From: Margaret Cullen <margaretw42@gmail.com<mailto:margaretw42@gmail.com>> Date: Wednesday, September 27, 2017 at 8:18 AM To: Microsoft Office User <sgundave@cisco.com<mailto:sgundave@cisco.com>> Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>, David Allan I <david.i.allan@ericsson.com<mailto:david.i.allan@ericsson.com>>, "banana@ietf.org<mailto:banana@ietf.org>" <banana@ietf.org<mailto:banana@ietf.org>> Subject: Re: [Banana] Updated Charter Hi Sri, I understand that you do not support chartering this group. I think it would be helpful, though, for me and for others, if you could be clear about _why_ you don’t support it. What “damage” do you think would be caused by the formation of this group? If you could explain that, perhaps we could find some way to do this work without causing that damage? Multiple other people have raised concerns with the charter, and I have been making modifications to the charter text in an attempt to address those concerns, successfully in some cases. I would like to do the same for your concerns, if you could help me understand what they are. Margaret On Sep 26, 2017, at 4:38 PM, Sri Gundavelli (sgundave) <sgundave@cisco.com<mailto:sgundave@cisco.com>> wrote: Let this be very clear, I and suppose many others am not agreeing to the current Banana WG charter. Lets not discuss about drafts, ownership and other aspects. I was trying to find a middle ground, where we can limit the damage resulting from the formation of this WG. Hope this helps. Lets focus on technical discussion. Sri On 9/26/17, 1:20 PM, "Banana on behalf of Margaret Wasserman" <banana-bounces@ietf.org<mailto:banana-bounces@ietf.org> on behalf of margaretw42@gmail.com<mailto:margaretw42@gmail.com>> wrote: Hi Wim, I have removed the word signaling in the most recently distributed version, as proposed by Dave Allan below. Does that address your concern, as well? Would people also find it clearer if we used the term protocol(s) or mechanism(s) or something similar where we are currently using the word "solutions"? I think that word may mean different things to different people. Margaret Sent from my iPhone On Sep 26, 2017, at 1:36 AM, Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>> wrote: My 2 cents on this and I believe this is where a lot of controversy is coming from, is why would we not charter Banana as a WG which is defining an information model that is required to execute banana. So banana defines which information needs to be exchanged and what the banana entities do with it to perform banana As such the actual protocol works can be done in different WG(s) and we can leverage existing work as Sri was pointing out. Would this work for people? My 2 cents, just a try to help. On 25/09/2017, 22:13, "Banana on behalf of David Allan I" <banana-bounces@ietf.org<mailto:banana-bounces@ietf.org> on behalf of david.i.allan@ericsson.com<mailto:david.i.allan@ericsson.com>> wrote: I'd probably be happier losing signaling. IMO it is an overloaded term... "specify protocol(s) that can be used..." WDYT? Dave -----Original Message----- From: Margaret Cullen [mailto:margaretw42@gmail.com] Sent: Monday, September 25, 2017 12:57 PM To: David Allan I <david.i.allan@ericsson.com<mailto:david.i.allan@ericsson.com>> Cc: banana@ietf.org<mailto:banana@ietf.org> Subject: Re: [Banana] Updated Charter Good point, Dave! I am a little concerned about the overuse of the term ³mechanism², though (since I define Bandwidth Aggregation mechanisms in the text). So how about just changing ³protocol² to ³protocol(s)"?: OLD: Select or specify a signalling protocol that can be used to send control information between BANANA Boxes, including: NEW: Select or specify signaling protocol(s) that can be used to send control information between BANANA Boxes, including: Or is theres something more that you were trying to capture by changing from ³protocols² to ³mechanisms²? In addition to what you mentioned, this might allow us to reuse an existing protocol to do part of this job, even if that protocol could not be extended to cover everything we need for BANANA. Margaret On Sep 25, 2017, at 3:42 PM, David Allan I <david.i.allan@ericsson.com<mailto:david.i.allan@ericsson.com>> wrote: HI Margaret An aspect that concerns me for a while is the notion that there will be a single signaling protocol to satisfy a laundry list of requirements. On first blush this seems to suggest a solution is already in the wings that needs the laundry list, or that we will end up with a bloated superset god protocol. Neither of which is IMO a totally desirable outcome. Easiest fix for me would be to replace ³a signaling protocol² with ³mechanisms². Cheers Dave From: Banana [mailto:banana-bounces@ietf.org] On Behalf Of Margaret Cullen Sent: Monday, September 25, 2017 12:33 PM To: philip.eardley@bt.com<mailto:philip.eardley@bt.com> Cc: banana@ietf.org<mailto:banana@ietf.org> Subject: Re: [Banana] Updated Charter No problem, Philip. I have included the latest text below. This does not yet include the changes I am currently discussing with Dave Sinicrope. Margaret Charter: BANdwidth Aggregation for Network Access WG The BANdwidth Aggregation for Network Access (BANANA) Working Group is chartered to develop solution(s) to support dynamic path selection on a per-packet basis in networks that have more than one point of attachment to the Internet. Bandwidth Aggregation consists of splitting local traffic across multiple Internet links on a per-packet basis, including the ability to split a single flow across multiple links when necessary. It is the goal of this WG to produce a Bandwidth Aggregation solution that will provide the following benefits: € Higher Per-Flow Bandwidth: Many Internet links available to homes and small offices (DSL, Cable, LTE, Satellite, VPNs, etc.) have relatively low bandwidth. Users may wish to run applications (such as streaming video, or content up/downloads) that require (or could benefit from) more bandwidth for a single traffic flow than is available on any of the local links. A Bandwidth Aggregation solution could supply the needed bandwidth by splitting a single traffic flow across multiple Internet links. € Reduced Cost: Traffic sharing on a per-packet basis allows the full bandwidth of the lowest-cost link to be used first, only using a higher-cost link when the lowest-cost link is full. € Increased Reliability: When one Internet link goes down, ongoing application flows can be moved to another link, preventing service disruption. Proposed BANANA solutions use different mechanisms (e.g. tunnels, proxies, etc.) to split and recombine traffic, but at an abstract level, they involve a local (hardware or software) component on the multi-access network, a remote component within the Internet or at the remote end, and mechanisms for those components to find each other, exchange signalling information, and direct traffic to each other. We refer to the functional components at each end as the Local and Remote ³BANANA Boxes², and we refer to the mechanisms they use to direct traffic to each other as ³Bandwidth Aggregation mechanisms². [Note: Despite our use of the term ³Boxes², it should be understood that a ³BANANA Box² might be a software component running on a piece of hardware with another primary purpose (e.g. a CPE router).] The Bandwidth Aggregation solutions developed in this group will work in true multi-provider scenarios (i.e. they will not depend on all of the aggregated links being provided by a single Internet access provider nor by a group of cooperating providers). Any protocols defined by this group will be IP-based, link-layer-independent solutions, and they will be designed to work across NATs and other middle boxes, as needed. The BANANA WG is chartered to complete the following work items: € Informally document/discuss BANANA problem statement and usage scenarios in a non-archival document (e.g. Wiki, Google Doc, etc.) € Determine how Local and Remote BANANA Boxes find each other (i.e. describe how BANANA boxes will be provisioned/configured.) € Select or specify a signalling protocol that can be used to send control information between BANANA Boxes, including: € IP Prefixes of access links € Information about link status and properties (including congestion) € Information needed by the Bandwidth Aggregation mechanism(s) in use € Determining which flows are/are not eligible for Bandwidth Aggregation € Select (and extend, if necessary) a tunneling encapsulation for sending traffic between BANANA Boxes. When applicable, the BANANA WG will use existing IETF protocols, or extensions to existing IETF protocols, as the basis for the work items listed above. When an existing protocol is used, the WG deliverable will be a document describing the use of that protocol for Bandwidth Aggregation and/or a set of options or extensions to an existing IETF protocol to make it useful for Bandwidth Aggregation. The BANANA WG will also work with other IETF WGs (and other SDOs, as requested) that define additional Bandwidth Aggregation mechanisms (if any) to ensure that the protocols defined by the BANANA WG will meet the needs of those additional mechanisms. Milestones € Apr 2018 Adopt WG draft for provisioning/configuration mechanism € Apr 2018 Adopt WG draft for signaling protocol € Apr 2018 Adopt WG draft(s) for tunnel encapsulation(s) € Feb 2019 WGLC on provisioning/configuration mechanism € Feb 2019 WGLC on signaling protocol € Feb 2019 WGLC on tunnel encapsulation(s) € Aug 2019 Send provisioning/configuration mechanism to the IESG € Aug 2019 Send signalling protocol to the IESG € Aug 2019 Send tunnel encapsulation(s) to the IESG On Sep 25, 2017, at 12:37 PM, <philip.eardley@bt.com<mailto:philip.eardley@bt.com>> <philip.eardley@bt.com<mailto:philip.eardley@bt.com>> wrote: Margaret, Please could you post the text on the mailing list, as our firewall blocks google docs Thanks! phil From: Banana [mailto:banana-bounces@ietf.org] On Behalf Of Margaret Cullen Sent: 22 September 2017 20:19 To: banana@ietf.org<mailto:banana@ietf.org> Subject: [Banana] Updated Charter I have updated the charter text in an attempt to reflect all of the feedback to date. You can find the new version here: https://docs.google.com/document/d/1byOJ_To6eL1ZBxKSYpTafQbngTBiNwxaK7 ReIsld9Ek/edit Thoughts? Comments? Do folks think this is ready to send to the IESG? Or are there other changes that it would make it clearer or better? Margaret _______________________________________________ Banana mailing list Banana@ietf.org<mailto:Banana@ietf.org> https://www.ietf.org/mailman/listinfo/banana _______________________________________________ Banana mailing list Banana@ietf.org<mailto:Banana@ietf.org> https://www.ietf.org/mailman/listinfo/banana _______________________________________________ Banana mailing list Banana@ietf.org<mailto:Banana@ietf.org> https://www.ietf.org/mailman/listinfo/banana
- Re: [Banana] Updated Charter Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [Banana] Updated Charter Florin Baboescu
- Re: [Banana] Updated Charter Margaret Wasserman
- Re: [Banana] Updated Charter Florin Baboescu
- Re: [Banana] Updated Charter Sri Gundavelli (sgundave)
- Re: [Banana] Updated Charter Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [Banana] Updated Charter Zhangmingui (Martin)
- Re: [Banana] Updated Charter Sri Gundavelli (sgundave)
- Re: [Banana] Updated Charter Sri Gundavelli (sgundave)
- Re: [Banana] Updated Charter Sri Gundavelli (sgundave)
- Re: [Banana] Updated Charter Margaret Wasserman
- Re: [Banana] Updated Charter Sri Gundavelli (sgundave)
- Re: [Banana] Updated Charter Muley, Praveen (Nokia - US/Mountain View)
- Re: [Banana] Updated Charter Margaret Wasserman
- [Banana] Updated Charter Margaret Cullen
- Re: [Banana] Updated Charter Margaret Cullen
- Re: [Banana] Updated Charter David Allan I
- Re: [Banana] Updated Charter Margaret Cullen
- Re: [Banana] Updated Charter David Allan I
- Re: [Banana] Updated Charter Margaret Cullen
- Re: [Banana] Updated Charter Margaret Cullen
- Re: [Banana] Updated Charter Margaret Wasserman
- Re: [Banana] Updated Charter Margaret Wasserman
- Re: [Banana] Updated Charter Sri Gundavelli (sgundave)
- Re: [Banana] Updated Charter Sri Gundavelli (sgundave)
- Re: [Banana] Updated Charter Margaret Cullen
- Re: [Banana] Updated Charter Margaret Cullen
- Re: [Banana] Updated Charter Sri Gundavelli (sgundave)
- Re: [Banana] Updated Charter philip.eardley
- Re: [Banana] Updated Charter Sri Gundavelli (sgundave)
- Re: [Banana] Updated Charter Margaret Cullen
- Re: [Banana] Updated Charter Sri Gundavelli (sgundave)
- Re: [Banana] Updated Charter Margaret Cullen
- Re: [Banana] Updated Charter Sri Gundavelli (sgundave)
- Re: [Banana] Updated Charter Margaret Cullen
- Re: [Banana] Updated Charter Sri Gundavelli (sgundave)
- Re: [Banana] Updated Charter Muley, Praveen (Nokia - US/Mountain View)
- Re: [Banana] Updated Charter N.Leymann
- Re: [Banana] Updated Charter Muley, Praveen (Nokia - US/Mountain View)
- Re: [Banana] Updated Charter mrcullen42
- Re: [Banana] Updated Charter Zhangmingui (Martin)
- Re: [Banana] Updated Charter Sri Gundavelli (sgundave)
- Re: [Banana] Updated Charter Margaret Wasserman
- Re: [Banana] Updated Charter Sri Gundavelli (sgundave)