Re: [Banana] Charter Text w/Milestones

Alexandre Petrescu <alexandre.petrescu@gmail.com> Mon, 17 July 2017 14:54 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: banana@ietfa.amsl.com
Delivered-To: banana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211E6131C41 for <banana@ietfa.amsl.com>; Mon, 17 Jul 2017 07:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeRXH7RX8T_C for <banana@ietfa.amsl.com>; Mon, 17 Jul 2017 07:54:53 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74C01200FC for <banana@ietf.org>; Mon, 17 Jul 2017 07:54:52 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v6HEsor4061889 for <banana@ietf.org>; Mon, 17 Jul 2017 16:54:50 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BEAD920512A for <banana@ietf.org>; Mon, 17 Jul 2017 16:54:50 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B45F3205035 for <banana@ietf.org>; Mon, 17 Jul 2017 16:54:50 +0200 (CEST)
Received: from [132.166.84.54] ([132.166.84.54]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6HEsn9Y028220 for <banana@ietf.org>; Mon, 17 Jul 2017 16:54:50 +0200
To: banana@ietf.org
References: <96A7BC33-FB64-487A-A60D-7AB8504C9DDF@gmail.com> <a1df884a51f246a7969c0057ff78d807@BTWP000357.corp.ads> <C3A4BFB9-EAD7-4B32-90C1-248D6D74ECD1@gmail.com> <9A767D1D-C6CA-4C7D-A281-7150E259881D@gmail.com> <DB5PR07MB13998EE07C5B5D5DBACED79C9B1A0@DB5PR07MB1399.eurprd07.prod.outlook.com> <7ED94797-5E72-4191-B861-4CD2F410BBD5@gmail.com> <7i60gox0c8.wl-jch@irif.fr> <DB5PR07MB1399FEDB262E0205457EA8AB9BFC0@DB5PR07MB1399.eurprd07.prod.outlook.com> <87bmqgov69.wl-jch@irif.fr> <DB5PR07MB1399977AFFE9FA7D19A2D34D9BFC0@DB5PR07MB1399.eurprd07.prod.outlook.com> <0d8ce583860345b89020113f1239be5d@BTWP000357.corp.ads> <21BD0F20-9CE5-466B-992E-93F6D84DB7D4@gmail.com> <95788B92-E8C1-4FE6-9B0C-7F29361D9297@trammell.ch>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <d3759d89-9f6e-bcf4-8c44-32f3f435d784@gmail.com>
Date: Mon, 17 Jul 2017 16:54:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <95788B92-E8C1-4FE6-9B0C-7F29361D9297@trammell.ch>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/bGF7b8wswkb_YIFEpa5qP-S_Yf0>
Subject: Re: [Banana] Charter Text w/Milestones
X-BeenThere: banana@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Bandwidth Aggregation for interNet Access: Discussion of bandwidth aggregation solutions based on IETF technologies." <banana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/banana>, <mailto:banana-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/banana/>
List-Post: <mailto:banana@ietf.org>
List-Help: <mailto:banana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/banana>, <mailto:banana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jul 2017 14:54:59 -0000

Mic: you want the Banana configuration protocol to also communicate the 
IP Prefixes of the internal link (i.e. the IP prefix of the "internal" 
link, or the IP prefix on the home links) between the Banana boxes.

Overall, the BANANA signalling protocol should communicate the following:
- the IP addresses of the BANANA Local box (DSL box) and of the BANANA
   Remote box
- the IP addresses of the virtual interfaces (if any) situated  on the
   BANANA Local and BANANA Remote
- maybe the prefix lengths of these addresses
- the IP Prefixes of the link(s) behind the BANANA local (home network),
   because you want the BANANA Local box to serve a network, it's not
   just for itself.

It's not sufficient in the charter to just say "IP Prefixes".

Alex

Le 26/05/2017 à 17:26, Brian Trammell (IETF) a écrit :
> +1 to "banana box" is fine, but perhaps since in my milieu 90% of the time is spent looking at boxes on whiteboards and 10% of the time is spent messing around with experimental infrastructure... most of which runs on VM images we call
> 
> ( +2 to "banana box" because it is much more satisfying in bikeshed discussions to ask "what color should the banana box be?" )
> 
> Cheers,
> 
> B
> 
> 
> 
>> On 26 May 2017, at 16:46, Margaret Wasserman <margaretw42@gmail.com> wrote:
>>
>> The charter is not a protocol specification.  We used the term "BANANA box" specifically to avoid specifying whether it was a service or a function, a router or a proxy, a piece of hardware or software, etc.  I was picturing a "box" in the sense of the "boxes and arrows" in an architectural diagram.  A "box" that, in turn, contains a BANANA signaling protocol and a BANANA encapsulation.
>>
>> Presumably in each of the "encapsulations", the BANANA Box will have a more specific name like "GRE tunnel endpoint", or "MPTCP proxy", etc.
>>
>> Personally I consider a GRE tunnel endpoint to perform a decapsulation _function_, while an MPTCP proxy provides a proxy _service_. So, in my lexicon (which may not match yours), neither "service" nor "function" covers all of the possibilities.
>>
>> Margaret
>>
>>> On May 26, 2017, at 9:09 AM, Jordan Melzer <Jordan.Melzer@telus.com> wrote:
>>>
>>> "Function" means an activity or purpose of an object.  It's used widely outside of computing and networking (eg, biology and medicine).  One can make reasonable sentences with the word function.  Eg: "The gateway may perform the BANANA function in addition to its other duties."  "The brain is responsible for any number of vital physiological functions."
>>>
>>> "Box" means a container with a flat bottom.  Computer servers have sometimes been called boxes because they are shaped like boxes and many operating systems end in "X", making for nice ear-worms: eg VAX box, UNIX box, Linux box.  Similarly, we are only having this discussion because BANANA box sounds good.  If there weren't a "B" in BANANA, nobody would want to use BANANA box.  Box makes no sense -- one thinks of a yellow box with bananas inside it -- but it is fun to say.  If we're good with BANANA, though, it's hard to argue that "box" is the problem!
>>>
>>> I don't really care what anyone calls it.  As long as there is CMT-SCTP or some other mostly-baked solution hidden somewhere in the pile of bananas, I'm good.
>>>
>>> -----Original Message-----
>>> From: Banana [mailto:banana-bounces@ietf.org] On Behalf Of Flinck, Hannu (Nokia - FI/Espoo)
>>> Sent: May 26, 2017 07:23 AM
>>> To: Juliusz Chroboczek <jch@irif.fr>
>>> Cc: Margaret Cullen <margaretw42@gmail.com>; banana@ietf.org
>>> Subject: Re: [Banana] Charter Text w/Milestones
>>>
>>> I disagree. This term is all over in the IETF documents. It is not limited to any particular wg as such.
>>> Please have a look at for example:
>>>
>>> https://tools.ietf.org/html/draft-wu-opsawg-service-model-explained-05
>>>
>>> Service Function Chaining (SFC) Architecture
>>> https://tools.ietf.org/html/rfc7665#page-15
>>>
>>> and the whole set of documents from the sfc wg.
>>>
>>> Problem Statement: Overlays for Network Virtualization uses term functionality, not "boxes"
>>> https://www.rfc-editor.org/rfc/rfc7364.txt
>>> Overlay gateway functionality could be combined with other network
>>>   functionality into a network device that implements the overlay
>>>   functionality and then forwards traffic between other internal
>>>   components that implement functionality such as full router service,
>>>   load balancing, firewall support, VPN gateway, etc.
>>>
>>> Can you show the otherwise?
>>>
>>> - Hannu
>>>
>>> -----Original Message-----
>>> From: Juliusz Chroboczek [mailto:jch@irif.fr]
>>> Sent: Friday, May 26, 2017 11:54 AM
>>> To: Flinck, Hannu (Nokia - FI/Espoo) <hannu.flinck@nokia-bell-labs.com>
>>> Cc: Margaret Cullen <margaretw42@gmail.com>; banana@ietf.org
>>> Subject: Re: [Banana] Charter Text w/Milestones
>>>
>>>>> I agree, the specific term "function" is specific to a fairly
>>>>> specific community.
>>>
>>>> Well, the specific community seems to be networking community. Don't
>>>> you agree?
>>>
>>> No, it's very specific to a certain culture.  Other cultures would use different terms -- the Iron Age "Seven Layers" culture would say "BANANA Service", the Broze Age "Internet" culture would say "BANANA Protocol", while the Neolithic "ARPANET" culture would say "BANANA Program".
>>>
>>> -- Juliusz
>>>
>>> _______________________________________________
>>> 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
> 
> 
> 
> _______________________________________________
> Banana mailing list
> Banana@ietf.org
> https://www.ietf.org/mailman/listinfo/banana
>