[bess] Comments to draft-sajassi-bess-secure-evpn-00

Linda Dunbar <linda.dunbar@huawei.com> Fri, 18 January 2019 17:48 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 73058131264; Fri, 18 Jan 2019 09:48:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id sIze7jPxstAo; Fri, 18 Jan 2019 09:48:03 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com []) (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 82B65131266; Fri, 18 Jan 2019 09:48:01 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 417A8BC0FCFB1B6F31F1; Fri, 18 Jan 2019 17:47:59 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com ( by lhreml704-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 18 Jan 2019 17:47:58 +0000
Received: from SJCEML521-MBS.china.huawei.com ([]) by SJCEML701-CHM.china.huawei.com ([]) with mapi id 14.03.0415.000; Fri, 18 Jan 2019 09:47:54 -0800
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "draft-sajassi-bess-secure-evpn@ietf.org" <draft-sajassi-bess-secure-evpn@ietf.org>, "bess@ietf.org" <bess@ietf.org>
CC: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
Thread-Topic: Comments to draft-sajassi-bess-secure-evpn-00
Thread-Index: AdSvVd0q3rG1i83dQiC+NuxXU2lhmg==
Date: Fri, 18 Jan 2019 17:47:54 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B24D300@sjceml521-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B24D300sjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/1yRii5JQjj2Tx0L-AYbm6DhubZI>
Subject: [bess] Comments to 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: Fri, 18 Jan 2019 17:48:06 -0000

Ali, et al,

One of the requirement you stated in the document is (under the section 2.3)

   "1) Per pair of PEs: A single IPsec tunnel between a pair of PEs to be used for all tenants' traffic supported by the pair of PEs."

Assuming that the solution is intended for SD-WAN.  The SD-WAN edge nodes usually have some ports connected to trusted domain (e.g. MPLS network) which doesn't need IPsec tunnel, and some ports connected to untrusted domain (e.g. Internet) which needs IPsec tunnel. Therefore, for PE based IPsec tunnel, it is necessary to associate the WAN ports (facing untrusted domain) with the IPsec tunnels.

Actually, even for other granularity (such as Per tenant, Per Subnet, or per IP) IPsec tunnels, it is necessary to associate with the WAN ports as well because the trusted domain doesn't need IPsec SA.

Linda Dunbar