Subject: Re: [Banana] [ALU] Re: Charter Text w/Milestones

From: "Muley, Praveen (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 3 Apr 2017 18:24:58 +0000

Hi :
   After attending several meetings , I am still NOT sure if there is clarity of right problem statement to charter a WG.  The issue which I have are following.

1. The third party operator offering service of bandwidth aggregation is NOT the case I have so far seen with our customers. That may be use case but is NOT the mainline line use case.  Either the operator offering service is wireline or wireless and is leasing the complementary line from other service provider but the device at home and anchor point of bandwidth aggregation is in control of the operator offering the service. 

2. If the above case is something broadband forum is discussing with 3GPP , then we SHOULD first understand what pieces 3GPP will address and what will remain in ietf before we making any assumptions and starting the work.

3. Generally adding more encapsulations at layer 3 we should consider carefully especially in case of third party offering service as some of the wireless networks already have overhead of carrying huge tunnel overhead plus just for the third party operator the wireless operator is NOT going to change MTU on its S5/S8  and s1-u networks.  Also entropy is another reason why MP-TCP or MP-UDP/ MP-QUIC  might turn out to be better solutions.

4. I know GRE is one solution which was discussed in BANANA meeting and if we have to develop signaling protocol for the tunnel status, then ietf has already produced one which is PMIP . Why not use it.

-Praveen

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
Sent: Thursday, March 30, 2017 10:56 AM
To: Jordan Melzer <[email-masked]>
Cc: Mirja Kuehlewind <[email-masked]>; Suresh Krishnan <[email-masked]>; [email-masked]
Subject: [ALU] Re: [Banana] Charter Text w/Milestones
Importance: Low

Perhaps it would make sense to write this charter in way that only references what this specific WG will do (choose one encapsulation, define a discovery/config mechanism, define a signaling protocol), and then do a minor re-charter to include adapting the signaling protocol to work with an MPTCP Proxy-based BANANA encapsulation if/when the MPTCP WG is chartered to produce one?  (And the same for any other group that produces one, I guess).

Thoughts?

Margaret

> On Mar 30, 2017, at 12:51 PM, Margaret Cullen <[email-masked]> wrote:
> 
> 
> The ambiguity may be cleared up if/when we know what is happening in 
> MPTCP.  The idea is that the BANANA group will define an encapsulation to tunnel packets between BANANA Boxes.  It is also possible that the MPTCP WG will define a “BANANA Encapsulation” using MPTCP proxies on both ends.  If there is more than one encapsulation, we would still like to have a single signaling protocol to communicate link information and status, as well as any signaling needed by the encapsulations.
> 
> Does that make sense?  How do you think I could make that clearer without this charter talking too specifically about what another WG may or may not do?
> 
> Margaret
> 
>> On Mar 30, 2017, at 12:06 PM, Jordan Melzer <[email-masked]> wrote:
>> 
>> Thanks, Margaret.
>> 
>> The proposed text sometimes uses singular and sometimes uses plural when referring to encapsulation(s).  I am not sure if the goal is to arrive at one encapsulation or many, and if BANANA will define the negotiation.  If some of the encapsulations don’t fully meet BANANA's goals, will BANANA still allow them to be negotiated?  If the goal is a single encapsulation, is there consensus that a single encapsulation that meets all needs is likely through minor extensions of existing encapsulations?
>> 
>> 
>> -----Original Message-----
>> From: Banana [mailto:[email-masked]] On Behalf Of Margaret 
>> Cullen
>> Sent: March 30, 2017 12:10 PM
>> To: [email-masked]
>> Cc: Mirja Kuehlewind; Suresh Krishnan
>> Subject: [Banana] Charter Text w/Milestones
>> 
>> Here is the (wordsmithed) charter text from last night.  I have also added milestones.
>> 
>> At this point, the text attempts to be neutral about the subject of whether there will be an MPTCP encapsulation (presumably done in the MPTCP WG) or not.  We might want to update the text based on the outcome of today’s MPTCP meeting if there is any clear conclusion.
>> 
>> Thoughts?  Comments?
>> 
>> Any feedback will be appreciated!
>> 
>> Margaret
>> 
>> The BANdwidth Aggregation for Network Access (BANANA) Working Group is chartered to develop solution(s) to support dynamic path selection on a per-packet basis in networks that have more than one point of attachment to the Internet.
>> 
>> Bandwith Aggregation consists of splitting local traffic across multiple Internet links on a per-packet basis, including the ability to split a single flow across multiple links when necessary.
>> 
>> It is the goal of this WG to produce a Bandwidth Aggregation solution that will provide the following benefits:
>> 
>> - Higher Per-Flow Bandwidth: Many Internet links available to homes 
>> and small offices (DSL, Cable, LTE, Satellite, etc.) have relatively 
>> low bandwidth.  Users may wish to run applications (such as streaming 
>> video, or content up/downloads) that require (or could benefit from) 
>> more bandwidth for a single traffic flow than is available on any of 
>> the local links.  A Bandwidth Aggregation solution could supply the 
>> needed bandwidth by splitting a single traffic flow across multiple 
>> Internet links.
>> 
>> - Reduced Cost: Traffic sharing on a per-packet basis allows the full 
>> bandwidth of the lowest-cost link to be used first, only using a 
>> higher-cost link when the lowest-cost link is full.
>> 
>> - Increased Reliability: When one Internet link goes down, ongoing 
>> application flows can be moved to another link, preventing service 
>> disruption.
>> 
>> Proposed BANANA solutions use different approaches (e.g. tunnels, proxies, etc.) to split and recombine traffic, but at an abstract level, they involve a local (hardware or software) component on the multi-access network, a remote component within the Internet, and mechanisms for those components to find each other, exchange signalling information, and direct traffic to each other.  We refer to these functional components as the Local and Remote "BANANA Boxes", and we refer to the method they use to direct traffic to each other as a "BANANA Encapsulation".
>> 
>> The Bandwidth Aggregation solutions developed in this group will work whether the attached links are provided by a single Internet Service Provider or multiple Providers.
>> 
>> The BANANA WG will have the following work items:
>> 
>> - Determine how Local and Remote BANANA Boxes find each other.
>> 
>> - Specify a signalling protocol that can be used to send 
>> configuration and control information between BANANA boxes, including:
>>   -  IP Prefixes of local links
>>   -  Information about link properties & status
>>   -  Information needed by the encapsulations
>> 
>> - Select (and extend, if necessary) an existing tunneling 
>> encapsulation for sending traffic between BANANA Boxes.
>> 
>> - Work with other IETF WGs defining BANANA encapsulations (if any) to 
>> ensure that the discovery mechanism and signalling protocol will meet 
>> their needs.
>> 
>> BANANA Boxes will determine if a specific flow is eligible for Bandwith Aggregation. If a flow is not eligible, it will not be split across multiple attached links.
>> 
>> For this initial charter, we will focus on how Local BANANA Boxes communicate with Remote BANANA Boxes.  We will not address the topic of cooperation between multiple Local BANANA Boxes.
>> 
>> MILESTONES
>> (Assumes WG Chartering by May 2017)
>> Dec 2017 Adopt WG draft for discovery/configuration mechanism Dec 
>> 2017 Adopt WG draft for signalling proocol Dec 2017 Adopt WG draft 
>> for tunnel encapsulation Oct 2018 WGLC on discovery/configuration 
>> mechanism Oct 2018 WGLC on signalling protocol Oct 2018 WGLC on 
>> tunnel encapsulation Apr 2019 Send discovery/configuration mechanism 
>> to the IESG Apr 2019 Send signalling protocl to the IESG Apr 2019 
>> Send tunnel encapsulation to the IESG
>> 
>> _______________________________________________
>> Banana mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/banana
>> _______________________________________________
>> Banana mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/banana
> 

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

