Re: [Banana] Charter

[Margaret Cullen <[e-mail]>]

Hi Wim,

I have heard and understand that you do not feel that we should proceed with this work without a (potentially lengthy) process to document the requirements, do gap analysis, etc.  That opinion was raised at the BOF meeting in Prague, as well, where several people said that they did not support going through that sort of process, and our AD, Suresh, told us that he wouldn’t charter this group to go through that sort of process.   At the end of the BOF, when we asked the questions, a large majority of the people who responded indicated that they thought the problem was clear and well understood, and that the charter represented work we should do in the IETF.  I understand that there are a few of you who feel differently, and you are welcome to express your opinions, but I would say that there was a fairly strong agreement of the people in the room in Prague _not_ to change the charter to include a requirements/gap analysis phase, so I am not planning to do so.

Margaret


> On Sep 18, 2017, at 9:42 AM, Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
> Margaret, GRE is one thing, but on top is the deliverables as outlined in the charter.
> 
> In a situation like this we should first do requirements and check gaps with existing protocols to ensure we go down the right direction. Given the scope is specified as multi-operator OTT deployment we need to ensure we understand all these implications.
> 
> Referring to this:
> Milestones
> 	• Apr 2018 Adopt WG draft for provisioning/configuration mechanism
> 	• Apr 2018 Adopt WG draft for signaling protocol
> 	• Apr 2018 Adopt WG draft(s) for tunnel encapsulation(s)
> 	• Feb 2019 WGLC on provisioning/configuration mechanism
> 	• Feb 2019 WGLC on signaling protocol
> 	• Feb 2019 WGLC on tunnel encapsulation(s)
> 	• Aug 2019 Send provisioning/configuration mechanism to the IESG
> 	• Aug 2019 Send signalling protocol to the IESG
> 	• Aug 2019 Send tunnel encapsulation(s) to the IESG
> 
> On 15/09/2017, 17:25, "Margaret Cullen" <[e-mail]> wrote:
> 
> 
>    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) <[e-mail]> 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)" <[e-mail]> 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 [[e-mail]] on behalf of Henderickx, Wim (Nokia - BE/Antwerp) [[e-mail]]
>>   Sent: Thursday, September 14, 2017 0:51
>>   To: [e-mail]
>>   Cc: Alexandre Petrescu; [e-mail]
>>   Subject: Re: [Banana] Charter
>> 
>>   How will you sent GRE through NAT. GRE has no port number
>> 
>>   On 13/09/2017, 17:27, "[e-mail]" <[e-mail]> 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
>>   [e-mail]
>>   https://www.ietf.org/mailman/listinfo/banana
>> 
> 
> 
> 
> 
>