Re: [Banana] Updated Charter

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

Hi Phil,

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 Charter suggests a common protocol to send control information between the Banana boxes, whatever bandwidth aggregation mechanism you choose.

Interestingly, I always thought the only work that can be useful  is about finding better methods for per-packet load balancing when using multiple links; strictly a data plane issue. But, in your view, “bandwidth” aggregation is vendor specific and that is precisely the today’s situation.

Now, lets see what is left. Lets try to frame the discussion without the use of “Banana" terminology and by using some general IP terminology.

--
There is a host/router which has two or more internet facing WAN links. Each of these link are bound to a different access network (Ex: DSL, LTE).  There is an IP address from the access network for each of those interfaces. It can be IPv4/IPv6 address. The device gets its IP address after authenticating to each of the access networks. This device also has an identify and security credentials. Lets call this node as N1. The device also has an ingress network where there are many IP hosts attached.

There is an anchor/gateway/aggregation node in the network which can authenticate/authorize/ the devices such as N1. It has the access/routing/QoS policy. It can do charging, accounting and the necessary business logic. It has interfaces to the backend system. Lets call this as N2.

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.
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
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
N1/N2 wants to track all paths of N1 and reachability by using heartbeats; if there is a problem on path, they both need to tear down that overlay tunnel path
N1/N2 wants to negotiate a traffic policy which says, App-1 traffic needs LTE as the most preferred path and DSL as the next preferred path. For App-2, its only DSL or DROP policy.
N1/N2 wants to negotiate an SIPTO policy where certain traffic gets offloaded with NAT translation
N1/N2, in some cases, do no want to negotiate a traffic policy and allow them to use a locally configured policy
N1/N2 wants to negotiate a inband QoS policy; Flow1 gets guaranteed QoS of 128Kbs guaranteed bit-rate, Attributes such GBR and many other attributes
N2 wants to inform N1 about the ingress Prefix P1 getting renumbered to P3.
N1 and N2 wants to secure the overlay tunnel path with some security policies.
----

We have protocols for realizing the above functionality.  We don’t need a new protocol for realizing this. If some one can explain the gap and justification as why this cannot be realized and a need for a brand new protocol, we can certainly have that discussion. Now, if the Ask is for extending a specific protocol, say IKEv2, so the peers can exchange some specific information between N1 and N2, then its a reasonable Ask. But, here what we are asking for is like a laundry list of requirements (peer discovery,  registration, prefix management, mobility, traffic policy management, path performance measurement …etc) and with no justification.



Regards
Sri


From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, September 28, 2017 at 2:22 AM
To: Microsoft Office User <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[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]>>
Subject: RE: [Banana] Updated Charter

Sri,
My reading of the proposed work is a bit different.
There are several “Bandwidth Aggregation mechanisms” proposed and in products (you have counted 7) - it doesn’t seem likely that we can converge to one solution and that the IETF could standardise “the chosen one”.
The Charter suggests a common protocol to send control information between the Banana boxes, whatever bandwidth aggregation mechanism you choose. It may also be possible to recommend way or ways of finding the other Banana box, again whatever the Bandwidth aggregation mechanism. These seem to me reasonable things to try and do. Do you have an issue with these two items? (I’m not sure). I don’t interpret these work items as “like redefining Mobile Ipv6/NEMO” (I’m not sure if you’re suggesting this – and I’m out of date with Nemo, so may be getting it wrong).
My understanding is that the final item, about a particular bandwidth aggregation solution, is a bit separate and isn’t going to determine what’s chosen for the first two items. I think you have an issue with this final work item, believing it would amount to the IETF rubber stamping a particular solution.
I wouldn’t support work on a problem statement – at least the general reasons for doing bandwidth aggregation seem to be understood.
From your last paragraph, I think you have ideas about what would be good alternative topics for a WG – would be interested in hearing about those.
Best wishes,
phil

From: Banana [mailto:[e-mail]] On Behalf Of Sri Gundavelli (sgundave)
Sent: 27 September 2017 23:24
To: Margaret Cullen <[e-mail]<mailto:[e-mail]>>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]<mailto:[e-mail]>>; David Allan I <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Banana] Updated Charter

