Re: [Banana] Charter

Margaret Cullen <mrcullen42@gmail.com> Tue, 19 September 2017 00:50 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 86DB01342AF for <banana@ietfa.amsl.com>; Mon, 18 Sep 2017 17:50:45 -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 zjSMHF3Z3YbY for <banana@ietfa.amsl.com>; Mon, 18 Sep 2017 17:50:43 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 993AF1342AA for <banana@ietf.org>; Mon, 18 Sep 2017 17:50:43 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id l25so2311662qtf.13 for <banana@ietf.org>; Mon, 18 Sep 2017 17:50:43 -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=WgZZwx4BuFAxLp4yh9/TXWdXQGBfGHTml1fYR1LsGvs=; b=BQJRC+ayG4sPcxeyW8l58MCcXzPnpTWa3wF30Sji8tgPQRB94nhsMa0ijG0HruGR0/ QPLgHnxUObUQWz2gAwpOsbbxcVZN9Lmp9VhOtynRMeZUEWB3WHfrLQ/FAXMWWNONS4jX DOZ9AUw89EUAOtyE/edRkjvxO8SY2MwsKx0a23WbvdzQmkX9ROpswrVFd145883CXx7U 7n38HwtGKWOA5ZmNGFzTaPS2+DeU8bQ4WOafPJA+YWNFyjP8QuTG3i7MDLUxFd2owG5d VIWYqc4zlfWcEbPkh5LiU7cwFHJyzAcdiedwj9Au2Ow6ZRBMe1BE2n4YwSLn0TBCfdzZ 6Jug==
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=WgZZwx4BuFAxLp4yh9/TXWdXQGBfGHTml1fYR1LsGvs=; b=G6V3OJgEuPXgJfLKIoylBh4tunO7tdHTNAclBJqsP/HKFCYs8BhiVF5++a7+QrY6xN 8sR5AhCi3v/P8lB/ic/7j2IXJG9yLXPdpwksSD59jUKELXJoaYYl938x4JlHZZ02N55T LASBt+W+sKI28MfnniiREu5KSxGi105nRUCJgK7wX49utq334VKMOfQt8w4dXNZAmlqc hsmYg9WbP8IhJQ/7yaiw8cLegxpS12WLAFuOmvfLvV4fTbcMlZhFzGHvqdCXfdF5HiC2 rkQe5zKDD0cF+y9moNfoCQpNMXkmwrCYWx9YK701xuyA47NT0d2e5h37et3aTsmpt7II FSNQ==
X-Gm-Message-State: AHPjjUhKa3fj0piz6KQkPbO6/LUXNz2tISzZdvPlIeIgPZoF4pzFZbUR lTUCWzE99O2NPl2MTQc=
X-Google-Smtp-Source: AOwi7QCIWJCkAr7vxYEo5X0Pf7k/QCUnqfTz3ZXBHZJGzF3Chkc7af6d9+SEeQdsOKvmmTXXXQDsEw==
X-Received: by 10.237.34.118 with SMTP id o51mr45319420qtc.36.1505782242649; Mon, 18 Sep 2017 17:50:42 -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 c11sm5853269qth.13.2017.09.18.17.50.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Sep 2017 17:50:41 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5115817C-642E-42F5-B761-E399118156D8"
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 20:50:40 -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: <E16200ED-1BEF-48F3-A43E-E738AD6A2A12@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/8dpJl7ETLJgJVDyOvlSM8hz8lEc>
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 00:50:45 -0000

HI Sri,


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

Cool.

I tried to look up “Cisco CCO”, and that appears to be a type of Cisco Customer ID for logging into a support/documentation system.  Not being a Cisco Customer, I guess I don’t have “CCO pages”.  Could you provide details here, or links that are accessible to someone who isn’t a Cisco customer?  What is the product actually called, so that I can look for other sources of information about it?

Also, what is the expansion of “SLA”? The only expansion I know of is “Service Level Agreement"  (i.e. a legal contract), but I assume you are referring to some sort of protocol?

> 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 existence of multiple deployed, proprietary solutions to this problem from multiple vendors only proves, to me anyway, that this is indeed an interesting problem to solve.  

Obviously, there could be advantages to having an open standard in this space for multi-vendor interoperability.   It sounds like the Cisco solution is based on open protocols, but that there might be proprietary extensions included (for the per-packet handling and signaling of performance data, etc.)?  Would you be willing to document your solution in Internet-Drafts to be considered for standardization?  If so, it sounds like this might be a very interesting candidate for BANANA work.

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

Although we don’t use the same terms, I believe the all of these things have also been considered in the Huawei GRE Tunnel Bonding solution (RFC 8127 and related documents), as well.  We have also had presentations on other solutions to this problem at various levels of specification and deployment.

We have more than just a few willing hands…  

Margaret