Re: [Banana] Updated Charter

[Florin Baboescu <[e-mail]>]

Hi Margaret, Mingui,



Very unfortunate pick of the naming convention in the examples below.
Consider that the N1-N4 have all a very clear meaning in the 5G System
architecture. Anyway, going back to the content, you mentioned below:

“Providers want performance measurement probes to be transmitted along the
same path as data packets. These probes will be defined as control
messages. Think about the above anycast mechanism. Providers do not expect
these probes to be exchanged between N1 and N2. In order to make the probes
be exchanged between N1 and N3 (or N4), these control messages (better all
the control messages) need to take the same tunnels as data packets. I do
not know an existing standard control protocol that meets this requirement
and can be used in the BANANA scenario. ”

There are already various tools for peer loss/path loss/path performance
measurements that IETF has standardized and that have already been in used
in various vendor solutions. Probes can be sent over a tunnel or on normal
transport path. Why exactly do I need a new one?

Thanks,

-Florin







*From:* Banana [mailto:[e-mail]] *On Behalf Of *Zhangmingui
(Martin)
*Sent:* Friday, September 29, 2017 4:49 AM
*To:* Margaret Cullen <[e-mail]>; Sri Gundavelli (sgundave) <
[e-mail]>
*Cc:* [e-mail]; [e-mail];
[e-mail]; [e-mail]
*Subject:* Re: [Banana] Updated Charter



Hi Margaret,



> [With the caveat that I don’t think anything should be DSL/LTE-specific,
though, or assume that there are exactly two links, or that there is only
one “N2” that can reach a given end-node]



This is a good point. It’s common that providers use multiple aggregation
BANANA boxes to achieve load balance. N2 would be a branch router (not the
aggregation BANANA box) that adopts anycast mechanism. Suppose the
aggregation BANANA boxes behind N2 are N3 and N4, then the tunnel endpoints
would be N1-N3 or N1-N4 rather than N1-N2. For this reason, N3 needs to let
N1 know he is the real tunnel endpoint. To me, this feature has to be
realized by a BANANA control protocol. DNS does not support this feature.



We can also identify several other features that require BANANA control
protocol(s).



Bypass is another important feature that requires BANANA control
protocol(s). Basically, this requirement requires the two BANANA boxes to
use the control protocol to timely exchange the traffic types that need to
bypass the two bonding tunnels.



Providers want performance measurement probes to be transmitted along the
same path as data packets. These probes will be defined as control
messages. Think about the above anycast mechanism. Providers do not expect
these probes to be exchanged between N1 and N2. In order to make the probes
be exchanged between N1 and N3 (or N4), these control messages (better all
the control messages) need to take the same tunnels as data packets. I do
not know an existing standard control protocol that meets this requirement
and can be used in the BANANA scenario.



If the quality of one of the tunnels downgrades below a certain level
(e.g., the measured RTT exceeds 300ms), the two BANANA boxes have to agree
on to disable this tunnel instantly while remain the other tunnel. This
action has to be executed relying on the control protocol. Is there an
existing standard control protocol already supports this feature. I don’t
think so.



Thanks,

Mingui



*From:* Banana [mailto:[e-mail] <[e-mail]>] *On
Behalf Of *Margaret Cullen
*Sent:* Friday, September 29, 2017 2:49 AM
*To:* Sri Gundavelli (sgundave)
*Cc:* [e-mail]; [e-mail];
[e-mail]; [e-mail]
*Subject:* Re: [Banana] Updated Charter



Hi Sri,



On Sep 28, 2017, at 12:18 PM, Sri Gundavelli (sgundave) <[e-mail]>
wrote:



We cannot solve market fragmentation issue around protocol use and at least
that cannot be the reason for defining a new protocol, or WG creation.  If
that is the PS, Wim’s suggestion to focus on an information elements is a
great proposal to get all solutions towards a common approach, but not by
mandating a specific protocol use.



