Re: [bess] Any protocols suitable for Application Flow Based Segmentation in draft-bess-bgp-sdwan-usage-3?

Robert Raszuk <robert@raszuk.net> Tue, 05 November 2019 23:21 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 58D4012008F for <bess@ietfa.amsl.com>; Tue, 5 Nov 2019 15:21:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.298
X-Spam-Level:
X-Spam-Status: No, score=-1.298 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no 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 qWhKNKg-mnQw for <bess@ietfa.amsl.com>; Tue, 5 Nov 2019 15:21:40 -0800 (PST)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 6E638120072 for <bess@ietf.org>; Tue, 5 Nov 2019 15:21:40 -0800 (PST)
Received: by mail-qk1-x731.google.com with SMTP id a18so5267037qkk.7 for <bess@ietf.org>; Tue, 05 Nov 2019 15:21:40 -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=q19Bkw2H/BR8j5hlk7wGAFhA5azOBbHYnZldf1uj7VQ=; b=TQXa/y7VA2A58ksTqjon0pkl7yT5GdDHcQBsmVrnjnnF0vq+vm3CqdobbGM8KjUjAO SCMFyqZ6yEiogNFihocY69Mtz9x6q3WTA/i6WpRjxuWpE/BiFJHoQZK5TZrMuE95r8Ky wKRFzP+3/jxfCXwPzhXEb6tdVLEMhLCGk1V5pkilLGQdPro5XSyqkeSRUtbDM+e09b8s eO/W9FKbZro2YdMs6m9u0Sm944eczRlT4UcnDFj8OlA+8lCrN/cMkDJNL3i7RtX4mis3 jx+coGREDRlQgTRbob5zsog0TrCH0ZHmogyQEqO0MlduQhyA0EzYcudSyYRXm9JJylot s6zw==
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=q19Bkw2H/BR8j5hlk7wGAFhA5azOBbHYnZldf1uj7VQ=; b=aFCh2wrM2TfWi85mCDvtjCVzFlxl3oMPLo7VmW7dY4baCnQISJp5b8ZQJ3AmAYnOLY Hdl0zirVIeQtjfeOUrLnvCVuIaXNAw5t3Ytft7V9sgv2t6Tx1jFuPH0LcYF+TccQqZky Wa7pEeGfneD9Iub3KOVYVLjTMdK/fNrn2ghfgTPLbkJOYT0KSjZk4l1GPoPd4lnsWQqy VAo1XKcLFBnqBVEFRyukoz1e1Qnv8rVOX8ulUzH4tcipL64leFXOq2/O03Thie43sfcA QP1ib1GCNK+7qEdFUtokvdnmHNGhcs0Rj+VlnhjhbJ3R3nK0QrVr6CPDmPjxV/4TqgLD WeZQ==
X-Gm-Message-State: APjAAAVrrb0HwfviqqFI02J8X7bE7hq4h2MhGJL0RqjBSCQB3+dcINZa mXXMbU+lDM0m7J6OhQDxFhY8PDKOYg5Pe2PsZRDOpw==
X-Google-Smtp-Source: APXvYqyQi+TUgi+EBZ7RpNN/qUViYdzJQr4+kbaOsfv8ca07XuvLbWrz1XXQ+TGoyAWnbtNbXd8stIaSQcxYfKepnc4=
X-Received: by 2002:a37:6087:: with SMTP id u129mr8195793qkb.219.1572996099271; Tue, 05 Nov 2019 15:21:39 -0800 (PST)
MIME-Version: 1.0
References: <BN8PR13MB262842C35C9955B8B45FAF08A97F0@BN8PR13MB2628.namprd13.prod.outlook.com> <CAOj+MMFqQNt4g4g+x3K6fn9X0ruOirFGKcXMPcpAUxm7xvHFSw@mail.gmail.com> <BN8PR13MB262822A6F3231D44628ED474A97E0@BN8PR13MB2628.namprd13.prod.outlook.com> <CAOj+MMHfjEsieECKHV9kTHKTYVMrK4dqecu3-SkzEU39HrzHFg@mail.gmail.com> <BN8PR13MB26284A0D4C3566BFDE147723A97E0@BN8PR13MB2628.namprd13.prod.outlook.com>
In-Reply-To: <BN8PR13MB26284A0D4C3566BFDE147723A97E0@BN8PR13MB2628.namprd13.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 06 Nov 2019 00:21:29 +0100
Message-ID: <CAOj+MMEk9bM1UB114j3=zpZpaB+U5sEpe_SmjZr6RMBZZ=FgqQ@mail.gmail.com>
To: Linda Dunbar <ldunbar@futurewei.com>
Cc: "bess@ietf.org" <bess@ietf.org>
Content-Type: multipart/related; boundary="000000000000bb617e0596a1b1eb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/klCEm2ZcVFq-4FWzFtHLf_Z-qwA>
Subject: Re: [bess] Any protocols suitable for Application Flow Based Segmentation in draft-bess-bgp-sdwan-usage-3?
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: Tue, 05 Nov 2019 23:21:42 -0000

> it is tremendous amount of work.

Well I am afraid this is entering implementation space and not subject to
any further debate on or off the list. Only note that IPSec is not the only
payload encryption option at your disposal for quality SDWANs.

On Tue, Nov 5, 2019 at 11:07 PM Linda Dunbar <ldunbar@futurewei.com> wrote:

