Re: [Banana] Charter

[Joerg Deutschmann <[e-mail]>]

Hi,

I'd like to emphasize that there is a actual demand for the bonding of 
satellite and terrestrial links (DSL, cable, LTE, ...). We must go for a 
provider-independent solution, because satellite and terrestrial 
networks are usually run by different operators. Especially branch 
offices or home offices (exchanging all data via a single IPsec tunnel) 
would benefit from a BANANA-like solution. Despite satellite 
connections, I see benefits in the combination of any link type (e.g. 
DSL + cable).

We have dedicated manpower for working on this topic and definitely 
would like to contribute to a BANANA WG (also not only in the context of 
satellite communication).

Best regards,
Joerg



On 18.09.2017 21:43, Sri Gundavelli (sgundave) wrote:
> 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
>