Re: [Banana] Charter

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

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 <[e-mail]<mailto:[e-mail]>>
Date: Monday, September 18, 2017 at 5:50 PM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]<mailto:[e-mail]>>, "Zhangmingui (Martin)" <[e-mail]<mailto:[e-mail]>>, Alexandre Petrescu <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Banana] Charter

HI Sri,


On Sep 18, 2017, at 8:20 PM, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> 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