> Robert,
>
>
>
> It is not the FIB size, but the number of IPsec SA maintenance required at
> each edge node that makes it difficult to scale more than 100 nodes.
>
> Each IPsec SA requires periodical key refreshment. For one node
> maintaining X number of IPsec SA, it is tremendous amount of work.
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Tuesday, November 05, 2019 3:15 PM
> *To:* Linda Dunbar <ldunbar@futurewei.com>
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] Any protocols suitable for Application Flow Based
> Segmentation in draft-bess-bgp-sdwan-usage-3?
>
>
>
> Linda,
>
>
>
> The key message here is that in properly designed SDWAN your limit is
> capped by volume of data traffic required to be encrypted and supported by
> your platform. Number of overlay adjacencies does not matter.
>
>
>
> It does not matter since the size of your FIB has orders of magnitude more
> capacity then any single SDWAN number of endpoints.
>
>
>
> Best,
>
> R,
>
>
>
> On Tue, Nov 5, 2019 at 9:20 PM Linda Dunbar <ldunbar@futurewei.com> wrote:
>
> Robert,
>
>
>
> You said “It has been deployed and is fully operating with no concern of
> scalability for number of years at least from one vendor I am aware of.”
>
>
>
> How many nodes of this deployment?
>
>
>
> As you described: just two nodes might need 18 IPsec tunnels. How about
> 100 node SDWAN network? 100*99 * 18?
>
>
>
> “So number of overlay pipes to be created in corresponding SDWAN data
> planes is 9 in each direction just over those *two* end points. 18 if you
> consider bidirectional traffic”
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Monday, November 04, 2019 6:54 PM
> *To:* Linda Dunbar <ldunbar@futurewei.com>
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] Any protocols suitable for Application Flow Based
> Segmentation in draft-bess-bgp-sdwan-usage-3?
>
>
>
> Hi Linda,
>
>
>
> > Overlay, the multipoint to multipoint WAN is an overlay network. If
> using IPsec
>
> > Point to Point tunnel, there would be N*(N-1) tunnels, which is too many
> to many.
>
>
>
> Please observe that any to any encapsulated paths setup in good SDWAN is
> day one requirement. And that is not only any src/dst to any src/dst. It is
> actually from any source interface over any available underlay to any
> available remote interface of the destination.
>
>
>
> Imagine if you have two end points each with three interfaces to the
> underlay. So number of overlay pipes to be created in corresponding
> SDWAN data planes is 9 in each direction just over those *two* end points.
> 18 if you consider bidirectional traffic.
>
>
>
> Good SDWAN can build such state and not only that .. it can also run in
> continued fashion SLA probes over all possible paths between given src and
> destination. When data is sent over selected per application path it is
> then encrypted. It can even do much more ... it can perform
> SDWAN-TE treating some endpoints as transits :).
>
>
>
> It has been deployed and is fully operating with no concern of scalability
> for number of years at least from one vendor I am aware of. So I question
> your observation and do believe that adding vrf based routing over well
> designed and correctly written SDWAN is of any scalability concern. As a
> matter of fact the implementation I am familiar with also has built in
> concept of VRFs too.
>
>
>
> No it is not trivial - but clearly possible.
>
>
>
> Best,
>
> Robert.
>
>
>
>
>
> On Mon, Nov 4, 2019 at 11:39 PM Linda Dunbar <ldunbar@futurewei.com>
> wrote:
>
> In MEF SD-WAN Service Specification WG, there has been a lot of discussion
> on Application Flow Based Segmentation.
>
> Application Flow based Segmentation refers to separating traffic based on
> business and security needs, e.g. having different topology for different
> traffic types or users/apps.
>
> For example, retail business requires traffic from payment applications in
> all branches only go to the Payment Gateway in its HQ Data Centers, whereas
> other applications can be multi-point (in Cloud DC too).
>
> Segmentation is a feature that can be provided or enabled for a single
> SDWAN service (or domain). Each Segment can have its own policy and
> topology.
>
> In the figure below, the traffic from the Payment application (Red Dotted
> line) is along the Tree topology, whereas other traffic can be multipoint
> to multi point topology as in VRF.
>
>
>
>
>
>
>
> Segmentation is analogous to VLAN (in L2 network) and VRF (in L3 network).
> But unlike VRF where all the intermediate nodes can forward per VRF, in
> SDWAN Overlay, the multipoint to multipoint WAN is an overlay network. If
> using IPsec Point to Point tunnel, there would be N*(N-1) tunnels, which is
> too many to many.
>
>
>
> Does anyone know an existing protocol that can handle the above scenario
> described in
> https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-bess-bgp-sdwan-usage%2F&data=02%7C01%7Cldunbar%40futurewei.com%7C0122616e8155496367d708d762354640%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637085853266243839&sdata=jo6WEei6clyY04voV97hfw76CbJjJZJNO4t3YFesI2w%3D&reserved=0>
>
>
>
>
>
> Thank you very much.
>
>
>
> Linda Dunbar
>
>
>
>
>
>
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=02%7C01%7Cldunbar%40futurewei.com%7C0122616e8155496367d708d762354640%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637085853266243839&sdata=trin1bRzUoN4q95fs7vH%2FyjeMo9n7zI9DVUKCJUt2PY%3D&reserved=0>
>
>