Subject: [Banana] Updated Charter

From: Margaret Cullen <[email-masked]>
Date: Fri, 22 Sep 2017 15:18:39 -0400

I have updated the charter text in an attempt to reflect all of the feedback to date.  You can find the new version here:
https://docs.google.com/document/d/1byOJ_To6eL1ZBxKSYpTafQbngTBiNwxaK7ReIsld9Ek/edit <https://docs.google.com/document/d/1byOJ_To6eL1ZBxKSYpTafQbngTBiNwxaK7ReIsld9Ek/edit>

Thoughts?  Comments?

Do folks think this is ready to send to the IESG?  Or are there other changes that it would make it clearer or better?

Margaret

---

From: Margaret Cullen <[email-masked]>
Date: Mon, 25 Sep 2017 15:32:40 -0400

No problem, Philip.  I have included the latest text below.  This does not yet include the changes I am currently discussing with Dave Sinicrope.

Margaret

Charter: BANdwidth Aggregation for Network Access WG

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.

Bandwidth 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, VPNs, 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 mechanisms (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 or at the remote end, and mechanisms for those components to find each other, exchange signalling information, and direct traffic to each other.   We refer to the functional components at each end as the Local and Remote “BANANA Boxes”, and we refer to the mechanisms they use to direct traffic to each other as “Bandwidth Aggregation mechanisms”.  

[Note:  Despite our use of the term “Boxes”, it should be understood that a “BANANA Box” might be a software component running on a piece of hardware with another primary purpose (e.g. a CPE router).]

The Bandwidth Aggregation solutions developed in this group will work
in true multi-provider scenarios (i.e. they will not depend on all of
the aggregated links being provided by a single Internet access provider
nor by a group of cooperating providers).  Any protocols defined by this
group will be IP-based, link-layer-independent solutions, and they will
be designed to work across NATs and other middle boxes, as needed.

The BANANA WG is chartered to complete the following  work items:
Informally document/discuss BANANA problem statement and usage scenarios in a non-archival document (e.g. Wiki, Google Doc, etc.)
Determine how Local and Remote BANANA Boxes find each other (i.e. describe how BANANA boxes will be provisioned/configured.)
Select or 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 the Bandwidth Aggregation mechanism(s) in use
Determining which flows are/are not eligible for Bandwidth Aggregation
Select (and extend, if necessary) a tunneling encapsulation for sending traffic between BANANA Boxes.

When applicable, the BANANA WG will use existing IETF protocols, or extensions to existing IETF protocols, as the basis for the work items listed above.  When an existing protocol is used, the WG deliverable will be a document describing the use of that protocol for Bandwidth Aggregation and/or a set of options or extensions to an existing IETF protocol to make it useful for Bandwidth Aggregation.

The BANANA WG will also work with other IETF WGs (and other SDOs, as requested) that define additional Bandwidth Aggregation mechanisms (if any)  to ensure that the protocols defined by the BANANA WG will meet the needs of those additional mechanisms.

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 Sep 25, 2017, at 12:37 PM, <[email-masked]> <[email-masked]> wrote:
> 
> Margaret,
> Please could you post the text on the mailing list, as our firewall blocks google docs
> Thanks!
> phil
>  
> From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
> Sent: 22 September 2017 20:19
> To: [email-masked]
> Subject: [Banana] Updated Charter
>

---

From: David Allan I <[email-masked]>
Date: Mon, 25 Sep 2017 19:42:09 +0000

HI Margaret

An aspect that concerns me for a while is the notion that there will be a single signaling protocol to satisfy a laundry list of requirements. On first blush this seems to suggest a solution is already in the wings that needs the laundry list, or that we will end up with  a bloated superset god protocol. Neither of which is IMO a totally desirable outcome.

Easiest fix for me would be to replace “a signaling protocol” with “mechanisms”.

Cheers
Dave

From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
Sent: Monday, September 25, 2017 12:33 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Banana] Updated Charter