---

From: "Zhangmingui (Martin)" <[email-masked]>
Date: Mon, 3 Apr 2017 22:17:49 +0000

Hi Praveen,

> 1. The third party operator offering service of bandwidth aggregation is NOT the case I have so far seen with our customers. That may be use case but is NOT the mainline line use case.  Either the…

[Mingui] I know “speedify” is an example tool of bandwidth aggregation that is provided by a third party operator. But why there has to be a third party? Is it more of interest that the operator let the BANANA box talk with a remote BANANA box while these two boxes are produced by different vendors?

> 2. If the above case is something broadband forum is discussing with 3GPP , then we SHOULD first understand what pieces 3GPP will address and what will remain in ietf before we making any assumptio…

[Mingui] No, BBF is talking about single-operator Hybrid Access rather than the third party operator problem.

[Mingui] Both tunnel based and MPTCP based BANANA solutions choose IETF from the first day. If there might be any conflict between the two SDOs, we could normally handle them through liaison.

> 3. Generally adding more encapsulations at layer 3 we should consider carefully especially in case of third party offering service as some of the wireless networks already have overhead of carrying…

[Mingui] We’ve already seen the mass deployment of tunnel based BANANA solution. The issues of MTU, entropy, etc are not challenging issues for tunneling techniques at all.

[Mingui] It’s not healthy to argue MP based solutions are better than tunnel based solutions or vice versa. Both kinds have their own problems to solve.

> 4. I know GRE is one solution which was discussed in BANANA meeting and if we have to develop signaling protocol for the tunnel status, then ietf has already produced one which is PMIP . Why not us…

[Mingui] From I observed in the past few (at least 3) years, carriers never became interested in rendering a heavy mobile IP stack to be a BANANA solution. The first thing must be done is how to remove 90% of PMIP’s complicated functionalities that are designed for mobile scenarios only. Subsequently, we still have to design missing functionalities, such as per-packet load distribution and the bypassing feature. You’d better come up with a draft to depict a complete solution before you claim it is usable at all. If you do so, you will soon find out you are repeating the story of GRE tunnel bonding.

Thanks,
Mingui

________________________________________
From: Banana [[email-masked]] on behalf of Muley, Praveen (Nokia - US/Mountain View) [[email-masked]]
Sent: Tuesday, April 04, 2017 2:24
To: Margaret Cullen
Cc: Mirja Kuehlewind; Suresh Krishnan; [email-masked]
Subject: Re: [Banana] [ALU] Re:  Charter Text w/Milestones

Hi :

-Praveen

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
Sent: Thursday, March 30, 2017 10:56 AM
To: Jordan Melzer <[email-masked]>
Cc: Mirja Kuehlewind <[email-masked]>; Suresh Krishnan <[email-masked]>; [email-masked]
Subject: [ALU] Re: [Banana] Charter Text w/Milestones
Importance: Low

Thoughts?

Margaret

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Tue, 4 Apr 2017 11:40:08 +0200

> On 4. Apr 2017, at 00:17, Zhangmingui (Martin) <[email-masked]> wrote:
> 
> Hi Praveen,
> 
> > Hi :

