Re: [Banana] Updated Charter

Margaret Cullen <margaretw42@gmail.com> Wed, 27 September 2017 15:23 UTC

Return-Path: <margaretw42@gmail.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 13AA0134E4D for <banana@ietfa.amsl.com>; Wed, 27 Sep 2017 08:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Rkhw4hYusppi for <banana@ietfa.amsl.com>; Wed, 27 Sep 2017 08:23:33 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87128134C08 for <banana@ietf.org>; Wed, 27 Sep 2017 08:18:47 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id 47so13983327qts.10 for <banana@ietf.org>; Wed, 27 Sep 2017 08:18:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=pVwVW/6QGmVSUwrtmE8g2tNiFRqOA5u3LIEnrcqT26Q=; b=shFQhmcdmttQgoWTDI0Ol1bqZQApAMUd/8t2gvvol7fNMEcBrJxMpfNaXxVKLte54c 9N1Qxnr/Rxvib54xad2qnuJ0vy1dBB0RSoJWiMiVnQbsZjILfYpUWIMwvCcV2Mas4B+I Pqm/78EAPGx2x8DqHPHBS8qquPEaf7RZu26IeTShoBQnX8sAjkSuAuaW/gEhRyydPdIH hjcmBKc/g2JB5CpTwRnbSGfwV2Ed48eFiFuPjuv5r+B6Il4py7qXvU6LO2Gm50XKHQOO 4vW/L+o5Lg/B6xd7Uje7DPTVR/Z1aLfgc0mRO+Kc6HTHYk+sFmzGjlxCw3ZD3WmqtJwm T6Pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=pVwVW/6QGmVSUwrtmE8g2tNiFRqOA5u3LIEnrcqT26Q=; b=alfuv4byfBoKzDHcUV6Fyhs6V3LI0DhPgZC+zBjV86Qak+lQh65Y+YhehentJwfYQy +fH6PqSAGfcPko/uoObsXOvrTpVWGBHk+c40FBoxnsxes0LJoZkjYx2XId+uRWqEY6XE zuavEMLtc2q/iJgIHrk56vLuWyKD/cVoWH1abCjA4T5lZwejAAvusy1ADjpgn/0a5cSq op47fo/XHHZVcEbMgSCiftrQWkx6hugmiI9lMsUwLMx1kmrdwikhIcYiwP8AbVWxh0tq 4TFLM4/Ll2DdB82LqaSKMn4kJrIcJRYF2TAkCRPuomYtxLYlCT1Sf+6DqjQdUXKiXkPS NsTg==
X-Gm-Message-State: AHPjjUj4NX3cqlBm6WqjGfYnjO5fd8cxj83J0ORPaO9nlQ4Qle5cG93a rZd3QeUeqXyNN2p/CDtjqRHC6DVt
X-Google-Smtp-Source: AOwi7QDMIvhOYnxwko9I6OY0MOIifqf13W9VmFPmStZ2AJALjEyndgP5AfrUL51rdC3MV5pHnWtalw==
X-Received: by 10.237.59.91 with SMTP id q27mr2425209qte.340.1506525526271; Wed, 27 Sep 2017 08:18:46 -0700 (PDT)
Received: from ?IPv6:2603:3005:2409:8400:f8a4:28b3:5b80:e702? ([2603:3005:2409:8400:f8a4:28b3:5b80:e702]) by smtp.gmail.com with ESMTPSA id 36sm8977951qtz.89.2017.09.27.08.18.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Sep 2017 08:18:45 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_86F94763-1AB2-4EBA-A53E-AD7EE079DE5A"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Margaret Cullen <margaretw42@gmail.com>
In-Reply-To: <D5F00874.28BB74%sgundave@cisco.com>
Date: Wed, 27 Sep 2017 11:18:44 -0400
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, David Allan I <david.i.allan@ericsson.com>, "banana@ietf.org" <banana@ietf.org>
Message-Id: <A0ED15BD-D3D2-461A-83A8-FC4015A73EE2@gmail.com>
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>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/EbXggnxQL4qxt5FMCmXFCBzVUB8>
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: Wed, 27 Sep 2017 15:23:36 -0000

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> 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> 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 on behalf of 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>
>>>   Cc: 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 <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>
>>>> <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
>>>> 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
>>>   https://www.ietf.org/mailman/listinfo/banana
>>> 
>>> 
>> 
>> _______________________________________________
>> Banana mailing list
>> 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 <https://www.ietf.org/mailman/listinfo/banana>