Margaret

  *   Higher Per-Flow Bandwidth: Many Internet links available to homes and small offices (DSL, Cable, LTE, Satellite, VPNs, 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.

  *   Informally document/discuss BANANA problem statement and usage scenarios in a non-archival document (e.g. Wiki, Google Doc, etc.)

  *   Determine how Local and Remote BANANA Boxes find each other (i.e. describe how BANANA boxes will be provisioned/configured.)

  *   Select or 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 the Bandwidth Aggregation mechanism(s) in use

  *   Determining which flows are/are not eligible for Bandwidth Aggregation

  *   Select (and extend, if necessary) a tunneling encapsulation for sending traffic between BANANA Boxes.

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 Sep 25, 2017, at 12:37 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Margaret,

From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
Sent: 22 September 2017 20:19
To: [email-masked]<mailto:[email-masked]>
Subject: [Banana] Updated Charter

I have updated the charter text in an attempt to reflect all of the feedback to date.  You can find the new version here:
https://docs.google.com/document/d/1byOJ_To6eL1ZBxKSYpTafQbngTBiNwxaK7ReIsld9Ek/edit

Thoughts?  Comments?

Margaret

---

From: Margaret Cullen <[email-masked]>
Date: Mon, 25 Sep 2017 15:56:50 -0400

Good point, Dave!

I am a little concerned about the overuse of the term “mechanism”, though (since I define Bandwidth Aggregation mechanisms in the text).  So how about just changing “protocol” to “protocol(s)"?:

OLD:

	Select or specify a signalling protocol that can be used to send 
	control information between BANANA Boxes, including:

NEW:

	Select or specify signaling protocol(s) that can be used to send 
	control information between BANANA Boxes, including:

Or is theres something more that you were trying to capture by changing from “protocols” to “mechanisms”?

In addition to what you mentioned, this might allow us to reuse an existing protocol to do part of this job, even if that protocol could not be extended to cover everything we need for BANANA.

Margaret

> On Sep 25, 2017, at 3:42 PM, David Allan I <[email-masked]> wrote:
> 
> HI Margaret
>  
> 	• Higher Per-Flow Bandwidth: Many Internet links available to homes and small offices (DSL, Cable, LTE, Satellite, VPNs, 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.
>  
> 	• Informally document/discuss BANANA problem statement and usage scenarios in a non-archival document (e.g. Wiki, Google Doc, etc.)
> 	• Determine how Local and Remote BANANA Boxes find each other (i.e. describe how BANANA boxes will be provisioned/configured.)
> 	• Select or 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 the Bandwidth Aggregation mechanism(s) in use
> 	• Determining which flows are/are not eligible for Bandwidth Aggregation
> 	• Select (and extend, if necessary) a tunneling encapsulation for sending traffic between BANANA Boxes.
>  
> 	• 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
>

---

From: David Allan I <[email-masked]>
Date: Mon, 25 Sep 2017 20:12:54 +0000

I'd probably be happier losing signaling. IMO it is an overloaded term...

"specify protocol(s) that can be used..." 

WDYT?
Dave

-----Original Message-----
From: Margaret Cullen [mailto:[email-masked]] 
Sent: Monday, September 25, 2017 12:57 PM
To: David Allan I <[email-masked]>
Cc: [email-masked]
Subject: Re: [Banana] Updated Charter

Good point, Dave!

OLD:

NEW:

Margaret

> [Note:  Despite our use of the term “Boxes”, it should be understood 
> that a “BANANA Box” might be a software component running on a piece 
> of hardware with another primary purpose (e.g. a CPE router).]
>  
> the aggregated links being provided by a single Internet access 
> provider nor by a group of cooperating providers).  Any protocols 
> defined by this group will be IP-based, link-layer-independent 
> solutions, and they will be designed to work across NATs and other middle boxes, as needed.
>  
> Please could you post the text on the mailing list, as our firewall 
> blocks google docs Thanks!
> phil
>

---

From: Margaret Cullen <[email-masked]>
Date: Mon, 25 Sep 2017 16:22:55 -0400

Okay…  I can get behind that change.  I will need to do a small wording shift in the rest of the charter to lose the term “signaling’ to refer to this item, though.  So, let me wait until the other Dave (Sinicrope) gets back to me about his proposed changes, and I will make this change in the next round-up.

Margaret

> On Sep 25, 2017, at 4:12 PM, David Allan I <[email-masked]> wrote:
> 
> _______________________________________________
> Banana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/banana

---

From: Margaret Cullen <[email-masked]>
Date: Mon, 25 Sep 2017 16:43:16 -0400

I now have the charter text included below, including the updates I proposed to address Dave Sinicrope’s and Dave Allan’s comments.  Dave and Dave, does this version address your concerns?  Or is there more than needs to be done?

Others, is this better than the old version?  Worse in some ways that I should try to fix?  

Any further comments?

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.  These solutions will be designed to work in situations where Internet access is provided by more than one Internet Service Provider, and without cooperation between a set of Internet Service Providers (i.e. these will be Over-The-Top (OTT) solutions).

It is the goal of this WG to produce a Bandwidth Aggregation solution with the following benefits:

Proposed BANANA solutions use different mechanisms (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 or at the remote end, and ways for those components to find each other, exchange control information, and direct traffic to each other.   We refer to the functional components at each end as the Local and Remote “BANANA Boxes”, and we refer to the ways they direct traffic to each other as “Bandwidth Aggregation mechanisms”.  

The Bandwidth Aggregation solution(s) developed in the BANANA working group will be designed to work in scenarios where Internet access links from multiple, independent Internet access providers are being aggregated  (i.e. where the aggregated Internet access links are not provided by a single Internet access provider, nor by a set of cooperating providers).  Any protocols defined by this working group will be IP-based, link-layer-independent solutions, and they will be designed to work across NATs and other middle boxes, as needed.

The BANANA WG is chartered to complete the following  work items:
	• Informally document/discuss a BANANA problem statement and usage scenarios in a non-archival document (e.g. Wiki, etc.)
	• Determine how Local and Remote BANANA Boxes find each other (i.e. describe how BANANA boxes will be provisioned/configured).
	• Select or specify protocol(s) 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 the Bandwidth Aggregation mechanism(s) in use
		• Determining which flows are/are not eligible for Bandwidth Aggregation
	• Select (and extend, if necessary) a tunneling encapsulation for sending traffic between BANANA Boxes.

The BANANA WG will work with other IETF WGs that define "Bandwidth Aggregation mechanisms" (as defined above), to ensure that protocols selected or specified by the BANANA WG for provisioning and the exchange of control information will work for those Bandwidth Aggregation mechanisms.  The BANANA WG will also work with other SDO(s) that are defining Bandwidth Aggregation solutions (e.g. Broadband Forum TR-378) to ensure that there are no conflicts between our work, and to ensure that there are no negative consequences for users when multiple Bandwidth Aggregation solutions are available in a single environment.

Milestones

> On Sep 25, 2017, at 4:22 PM, Margaret Cullen <[email-masked]> wrote:
> 
>

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 26 Sep 2017 05:36:51 +0000

My 2 cents on this and I believe this is where a lot of controversy is coming from, is why would we not charter Banana as a WG which is defining an information model that is required to execute banana. So banana defines which information needs to be exchanged and what the banana entities do with it to perform banana
As such the actual protocol works can be done in different WG(s) and we can leverage existing work as Sri was pointing out.

Would this work for people? My 2 cents, just a try to help.

On 25/09/2017, 22:13, "Banana on behalf of David Allan I" <[email-masked] on behalf of [email-masked]> wrote:

    
    WDYT?
    Dave
    
    -----Original Message-----
    From: Margaret Cullen [mailto:[email-masked]] 
    Sent: Monday, September 25, 2017 12:57 PM
    To: David Allan I <[email-masked]>
    Cc: [email-masked]
    Subject: Re: [Banana] Updated Charter

    Good point, Dave!

    OLD:

    NEW:

    
    
    Margaret

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 26 Sep 2017 14:53:14 +0000

> My 2 cents on this and I believe this is where a lot of controversy is
>coming from, is why would we not charter Banana as a WG which is defining
>an information model that is required to execute banana. So banana
>defines which information needs to be exchanged and what the banana
>entities do with it to perform banana As such the actual protocol works
>can be done in different WG(s) and we can leverage existing work as Sri
>was pointing out.

That makes sense to me.

- No new  protocols (signaling or encapsulation) or protocol changes
- No selection of ³The Banana Solution², or solution work
- No ³Banana² branding on any protocol/solution; or the terminology of
³Banana boxes², ³Banana links² ..etc.

- Document various protocol approaches for realizing multipath between two
gateways as an informational RFC; identify current art; recommend
respective protocol WG¹s or INT/Transport Area to standardize extensions
- Specify Algorithm and analysis for per-packet load-balancing;
implementation considerations; without tying to any protocol/solution;
even BBF can make use of this algorith

This is some useful work and can benefit the community and other working
groups; will not impact vendor solutions, market situation, result in
definition of alternative protocols which do the same.
SDO¹s can leverage this work and focus on system architecture/solution.

Sri

On 9/25/17, 10:36 PM, "Banana on behalf of Henderickx, Wim (Nokia -
BE/Antwerp)" <[email-masked] on behalf of
[email-masked]> wrote:

>My 2 cents on this and I believe this is where a lot of controversy is
>coming from, is why would we not charter Banana as a WG which is defining
>an information model that is required to execute banana. So banana
>defines which information needs to be exchanged and what the banana
>entities do with it to perform banana
>As such the actual protocol works can be done in different WG(s) and we
>can leverage existing work as Sri was pointing out.
>
>On 25/09/2017, 22:13, "Banana on behalf of David Allan I"
><[email-masked] on behalf of [email-masked]> wrote:
>
>    I am a little concerned about the overuse of the term ³mechanism²,
>though (since I define Bandwidth Aggregation mechanisms in the text).  So
>how about just changing ³protocol² to ³protocol(s)"?:
>    
>    OLD:
>    
>    Or is theres something more that you were trying to capture by
>changing from ³protocols² to ³mechanisms²?
>    
>    In addition to what you mentioned, this might allow us to reuse an
>existing protocol to do part of this job, even if that protocol could not
>be extended to cover everything we need for BANANA.
>    
>    Margaret
>    
>    
>    
>    
>    
>    > An aspect that concerns me for a while is the notion that there
>will be a single signaling protocol to satisfy a laundry list of
>requirements. On first blush this seems to suggest a solution is already
>in the wings that needs the laundry list, or that we will end up with  a
>bloated superset god protocol. Neither of which is IMO a totally
>desirable outcome.
>    >  
>    > Easiest fix for me would be to replace ³a signaling protocol² with
>³mechanisms².
>    >  
>    > Cheers
>    > Dave
>    >  
>    > No problem, Philip.  I have included the latest text below.  This
>does not yet include the changes I am currently discussing with Dave
>Sinicrope.
>    >  
>    > 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.
>    >  
>    > Bandwidth 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, VPNs, 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 mechanisms (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 or at the remote end, and
>mechanisms for those components to find each other, exchange signalling
>information, and direct traffic to each other.   We refer to the
>functional components at each end as the Local and Remote ³BANANA Boxes²,
>and we refer to the mechanisms they use to direct traffic to each other
>as ³Bandwidth Aggregation mechanisms².
>    >  
>    > [Note:  Despite our use of the term ³Boxes², it should be
>understood 
>    > that a ³BANANA Box² might be a software component running on a
>piece 
>    > 	€ Informally document/discuss BANANA problem statement and usage
>scenarios in a non-archival document (e.g. Wiki, Google Doc, etc.)
>    > 	€ Determine how Local and Remote BANANA Boxes find each other
>(i.e. describe how BANANA boxes will be provisioned/configured.)
>    > 	€ Select or specify a signalling protocol that can be used to send
>    > 	€ IP Prefixes of access  links
>    > 	€ Information about link status and properties (including
>congestion)
>    > 	€ Information needed by the Bandwidth Aggregation mechanism(s) in
>use
>    > 	€ Determining which flows are/are not eligible for Bandwidth
>Aggregation
>    > 	€ Select (and extend, if necessary) a tunneling encapsulation for
>sending traffic between BANANA Boxes.
>    >  
>    > When applicable, the BANANA WG will use existing IETF protocols, or
>extensions to existing IETF protocols, as the basis for the work items
>listed above.  When an existing protocol is used, the WG deliverable will
>be a document describing the use of that protocol for Bandwidth
>Aggregation and/or a set of options or extensions to an existing IETF
>protocol to make it useful for Bandwidth Aggregation.
>    >  
>    > The BANANA WG will also work with other IETF WGs (and other SDOs,
>as requested) that define additional Bandwidth Aggregation mechanisms (if
>any)  to ensure that the protocols defined by the BANANA WG will meet the
>needs of those additional mechanisms.
>    >  
>    > 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
>    >  
>    > I have updated the charter text in an attempt to reflect all of the
>feedback to date.  You can find the new version here:
>    > 
>    > Do folks think this is ready to send to the IESG?  Or are there
>other changes that it would make it clearer or better?
>    >  
>    > Margaret
>

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 26 Sep 2017 11:48:28 -0400

Sri and Wim,

I understand that you do not think that the BANANA WG should be chartered to do any protocol work at this time -- that we should work only on a problem statement, models, informational documents, etc.

I have not changed the charter to reflect your input for two reasons:  1) I don't believe that the majority of the people who are engaged in the BANANA work agree with you, and 2) I don't think such a group would be successful, because there would not be sufficient interest to do the work.

If you feel that such work would actually be valuable to the community, please write drafts.  If not, please don't try to assign that work to others, as a hurdle to prevent or delay work that you do not support.

Margaret

Sent from my iPhone

> On Sep 26, 2017, at 10:53 AM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> 
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 26 Sep 2017 16:22:06 +0000

Margaret,

> If you feel that such work would actually be valuable to the community,
>please write drafts. If not, please don't try to assign that work to
>others, as a hurdle to prevent or delay work that you do not support.

This is a discussion on charter scope. What should be in the “IETF Banana
WG charter” is the point of discussion.  We are not assigning work to you,
or to any one. If this becomes a WG, it is an IETF WG that any one can
contribute and not some personal WG that belongs to few people. So, I am
not sure why you are reading these comments as “work assignment”.

I am providing my comments in an objective manner and so use of the
phrases such as, “as a hurdle to prevent or delay work”, is not
appreciated. 

As you have seen in this mailer, many of us do not agree with this open,
solution-oriented charter. I have cited past examples and how Banana
charter departs from those IETF conventions. I have raised very specific
questions to the AD in my long email. I also do not have to remind on the
lack of agreement in IETF97 on PS, and a straight charter text discussion
in IETF99; or a long 2 to 3 year Banana history with the past AD’s not
chartering this work.

If somehow this charter text manages to go beyond this point and hits
IESG, I am certain we have processes and tools in place for appeals and
that IESG will review these discussions carefully and put some bounds on
this charter.

Sri

On 9/26/17, 8:48 AM, "Margaret Wasserman" <[email-masked]> wrote:

>Sri and Wim,
>
>I understand that you do not think that the BANANA WG should be chartered
>to do any protocol work at this time -- that we should work only on a
>problem statement, models, informational documents, etc.
>
>I have not changed the charter to reflect your input for two reasons:  1)
>I don't believe that the majority of the people who are engaged in the
>BANANA work agree with you, and 2) I don't think such a group would be
>successful, because there would not be sufficient interest to do the work.
>
>If you feel that such work would actually be valuable to the community,
>please write drafts.  If not, please don't try to assign that work to
>others, as a hurdle to prevent or delay work that you do not support.
>
>Margaret
>
>Sent from my iPhone
>

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 26 Sep 2017 16:15:21 -0400

Hi Sri,

> On Sep 26, 2017, at 12:22 PM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> 
> Margaret,

> contribute and not some personal WG that belongs to few people.

Absolutely, and we would welcome your contributions.  If you are offering to do the work you have suggested, by all means, write drafts!  We will consider adding them to the charter or milestones.

I was under the (mistaken?) impression that you were proposing that someone other than you should write a set of support documents _instead_ of doing the work that is currently in the charter.  

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 26 Sep 2017 16:20:03 -0400

Hi Wim,

I have removed the word signaling in the most recently distributed version, as proposed by Dave Allan below.  Does that address your concern, as well?

Would people also find it clearer if we used the term protocol(s) or mechanism(s) or something similar where we are currently using the word "solutions"?  I think that word may mean different things to different people.

Margaret

Sent from my iPhone

> On Sep 26, 2017, at 1:36 AM, Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]> wrote:
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 26 Sep 2017 20:27:27 +0000

Margaret - Can you clarify ³we² here in this context is who?  You are
moderating this discussion, or saying this in the capacity of an
individual proposing some text to the charter?

On 9/26/17, 1:15 PM, "Margaret Wasserman" <[email-masked]> wrote:

