Re: [Banana] Charter

[Suresh Krishnan <[e-mail]>]

Hi all,
  I think extreme positions on the suitability of the posted charter (“It is perfect” to “It is worthless”) are not likely going to help moving forward. The idea of putting up the proposed charter for review is to bring out opinions and to modify the charter to make it more widely applicable to a larger community. I am glad that we are having this discussion right now on the list. If you think the charter does not clearly describe a problem to be solved, that is something that certainly needs to be fixed. The best way to fix the charter is by proposing edits (add/modify/delete) and see if the participants in this ML are fine with those changes. Regarding conflicts, once the charter gets sent to me there will be further levels of review to see if the work conflicts with other ongoing IETF work (e.g. in mptcp) during the IESG Internal Review and the external review by the entire IETF community. So I am not very worried about this part. If people feel that writing down a clear problem statement is a way to make progress I am fine with starting with that too as long as the recommendations specified in the IESG statement at

https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html

are understood and followed.

Thanks
Suresh

> On Sep 18, 2017, at 11:58 PM, Zhangmingui (Martin) <[e-mail]> wrote:
> 
> I cannot agree with you more.
> 
> It requires resources to execute a full set of drafts on problem statement, use case, requirements, gap analysis, framework, architecture, applicability etc. I don't think any of them are necessary at this stage. I don’t think it is necessary to step back to work on the problem statement either, since the problem, to me, had already been thoroughly discussed and is clear enough after two BOFs, several bar BOFs and dozens of email discussions. Actually, the charter of the current version neatly describes the problem. I can even see people is developing BANANA solutions. 
> 
> I wish this WG to be a solution-based rather than a issue-based one. Otherwise, I do not expect it to be a productive WG on working protocols out. 
> 
> Thanks,
> Mingui
> 
>> -----Original Message-----
>> From: Margaret Cullen [mailto:[e-mail]]
>> Sent: Tuesday, September 19, 2017 3:19 AM
>> To: Henderickx, Wim (Nokia - BE/Antwerp)
>> Cc: Zhangmingui (Martin); Alexandre Petrescu; [e-mail]
>> Subject: Re: [Banana] Charter
>> 
>> 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
>>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
> 
> _______________________________________________
> Banana mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/banana