Re: [Banana] Charter

["Zhangmingui (Martin)" <[e-mail]>]

Hi Suresh,

> In my view the conflict is about whether the the "provider-controlled
> (single-provider or cooperating-provider)" part is in scope of the charter or not. I
> don’t think we can have a meaningful conversation unless we state this in the
> charter one way or another.

Surely we do not have conflict for the cooperating-provider scenario. But I want to argue there is no conflict even for the single-provider part.

TR-348 is "Hybrid Access Broadband Network Architecture". I knew contributors from vendors and operators worked closely to develop a good set of requirements. 75 of them. They are the core asset of TR-348. Since the TR is public, people can easily download it and check. (https://www.broadband-forum.org/technical/download/TR-348.pdf ) The title of WT-378 is "Nodal Requirements for Hybrid Access Broadband Networks". It's not published yet but we can be sure it will not develop specific protocols either. Working Texts and Technical Reports in BBF often include references to RFCs and working group documents. WT-378 is not an exception. We should understand this manner as the encouragement of protocol development in IETF rather than discouragement. BBF is not the sole organization that relies on some standardized protocols developed by IETF. There are many others. I believe this is a good way of cooperation rather than competition.

If we regarded BANANA effort as competition, then we have many more. For example, Section 5.4.3 of TR-348 points to the two-ended-proxy effort in the MPTCP WG. We also consider it as a competition? We all know it doesn't make any sense. 

We are fear of undermining the good relationship between IETF and BBF so we don't step into the area that might be covered by BBF. Is it an overkill caused by such fear to scope the development of protocols for a single provider scenario out of BANANA WG? If we face the fear, we would find BBF is actually asking for help from IETF. How can we just sit by and watch?

In my view, the documents developed by BBF can be regarded as external support documents of BANANA. Since BANANA WG is to be chartered not to formally publish support documents, I think this kind of conflicts can be nicely avoided. In this sense, the option to develop formal problem statement and requirements documents is more likely to cause conflicts.

Thanks,
Mingui

> -----Original Message-----
> From: Banana [mailto:[e-mail]] On Behalf Of Suresh Krishnan
> Sent: Friday, September 22, 2017 11:48 AM
> To: Margaret Cullen
> Cc: David Allan I; Muley, Praveen (Nokia - US/Mountain View); Sri Gundavelli
> (sgundave); Alexandre Petrescu; David Sinicrope; Henderickx, Wim (Nokia -
> BE/Antwerp); [e-mail]
> Subject: Re: [Banana] Charter
> 
> Hi Margaret,
> 
> > On Sep 21, 2017, at 11:54 AM, Margaret Cullen <[e-mail]>
> 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.
> 
> Can you please elaborate on the things you mention in this paragraph?
> Specifically "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)”.
> 
> >
> >
> > 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
> 
> I think this is a strawman. Is there anybody suggesting this?
> 
> > 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.
> 
> In my view the conflict is about whether the the "provider-controlled
> (single-provider or cooperating-provider)" part is in scope of the charter or not. I
> don’t think we can have a meaningful conversation unless we state this in the
> charter one way or another.
> 
> Thanks
> Suresh
> 
> _______________________________________________
> Banana mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/banana