Subject: [Banana] BOF Proposal

From: Margaret Cullen <[email-masked]>
Date: Wed, 28 Sep 2016 22:26:13 -0400

Hi Banana Folks,

I have attached a draft of a BOF request for Seoul in November (Suresh, I am cc:ing you for your information — this is not a formal request, yet).  This needs to be submitted by September 30th, but I would like to get your feedback over the next couple of days, as possible.  Assuming the BOF is approved, I think we will continue to have some time to work on the agenda and proposed WG charter leading into the meeting.

The biggest open question in this draft is whether to include the MPTCP proposal(s) in this BOF (and proposed WG) or not.  From what I’ve seen (from the outside), it looks like there is more interest in moving this work to the Internet area than there is in doing the work in the MPTCP WG, but I’d be interested in hearing how things look to more active MPTCP participants…

If we _do_ want to include MPTCP in this BOF, it would be highly desirable to list one of more MPTCP folks (technology experts, solution authors, potential implementors or operators who wish to deploy an MPTCP solution) to list as proponents of this BOF.  Any volunteers?

Feedback on the entire BOF request would also be appreciated.

Thanks,
Margaret

- Name: Bandwidth Aggregation for Network Access (BANANA)

- Description: 

- Agenda:

0) Administrivia (5 mins)
1) Problem Statement: (20 mins)
	- Problem statements from other SDOs
	- BANANA Problem Statement Draft
2) Brief Overview of Solution Space & Considerations (20 min)
	- BANANA Consideration Draft
	- Tunnel Bonding
	- MPTCP Proxy
	- MIP-Based Approach
3) Operational Experience (20 mins)
	- Deutsche Telecom
	- Others?
4) Draft Charter (10 mins)
5) Open Discussion (30 mins)
6) Questions & Next Steps (15 mins)

- Status: WG Forming (although other options may be discussed)

- Responsible AD: Suresh Krishnan

- BoF proponents: TBD

- BoF chairs: TBD 

- Number of people expected to attend: 100 

- Length of session (1, 1.5, 2, or 2.5 hours): 2 hours 

- Conflicts to avoid (whole Areas and/or WGs): Entire INT Area (if possible), INTAREA WG, MPTCP, DMM, TRILL, HOMENET, BABEL, CAPPORT

- Mailing List: https://www.ietf.org/mailman/listinfo/banana 

- Draft charter: 

- Relevant drafts:

---

From: <[email-masked]>
Date: Thu, 29 Sep 2016 10:58:15 +0000

Hi Margaret, all,

Thanks for progressing this. 

Personally I now think that MPTCP should be included in a banana BoF. Following discussion on the mptcp mailing list, it seems to me that an mptcp-based solution needs more than an extension to mptcp - and this extra stuff seemed to be in more in the scope of INTAREA (however, it is quite possible that my conclusion is mistaken). Hopefully the forthcoming "merged" version of the mptcp proposal will be clearer about what work is needed, so we can split off the right portion to the mptcp WG.

One point that came up during the mptcp discussions is that it seems to assume a controlled environment (to avoid a problem where the message reaches the 'wrong' proxy). If something similar is true for the other solution approaches, then I think it should be mentioned in the charter and perhaps also the BoF proposal.  

Thanks,
Phil

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
Sent: 29 September 2016 03:26
To: [email-masked]
Cc: Mingui Zhang <[email-masked]>; Nicolai Leymann <[email-masked]>; Suresh Krishnan <[email-masked]>
Subject: [Banana] BOF Proposal

Hi Banana Folks,

Thanks,
Margaret

- Description: 

- Agenda:

- BoF proponents: TBD

- BoF chairs: TBD 

- Draft charter: 

- Relevant drafts: 

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

---

From: Margaret Cullen <[email-masked]>
Date: Thu, 29 Sep 2016 07:55:23 -0400

Hi Phil,

> On Sep 29, 2016, at 6:58 AM, <[email-masked]> <[email-masked]> wrote:
> 

This what I meant when I was talking about how the assumption that both links are provided by the same operator makes this a more tractable subset of the site multihoming problem.  Thanks to your comment, I realized that I didn’t say _why_ it is more tractable.  Will add.

Yes, the solutions in this space generally require a central box (to serve as an MPTCP proxy or a tunnel endpoint) in the provider portion of the network that will recombine the traffic in some way.  The operator network would need to be designed such that all traffic from a single subscriber goes through the same box.

Thanks,
Margaret

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 30 Sep 2016 07:06:15 +0000

Hi Margaret, Hi Phil,

Yes, a controlled environment should become a common requirement. At least two things are more tractable in a controlled environment. The first thing as you mentioned is about addressing. One subscriber needs to resolve a sole address or a sole set of addresses that represent a central box. The other thing is about AAA.

Thanks,
Mingui

> From: Margaret Cullen [mailto:[email-masked]]
> Sent: Thursday, September 29, 2016 7:55 PM
> To: [email-masked]
> Cc: [email-masked]; Mingui Zhang; [email-masked]; Suresh
> Krishnan
> Subject: Re: [Banana] BOF Proposal
> 
> 
> Hi Phil,
> 
> > One point that came up during the mptcp discussions is that it seems to assume
> a controlled environment (to avoid a problem where the message reaches the
> 'wrong' proxy). If something similar is true for the other solution approaches,
> then I think it should be mentioned in the charter and perhaps also the BoF
> proposal.
> 
> This what I meant when I was talking about how the assumption that both links
> are provided by the same operator makes this a more tractable subset of the site
> multihoming problem.  Thanks to your comment, I realized that I didn’t say
> _why_ it is more tractable.  Will add.
> 
> Yes, the solutions in this space generally require a central box (to serve as an
> MPTCP proxy or a tunnel endpoint) in the provider portion of the network that
> will recombine the traffic in some way.  The operator network would need to be
> designed such that all traffic from a single subscriber goes through the same box.
> 
> Thanks,
> Margaret

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 30 Sep 2016 22:37:40 +0000

Hi Margaret,

On 09/28/2016 10:26 PM, Margaret Cullen wrote:
>
> Hi Banana Folks,
>
> I have attached a draft of a BOF request for Seoul in November (Suresh, I am cc:ing you for your information — this is not a formal request, yet).

Are you ready to make the formal request yet? The deadline is 23:59 UTC today.

https://trac.tools.ietf.org/bof/trac/

Thanks
Suresh

---

From: Margaret Cullen <[email-masked]>
Date: Fri, 30 Sep 2016 18:40:27 -0400

I am doing my final edits and will send it very soon!!  

Margaret

> On Sep 30, 2016, at 6:37 PM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Margaret,
>