Re: [Banana] Charter

[Mirja Kühlewind <[e-mail]>]

Hi Sri, hi all,

I didn’t speak up so far because I think most things have already been said, regarding scope and problem. To me the knowledge that there are (proprietary) already deployed solutions is a good sign that there is a need for this work and the role of standardization here is to document these approaches to make things interoperable between different vendors and different operations. 

However, I would like to add one more point. Sri, you said several times that there are already groups in the IETF that could standardize these extensions, when needed. That is true for some groups but also not for all. MPTCP is chartered to document the use of MPTCP proxy mechanisms but it is not charter to work on protocol extensions that e.g. provide additional signaling for this use case. MPTCP is an TCP extension and TCP is an end-to-end protocol not a tunneling protocol. 

Moreover, seeing that the same problem is considered in various different groups in the IEFT, is another point that indicated to me that we probably need an own working group, otherwise we will end up doing the same work multiple times. What we need is to get all the people working on the same problem in the same room and talk to each other. Of course if extensions are considered to existing protocols and we have an active working group that maintains that protocol, we need close cooperation with that group. However, that is not a new problem and we have that in many groups. What we usually do is a common wgcl in both/multiple groups or even start the doc in one group and move it over to another if we figure out that the needed expertise is there. It’s the job of the ADs to make sure that this inter-wg or even inter-area awareness happens and I’m not worried about this.

Mirja



> Am 22.09.2017 um 17:53 schrieb Sri Gundavelli (sgundave) <[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.
> 
> 
> Even if the charter restricts the group from working on only
> multi-provider solution (or vice-versa), what does it mean from the IETF
> protocol point of view. We don¹t model provider relations in protocols
> (other than some path attributes in BGP). Will ³Banana solution² defined
> for multi-provider stop working for single provider? Or, we will put an
> artificial restriction that this solution MUST NOT be used for single
> provider? How do I read that?
> 
> 
> IF we step back, the motivation for this work is DSL + LTE aggregation. If
> BBF and 3GPP have a work item, they will possibly define a initiator
> function which can collocate with the RG and a terminating/aggregating
> function on either PGW or on the BNG. Within these entities they have the
> choice to use GTP (most likely), PMIPv6, L2TP, MPTCP, MPQUIC, or a Static
> tunnel with a controller based interface. If their evaluation of all IETF
> protocols result in the conclusion that they need a new signaling
> protocol, they will initiate that request to IETF and then Banana WG can
> go into some rapid action. However, if they decide to use one of the
> existing protocol and need a protocol extension, they will request the
> same from that respective protocol group. They may also choose not to go
> with an overlay approach/IETF protocols, as they will argue they can
> leverage inband QoS signaling for leveraging transport QoS and map between
> EPC QoS bearers and service flows on the BBF access; they can provide
> single QoS control point. What would be our argument on why any overlap
> approach is better in this context?
> 
> So, I am wondering who is the customer for this work? Lets also not forget
> the 7 other solution approaches that are out there. If the primary stake
> holders are asking "not to" start this work, why would we charter
> ³solution² work? Why would we do that and who uses this standard?
> 
> 
> 
> 
> Sri
> 
> 
> 
> 
> 
> 
> 
> 
> On 9/21/17, 8:47 PM, "Suresh Krishnan" <[e-mail]> wrote:
> 
>> 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