Re: [Banana] Updated Charter

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

> 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.



That makes sense to me.


- No new  protocols (signaling or encapsulation) or protocol changes
- No selection of ³The Banana Solution², or solution work
- No ³Banana² branding on any protocol/solution; or the terminology of
³Banana boxes², ³Banana links² ..etc.

- Document various protocol approaches for realizing multipath between two
gateways as an informational RFC; identify current art; recommend
respective protocol WG¹s or INT/Transport Area to standardize extensions
- Specify Algorithm and analysis for per-packet load-balancing;
implementation considerations; without tying to any protocol/solution;
even BBF can make use of this algorith

This is some useful work and can benefit the community and other working
groups; will not impact vendor solutions, market situation, result in
definition of alternative protocols which do the same.
SDO¹s can leverage this work and focus on system architecture/solution.





Sri










On 9/25/17, 10:36 PM, "Banana on behalf of Henderickx, Wim (Nokia -
BE/Antwerp)" <[e-mail] on behalf of
[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