Re: [Banana] Reaching Consensus on Problem Statement

[Margaret Cullen <[e-mail]>]

Hi Joe,

> On Feb 6, 2017, at 2:12 PM, Joe Touch <[e-mail]> wrote:
> 
> On 2/4/2017 1:00 PM, Alan Ford wrote:
>> One observation is that I think it is implied that this requires some
>> kind of device in the network to assist with these scenarios (since
>> otherwise end-to-end MPTCP would solve most of this for stream-based
>> transports), but this is not stated.
> 
> It seems like it requires *two* such devices (tunnel endpoints) to make
> this work.
> 
> The point is that you're essentially hiding dynamic multipath routing
> inside what looks like a tunnel (which looks like a link).
> 
> I.e., this is really just a recursive router (of which LISP is one
> example) with two edge devices.

Yes.  The things I think we can standardize here are how the two devices (securely) communicate, how data is encapsulated between them, what traffic they should bypass, and how they should transform packets on ingress/egress so that they are transparent to non-multi-access-aware end-nodes.  In other words, the things that would need to be standardized for the devices on the two ends of a single BANANA connection to be manufactured by different vendors.

One interesting thing to consider is that there will be two devices involved for any one flow, but if we envision a solution to the end-to-end scenario described in the BOF, the two devices might be two CPE devices, in which case the CPE device in a home with more than one flow might have BANANA connections to more than one remote device, up to one per flow.  This scenario is not covered by any of the current solution proposals, but some of them could be (fairly easily?) extended to cover it.

> There are other considerations, e.g., this has more potential impact on
> reordering and less problems with egress determination for new flows
> (since there's only one egress in each direction), but there might be
> useful similarities to consider, FWIW.

Yes, I agree.

Margaret