Hi Margaret,

Sure, Several reasons why I disagree ..  I will state them again and at the risk of repeating myself ..

1. Lack of a clear problem statement – You are attempting to charter this WG by providing a broad solution description and with no identified technical problems or solution approaches.  Various vendors have products supporting this solution and I have identified at least 6 different approaches for realizing this solution and Praveen tells me they have the 7th approach.  Now, you want a charter that allows you (or others chosen for chairing this group) to be in a position where they can standardize any protocol/approach and put an IETF stamp on it. This is not IETF’s business to pick one protocol and call it a “Banana” Solution. This stamping will hurt vendors who may choose not to support what you standardize. So, the idea of a “solution” branding is the issue here and the idea of giving such power to a WG chair is the issue here.  The idea of allowing you to define a new signaling/user-plane protocol with no justification and that's based on your determination is the issue here.

2. The charter that you are trying to propose below is like redefining Mobile IPv6/NEMO functionality and many other things. The idea of peer discovery, prefix allocation, NAT traversal, Traffic Policies ..and all the other extensions that come with it in the form of security, protocol semantics  is not a small efforts, or a charter that 10 people in Banana WG can deliver.  Your only argument for not using existing protocols is about lack of a specification on Per-packet LB. So, you want to reinvent the whole wheel, signaling and user plane… and put a solution stamp. Also, the “banana” solution overlaps with what 3GPP and BBF plans to do with their work item. So, we do not know yet who wants this work.

3. There is also simply no support for this work, IMO. I do understand there were few extra voices in the room in IETF99 that gave few people an impression that people are jumping to do this work, but if you look at the complete picture, last 3 years of history, SDO interest,  email activity, current opposition and the fact that this is being discussed for 3+ years is a good hint on where this should go.

So, I suggest we let this cool down a bit. We need to have conducive environment to discuss and agree on a problem statement.  That time is not now and not over emails. Lets meet in IETF 100 and start those discussions and also include BBF/3GPP folks so they can provide feedback.  You can certainly tweak few lines of charter text and call it a success, but I am certain it will go no where as I don’t see support for this. Charter text discussion at this stage is premature IMO.



Sri

------------

  *

  *   Determine how Local and Remote BANANA Boxes find each other (i.e. describe how BANANA boxes will be provisioned/configured).

  *   Select or specify protocol(s) that can be used to send control information between BANANA Boxes, including:

  *   IP Prefixes of access  links

  *   Information about link status and properties (including congestion)

  *   Information needed by the Bandwidth Aggregation mechanism(s) in use

  *   Determining which flows are/are not eligible for Bandwidth Aggregation

  *   Select (and extend, if necessary) a tunnel-based method for sending traffic between BANANA Boxes (i.e. specify a tunnel-based Bandwidth Aggregation mechanism).
-----------


From: Margaret Cullen <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, September 27, 2017 at 8:18 AM
To: Microsoft Office User <[e-mail]<mailto:[e-mail]>>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]<mailto:[e-mail]>>, David Allan I <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Banana] Updated Charter


Hi Sri,

I understand that you do not support chartering this group.  I think it would be helpful, though, for me and for others, if you could be clear about _why_ you don’t support it.  What “damage” do you think would be caused by the formation of this group? If you could explain that, perhaps we could find some way to do this work without causing that damage?

Multiple other people have raised concerns with the charter, and I have been making modifications to the charter text in an attempt to address those concerns, successfully in some cases.  I would like to do the same for your concerns, if you could help me understand what they are.

Margaret


On Sep 26, 2017, at 4:38 PM, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> wrote:

Let this be very clear, I and suppose many others am not agreeing to the
current Banana WG charter. Lets not discuss about drafts, ownership and
other aspects.

I was trying to find a middle ground, where we can limit the damage
resulting from the formation of this WG. Hope this helps.

Lets focus on technical discussion.

Sri




