Re: [Banana] Charter

[<[e-mail]>]

Dear all,

> 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.

At this point I can tell you that there is an operator interest to work on it. As we have a running solution, we had and have dialogs with several operators in Europe. I would say that there is a need to develop something like BANANA.

The interest from all parties to support BBF was very high to define the "Hybrid Access Broadband Network architecture" TR-348. That should also give us hints that there is a potential interest on the BANANA topic.

Cornelius 

Deutsche Telekom Technik GmbH 
Fixed Mobile Engineering Deutschland 
Cornelius Heidemann
 
www.telekom.de    
Erleben, was verbindet.  
Die gesetzlichlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtangaben-dttechnik


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"
<[e-mail] on behalf of [e-mail]> 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) 
>><[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

_______________________________________________
Banana mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/banana