Re: [Banana] Charter

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