>> This is a discussion on charter scope. What should be in the ³IETF
>>Banana
>> WG charter² is the point of discussion.  We are not assigning work to
>>you,
>Absolutely, and we would welcome your contributions.  If you are offering
>to do the work you have suggested, by all means, write drafts!  We will
>consider adding them to the charter or milestones.
>
>I was under the (mistaken?) impression that you were proposing that
>someone other than you should write a set of support documents _instead_
>of doing the work that is currently in the charter.
>
>Margaret
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 26 Sep 2017 20:38:02 +0000

Let this be very clear, I and suppose many others am not agreeing to the
current Banana WG charter. Lets not discuss about drafts, ownership and
other aspects.

I was trying to find a middle ground, where we can limit the damage
resulting from the formation of this WG. Hope this helps.

Lets focus on technical discussion.

Sri

On 9/26/17, 1:20 PM, "Banana on behalf of Margaret Wasserman"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi Wim,
>
>I have removed the word signaling in the most recently distributed
>version, as proposed by Dave Allan below.  Does that address your
>concern, as well?
>
>Would people also find it clearer if we used the term protocol(s) or
>mechanism(s) or something similar where we are currently using the word
>"solutions"?  I think that word may mean different things to different
>people.
>
>Margaret
>
>Sent from my iPhone
>
>>coming from, is why would we not charter Banana as a WG which is
>>defining an information model that is required to execute banana. So
>>banana defines which information needs to be exchanged and what the
>>banana entities do with it to perform banana
>>though (since I define Bandwidth Aggregation mechanisms in the text).
>>So how about just changing ³protocol² to ³protocol(s)"?:
>> 
>>    OLD:
>> 
>>existing protocol to do part of this job, even if that protocol could
>>not be extended to cover everything we need for BANANA.
>> 
>>    Margaret
>> 
>> 
>> 
>> 
>> 
>>> An aspect that concerns me for a while is the notion that there will
>>>be a single signaling protocol to satisfy a laundry list of
>>>requirements. On first blush this seems to suggest a solution is
>>>already in the wings that needs the laundry list, or that we will end
>>>up with  a bloated superset god protocol. Neither of which is IMO a
>>>totally desirable outcome.
>>> 
>>> No problem, Philip.  I have included the latest text below.  This does
>>>not yet include the changes I am currently discussing with Dave
>>>Sinicrope.
>>> 
>>> 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
>>> 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, VPNs, etc.) have
>>>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.
>>>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 or at the
>>>remote end, and mechanisms for those components to find each other,
>>>exchange signalling information, and direct traffic to each other.   We
>>>refer to the functional components at each end as the Local and Remote
>>>³BANANA Boxes², and we refer to the mechanisms they use to direct
>>>traffic to each other as ³Bandwidth Aggregation mechanisms².
>>> 
>>> [Note:  Despite our use of the term ³Boxes², it should be understood
>>> that a ³BANANA Box² might be a software component running on a piece
>>>    € Determine how Local and Remote BANANA Boxes find each other (i.e.
>>>describe how BANANA boxes will be provisioned/configured.)
>>>listed above.  When an existing protocol is used, the WG deliverable
>>>will be a document describing the use of that protocol for Bandwidth
>>> The BANANA WG will also work with other IETF WGs (and other SDOs, as
>>>requested) that define additional Bandwidth Aggregation mechanisms (if
>>>any)  to ensure that the protocols defined by the BANANA WG will meet
>>>the needs of those additional mechanisms.
>>> 
>>> Milestones
>>> Do folks think this is ready to send to the IESG?  Or are there other
>>>changes that it would make it clearer or better?
>>> 
>>> Margaret
>>

---

From: Margaret Cullen <[email-masked]>
Date: Wed, 27 Sep 2017 11:07:51 -0400

Many people have said, at various times, that they would be very happy to see a presentation or a write-up on how you are using Mobile IP to do bandwidth aggregation.  I would certainly be happy to see other contributions to the group, as well.

> On Sep 26, 2017, at 4:27 PM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
>

---

From: Margaret Cullen <[email-masked]>
Date: Wed, 27 Sep 2017 11:18:44 -0400

Hi Sri,

I understand that you do not support chartering this group.  I think it would be helpful, though, for me and for others, if you could be clear about _why_ you don’t support it.  What “damage” do you think would be caused by the formation of this group? If you could explain that, perhaps we could find some way to do this work without causing that damage?

Multiple other people have raised concerns with the charter, and I have been making modifications to the charter text in an attempt to address those concerns, successfully in some cases.  I would like to do the same for your concerns, if you could help me understand what they are.

Margaret

> On Sep 26, 2017, at 4:38 PM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> 
> <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi Wim,
>> 
>>>> On Sep 25, 2017, at 3:42 PM, David Allan I
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> HI Margaret
>>>> 
>>>> From: Banana [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Margaret
>>>> Cullen
>>>> To: [email-masked] <mailto:[email-masked]>
>>>> Cc: [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/banana <https://www.ietf.org/mailman/listinfo/banana>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 27 Sep 2017 22:23:54 +0000

Hi Margaret,

Sure, Several reasons why I disagree ..  I will state them again and at the risk of repeating myself ..

1. Lack of a clear problem statement – You are attempting to charter this WG by providing a broad solution description and with no identified technical problems or solution approaches.  Various vendors have products supporting this solution and I have identified at least 6 different approaches for realizing this solution and Praveen tells me they have the 7th approach.  Now, you want a charter that allows you (or others chosen for chairing this group) to be in a position where they can standardize any protocol/approach and put an IETF stamp on it. This is not IETF’s business to pick one protocol and call it a “Banana” Solution. This stamping will hurt vendors who may choose not to support what you standardize. So, the idea of a “solution” branding is the issue here and the idea of giving such power to a WG chair is the issue here.  The idea of allowing you to define a new signaling/user-plane protocol with no justification and that's based on your determination is the issue here.

2. The charter that you are trying to propose below is like redefining Mobile IPv6/NEMO functionality and many other things. The idea of peer discovery, prefix allocation, NAT traversal, Traffic Policies ..and all the other extensions that come with it in the form of security, protocol semantics  is not a small efforts, or a charter that 10 people in Banana WG can deliver.  Your only argument for not using existing protocols is about lack of a specification on Per-packet LB. So, you want to reinvent the whole wheel, signaling and user plane… and put a solution stamp. Also, the “banana” solution overlaps with what 3GPP and BBF plans to do with their work item. So, we do not know yet who wants this work.

3. There is also simply no support for this work, IMO. I do understand there were few extra voices in the room in IETF99 that gave few people an impression that people are jumping to do this work, but if you look at the complete picture, last 3 years of history, SDO interest,  email activity, current opposition and the fact that this is being discussed for 3+ years is a good hint on where this should go.

So, I suggest we let this cool down a bit. We need to have conducive environment to discuss and agree on a problem statement.  That time is not now and not over emails. Lets meet in IETF 100 and start those discussions and also include BBF/3GPP folks so they can provide feedback.  You can certainly tweak few lines of charter text and call it a success, but I am certain it will go no where as I don’t see support for this. Charter text discussion at this stage is premature IMO.

Sri

------------

  *

  *
Determine how Local and Remote BANANA Boxes find each other (i.e. describe how BANANA boxes will be provisioned/configured).
  *
Select or specify protocol(s) that can be used to send control information between BANANA Boxes, including:

  *
  *
  *
  *

  *
Select (and extend, if necessary) a tunnel-based method for sending traffic between BANANA Boxes (i.e. specify a tunnel-based Bandwidth Aggregation mechanism).

-----------

From: Margaret Cullen <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 27, 2017 at 8:18 AM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]<mailto:[email-masked]>>, David Allan I <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Banana] Updated Charter

Hi Sri,

Margaret

On Sep 26, 2017, at 4:38 PM, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:

Sri

On 9/26/17, 1:20 PM, "Banana on behalf of Margaret Wasserman"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Wim,

Margaret

Sent from my iPhone

On Sep 26, 2017, at 1:36 AM, Henderickx, Wim (Nokia - BE/Antwerp)
<[email-masked]<mailto:[email-masked]>> wrote:

On 25/09/2017, 22:13, "Banana on behalf of David Allan I"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

  I'd probably be happier losing signaling. IMO it is an overloaded
term...

  WDYT?
  Dave

  -----Original Message-----
  From: Margaret Cullen [mailto:[email-masked]]
  Sent: Monday, September 25, 2017 12:57 PM
  To: David Allan I <[email-masked]<mailto:[email-masked]>>
  Cc: [email-masked]<mailto:[email-masked]>
  Subject: Re: [Banana] Updated Charter

  Good point, Dave!

  OLD:

  NEW:

  Margaret

On Sep 25, 2017, at 3:42 PM, David Allan I
<[email-masked]<mailto:[email-masked]>> wrote:

HI Margaret

Cheers
Dave

From: Banana [mailto:[email-masked]] On Behalf Of Margaret
Cullen
Sent: Monday, September 25, 2017 12:33 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Banana] Updated Charter

Margaret

solutions, and they will be designed to work across NATs and other
middle boxes, as needed.

Milestones

On Sep 25, 2017, at 12:37 PM, <[email-masked]<mailto:[email-masked]>>
<[email-masked]<mailto:[email-masked]>> wrote:

Margaret,

From: Banana [mailto:[email-masked]] On Behalf Of Margaret
Cullen
Sent: 22 September 2017 20:19
To: [email-masked]<mailto:[email-masked]>
Subject: [Banana] Updated Charter

I have updated the charter text in an attempt to reflect all of the
feedback to date.  You can find the new version here:
https://docs.google.com/document/d/1byOJ_To6eL1ZBxKSYpTafQbngTBiNwxaK7
ReIsld9Ek/edit

Thoughts?  Comments?

Margaret

  _______________________________________________
  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

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

---

From: <[email-masked]>
Date: Thu, 28 Sep 2017 09:22:50 +0000

