[bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Linda Dunbar <linda.dunbar@huawei.com> Thu, 05 July 2018 15:53 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 1FE4E130F17 for <bess@ietfa.amsl.com>; Thu, 5 Jul 2018 08:53:15 -0700 (PDT)
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 CmvuCwERUc1c for <bess@ietfa.amsl.com>; Thu, 5 Jul 2018 08:53:12 -0700 (PDT)
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 F2148130F2B for <bess@ietf.org>; Thu, 5 Jul 2018 08:53:11 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id BA95C4FB80EA6 for <bess@ietf.org>; Thu, 5 Jul 2018 16:53:07 +0100 (IST)
Received: from SJCEML702-CHM.china.huawei.com ( by lhreml704-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 5 Jul 2018 16:53:09 +0100
Received: from SJCEML521-MBS.china.huawei.com ([]) by SJCEML702-CHM.china.huawei.com ([]) with mapi id 14.03.0382.000; Thu, 5 Jul 2018 08:53:03 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Eric C Rosen <erosen@juniper.net>, Ron Bonica <rbonica@juniper.net>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: comments and suggestions to draft-rosen-bess-secure-l3vpn-01
Thread-Index: AdQUd6UGClvRk5FQRUGF9YyejctT/A==
Date: Thu, 05 Jul 2018 15:53:02 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B07E161@sjceml521-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B07E161sjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/4I3dk0eP-22jb8TwdxFMF4o-xsM>
Subject: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 05 Jul 2018 15:53:28 -0000

Eric and Ron,

We think that the method described in your draft is useful for CPE based EVPN, especially for SD-WAN between CPEs.
But, it misses some aspects to aggregate CPE-based VPN routes with internet routes that interconnect the CPEs.

Question to you: Would you like to expand your draft to cover the scenario of aggregating CPE-based VPN routes with internet routes that interconnect the CPEs?

If yes, we think the following areas are needed:

*        For RR communication with CPE, this draft only mentioned IPSEC. Are there any reasons that TLS/DTLS are not added?

*        The draft assumes that C-PE "register" with the RR. But it doesn't say how. Should "NHRP" (modified version) be considered?

*        It assumes that C-PE and RR are connected by IPsec tunnel. With zero touch provisioning, we need an automatic way to synchronize the IPSec SA between C-PE and RR. The draft assumes:

p  A C-PE must also be provisioned with whatever additional information is needed in order to set up an IPsec SA with each of the red RRs

*        IPsec requires periodic refreshment of the keys. How to synchronize the refreshment among multiple nodes?

*        IPsec usually only send configuration parameters to two end points and let the two end points to negotiate the KEY. Now we assume that RR is responsible for creating the KEY for all end points. When one end point is confiscated, all other connections are impacted.

If you are open to expand your draft to cover SD-WAN, we can help providing the sections to address the bullets mentioned above.

We have a draft analyzing the technological gaps when using SD-WAN to interconnect workloads & apps hosted in various locations: https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/
Appreciate your comments and suggestions to our gap analysis.

Thanks, Linda Dunbar