Re: [Banana] Charter

[David Sinicrope <[e-mail]>]

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.  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.  You say below that “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.  “



The solutions and solution architectures that are normally produced by the BBF also do not pre/proscribe business model (how a service is packaged and offered), but in providing an architecture they do place function in the network, and determine who has ownership & control of it (management, signaling, etc).  This seems to imply that in the charter when you use the word solution, you are talking more about protocols and not what I would consider solution architecture.  This seems to be supported by the work items listed in the draft charter, with the possible exception of the usage scenarios. 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?



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?



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