Sri,
My reading of the proposed work is a bit different.
There are several “Bandwidth Aggregation mechanisms” proposed and in products (you have counted 7) - it doesn’t seem likely that we can converge to one solution and that the IETF could standardise “the chosen one”.
The Charter suggests a common protocol to send control information between the Banana boxes, whatever bandwidth aggregation mechanism you choose. It may also be possible to recommend way or ways of finding the other Banana box, again whatever the Bandwidth aggregation mechanism. These seem to me reasonable things to try and do. Do you have an issue with these two items? (I’m not sure). I don’t interpret these work items as “like redefining Mobile Ipv6/NEMO” (I’m not sure if you’re suggesting this – and I’m out of date with Nemo, so may be getting it wrong).
My understanding is that the final item, about a particular bandwidth aggregation solution, is a bit separate and isn’t going to determine what’s chosen for the first two items. I think you have an issue with this final work item, believing it would amount to the IETF rubber stamping a particular solution.
I wouldn’t support work on a problem statement – at least the general reasons for doing bandwidth aggregation seem to be understood.
From your last paragraph, I think you have ideas about what would be good alternative topics for a WG – would be interested in hearing about those.
Best wishes,
phil

From: Banana [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: 27 September 2017 23:24
To: Margaret Cullen <[email-masked]>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; David Allan I <[email-masked]>; [email-masked]
Subject: Re: [Banana] Updated Charter

Hi Margaret,

Sri

------------

  *

  *   Determine how Local and Remote BANANA Boxes find each other (i.e. describe how BANANA boxes will be provisioned/configured).

  *   Select or specify protocol(s) that can be used to send control information between BANANA Boxes, including:

  *   Select (and extend, if necessary) a tunnel-based method for sending traffic between BANANA Boxes (i.e. specify a tunnel-based Bandwidth Aggregation mechanism).
-----------

Hi Sri,

Margaret

Sri

Hi Wim,

Margaret

Sent from my iPhone

  WDYT?
  Dave

  -----Original Message-----
  From: Margaret Cullen [mailto:[email-masked]]
  Sent: Monday, September 25, 2017 12:57 PM
  To: David Allan I <[email-masked]<mailto:[email-masked]>>
  Cc: [email-masked]<mailto:[email-masked]>
  Subject: Re: [Banana] Updated Charter

  Good point, Dave!

  OLD:

  NEW:

  Margaret

HI Margaret

Cheers
Dave

Margaret

Milestones

Margaret,

Thoughts?  Comments?

Margaret

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 28 Sep 2017 16:18:40 +0000

Hi Phil,

We cannot solve market fragmentation issue around protocol use and at least that cannot be the reason for defining a new protocol, or WG creation.  If that is the PS, Wim’s suggestion to focus on an information elements is a great proposal to get all solutions towards a common approach, but not by mandating a specific protocol use.

> The Charter suggests a common protocol to send control information between the Banana boxes, whatever bandwidth aggregation mechanism you choose.

Interestingly, I always thought the only work that can be useful  is about finding better methods for per-packet load balancing when using multiple links; strictly a data plane issue. But, in your view, “bandwidth” aggregation is vendor specific and that is precisely the today’s situation.

Now, lets see what is left. Lets try to frame the discussion without the use of “Banana" terminology and by using some general IP terminology.

--
There is a host/router which has two or more internet facing WAN links. Each of these link are bound to a different access network (Ex: DSL, LTE).  There is an IP address from the access network for each of those interfaces. It can be IPv4/IPv6 address. The device gets its IP address after authenticating to each of the access networks. This device also has an identify and security credentials. Lets call this node as N1. The device also has an ingress network where there are many IP hosts attached.

There is an anchor/gateway/aggregation node in the network which can authenticate/authorize/ the devices such as N1. It has the access/routing/QoS policy. It can do charging, accounting and the necessary business logic. It has interfaces to the backend system. Lets call this as N2.

N1 wants to discover N2; It can be based on DNS FQDN, DNS SRV lookup, DHCP option, an attribute in AAA that comes to the device as part of the access authentication, or a static IP address configured locally.
N1 wants to register with N2. N1 wants to presents its identity, authorize it self. N2 needs to use the identify and check AAA/local DB to authorize N1
N1 wants some flexible way to generate its identify, based on access network, hardware identifiers ..etc
N1 wants to register its reachability with N2. I have IP1 from LTE and IP2 from DSL
N1 wants a ask N2 for a set of prefixes for its ingress network from the anchor. It can obtain/register/negotiate Prefix P1, P2 and P3.
N1 wants an overlay tunnel to N2 over LTE. and another tunnel over DSL So, N2 can forward the traffic bound to N1’s ingress prefixes over an overlay path. Hiding the ingress prefix traffic from the transport topology
N1/N2 wants to continuously check path-reachability/peer-loss over DSL and also over LTE
N1/N2 wants to track all paths of N1 and reachability by using heartbeats; if there is a problem on path, they both need to tear down that overlay tunnel path
N1/N2 wants to negotiate a traffic policy which says, App-1 traffic needs LTE as the most preferred path and DSL as the next preferred path. For App-2, its only DSL or DROP policy.
N1/N2 wants to negotiate an SIPTO policy where certain traffic gets offloaded with NAT translation
N1/N2, in some cases, do no want to negotiate a traffic policy and allow them to use a locally configured policy
N1/N2 wants to negotiate a inband QoS policy; Flow1 gets guaranteed QoS of 128Kbs guaranteed bit-rate, Attributes such GBR and many other attributes
N2 wants to inform N1 about the ingress Prefix P1 getting renumbered to P3.
N1 and N2 wants to secure the overlay tunnel path with some security policies.
----

We have protocols for realizing the above functionality.  We don’t need a new protocol for realizing this. If some one can explain the gap and justification as why this cannot be realized and a need for a brand new protocol, we can certainly have that discussion. Now, if the Ask is for extending a specific protocol, say IKEv2, so the peers can exchange some specific information between N1 and N2, then its a reasonable Ask. But, here what we are asking for is like a laundry list of requirements (peer discovery,  registration, prefix management, mobility, traffic policy management, path performance measurement …etc) and with no justification.

Regards
Sri

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 28, 2017 at 2:22 AM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Banana] Updated Charter

Sri,

From: Banana [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: 27 September 2017 23:24
To: Margaret Cullen <[email-masked]<mailto:[email-masked]>>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; David Allan I <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Banana] Updated Charter

Hi Margaret,

Sri

------------

  *

Hi Sri,

Margaret

Sri

Hi Wim,

Margaret

Sent from my iPhone

  WDYT?
  Dave

  -----Original Message-----
  From: Margaret Cullen [mailto:[email-masked]]
  Sent: Monday, September 25, 2017 12:57 PM
  To: David Allan I <[email-masked]<mailto:[email-masked]>>
  Cc: [email-masked]<mailto:[email-masked]>
  Subject: Re: [Banana] Updated Charter

  Good point, Dave!

  OLD:

  NEW:

  Margaret

HI Margaret

Cheers
Dave

Margaret

Milestones

Margaret,

Thoughts?  Comments?

Margaret

---

From: Margaret Cullen <[email-masked]>
Date: Thu, 28 Sep 2017 14:49:02 -0400

Hi Sri,

> On Sep 28, 2017, at 12:18 PM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> 

The point of standardization, at least IETF standardization, is so that there can be products from multiple vendors that _interoperate_.  In my opinion, this is a case where interoperability would be particularly desirable, especially for situations where bandwidth aggregation is performed over-the-top (as Dave Sinicrope would say), rather than terminating in an operator's network.  The good news is that we already have multiple options for bandwidth aggregation out there, with running code, and they work.  The downside is that they are all proprietary, so they don’t work _together_.  In your terminology, you can only get the benefits of bandwidth aggregation if N1 and N2 were bought from the same vendor, and the goal of this WG would be to fix that.

> N1 wants to discover N2; It can be based on DNS FQDN, DNS SRV lookup, DHCP option, an attribute in AAA that comes to the device as part of the access authentication, or a static IP address configur…

Most of these choices require some sort of standards development work:  a DHCP option, defining a AAA attribute, defining a new DNS SRV type, etc…  None of these things can just magically be used to find “N2” in an interoperable fashion, without some standards work.  Having 6 options is about as useful, for interoperability, as having no option at all.  So, it would be good to define one way that N1 finds N2 (or a limited set of ways, and an order for trying them), so that boxes from different vendors can actually find each other without users having to populate multiple databases, deal with multiple boxes that do different things with the same configuration information,  or configure the same information into half-a-dozen places.  

> N1 wants to register with N2. N1 wants to presents its identity, authorize it self. N2 needs to use the identify and check AAA/local DB to authorize N1 

Or it could use TLS, or DTLS, or…  There are numerous ways to authenticate between boxes, and we won’t get any interoperability until we pick exactly one.  If we wanted to use AAA (RADIUS or Diameter), we would also (at the very least) need to define a service name, and agree to at least one “mandatory to implement” method.  AAA might not be the best choice, though, given that we probably don’t want to limit bandwidth aggregation to the case where N1 and N2 have a single authority or overarching federation to run the AAA infrastructure.  So, a certificate-based or PKI system might be better?  

> N1/N2 wants to continuously check path-reachability/peer-loss over DSL and also over LTE
[…]

These are the sorts of things that require the exchange of control information.  [With the caveat that I don’t think anything should be DSL/LTE-specific, though, or assume that there are exactly two links, or that there is only one “N2” that can reach a given end-node]  Perhaps you are saying that MIP already has a control-information-exchange mechanism that we could use for this?  If so, then great, you should propose it, and we should consider it!  We might need to extend a MIP control-information-exchange to include the information that is needed for per-packet load-balancing and recombination.  If we also used MIP as the tunnel-based Bandwidth Aggregation mechanism, we might also need to extend the MIP tunnel support to include per-packet load balancing and recombination functions — perhaps adding a packet sequence number, for example.  If the proposed BANANA WG decides this is the best approach, perhaps we could work with the DMM WG to standardize those extensions?  There may be other protocols we should consider for this role, though, that don’t have existing IETF WGs.  In those cases, we might do the extensions in the proposed BANANA WG. 

I would also add something that you didn’t include:

There might be more than one Bandwidth Aggregation mechanism available on N1.  For example, we might have an MPTCP-Proxy-based mechanism available that can be used for Bandwidth Aggregation of TCP traffic, and a tunneling mechanism that can handle any IP traffic.  N1 might want to know which mechanisms are available on N2 (or potentially on N3 or N4 if they can be used to reach the same end node), and what types of traffic they can handle.  We might need some mechanism to resolve what traffic will be sent where, etc.  If we envision a world with multiple standard Bandwidth Aggregation mechanisms, we may need to choose at least one mandatory-to-implement Bandwidth Aggregation mechanism that all of N1…Nn will support, so that we can ensure interoperability.

Margaret

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 28 Sep 2017 20:03:02 +0000

Hi Margaret,

