[Isis-wg] Comments on draft-xu-isis-flooding-reduction-in-msdc-00

Erik Auerswald <auerswald@fg-networking.de> Tue, 18 April 2017 19:27 UTC

Return-Path: <auerswald@fg-networking.de>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8B7129C31 for <isis-wg@ietfa.amsl.com>; Tue, 18 Apr 2017 12:27:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 CAKLr-SLPkOu for <isis-wg@ietfa.amsl.com>; Tue, 18 Apr 2017 12:27:39 -0700 (PDT)
Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) (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 347EB1293D9 for <isis-wg@ietf.org>; Tue, 18 Apr 2017 12:27:38 -0700 (PDT)
Received: from mail.fg-networking.de (mail.fg-networking.de [131.246.197.23]) by mailgw1.uni-kl.de (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v3IJRUtp009575 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Apr 2017 21:27:30 +0200
Received: from fgn-t61 (unknown [10.122.4.15]) by mail.fg-networking.de (Postfix) with ESMTP id 4BE202007A; Tue, 18 Apr 2017 21:27:23 +0200 (CEST)
Received: by fgn-t61 (Postfix, from userid 1000) id 986D11065AB; Tue, 18 Apr 2017 21:27:23 +0200 (CEST)
Date: Tue, 18 Apr 2017 21:27:23 +0200
From: Erik Auerswald <auerswald@fg-networking.de>
To: Xuxiaohu <xuxiaohu@huawei.com>, isis-wg@ietf.org
Message-ID: <20170418192723.GB17787@fg-networking.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/Cv8RQEaYZ_qKeU18_aBXf0axwYw>
Subject: [Isis-wg] Comments on draft-xu-isis-flooding-reduction-in-msdc-00
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Apr 2017 19:27:41 -0000

Hi,

after reading the openfabric draft I looked at other data
center related IS-IS drafts. I would like to comment on
draft-xu-isis-flooding-reduction-in-msdc-00.

I like the idea of using what the draft calls "controllers" to
regulate link-state information dissemination. This architecture
shows similarities to using route reflectors for BGP (RFC 4456) and
to Google's Firepath routing solution (see Jupiter Rising: A Decade of
Clos Topologies and Centralized Control in Google's Datacenter Network,
https://research.google.com/pubs/pub43837.html).

This idea can be realized using existing implementations, with additional
possible optimizations via IS-IS extensions. In fact I built a lab today
to play with the idea, using a couple of switches, one of which was used
as controller, and the others as fabric switches.

To prevent the "management network" of the draft to be used for data
forwarding, high link costs on these interfaces, both on controller and
fabric (i.e. non-controller) switches, suffices. This can and should be
symmetrical, there is no need for asymmetrical link costs as proposed
by e.g. openfabric. Another possibility is to set the overload bit for
the controllers.

RFC 2973, IS-IS Mesh Groups, can be used to prevent flooding on the
data path links.

The management network as described by the draft should not be interpreted
as a virtual router or VRF. Thus the (often single) management port
found on data center switches cannot be used for this purpose. Front
ports need to be used instead. The Dell Z9100-ON switch, for example,
provides two 1G/10G ports (in addition to 32 100G ports) that could be
used for redundant controller connections.

The controllers can be implemented using switches, or using x86 servers
running a routing daemon (e.g. BIRD, Quagga, ...). Small data center
networks could use two switches as controllers with a direct connection
from each data plane switch to each controller switch. If the fabric
comprises more switches than can be connected to a single controller
switch, two separate Ethernet networks comprised of standard switches can
be used to connect two servers acting as controllers. Each controller and
fabric switch could be connected to two independent Ethernet networks in
a resiliency model similar to Fibre Channel networks (SAN A & SAN B).
These simple Ethernet networks would not even need to rely on STP to
provide redundant controller connections. Each fabric switch would use
one VLAN to connect to management Ethernet one, and a different VLAN
to connect to management Ethernet two. If each management Ethernet is
comprised of just one controller switch connecting to all fabric switches,
one VLAN per controller switch suffices. The two controller switches
would not be connected. If two servers are used as controllers, each
could connect one routed port to each of the two management Ethernets.

The basic architecture of sending link-state information via controller
lends itself to further optimizations, e.g. suppressing link-state if
and only if a default or summary route pointing towards all connected
spines suffices. This would open the doors for traffic engineering via
controllers as well.

I'd say draft-xu-isis-flooding-reduction-in-msdc-00 shows a lot of
potential. It even allows experimentation today using readily available
parts (switches and open source routing daemons).

Thanks,
Erik
-- 
Dipl.-Inform. Erik Auerswald         http://www.fg-networking.de/
auerswald@fg-networking.de T:+49-631-4149988-0 M:+49-176-64228513

Gesellschaft für Fundamental Generic Networking mbH
Geschäftsführung: Volker Bauer, Jörg Mayer
Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630