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

[Erik Auerswald <[e-mail]>]

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/
[e-mail] T:[phone] M:[phone]

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