Subject: [Banana] Troublesome Encapsulations

From: Margaret Cullen <[email-masked]>
Date: Wed, 20 Sep 2017 16:23:46 -0400

We seem to be continuing to struggle with the term "BANANA Encapsulations", and I have been thinking about alternatives.  The problem comes up because neither “transport” nor “encapsulation” is the right word, since some of the proposed BANANA approaches use transport-layer mechanisms to split/recombine flows, while others use tunnel-based mechanisms (AKA encapsulations) to split/recombine flows.

What if, instead, we used the term “Bandwidth Aggregation (BA) Mechanism”?  We would define a BA Mechanism to be a transportlayeror encapsulation-layer mechanism that splits a single flow across multiple access networks and restores the traffic to a single flow before it reaches its final destination.  

We could then make it clear that the BANANA signaling protocol should be designed to work with multiple possible BA Mechanisms, perhaps even with multiple BA Mechanisms in use on the same BANANA Box at the same time.

Do you think this change would make the charter clearer?  Or more confusing?  Any other thoughts?

If folks like this general idea, I will suggest explicit charter changes to make it so.

Thanks,
Margaret

---

From: "Zhangmingui (Martin)" <[email-masked]>
Date: Thu, 21 Sep 2017 04:00:54 +0000

Hi Margaret,

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

I understand this is about the integration of BANANA-WG-defined protocol and non-BANANA-WG-defined BANANA-like approach. I thought we may simply replace the two appearances of “Encapsulations” with “approaches”. But I think the term " Bandwidth Aggregation (BA) Mechanism " is also fine.

During the 99th IETF meeting, a side meeting was organized to present a few BANANA solutions/proposals. I got to know the following draft that happened to document a potential solution in this area. 

https://tools.ietf.org/html/draft-zuo-banana-mptcp-integration-00

It shows other IETF WGs may be lack of a signaling protocol to exchange certain information between the two boxes in order to realize a BANANA solution. However, if the BANANA protocol is adopted there, this WG need not bother with reinventing an entire signaling protocol. A few extensions to the BANANA protocol might be OK.

Thanks,
Mingui

> -----Original Message-----
> From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
> Sent: Thursday, September 21, 2017 4:24 AM
> To: [email-masked]
> Subject: [Banana] Troublesome Encapsulations
> 
> We seem to be continuing to struggle with the term "BANANA Encapsulations",
> and I have been thinking about alternatives.  The problem comes up because
> neither “transport” nor “encapsulation” is the right word, since some of the
> proposed BANANA approaches use transport-layer mechanisms to
> split/recombine flows, while others use tunnel-based mechanisms (AKA
> encapsulations) to split/recombine flows.
> 
> What if, instead, we used the term “Bandwidth Aggregation (BA) Mechanism”?
> We would define a BA Mechanism to be a transportlayeror encapsulation-layer
> mechanism that splits a single flow across multiple access networks and restores
> the traffic to a single flow before it reaches its final destination.
> 
> We could then make it clear that the BANANA signaling protocol should be
> designed to work with multiple possible BA Mechanisms, perhaps even with
> multiple BA Mechanisms in use on the same BANANA Box at the same time.
> 
> _______________________________________________
> Banana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/banana