Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00

Robert Raszuk <robert@raszuk.net> Mon, 05 November 2018 18:04 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1051277D2 for <bess@ietfa.amsl.com>; Mon, 5 Nov 2018 10:04:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 yQOeOvAcr1Ij for <bess@ietfa.amsl.com>; Mon, 5 Nov 2018 10:04:39 -0800 (PST)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 83107127133 for <bess@ietf.org>; Mon, 5 Nov 2018 10:04:39 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id d19so16373111qkg.5 for <bess@ietf.org>; Mon, 05 Nov 2018 10:04:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mCI0ztN4O0K+Rt3bZ+7FaNWSnMbUoQvaZ83LbRWFUGg=; b=T3AwEQ9FUTtHutKzeTr94MabpzC8L7T/Q1EN5MjJMp8c6xiQejDhlrZofgO+p6KFpn 9twWR+ApVwugpP06u1QKOya0lLLrqT2+LdNl25uTvr6et3pCTSKHppcgZamIFtyfJhxl 5nevyhxvfJRvH4OUQFQli4XA7Lfzn6P0dLbHlS2/fj52jej2pf1tWLL76IBI1ZKTMrBa Cfz8vBdNTOx/Bf4hEWIkhvVrvyDXX/rofxMQivflA7SzGEx7A7KQpvS9n8YfJdJ+QiCe E8IKq1JUoJwzZ9zGsOChl71n94YWBaGXEd3Am3i3jQNB05JpqLuoCccZebQ3uPNOo5w2 4JNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mCI0ztN4O0K+Rt3bZ+7FaNWSnMbUoQvaZ83LbRWFUGg=; b=WJon01kdhqqzfs0o6iFhx7iZTshy11BWYED9yyFEzJnTx/6thn0Ch8pKHi3Y10WCIb xkM50lNz7H+aChGOjdIpLcDerQSfa1gar/pf9qzlkXthLBt0rh+gqED+k+P5P8Ct1Nus x6C21hZB2ebCop2ZWAfzPmrlAqqb0ka7dLx4q9uQRMcG+TJcZRU6Qz0qgvZWjQXPbt4w RATrmD14PnVIjk8VU57Xm1MxXg4DhWi6lG/zSslAfppSi1HY/jGQbIMtK8i5eJz3UcRc bo98KFpFNP4OQ/oaDnR0FKoOv+GbJ4R1NwhpcqwlVCK6LYgL8oSsxjPvZT47jNAtoadT ZQbg==
X-Gm-Message-State: AGRZ1gIobZZwSxnUNgFBpKo4r3nv2ArcHNb4HBsc0+tw8mYZRjDIEuxv 6eSqjJPkkPJ17d8rnaXtCyzi0QsWvDlqP0abta83LpnxLNg=
X-Google-Smtp-Source: AJdET5eyJUff/n94m1Dgn9uM8CUhcuCKGE4wCbzlL9OsZAUWY1TzEt+yl7Gtg24eojw2q8E2HJgaVRVCAzEj/Yy/MHk=
X-Received: by 2002:a0c:e84f:: with SMTP id l15mr22051697qvo.124.1541441078610; Mon, 05 Nov 2018 10:04:38 -0800 (PST)
MIME-Version: 1.0
References: <4A95BA014132FF49AE685FAB4B9F17F66B17F9DE@sjceml521-mbs.china.huawei.com> <CAOj+MMF+0NA9xHFAt__GkbwYL6_wfJqKy2Wi-qo5+iNJ=drajw@mail.gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B182896@sjceml521-mbs.china.huawei.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B182896@sjceml521-mbs.china.huawei.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 05 Nov 2018 19:04:27 +0100
Message-ID: <CAOj+MMHKNcUrr9ttU3=usg9D6k-=PFqZeYvufWDd0CAUEAAtoQ@mail.gmail.com>
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: idr@ietf.org, bess@ietf.org
Content-Type: multipart/alternative; boundary="000000000000eede450579eeb744"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/UjjVf8DzGuB22Ux3KHXIDfhYHRE>
Subject: Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2018 18:04:42 -0000

Hi Linda,

There are some key differences: Skype and CDN overlay companies don’t have
> any intension to interoperate, but networking needs interoperability.
>

There is no issue about interoperability. Observe that that each endpoint
can today seamlessly be a member of N different SD-WAN orchestration
systems. In fact wise deployment requires that to provide sufficient
robustness on a per site SD-WAN VPN basis.

 Adding a new BGP SAFI is 1% of implementation burden of adding a new
> protocol.
>

Look ... BGP RRs got loaded with carrying dynamic IGP data. Now we are
facing to load it with IPSec data. Where does this end ?

IMHO IDR WG should evaluate each proposal for extension in the view of what
elements of BGP protocol given extension attempts to augment. If this is
solely for transporting opaque data such proposal should be either denied
or ensured by MUST that is has to run on different instance of real BGP
(just to accomodate your 1% code extension) as proposed
in draft-raszuk-mi-bgp-00


4. Registry of Data on AWS etc...
>
> [Linda] sure if AWS is interested in participating to make the needed
> changes. More work is needed to make AWS Data registry to communicate our
> existing BGP?
>

AWS or Azure or GCP should not play any role in that. Those would be purely
compute infra providers taking no responsibility for what data is being
exchanged there. Obviously some vendor neutral entitiy should operate it.
Likely some ICANN analogy on how DNS is being run today.

But as mentioned above for SD-WAN I really do not see a problem. Any open
or closed SD-WAN orchestration with just few clicks of the mouse can add or
delete sites and such sites can participate in more then one SD-WAN. In
fact paying few dollars per month per site allows you to outsource your WAN
networking costs for peanuts as well as benefit from a lot of non limited
custom features between SD-WAN providers.

Do we really want now to limit that innovation by putting them onto IETF
tracks (regardless of WG chosen to own this) ?

Thx,
R.