I think it is generally a good idea to design solutions in a way that they _can_ be operated in a completely distributed fashion by as many parties as there are network elements involved. Merging parties later on is easy, differentiating is difficult.
This comes at cost of complexity, but I think BANANA is still in the "exploring the design space” phase and not in the “cutting complexity” pahse.

> [Mingui] From I observed in the past few (at least 3) years, carriers never became interested in rendering a heavy mobile IP stack to be a BANANA solution. The first thing must be done is how to remove 90% of PMIP’s complicated functionalities that are designed for mobile scenarios only.

I don’t see why we should care about this in BANANA: PMIP is complex because of its trust- and mobility model. As long as operator have GTP2 and PMIP as function equivalent choices, there is no motivation for operators to migrate to PIMP. That does not imply anything for BANANA.

> [Mingui] Subsequently, we still have to design missing functionalities, such as per-packet load distribution and the bypassing feature.

We have IFOM in PMIP which allows per-flow load distribution. Extending this to per-packet distribution sounds reasonable to me as it allows to mix per flow and per packet load distribution in a way the you can distribute protocols that are distributable per packet while distributing per flow e.g. for regular TCP.
Bypassing can at least be done by the client by using the COAs / visited network address as source addresses for e.g. MPTCP flows.
 
> [Mingui] You’d better come up with a draft to depict a complete solution before you claim it is usable at all. If you do so, you will soon find out you are repeating the story of GRE tunnel bonding.

We are still in the chartering phase… please keep that in mind.

AVE!
  Philipp S. Tiesel / phils…

---

From: "Muley, Praveen (Nokia - US/Mountain View)" <[email-masked]>
Date: Tue, 4 Apr 2017 17:48:37 +0000

Hi Mingui :

From: Banana [mailto:[email-masked]] On Behalf Of Zhangmingui (Martin)
Sent: Monday, April 03, 2017 3:18 PM
To: Muley, Praveen (Nokia - US/Mountain View) <[email-masked]>; Margaret Cullen <[email-masked]>
Cc: Mirja Kuehlewind <[email-masked]>; Suresh Krishnan <[email-masked]>; [email-masked]
Subject: [ALU] Re: [Banana] [ALU] Re: Charter Text w/Milestones
Importance: Low

Hi Praveen,

> 1. The third party operator offering service of bandwidth aggregation is NOT the case I have so far seen with our customers. That may be use case but is NOT the mainline line use case.  Either the…

[Mingui] I know "speedify" is an example tool of bandwidth aggregation that is provided by a third party operator. But why there has to be a third party? Is it more of interest that the operator let the BANANA box talk with a remote BANANA box while these two boxes are produced by different vendors?

PM >> It will be more important to clarify the exact use case so that there is no overlap with other SDO.

PM >>     I thought broadband forum has done all the work in terms of requirement for the use cases of hybrid access. If we are saying we want to address the case which is NOT addressed by broadband forum then we SHOULD definitely see is there larger interest of community to solve that use case ?   My point here is if broadband forum already agreed to work with 3GPP then can we identify the exact piece that can be addressed in ietf .
                                               Had the MP-TCP proxy work or PMIP work NOT  been adopted by respective WG , it would have made  larger case. However as these solutions are progressing in respective working group I am NOT sure if there is larger chunk of work left to justify formation of new WG.

> 3. Generally adding more encapsulations at layer 3 we should consider carefully especially in case of third party offering service as some of the wireless networks already have overhead of carrying…

[Mingui] We've already seen the mass deployment of tunnel based BANANA solution. The issues of MTU, entropy, etc are not challenging issues for tunneling techniques at all.

PM >> This NOT technical complexity but more of operational complexity an d to make it work with existing networks.

[Mingui] It's not healthy to argue MP based solutions are better than tunnel based solutions or vice versa. Both kinds have their own problems to solve.

PM >>  Whether we like or NOT MP-solutions are solving the FAT flow issues and seems like complementing them with tunnel based or non-tunnel based solutions addressed the overall use case. Given that one definitely needs to ask is there a need for another  solution whose standards are NOT yet defined.

> 4. I know GRE is one solution which was discussed in BANANA meeting and if we have to develop signaling protocol for the tunnel status, then ietf has already produced one which is PMIP . Why not us…

[Mingui] From I observed in the past few (at least 3) years, carriers never became interested in rendering a heavy mobile IP stack to be a BANANA solution. The first thing must be done is how to remove 90% of PMIP's complicated functionalities that are designed for mobile scenarios only. Subsequently, we still have to design missing functionalities, such as per-packet load distribution and the bypassing feature. You'd better come up with a draft to depict a complete solution before you claim it is usable at all. If you do so, you will soon find out you are repeating the story of GRE tunnel bonding.

PM >>  I partially agree with you on complexities of PMIP on the signaling overhead of state maintenance but there exist already use and may be PMIP folks may have reason for having this. The point here is, ietf already has developed a signaling protocol and that complementing with MP solutions addresses the  per packet use case too.   Hence it is important to come up with clear problem statement which is NOT addressed by existing standards to make WG formation case.

Thanks,
Praveen

Thanks,
Mingui

Cc: Mirja Kuehlewind; Suresh Krishnan; [email-masked]<mailto:[email-masked]>

Hi :

-Praveen

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
Sent: Thursday, March 30, 2017 10:56 AM
To: Jordan Melzer <[email-masked]<mailto:[email-masked]>>
Cc: Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>; Suresh Krishnan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [ALU] Re: [Banana] Charter Text w/Milestones
Importance: Low

Thoughts?

Margaret