> Perhaps you are saying that MIP already has a control-information-exchange mechanism that we could use for this?  If so, then great, you should propose it, and we should consider it!

Multipath/multihoming is a core capability of MIP architecture and if you review the published work/vendor solutions, you can see that. The burden is not on me to prove this. The point is we don’t charter this work with all of these work items and then go decide what to do there. The issue is we still do not know why we are asking for this specific charter.  If the goal is to understand if MIP/or some other protocol is already meeting all the requirements for the use-cases that we never converged, lets charter the work with that exactly one statement. “Explore IETF protocols that are used/suited for supporting multipath requirements; Identify all gaps and recommend extension that needs to be standardized by IETF”.

> The downside is that they are all proprietary, so they don’t work _together_.

The list I gave is a set of features supported today based on MIP RFC standards.  We are confusing folks to mean each of these feature is a different protocol and all are proprietary.  Please identify which aspects are proprietary and lets focus on them, without starting from basics and asking for a new signaling/user-plane protocol that does functionally the same thing. MIP is a control plane protocol and has support for multi-homing. Please let me know exactly what is the non-standard feature in that list and we can fix that.

> Or it could use TLS, or DTLS, or…

Sure. RFC6618 is your starting point

When a protocol support multiple options, say "encapsulation modes, GRE/IP-in-IP/UDP", it does not mean they are non inter-operable, or a bad thing. It means two things. A given deployment/solution based on that protocol may use all modes and the selection of the mode is based on protocol negotiation. It also means an SDO/vendor can limit the features in a profile definition, by being very prescriptive on what is supported in their solution. So, this is a vendor/SDO/solution problem and not an IETF protocol problem.

Sri

From: Margaret Cullen <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 28, 2017 at 11:49 AM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Banana] Updated Charter

Hi Sri,

On Sep 28, 2017, at 12:18 PM, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:

Margaret

---

From: Margaret Cullen <[email-masked]>
Date: Thu, 28 Sep 2017 16:41:20 -0400

> On Sep 28, 2017, at 4:03 PM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> 
> The list I gave is a set of features supported today based on MIP RFC standards.  

I can see how (some of) the MIP technology could apply to (parts of) this problem space in interesting ways.  However, MIP (as it exists in the RFCs I have read, and presumably in most implementations) has several properties that don’t seem like a great fit for a the BANANA problem statement, including:

1) It is focused on mobility, not load balancing, and these aren’t inherently the same thing.  While I can see how you could repurpose some of MIP's mechanisms for load balancing, I don’t see how you could use an arbitrary RFC-compliant implementation for this purpose without modifications.
2) It is flow-based.  I didn’t see any mechanism for recognizing that a single flow has been split across multiple paths, and recombining that flow before forwarding it to the final destination.  
3) Its security model seems to rely on the notion that the destination node and the Home Agent are under the same administrative control.  Maybe RFC 6618 will change my mind about this — I will read it.
4) The home agent is on the “home network” of the destination, not necessarily on the network where the destination is currently located…  I think that bandwidth aggregation needs to have one endpoint on the local network with the end-node, so that it can detect that there is more than one local link to aggregate.  However, even if there was a home agent locally, I am not sure how/if a MIP end-node would find it and associate with it.

It is possible that I am missing something, but if so, then it is very likely that other people are missing it, too.  If you want us to decide that there is no need to specify a flow-based bandwidth aggregation mechanism because MIP already does that, I think you would need to do something to explain _how_ MIP already does that, because it isn’t obvious.

Margaret

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 28 Sep 2017 21:19:41 +0000

We can make very  general statements that MIP is not designed for this, or that and so lets do some thing new. But, we all are very technical people and I hope to see these statements backed by technical data and with detailed analysis. Otherwise, these comments may not mean any thing.

If MIP has lot of options and capabilities, and one does not understand, we should have discussions on that and not charter a WG and define a new protocol. The amount of work that went in Multihoming, IFOM, Security ..etc is not a small effort.  Vendors have deployed solutions and so IETF should have reasons to define alternatives that do the same thing.

Sri

Date: Thursday, September 28, 2017 at 1:41 PM

On Sep 28, 2017, at 4:03 PM, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:

> The downside is that they are all proprietary, so they don't work _together_.

I can see how (some of) the MIP technology could apply to (parts of) this problem space in interesting ways.  However, MIP (as it exists in the RFCs I have read, and presumably in most implementations) has several properties that don't seem like a great fit for a the BANANA problem statement, including:

1) It is focused on mobility, not load balancing, and these aren't inherently the same thing.  While I can see how you could repurpose some of MIP's mechanisms for load balancing, I don't see how you could use an arbitrary RFC-compliant implementation for this purpose without modifications.
2) It is flow-based.  I didn't see any mechanism for recognizing that a single flow has been split across multiple paths, and recombining that flow before forwarding it to the final destination.
3) Its security model seems to rely on the notion that the destination node and the Home Agent are under the same administrative control.  Maybe RFC 6618 will change my mind about this - I will read it.
4) The home agent is on the "home network" of the destination, not necessarily on the network where the destination is currently located...  I think that bandwidth aggregation needs to have one endpoint on the local network with the end-node, so that it can detect that there is more than one local link to aggregate.  However, even if there was a home agent locally, I am not sure how/if a MIP end-node would find it and associate with it.

It is possible that I am missing something, but if so, then it is very likely that other people are missing it, too.  If you want us to decide that there is no need to specify a flow-based bandwidth aggregation mechanism because MIP already does that, I think you would need to do something to explain _how_ MIP already does that, because it isn't obvious.

Margaret

---

From: Margaret Cullen <[email-masked]>
Date: Thu, 28 Sep 2017 18:42:43 -0400

Some of us have been talking about bandwidth aggregation in an open, IETF, non-WG context for about 3 years now.  You were at some of our early meetings, at which we attempted to catalog and review all of the different solutions in this space, and talk about their similarities and differences.  Many people presented their solutions at Bar BOFs or provided pointers to specifications for their solutions, etc.  We asked you to present your MIP-based solutions, but you refused, and you later stopped attending our meetings.   We reviewed the related requirements work from the BBF.  We had several Bar BOFs, an informational BOF, and a WG Forming BOF.  There have been mailing list discussions, shared google docs, etc.  Some of the proposals were improved based on feedback from our meetings, or to incorporate features of other solutions.  Lots of different people from different companies have written drafts for consideration by the proposed WG.  Some of the proprietary solutions have been successfully deployed and are in use by hundreds of thousands of customers.  Researchers have done modeling of the behavior of some of the proposed mechanisms, and have come to interesting conclusions.  At this point we have multiple operators, several vendors and a couple of academic institutions actively engaged in the effort.

You and I are in agreement that people should go through a process of reviewing what is out there before they attempt to charter a WG to do new protocol work.  However, I believe that we have already done the things that  you are currently saying that we need to slow down and do.  It was your choice not to participate in that process, and I don’t think we should be required to do it over, so that you can participate this time.

We presented the results of much of our investigation at the Informational Bar BOF.  That work has lead many of us to the opinion that (1) there is no standards-based solution out there that solves this problem, as-is, (2) there are a number of proprietary solutions based on different standards-based technologies (MIP, MPTCP, GRE, etc.), (3) there is a need for bandwidth aggregation mechanisms that allows a single flow to be balanced across multiple paths, (4) MPTCP and tunneling mechanisms both have advantages and disadvantages, and (4) it would be beneficial to have standards in this space, for interoperability between vendors. 

I suppose that the IAB and IESG could decide that it is a bad idea to standardize a packet-based load balancing mechanism for bandwidth aggregation.  I wouldn’t like that answer, but 

Margaret

> On Sep 28, 2017, at 5:19 PM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> 
> From: Margaret Cullen <[email-masked] <mailto:[email-masked]>>
> To: Microsoft Office User <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> On Sep 28, 2017, at 4:03 PM, Sri Gundavelli (sgundave) <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 28 Sep 2017 23:22:52 +0000

> I suppose that the IAB and IESG could decide that it is a bad idea to standardize a packet-based load balancing mechanism for bandwidth aggregation.  I wouldn’t like that answer, but

We cannot use this one feature as a reason for redefining the entire MIP multi-homing architecture starting with a new signaling protocol and define 20 other extensions. I am sure, the same folks in IAB/IESG will not be delighted to see that WG will duplicate every thing that was done previously and then add this new feature.

I have said it multiple times. If you want to publish an algorithm/analysis on how Per-packet load balancing approach across multiple overlay tunnel paths, as a generalized approach applicable to MobIKE, MIP, Static Tunnels and GTP based architectures, it is absolutely fine. This was Wim’s comment too; to focus on the information elements that tunnel peers can exchange, which can be applied to any signaling protocol.

Its not my absence as an individual, in some what a semi-private meeting (or not governed under any IETF process), is the basis for redefining protocols. Our IETF process cannot be this weak where a small group of people can create alternatives with identical architectures and semantics. All of this confusion is due to the bizarre process adopted in IETF99 to skip PS discussion and focus on charter text which is cluttered with Banana terminology, and providing no data on gap analysis, or on the actual use-cases/PS.

Sri

Date: Thursday, September 28, 2017 at 3:42 PM

Margaret

On Sep 28, 2017, at 5:19 PM, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:

Sri

Margaret

---

From: "Muley, Praveen (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 29 Sep 2017 09:32:20 +0000

All :

 https://www.ietf.org/archive/id/draft-muley-network-based-bonding-hybrid-access-01.txt

This solution uses all existing standards and works in  all combinations of hybrid access  (DSL + LTE )  ( Wifi+LTE)  ( LTE + satellite)  and (5g + 4G) and works with  modems/handsets.  It also covers the approach using combination of solutions such as use of MP-TCP proxy to address packet based load balancing.

Apart from MP-TCP I see MP-QUIC being discussed in QUIC.    In that case  what type of traffic issues are we trying to address by having yet another MP mechanism here in BANANA?   It will be good to know the exact problem or use case which is NOT addressed by any of the other mechanisms  which hurts any of the existing deployments that.

https://datatracker.ietf.org/meeting/99/materials/slides-99-quic-sessb-first-experiments-with-multipath-quic/

In beginning 3 years back when the discussion started, I was very much in support of having common WG to discuss hybrid access problem and in fact had objected to adoption of MIP work getting adopted in DMM working group . But over the years MIP work is progressing in DMM, MP-TCP and MP-QUIC are discussed separately in their respective WG. Now,  It doesn't make sense to reset any of that work now just to start another WG. And in those regards I see Wim's proposal quite reasonable.
                           Since there seems to be concern on clarity of the problem statement among quite a few participants, I would suggest to use IETF 100 to have face to face meeting to hash out the exact problem statement.

