Re: [Banana] Charter

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

Hi Tommy,

Vendors have developed and deployed solutions for hybrid-access use-case (broad-band forum terminology). These are all based on existing IETF protocols and some vendor extensions for vendor differentiation (as in any technology). Now, if there is a non-standard extension in a given solution/protocol, one has the option to standardize that knob in that respective protocol group. If the solution is based on IPSec/IKEv2, there is ipsecme protocol group that is out there to standardize that option, there is MPTCP, QUIC, DMM working groups for other approaches. The protocol expertise resides in those groups. So, that option is available today and any one take the needed extensions and fix it in that WG.

The key issue with the Banana charter is lack of a clear problem statement, other than the description of a high-level solution requirement and Banana terminology. There is a not a single statement in the charter which points to a technical issue. I was hoping its was about packet load-balancing on overlay tunnel paths. That is a meaningful charter item with no relation to any specific solution/signaling protocol/encapsulation.

The idea of chartering a solution-type working group is new to me. I do not remember seeing such working group. The closest that comes to my mind is IPv6 group  focussing on deployments aspects to realize IPv6 more quickly, but clearly they were not chartered to do protocol extensions.  There has to be some value in going that route for this point solution.   Assuming we go that route, what would be deliverable of the WG?  Is it only documentation of various solutions and fix interop issues by engaging the respective protocol groups? Will the WG refrain from defining protocol extensions? Can we put that in the charter (no protocol extensions allowed)? Lets also look at the solutions that are out there. Will Banana pick one of these approach and start calling it Banana?  Or, because there are “n” solutions, Banana will standardize a new protocol/solution and call it Banana solution?



1. Multi path Support with PMIPv6


[cid:8ABDF9D9-00F9-4493-B1ED-BB91E45D14DD]






2.  Multi path Support with MobIKE


[cid:D6FD6A64-BB2E-4AE6-913F-B46F2FB49F4B]






3. Multi path Support with DSMIPv6

[cid:DE3C3C9D-0CEB-4907-8C4D-376EF78BAD69]




4. Multi path Support with Static Tunnel Peer Provisioning


[cid:CF06DC5D-CE6E-4E5A-8010-E5ED985504DC]





5. Multi path Support with QUIC/MPTCP Proxy (Client Initiated)


[cid:0F859BC7-2C30-4FE2-8899-43BE567C2386]




6. Multi path Support with QUIC/MPTCP Proxy (Proxy Initiated)


[cid:1C40439B-02E1-47BC-BE0B-28B2BD41E2F1]




Regards
Sri



From: <[e-mail]<mailto:[e-mail]>> on behalf of Tommy Pauly <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, September 19, 2017 at 4:31 PM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Cc: Margaret Cullen <[e-mail]<mailto:[e-mail]>>, "Zhangmingui (Martin)" <[e-mail]<mailto:[e-mail]>>, Alexandre Petrescu <[e-mail]<mailto:[e-mail]>>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: 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) <[e-mail]<mailto:[e-mail]>> 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 <[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

_______________________________________________
Banana mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/banana