Re: [Banana] [ALU] Re: Charter Text w/Milestones

["Philipp S. Tiesel" <[e-mail]>]

> On 4. Apr 2017, at 00:17, Zhangmingui (Martin) <[e-mail]> wrote:
> 
> Hi Praveen,
> 
> > Hi :
> >    After attending several meetings , I am still NOT sure if there is clarity of right problem statement to charter a WG.  The issue which I have are following.
> 
> > 1. The third party operator offering service of bandwidth aggregation is NOT the case I have so far seen with our customers. That may be use case but is NOT the mainline line use case.  Either the operator offering service is wireline or wireless and is leasing the complementary line from other service provider but the device at home and anchor point of bandwidth aggregation is in control of the operator offering the service. 
>  
> [Mingui] I know “speedify” is an example tool of bandwidth aggregation that is provided by a third party operator. But why there has to be a third party? Is it more of interest that the operator let the BANANA box talk with a remote BANANA box while these two boxes are produced by different vendors?

I think it is generally a good idea to design solutions in a way that they _can_ be operated in a completely distributed fashion by as many parties as there are network elements involved. Merging parties later on is easy, differentiating is difficult.
This comes at cost of complexity, but I think BANANA is still in the "exploring the design space” phase and not in the “cutting complexity” pahse.

> > 4. I know GRE is one solution which was discussed in BANANA meeting and if we have to develop signaling protocol for the tunnel status, then ietf has already produced one which is PMIP . Why not use it.
>  
> [Mingui] From I observed in the past few (at least 3) years, carriers never became interested in rendering a heavy mobile IP stack to be a BANANA solution. The first thing must be done is how to remove 90% of PMIP’s complicated functionalities that are designed for mobile scenarios only.

I don’t see why we should care about this in BANANA: PMIP is complex because of its trust- and mobility model. As long as operator have GTP2 and PMIP as function equivalent choices, there is no motivation for operators to migrate to PIMP. That does not imply anything for BANANA.

> [Mingui] Subsequently, we still have to design missing functionalities, such as per-packet load distribution and the bypassing feature.

We have IFOM in PMIP which allows per-flow load distribution. Extending this to per-packet distribution sounds reasonable to me as it allows to mix per flow and per packet load distribution in a way the you can distribute protocols that are distributable per packet while distributing per flow e.g. for regular TCP.
Bypassing can at least be done by the client by using the COAs / visited network address as source addresses for e.g. MPTCP flows.
 
> [Mingui] You’d better come up with a draft to depict a complete solution before you claim it is usable at all. If you do so, you will soon find out you are repeating the story of GRE tunnel bonding.

We are still in the chartering phase… please keep that in mind.

AVE!
  Philipp S. Tiesel / phils…