Re: [Banana] Charter

[Margaret Cullen <[e-mail]>]

 
> The problem with the proposed charter text is the following. Our starting point was about a load-balancing problem.

What starting point?  

These discussions have never been about a generic load balancing problem.  We have always been talking about a home or small office with two or more connections to the Internet, at least some of which are relatively low-bandwidth, and few flows with perhaps only one large or long-lived flow.  I apparently didn’t do a good job of formulating that problem statement at the Informational BOF, because people didn’t understand it.  If you were one of those people, I apologize for being unclear. There was a time, more than a year ago, when we were talking about constraining the problem to a single-operator scenario, but the IESG and IAB thought (correctly, IMO) that it would be more in-scope for the IETF to consider the larger multi-operator problem.  That was decided before the Informational BOF in November of 2016.   The problem was much better formulated during the BANANA mailing list discussion in February, and a much clearer version was included in the charter text reviewed at the BANANA bar BOF in early April.   That version of the charter, first presented in March 2017, is what grew into the charter text presented at the WG-forming BOF in July, and into the text we have now. 

> Given two overlay tunnel paths, how do I split the traffic between these two tunnel paths; is it flow-based routing, packet based routing, or weighted packet distribution, what should be the algorithm and considerations. If you had kept at this at this level, a study item on this might be a reasonable proposal, as we could have learnt if there are any gaps in this area. This is strictly a user-plane discussion and no need for signaling plane.  Instead, the charter talks about "Banana Boxes", "Banana Encapsulation", "Banana Signaling”; This is solution description. IETF does not do system architecture, that is in SDO scope; we work on protocols.

The term BANANA Boxes was first used on the mailing list on February 4th, and it has been used extensively since then in email, in draft charter text, in minutes, etc.  It isn’t a new term, or a new concept.  There is in-band signaling in MPTCP already, and the GRE Tunnel Bonding proposal included a signaling protocol, so signaling has alway been under discussion to some degree.  I think it was Mirja’s idea, at the Bar BOF at IETF-97, to break the provisioning, signaling and transport/encapsulation out separately, so that we might write more than one transport/encapsulation that uses the same signaling protocol, for instance.  This also opened the door to proposals to have one base protocol (perhaps a tunneling protocol) for all traffic, while using other multi-path protocols (such as MPTCP, perhaps MP-QUIC if/when it arrives) to performed bandwidth aggregation in a coordinated fashion.
> 
> We can define a new signaling protocol, just to solve this distribution problem, which can authenticate/authorize the peers, allows path registrations, or prefix allocations, but it will be exactly the same as some existing protocols, but with a new signaling semantics. So, what would be achieve from this effort? It will be another signaling protocol  called “Banana”,  which does exactly the same. I wonder, what is the point of this effort? 

There is no requirement in the Charter that we develop a new protocol and call it BANANA <anything>.  It could be that we write a document for how to do bandwidth aggregation that defines some new messages to run over an existing signaling protocol, for instance.  If you know of a signaling protocol that could do this, I suggest that you point it out to the group, perhaps with a Draft that defines how additional BANANA-specific information could be signaled, if necessary.  If we did that, then the existing protocol would become the “BANANA Signaling Protocol” referred to in the charter.

> I suggest we go back to the drawing board and discuss the Problem Statement. I am saying this very objectively, not with the goal to block this work. 

I hear and understand what you are saying, and I am pretty sure that other people on the list hear and understand what you are saying.  I don’t personally agree that would be the right step to take at this point.  Other people should feel free to express their opinions.

Margaret