Re: [Banana] Charter

Hi Margaret,

It is not just the question of counting hands in the room, I do not think
that¹s the criteria for ³consensus² determination. We all have been in
IETF long enough and we know that does not mean any thing. Sure, there may
be few excited researchers/students who have no skin in the game to
express interest in the work, but Standardization should have a product
path. Are the key network vendors who have skin in the game have expressed
interest for this work? Is there SDO interest from 3GPP, Wireless or
Broadband guys? Clearly, I do not see that and there is no support for
this work.

Also, many folks asked why there is a need for a new signaling protocol.
When I asked this question, some explicit text was added to say something
along the lines, ³WG will not define a new signaling protocol, unless the
existing protocols do not meet the requirement². I remember Mirja
commenting on that and the chairs editing the text (Mirja can comment if I
am wrong here). But, the below charter text conveniently removed that
entire text and now shows a milestone for the signaling work. So, the work
is getting steered not based on consensus, but on a pre-determined path.

Bottomline, this work has no support. There is no vendor, SDO or operator
interest; we need to have additional discussions. This is a classic case
for IESG Appeal.

‹-
€ Specify a signalling protocol that can be used to send control
information between BANANA Boxes, including:
		€ IP Prefixes of access  links
		€ Information about link status and properties (including congestion)
		€ Information needed by BANANA Encapsulations
		€ Determining which flows are/are not eligible for BANANA Encapsulation
	€ Select (and extend, if necessary) an existing tunneling encapsulation
(e.g. GRE)  for sending traffic between BANANA Boxes.

€ Feb 2019 WGLC on signaling protocol

‹-

Sri

>
Feb 2019 WGLC on signaling protocol

On 9/18/17, 12:18 PM, "Banana on behalf of Margaret Cullen"
<banana-bounces@ietf.org on behalf of mrcullen42@gmail.com> wrote:

>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)
>><wim.henderickx@nokia.com> 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" <mrcullen42@gmail.com> 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)
>>><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
>>> 
>> 
>> 
>> 
>> 
>> 
>
>_______________________________________________
>Banana mailing list
>Banana@ietf.org
>https://www.ietf.org/mailman/listinfo/banana