Re: [Banana] Charter

Hi Sri,

I think your point about the distinction between solutions and protocols is important for this discussion, and the heart of what you are getting at. To that end, I think that this work is indeed charterable by the IETF, and the proposed charter gives the group the flexibility to delve into these discussions further.

Can we frame the work of the WG as "updates to protocols to help build better standards-based solutions"? BANANA isn't set up to be a pure-protocol group; it is about adding options or recommending how to use protocols together. But neither is it simply a solution-based group. We shouldn't end up with a lot of MUST statements about how solutions should be deployed. Instead, we should be looking at existing protocols and identify the gaps or options or extensions we need to address in existing protocols to make it simpler to create interoperable non-proprietary solutions.

As an analogy for this work: having come from the VPN side of things, the IETF has defined protocol extensions for protocols like IPSec and IKE to fill in gaps that VPN solutions commonly needed to extend with proprietary solutions. By defining these protocol bits as standards, we can help encourage interoperability. The work of BANANA would help look at the opportunities in protocols that may be used for bandwidth aggregation solutions. This work may be all done in incremental documents, not necessarily large new protocols, but is still useful and applicable work.

Thanks,
Tommy

> On Sep 19, 2017, at 9:25 AM, Sri Gundavelli (sgundave) <sgundave@cisco.com> wrote:
> 
> Hi Margaret,
> 
> > The existence of multiple deployed, proprietary solutions to this problem from multiple vendors only proves, to me anyway, that this is indeed an interesting problem to solve.  
> 
> The issue is we are mixing protocol work with solution work. We don’t do solutions, that is for the expertise of Vendors, and experts in SDO’s at Broadband forum and 3GPP  .
> 
> I understand folks are interested in “Banana type of solution”. But, that is not a problem statement that IETF can charter.   We need to state the requirement in more specific terms.  
> 
> For example, if the goal is to define a “a better packet load-glancing mechanism given to two tunnel overlay paths”, without any binding to a specific protocol, then its about considerations and the logic for packet spraying on two overlay tunnel paths.  We cannot bring operator, prefix allocations, tunnel setup mechanisms into the discussion.
> 
> Given the below pointers on existing art, if we can state the problem in more precise terms, then we can agree upon some charter text. In the current form with "solution type description”,  this is a non-starter.
> 
> 
> Sri
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> From: Margaret Cullen <mrcullen42@gmail.com <mailto:mrcullen42@gmail.com>>
> Date: Monday, September 18, 2017 at 5:50 PM
> To: Sri Gundavelli <sgundave@cisco.com <mailto:sgundave@cisco.com>>
> Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com <mailto:wim.henderickx@nokia.com>>, "Zhangmingui (Martin)" <zhangmingui@huawei.com <mailto:zhangmingui@huawei.com>>, Alexandre Petrescu <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>, "banana@ietf.org <mailto:banana@ietf.org>" <banana@ietf.org <mailto:banana@ietf.org>>
> Subject: Re: [Banana] Charter
> 
> HI Sri,
> 
> 
>> On Sep 18, 2017, at 8:20 PM, Sri Gundavelli (sgundave) <sgundave@cisco.com <mailto:sgundave@cisco.com>> wrote:
>> 
>> > There are people solving this problem today, in the field, though, and they don’t seem to be using the protocols you have mentioned.  Can you point to someone who is?
>> 
>> OK! I can provide that information. We have large scale deployments of the below based on Proxy Mobile IPv6 (100’s of thousands), with the ability to perform per-flow load balancing and per-packet and link-weighted packet distribution.  Many DSL operators have deployed this (DSL RG with LTE dongle)  and we have also deployed for many overlay applications.  You can check cisco CCO pages for the product details. For measuring path characteristics, we use IP SLA. Its a solution based on PMIP mobility and SLA for path performance measurement.  
> 
> Cool.
> 
> I tried to look up “Cisco CCO”, and that appears to be a type of Cisco Customer ID for logging into a support/documentation system.  Not being a Cisco Customer, I guess I don’t have “CCO pages”.  Could you provide details here, or links that are accessible to someone who isn’t a Cisco customer?  What is the product actually called, so that I can look for other sources of information about it?
> 
> Also, what is the expansion of “SLA”? The only expansion I know of is “Service Level Agreement"  (i.e. a legal contract), but I assume you are referring to some sort of protocol?
> 
>> Your problem statement is exactly this. The difference is that its Banana Signaling, Banana encapsulation and with Banana anchor/CPE. Its 100% re-invention of existing art, IMO, but built on the argument that we need improved packet distribution scheme. In the process you are building a solution, IMO.
> 
> The existence of multiple deployed, proprietary solutions to this problem from multiple vendors only proves, to me anyway, that this is indeed an interesting problem to solve.  
> 
> Obviously, there could be advantages to having an open standard in this space for multi-vendor interoperability.   It sounds like the Cisco solution is based on open protocols, but that there might be proprietary extensions included (for the per-packet handling and signaling of performance data, etc.)?  Would you be willing to document your solution in Internet-Drafts to be considered for standardization?  If so, it sounds like this might be a very interesting candidate for BANANA work.
> 
>> The aspect of CPE registering with the anchor, discovery of the anchor, path specific registrations, prefix negotiation for the ingress network from the overlay anchor, tunnel parameter negotiation, flow policy negotiation have to be part of your protocol. So, this is the big overlap and so this is not about few willing hands to do the work.
> 
> Although we don’t use the same terms, I believe the all of these things have also been considered in the Huawei GRE Tunnel Bonding solution (RFC 8127 and related documents), as well.  We have also had presentations on other solutions to this problem at various levels of specification and deployment.
> 
> We have more than just a few willing hands…  
> 
> Margaret
> 
> _______________________________________________
> Banana mailing list
> Banana@ietf.org
> https://www.ietf.org/mailman/listinfo/banana