Re: [Banana] diff (banana load distribution, next-hop selection of multipath)

[Margaret Cullen <[e-mail]>]

> On Feb 4, 2017, at 12:54 PM, Joe Touch <[e-mail]> wrote:
> 
>> So, according to my understanding the goal is to sequence incoming packets and distribute them onto multiple paths (heterogeneous yet multi-hops) in a per-packet manner and then restore their order according to their sequence number. 
> Sure - getting that right is an issue of picking the right algorithm,
> but again that seems like an IRTF issue at this point (unless you're
> just identifying an existing ECMP algorithm, at which point BANANA
> should specify "no new algs”).

For the purpose of this message, I am going to refer to the end points of a BANANA flow as “BANANA Boxes”.  Depending on what solution(s) we develop, these could be bonded tunnel endpoints or proxies.  I am sure we can come up with a better name for these things when we write any sort of architecture/solution documents, but I am failing to come up with a better name at the moment.

I think we could/should specify:  how the traffic is sent between the “BANANA Boxes” (addressing, ports, encapsulations, etc.), how traffic is recombined into a single flow on the remote end, and any signaling that is needed between the “BANANA Boxes” (for channel set-up, flow control, etc.).  I think those are the things that need to be standardized in order for BANANA-aware CPE from multiple vendors to talk to a centralized “BANANA Box” (or perhaps to BANANA-aware CPE boxes on the other end), which is something that real-life vendors have indicated an interest in being able to do.

Personally, I would consider algorithms that run within a single box to decide whether to aggregate a particular flow, or how to distribute traffic between the local access links, to be implementation-specific.  This is an area where one vendor could differentiate from another, by coming up with algorithms that provide better performance, faster failover, or the like.  

Margaret