Re: [Banana] Final(?) BANANA Charter Text

[chenlihao <[e-mail]>]

Hi Margaret,

I have read the charter text and I think the issues have been well addressed. Works here would be worthwhile in my opinion and I'd like to support it.

Lihao

> -----Original Message-----
> From: Banana [mailto:[e-mail]] On Behalf Of Margaret Cullen
> Sent: Tuesday, September 19, 2017 3:48 AM
> To: [e-mail]
> Subject: Re: [Banana] Final(?) BANANA Charter Text
> 
> If there are people who do support the BANANA charter text, more or less as
> written, and would like to see us do this work in the IETF, it would be helpful if
> you could state that support here, along with any constructive suggestions you
> have for improvements to the text.
> 
> Thanks,
> Margaret
> 
> 
> > On Sep 12, 2017, at 9:40 AM, Margaret Cullen <[e-mail]>
> wrote:
> >
> >
> > Hi BANANA Folks,
> >
> > Based on the meeting in Prague, and the feedback we have received on the
> BANANA List regarding the charter Google Doc, I have included the current
> state of the BANANA charter text below.  I believe that all of the issues have
> been addressed, and that this charter is ready to go to the IESG for review.
> >
> > We’d like to get this charter to the IESG as soon as possible, in the hope of
> chartering a WG before the November IETF meeting, so please provide any final
> feedback you have on this text to the BANANA list no later than next Tuesday,
> September 19th.  Thank you.  Unless there are any major issues, I will send
> this charter (with minor tweaks as needed) to the IESG next Tuesday.
> >
> > The current working version of the charter text also continues to be visible
> here:
> https://docs.google.com/document/d/1byOJ_To6eL1ZBxKSYpTafQbngTBiNwxa
> K7ReIsld9Ek/edit
> >
> > Thank you,
> > 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 approaches (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 methods
> they use to direct traffic to each other as a “BANANA Encapsulations”.
> >
> > [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).  Similarly, the use of the
> term “Encapsulation” does not mean that all BANANA Encapsulations will add
> an explicit encapsulation header.]
> >
> > The Bandwidth Aggregation solutions developed in this group will be designed
> to work in multi-provider scenarios (i.e. they will not depend on all of the
> aggregated links being provided by a single Internet access provider).
> >
> > The BANANA WG is chartered to complete the following  work items:
> > 	• Informally document/discuss BANANA 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.
> define BANANA provisioning/configuration mechanism(s)).
> > 	• 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 BANANA Encapsulations
> > 		• Determining which flows are/are not eligible for BANANA
> Encapsulation
> > 	• Select (and extend, if necessary) an existing tunneling encapsulation (e.g.
> GRE)  for sending traffic between BANANA Boxes.
> >
> > The BANANA WG will consider existing IETF protocols, where applicable, as
> the basis for the work items listed above.
> >
> > The Banana WG will work also with other IETF WGs (and other SDOs, as
> requested) that define additional BANANA Encapsulations (if any)  to ensure
> that the protocols defined by the BANANA WG will meet the needs of those
> additional Encapsulations.
> >
> > 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
> >
> >
> >
> 
> _______________________________________________
> Banana mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/banana