Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00

"Ali Sajassi (sajassi)" <sajassi@cisco.com> Sun, 04 November 2018 15:02 UTC

Return-Path: <sajassi@cisco.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 8B02C130E0E; Sun, 4 Nov 2018 07:02:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.969
X-Spam-Level:
X-Spam-Status: No, score=-14.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 hSZwqOUI-60S; Sun, 4 Nov 2018 07:02:04 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52BA5130DD9; Sun, 4 Nov 2018 07:02:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20886; q=dns/txt; s=iport; t=1541343724; x=1542553324; h=from:to:subject:date:message-id:mime-version; bh=cArWyxRy/cf3OTsPEZYzKmhT5C3uKrKLx6BdhS4nq8M=; b=PAa+P0ub4HYeAyx37ekqm0YPztZZxgC9Th9AT9Qv5qe5lIAp3ngaKyVl EwyMIDRNLsPnb9pKcI+VlvUqp+qRjHJvjEa82+l3zqcUkgeqfpheWbUXT GcoHLj6goPbyYDH69qYFBQLfVyI7AVWk05ywsECaGURRkl7CR/7bzN56I U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ApAAAGCd9b/4cNJK1jHAEBAQQBAQcEAQGBUQcBAQsBgQ1IL2Z/KAqDbIgYjBWBaCWRWYVUgXoLAQElhEcZgyciNA0NAQMBAQIBAQJtHAyFOgEGI2gBCBEDAQIkBwIEMB0KBAEJCRuDBgGBHWQPpyOBLoQ/QIUQBYtZHReCAIERJwwTgh4ugxsCAwGBfYJkMYImAokGhViGKolWVAkChmyDJIZ/GJBgjQiKFwIRFIEmHTiBVXAVOyoBgkGCLBISiEuFPm+NDYEfAQE
X-IronPort-AV: E=Sophos;i="5.54,464,1534809600"; d="scan'208,217";a="475808446"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Nov 2018 15:02:02 +0000
Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id wA4F225d009318 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 4 Nov 2018 15:02:03 GMT
Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 4 Nov 2018 10:02:01 -0500
Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1395.000; Sun, 4 Nov 2018 10:02:02 -0500
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, "idr@ietf.org" <idr@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00
Thread-Index: AQHUdE9XmdLiJU5oSUqEW64fomgVyA==
Date: Sun, 04 Nov 2018 15:02:01 +0000
Message-ID: <B05ED9DA-28CA-4561-B20A-50FC1EBA01E2@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.123.216]
Content-Type: multipart/alternative; boundary="_000_B05ED9DA28CA4561B20A50FC1EBA01E2ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.143, xch-rtp-003.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/FpzWgcMKHpAxMKWrusvhgBqLJs4>
Subject: Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by 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: Sun, 04 Nov 2018 15:02:07 -0000

Just finished reading your draft and I don’t think the two drafts are complimentary. Frankly, I don’t see any advantages for using a separate SAFI for this purpose but many disadvantages such as:


  1.  Resurrecting the approach in RFC 5512 that is being deprecated – i.e., send a separate route for the tunnel and then color the other routes to associated with the tunnel (using indirection) and opposed the current common practice in Tunnel Encap attribute that sends the attribute directly with the corresponding route.
  2.  When establishing IPsec tunnel at a more granular level (e.g., per pair of VPN MAC or IP addresses), you need to advertise twice as many routes !!
  3.  The overhead associated with a new SAFI as opposed to use exiting attribute
  4.  NAT can be handled without the new SAFI

The secure tunnel between each PE and the RR (e.g., IPsec) for the BGP session is common between the two drafts as mentioned first by the controller-ike draft. This is needed because you want to make sure that the BGP session goes over a tunnel that is authenticated between the peers (and encrypted). Intuitively the use of tunnel encap attribute for IPsec should be clear as IPsec is another tunnel type and key exchange parameter, transfer function, DH groups, etc. are attributes/properties of such tunnel and thus to be advertised in this new tunnel type TLV.

Let’s start with EVPN because that is the technology/solution being used predominately in DCs, DCIs, and enterprise inter-site connectivity. I listed the disadvantages of using a separate SAFI above, can you list the advantages of using a separate SAFI for EVPN?

Cheers,
Ali

From: BESS <bess-bounces@ietf.org> on behalf of Linda Dunbar <linda.dunbar@huawei.com>
Date: Tuesday, October 30, 2018 at 9:19 AM
To: "idr@ietf.org" <idr@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Subject: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00

IDR group, BESS group,

https://datatracker.ietf.org/doc/draft-dunbar-idr-bgp-sdwan-overlay-ext/ specifies a new BGP SAFI (=74) in order to advertise a SD-WAN edge node’s capabilities in establishing SD-WAN overlay tunnels with other SD-WAN nodes through third party untrusted networks.

draft-sajassi-bess-secure-evpn-00 describes an EVPN solution for PE nodes to exchange key and policy to create private pair-wise IPsec Security Associations without IKEv2 point-to-point signaling or any other direct peer-to-peer session establishment messages.

I think those two solutions are not conflicting with each other. Actually they are compliment to each other to some degree. For example,

  *   the Re-key mechanism described by draft-sajassi-bess-secure-evpn-00 can be utilized by draft-dunbar-idr-bgp-sdwan-overlay-ext
  *   The SD-WAN Overlay SAFI can be useful to simplify the process on RR to re-distribute the Tunnel End properties to authorized peers.
  *   When SD-WAN edge nodes use private address, or no IP address, NAT properties for the end points distribution described draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.
  *   The secure channel between SD-WAN edge nodes and RR described by draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.

Any thoughts?

Thank you very much.

Linda Dunbar