Re: [Banana] Charter

Margaret Cullen <mrcullen42@gmail.com> Tue, 19 September 2017 03:14 UTC

Return-Path: <mrcullen42@gmail.com>
X-Original-To: banana@ietfa.amsl.com
Delivered-To: banana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFDC133211 for <banana@ietfa.amsl.com>; Mon, 18 Sep 2017 20:14:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzSB3Zs4he8a for <banana@ietfa.amsl.com>; Mon, 18 Sep 2017 20:14:55 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611751321BB for <banana@ietf.org>; Mon, 18 Sep 2017 20:14:55 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id l25so2514914qtf.13 for <banana@ietf.org>; Mon, 18 Sep 2017 20:14:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=vzRMV1x+dCiUv3qwRcz82G/7mfsbi9vERTn60AGzijA=; b=GO/n3om59isyyGjAzWzCkXWE3cuRdvqsrG2H6jq/nLd36ga/C9xOX4uQosDA4ir7nT Ol9sEwv/XkkP8cqi+pVQrL5Lt4DguXbbQbL2P8i4gPAJbzpZUQvmm1BbDhfIGHwuZOjW 1Nl4m7WVUObvVCfn8TVwKDNGveLpiGPhsXitwhiTDyvjYZCZyz3tgC69VAAbUTz8jYXq fCdElWk0eFJK1PaDOy+kdp863/hwiRyjkaD0IMRrkcjxgi8+XL0T3kokRKsZYZNqUb1n vyp9btgUhX7UQvN0VuUHKJC3LQ0k+st4V9ePbRr2hm5GrzLtZcpXArwKhZePR+Shz3GO IYog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=vzRMV1x+dCiUv3qwRcz82G/7mfsbi9vERTn60AGzijA=; b=EJWO9TSQHRuq+0sseEH9warvtzNhH0ttBIGjplYfYQ91MvfP7Ye3mHWweK9TPpj2Jw 0N5U3P7uwtGzsYd8klWLmqrJL/9CISXD93gGmiu8w4GNJ1uvgbz5ErrNTiV6ebaLMqL3 LxIyCRCIWjQe8FjZjftiHr4XKvRg+4KIHHxW+430n5FGUWNwaxe9EhTnc+Z+gIoN9RQ2 +p+yKTnIFJn6wn7BhUDFcDKZd84afVtsnOB283vooj72eg8nmGwC/10eEolPfUui3MXo fJtEcOlO6D+wXlsUwL/plD0IBGzqYqyvP4SVI5HDEjnAukY8aghy5+Tii6oVOfZP8Aiv F5sA==
X-Gm-Message-State: AHPjjUj5OdHFZvj1VISxoR3jYRGqP0IwW5LjvWtASZDEp798APmluu/E YrZ8jMykdvVDMw==
X-Google-Smtp-Source: AOwi7QCSSX8871/cWKLX4p68bbqZHEpXmEnxfu9YpI9Ml3isjvnY8Gpw8aiWdEQfldtQM/0pJH8uTQ==
X-Received: by 10.200.52.117 with SMTP id v50mr55925628qtb.333.1505790894462; Mon, 18 Sep 2017 20:14:54 -0700 (PDT)
Received: from ?IPv6:2601:18c:503:a54a:f47b:5bf6:c24c:20c5? ([2601:18c:503:a54a:f47b:5bf6:c24c:20c5]) by smtp.gmail.com with ESMTPSA id m18sm463761qtb.77.2017.09.18.20.14.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Sep 2017 20:14:53 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0C2584A9-AB5A-4DBE-AB25-14BBFAE0FCB7"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Margaret Cullen <mrcullen42@gmail.com>
In-Reply-To: <D5E5AA42.22D7AB%sgundave@cisco.com>
Date: Mon, 18 Sep 2017 23:14:52 -0400
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, "Zhangmingui (Martin)" <zhangmingui@huawei.com>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, "banana@ietf.org" <banana@ietf.org>
Message-Id: <6560351F-7753-48A7-8601-BF6E91C6AC36@gmail.com>
References: <96A7BC33-FB64-487A-A60D-7AB8504C9DDF@gmail.com> <a1df884a51f246a7969c0057ff78d807@BTWP000357.corp.ads> <C3A4BFB9-EAD7-4B32-90C1-248D6D74ECD1@gmail.com> <9A767D1D-C6CA-4C7D-A281-7150E259881D@gmail.com> <DB5PR07MB13998EE07C5B5D5DBACED79C9B1A0@DB5PR07MB1399.eurprd07.prod.outlook.com> <7ED94797-5E72-4191-B861-4CD2F410BBD5@gmail.com> <7i60gox0c8.wl-jch@irif.fr> <DB5PR07MB1399FEDB262E0205457EA8AB9BFC0@DB5PR07MB1399.eurprd07.prod.outlook.com> <87bmqgov69.wl-jch@irif.fr> <DB5PR07MB1399977AFFE9FA7D19A2D34D9BFC0@DB5PR07MB1399.eurprd07.prod.outlook.com> <0d8ce583860345b89020113f1239be5d@BTWP000357.corp.ads> <21BD0F20-9CE5-466B-992E-93F6D84DB7D4@gmail.com> <95788B92-E8C1-4FE6-9B0C-7F29361D9297@trammell.ch> <d3759d89-9f6e-bcf4-8c44-32f3f435d784@gmail.com> <01e83ac6-0bd0-e7c7-01e4-0ffb7af73034@gmail.com> <4B6D7CF5-E6BC-4ECA-9299-7458A624320B@nokia.com> <B31BA5EB-7369-4B49-B240-AA6C3E653231@gmail.com> <2F216DBC-43EE-45AC-AAB8-68C81A14AD73@nokia.com> <4552F0907735844E9204A62BBDD325E7A65EC703@NKGEML515-MBX.china.huawei.com> <260086DD-D245-46EF-89E2-308D5A58AAFB@nokia.com> <5FECB6A6-41B7-41D1-A8B8-B7BCE8474F90@gmail.com> <2CD45C9D-41FB-425F-946E-D3AE47C9B000@nokia.com> <6A618A1C-92FB-467F-8F7D-6A9B40FC191E@gmail.com> <D5E56BEA.28AE8D%sgundave@cisco.com> <9CD725AF-B9FE-4E81-BFD6-21A812DF48CF@gmail.com> <D5E58ECD.22D723%sgundave@cisco.com> <355C07D1-032F-4E07-AEEB-6E1FD5024A68@gmail.com> <D5E5AA42.22D7AB%sgundave@cisco.com>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/3skEEQHa54jcC39c9sjUDvE2cSw>
Subject: Re: [Banana] Charter
X-BeenThere: banana@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Bandwidth Aggregation for interNet Access: Discussion of bandwidth aggregation solutions based on IETF technologies." <banana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/banana>, <mailto:banana-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/banana/>
List-Post: <mailto:banana@ietf.org>
List-Help: <mailto:banana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/banana>, <mailto:banana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Sep 2017 03:14:57 -0000

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) <sgundave@cisco.com> 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 <mrcullen42@gmail.com <mailto:mrcullen42@gmail.com>>
> Date: Monday, September 18, 2017 at 4:15 PM
> To: Sri Gundavelli <sgundave@cisco.com <mailto:sgundave@cisco.com>>
> Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com <mailto:wim.henderickx@nokia.com>>, "Zhangmingui (Martin)" <zhangmingui@huawei.com <mailto:zhangmingui@huawei.com>>, Alexandre Petrescu <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>, "banana@ietf.org <mailto:banana@ietf.org>" <banana@ietf.org <mailto:banana@ietf.org>>
> Subject: Re: [Banana] Charter
> 
> 
>> On Sep 18, 2017, at 6:30 PM, Sri Gundavelli (sgundave) <sgundave@cisco.com <mailto:sgundave@cisco.com>> 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