Re: [Banana] Charter

Given the concerns about GRE and NATs, perhaps it would make sense to remove the explicit mention of GRE from the charter and add some wording about traversal of NATs and other middle boxes?  Maybe something along these lines?

OLD:
The Bandwidth Aggregation solutions developed in this group will be designed to work in multi-provider scenarios (i.e. they will not depend on all of the aggregated links being provided by a single Internet access provider).

NEW:  
The Bandwidth Aggregation solutions developed in this group will be designed to work in multi-provider scenarios (i.e. they will not depend on all of the aggregated links being provided by a single Internet access provider, and they will be designed to work across NATs and other middle boxes, as needed).

OLD:
Select (and extend, if necessary) an existing tunneling encapsulation (e.g. GRE)  for sending traffic between BANANA Boxes.

NEW:
Select (and extend, if necessary) an existing tunneling encapsulation for sending traffic between BANANA boxes.

Do people think these changes would be an improvement to the existing charter text?  If there are no objections over the next few days, I will make these changes to the online charter text.

Margaret

> On Sep 15, 2017, at 12:39 AM, Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com> wrote:
> 
> The issue I have here is the following. We are chartering a new WG to solve a certain problem.
> The charter already hints to GRE while we have not understood the requirements and have looked at what the best solution would be to accommodate these requirements. The environment in the charter is multi-operator, which means we will have to deal with NAT in multiple ways as long as we intend to use v6.
> 
> So, the issue I have with the charter in general is that we are trying to define a protocols/signalling extensions, while we have not understood the requirements and have done a gap analysis regarding this. The first thing that should happen is look at the requirements and more importantly look at the algorithms we would need to accommodate these requirements. After do gap analysis for the existing protocols and then define the potential extensions. In the last step we should even see if other WG are not already suited to handle this activity.
> 
> On 14/09/2017, 07:07, "Zhangmingui (Martin)" <zhangmingui@huawei.com> wrote:
> 
>    Hi Alex,
> 
>    If "GRE passthrough NAT" was proved to be really required, there are two options:
>    1. GRE in UDP while the UDP provides you the port number.
>    2. The GRE Key field to be used to carry the port number. 
>    For the second option, there are some existing implementations. But it is not an option if the Key field has already used for other purpose, e.g., security.
> 
>    However, I would say the popular usage is that the NAT happens just before the GRE tunnel. Why do we have to insert a NAT device in between two GRE tunnel endpoints?
> 
>    Thanks,
>    Mingui
> 
>    ________________________________________
>    From: Banana [banana-bounces@ietf.org] on behalf of Henderickx, Wim (Nokia - BE/Antwerp) [wim.henderickx@nokia.com]
>    Sent: Thursday, September 14, 2017 0:51
>    To: mrcullen42@gmail.com
>    Cc: Alexandre Petrescu; banana@ietf.org
>    Subject: Re: [Banana] Charter
> 
>    How will you sent GRE through NAT. GRE has no port number
> 
>    On 13/09/2017, 17:27, "mrcullen42@gmail.com" <mrcullen42@gmail.com> wrote:
> 
>        Hi Wim,
> 
>        Sent from my iPhone
> 
>> If I hear GRE as a proposal it is very NAT unfriendly and the solution need to work across multiple providers, so this is an important consideration.
> 
>        Sorry, I somehow dropped this thread while I was in vacation...
> 
>        Why do you think that (all) GRE-based proposal(s) would be NAT unfriendly?
> 
>        Margaret
> 
> 
>    _______________________________________________
>    Banana mailing list
>    Banana@ietf.org
>    https://www.ietf.org/mailman/listinfo/banana
> 