Re: [Banana] Updated Charter

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Fri, 29 September 2017 13:04 UTC

Return-Path: <sgundave@cisco.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 82B2C13451A for <banana@ietfa.amsl.com>; Fri, 29 Sep 2017 06:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Iu4QWvGP82FN for <banana@ietfa.amsl.com>; Fri, 29 Sep 2017 06:04:04 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA94D13292F for <banana@ietf.org>; Fri, 29 Sep 2017 06:04:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4911; q=dns/txt; s=iport; t=1506690243; x=1507899843; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FOQsh2oLGYYMcx6QRlSUjg73PL0033xFdZqsydKV2EE=; b=Y1G7TI88xdNsUDbz91IUPNa2xXzgfeY8ASPvIbsyuWW2YKNC5YGDzxqD lmWhq5Q4NRDWPw8b9qVE3yE7auHU7njPEaTB6sy74nN/qNpH2zBsRzA+M qL7kWuL35FeVAEviy4jIJJk4yCcPLLAQDenoIz7ZJd2FSv3iR91ntZLUI I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AoAgDaQ85Z/4oNJK1eGQEBAQEBAQEBAQEBBwEBAQEBgm9tgVIng3iaAIFUkQ+HUAqFOwIahBNXAQIBAQEBAQJrHQuFGQYjVhACAQgEOwMCAgIwFBECBA4FG4kyZKcZgieLRAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DLYICgVGBaisLgnKIFy+CMQWhLAKUYpMHlSECERkBgTgBV4EOeBVbAYcKdog6AQEB
X-IronPort-AV: E=Sophos;i="5.42,452,1500940800"; d="scan'208,217";a="9903511"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Sep 2017 13:04:03 +0000
Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v8TD42IV017789 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Sep 2017 13:04:03 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 29 Sep 2017 08:04:02 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Fri, 29 Sep 2017 08:04:02 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: "N.Leymann@telekom.de" <N.Leymann@telekom.de>
CC: "praveen.muley@nokia.com" <praveen.muley@nokia.com>, "margaretw42@gmail.com" <margaretw42@gmail.com>, "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>
Thread-Topic: [Banana] Updated Charter
Thread-Index: AQHTM9eexsvXjcsNVkeNi77GH0FlxKLGAnlIgABWaYCAAAQaAIAABH0AgACdkYCAAPbEgP//kB8AgAGuBQCAAAHFAIABLSAA////OYCAAJ75AP//n7KAAA/13gD//5W4gIAAjDKA//+WOID//0hvQIAB4DUA///d+C8=
Date: Fri, 29 Sep 2017 13:04:02 +0000
Message-ID: <AB097715-06CF-4346-8D71-F85A1D94FFE7@cisco.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> <867B5DD2-E180-476E-B6DA-D1D939A8F8D9@gmail.com> <D5F2ADD7.5A3D%sgundave@cisco.com> <C753FE39-71C5-46BB-91F2-1666D482C575@gmail.com> <D5F2CA59.5A89%sgundave@cisco.com> <HE1PR0701MB2188DBC9FE6021F47C14521BEA7E0@HE1PR0701MB2188.eurprd07.prod.outlook.com>, <1890cb3cd61b4d799497b0dc01030143@HE105662.emea1.cds.t-internal.com>
In-Reply-To: <1890cb3cd61b4d799497b0dc01030143@HE105662.emea1.cds.t-internal.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_AB09771506CF43468D71F85A1D94FFE7ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/hWUuaIx28zq7C4d-rq6FiPcqS30>
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: Fri, 29 Sep 2017 13:04:05 -0000

Hi Nic,

On Sep 29, 2017, at 3:06 AM, "N.Leymann@telekom.de<mailto:N.Leymann@telekom.de>" <N.Leymann@telekom.de<mailto:N.Leymann@telekom.de>> wrote:

I see here the risk that every WG comes up with a specific solution (e.g. for QUIC, MPTCP, …). The might use different control mechanisms and
even different policies (e.g. QUIC might prefer WLAN over LTE, MPTCP LTE over WLAN).

There will never be one God protocol which is the protocol for a solution. QUIC/MPTCP/MobIKE/MIP/SSL/GTP are all candidate protocols that will be enhanced and deployed for multipath related solutions. We cannot stop them from extending those protocols.

We are mixing interoperability within a protocol, with interoperability across solutions.
IETF is not in the business of mandating a specific protocol for a solution, or strive for a single solution across internet. A vendor/SDO may use "n" of protocols of his choice for a solution. We only ensure interoperability within a protocol and not interoperability across solutions. Again, IETF has not standardized "the routing protocol", or "the IPv6 transitioning protocol" and there will never be, "The Banana protocol".

Sri