Re: [Banana] Updated Charter

["Sri Gundavelli (sgundave)" <[e-mail]>]

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"
<[e-mail] on behalf of [e-mail]> 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)
>><[e-mail]> 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"
>><[e-mail] on behalf of [e-mail]> 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:[e-mail]]
>>    Sent: Monday, September 25, 2017 12:57 PM
>>    To: David Allan I <[e-mail]>
>>    Cc: [e-mail]
>>    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
>>><[e-mail]> 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:[e-mail]] On Behalf Of Margaret
>>> Cullen
>>> Sent: Monday, September 25, 2017 12:33 PM
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> 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, <[e-mail]>
>>><[e-mail]> wrote:
>>> 
>>> Margaret,
>>> Please could you post the text on the mailing list, as our firewall
>>> blocks google docs Thanks!
>>> phil
>>> 
>>> From: Banana [mailto:[e-mail]] On Behalf Of Margaret
>>> Cullen
>>> Sent: 22 September 2017 20:19
>>> To: [e-mail]
>>> 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
>>    [e-mail]
>>    https://www.ietf.org/mailman/listinfo/banana
>> 
>> 
>
>_______________________________________________
>Banana mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/banana