Re: [Banana] Charter

[Margaret Wasserman <[e-mail]>]

Hi Dave,

> On Sep 25, 2017, at 5:00 PM, David Sinicrope <[e-mail]> wrote:
> 
> Hi Margaret,
> Before I go through your new proposed text I’m hoping you can help me with some questions.
>  
> Can you elaborate on what you mean by “non-5G providers” below?  This and the “/” in your term “BBF/5G solution” seems to indicate a perception that the BBF solution (TR-348, WT-378) and the BBF work with 3GPP are inseparable and only apply to 5G. 

I had been told they were specific to 5G, but maybe they are more generic DSL/LTE solutions?  My point is that if the solutions you provide assume the presence of LTE and/or DSL interfaces, they won't work for people who don't have those types of interfaces, right?  So, those people might use BANANA instead.

Obviously,  our charter will not discuss the technical details of your solutions.  I want to understand them, but the BANANA charter doesn't have to block  on me understanding them.

> Maybe I’m reading too much into this, but just to be clear, I’m pretty sure, e.g., given the timeframe for the projects, that the TR-348 and WT-348 work applies to previous generations of mobile and fixed networks and can be used in a 5G environment as well. 
>  
> Another thing I/we may be disconnected on is the word “solution” used in the charter. 

I do not think we use the term solution in the same way that you do.  Even when we do an architecture document, it is a "boxes and arrows" document that shows the major logical elements, message flow, etc.  It doesn't talk about who owns what, where in the Internet topology the boxes will be situated, who owns them, etc.  I think everything we do falls into what you call "protocols".

Our usage scenarios will be for reference and common understanding only.  They won't be a normative part of the protocols, nor will they be published in an RFC or other archival form.

>  Yet I would think defining and scoping BANANA to an OTT environment would involve both, the definition of the architecture (even if only a reference architecture), including intended placement of the function, and also the definition/extension of whatever protocols are used.  I’m having trouble seeing how this reconciles with your statement above.  Can you help clarify?

When you write a protocol, you design it based on assumptions about the environment in which it will be used.  We would write protocols that are IP-based, link-layer-technology-independent, and that don't not require any cooperation between the providers of the aggregated links to function.  Our assumption will be that the remote and local BANANA boxes are across an arbitrary span of Internet from each other.  We don't have any means to control where the BANANA protocols will actually be implemented or used, though.  

> The one thing I see missing from your reply is where a liaison will be sent to the BBF asking for the information you are requesting.
> What are your plans for progressing this liaison? 

As I thought I said earlier, it is my understanding that Suresh will handle whatever communication is needed with other standards bodies as part of the IESG/IAB review.  So, I don't think that this will happen until after the charter is submitted to the IESG.  Suresh can correct me if I am wrong.

Margaret
>  
> Thanks,
> Dave
> BBF/IETF Liaison Manager
>  
> On 9/25/17, 3:53 PM, "Margaret Cullen" <[e-mail]> wrote:
>  
>     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
>    
>