Re: [Banana] Charter

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

Margaret,

>  If you believe that PMIPv6-based approach to this problem is the best solution, perhaps you should write a draft (or drafts) describing that solution, so the WG can consider it?

There is nothing like a best solution and that discussion is out of scope for IETF, IMO.  I have already talked about “n” different ways vendors are realizing this today. and PMIPv6 based solution is one among the many approaches. We have large scale deployments and so I do not need to write a draft on that approach.

I think what you are looking for is like an open charter for a solution with the right to define what ever protocol ( or protocols) needed for this solution. Without presenting any data as why those existing “n” mechanisms don’t work, having this in the charter makes no sense to me. If the only argument is, "there are people interested in working in this”,  that IMO is a weak argument, as most of those folks are draft authors.

I think we need much stronger consensus and industry wide participation, for obtaining such broad charter, allowing definition of new protocols based on some solution description.


Sri


From: Margaret Wasserman <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, September 19, 2017 at 7:55 PM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Cc: Tommy Pauly <[e-mail]<mailto:[e-mail]>>, 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

Sri,

>Can we put that in the charter (no protocol extensions allowed)?

How would that make sense for a group that is chartered to define three protocols?  Yes, we might reuse existing protocols, but we also might define some new ones, or we might define extensions to existing protocols to meet our needs.

While there is no one complete proposal at this point, and it will be up to the WG to choose what approaches to use for each part of the solution, I could see this group defining multiple protocols and extensions, such as:  a DHCP option or RA record to provision the location of a centralized remote BANANA Box, or (more interestingly, IMO) a DNS record to find the remote BANANA box closest to a specific destination address.  A tunnel-based encapsulation (perhaps based on RFC 8157, or your MIP-based proposal if you choose to document it, or some other proposal), a description of how to use an MPTCP proxy (and maybe an MPQUIC Proxy, if that even makes sense?) in conjunction with a default tunneling solution to perform more optimal aggregration for TCP (or QUIC?) traffic in a coordinated fashion with the aggregation of other traffic, a conceptual description of the information that needs to be signaled between BANANA boxes for two-way load balancing and flow control, etc., and either a new protocol or extensions to an existing signaling protocol to send that information. Maybe we would also choose to write some type of "boxes and arrows" architecture document to describe how the pieces fit together.

It wouldn't make sense, in my opinion, to charter the WG in a way that would stop us from doing any of those things, if the WG has consensus to do them.

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

If we don't end up writing a new protocol at all, there might be no protocol _named_ BANANA.   There would probably be BANANA options, records or extensions, though.

If you believe that PMIPv6-based approach to this problem is the best solution, perhaps you should write a draft (or drafts) describing that solution, so the WG can consider it?

Margaret


1. Multi path Support with PMIPv6


<8ABDF9D9-00F9-4493-B1ED-BB91E45D14DD.png>






2.  Multi path Support with MobIKE


<D6FD6A64-BB2E-4AE6-913F-B46F2FB49F4B.png>






3. Multi path Support with DSMIPv6

<DE3C3C9D-0CEB-4907-8C4D-376EF78BAD69.png>




4. Multi path Support with Static Tunnel Peer Provisioning


<CF06DC5D-CE6E-4E5A-8010-E5ED985504DC.png>





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


<0F859BC7-2C30-4FE2-8899-43BE567C2386.png>




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


<1C40439B-02E1-47BC-BE0B-28B2BD41E2F1.png>




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