[spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

Linda Dunbar <linda.dunbar@futurewei.com> Mon, 08 July 2019 22:11 UTC

Return-Path: <linda.dunbar@futurewei.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FB91202CF for <spring@ietfa.amsl.com>; Mon, 8 Jul 2019 15:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=0.001] autolearn=ham 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 VSvpkr43Qr3z for <spring@ietfa.amsl.com>; Mon, 8 Jul 2019 15:11:13 -0700 (PDT)
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680100.outbound.protection.outlook.com [40.107.68.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26049120338 for <spring@ietf.org>; Mon, 8 Jul 2019 15:11:13 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xm09zF3EKwwbUahbKjJkrtpxk29CXtnj3oPTWk+LBGefMP25/FYt1yrCHLXE2AEFLa/W+nyPDssxJ2aTRVngMltUrw51DM4+Lpw1O7NouoctHqWYsskpDtMhZhlNujBgyp5jtlGDdH3ZrPaip9Y1ioQz5e5fiIXUCw8Cw+XFpEOwsncB3OtXXDpHpKhmqsLnn0UuAx4uAwZ45PhzQ0zyZH6byb+ox+7pn+qal6LgNUWUC6g3I9vcmoOdDDEkGK6aczgKtFEpqdfTzf3/GkeifOtgU+IZo0T+fwQjrvQbaDEmhj7oVa27Ifq/24qvrUG2ajGW3GX8f9qHwClv5cmK3Q==
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=JLmHMT906Hl+ge+6QftuvcQ1buk4j2zpDNwe0F+qnEQ=; b=V0hEvE/LOoCvlri3CFqC9CaVMTw4/zQbNE1hSlt0eqytrSJNLGse9II++UOKIiJtEW33qHqn1AmwiUqeQzm/shyS4D10Sf6vAeaxcUraYxl2tk+HjgH1QQLc4XPgqI+JlKezGKdhjmDTaER/AqK+Y1gS+qwIXo/alIayEV/XkO8PXi5VtzKvXEwoKBoqoi2B31njpf9XxwJo7SJZcj1x2h1+CCV/LcFN6LBG0Eu/E+iFed0nTgmbbfgo7qfRLp05QyFxreojAqn5+vzFpqZ0o3BQrPt9F0SJWd8Z+Ds1HRVabyjOVnC4CHxNEReG22NcP6SFONmXVIcwhBm69K+snw==
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=JLmHMT906Hl+ge+6QftuvcQ1buk4j2zpDNwe0F+qnEQ=; b=cQNQ4XoUO0uLWpv8ySsmnouSCjJQo+hwKtEMt30Dyx8Sf7E+SnYUXsSIGhKMRtCJ6PH0EsUbIA9VCgfE2X+6D/W1cDRLcf8SQr+SuYJdiuuZhv78DOV0Nt1BJphDZuCwP43WmXfrcfZYPvinLQWRwWECHxPvW8alfUmReDmpPMw=
Received: from MN2PR13MB3582.namprd13.prod.outlook.com (10.255.238.139) by MN2PR13MB2686.namprd13.prod.outlook.com (20.178.252.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Mon, 8 Jul 2019 22:11:11 +0000
Received: from MN2PR13MB3582.namprd13.prod.outlook.com ([fe80::e068:8461:62d7:e0c1]) by MN2PR13MB3582.namprd13.prod.outlook.com ([fe80::e068:8461:62d7:e0c1%7]) with mapi id 15.20.2073.008; Mon, 8 Jul 2019 22:11:11 +0000
From: Linda Dunbar <linda.dunbar@futurewei.com>
To: SPRING WG <spring@ietf.org>
Thread-Topic: Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?
Thread-Index: AdU12gZxiC6o7DmCSja15PZWT4zSoA==
Date: Mon, 08 Jul 2019 22:11:11 +0000
Message-ID: <MN2PR13MB35821DA403CCE784CB3B065D85F60@MN2PR13MB3582.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=linda.dunbar@futurewei.com;
x-originating-ip: [12.111.81.80]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bbd23282-ab51-4bb1-a823-08d703f12f51
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR13MB2686;
x-ms-traffictypediagnostic: MN2PR13MB2686:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <MN2PR13MB2686FB7D359E664464FEC38885F60@MN2PR13MB2686.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 00922518D8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(396003)(136003)(39840400004)(366004)(376002)(189003)(199004)(316002)(53936002)(76116006)(3846002)(790700001)(6116002)(71200400001)(86362001)(476003)(71190400001)(2906002)(68736007)(236005)(66476007)(55016002)(73956011)(66446008)(64756008)(9686003)(54896002)(66556008)(66574012)(52536014)(66946007)(5660300002)(6436002)(6306002)(8676002)(81166006)(6916009)(81156014)(26005)(102836004)(186003)(478600001)(33656002)(8936002)(7696005)(14454004)(966005)(99286004)(256004)(7736002)(74316002)(44832011)(606006)(25786009)(486006)(14444005)(66066001)(6506007)(193643001); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR13MB2686; H:MN2PR13MB3582.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-message-info: wt5Zgw686RDVBULQ156ICEq2/FvXXeGIUr1LZkSmP7N9taIad8gwGuPTbScj75xvR2nTm8rZAn6k789gvNT9gKGEzWDyewdlTpCHdu+EOwa6hGk+nyAfOf0l7ikK9rKdoucdUOLLpwJXkSIMNJv2naIksHAGU4/d9o+e1Wk3m9EtqK0WGjOoRE66HT36Zh79c8risiGYXKDDI0roBn37O7cpGfz1cvpyAOWWU1Vn/tRcD7O6yQfEyd0Iq+DSWYTiX8TFFPNOC8KyDM55kiBoZhuDCVeiljTuArn8pyQ6xo+nGh0Hk6kVJlM+Uj4bBOrbu9fXeMBma3i2FGoPAppyaPqjIgeIDVfQVqpJGzhGFi0kgKnEH+LH1BLfl7DHQRXytttuAv+8xKfqNgnk6dhmHAeCqTfFuGE1ob3UgB/Du94=
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB35821DA403CCE784CB3B065D85F60MN2PR13MB3582namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bbd23282-ab51-4bb1-a823-08d703f12f51
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 22:11:11.1027 (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: ldunbar@futurewei.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB2686
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/mvIlNxBm51RWc_ttzQOltmb2e8E>
Subject: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jul 2019 22:11:29 -0000

SD-WAN, as described by ONUG (Open Network User Group), is about pooling WAN bandwidth from multiple service providers to get better WAN bandwidth management, visibility & control.
Because of the ephemeral property of the selected Cloud DCs, an enterprise or its network service provider may not have the direct links to the Cloud DCs that are optimal for hosting the enterprise's specific workloads/Apps. Under those circumstances, SD-WAN is a very flexible choice to interconnect the enterprise on-premises data centers & branch offices to its desired Cloud DCs.
However, SD-WAN paths over public internet can have unpredictable performance, especially over long distances and cross state/country boundaries. Therefore, it is highly desirable to place as much as possible the portion of SD-WAN paths over service provider VPN (e.g. enterprise's existing VPN) that have guaranteed SLA and to minimize the distance/segments over public internet.

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/ describes a method to enforce a SD-WAN path's head-end selected route traversing through a list of specific nodes of multiple network segments without requiring the nodes in each network segments to have the intelligence (or maintaining states) of selecting next hop or next segments.

When a SR domain has multiple PEs with ports facing the external networks (such as the public internet or LTE termination), SD-WAN paths can traverse the SR domain via different ingress/egress PEs resulting in different E2E performance.

Even with the same ingress/egress, some flows may need different segments across the SR Domain. It is not practical, or even possible, for PEs to determine which Apps' flows should egress.
Segment Routing can be used to steer packets (or path) to traverse the explicit egress node, or explicit segments through the SR Domain based on the SLA requested by the SD-WAN head-end nodes.

When the SDWAN edge nodes are directly connected to the PEs of SR domain, is it appropriate for SDWAN edge nodes to use GRE/VxLAN header bits to indicate the desired SR Path?

We are looking for feedback, criticisms, or suggestion on the the proposed approach.

Thank you,
Linda