Re: [Banana] Charter

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

> The IETF WG formation process focuses on making sure that there is an actual community of people who want to do a well-understood set of work, that those people have the skills and knowledge to do the work successfully, and that they represent enough segments of the industry to have a wide-enough perspective to do the work in a way that will be widely applicable.  The IETF is set up to attract competent groups of people who want to do interesting work within the IETF's scope, and offer them an environment and support that will allow them to do a good job.

Generally, I agree with your above statement. If there is enough interest to do some new work and people ready to write some drafts and people ready to chair the meetings, creation of a WG should be the most logical thing. But, that goes with the assumption that the work is not overlapping with some other work that is happening some where else. That needs to be ensured and hence the need to agree upon the problem statement from both interested and non-interested parties. We need to review this overlap with QUIC, MPTCP, MobIKE and Mobile IPv6 protocols.

The problem with the proposed charter text is the following. Our starting point was about a load-balancing problem. 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.

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?

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.


Sri



From: Margaret Cullen <[e-mail]<mailto:[e-mail]>>
Date: Monday, September 18, 2017 at 1:50 PM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]<mailto:[e-mail]>>, "Zhangmingui (Martin)" <[e-mail]<mailto:[e-mail]>>, Alexandre Petrescu <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Banana] Charter