On 9/26/17, 1:20 PM, "Banana on behalf of Margaret Wasserman"
<[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:


Hi Wim,

I have removed the word signaling in the most recently distributed
version, as proposed by Dave Allan below.  Does that address your
concern, as well?

Would people also find it clearer if we used the term protocol(s) or
mechanism(s) or something similar where we are currently using the word
"solutions"?  I think that word may mean different things to different
people.

Margaret

Sent from my iPhone


On Sep 26, 2017, at 1:36 AM, Henderickx, Wim (Nokia - BE/Antwerp)
<[e-mail]<mailto:[e-mail]>> wrote:

My 2 cents on this and I believe this is where a lot of controversy is
coming from, is why would we not charter Banana as a WG which is
defining an information model that is required to execute banana. So
banana defines which information needs to be exchanged and what the
banana entities do with it to perform banana
As such the actual protocol works can be done in different WG(s) and we
can leverage existing work as Sri was pointing out.

Would this work for people? My 2 cents, just a try to help.

On 25/09/2017, 22:13, "Banana on behalf of David Allan I"
<[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

  I'd probably be happier losing signaling. IMO it is an overloaded
term...

  "specify protocol(s) that can be used..."

  WDYT?
  Dave

  -----Original Message-----
  From: Margaret Cullen [mailto:[e-mail]]
  Sent: Monday, September 25, 2017 12:57 PM
  To: David Allan I <[e-mail]<mailto:[e-mail]>>
  Cc: [e-mail]<mailto:[e-mail]>
  Subject: Re: [Banana] Updated Charter


  Good point, Dave!

  I am a little concerned about the overuse of the term ³mechanism²,
though (since I define Bandwidth Aggregation mechanisms in the text).
So how about just changing ³protocol² to ³protocol(s)"?:

  OLD:

      Select or specify a signalling protocol that can be used to send
      control information between BANANA Boxes, including:

  NEW:

      Select or specify signaling protocol(s) that can be used to send
      control information between BANANA Boxes, including:

  Or is theres something more that you were trying to capture by
changing from ³protocols² to ³mechanisms²?

  In addition to what you mentioned, this might allow us to reuse an
existing protocol to do part of this job, even if that protocol could
not be extended to cover everything we need for BANANA.

  Margaret






On Sep 25, 2017, at 3:42 PM, David Allan I
<[e-mail]<mailto:[e-mail]>> wrote:

HI Margaret

An aspect that concerns me for a while is the notion that there will
be a single signaling protocol to satisfy a laundry list of
requirements. On first blush this seems to suggest a solution is
already in the wings that needs the laundry list, or that we will end
up with  a bloated superset god protocol. Neither of which is IMO a
totally desirable outcome.

Easiest fix for me would be to replace ³a signaling protocol² with
³mechanisms².

Cheers
Dave

From: Banana [mailto:[e-mail]] On Behalf Of Margaret
Cullen
Sent: Monday, September 25, 2017 12:33 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Banana] Updated Charter


No problem, Philip.  I have included the latest text below.  This does
not yet include the changes I am currently discussing with Dave
Sinicrope.

Margaret


Charter: BANdwidth Aggregation for Network Access WG

The BANdwidth Aggregation for Network Access (BANANA) Working Group is
chartered to develop solution(s) to support dynamic path selection on a
per-packet basis in networks that have more than one point of
attachment to the Internet.

Bandwidth Aggregation consists of splitting local traffic across
multiple Internet links on a per-packet basis, including the ability to
split a single flow across multiple links when necessary.

It is the goal of this WG to produce a Bandwidth Aggregation solution
that will provide the following benefits:

  € Higher Per-Flow Bandwidth: Many Internet links available to homes
and small offices (DSL, Cable, LTE, Satellite, VPNs, etc.) have
relatively low bandwidth. Users may wish to run applications (such as
streaming video, or content up/downloads) that require (or could
benefit from) more bandwidth for a single traffic flow than is
available on any of the local links. A Bandwidth Aggregation solution
could supply the needed bandwidth by splitting a single traffic flow
across multiple Internet links.
  € Reduced Cost: Traffic sharing on a per-packet basis allows the
full bandwidth of the lowest-cost link to be used first, only using a
higher-cost link when the lowest-cost link is full.
  € Increased Reliability: When one Internet link goes down, ongoing
application flows can be moved to another link, preventing service
disruption.

Proposed BANANA solutions use different mechanisms (e.g. tunnels,
proxies, etc.) to split and recombine traffic, but at an abstract
level, they involve a local (hardware or software) component on the
multi-access network, a remote component within the Internet or at the
remote end, and mechanisms for those components to find each other,
exchange signalling information, and direct traffic to each other.   We
refer to the functional components at each end as the Local and Remote
³BANANA Boxes², and we refer to the mechanisms they use to direct
traffic to each other as ³Bandwidth Aggregation mechanisms².

[Note:  Despite our use of the term ³Boxes², it should be understood
that a ³BANANA Box² might be a software component running on a piece
of hardware with another primary purpose (e.g. a CPE router).]

The Bandwidth Aggregation solutions developed in this group will work
in true multi-provider scenarios (i.e. they will not depend on all of
the aggregated links being provided by a single Internet access
provider nor by a group of cooperating providers).  Any protocols
defined by this group will be IP-based, link-layer-independent
solutions, and they will be designed to work across NATs and other
middle boxes, as needed.

The BANANA WG is chartered to complete the following  work items:
  € Informally document/discuss BANANA problem statement and usage
scenarios in a non-archival document (e.g. Wiki, Google Doc, etc.)
  € Determine how Local and Remote BANANA Boxes find each other (i.e.
describe how BANANA boxes will be provisioned/configured.)
  € Select or specify a signalling protocol that can be used to send
control information between BANANA Boxes, including:
  € IP Prefixes of access  links
  € Information about link status and properties (including
congestion)
  € Information needed by the Bandwidth Aggregation mechanism(s) in
use
  € Determining which flows are/are not eligible for Bandwidth
Aggregation
  € Select (and extend, if necessary) a tunneling encapsulation for
sending traffic between BANANA Boxes.

When applicable, the BANANA WG will use existing IETF protocols, or
extensions to existing IETF protocols, as the basis for the work items
listed above.  When an existing protocol is used, the WG deliverable
will be a document describing the use of that protocol for Bandwidth
Aggregation and/or a set of options or extensions to an existing IETF
protocol to make it useful for Bandwidth Aggregation.

The BANANA WG will also work with other IETF WGs (and other SDOs, as
requested) that define additional Bandwidth Aggregation mechanisms (if
any)  to ensure that the protocols defined by the BANANA WG will meet
the needs of those additional mechanisms.

Milestones
  € Apr 2018 Adopt WG draft for provisioning/configuration mechanism
  € Apr 2018 Adopt WG draft for signaling protocol
  € Apr 2018 Adopt WG draft(s) for tunnel encapsulation(s)
  € Feb 2019 WGLC on provisioning/configuration mechanism
  € Feb 2019 WGLC on signaling protocol
  € Feb 2019 WGLC on tunnel encapsulation(s)
  € Aug 2019 Send provisioning/configuration mechanism to the IESG
  € Aug 2019 Send signalling protocol to the IESG
  € Aug 2019 Send tunnel encapsulation(s) to the IESG

On Sep 25, 2017, at 12:37 PM, <[e-mail]<mailto:[e-mail]>>
<[e-mail]<mailto:[e-mail]>> wrote:

Margaret,
Please could you post the text on the mailing list, as our firewall
blocks google docs Thanks!
phil

From: Banana [mailto:[e-mail]] On Behalf Of Margaret
Cullen
Sent: 22 September 2017 20:19
To: [e-mail]<mailto:[e-mail]>
Subject: [Banana] Updated Charter

I have updated the charter text in an attempt to reflect all of the
feedback to date.  You can find the new version here:
https://docs.google.com/document/d/1byOJ_To6eL1ZBxKSYpTafQbngTBiNwxaK7
ReIsld9Ek/edit

Thoughts?  Comments?

Do folks think this is ready to send to the IESG?  Or are there other
changes that it would make it clearer or better?

Margaret

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


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

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