Re: [Banana] Charter

["Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>]

Also on the encapsulation we probably need to look for options and see what would be the recommended choice.
In NVO3 they spent quite a bit of time on this to decide what to do and recommend something based on what we have available in IETF.

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.

On 17/07/2017, 17:07, "Banana on behalf of Alexandre Petrescu" <[e-mail] on behalf of [e-mail]> wrote:

    Mic: for the encapsulation methods.
    
    IP encapsulation can mean to add another IP header similar to the 
    original, or to add another header like a Routing Header, or to add 
    another non-IP header.
    
    There are many encapsulation methods at IETF and some other outside of 
    IETF (e.g. GTP at 3GPP).  People also work new encapsulation methods at 
    IETF like "skinny encap" in 6man WG.
    
    There could be a means between BANANA Local box and BANANA Remote box to 
    negotiate that method of "encapsulation", and maybe default to some 
    value such as "Generic Encapsulaiton"
    
    Alex
    
    Le 17/07/2017 à 16:54, Alexandre Petrescu a écrit :
    > 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 <[e-mail]> 
    >>> 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 <[e-mail]> 
    >>>> 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:[e-mail]] On Behalf Of Flinck, 
    >>>> Hannu (Nokia - FI/Espoo)
    >>>> Sent: May 26, 2017 07:23 AM
    >>>> To: Juliusz Chroboczek <[e-mail]>
    >>>> Cc: Margaret Cullen <[e-mail]>; [e-mail]
    >>>> 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:[e-mail]]
    >>>> Sent: Friday, May 26, 2017 11:54 AM
    >>>> To: Flinck, Hannu (Nokia - FI/Espoo) <[e-mail]>
    >>>> Cc: Margaret Cullen <[e-mail]>; [e-mail]
    >>>> 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
    >>>> [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
    >>
    > 
    > _______________________________________________
    > Banana mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/banana
    > 
    
    _______________________________________________
    Banana mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/banana