> On Mar 30, 2017, at 12:51 PM, Margaret Cullen <[email-masked]<mailto:[email-masked]>> wrote:
>
>
> MPTCP.  The idea is that the BANANA group will define an encapsulation to tunnel packets between BANANA Boxes.  It is also possible that the MPTCP WG will define a "BANANA Encapsulation" using MPTCP proxies on both ends.  If there is more than one encapsulation, we would still like to have a single signaling protocol to communicate link information and status, as well as any signaling needed by the encapsulations.
>
>> On Mar 30, 2017, at 12:06 PM, Jordan Melzer <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Thanks, Margaret.
>>
>> The proposed text sometimes uses singular and sometimes uses plural when referring to encapsulation(s).  I am not sure if the goal is to arrive at one encapsulation or many, and if BANANA will define the negotiation.  If some of the encapsulations don't fully meet BANANA's goals, will BANANA still allow them to be negotiated?  If the goal is a single encapsulation, is there consensus that a single encapsulation that meets all needs is likely through minor extensions of existing encapsulations?
>>
>>
>> To: [email-masked]<mailto:[email-masked]>
>> At this point, the text attempts to be neutral about the subject of whether there will be an MPTCP encapsulation (presumably done in the MPTCP WG) or not.  We might want to update the text based on the outcome of today's MPTCP meeting if there is any clear conclusion.
>>
>> Thoughts?  Comments?
>>
>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>

_______________________________________________
Banana mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/banana
_______________________________________________
Banana mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/banana

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 4 Apr 2017 18:55:32 +0000

> So before progressing, I think more effort needs to be put into
>demonstrating that there is a common problem to be solved that is any
>more than configuration of what I believe to be a boutique use case.

Agree with Dave. I am not understanding what this group intends to
develop. I am all for bringing new features/addressing gaps in protocol
specific groups such as MPTCP/DMM ..etc.

Sri

On 3/30/17, 11:12 AM, "Banana on behalf of David Allan I"
<[email-masked] on behalf of [email-masked]> wrote:

>HI
>
>I have to admit I have a few problems with this....
>
>First, two items in the interest of full disclosure,
>
>1) I'm focused on the converged operator case where this is likely to be
>a managed service, and my comments are a result of viewing the problem
>through that lens. As such, operators already have tools to do a chunk of
>this (e.g. policy and configuration) which they will simply extend as
>necessary vs. deploy new protocols.
>
>2) I have a leadership position in Broadband Forum where we have been
>working this space for some time. We expect to do further work as part of
>efforts to add fixed access/hybrid access directly to a 5G core. This is
>to satisfy the aspirations of a number of European carriers of have both
>wireless and wireline offerings and wish to converge them. This is a
>project we are initiating in cooperation with 3GPP with deliverables to
>be complete for release 16(YE 2018), and I would expect this to address a
>chunk of the wishlist in the charter independently of any BANANA efforts.
>My reasons for thinking this outlined above, the bootstrapping and
>configuration I would expect to be achieved by augmenting already
>specified and deployed tools.
>
>IF this were to go forward I would want to see the necessary functions
>decomposed, and separate out initial bootstrapping of the service from
>steady state operation. A toolbox of protocols that could be individually
>adopted would serve the industry better than a god protocol. That being
>said, if bootstrapping and initial configuration is taken off the table
>as not of use to my constituency,  I am highly skeptical that the steady
>state operation of any of a number of solutions can be genericized to be
>common to the set of approaches currently on the table... Off the top of
>my head I would characterize the steady state functions as:
>	- routing to an off path proxy <-- property of the individual protocol
>solution
>	- flow control <-- property of the individual protocol solution, e.g.
>TCP can be dealt with differently than UDP, differently than something
>like QUIC
>	- maintaining ordering guarantees <-- property of the individual
>protocol solution
>	- fault detection <-- COULD be separate OAM, or bundled into the
>individual solution's flow control, ergo part of the specific solution....
>
>So before progressing, I think more effort needs to be put into
>demonstrating that there is a common problem to be solved that is any
>more than configuration of what I believe to be a boutique use case.
>
>I hope this helps
>Dave
>
>
>
>Sent: Thursday, March 30, 2017 11:10 AM
>To: [email-masked]
>Cc: Mirja Kuehlewind <[email-masked]>; Suresh Krishnan
><[email-masked]>
>At this point, the text attempts to be neutral about the subject of
>whether there will be an MPTCP encapsulation (presumably done in the
>MPTCP WG) or not.  We might want to update the text based on the outcome
>of today¹s MPTCP meeting if there is any clear conclusion.
>
>Thoughts?  Comments?
>
>The BANdwidth Aggregation for Network Access (BANANA) Working Group is
>chartered to develop solution(s) to support dynamic path selection on a
>per-packet basis in networks that have more than one point of attachment
>to the Internet.
>
>Bandwith Aggregation consists of splitting local traffic across multiple
>Internet links on a per-packet basis, including the ability to split a
>single flow across multiple links when necessary.
>
>It is the goal of this WG to produce a Bandwidth Aggregation solution
>that will provide the following benefits:
>
>  low bandwidth.  Users may wish to run applications (such as
>  streaming video, or content up/downloads) that require (or could
>  benefit from) more bandwidth for a single traffic flow than is
>  available on any of the local links.  A Bandwidth Aggregation
>  solution could supply the needed bandwidth by splitting a single
>  traffic flow across multiple Internet links.
>
>Proposed BANANA solutions use different approaches (e.g. tunnels,
>proxies, etc.) to split and recombine traffic, but at an abstract level,
>they involve a local (hardware or software) component on the multi-access
>network, a remote component within the Internet, and mechanisms for those
>components to find each other, exchange signalling information, and
>direct traffic to each other.  We refer to these functional components as
>the Local and Remote "BANANA Boxes", and we refer to the method they use
>to direct traffic to each other as a "BANANA Encapsulation".
>
>The Bandwidth Aggregation solutions developed in this group will work
>whether the attached links are provided by a single Internet Service
>Provider or multiple Providers.
>
>- Specify a signalling protocol that can be used to send configuration
>  and control information between BANANA boxes, including:
>- Work with other IETF WGs defining BANANA encapsulations
>  (if any) to ensure that the discovery mechanism and signalling
>  protocol will meet their needs.
>
>BANANA Boxes will determine if a specific flow is eligible for Bandwith
>Aggregation. If a flow is not eligible, it will not be split across
>multiple attached links.
>
>For this initial charter, we will focus on how Local BANANA Boxes
>communicate with Remote BANANA Boxes.  We will not address the topic of
>cooperation between multiple Local BANANA Boxes.
>
>MILESTONES
>Dec 2017 Adopt WG draft for discovery/configuration mechanism Dec 2017
>Adopt WG draft for signalling proocol Dec 2017 Adopt WG draft for tunnel
>encapsulation Oct 2018 WGLC on discovery/configuration mechanism Oct 2018
>WGLC on signalling protocol Oct 2018 WGLC on tunnel encapsulation Apr
>2019 Send discovery/configuration mechanism to the IESG Apr 2019 Send
>signalling protocl to the IESG Apr 2019 Send tunnel encapsulation to the
>IESG
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 4 Apr 2017 18:55:34 +0000

