Re: [Banana] Charter

[Margaret Cullen <[e-mail]>]

Hi Dave,

> On Sep 25, 2017, at 2:12 PM, David Sinicrope <[e-mail]> wrote:
> 
> Margaret,
>  
> https://www.broadband-forum.org/standards-and-software/downloads/technical-work-in-progress
> I believe you may be looking for WT-378 The solutions document for TR-348 - Hybrid Access Broadband Network Architecture for the home and business.  See the public link above. (Note: the video is home centric, but my understanding is that the work is broader in scope.)  This is the only public description I’m aware of.  (Admittedly, it could say more.)

Thank you.  Yes, this is the sort of thing I was looking for.  I will look at the videos and try to better familiarize myself with this work.

At this point, I think we are in (at least rough) agreement about the spaces in which the proposed BANANA group and the BBF/5G group could work in ways that are not in conflict with one another.  Fortunately for us, I think those are also the spaces in which we both wanted and intended to work!  The difficulty lies in putting the concepts into words that will make this clear to everyone.

We may differ on one point, which is that if the only two solutions that exist in the world are the BBF/5G solution and our generic, OTT solution, non-5G providers may choose to use our solution to aggregate their customers links (e.g. a Cable/LTE combination).  While that isn’t the main scenario for which we would be designing a BANANA solution, I don’t think we should do anything to stop that from working.  Do you?

> From the Google Doc: “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.”
>  
> - instead of “…support dynamic path selection on a per-packet basis in networks that have more than one point of attachment to the Internet”,  I suggest: “…support dynamic path selection on a per-packet basis for user equipment with more than one point of access to the Internet without operator involvement in the aggregation. (i.e., ‘Over The Top’ (OTT) environment).”  This, in my opinion, describes the “OTT” case. I’d be interested to hear from others whether this is sufficient to describe OTT.
>  
> To further support the distinction, anywhere “Internet links” or “link” shows up, it should be change to “Internet access services”.
>  
> Also, I recommend changing: “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). “
> To
> “The Bandwidth Aggregation solutions developed in this working group are designed for scenarios where a user or customer wishes to aggregate multiple independent Internet access services that are agnostic of each other. (i.e. the aggregated Internet access services are not provided by a single Internet access provider nor by multiple cooperating providers).”

Terms like “internet access services” are not widely used in the IETF, and I am not sure I want to introduce that term in this charter.

More importantly, we don't prescribe nor proscribe a business model for our protocols (e.g. say that something will run on user equipment vs. equipment owned by someone else, etc.) — we make all of our protocols safe to run over the Internet, and we enable end-users, operators, system integrators, vendors, service providers, and other SDOs to specify, implement and use them wherever they are useful.  

I do think I understand what you are driving at, though, so let’s see if I can come up with a way to say it without making it sound like the IETF is trying to dictate where (in the Internet topology) the resulting protocols can and cannot be used.  

How about this?:

OLD:

	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.

NEW:

	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 Internet 
	Service Provider, and without cooperation between a set of Internet Service 
	Providers (i.e. these will be Over-The-Top (OTT) solutions).

And this?:

OLD:

	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.


NEW:

	The Bandwidth Aggregation solution(s) developed in this 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 
	all of 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 group will be IP-based, link-layer-independent solutions, and 
	they will be designed to work across NATs and other middle boxes, as needed.

Would those changes capture your points?  Or am I still missing something important?

>  Also regarding other SDOs:  From the Google Doc: “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.”
> - What is meant here by “mechanisms”?  Thinking in the BBF context, I would have assumed “mechanism” to be a protocol or protocol extension and that these would prefer to be done in IETF rather than elsewhere.  For the BBF context, it seems like the word “mechanism” could/should be substituted for “solution”.  Are there other SDOs that would define aggregation protocols that BANANA would work with?  (e.g., MP-TCP?)   Assuming yes, perhaps two points to be made in this paragraph then: A. work with other SDOs defining solutions to ensure no conflict; B. work with other WGs & SDOs defining protocol mechanisms to consider their needs.

“Mechanisms" is the word I used to replace “Encapsulations”, because some people thought that “Encapsulations” automatically implied tunneling.  I will try to be clearer, as this change definitely made things less clear in this particular paragraph.

> I suggest changing the text to:
> “The BANANA WG will also work with other IETF WGs, and other SDOs, as requested, that: A. define Bandwidth Aggregation solutions (e.g., Broadband Forum) to ensure that the solutions defined by the BANANA WG avoid conflict.  B. define additional Bandwidth Aggregation mechanisms in a way that ensures that the protocols adopted and possibly enhanced by the BANANA WG will consider the needs of the other organizations.”

I agree with what you are sayingthere, and will attempt to incorporate this edit.  I am also thinking that just being more direct here might be better — referencing the actual BBF/5G work by name, and saying that we will work with that group, as needed, to resolve any conflicts or concerns, perhaps.  Is there a 3GPP moniker for this group that I should also include?

How about this?:

OLD:

	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.

NEW:

	The BANANA WG will work with other IETF WGs that define "Bandwidth
	Aggregation mechanisms" (as defined above), to ensure that the
	provisioning and signaling protocols selected or specified by the BANANA 
	WG 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.

How do those changes look to you?  What do other people think?

Margaret