Re: [Banana] Charter

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi Mirja,

Yes, vendors have been deploying multipath solutions and I have personally
defined and deployed such architectures. There is lot of known-art in this
area and that includes standardization right from multi-link PPP,
DSMIP-IFOM, MPTCP and in other protocols areas. So, this is not a new
problem as being presented. Now, the issue is not with bringing all
multipath discussions to one common place, about the need to document all
known approaches, or asking for a specific extension in a specific
protocol.  But, the idea of Banana WG defining “a solution” and calling it
a IETF Banana solution is an issue. The idea of departing from protocol
work to solution work is an issue. I tend to think that is outside the
IETF charter and falls in the vendor/SDO territory. As a case in point,
lets go back to topic of IPv6 transitioning and the contentious debates
around IETF picking one approach for transitioning, among DSLite,
Gi-DSLit, NAT64 and the zillion other variants. At that time, Jari Arkko,
was very clear, we are only providing tools to the community and we will
not pick one approach as that amounts to helping a vendor.  So, I, not as
an individual, but representing my employer, have a problem giving such
authority to the chairs of this WG. If the counter argument is that the
chairs will not pick a solution, but will standardize many solutions based
on all known protocols offering such promise/capability, then the charter
clear should state that, Ex:”Banana WG will extend protocol X, Y and Z for
multipath support”. But, there has to be explicit statement that the WG is
not going to define new “signaling” or “user plane” protocols. That is the
core issue here.

The bar for defining new protocols must be very high; Besides the few
interested individuals there has to be support from across the community
when chartering such work. Its not just about support from dozen people (+
/ -), that makes it in to the charter. We don’t want IETF protocols to be
diluted with alternatives that do the same thing with a different
name/brand. The need for new signaling protocol must be backed with the
data that existing protocols do not fit the bill and so we need this new
approach. Again, case and point, when IETF went from client-based mobility
to network-based mobility, there was industry wide participation with
100’s participants/companies, support from WiMAX, 3GPP and with a strong
technical backing of basing it on a new architectural approach. There was
no such data presented here for Banana, and in the absence of such
data/analysis, the charter must explicitly state that WG is not allowed to
define a new signaling/user-plane protocol.

It must be noted that there is also no SDO Ask for this work.  If I
understand correctly they are in fact asking IETF to relax for some more
time till they make progress.  It may be for the AD to measure the support
for his work, but I do not see such support for this work beyond a small
group of people.  If you review the number of technical contributions to
Banana WG in 2015, 2016 and 2017, one can can clearly see that its mostly
the authors of 1 or 2 drafts, potential chairs and few individuals who
have contributed any thing. But, I realize its AD has the option charter
WG at their discretion, but the above issues have to be addressed, IMO.


Sri

 












On 9/25/17, 3:29 AM, "Mirja Kühlewind" <[e-mail]>
wrote:

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