[Idr] Seeking feedback to requesting a SD-WAN SAFI for advertising SD-WAN edge node’s capabilities: draft-dunbar-idr-bgp-sdwan-overlay-ext-00.txt

Linda Dunbar <linda.dunbar@huawei.com> Wed, 24 October 2018 02:43 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2730A130E5F for <idr@ietfa.amsl.com>; Tue, 23 Oct 2018 19:43:52 -0700 (PDT)
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 b-8KZ-hQ7GWu for <idr@ietfa.amsl.com>; Tue, 23 Oct 2018 19:43:49 -0700 (PDT)
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 0C1D3130E51 for <idr@ietf.org>; Tue, 23 Oct 2018 19:43:49 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A6E7DAC57C18C for <idr@ietf.org>; Wed, 24 Oct 2018 03:43:44 +0100 (IST)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 24 Oct 2018 03:43:45 +0100
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.103]) by SJCEML702-CHM.china.huawei.com ([169.254.4.193]) with mapi id 14.03.0415.000; Tue, 23 Oct 2018 19:43:40 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "idr@ietf.org" <idr@ietf.org>
CC: "jgs@juniper.net" <jgs@juniper.net>, "shares@ndzh.com" <shares@ndzh.com>
Thread-Topic: Seeking feedback to requesting a SD-WAN SAFI for advertising SD-WAN edge node’s capabilities: draft-dunbar-idr-bgp-sdwan-overlay-ext-00.txt
Thread-Index: AdRrMj6MSRqSF4whQHGpN/KyHiyj9w==
Date: Wed, 24 Oct 2018 02:43:39 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B17C733@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.47.128.114]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B17C733sjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/dKLLupkU00HHzmTTctniMNrVS5k>
Subject: [Idr] Seeking feedback to requesting a SD-WAN SAFI for advertising SD-WAN edge node’s capabilities: draft-dunbar-idr-bgp-sdwan-overlay-ext-00.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2018 02:43:52 -0000

We are seeking feedback for requesting a new SD-WAN SAFI 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. Details on why and what are described in our new draft: https://www.ietf.org/internet-drafts/draft-dunbar-idr-bgp-sdwan-overlay-ext-00.txt

We understand the complication of having a new SAFI.
But, the mechanisms described by [draft-ietf-idr-tunnel-encaps-10] 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.
There is a suggestion on using a “Fake Route” for a SD-WAN node to use [draft-ietf-idr-tunnel-encaps] to advertise its SD-WAN tunnel end-points properties. However, using “Fake Route” can create deployment complexity for large SD-WAN networks with many tunnels. For example, for a SD-WAN network with hundreds of nodes, with each node having many ports & many end-points to establish SD-WAN tunnels to their corresponding peers, the node would need many “fake addresses”. For large SD-WAN networks (such as has more than 10000 nodes), each node might need 10’s thousands of “fake addresses”, which is very difficult to manage and needs lots of configuration to get the nodes provisioned.

In addition, hosts/applications attached to SD-WAN edge nodes can belong to different tenants, requiring SD-WAN nodes to establish different tunnels to different SD-WAN nodes. As shown in the figure below, C1 node alone has to establish following SD-WAN tunnels:
•       two SD-WAN tunnels to C2: one for Tenant 1, another one for Tenant 2,
•       One SD-WAN tunnel to C3 for Tenant 1, and
•       two SD-WAN tunnels to C4: one for Tenant 1, another one for Tenant 2,

                                                     +----------+
                                            +--------+ Tenant 2 |
                                            |        +----------+
         +--------+                         |          +--------+
         | Tenant +--+                      |     +----| Tenant |
         | 1      |  |                      |     |    | 1      |
         +--------+  |    ................. |     |    +--------+
                     |  +-+-+           +-+-+     |
                     +--|C1 |---+   +---|C2 |-----+        +---------+
                        +-+-+   |   |   +---+        /-----+ Tenant 1|
                        / .    +-----+      .       /      +---------+
                       /  . +--| RR  |--+   .      /     +---------+
                      /   . |  +-----+   \  .     /------+ Tenant 3|
                     |    . |  Overlay    \ .    /       +---------+
                     |    . |  untrusted   +--+--+    +--------+
         +--------+  |    . |   Networks   | C4  |    | Tenant |
         | Tenant +--+    . |              |     |----| 2      |
         | 2      |       ..  \ +---+       +--+--+    +--------+
         +--------+       .....+C3 +..........+
                               +---+
                                 |
                                 |
                       =====================
                         |               |
                     +--------+      +--------+
                     | Tenant |      | Tenant |
                     | 2      |      | 3      |
                     +--------+      +--------+


Thank you very much.

Linda Dunbar

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Sunday, October 21, 2018 8:41 AM
To: Linda Dunbar <linda.dunbar@huawei.com>; Haoweiguo <haoweiguo@huawei.com>; Wanghaibo (Rainsword) <rainsword.wang@huawei.com>; Linda Dunbar <linda.dunbar@huawei.com>; Haoweiguo <haoweiguo@huawei.com>
Subject: New Version Notification for draft-dunbar-idr-bgp-sdwan-overlay-ext-00.txt


A new version of I-D, draft-dunbar-idr-bgp-sdwan-overlay-ext-00.txt
has been successfully submitted by Linda Dunbar and posted to the IETF repository.

Name:           draft-dunbar-idr-bgp-sdwan-overlay-ext
Revision:       00
Title:          BGP Extension for SDWAN Overlay Networks
Document date:  2018-10-19
Group:          Individual Submission
Pages:          16
URL:            https://www.ietf.org/internet-drafts/draft-dunbar-idr-bgp-sdwan-overlay-ext-00.txt
Status:         https://datatracker.ietf.org/doc/draft-dunbar-idr-bgp-sdwan-overlay-ext/
Htmlized:       https://tools.ietf.org/html/draft-dunbar-idr-bgp-sdwan-overlay-ext-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dunbar-idr-bgp-sdwan-overlay-ext


Abstract:
   The document defines a new BGP SAFI with a new NLRI 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
   networks. The goal is for SD-WAN network to scale, enabling SD-WAN
   overlay tunnels among large number of SD-WAN nodes to be established
   with few provisioning needed.

   A "SD-WAN" tunnel refers to a point-to-point IPsec overlay path
   between two end-points that can aggregate multiple different types
   of underlay networks. An "end-point" is referring to a port on a SD-
   WAN node throughout this document.

   This document specifies new sub-TLVs for the SD-WAN Tunnel
   Encapsulation Attribute.




Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat