Re: [Banana] Updated Charter

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

We can make very  general statements that MIP is not designed for this, or that and so lets do some thing new. But, we all are very technical people and I hope to see these statements backed by technical data and with detailed analysis. Otherwise, these comments may not mean any thing.

If MIP has lot of options and capabilities, and one does not understand, we should have discussions on that and not charter a WG and define a new protocol. The amount of work that went in Multihoming, IFOM, Security ..etc is not a small effort.  Vendors have deployed solutions and so IETF should have reasons to define alternatives that do the same thing.

Sri



From: Margaret Cullen <[e-mail]<mailto:[e-mail]>>
Date: Thursday, September 28, 2017 at 1:41 PM
To: Microsoft Office User <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Banana] Updated Charter


On Sep 28, 2017, at 4:03 PM, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> wrote:

> The downside is that they are all proprietary, so they don't work _together_.

The list I gave is a set of features supported today based on MIP RFC standards.

I can see how (some of) the MIP technology could apply to (parts of) this problem space in interesting ways.  However, MIP (as it exists in the RFCs I have read, and presumably in most implementations) has several properties that don't seem like a great fit for a the BANANA problem statement, including:

1) It is focused on mobility, not load balancing, and these aren't inherently the same thing.  While I can see how you could repurpose some of MIP's mechanisms for load balancing, I don't see how you could use an arbitrary RFC-compliant implementation for this purpose without modifications.
2) It is flow-based.  I didn't see any mechanism for recognizing that a single flow has been split across multiple paths, and recombining that flow before forwarding it to the final destination.
3) Its security model seems to rely on the notion that the destination node and the Home Agent are under the same administrative control.  Maybe RFC 6618 will change my mind about this - I will read it.
4) The home agent is on the "home network" of the destination, not necessarily on the network where the destination is currently located...  I think that bandwidth aggregation needs to have one endpoint on the local network with the end-node, so that it can detect that there is more than one local link to aggregate.  However, even if there was a home agent locally, I am not sure how/if a MIP end-node would find it and associate with it.

It is possible that I am missing something, but if so, then it is very likely that other people are missing it, too.  If you want us to decide that there is no need to specify a flow-based bandwidth aggregation mechanism because MIP already does that, I think you would need to do something to explain _how_ MIP already does that, because it isn't obvious.

Margaret