Re: [Banana] Updated Charter

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

Hi Margaret,


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

Multipath/multihoming is a core capability of MIP architecture and if you review the published work/vendor solutions, you can see that. The burden is not on me to prove this. The point is we don’t charter this work with all of these work items and then go decide what to do there. The issue is we still do not know why we are asking for this specific charter.  If the goal is to understand if MIP/or some other protocol is already meeting all the requirements for the use-cases that we never converged, lets charter the work with that exactly one statement. “Explore IETF protocols that are used/suited for supporting multipath requirements; Identify all gaps and recommend extension that needs to be standardized by IETF”.


> The downside is that they are all proprietary, so they don’t work _together_.

The list I gave is a set of features supported today based on MIP RFC standards.  We are confusing folks to mean each of these feature is a different protocol and all are proprietary.  Please identify which aspects are proprietary and lets focus on them, without starting from basics and asking for a new signaling/user-plane protocol that does functionally the same thing. MIP is a control plane protocol and has support for multi-homing. Please let me know exactly what is the non-standard feature in that list and we can fix that.


> Or it could use TLS, or DTLS, or…

Sure. RFC6618 is your starting point

When a protocol support multiple options, say "encapsulation modes, GRE/IP-in-IP/UDP", it does not mean they are non inter-operable, or a bad thing. It means two things. A given deployment/solution based on that protocol may use all modes and the selection of the mode is based on protocol negotiation. It also means an SDO/vendor can limit the features in a profile definition, by being very prescriptive on what is supported in their solution. So, this is a vendor/SDO/solution problem and not an IETF protocol problem.


Sri





From: Margaret Cullen <[e-mail]<mailto:[e-mail]>>
Date: Thursday, September 28, 2017 at 11:49 AM
To: Microsoft Office User <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Banana] Updated Charter

Hi Sri,

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