Re: [Banana] Charter

[Margaret Cullen <[e-mail]>]

Hi Sri,

Thinking about this message, I think the real answer to your question lies at a much higher level than the answers I gave…

We are talking about two different things here, one that is being done in the BBF, and the other of which is proposed in the BANANA BOF:

(1)  The BBF is (as I understand it) working on a DSL/5G-specific solution that requires cooperation from a customer's Internet service provider(s).

and

(2) The BANANA group is talking about an IP-based, link-layer-independent solution that does not require explicit cooperation from any Internet service provider.

These things both sound awesome to me, and I think the world should have both of them!  They are very different things, and people will use them in different situations for different reasons.  

#1 lets providers, or cooperating groups of providers, give their BBF/5G customers faster and better service, without the need for the customer to understand the solution or contract for a third-party service.

#2 allows an end user to gain, or a third-party aggregation service provider to provide, faster and better service by aggregating whatever links the customer has available. without the explicit cooperation of the customer’s Internet service providers.

In BANANA, we would be defining a solution that can be used by whoever chooses to run it (or whoever contracts with a third-party to run it).  It is not desirable (or even technically practical) for a BANANA implementation to determine if it is being run by an end-user, a third-party service provider, or an Internet service provider, and there is certainly no good way to tell whether it is running over two links from the same service provider.  You also don’t want to detect the link types and refuse to run if one the links supports 5G, or if one of the links is DSL…  I don’t think any of us, including the BBF or 3GPP, would want that.

What we should do is coordinate with the BBF to ensure that customers will not run into problems if they do try to run the BANANA solution over a set of links that includes links with the BBF/5G solution enabled.  We can’t know what the best approach would be to avoid any problems, until we know a lot more about both solutions, but pertinent question might be whether the BANANA software can detect that the BBF/5G bonding is in place, and if so, whether BANANA would treat a set of bonded BBF/5G links as separate links for the purposes of BANANA, or as a single link.  These are things I think it would be important for the BANANA WG and the folks working on the BBF/5G solution to keep in mind going forward, and to communicate about in more detail as we know more about the two solutions.

Margaret


> On Sep 22, 2017, at 1:24 PM, Margaret Cullen <[e-mail]> wrote:
> 
>>> Actually, there are quite a few people who have indicated that they would
>>> like to aggregate other link types.  There was a presentation at IETF-97
>>> about aggregating LTE and Wifi, one person on this thread mentioned
>>> wanted to aggregate two WiFi links, another person has talked about
>>> aggregating VPN links. etc.
>>> 
>> 
>> So, LTE and DSL are out;  WiFi as a WAN link to home is not a known
>> service; SATRAN access to home is unheard of.
>> 
>> So, what are the two remaining links that are not WiFi, LTE, DSL, SATRAN
>> and not aggregation?
> 
> I don’t understand this message…
> 
> You made a statement that DSL/LTE was the only motivator for this work, and it would be solved by a BBF/5G layer-two solution.  I indicated that there also people who have stated that they want to aggregate non-BBF, or non-5G link types.  I didn’t say anything was out, and I don’t know what “two remaining links” you are talking about.  
> 
> The solutions we have been discussing in BANANA are IP-based link-layer-independent solutions.  We wouldn’t be ruling any link types in or out…
> 
> Margaret
> 
> 
> _______________________________________________
> Banana mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/banana