Hi Mingui,

> [Mingui] From I observed in the past few (at least 3) years, carriers never became interested in rendering a heavy mobile IP stack to be a BANANA solution. The first thing must be done is how to re…

This is your argument basis for creating a new working group? So, there is a signaling protocol X which in your mind is bulky and so you will design a new protocol which will be less bulky. The protocol that is in question uses two messages and few options; it has the semantics and the design to support authentication, authorization and support for various features. But, in your mind its bulky and so you will be able to design a much better signaling protocol and with no loss of functional capabilities. Can you give a glimpse of how your new signaling protocol looks like? Can you compare that with the existing protocol?

I presume your new signaling protocol will rely on a standard tunneling protocol like GRE (just as how the above bulky protocol does) and that keeps all the forwarding plane considerations identical. But, magically your new signaling protocol will bea much better protocol and operators will embrace it and device vendors will roll it out in no time. That is your thinking?

Signaling protocol A with tunneling scheme X, vs Signaling protocol B with tunneling scheme X. Is there any feedback from any SDO that enforces your view point that they are looking for IETF to come out with a new protocol?

Industry spent few years on designing these protocols and then there was mass community interest. Now, couple of folks want a new protocol and so we will create a new working group? I really hope there is consensus and mass community interest behind this request and which I am not seeing.

> The first thing must be done is how to remove 90% of PMIP’s complicated functionalities that are designed for mobile scenarios only.

Please qualify this statement. Explain me what are those features that are in your 90% list and which of those features are mandatory to implement features?

Sri

From: Banana <[email-masked]<mailto:[email-masked]>> on behalf of "Zhangmingui (Martin)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 3, 2017 at 2:17 PM
To: "Muley, Praveen (Nokia - US/Mountain View)" <[email-masked]<mailto:[email-masked]>>, Margaret Cullen <[email-masked]<mailto:[email-masked]>>
Cc: Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>, Suresh Krishnan <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Banana] [ALU] Re: Charter Text w/Milestones

Hi Praveen,

Thanks,
Mingui

From: Banana [[email-masked]<mailto:[email-masked]>] on behalf of Muley, Praveen (Nokia - US/Mountain View) [[email-masked]<mailto:[email-masked]>]

Hi :

-Praveen

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
Sent: Thursday, March 30, 2017 10:56 AM
To: Jordan Melzer <[email-masked]<mailto:[email-masked]>>
Cc: Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>; Suresh Krishnan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [ALU] Re: [Banana] Charter Text w/Milestones
Importance: Low

Thoughts?

Margaret

---

From: Jordan Melzer <[email-masked]>
Date: Tue, 4 Apr 2017 20:05:31 +0000

I would like to see the group develop a path bonding mechanism that works for arbitrary collections of links (like MPTCP) and allows arbitrary protocols to run across them (unlike MPTCP).  I believe this implies flow control but not retransmission.  There may be some other considerations -- eg packet size, perhaps some policy concerns around what link gets used first / by what.  There are a number of uses for arbitrary link bonding, some of which would apply only to a network segment but not the endpoints and others which would involve one or both endpoints.  If it's possible to make a protocol that could be used in any of these ways that would be great.

Like every other group doing a multipath something, I think this group should briefly put together requirements and then define a solution that meets them.  Where BANANA is different from some of the others is that it would be building a general multi-path solution.  If you feel there already is one or a potential to do one without creating any new messages, say so -- certainly an informational RFC explaining how to do something with existing tools is easier to do than making a new protocol.  If not, it does sound possible to build -- some of the current solutions are very close -- feel free to suggest a method.

Though I am not sure that this is the group consensus, I believe the reason there is a new group for this is that no other protocol / group has nailed any path collection, any protocol multipathing.  If we're able to agree on what that really is and another IETF group can solve it -- great.  We knock off early for beers. 