The point of standardization, at least IETF standardization, is so that
there can be products from multiple vendors that _interoperate_.  In my
opinion, this is a case where interoperability would be particularly
desirable, especially for situations where bandwidth aggregation is
performed over-the-top (as Dave Sinicrope would say), rather than
terminating in an operator's network.  The good news is that we already
have multiple options for bandwidth aggregation out there, with running
code, and they work.  The downside is that they are all proprietary, so
they don’t work _together_.  In your terminology, you can only get the
benefits of bandwidth aggregation if N1 and N2 were bought from the same
vendor, and the goal of this WG would be to fix that.



N1 wants to discover N2; It can be based on DNS FQDN, DNS SRV lookup, DHCP
option, an attribute in AAA that comes to the device as part of the access
authentication, or a static IP address configured locally.



Most of these choices require some sort of standards development work:  a
DHCP option, defining a AAA attribute, defining a new DNS SRV type, etc…
 None of these things can just magically be used to find “N2” in an
interoperable fashion, without some standards work.  Having 6 options is
about as useful, for interoperability, as having no option at all.  So, it
would be good to define one way that N1 finds N2 (or a limited set of ways,
and an order for trying them), so that boxes from different vendors can
actually find each other without users having to populate multiple
databases, deal with multiple boxes that do different things with the same
configuration information,  or configure the same information into
half-a-dozen places.



N1 wants to register with N2. N1 wants to presents its identity, authorize
it self. N2 needs to use the identify and check AAA/local DB to authorize
N1



Or it could use TLS, or DTLS, or…  There are numerous ways to authenticate
between boxes, and we won’t get any interoperability until we pick exactly
one.  If we wanted to use AAA (RADIUS or Diameter), we would also (at the
very least) need to define a service name, and agree to at least one “mandatory
to implement” method.  AAA might not be the best choice, though, given that
we probably don’t want to limit bandwidth aggregation to the case where N1
and N2 have a single authority or overarching federation to run the AAA
infrastructure.  So, a certificate-based or PKI system might be better?



N1 wants some flexible way to generate its identify, based on access
network, hardware identifiers ..etc

N1 wants to register its reachability with N2. I have IP1 from LTE and IP2
from DSL

N1 wants a ask N2 for a set of prefixes for its ingress network from the
anchor. It can obtain/register/negotiate Prefix P1, P2 and P3.

N1 wants an overlay tunnel to N2 over LTE. and another tunnel over DSL So,
N2 can forward the traffic bound to N1’s ingress prefixes over an overlay
path. Hiding the ingress prefix traffic from the transport topology

N1/N2 wants to continuously check path-reachability/peer-loss over DSL and
also over LTE

[…]



These are the sorts of things that require the exchange of control
information.  [With the caveat that I don’t think anything should be
DSL/LTE-specific, though, or assume that there are exactly two links, or
that there is only one “N2” that can reach a given end-node]  Perhaps you
are saying that MIP already has a control-information-exchange mechanism
that we could use for this?  If so, then great, you should propose it, and
we should consider it!  We might need to extend a MIP
control-information-exchange to include the information that is needed for
per-packet load-balancing and recombination.  If we also used MIP as the
tunnel-based Bandwidth Aggregation mechanism, we might also need to extend
the MIP tunnel support to include per-packet load balancing and
recombination functions — perhaps adding a packet sequence number, for
example.  If the proposed BANANA WG decides this is the best approach,
perhaps we could work with the DMM WG to standardize those extensions?
There may be other protocols we should consider for this role, though, that
don’t have existing IETF WGs.  In those cases, we might do the extensions
in the proposed BANANA WG.



I would also add something that you didn’t include:



There might be more than one Bandwidth Aggregation mechanism available on
N1.  For example, we might have an MPTCP-Proxy-based mechanism available
that can be used for Bandwidth Aggregation of TCP traffic, and a tunneling
mechanism that can handle any IP traffic.  N1 might want to know which
mechanisms are available on N2 (or potentially on N3 or N4 if they can be
used to reach the same end node), and what types of traffic they can
handle.  We might need some mechanism to resolve what traffic will be sent
where, etc.  If we envision a world with multiple standard Bandwidth
Aggregation mechanisms, we may need to choose at least one
mandatory-to-implement Bandwidth Aggregation mechanism that all of N1…Nn
will support, so that we can ensure interoperability.



Margaret