Re: [Banana] Charter

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

 I think it's better for the IETF to define the protocol for the signalling between the Banana 'boxes'. The algorithm for splitting traffic between the paths can be left for vendors, I think.

Hi Phil,

The only technical point that I have seen in all the Banana discussions over the last 2+ years was about per-packet load balancing. How do you support per-packet load balancing given two tunnel overlay paths. In the past IETF transport AD always discouraged this mode. This is a generic  problem, can be used with controller initiated static  (SDWAN) tunnels, IPsec based tunnels, PMIP tunnels..etc. We dont need a new signaling protocol for this, you can use any of the existing protocols. Its a flag in DSMIP IFOM 6088/6089 or in IKEv2 RFC. Why do you need a new protocol for this? If the algorithm is left for vendors as the case today, what are we developing here? What is the point of this effort? How is new signaling between "banana" boxes helping? What is it solving?

Regards
Sri


On Sep 20, 2017, at 2:03 AM, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> wrote:


Sri,



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



I think it's better for the IETF to define the protocol for the signalling between the Banana 'boxes'. The algorithm for splitting traffic between the paths can be left for vendors, I think.



There's an open question in my mind whether the split would be done per packet or per flow, and if that choice has implications on the signalling protocol between the Banana boxes.  I presume that if, as the charter says, it allows per packet split, then it also supports per flow support?



Best wishes,

phil

From: Banana [mailto:[e-mail]] On Behalf Of Sri Gundavelli (sgundave)
Sent: 18 September 2017 23:30
To: Margaret Cullen <[e-mail]<mailto:[e-mail]>>
Cc: Zhangmingui (Martin) <[e-mail]<mailto:[e-mail]>>; Alexandre Petrescu <[e-mail]<mailto:[e-mail]>>; Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Banana] Charter

> 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