[bess] what are the problems to anticipate with new SD-WAN SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext ?

Linda Dunbar <linda.dunbar@huawei.com> Mon, 05 November 2018 16:18 UTC

Return-Path: <linda.dunbar@huawei.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 9E7FD130DF2; Mon, 5 Nov 2018 08:18:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 7_Y-OXqeyPLB; Mon, 5 Nov 2018 08:18:54 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 B38F0130E0C; Mon, 5 Nov 2018 08:18:53 -0800 (PST)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 243135318788C; Mon, 5 Nov 2018 16:18:49 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 5 Nov 2018 16:18:50 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.103]) by SJCEML701-CHM.china.huawei.com ([169.254.3.13]) with mapi id 14.03.0415.000; Mon, 5 Nov 2018 08:18:37 -0800
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "idr@ietf.org" <idr@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: what are the problems to anticipate with new SD-WAN SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext ?
Thread-Index: AdR1IZ7N5hdOc6clTcOI7WPejCyj0w==
Date: Mon, 5 Nov 2018 16:18:37 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B182D88@sjceml521-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.126.173.228]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B182D88sjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/zqaZvvQdDub6N_tiTXn1RNAbDbs>
Subject: [bess] what are the problems to anticipate with new SD-WAN SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext ?
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 16:18:57 -0000

There are already >60 BGP SAFI being specified: https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml

Many people told me that New SAFI would requires changes to RR.

But to use RR to relay SD-WAN end point properties to the authorized peers, RR has to be enhanced.

For normal IPsec, edge nodes have to be provisioned with policies on which peers the edge nodes can establish IPsec SA. For large SD-WAN deployment, it becomes N square problem, as Ali described at the BESS session today. It scales much better if the SD-WAN CPE offload the Security Association Policy work to RR, by just advertising its properties to its corresponding RR:

-        RR can authenticate if the Peer is authorized to receive the Advertisement.
-        CPE and RR has to establish a secure channel first (such as TLS or DTLS) before CPE can propagate its end points properties to its RR
-        IPsec SA needs to re-key periodically, there will be many messages for the same tunnel, but with different IPsec SA subTLV.

Having a new SAFI makes RR implementation so much cleaner & simpler.

Really appreciate anyone can elaborate what are the problems to anticipate with new SD-WAN SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext ?

Thank you
Linda Dunbar