Re: [Banana] Charter

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

Hi Margaret,

PMIPv6 supports IPv4 or IPv6 for transport, so the tunnel can be based on IPv4-GRE, IPv6-GRE, IPv4-UDP, or IPv6-UDP. The overlay traffic (user plane) can be IPv4, IPv6 or IPv4/IPv6. All based on RFC standards.

With regards to my comment on IP SLA, there are various tools for measuring path performance.  These metrics include path-loss, delay, jitter, packet loss, packet sequencing, peer loss, Voice quality MOS ... These are achieved by sending various packet probes. The IP Performance guys in IETF can point of the available RFC publications on these approaches.



Regards
Sri


From: Margaret Cullen <[e-mail]<mailto:[e-mail]>>
Date: Monday, September 18, 2017 at 8:14 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


One more question about this solution, Sri — is this an IPv6-only solution?  Or does it do bandwidth aggregation for IPv4 traffic over an IPv6 tunnel, or something similar?

Margaret


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.

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




<74A4446F-CFF1-4CCD-973D-BF402E138FD2.png>


*** I know some others realizing the above with MobIKE extensions, and some others realizing the same based on MPTCP Anchor.


Sri



From: Margaret Cullen <[e-mail]<mailto:[e-mail]>>
Date: Monday, September 18, 2017 at 4:15 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


On Sep 18, 2017, at 6:30 PM, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> wrote:
Generally, I agree with your above statement. If there is enough interest to do some new work and people ready to write some drafts and people ready to chair the meetings, creation of a WG should be the most logical thing. But, that goes with the assumption that the work is not overlapping with some other work that is happening some where else. That needs to be ensured and hence the need to agree upon the problem statement from both interested and non-interested parties. We need to review this overlap with QUIC, MPTCP, MobIKE and Mobile IPv6 protocols.

This is one of the reasons we have BOFs.  If you believe that there is some overlap with one of those protocols, or that one of those protocols already solves the problem, say that and explain how.  Also, perhaps include some explanation of what that protocol is not already being used to solve this problem, or what sort of changes or extensions would be needed to make it solve the problem more completely.  I am pretty sure that the IESG doesn’t want to charter a group to solve an already-solved problem.

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?

Margaret