Jordan

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: April 4, 2017 02:56 PM
To: David Allan I; Margaret Cullen; [email-masked]
Cc: Mirja Kuehlewind; Suresh Krishnan
Subject: Re: [Banana] Charter Text w/Milestones

>more than configuration of what I believe to be a boutique use case.

Agree with Dave. I am not understanding what this group intends to develop. I am all for bringing new features/addressing gaps in protocol specific groups such as MPTCP/DMM ..etc.

Sri

On 3/30/17, 11:12 AM, "Banana on behalf of David Allan I"
<[email-masked] on behalf of [email-masked]> wrote:

>1) I'm focused on the converged operator case where this is likely to 
>be a managed service, and my comments are a result of viewing the 
>problem through that lens. As such, operators already have tools to do 
>a chunk of this (e.g. policy and configuration) which they will simply 
>extend as necessary vs. deploy new protocols.
>
>working this space for some time. We expect to do further work as part 
>of efforts to add fixed access/hybrid access directly to a 5G core. 
>This is to satisfy the aspirations of a number of European carriers of 
>have both wireless and wireline offerings and wish to converge them. 
>This is a project we are initiating in cooperation with 3GPP with 
>deliverables to be complete for release 16(YE 2018), and I would expect 
>this to address a chunk of the wishlist in the charter independently of any BANANA efforts.
>steady state operation. A toolbox of protocols that could be 
>individually adopted would serve the industry better than a god 
>protocol. That being said, if bootstrapping and initial configuration 
>is taken off the table as not of use to my constituency,  I am highly 
>skeptical that the steady state operation of any of a number of 
>solutions can be genericized to be common to the set of approaches 
>currently on the table... Off the top of my head I would characterize the steady state functions as:
>MPTCP WG) or not.  We might want to update the text based on the 
>outcome of today¹s MPTCP meeting if there is any clear conclusion.
>
>Thoughts?  Comments?
>
>per-packet basis in networks that have more than one point of 
>attachment to the Internet.
>
>Bandwith Aggregation consists of splitting local traffic across 
>multiple Internet links on a per-packet basis, including the ability to 
>split a single flow across multiple links when necessary.
>
>proxies, etc.) to split and recombine traffic, but at an abstract 
>level, they involve a local (hardware or software) component on the 
>multi-access network, a remote component within the Internet, and 
>mechanisms for those components to find each other, exchange signalling 
>information, and direct traffic to each other.  We refer to these 
>functional components as the Local and Remote "BANANA Boxes", and we 
>refer to the method they use to direct traffic to each other as a "BANANA Encapsulation".
>
>Adopt WG draft for signalling proocol Dec 2017 Adopt WG draft for 
>tunnel encapsulation Oct 2018 WGLC on discovery/configuration mechanism 
>Oct 2018 WGLC on signalling protocol Oct 2018 WGLC on tunnel 
>encapsulation Apr
>signalling protocl to the IESG Apr 2019 Send tunnel encapsulation to 
>the IESG
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 4 Apr 2017 20:54:35 +0000

> Where BANANA is different from some of the others is that it would be
>building a general multi-path solution.

This goal of realizing a, "general multi-path solution” will end up
creating a new signaling protocol with identical capabilities that the
existing protocol does. Duplicating all the capabilities, gateway
discovery, authentication, path connectivity tests, multi path signaling,
flow policy negotiation … all and every semantic that is present in
existing protocols will be required. Just that there will be new name for
the protocol called “BANANA”, which gives a false illusion that it is
specific to tunnel bonding and so it will be better and it will take 4 to
5 years ti complete that work. For all practical purposes, the signaling
semantics will be identical, only the messaging formats will be different.
You call it “Banana”, I call it “Mobile IP”. but it looks the same, does
the same thing and you need all the capabilities.

FWIW, Mobile IP was defined with the goal to keep it access agnostic and
has support for anchor discovery and signaling for multi path
establishment. it is not clear why that protocol cannot be used here and
why there is a need for a new protocol? More importantly, which SDO is
asking for it and why? The bar for new signaling protocol standardization
should be very high.

Now, with respect to data plane, or more specifically on how to split
traffic between two peers and in the presence of multiple overlay tunnel
paths, there are many deployments and existing vendor solutions that has
addressed this issue. Mobile IP, PMIP, Multilink PPP, MPTPCP have support
for flow distribution to large part. But, if there is a specific gap, say,
we need an informational spec on how the tunnel peers have to behave when
splitting a IP flow across multiple tunnel paths ..some specific
considerations etc, that can be done in that specific working group.  If
the extension required is for TCP based protocol, it can be done in MPTCP
WG; if the extension is for overlay tunnel based paths, DMM WG can address
that. INT area WG can also publish information specs on such matters,
exactly how there is UDP encap being defined for GRE. I am failing to
understand why a new working group is needed.

Sri

On 4/4/17, 1:05 PM, "Jordan Melzer" <[email-masked]> wrote:

>I would like to see the group develop a path bonding mechanism that works
>for arbitrary collections of links (like MPTCP) and allows arbitrary
>protocols to run across them (unlike MPTCP).  I believe this implies flow
>control but not retransmission.  There may be some other considerations
>-- eg packet size, perhaps some policy concerns around what link gets
>used first / by what.  There are a number of uses for arbitrary link
>bonding, some of which would apply only to a network segment but not the
>endpoints and others which would involve one or both endpoints.  If it's
>possible to make a protocol that could be used in any of these ways that
>would be great.
>
>Like every other group doing a multipath something, I think this group
>should briefly put together requirements and then define a solution that
>meets them.  Where BANANA is different from some of the others is that it
>would be building a general multi-path solution.  If you feel there
>already is one or a potential to do one without creating any new
>messages, say so -- certainly an informational RFC explaining how to do
>something with existing tools is easier to do than making a new protocol.
> If not, it does sound possible to build -- some of the current solutions
>are very close -- feel free to suggest a method.
>
>Though I am not sure that this is the group consensus, I believe the
>reason there is a new group for this is that no other protocol / group
>has nailed any path collection, any protocol multipathing.  If we're able
>to agree on what that really is and another IETF group can solve it --
>great.  We knock off early for beers.
>
>Jordan
>

---

From: <[email-masked]>
Date: Wed, 5 Apr 2017 09:52:34 +0000

Hi Mingui, Praveen,

Please see below quick comments regarding few points you raised up.

> 1. The third party operator offering service of bandwidth aggregation is NOT the case I have so far seen with our customers. That may be use case but is NOT the mainline line use case.  Either the…

[Mingui] I know "speedify" is an example tool of bandwidth aggregation that is provided by a third party operator. But why there has to be a third party?

[PS] because of economic reasons... it allows to deploy the service without impacting, or (worse) replacing, current CPE or network elements.... Anyway, it is out of the scope of banana discussions...

Is it more of interest that the operator let the BANANA box talk with a remote BANANA box while these two boxes are produced by different vendors?

> 4. I know GRE is one solution which was discussed in BANANA meeting and if we have to develop signaling protocol for the tunnel status, then ietf has already produced one which is PMIP . Why not us…

[PS] I agree it would be common sense...

[Mingui] From I observed in the past few (at least 3) years, carriers never became interested in rendering a heavy mobile IP stack to be a BANANA solution. The first thing must be done is how to remove 90% of PMIP's complicated functionalities that are designed for mobile scenarios only. Subsequently, we still have to design missing functionalities, such as per-packet load distribution

[PS] this is not true... we have discussed this many times and I'm running out of ways to explain that traffic distribution problem is orthogonal to IP mobility protocols... Considering multiple care-of-addresses support, once tunnels are established the sender can forward either on a per-flow or a per-packet basis. You can check RFC4908 and more recent RFC6089 that gives example of how mobile IP can configure bonding (considering UDP).

and the bypassing feature.

[PS] come on... IP mobility is about dynamically establishing tunnels... then you can of course forward traffic using local addresses (i.e. bypass) or home addresses (i.e. use bonding)... this is basic policy routing...

You'd better come up with a draft to depict a complete solution before you claim it is usable at all. If you do so, you will soon find out you are repeating the story of GRE tunnel bonding.

[PS] I'm not sure... If you do so, you might want to not be stuck with one single tunneling protocol; you might want to not collocate control and data path within a single protocol (i.e. adding control message to GRE)... Personally,  I find out that you are reinventing IP mobility signaling and TCP traffic control... Just my opinion...

[PS] 100% inline

My 0.2 cents...
Pierrick
Thanks,
Praveen

Thanks,
Mingui

Hi :

-Praveen

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
Sent: Thursday, March 30, 2017 10:56 AM
To: Jordan Melzer <[email-masked]<mailto:[email-masked]>>
Cc: Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>; Suresh Krishnan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [ALU] Re: [Banana] Charter Text w/Milestones
Importance: Low

Thoughts?

Margaret

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 08 Apr 2017 03:18:14 +0200

I'm afraid I missed the beginning of this discussion, so please forgive me
if that has been answered before.

What point are you making, Sri?  Are you saying that MIPv6 already solves
the problem that BANANA is aiming for, or are you merely saying that
BANANA should reuse as much of the MIPv6 signalling protocols as possible?

In either case, I'd appreciate some pointers to reading material.

Thanks,

-- Juliusz

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 11 Apr 2017 17:02:02 +0000

I am sure you can review the thread in the archives, Julius. I hope you will also answer the questions on the need for a new signaling protocol and how that will be better than existing protocols.

I also do not see a need for both of us to engage in any arguments about this work. There are literally 2 or 3 people supporting this work and every one else opposing it and there is zero SDO support. I am sure AD will do that counting and we do not have to bother about that. But, IMO, this is not going any where and so we as well save some time :)