-Praveen

From: Banana [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Thursday, September 28, 2017 4:23 PM
To: Margaret Cullen <[email-masked]>
Cc: [email-masked]; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Banana] Updated Charter

> I suppose that the IAB and IESG could decide that it is a bad idea to standardize a packet-based load balancing mechanism for bandwidth aggregation.  I wouldn't like that answer, but

I have said it multiple times. If you want to publish an algorithm/analysis on how Per-packet load balancing approach across multiple overlay tunnel paths, as a generalized approach applicable to MobIKE, MIP, Static Tunnels and GTP based architectures, it is absolutely fine. This was Wim's comment too; to focus on the information elements that tunnel peers can exchange, which can be applied to any signaling protocol.

Sri

You and I are in agreement that people should go through a process of reviewing what is out there before they attempt to charter a WG to do new protocol work.  However, I believe that we have already done the things that  you are currently saying that we need to slow down and do.  It was your choice not to participate in that process, and I don't think we should be required to do it over, so that you can participate this time.

I suppose that the IAB and IESG could decide that it is a bad idea to standardize a packet-based load balancing mechanism for bandwidth aggregation.  I wouldn't like that answer, but

Margaret

Sri

Margaret

---

From: <[email-masked]>
Date: Fri, 29 Sep 2017 10:05:50 +0000

Hi,

Please see inline.

Nic

Von: Banana [mailto:[email-masked]] Im Auftrag von Muley, Praveen (Nokia - US/Mountain View)
Gesendet: Freitag, 29. September 2017 11:32
An: Sri Gundavelli (sgundave) <[email-masked]>; Margaret Cullen <[email-masked]>
Cc: [email-masked]; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; [email-masked]; [email-masked]
Betreff: Re: [Banana] Updated Charter

>
> This solution uses all existing standards and works in  all combinations of hybrid access  (DSL + LTE )  ( Wifi+LTE)  ( LTE + satellite)  and (5g + 4G)
> and works with  modems/handsets.  It also covers the approach using combination of solutions such as use of MP-TCP proxy to address
> packet based load balancing.
>From what I understand this approach assumes a tight integration of Mobile and Fixed network based on a BNG (with the BNG connected to
Mobile Network). This is usually not the case (even if fixed and mobile access are from the same provider).

> Apart from MP-TCP I see MP-QUIC being discussed in QUIC.    In that case  what type of traffic issues are we trying to address by having yet
> another MP mechanism here in BANANA?   It will be  good to know the exact problem or use case which is NOT addressed by any of the
> other mechanisms  which hurts any of the existing deployments that.
I see here the risk that every WG comes up with a specific solution (e.g. for QUIC, MPTCP, ...). The might use different control mechanisms and
even different policies (e.g. QUIC might prefer WLAN over LTE, MPTCP LTE over WLAN).

Regards

Nic

Cc: [email-masked]<mailto:[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Sri

Margaret

Sri

Margaret

---

From: "Muley, Praveen (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 29 Sep 2017 10:54:13 +0000

Hi Nic :
      My comments inline

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, September 29, 2017 3:06 AM
To: Muley, Praveen (Nokia - US/Mountain View) <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; [email-masked]; [email-masked]
Subject: AW: [Banana] Updated Charter

Hi,

Please see inline.

Nic

An: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Margaret Cullen <[email-masked]<mailto:[email-masked]>>

Mobile Network).

PM >> > No this can work exactly how roaming works on S8 ( for mobile ) and in case wireline  bonding will happen in LNS.

This is usually not the case (even if fixed and mobile access are from the same provider).

PM >>> I disagree with your statement  of " usually " since we are engaged with TOP Teir1s from all geography on hybrid access discussions. But I agree some operators MAY have specific positions on this.

Also  if you look at BBF solution discussions they are having converged  5G core with BNG/interworking function talking to AMF/SMF.

PM >>  Concern is fine but this in itself cannot be justification to start a WG. We need to agree to problem which is real and is relevant to deployment.  I don't think QUIC or MP-TCP would ever define affinities. These will be operator policies. Today by using PcRF all operators gets flexibility to define their business plan and similar model will exist while using hybrid access.

Regards,
Praveen

Regards

Nic

Sri

Margaret

Sri

Margaret

---

From: [email-masked]
Date: Fri, 29 Sep 2017 07:30:59 -0400

Hi Praveen,

The document you cited is not an "over-the-top" or link-layer-independent mechanism, as it cites particular elements in an operator network.  It might be possible to change it to be more link-layer independent, though.

The bigger point is that it is not a standard.  Currently, it describes one if several proprietary ideas for how to perform bandwidth aggregation.  I don't remember if this particular one is implemented or deployed, but some of them are.

The point of the WG would be to develop standards in this space for cross-vendor interoperability.

Margaret

Sent from my iPhone

> On Sep 29, 2017, at 5:32 AM, Muley, Praveen (Nokia - US/Mountain View) <[email-masked]> wrote:
> 
> All :
>       
> In beginning 3 years back when the discussion started, I was very much in support of having common WG to discuss hybrid access problem and in fact had objected to adoption of MIP work getting adopted in DMM working group . But over the years MIP work is progressing in DMM, MP-TCP and MP-QUIC are discussed separately in their respective WG. Now,  It doesn’t make sense to reset any of that work now just to start another WG. And in those regards I see Wim’s proposal quite reasonable.
> From: Margaret Cullen <[email-masked]>
> To: Microsoft Office User <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> From: Margaret Cullen <[email-masked]>
> To: Microsoft Office User <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: "Zhangmingui (Martin)" <[email-masked]>
Date: Fri, 29 Sep 2017 11:49:13 +0000

Hi Margaret,

> [With the caveat that I don’t think anything should be DSL/LTE-specific, though, or assume that there are exactly two links, or that there is only one “N2” that can reach a given end-node]

This is a good point. It’s common that providers use multiple aggregation BANANA boxes to achieve load balance. N2 would be a branch router (not the aggregation BANANA box) that adopts anycast mechanism. Suppose the aggregation BANANA boxes behind N2 are N3 and N4, then the tunnel endpoints would be N1-N3 or N1-N4 rather than N1-N2. For this reason, N3 needs to let N1 know he is the real tunnel endpoint. To me, this feature has to be realized by a BANANA control protocol. DNS does not support this feature.

We can also identify several other features that require BANANA control protocol(s).
Bypass is another important feature that requires BANANA control protocol(s). Basically, this requirement requires the two BANANA boxes to use the control protocol to timely exchange the traffic types that need to bypass the two bonding tunnels.

Providers want performance measurement probes to be transmitted along the same path as data packets. These probes will be defined as control messages. Think about the above anycast mechanism. Providers do not expect these probes to be exchanged between N1 and N2. In order to make the probes be exchanged between N1 and N3 (or N4), these control messages (better all the control messages) need to take the same tunnels as data packets. I do not know an existing standard control protocol that meets this requirement and can be used in the BANANA scenario.

If the quality of one of the tunnels downgrades below a certain level (e.g., the measured RTT exceeds 300ms), the two BANANA boxes have to agree on to disable this tunnel instantly while remain the other tunnel. This action has to be executed relying on the control protocol. Is there an existing standard control protocol already supports this feature. I don’t think so.

Thanks,
Mingui

From: Banana [mailto:[email-masked]] On Behalf Of Margaret Cullen
Sent: Friday, September 29, 2017 2:49 AM
To: Sri Gundavelli (sgundave)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Banana] Updated Charter

Hi Sri,

Margaret

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 29 Sep 2017 13:04:02 +0000

Hi Nic,

On Sep 29, 2017, at 3:06 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

I see here the risk that every WG comes up with a specific solution (e.g. for QUIC, MPTCP, …). The might use different control mechanisms and
even different policies (e.g. QUIC might prefer WLAN over LTE, MPTCP LTE over WLAN).

There will never be one God protocol which is the protocol for a solution. QUIC/MPTCP/MobIKE/MIP/SSL/GTP are all candidate protocols that will be enhanced and deployed for multipath related solutions. We cannot stop them from extending those protocols.

We are mixing interoperability within a protocol, with interoperability across solutions.
IETF is not in the business of mandating a specific protocol for a solution, or strive for a single solution across internet. A vendor/SDO may use "n" of protocols of his choice for a solution. We only ensure interoperability within a protocol and not interoperability across solutions. Again, IETF has not standardized "the routing protocol", or "the IPv6 transitioning protocol" and there will never be, "The Banana protocol".

Sri

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 29 Sep 2017 09:31:39 -0400

Hi Sri,

BANANA is the name of a proposed WG, not a protocol.  The candidates have multiple different names.  What the final protocols, extensions or options would be called is unknown, especially if they result from the merger of multiple proposals, but I doubt any of them would be called "BANANA"...  

There is a value to having a standard, even if multiple proprietary approaches continue to exist, IMO.

Margaret

Sent from my iPhone

> On Sep 29, 2017, at 9:04 AM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> 
> Hi Nic,
> 
> On Sep 29, 2017, at 3:06 AM, "[email-masked]" <[email-masked]> wrote:
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 29 Sep 2017 13:48:12 +0000

Hi Margaret,

Various enterprises use various type of VPN solutions. Some are based on IPsec, some on SSL and some on SSH.. etc. Those are non-interoperable across solutions, but some are interoperable within a solution, when using the same protocol.

To address this issue, IETF did not go create a "VPN working group" and argued that all are proprietary solutions and so we need a single interoperable solution, based on the protocol we choose.  So, what you have been asking for three years is some thing new  We probably should bring this Banana discussion in IETF plenary and ask IETF to change their work scope.

Sri

On Sep 29, 2017, at 6:31 AM, Margaret Wasserman <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sri,

Margaret

Sent from my iPhone

On Sep 29, 2017, at 9:04 AM, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Nic,

Sri

---

From: Florin Baboescu <[email-masked]>
Date: Fri, 29 Sep 2017 13:53:11 -0700

Hi Margaret, Mingui,

Very unfortunate pick of the naming convention in the examples below.
Consider that the N1-N4 have all a very clear meaning in the 5G System
architecture. Anyway, going back to the content, you mentioned below:

