Re: [Banana] Updated Charter

Margaret Cullen <margaretw42@gmail.com> Thu, 28 September 2017 20:41 UTC

Return-Path: <margaretw42@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 BAABB13494C for <banana@ietfa.amsl.com>; Thu, 28 Sep 2017 13:41:24 -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 Yx6IgotiLF7L for <banana@ietfa.amsl.com>; Thu, 28 Sep 2017 13:41:23 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 4E8B31346BD for <banana@ietf.org>; Thu, 28 Sep 2017 13:41:23 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id b1so3394312qtc.4 for <banana@ietf.org>; Thu, 28 Sep 2017 13:41:23 -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=4vVcuLSOqqMXC/MxtkswPfYlddpYMHVsFzK4FrpIjn8=; b=qF9gfcwZBxT+cjPldOzLiedbmYp7qos926q3NvJ8C6m/caK2Sii3QNlIFm3XYuUDzM AeSNW4wFouQmVhPGvrDXo/TufvWyl6qkHAb5SgQkbB2pI5AmCT/Ke1iegsSytDq6BlVg hY/k7NQosF9sLzelXv62Iyx7PARDtUOG91bKVYoHfIczgmOMuQy6KaYOAUFtp4P21XQh /9NTWBdbsE3F+a4uOIcaHAjEo0gle0aqS6BTxVvNIOGdMu2ex5Cx/sdIcmVyDa+Ra9tE KJkRXOoUvDTxKFQpNwv9c0tif/Mgvk3AS/vnAZ3r4raowZD9B4d3fQcPEbA73oeumEaC 4YsQ==
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=4vVcuLSOqqMXC/MxtkswPfYlddpYMHVsFzK4FrpIjn8=; b=qSM3SRc1qbBKAGEeiV21vFuooRgLIhi8QgLNXm4UYe19qwF7EvCby5D5xaXy4gzfTt /gZAXkiCz3ImYawx+Hyi4pr/MgM8sZhoBeIz6O69/geFdi3RJU2NP3kSY/bMW7LJS7s7 q9qkUTgiZqfxgcYHDV+hvLnIjer+W2zzoj5ikkJThOTTLee15/k/OtEvuoGdoaNGqf9B soyTZZTKjT0Pl5j3d41o/b7Pw1j18PaIJQIJtxkqHAYuZMIfKLUPaS1QA1KVoED6WX1D uB9mvS4EcupeNltnICblqHKyHIymTiukL14UsvDa70L3tx2b2ohNvu/KK8ThpuEKTblN +xXA==
X-Gm-Message-State: AMCzsaVgdF/CzJz9I3QnPztMa/o73EX2Gkoo2KMO+/UVdt4I5Wet3A/V cQDH0AWVtKx8DTirJcIdSzk=
X-Google-Smtp-Source: AOwi7QAAztd053MLGUp7os/ZiAJ1nDF4kYrd1G5KMP3gxuqNqM7fGkjJ6fstMVohdDo9ryLfBEhUrw==
X-Received: by 10.200.9.66 with SMTP id z2mr2929389qth.254.1506631282401; Thu, 28 Sep 2017 13:41:22 -0700 (PDT)
Received: from ?IPv6:2601:18c:503:a54a:dd80:b7c7:708e:b64e? ([2601:18c:503:a54a:dd80:b7c7:708e:b64e]) by smtp.gmail.com with ESMTPSA id r28sm1661709qte.81.2017.09.28.13.41.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Sep 2017 13:41:21 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7C7F232C-8B9A-4CC1-9803-6BDB4749F4E3"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Margaret Cullen <margaretw42@gmail.com>
In-Reply-To: <D5F2935A.5985%sgundave@cisco.com>
Date: Thu, 28 Sep 2017 16:41:20 -0400
Cc: "philip.eardley@bt.com" <philip.eardley@bt.com>, "wim.henderickx@nokia.com" <wim.henderickx@nokia.com>, "david.i.allan@ericsson.com" <david.i.allan@ericsson.com>, "banana@ietf.org" <banana@ietf.org>
Message-Id: <867B5DD2-E180-476E-B6DA-D1D939A8F8D9@gmail.com>
References: <2F845727-395A-4FDD-9E6D-41734E22F9BD@gmail.com> <a7717b292b2f4ece916410f98dc38cb4@rew09926dag03b.domain1.systemhost.net> <BEBED891-9A4B-421F-BD80-606D20FB803B@gmail.com> <E6C17D2345AC7A45B7D054D407AA205C68F6B38A@eusaamb105.ericsson.se> <E8628CC1-A63B-422C-AF18-3A16AF3F9223@gmail.com> <E6C17D2345AC7A45B7D054D407AA205C68F6B49C@eusaamb105.ericsson.se> <B420FF35-A139-45EB-AE64-A330B58A5E28@nokia.com> <0C6764E0-B414-4F0A-A04C-B9CC9E5DFABB@gmail.com> <D5F00874.28BB74%sgundave@cisco.com> <A0ED15BD-D3D2-461A-83A8-FC4015A73EE2@gmail.com> <D5F1703B.5643%sgundave@cisco.com> <495513e936694f4da78b8ccf3091c618@rew09926dag03b.domain1.systemhost.net> <D5F26882.5810%sgundave@cisco.com> <D760CAA0-60B7-4DE6-A0CD-690B159E8249@gmail.com> <D5F2935A.5985%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/ajs9drF4u8rSHhoX9LqjpfiWMZw>
Subject: Re: [Banana] Updated 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: Thu, 28 Sep 2017 20:41:25 -0000

> On Sep 28, 2017, at 4:03 PM, Sri Gundavelli (sgundave) <sgundave@cisco.com> wrote:
> 
> > 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.  

I can see how (some of) the MIP technology could apply to (parts of) this problem space in interesting ways.  However, MIP (as it exists in the RFCs I have read, and presumably in most implementations) has several properties that don’t seem like a great fit for a the BANANA problem statement, including:

1) It is focused on mobility, not load balancing, and these aren’t inherently the same thing.  While I can see how you could repurpose some of MIP's mechanisms for load balancing, I don’t see how you could use an arbitrary RFC-compliant implementation for this purpose without modifications.
2) It is flow-based.  I didn’t see any mechanism for recognizing that a single flow has been split across multiple paths, and recombining that flow before forwarding it to the final destination.  
3) Its security model seems to rely on the notion that the destination node and the Home Agent are under the same administrative control.  Maybe RFC 6618 will change my mind about this — I will read it.
4) The home agent is on the “home network” of the destination, not necessarily on the network where the destination is currently located…  I think that bandwidth aggregation needs to have one endpoint on the local network with the end-node, so that it can detect that there is more than one local link to aggregate.  However, even if there was a home agent locally, I am not sure how/if a MIP end-node would find it and associate with it.

It is possible that I am missing something, but if so, then it is very likely that other people are missing it, too.  If you want us to decide that there is no need to specify a flow-based bandwidth aggregation mechanism because MIP already does that, I think you would need to do something to explain _how_ MIP already does that, because it isn’t obvious.

Margaret