But, just to get the focus on the minor gap in the existing work, please see the below diagram.  If you remove the signaling from the equation, you have a scenario where there are multiple overlay tunnels between two peers (CPE and aggregation gateway) and its about how you efficiently use those two paths for the IP traffic. There is MPTCP and there is other existing work around IFOM/DSMIP that does take care of policy based routing (refer to RFC7629, RFC6088, RFC6089, RFC5555, RFC7864 and few other I-D's);. Sure, the later work does not exactly tell you how to split a flow. But, vendors have always done that and used IP SLA probes for path measurements.

So, this has nothing to do with signaling and its strictly about user-plane. There is no need for defining a new signaling protocol, a new discovery mechanism, authentication, policy interfaces, path check frame work ..etc.   This is massive amount of work and industry is not looking for that. If you really want some information spec on how two forwarding entities can deal with this for overlay tunnels, one can certainly publish an informational I-D in INT area. It can be certainly used by IETF or SDO specific signaling protocols that use overlay tunneling modes.

Sri

On 4/7/17, 6:18 PM, "Juliusz Chroboczek" <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 11 Apr 2017 21:27:54 +0200

> I also do not see a need for both of us to engage in any arguments about this
> work.

I've re-read my mail, and I'm still not quite sure what gave you the idea
that I wanted to argue.  If anything gave that impression, please be
assured that that was not the intent.

> (refer to RFC7629, RFC6088, RFC6089, RFC5555, RFC7864

Thanks for the pointers, although I wish you had been a little more selective.

-- Juliusz

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 11 Apr 2017 19:52:35 +0000

>  If anything gave that impression, please be assured that that was not
>the intent.

Ok! Fair point. 

Cheers
Sri

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 11 Apr 2017 23:26:19 +0200

> (refer to RFC7629, RFC6088, RFC6089, RFC5555, RFC7864 and few other
> I-D’s)

Ok, I've now had a look -- and RFC 7629 is interesting.  A couple questions:

  (1) What's the recommended way to send a timestamped packet over a tunnel?
  (2) What's the recommended way to send vendor-specific or experimental
      data over a tunnel?
  (3) Are there any open-source implementations one could build on?

-- Juliusz

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 11 Apr 2017 22:36:32 +0000

On 4/11/17, 2:26 PM, "Juliusz Chroboczek" <[email-masked]> wrote:

>> I-D¹s)

GRE encapsulation header can be used for notifying user-plane related
hints to a GRE tunnel peer. For example, RFC2890 carries a key sequence
extension which is used for overlapping IP use-cases and the corresponding
control plane signaling is in MIP4, MIPv6, PMIPv6, GTP and IKEv2
protocols.  There is no general Vendor-specific extension support for GRE.
However, there have been previous attempts, but the IETF did not agree for
vendor-specific/experimental extensions to GRE or to ND (Ex:
https://tools.ietf.org/html/draft-gundavelli-6man-ipv6-nd-vendor-spec-optio
ns-00, https://tools.ietf.org/html/draft-song-gre-tlv-extension-00). Now,
if there is a need to carry additional hints in user plane, GRE extensions
can be proposed and INT area is a great start as it already looking at
many GRE extensions.

Sri

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Fri, 21 Apr 2017 12:09:33 +0000

Hello 

I have comment related to the used terminology in the charter description. 

It talks about "BANANA boxes" which is a bit old fashioned and if taken too strictly limits the solution space to “boxes” of some sort. A more accurate and up-to-date term would be BANANA functions as you may then support virtualized functions that can be located more flexibly e.g. in a host device, or an enterprise could etc.  

Especially the configuration and control protocol part of the charter I find very much needed and an area where we could provide input and help.

Best regards
Hannu

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
Sent: Thursday, March 30, 2017 8:56 PM
To: Jordan Melzer <[email-masked]>
Cc: Mirja Kuehlewind <[email-masked]>; Suresh Krishnan <[email-masked]>; [email-masked]
Subject: Re: [Banana] Charter Text w/Milestones

Thoughts?

Margaret

> The ambiguity may be cleared up if/when we know what is happening in MPTCP.  The idea is that the BANANA group will define an encapsulation to tunnel packets between BANANA Boxes.  It is also possible that the MPTCP WG will define a “BANANA Encapsulation” using MPTCP proxies on both ends.  If there is more than one encapsulation, we would still like to have a single signaling protocol
> to communicate link information and status, as well as any signaling needed by the encapsulations.  
> 
>> Dec 2017 Adopt WG draft for discovery/configuration mechanism Dec 2017 Adopt WG draft for signalling proocol Dec 2017 Adopt WG draft for tunnel encapsulation Oct 2018 WGLC on discovery/configuration mechanism Oct 2018 WGLC on signalling protocol Oct 2018 WGLC on tunnel encapsulation Apr 2019 Send discovery/configuration mechanism to the IESG Apr 2019 Send signalling protocl to the IESG Apr 2019 Send tunnel encapsulation to the IESG
>>

---

From: Margaret Cullen <[email-masked]>
Date: Mon, 24 Apr 2017 03:48:19 -0400

HI Hannu,

> On Apr 21, 2017, at 8:09 AM, Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]> wrote:
> 

It is the explicit intention that “BANANA Boxes” may be separate hardware components or software components running on CPE, an end system, etc.  I will see if i can improve the wording to make this clearer.  We struggled with the right word to use for something that can be a hardware or software component with either proxy-like or tunnel-endpoint-like properties — a word that wouldn’t constrain the solution selection.  I am not familiar with the use of the term “functions” as you describe it, so it doesn’t immediately seem clearer to me.  Does it to others?

> Especially the configuration and control protocol part of the charter I find very much needed and an area where we could provide input and help.

Excellent.  This is likely to be the meat of any effort.  The “encapsulations” are expected to use existing protocols like GRE, MPTCP, etc.

Thanks,
Margaret

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Mon, 24 Apr 2017 10:49:13 +0000

Hello again

Just to clarify the where from the term "network function" is stemming from:

See https://en.wikipedia.org/wiki/Network_function_virtualization

Note also that within the IRTF there is Network Function Virtualization Research Group, https://irtf.org/nfvrg

Also in the ONF there is  Virtual CPE (vCPE) Framework
https://www.opennetworking.org/products-listing/virtual-cpe-vcpe-framework 

Best regards
Hannu

-----Original Message-----
From: Margaret Cullen [mailto:[email-masked]] 
Sent: Monday, April 24, 2017 10:48 AM
To: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>
Cc: Jordan Melzer <[email-masked]>; Mirja Kuehlewind <[email-masked]>; Suresh Krishnan <[email-masked]>; [email-masked]
Subject: Re: [Banana] Charter Text w/Milestones

HI Hannu,

Thanks,
Margaret