“Providers want performance measurement probes to be transmitted along the
same path as data packets. These probes will be defined as control
messages. Think about the above anycast mechanism. Providers do not expect
these probes to be exchanged between N1 and N2. In order to make the probes
be exchanged between N1 and N3 (or N4), these control messages (better all
the control messages) need to take the same tunnels as data packets. I do
not know an existing standard control protocol that meets this requirement
and can be used in the BANANA scenario. ”

There are already various tools for peer loss/path loss/path performance
measurements that IETF has standardized and that have already been in used
in various vendor solutions. Probes can be sent over a tunnel or on normal
transport path. Why exactly do I need a new one?

Thanks,

-Florin

*From:* Banana [mailto:[email-masked]] *On Behalf Of *Zhangmingui
(Martin)
*Sent:* Friday, September 29, 2017 4:49 AM
*To:* Margaret Cullen <[email-masked]>; Sri Gundavelli (sgundave) <
[email-masked]>
*Cc:* [email-masked]; [email-masked];
[email-masked]; [email-masked]
*Subject:* Re: [Banana] Updated Charter

Hi Margaret,

> [With the caveat that I don’t think anything should be DSL/LTE-specific,
though, or assume that there are exactly two links, or that there is only
one “N2” that can reach a given end-node]

This is a good point. It’s common that providers use multiple aggregation
BANANA boxes to achieve load balance. N2 would be a branch router (not the
aggregation BANANA box) that adopts anycast mechanism. Suppose the
aggregation BANANA boxes behind N2 are N3 and N4, then the tunnel endpoints
would be N1-N3 or N1-N4 rather than N1-N2. For this reason, N3 needs to let
N1 know he is the real tunnel endpoint. To me, this feature has to be
realized by a BANANA control protocol. DNS does not support this feature.

We can also identify several other features that require BANANA control
protocol(s).

Bypass is another important feature that requires BANANA control
protocol(s). Basically, this requirement requires the two BANANA boxes to
use the control protocol to timely exchange the traffic types that need to
bypass the two bonding tunnels.

Providers want performance measurement probes to be transmitted along the
same path as data packets. These probes will be defined as control
messages. Think about the above anycast mechanism. Providers do not expect
these probes to be exchanged between N1 and N2. In order to make the probes
be exchanged between N1 and N3 (or N4), these control messages (better all
the control messages) need to take the same tunnels as data packets. I do
not know an existing standard control protocol that meets this requirement
and can be used in the BANANA scenario.

If the quality of one of the tunnels downgrades below a certain level
(e.g., the measured RTT exceeds 300ms), the two BANANA boxes have to agree
on to disable this tunnel instantly while remain the other tunnel. This
action has to be executed relying on the control protocol. Is there an
existing standard control protocol already supports this feature. I don’t
think so.

Thanks,

Mingui

*From:* Banana [mailto:[email-masked] <[email-masked]>] *On
Behalf Of *Margaret Cullen
*Sent:* Friday, September 29, 2017 2:49 AM
*To:* Sri Gundavelli (sgundave)
*Cc:* [email-masked]; [email-masked];
[email-masked]; [email-masked]
*Subject:* Re: [Banana] Updated Charter

Hi Sri,

On Sep 28, 2017, at 12:18 PM, Sri Gundavelli (sgundave) <[email-masked]>
wrote:

We cannot solve market fragmentation issue around protocol use and at least
that cannot be the reason for defining a new protocol, or WG creation.  If
that is the PS, Wim’s suggestion to focus on an information elements is a
great proposal to get all solutions towards a common approach, but not by
mandating a specific protocol use.

The point of standardization, at least IETF standardization, is so that
there can be products from multiple vendors that _interoperate_.  In my
opinion, this is a case where interoperability would be particularly
desirable, especially for situations where bandwidth aggregation is
performed over-the-top (as Dave Sinicrope would say), rather than
terminating in an operator's network.  The good news is that we already
have multiple options for bandwidth aggregation out there, with running
code, and they work.  The downside is that they are all proprietary, so
they don’t work _together_.  In your terminology, you can only get the
benefits of bandwidth aggregation if N1 and N2 were bought from the same
vendor, and the goal of this WG would be to fix that.

N1 wants to discover N2; It can be based on DNS FQDN, DNS SRV lookup, DHCP
option, an attribute in AAA that comes to the device as part of the access
authentication, or a static IP address configured locally.

Most of these choices require some sort of standards development work:  a
DHCP option, defining a AAA attribute, defining a new DNS SRV type, etc…
 None of these things can just magically be used to find “N2” in an
interoperable fashion, without some standards work.  Having 6 options is
about as useful, for interoperability, as having no option at all.  So, it
would be good to define one way that N1 finds N2 (or a limited set of ways,
and an order for trying them), so that boxes from different vendors can
actually find each other without users having to populate multiple
databases, deal with multiple boxes that do different things with the same
configuration information,  or configure the same information into
half-a-dozen places.

N1 wants to register with N2. N1 wants to presents its identity, authorize
it self. N2 needs to use the identify and check AAA/local DB to authorize
N1

Or it could use TLS, or DTLS, or…  There are numerous ways to authenticate
between boxes, and we won’t get any interoperability until we pick exactly
one.  If we wanted to use AAA (RADIUS or Diameter), we would also (at the
very least) need to define a service name, and agree to at least one “mandatory
to implement” method.  AAA might not be the best choice, though, given that
we probably don’t want to limit bandwidth aggregation to the case where N1
and N2 have a single authority or overarching federation to run the AAA
infrastructure.  So, a certificate-based or PKI system might be better?

N1 wants some flexible way to generate its identify, based on access
network, hardware identifiers ..etc

N1 wants to register its reachability with N2. I have IP1 from LTE and IP2
from DSL

N1 wants a ask N2 for a set of prefixes for its ingress network from the
anchor. It can obtain/register/negotiate Prefix P1, P2 and P3.

N1 wants an overlay tunnel to N2 over LTE. and another tunnel over DSL So,
N2 can forward the traffic bound to N1’s ingress prefixes over an overlay
path. Hiding the ingress prefix traffic from the transport topology

N1/N2 wants to continuously check path-reachability/peer-loss over DSL and
also over LTE

[…]

These are the sorts of things that require the exchange of control
information.  [With the caveat that I don’t think anything should be
DSL/LTE-specific, though, or assume that there are exactly two links, or
that there is only one “N2” that can reach a given end-node]  Perhaps you
are saying that MIP already has a control-information-exchange mechanism
that we could use for this?  If so, then great, you should propose it, and
we should consider it!  We might need to extend a MIP
control-information-exchange to include the information that is needed for
per-packet load-balancing and recombination.  If we also used MIP as the
tunnel-based Bandwidth Aggregation mechanism, we might also need to extend
the MIP tunnel support to include per-packet load balancing and
recombination functions — perhaps adding a packet sequence number, for
example.  If the proposed BANANA WG decides this is the best approach,
perhaps we could work with the DMM WG to standardize those extensions?
There may be other protocols we should consider for this role, though, that
don’t have existing IETF WGs.  In those cases, we might do the extensions
in the proposed BANANA WG.

There might be more than one Bandwidth Aggregation mechanism available on
N1.  For example, we might have an MPTCP-Proxy-based mechanism available
that can be used for Bandwidth Aggregation of TCP traffic, and a tunneling
mechanism that can handle any IP traffic.  N1 might want to know which
mechanisms are available on N2 (or potentially on N3 or N4 if they can be
used to reach the same end node), and what types of traffic they can
handle.  We might need some mechanism to resolve what traffic will be sent
where, etc.  If we envision a world with multiple standard Bandwidth
Aggregation mechanisms, we may need to choose at least one
mandatory-to-implement Bandwidth Aggregation mechanism that all of N1…Nn
will support, so that we can ensure interoperability.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 29 Sep 2017 17:09:19 -0400

Sent from my iPhone
> On Sep 29, 2017, at 4:53 PM, Florin Baboescu <[email-masked]> wrote:
> 
> Hi Margaret, Mingui,
>  
> Very unfortunate pick of the naming convention in the examples below. Consider that the N1-N4 have all a very clear meaning in the 5G System architecture. Anyway, going back to the content, you mentioned below:

The examples and naming were not mine.  They were names picked by Sri, which I took to be arbitrary system names.  If Sri meant to refer to particular system components, I didn't realize that.  

Margaret

> “Providers want performance measurement probes to be transmitted along the same path as data packets. These probes will be defined as control messages. Think about the above anycast mechanism. Providers do not expect these probes to be exchanged between N1 and N2. In order to make the probes be exchanged between N1 and N3 (or N4), these control messages (better all the control messages) need to take the same tunnels as data packets. I do not know an existing standard control protocol that meets this requirement and can be used in the BANANA scenario. ”
> There are already various tools for peer loss/path loss/path performance measurements that IETF has standardized and that have already been in used in various vendor solutions. Probes can be sent over a tunnel or on normal transport path. Why exactly do I need a new one?
> Thanks,
> -Florin
>  
>  
>  
> From: Banana [mailto:[email-masked]] On Behalf Of Zhangmingui (Martin)
> Sent: Friday, September 29, 2017 4:49 AM
> To: Margaret Cullen <[email-masked]>; Sri Gundavelli (sgundave) <[email-masked]>

---

From: Florin Baboescu <[email-masked]>
Date: Fri, 29 Sep 2017 14:10:21 -0700

Hi Margaret,

I share similar opinion with the comments posted by Praveen and Sri below,
so I’m not going to go through the same comments again. However, I cannot
avoid coming back to the same comment/suggestion I had last week.

As you may remember, I expressed my concerns that the IETF is trying to
step into proposing one or more solutions that has already been covered by
both 3GPP and BBF. Unfortunately, in the case of IETF, I somehow miss
seeing proper requirements or problem statement(s), for which a consensus
can be achieved. Furthermore, a solution that introduces an aggregation
point in the 3GPP architecture, requires some more discussion and
understanding. But again, this is a discussion we may get into only if we
get an agreement first on what are we actually trying to solve!

Therefore, as I suggested earlier, if progress is to be made, let’s start
with the basics, which is to work on a set of requirements and a problem
statement that we all can agree. This should be the only scope of  the
conversation at least in the next IETF meeting.

Thank you.

-Florin

