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

Linda Dunbar <ldunbar@futurewei.com> Mon, 04 November 2019 22:39 UTC

Return-Path: <ldunbar@futurewei.com>
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 268C4120072 for <bess@ietfa.amsl.com>; Mon, 4 Nov 2019 14:39:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.593
X-Spam-Level:
X-Spam-Status: No, score=-0.593 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 HluPtHLTiS6z for <bess@ietfa.amsl.com>; Mon, 4 Nov 2019 14:39:32 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760114.outbound.protection.outlook.com [40.107.76.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A17D12009C for <bess@ietf.org>; Mon, 4 Nov 2019 14:39:32 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ap5M8fS3EL8Lp1XXEOERaA/vtm54VxfzO/kzdA+CXh/AwthsL035XLQ1UeDSbPjwZSWnBE3pryiGtSb8cDgTmrjxvUUaJegUToBEpELh8Xr2Q4pwfFnC5s35x+59SZWLKqiH0gM87rGQ+4pQVVEfXvZaBVUDLwi3Zu71Hwvp6hy+wWD+5krpR1pxgBCqD/iKr2B36bjCGsEJDJT9qJEhE9aBqe1+AqXLntCBEPgndAnagJIml1FTo9WhTANDpgvaNKIq8vlMxf5ipXYnf05Md2pQcGfbi4xbKHA2uedjI+CbkoOu0C4NC6HavoAELda++Y31EflSWM5YhBaVZTnj5A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+rLyatNZEaq9AVQk/h2TzgXxCskgxvITUs/mF8LH9lk=; b=Y/CedjaAvm5hRitbI0iYNCDOpZbrKZHqQ6d3oKG0DhgX6cFti3+4Tf0bZf2n3GdSuEeLdcrg88tzjV9Uoui/tc6q0NrnvtYXJ3o+TG7UTG2mckbYmnESe3RZMG1HmX58CmGyXnBy81jSffEKCZnaUAX7XDYCgygirLLSSXJPtjdu4W7ACuYGWhvhyUlFB+Dm5ZaRzGZcFN1tBmO2Oxh/f9YQl8FRaPstOXl2cHRxvYrQtdk5C6CsWVJoVxID7IRBdimhpfdGc7IvOtiYxZc8GTtXN5k2SBvaMnMX5bsYGvMKAw8qZeNY0jdGD+lI0GakiZDE9AYtkVKbhN6Gz7sv+g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+rLyatNZEaq9AVQk/h2TzgXxCskgxvITUs/mF8LH9lk=; b=eaLO4Nn6zsOnspIli7c01Hh12A9taOhRCBxWxkLN5F8C0sSOhqnZGyYPoHNOU3SMI/5ZtkGTgwbKNQwcOkalJY+MG9ZK0+I/SU7OC54kHIKl1IGGuEq7N/fGQO+AI61ltp6phWaiKaE8RE8PHDzbhjRAZ+IaRY9nB31Dt66az0E=
Received: from BN8PR13MB2628.namprd13.prod.outlook.com (20.178.219.10) by BN8PR13MB2706.namprd13.prod.outlook.com (20.178.218.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Mon, 4 Nov 2019 22:39:30 +0000
Received: from BN8PR13MB2628.namprd13.prod.outlook.com ([fe80::cdcb:582a:8e76:9c17]) by BN8PR13MB2628.namprd13.prod.outlook.com ([fe80::cdcb:582a:8e76:9c17%3]) with mapi id 15.20.2430.014; Mon, 4 Nov 2019 22:39:30 +0000
From: Linda Dunbar <ldunbar@futurewei.com>
To: "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Any protocols suitable for Application Flow Based Segmentation in draft-bess-bgp-sdwan-usage-3?
Thread-Index: AdWTYJxA+BN8rE5sRpa1mjWPE2RXqg==
Date: Mon, 04 Nov 2019 22:39:29 +0000
Message-ID: <BN8PR13MB262842C35C9955B8B45FAF08A97F0@BN8PR13MB2628.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ldunbar@futurewei.com;
x-originating-ip: [12.111.81.95]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 94f59bb1-172c-4a14-7a6a-08d76177db10
x-ms-traffictypediagnostic: BN8PR13MB2706:
x-microsoft-antispam-prvs: <BN8PR13MB2706E1FFC571EC3BDE42AE51A97F0@BN8PR13MB2706.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0211965D06
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(39850400004)(396003)(136003)(376002)(366004)(189003)(199004)(6506007)(476003)(3846002)(71200400001)(2501003)(5660300002)(6116002)(26005)(71190400001)(81166006)(102836004)(6436002)(30864003)(2351001)(186003)(5640700003)(8676002)(6916009)(1730700003)(8936002)(81156014)(6306002)(7736002)(25786009)(305945005)(99286004)(74316002)(66446008)(55016002)(64756008)(66556008)(66476007)(76116006)(66946007)(66616009)(14444005)(256004)(33656002)(86362001)(316002)(966005)(2906002)(478600001)(66066001)(52536014)(486006)(99936001)(7696005)(14454004)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN8PR13MB2706; H:BN8PR13MB2628.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: L4AJCjozIy45JaH5QwfTyUfs1+4ObYuWW9E/JQYl4kTf8QnPfmg9zCoKISKmteZzkxE2eAhNnUEnDtmmRNboNZqQXMaPqYFFD1R12diI6c94H0OgmUNuGhhC5pjZfG54dDt7IZxGJ1ZnciiS2xTSFGb08BXvx5w+bngrm7T9mosBBR4aXP5c664ehcCQXf/LoecCSOIJr33JxiaXYSTvQreQbvhVHyB+HB5r6xFPE+nU/gXRzgL5RBeIHwIbbDOcReD2Ukj+TPEG706RGbXOiaBzChSNRs0CCRfKv2/JVZwHygXlhGNbYmm3X6T9KsrsF4QhlqWTXreM49FR7wi7jS0jjfZH1GVvkVGql/d2vGX17g01nimUg9bY/p/bMtQ4lGhElp+ZNhukyDeB20nszQBDInIQFAWrv6km6xf1D/AEkeO6pbrUq5fRhRWRBMNW
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_004_BN8PR13MB262842C35C9955B8B45FAF08A97F0BN8PR13MB2628namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 94f59bb1-172c-4a14-7a6a-08d76177db10
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2019 22:39:29.7219 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tQck3xqL3iY+RE3A9wi2I7DJB7Bfs3nasX6ZwUqCDD+OFCCvswxo7aFVHFMrm7xS3hp3DtE9U3DFs6gieSWV/A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR13MB2706
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/Y7m28W9mt14_meVnPSqTLzRm__I>
Subject: [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: Mon, 04 Nov 2019 22:39:34 -0000

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/


Thank you very much.

Linda Dunbar