Re: [Banana] Charter

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.)

To get an accurate description and the latest information on their work and its status, I recommend liaising the BANANA draft charter to the BBF and ask them for more information on their work in this space, including their project with 3GPP.  In my opinion, asking them directly would get the most accurate information possible and would be the most help in crafting charter text to avoid overlap.  Given the BBF history with focus on requirements, solutions and architecture rather than protocol design, I can understand the impression you mention below.

I support recommending to the IESG that BBF be kept apprised of all ongoing BANANA work and output.

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

I took another look at the Google Doc version of the charter (as of 11:30 EDT today).  Below are some comments regarding the BBF overlap concern:

(Note: These are my personal suggestions i.e., they don’t reflect a representation, opinion or view of the Broadband Forum or its members)

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).”

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.

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.”

Please let me know if you have questions.

Regards,

Dave

BBF/IETF Liaison Manager

On 9/25/17, 10:25 AM, "Margaret Cullen" <margaretw42@gmail.com> wrote:

    Hi Dave,

    I am still trying to find a charter or other description of the BBF/5G protocol work, so that we can potentially reference it in our charter, and so that I can make a recommendation to the IESG regarding what group(s) should be apprised of this work.

    As I mentioned, I am not a member of the BBF, but I have asked some members to help me find a pointer to this charter, and they couldn’t find it either.  They only found the charter for the requirements work.  They were also under the impression that the BBF doesn’t do this sort of protocol work?  Has the protocol work actually been chartered in the 3GPP?  If so, do you have a pointer to that charter or a description of that work?

    I could use some help understanding the scope and state of the protocol work you have referenced.

    Thanks,

    Margaret

    > On Sep 22, 2017, at 1:23 PM, David Sinicrope <david.sinicrope@ericsson.com> wrote:

    >

    > Margaret,

    > Please let me address a few of your points.

    >

    > First let me address the accusation of “using the threatening tone”. This is a serious accusation and one I believe to be unfounded. At no point is the language I am using making threats. I am simply stating the potential negative impact of overlap to the BBF-IETF relationship and suggest a corrective course of action.

    >

    > I do not understand your statement/accusations about me or the BBF blocking work or the BBF releasing objection to the BANANA work. All work in the IETF is done according to the IETF process and I’m not aware of any part of the IETF process that lets another organization or individual block or release work.

    >

    > As far as being willing to help and the “hats” I wear, I believe I have made it clear that I have been participating in my role as the IETF Liaison Manager to the Broadband Forum.  At each BANANA BoF I have attended (all but Yokohama), I have tried to help the work progress by advising that the work scope not overlap with the BBF.    Scoping the work to avoid overlap will provide clearer direction, and in turn avoid debate and lead to faster progression of the work.

    >

    > As for the proposed alternative wording, I appreciate your attempt to accommodate the concerns I raised and avoid the scope overlap I highlighted.  I think the changed text is a marked improvement toward avoiding overlap.  I stand by the suggestions I have made in my previous email, including liaising a draft of the charter, once stable, to the BBF and requesting their input.  I cannot advise what the BBF position would be on a charter they have not seen.  I believe liaising the draft charter would not only provide BANANA with important feedback, but also would be seen as a gesture of goodwill helping foster a cooperative IETF-BBF relationship on this topic.

    >

    > I look forward to finalizing the BANANA charter and a cooperative and productive work relationship between the IETF and BBF on this topic.

    >

    > Regards,

    > Dave Sinicrope

    > BBF/IETF Liaison Manager

    >

    >

    > On 9/21/17, 11:54 AM, "Margaret Cullen" <margaretw42@gmail.com> wrote:

    >

    >    Hi Dave,

    >

    >    It is not our intent to overlap with work in the BBF or the 3GPP.  It is also quite explicitly our intention to develop a multi-provider, “over-the-top” solution.  If that is unclear in the charter, we should make it clearer.

    >

    >    You wrote:

    >> Over the course of the BANANA charter creation this positioning (i.e., BANANA = multi provider, OTT, not in conflict with the BBF) seems to have been increasingly diluted, resulting in the existing charter which, as noted below, gives license to deal with the entire space and seemingly casts aside the previous scope positioning and concerns.

    >

    >    I’m not sure how this message has been “diluted", so I will need your help in un-diluting it.  Is there something in particular that was included in previous descriptions of this work that has been (perhaps unintentionally) removed from the current charter?  This is essentially the same charter text we have been discussing for 6+ months, and the same work we have been discussing for multiple years.

    >

    >    To break down your two points:

    >    (1) The charter is unclear that this is intended to be a multi-provider solution.  The charter says:

   >

    >    "The Bandwidth Aggregation solutions developed in this group will be designed to work in multi-provider scenarios (i.e. they will not depend on all of the aggregated links being provided by a single Internet access provider)."

    >

    >    How would you change that sentence to make it clearer that these solutions will be multi-provider?  Would it help to say something about the BANANA solutions not requiring explicit cooperation between providers?  I think it would be acceptable to the group to add that wording, as we have been talking about solutions that would work with any set of providers, not just with a single provider or a cooperating set of providers.

    >

    >    (2) The charter does not say that this will be an OTT solution.

    >

    >    It is true that the charter does not explicitly say that we will develop an “over-the-top” solution. It is, however, the scope of the IETF to do IP-based, link-layer-independent work (except in unusual cases), and this work is no exception.  We don’t usually use the term OTT in the IETF, but I wouldn’t object to explicitly saying that this work will be an IP-based and link-layer-independent, if it would make things clearer for people who are not familiar with the usual scope of IETF work.  If there is some other property of OTT solutions that you think is important here, please let me know what it is.

    >

    >    Putting these together, along with the NAT change discussed earlier, I think we would end up with the following text:

    >

    >    "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."

    >

    >    Would this change address your concerns?  If so, I will post it in another thread for feedback from the list.  If not, could you suggest a specific change that would address your concerns?

    >

    >> You also wrote:

    >> Subsequent to the concerns noted above, the BBF has embarked on a project in cooperation with 3GPP to converge fixed access and the 5G core which would include hybrid access scenarios and fixed wireless access.  BBF and 3GPP currently have work underway and are looking to produce documents in the 3GPP Rel 16 timeframe.

    >

    >    Prior to the announcement of the 5G work, it had been stated openly that the BBF planned to produce a requirements document for “hybrid access”, and then the BBF would look at protocols from other standards bodies, such as the IETF, to determine how to meet those requirements.  The BANANA effort was blocked (for over a year, with no discussion on the BANANA list or even a statement on the list explaining why) until the BBF’s requirements were published, so that our work would not interfere (in some unspecified way) with the BBF requirements effort.  After the BBF requirements document was published, the BBF withdrew its objection to the BANANA work proceeding in the IETF.

    >

    >    Now, the BBF is starting a _new_ standardization effort (started _much later_ than the BANANA work), and you would like the IETF to further block or limit the BANANA work to avoid conflicting with this new effort.   It seems to me that the BBF is the one expanding the scope of their work, not the BANANA group.

    >

    >    Personally, I object strongly to the notion that the IETF should block or reject work on end-user-controlled, multi-provider, IP-based, link-layer-independent solutions because they “conflict" with provider-controlled (single-provider or cooperating-provider) solutions, or with solutions that are only applicable to specific link layer technologies (i.e. BBF/5G) thus only serving a subset of Internet users.

    >

    >    Dave, what hat were you wearing when you wrote this message?  Ordinarily if the BBF’s liaison to the IETF wrote to a WG or BOF mailing list that I was chairing claiming some sort of conflict with the BBF’s work and using the threatening tone you have assumed here, I would talk to the IETF’s liaison to the BBF and  get their help in resolving the situation.  In this case, though, the IETF’s liaison to the BBF is also you.  So, I guess I have no recourse but to ask you to help us figure out how to position the BANANA work so that the BBF will understand that we are intending to do a true multi-provider, OTT solution, that this work is in scope for the IETF, and that it does not conflict with the BBF’s work.  Do you think you will be willing and able to do that?

    >

    >    Margaret

    >

    >

    >

    >

    >

    > _______________________________________________

    > Banana mailing list

    > Banana@ietf.org

    > https://www.ietf.org/mailman/listinfo/banana