Re: [bess] [Idr] 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

"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> Mon, 05 November 2018 09:35 UTC

Return-Path: <jorge.rabadan@nokia.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 96C281277BB; Mon, 5 Nov 2018 01:35:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.371
X-Spam-Level:
X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 YB6nywZ-xcZB; Mon, 5 Nov 2018 01:35:46 -0800 (PST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50118.outbound.protection.outlook.com [40.107.5.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9C9127133; Mon, 5 Nov 2018 01:35:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SFreLgnLfhlDPyU33J7JjA2DhsCowlIz8SsVIm5UOps=; b=Od8Ndc6w9lNtafe9i86yiLOoIK3KGBzHaTQQZeBkA4sHdPbBMtP9fOiBiNz7rKB8RszvvobcRkOhRBBSPgW+YyebQZwOaPwcpLjhTS9QE5a8UScSO0iSjsaXR+fpLnXdw+8kpLA6qfb+yHDjbJZQVSUKi65Kh0404tUTX6N9fcE=
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com (52.134.82.20) by AM0PR07MB5249.eurprd07.prod.outlook.com (20.178.19.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.32; Mon, 5 Nov 2018 09:35:42 +0000
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::6996:3137:3456:ae8]) by AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::6996:3137:3456:ae8%5]) with mapi id 15.20.1294.032; Mon, 5 Nov 2018 09:35:42 +0000
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
To: "Ali Sajassi (sajassi)" <sajassi@cisco.com>, Linda Dunbar <linda.dunbar@huawei.com>, "idr@ietf.org" <idr@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [Idr] [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: AQHUdOrrRfuUk3CAmEaSp8CumT+rGg==
Date: Mon, 05 Nov 2018 09:35:42 +0000
Message-ID: <A2138809-FCE3-4AC5-BD5A-347BA5FE674A@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.12.0.181014
x-originating-ip: [110.170.235.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB5249; 6:iOXHNBnjzy1fQYTX4VuluRP9SBZzMybvdbTkG3YL4QQGZettZ0ILJKosu0Ji3C5r4PSh08aFifbnRXwKKrpCCwvYJMq+1kEmfDW+Tzhd5IrkQmgfLlPEhBUrKo9NXYqIqTkp7AfnUXEcbtXsTS2MdjdqzO4a+ZC5t4rMejNsXPIQM7mnTa5gX+IMqvEGi6ep3zoEQM7ITG88bJnpU/GNBprdlPhdDRt+FuJnsxBT/OktdAtpgTO8l40s5D2sfElYoCR74H1fyIEWuaDkbhA3VkPefeoTNPclXUxpk39EZQcI+HYjrpVk6XppqeRVpLwLLn1ZJ+5naJD1deRVykFYwYq4OilmFLu3lw0hKn34fCb2JS1KRfa8hFg2g1RGg5rKZILaw5FVdezmREy6IyGr63GAfRuXlGmIsizjQvetogy2A+N+eg1GHybC4JZg9hCasQ/eRZuhXlMNs2iaWRR1qw==; 5:APa3LjfkaO4URvtTKTzvn9kAqowfJxxXbhLF65liuifCCh5atfauWN8GO5QyepPF/wUr0F8203CStcUOiCwdemuni5Vhifbvvq8BNQk+v7LKRChbzUShFmBXlrjucn5ZGilNC5R7ghRMRsHRVhRWk+c8iHOX9MhuL4mdEOFDzCo=; 7:nm3tylSUeeYrVnghX/6xZxJUCaSDgA4AibKv2r3By7tzjYcxTt3feZc6vF87QaPQVwKkFEu+VKA1cCy7IgY3R8a2X+tE9LW17Bk1KRfuFoQdHfgwnFH+lJM+ZGtZt9/bI74vwS58sQtm/zJCjOPxWQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: e3a3b745-2e7a-470f-0b27-08d643020e31
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7167020)(7193020); SRVR:AM0PR07MB5249;
x-ms-traffictypediagnostic: AM0PR07MB5249:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jorge.rabadan@nokia.com;
x-microsoft-antispam-prvs: <AM0PR07MB52496629DFE89F04556D73B7F7CA0@AM0PR07MB5249.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(269456686620040)(95692535739014)(120809045254105)(192374486261705)(50582790962513);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(11241501184)(806099)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB5249; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB5249;
x-forefront-prvs: 08476BC6EF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(396003)(366004)(136003)(199004)(189003)(81166006)(6246003)(256004)(5024004)(14444005)(36756003)(25786009)(81156014)(316002)(110136005)(58126008)(8676002)(26005)(6506007)(2906002)(102836004)(55236004)(53546011)(478600001)(33656002)(186003)(99286004)(2501003)(2616005)(14454004)(71200400001)(71190400001)(7736002)(83716004)(476003)(966005)(6116002)(3846002)(66066001)(229853002)(2900100001)(305945005)(68736007)(5660300001)(82746002)(105586002)(6436002)(486006)(6486002)(53936002)(8936002)(86362001)(106356001)(6306002)(6512007)(97736004)(2201001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB5249; H:AM0PR07MB3844.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:3;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: jTugxu4Php93EQHHWb2P2O36Ef6GfNTA1HFEIpISPcij2DC1NUDM7A7qJ31vHRK1hZQLgkciJH8AcQhoCmwRzr4UyRpdfEAbGqbN+PBwvlQg4NHUSRWoSsAtCIz26XKwwlny7SztIqIkwJ1D5ZpljQrs33jJkaPW8Nq+AGCr/VaIlzJo5BoUTxoZsAIk2909PTZ1fQiXCd2UwEw+F0CCIHgDOjZ1O1zfzUepdK5mdCejKqOcF5GtIt6rm1L7NJ5gUmQesNK6ZiaOiWixUY48UdE6nYsBXJSWh2jD69/lIkdasJzPp7bY4cMeIs3EplE1QEtJMJxVUGjPjMsr8f++sWvwWeOcwsSpG/AZjqb3TLg=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <CB1D66C918F83B408CD87D9247B74563@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e3a3b745-2e7a-470f-0b27-08d643020e31
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2018 09:35:42.5754 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5249
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/F-OdVlO2HYZcTnKO2g93HPfyzsM>
Subject: Re: [bess] [Idr] 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: Mon, 05 Nov 2018 09:35:48 -0000

Ali,

About that granularity, I have a couple of questions about the table in page 17, and the corresponding sections.
 
a) per PE granularity, EVPN case: wouldn't make sense to use an EVPN route? EVPN is the only AFI/SAFI deployed in many networks, so I would really use an EVPN route for this. We could use the AD per-ES route with ESI=0, as we did in RFC8317.

b) per tenant, EVPN case: in a Layer-3 tenant, a given BD may not be attached to all the PEs of the L3 tenant domain, hence the IMET route may not work. An alternative for L3 tenants is to use an SBD in all the PEs and use an IMET on the SBD.  

