IETF Logo Mail Archive

Re: [Banana] Charter Text w/Milestones

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Tue, 11 April 2017 17:02 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 0C22C12EB22 for <banana@ietfa.amsl.com>; Tue, 11 Apr 2017 10:02:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 d443rF5B7Dzb for <banana@ietfa.amsl.com>; Tue, 11 Apr 2017 10:02:04 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B98512EB16 for <banana@ietf.org>; Tue, 11 Apr 2017 10:02:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32715; q=dns/txt; s=iport; t=1491930124; x=1493139724; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2eyI2WJDbV4lIYqcUKxIpCjPfe4lF2X8ZlqpnSnRizs=; b=BscR+oPkFkbowfwYLXkQP/701AT1x8cPLQgVY2hB7sf2VjUKi312BdaU phDJfY31QIIp/xWELKBojunKdz8J8iYh6ISelSo7rKi92+RG2RkFXBIpL CbixjbvK/RpisuG/3dPA/NOF8ooiB3hxQTirL6nq0eNb4iGxCrETnewGJ g=;
X-Files: 5C4402A7-A916-4F52-93DB-82E9837B6630.jpg : 18843
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AaAQAjC+1Y/5BdJa1cGQEBAQEBAQEBAQEBBwEBAQEBgm5lgWwHjXKhcoINgyeCDwcBhhwCg2E/GAECAQEBAQEBAWsohRYGBXQQAgEIDg8BAQEKFQcCBRABDgwUEQIEDgQBBgiKAqtNin4BAQEBAQEBAQEBAQEBAQEBAQEBAQEOD4ZQhHCKOwEEkC6JZQOCaQGGCoxTgX+FLooXk3kHAR84gQVbFYUcHIFjdYhIgQ0BAQE
X-IronPort-AV: E=Sophos;i="5.37,186,1488844800"; d="jpg'145?scan'145,208,217,145";a="234672744"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2017 17:02:03 +0000
Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v3BH23Ec024647 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Apr 2017 17:02:03 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Apr 2017 12:02: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.1210.000; Tue, 11 Apr 2017 12:02:02 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Juliusz Chroboczek <jch@irif.fr>
CC: "banana@ietf.org" <banana@ietf.org>
Thread-Topic: [Banana] Charter Text w/Milestones
Thread-Index: AQHSqXAp2s4lKhNks0mSUBk5UfvI8KGuA2eAgAeDAYCAAHgogP//mFwAgAV2AgCABVoagA==
Date: Tue, 11 Apr 2017 17:02:02 +0000
Message-ID: <D51252DC.26CD6B%sgundave@cisco.com>
References: <96A7BC33-FB64-487A-A60D-7AB8504C9DDF@gmail.com> <E6C17D2345AC7A45B7D054D407AA205C68D24314@eusaamb105.ericsson.se> <D5093953.266331%sgundave@cisco.com> <6eb47203c5f447d3bd3dd1e8c38d0f5c@BTWP000357.corp.ads> <D5094D7C.223DAC%sgundave@cisco.com> <8760ifu27d.wl-jch@irif.fr>
In-Reply-To: <8760ifu27d.wl-jch@irif.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.32.246.213]
Content-Type: multipart/related; boundary="_004_D51252DC26CD6Bsgundaveciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/rc9dktcLKa-4GWAdCObx9cTXRpo>
Subject: Re: [Banana] Charter Text w/Milestones
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, 11 Apr 2017 17:02:06 -0000

I am sure you can review the thread in the archives, Julius. I hope you will also answer the questions on the need for a new signaling protocol and how that will be better than existing protocols.

I also do not see a need for both of us to engage in any arguments about this work. There are literally 2 or 3 people supporting this work and every one else opposing it and there is zero SDO support. I am sure AD will do that counting and we do not have to bother about that. But, IMO, this is not going any where and so we as well save some time :)

But, just to get the focus on the minor gap in the existing work, please see the below diagram.  If you remove the signaling from the equation, you have a scenario where there are multiple overlay tunnels between two peers (CPE and aggregation gateway) and its about how you efficiently use those two paths for the IP traffic. There is MPTCP and there is other existing work around IFOM/DSMIP that does take care of policy based routing (refer to RFC7629, RFC6088, RFC6089, RFC5555, RFC7864 and few other I-D's);. Sure, the later work does not exactly tell you how to split a flow. But, vendors have always done that and used IP SLA probes for path measurements.

[cid:5C4402A7-A916-4F52-93DB-82E9837B6630]


So, this has nothing to do with signaling and its strictly about user-plane. There is no need for defining a new signaling protocol, a new discovery mechanism, authentication, policy interfaces, path check frame work ..etc.   This is massive amount of work and industry is not looking for that. If you really want some information spec on how two forwarding entities can deal with this for overlay tunnels, one can certainly publish an informational I-D in INT area. It can be certainly used by IETF or SDO specific signaling protocols that use overlay tunneling modes.


Sri



On 4/7/17, 6:18 PM, "Juliusz Chroboczek" <jch@irif.fr<mailto:jch@irif.fr>> wrote:

I'm afraid I missed the beginning of this discussion, so please forgive me
if that has been answered before.

What point are you making, Sri?  Are you saying that MIPv6 already solves
the problem that BANANA is aiming for, or are you merely saying that
BANANA should reuse as much of the MIPv6 signalling protocols as possible?

In either case, I'd appreciate some pointers to reading material.

Thanks,

-- Juliusz

v2.23.0 | Report a Bug | By Email