[Idr] Request a 10 minutes presentation slot at IDR Interim on 10/26/2018 for draft-dunbar-idr-bgp-sdwan-overlay-ext-00

Linda Dunbar <linda.dunbar@huawei.com> Thu, 18 October 2018 15:33 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 5E1D5130E9C for <idr@ietfa.amsl.com>; Thu, 18 Oct 2018 08:33:23 -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 44vcjepkcqEJ for <idr@ietfa.amsl.com>; Thu, 18 Oct 2018 08:33:20 -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 D87F912F295 for <idr@ietf.org>; Thu, 18 Oct 2018 08:33:19 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 3AA47B2E3A611 for <idr@ietf.org>; Thu, 18 Oct 2018 16:33:16 +0100 (IST)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 18 Oct 2018 16:33:17 +0100
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.103]) by SJCEML703-CHM.china.huawei.com ([169.254.5.30]) with mapi id 14.03.0415.000; Thu, 18 Oct 2018 08:33:11 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Request a 10 minutes presentation slot at IDR Interim on 10/26/2018 for draft-dunbar-idr-bgp-sdwan-overlay-ext-00
Thread-Index: AdRm918/hoL43lu3R/iPU6catOCGcg==
Date: Thu, 18 Oct 2018 15:33:10 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B175C8C@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.192.11.112]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B175C8Csjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RO_uw037CSczgo8es0eCak70Rl8>
Subject: [Idr] Request a 10 minutes presentation slot at IDR Interim on 10/26/2018 for draft-dunbar-idr-bgp-sdwan-overlay-ext-00
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: Thu, 18 Oct 2018 15:33:30 -0000

Sue and John,

I would like a 10 minutes slot at the IDR Interim on 10/26/2018 for draft-dunbar-idr-bgp-sdwan-overlay-ext-00 (to be uploaded this weekend).

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.

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

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, October 04, 2018 12:57 PM
To: idr@ietf.org
Subject: [Idr] Interim on 10/26/2018 instead of IETF 103

Greetings:

IDR will have an virtual interim on 10/26/2018 from 10:00 - 12:00 ET instead of a meeting at IETF 103.

Both chairs will not be able to attend IETF 103.  John Scudder let me know at IETF 102 that he had another commitment. This week I found out that my husband will be for surgery during first 10 days of November - so I will not be able to attend IETF 103.

Please send John and I requests for presentations at the interim on 10/26/2018.

Susan Hares
Co-chair IDR