Re: [Banana] Charter

[[e-mail]]

Hi Alex,

Sent from my iPhone

> On Jul 17, 2017, at 11:06 AM, Alexandre Petrescu <[e-mail]> wrote:
> 
> Mic: for the encapsulation methods.
> 
> IP encapsulation can mean to add another IP header similar to the original, or to add another header like a Routing Header, or to add another non-IP header.

As the charter text now attempts to make clear, when we talk about a "BANANA Encapsulation" we are not necessarily talking about adding an extra header, as the "Encapsulation" could be a tunnel-based mechanism (of which the bonding tunnels proposal is an example) OR a proxy-based solution (of which MPTCP Proxy is an example).

> There are many encapsulation methods at IETF and some other outside of IETF (e.g. GTP at 3GPP).  People also work new encapsulation methods at IETF like "skinny encap" in 6man WG.
> 
> There could be a means between BANANA Local box and BANANA Remote box to negotiate that method of "encapsulation", and maybe default to some value such as "Generic Encapsulaiton"

There is definitely a desire, reflected in the charter, to support more than one type of BANANA Encapsulation.  There has even been discussion about using more than one BANANA Encapsulation in a single deployment (I.e. MPTCP Proxy for TCP traffic and tunnels for non-TCP traffic).  The signaling protocol could include negotiating which Encapsulation is used for which traffic, if there are multiple options available on both ends.

The most recent proposed BANANA charter text indicates that the BANANA WG will define a tunnel-based Encapsulation. There is also ongoing discussion of defining an MPTCP-based Encapsulation in the MPTCP WG.

Margaret