*From:* Banana [mailto:[email-masked]] *On Behalf Of *Sri
Gundavelli (sgundave)
*Sent:* Friday, September 29, 2017 6:48 AM
*To:* Margaret Wasserman <[email-masked]>
*Cc:* [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
*Subject:* Re: [Banana] Updated Charter

Hi Margaret,

There is a value to having a standard, even if multiple proprietary
approaches continue to exist, IMO.

Various enterprises use various type of VPN solutions. Some are based on
IPsec, some on SSL and some on SSH.. etc. Those are non-interoperable
across solutions, but some are interoperable within a solution, when using
the same protocol.

To address this issue, IETF did not go create a "VPN working group" and
argued that all are proprietary solutions and so we need a single
interoperable solution, based on the protocol we choose.  So, what you have
been asking for three years is some thing new  We probably should bring
this Banana discussion in IETF plenary and ask IETF to change their work
scope.

Sri

On Sep 29, 2017, at 6:31 AM, Margaret Wasserman <[email-masked]>
wrote:

Hi Sri,

BANANA is the name of a proposed WG, not a protocol.  The candidates have
multiple different names.  What the final protocols, extensions or options
would be called is unknown, especially if they result from the merger of
multiple proposals, but I doubt any of them would be called "BANANA"...

There is a value to having a standard, even if multiple proprietary
approaches continue to exist, IMO.

Margaret

Sent from my iPhone

On Sep 29, 2017, at 9:04 AM, Sri Gundavelli (sgundave) <[email-masked]>
wrote:

Hi Nic,

On Sep 29, 2017, at 3:06 AM, "[email-masked]" <[email-masked]>
wrote:

I see here the risk that every WG comes up with a specific solution (e.g.
for QUIC, MPTCP, …). The might use different control mechanisms and

even different policies (e.g. QUIC might prefer WLAN over LTE, MPTCP LTE
over WLAN).

There will never be one God protocol which is the protocol for a solution.
QUIC/MPTCP/MobIKE/MIP/SSL/GTP are all candidate protocols that will be
enhanced and deployed for multipath related solutions. We cannot stop them
from extending those protocols.

We are mixing interoperability within a protocol, with interoperability
across solutions.

IETF is not in the business of mandating a specific protocol for a
solution, or strive for a single solution across internet. A vendor/SDO may
use "n" of protocols of his choice for a solution. We only ensure
interoperability within a protocol and not interoperability across
solutions. Again, IETF has not standardized "the routing protocol", or "the
IPv6 transitioning protocol" and there will never be, "The Banana
protocol".

Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sat, 30 Sep 2017 05:27:21 +0000

Hi Mingui,

You talked about three new technical requirements for “Banana” solution. I thought I will provide my comments on those three requirements and how they are realized today. See inline …

From: "Zhangmingui (Martin)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 29, 2017 at 4:49 AM
To: Margaret Cullen <[email-masked]<mailto:[email-masked]>>, Microsoft Office User <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Banana] Updated Charter

Hi Margaret,

[Sri] Your ingress prefix comes from an anchor. Now, if you have 10 remote sites with an anchor in each site and if you want the CPE to use all the anchors, you need prefixes from each of those anchors. So, its not clear how the source address selection works, or many prefixes will you host on the network behind the CPE. May be you meant some thing else, but this requirement is not clear to me.

But, if you are pointing to an anchor-less model, probably LISP is the protocol for you. There, encap selection is based on destination address.  LISP has no concept of an anchor, but uses tunnels and encap selection is based on destination address. LISP  also has multipath support and so that would be a great protocol for this solution.

[Sri] This property is there in mobile architecture and typically referred to as SIPTO. Look at RFC 6909 (https://tools.ietf.org/html/rfc6909)
is a good starting point.  Note that the ingress prefixes are topologically anchored on the anchor and so for that traffic to skip the tunnel, they need to be NAT translated.

[Sri] As Florin pointed out, there are many performance measurement tools/probes that are out there.  IPPM guys have published a number of RFC’s in this space.

https://datatracker.ietf.org/wg/ippm/documents/

These tools can measure various aspects at a very granular level. You can send probes over L3/L4  tunnels, or non-tunnel path. You can send probes of certain protocol type, frequency, with certain DSCP markings, certain packet sizes .. and you can measure various performance aspects (jitter, MOS, packet loss …etc). You can configure these tools independent of the multipath feature, but the reports from these measurements influence the protocol states of other protocols.

You may want the tunnel to be torn down when the latency exceeds 300 milli-secs, but in some other deployment they want the tunnel to be torn down when the voice MOS measurement falls below certain value. So, this is not about a “standard", its more about configuration and a deployment knob.

We do use these tools in cisco products supporting hybrid access solutions.

Thanks,
Mingui

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Sri,

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 30 Sep 2017 09:39:37 -0400

Hi Florin,

> On Sep 29, 2017, at 5:10 PM, Florin Baboescu <[email-masked]> wrote:
> 
> Hi Margaret,
>  
> I share similar opinion with the comments posted by Praveen and Sri below, so I’m not going to go through the same comments again. However, I cannot avoid coming back to the same comment/suggestion I had last week.
> As you may remember, I expressed my concerns that the IETF is trying to step into proposing one or more solutions that has already been covered by both 3GPP and BBF. Unfortunately, in the case of IETF, I somehow miss seeing proper requirements or problem statement(s), for which a consensus can be achieved. Furthermore, a solution that introduces an aggregation point in the 3GPP architecture, requires some more discussion and understanding. But again, this is a discussion we may get into only if we get an agreement first on what are we actually trying to solve!

The IETF would not be working on a mechanism that involves introducing anything into the 3GPP network.  The BBF and 3GPP are working on solutions of that sort, using a non-IETF-defined, 3GPP-specific bandwidth aggregation mechanism.

As our charter text clearly states (in multiple places now), the IETF would be working on an IP-based, link-layer-independent, OTT bandwidth aggregation mechanism that does not require that the aggregated links be from a single provider or a set of cooperating providers.  We will not even assume, therefore that any of the aggregated links _are_ 3GPP links, never mind require changes to the 3GPP network.

It is the job of the BBF and the 3GPP to decide on DSL and 3GPP network architecture.  The IETF writes more widely-applicable standards for the Internet, in general.  The BBF and the 3GPP (like many other SDOs) often use our standards (and other standards, including their own) to produce network architectures that specify where in the DSL or 3GPP network a particular protocol will be run.

Sri continues to state that we are doing something 3GPP-specific due to statements in an expired draft that didn't accurately represent the view of the group about the scope of our work at the time it was written.
Our charter text describes what we are actually planning to do.

If you think the charter text is unclear about this distinction in some way, please suggest edits to make it clearer.

Thanks,
Margaret

>  
> Therefore, as I suggested earlier, if progress is to be made, let’s start with the basics, which is to work on a set of requirements and a problem statement that we all can agree. This should be the only scope of  the conversation at least in the next IETF meeting.
>  
> Thank you.
> -Florin
>  
>  
>  
> Sent: Friday, September 29, 2017 6:48 AM
> To: Margaret Wasserman <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> On Sep 29, 2017, at 6:31 AM, Margaret Wasserman <[email-masked]> wrote:
> 
> Hi Sri,
>

---

From: "Muley, Praveen (Nokia - US/Mountain View)" <[email-masked]>
Date: Sat, 30 Sep 2017 22:20:03 +0000

Hi Margaret :
      My comments inline

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, September 29, 2017 4:31 AM
To: Muley, Praveen (Nokia - US/Mountain View) <[email-masked]>
Cc: Sri Gundavelli (sgundave) <[email-masked]>; Margaret Cullen <[email-masked]>; [email-masked]; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Banana] Updated Charter

Hi Praveen,

The bigger point is that it is not a standard.
PM >> Can you please elaborate this comment ?  All the interfaces shown are standard. That’s why the draft is informational. Draft doesn’t ask for any new extensions.

Currently, it describes one if several proprietary ideas for how to perform bandwidth aggregation.  I don't remember if this particular one is implemented or deployed, but some of them are.

PM >> This is implemented across all Nokia product lines relevant to this space and the co-author list on draft shows acceptance across carrier space.

PM >>  But that also is goal of MP-TCP/MP-QUIC.  In fact if you have to do over the top solution for packet based distribution, then good candidates are MP-TCP/MP-QUIC as at least there is NO  firewall which will block that traffic. Any other encaps MAY need co-operation from the other carriers to allow such traffic.
            My concern on charter is we approaching this as BANANA solution and there are several components like discovery/signaling etc. IETF never had BNG like working group to solve all BNG related issues which are somewhat similar to this BANANA GW.  BNG uses set of protocols  and for each of them you have specific WG. IP address can be allocated using Radius/DHCP but there are different WGs dealing with those extensions. Similarly here there are different WGs working on solution and eventually market will decide which one they are interested in pursuing based on use cases deployment/legacy concerns etc.
                               And in this context its more important to scope out our problem statement and see what is missing in existing solutions.  Answer to some these questions will help us agree on charter text.
-Praveen

Margaret

Sent from my iPhone

On Sep 29, 2017, at 5:32 AM, Muley, Praveen (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>> wrote:
All :

-Praveen

Sri

Margaret

Sri

Margaret

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sun, 1 Oct 2017 01:02:46 +0000

MIP/MobIKE/LISP/ (also Static tunnels) are all over the top approaches. They are access technology agnostic and do not require support from the access network and can operate on any type of network.  Multihoming is a key capability in these protocols and they all provide mechanisms for establishing multiple (yes, 2 or more) overlay tunnel paths.  How the traffic is distributed between these overlay paths is based on configuration, or based on the exchange of traffic flow spec.

MIP, while its access agnostic, also has the capability to leverage the transport QoS provided by a specific access network. For example QoS interworking for 3GPP and WiFi (WMM AC) is specified in:

https://tools.ietf.org/html/rfc7222
https://tools.ietf.org/html/rfc7561

So, vendors can pick protocol of their choice for building a "Multihoming” solution and there are solutions from multiple vendors; each solution interoperable when confirmed to the respective protocols.

So, after weeks of discussions,  I am still clueless on what exactly are we solving here in Banana and the problem statement.

Sri

From: "Muley, Praveen (Nokia - US/Mountain View)" <[email-masked]<mailto:[email-masked]>>
Date: Saturday, September 30, 2017 at 3:20 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Microsoft Office User <[email-masked]<mailto:[email-masked]>>, Margaret Cullen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Banana] Updated Charter

Hi Margaret :
      My comments inline

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, September 29, 2017 4:31 AM
To: Muley, Praveen (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>
Cc: Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>>; Margaret Cullen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Banana] Updated Charter

Hi Praveen,

Margaret

Sent from my iPhone

-Praveen

Sri

Margaret

Sri

Margaret