And a last comment: I think section 9 is a copy paste error from another draft ;-)

Thank you.
Jorge




From: Idr <idr-bounces@ietf.org> on behalf of "Ali Sajassi (sajassi)" <sajassi@cisco.com>
Date: Monday, November 5, 2018 at 12:11 AM
To: Linda Dunbar <linda.dunbar@huawei.com>, "idr@ietf.org" <idr@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [Idr] [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

 
Linda,
 
You should read my draft again as it explains IPsec tunnels needed at different level of granularity and how this can be achieved with existing routes. The traffic does not get sent till the IPsec tunnel is established between a pair of endpoints and the draft specifies 6 different types of endpoints for different level of granularity – i.e., per PE, per tenant, per subnet, per IP, per MAC, and per AC.
 
Cheers,
Ali
 
From: Linda Dunbar <linda.dunbar@huawei.com>
Date: Sunday, November 4, 2018 at 7:00 AM
To: Cisco Employee <sajassi@cisco.com>, "idr@ietf.org" <idr@ietf.org>, "bess@ietf.org" <bess@ietf.org>
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
 
Ali, 
 
Your draft-sajassi-bess-secure-evpn-00 defines two new Tunnel Types along with its associated sub-TLVs for The Tunnel Encapsulation Attribute [TUNNEL-ENCAP]. 
 
[Tunnel-Encap] cannot be effectively used for SD-WAN overlay network because a SD-WAN Tunnel needs to be established before data arrival. There is no routes to be associated with the SD-WAN Tunnel.
 
How do you address those issues? 
 
Linda
 
From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] 
Sent: Wednesday, October 31, 2018 12:04 PM
To: Linda Dunbar <linda.dunbar@huawei.com>; idr@ietf.org; bess@ietf.org
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
 
Hi Linda,
 
I haven’t read your draft yet. I am traveling now but will plan to read your draft over next couple of days and respond to your questions.
 
Cheers,
Ali
 
From: BESS <mailto:bess-bounces@ietf.org> on behalf of Linda Dunbar <mailto:linda.dunbar@huawei.com>
Date: Tuesday, October 30, 2018 at 9:19 AM
To: "mailto:idr@ietf.org" <mailto:idr@ietf.org>, "mailto:bess@ietf.org" <mailto: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